User talk:Fred Gandt

Comments about/for Fred Gandt

Please create a new section for comments made on a new subject by clicking the "+" tab rather than the "Edit" tab.

Please sign you comment by adding 4 tildes (these thingies ---> "~") at the end of your comment.

• E.g. "Blah blah blah ~~~~"

When you save your edit/creation the wiki will automatically convert the 4 tildes into your signature.

Abusive, offensive or otherwise inappropriate comments will be removed and reported to Linden Labs.

touch_start and SVC-3017

You posted a new example to touch_start and touch_end but it looks like it shouldn't work properly due to SVC-3017. Either your example does not work properly, or both SVC-3017 and the documentation that relies upon it needs to be updated. Also, the comment "A minor concern to take note of..." is a bit confusing. -- Strife ^{(talk|contribs)} 04:59, 31 January 2010 (UTC)

Considering the amount of noise in SVC-3017, I'm thinking the caveat (I rewrote the crappy Note) has little to do with SVC-3017 or SVC-3017 has mutated to include more than it's title. -- Strife ^{(talk|contribs)} 05:20, 31 January 2010 (UTC)

Hiya. I haven't read all of SVC-3017 and I can't imagine wanting to. The example script I posted does exactly what it says on the tin but, I'll pomp the notation up if you think it needs it. I encountered SVC-3017 many many months ago and can confirm that there is/was a bug that shows up if you use touch events to swap states (vague?) but I just got on and fixed it and no longer have the scripts. -- Fred Gandt ^{(talk|contribs)} 08:30, 31 January 2010 (UTC)

I have read and posted to the jira on this issue. The script example posted here and here is to demonstrate the way things are at present and helps to show the touch_ chain to a learner. It may demonstrate bugged behavior but it is the behavior we live with.<lsl>default

{// On returning here (from state other) the touch chain will be damaged. // To trigger the touch_start (again) the prim will have to be touched twice.

   touch_start(integer nd)
   {
       state other;
   }

} state other {

   state_entry()
   {
       llSetTimerEvent(0.1);
   }
   timer()
   {
       state default;
   }

}</lsl>The above demonstrates the bug SVC-3017 was originally posted to highlight. The "two issues" are clearly so closely related that they have become one (rightly). -- Fred Gandt ^{(talk|contribs)} 11:42, 31 January 2010 (UTC)

Ah good, so the caveat is wrong. I'll remove it. -- Strife ^{(talk|contribs)} 00:51, 1 February 2010 (UTC)

All this new stuff we are getting is awesome!! Thanks LL.

Thanks LL. Looking forward to playing with all the new goodies. -- Fred Gandt ^{(talk|scripts|contribs)} 01:17, 2 March 2010 (UTC)

llGetPos

Is this really the right place for demonstrating this concept? -- Strife ^{(talk|contribs)} 22:08, 12 March 2010 (UTC)

Since the separation of floats from vectors is very useful when writing scripts dealing with positions and two of the simplest functions (I suppose the example should also be added to llSetPos) (and thus the most likely to be used first by new scriptors) that deal with positions are llGetPos and llSetPos, it stikes me as the perfect place to show how to do it. I learned to script by reading the wiki and had no idea floats of vectors could be used separately until seeing it done in a very obscure example (so obscure I cannot remember where it was). It wasn't presented as an available option and as far as I know until I added this example isn't. I can't think of a better place to demonstrate to new scriptors that it not only can be done but how. Where would you demonstrate it? -- Fred Gandt ^{(talk|scripts|contribs)} 00:51, 13 March 2010 (UTC)

Changed the example. I would value your opinion. But I ask that we continue a discussion if your opinion is that an example of how to do this is not needed. I strongly feel that all the help a learner can get is awesome. -- Fred Gandt ^{(talk|scripts|contribs)} 05:38, 13 March 2010 (UTC)

llSetSitText

Your recent addition makes me wonder about the functionality. I propose it's doing one of the following:

1. It ignores the command to update sit-text when made from child prims (which is what your caveat basically says)
2. Each prim has it's own sit text but the client only displays that of the root (what I think is actually happening)

