User talk:Fred Gandt

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...). -- Strife ^{(talk|contribs)} 20:36, 19 March 2010 (UTC)