I believe you use to be able to: if you had the edit window open and select individual enabled, select a prim by left clicking upon it, then right clicking on it would bring up that prim's pie menu. With that you would see the sit text for that prim. If that fails, you could set the sit text from a script in a child prim and then unlink the object, if the unlinked child (that contains the script) has the sit text (as specified by the script) we know that it is a primitive property that the client doesn't display. If either of these tests provide a positive, we know it's #2, but if they both fail, we haven't conclusively proved #1 (the simulator could propigate the sit text of the root to all children upon unlinking; the client might not allow bringing up the pie menu for children).

-- Strife ^{(talk|contribs)} 02:05, 19 March 2010 (UTC)

Okies. I'll re-test tomorrow. I missed the possibility of #2 earlier. I get the idea. Such a long day.The constant server issues didn't help. Not that the issues effected me directly but I try and help out in groups where 4000 people logging in and out and many commenting on every little server issue....I'll test after some sleep. *waves* -- Fred Gandt ^{(talk|scripts|contribs)} 03:19, 19 March 2010 (UTC)

Updated the caveat. The info is now accurate but not sure about the actual wording. I can tend toward over explaining and trying to keep things short makes my head spin. See what you think? -- Fred Gandt ^{(talk|scripts|contribs)} 16:03, 19 March 2010 (UTC)

Not your fault, you didn't know the current behavior is viewed by some (myself included) as being a bug: SVC-4870. I hate to say this but I knew about this bug before we had JIRA. During the bad old days, bugs like this wouldn't get reported, there were just so many things wrong with LSL that we got pretty apathetic, or we thought they already knew about the bug. But we have jira now and a "Search JIRA for related Bugs" link (one of my better ideas... I think it was mine... I should really use it more often). -- Strife ^{(talk|contribs)} 20:36, 19 March 2010 (UTC)

Is it a bug? -- Fred Gandt ^{(talk|scripts|contribs)} 23:20, 19 March 2010 (UTC)

All a matter of perspective. I think it is but it could just be a design shortfall. -- Strife ^{(talk|contribs)} 18:32, 21 March 2010 (UTC)

Agreed. I said as much on the jira. I hadn't ever bothered with much use of either but, it seems obvious that being able to have linked seats or buttons show unique text would be a boon. Bug or not is isn't very clever the way it is. -- Fred Gandt ^{(talk|scripts|contribs)} 20:59, 21 March 2010 (UTC)

A boon it would be. There are some folks on Jira who just don't get that distinction; they equate poor design with bugs. It's situations like this when we need an "Improvement" issue type (they have it on Atlasian's Jira). *sigh* -- Strife ^{(talk|contribs)} 00:53, 22 March 2010 (UTC)

"Improvement" type (closed as "Won't finish") request. -- Fred Gandt ^{(talk|scripts|contribs)} 01:56, 26 March 2010 (UTC)

The thing that bugs me (pun intended) about the jira is that feature requests and thus improvement requests are so often left unassigned and seemingly dormant for sooooo very long. Then because they are NEVER put forward for triage, if they are being considered we have no input or feedback to know one way or another what if any decisions are being made. The whole foundation idea of SL was (or so I thought) "User Created Content" but, the very part of SL development that is a halfway point between making stuff inworld and getting involved with developing a better grid is almost entirely missing. What makes my skin crawl is that SL is supposed to be the web in 3D. A better way to share the internet. Where are the Linden Labs inworld offices (not the office hours)? If we find a bug why do we not go to the Linden Labs garage where Greesemonkey Linden (dressed in overalls and carrying a large wrench) meets us out front and asks "Have you checked the oil recently?" with a wry look on his animated face. Why if we have a support question do we not visit the Linden Labs Support complex where we take a virtual ticket and wait in the virtual foyer for our number to be called? Using outside websites to deal with inside issues baffles me completely. Seems to be totally counter-intuitive. -- Fred Gandt ^{(talk|scripts|contribs)} 04:44, 22 March 2010 (UTC)

Feature suggestions

I've been intentionally avoiding putting feature suggestions in the articles. It's not that they aren't useful, they just aren't as useful as bugs. I've given it some thought and here are my criteria:

• Is this feature request a response to an existing caveat? If not, is the documentation significantly deficient as a result?
• Is the functionality requested so obvious that it is often requested?

It only needs to meet one of the two criteria. If you need an example of one that doesn't meet the criteria take a look at SVC-5700. I wouldn't be surprised if I had a cognitive bias towards my own feature suggestions and have subsequently violated my own rules. -- Strife ^{(talk|contribs)} 03:18, 24 April 2010 (UTC)

Lolz, I was just in the process of dealing with Ugleh's Talk page. I'll admit that I forgot to sign before but, I can't help feeling like I have been ripped off. Vector2List?? Yikes. Mind you...It does prove my earlier point about an explanation of how to grab floats from vectors ;-)

I saw you added instruction to that effect on the vector page. Ideal.

If you feel that the feature request I posted is not suitable, I am fine with you removing it. I have just seen so many of them around I thought it was "normal". There are even whole fake pages devoted to functions that don't exist. But I avoid fuss like the plague so, do what you will mate.

I actually quite chuffed that I managed to use a template properly. Shame it wasn't acceptable usage eh? lol. -- Fred Gandt ^{(talk|contribs)} 03:31, 24 April 2010 (UTC)

The content was already there, it needed some TLC to bring out its full potential.

I like to discourage the creating of feature request articles but they do fill a niche. The article can propose a feature but often can give the user a workaround user-function. So a user who stumbles upon the article thinking "ah! the solution to my problem" will still get a solution to their problem.

You did a good job building the template; I screw the Issue templates up all the time. It's inclusion is not black and white, it clearly falls in a gray area.

My vision for the documentation is incomplete, it always has been. I knew what attributes I wanted it to have but not what form it should take. As the documentation has evolved so has my understanding of it. There have been things that I have disapproved of, but as time has passed I've seen the value in them. The trick is to accommodate chaos and turn it into order; to capture the fleeting ideas of our users and pin them down in such a way that they are accessible and not overbearing (the purpose of documentation after all is to educate, not indoctrinate). Gray area content is often partially ordered chaos: A) we can mine it for trends and B) we can mine it for truth. If we deny it existence we deny ourselves growth opportunities.

So until I think up a good reason (or someone convinces me of a good reason) to remove it, it stays. Which is unlikely, and anyway, it might be useful. Right now it's not doing any harm, it's at the way bottom of the page. If I had thought your suggestion was black or white I wouldn't have posted but just acted. Because it's in a gray area I wanted to explain what I thought black and white were so you could decide for yourself.

I sometimes turn stupid caveats into feature suggests (as that way they get banished to the bottom of the page). I often cross post bug caveats to JIRA and reformulate the caveat because sometimes they don't have JIRA's yet. The Issue sections provide a way of cleansing the documentation while at the same time honoring those contributions. I may not agree with the contribution but I'll try to keep it around in one form or another. Which is why we have feature suggestions in the Issue tables. It's not really all about documentation, it's about people. They say the perfect computer system has no users, but how can a system be perfect without users to define perfection?

I'm rambling, I need to go to bed. -- Strife ^{(talk|contribs)} 04:53, 25 April 2010 (UTC)

Howdy do?

If the decision is up to me "to leave or, not to leave?" I would go with leave. Not because it's my baby but because it has great value as a request. Being able to block sitting on an object would save so much messing about with sit targets and unsitting. Also once the sit has occurred is too late in some conceivable circumstances.

• Is the functionality requested so obvious that it is often requested?

I think if not often requested, it would have been often wished for. I have many times (just not until recently made the request). Moreover, I would (just thought of this) also put the issue link on the llUnSit page. I really am not so fussy though Strife. If it dissapears I won't even look at the page history. There are plenty of things to worry about in the world....This isn't one of the most pressing. -- Fred Gandt ^{(talk|contribs)} 07:19, 25 April 2010 (UTC)

Question re: llEmail and email

I don't know the answer, but I will try to find out for you. --Rand Linden 23:49, 21 May 2010 (UTC)

User Page Edits

I'm with you, I don't like that scriptor changing my personal pages. I left another note on their talk page because they erased my first note. Looks like a consistent pattern now. Toady Nakamura 08:55, 4 November 2012 (PST)

Yeah, it's not on. If he edited your pages after I told him to leave mine alone, he should be firmly discouraged by admin. Fortunately, we have page histories and undo buttons or I'd be furious (more furious). fredgandt 09:54, 4 November 2012 (PST)