Why has LSL after all these years not sorted their arrant stupid code logic?

[steph Arnott]

Does my head in. It is not logic.

Edited January 23, 2019 by steph Arnott

[Love Zhaoying]

Other people fail because their help does not solve your problem. Am I understanding correctly?

[steph Arnott]

2 minutes ago, Love Zhaoying said:

Other people fail because their help does not solve your problem. Am I understanding correctly?

Has nothing to do with that. LL has changed how code such as PARCEL_FLAG_ALLOW_CREATE_OBJECTS works. There used to be a micro second to get a comparision. Some time late last year it is zero. These clitches have been noticed by many script writters in SL over the last few months. It started i te main regions and is now in every server.

[Love Zhaoying]

4 minutes ago, steph Arnott said:

Has nothing to do with that. LL has changed how code such as PARCEL_FLAG_ALLOW_CREATE_OBJECTS works. There used to be a micro second to get a comparision. Some time late last year it is zero. These clitches have been noticed by many script writters in SL over the last few months. It started i te main regions and is now in every server.

Thank you for sharing your specific complaint. Have you considered filing a JIRA?

[Motoko Oanomochi]

Hello,

Outside the fact the "closed club" likes a lot patronize peoples here, it is true Jira is the way to declare a problem. You can make a ticket too.

On my personal side, I can say frankly I found LL peoples very often helpful. Now, it is on your side to prepare an example easy to reproduce for LL. And then you can go forward.

Best Regards, Motoko Oanomochi

[steph Arnott]

1 minute ago, Qie Niangao said:

I don't understand. A microsecond from when to when? I can speculate that llGetParcelFlags() might possibly have predictably taken until the next frame to return and now it sometimes returns in the same frame, but... that doesn't make much sense, so it's probably something else. But what?

The time the agent is registered by the sim server the teleport event is dropped instantly. You can not even do a test any more.

[Wulfie Reanimator]

4 minutes ago, steph Arnott said:

The time the agent is registered by the sim server the teleport event is dropped instantly. You can not even do a test any more.

The changed event works perfectly fine on teleport. I've used it very recently. Post the (full) code that isn't working for you and explain how it should work. I can guarantee that you've just made a mistake that you won't acknowledge and are shifting the blame on LL. This isn't the first time. 

Edited January 25, 2019 by Wulfie Reanimator

[Qie Niangao]

1 minute ago, Love Zhaoying said:

And why would someone write code that would fail, if it returned faster?

I've written hidden race conditions that only surface when something happens faster than it did when originally tested.

3 minutes ago, steph Arnott said:

The time the agent is registered by the sim server the teleport event is dropped instantly. You can not even do a test any more.

Now I'm more confused. So this is really about a dropped CHANGED_TELEPORT event? And it just spontaneously drops, not because the event queue overflowed with other events, perhaps generated faster than they used to?

[steph Arnott]

2 minutes ago, Qie Niangao said:

I've written hidden race conditions that only surface when something happens faster than it did when originally tested.

Now I'm more confused. So this is really about a dropped CHANGED_TELEPORT event? And it just spontaneously drops, not because the event queue overflowed with other events, perhaps generated faster than they used to?

It is not an event over flow. The event queue drops the change, it does not even get to this part. if (PARCEL_FLAG_ALLOW_CREATE_OBJECTS & Parcel_Flags). Every sim with no rezz is the same. Before there was sufficient time to opt out of the code block. That no longer happens.

[Qie Niangao]

8 minutes ago, steph Arnott said:

Before there was sufficient time to opt out of the code block. That no longer happens.

That's interesting. What event is this code block handling?

[steph Arnott]

1 minute ago, Qie Niangao said:

That's interesting. What event is this code block handling?

A HUD object to be rezzed on arrival. Worked fine for years now it jams the script at the change point. The code block tests for object rezz perms whether both none group and group. Several other issues have been noted by others regarding type message splitting.

[Love Zhaoying]

24 minutes ago, Qie Niangao said:

Now I'm more confused. So this is really about a dropped CHANGED_TELEPORT event? And it just spontaneously drops, not because the event queue overflowed with other events, perhaps generated faster than they used to?

The plot thickens!

[Qie Niangao]

21 minutes ago, steph Arnott said:

A HUD object to be rezzed on arrival. Worked fine for years now it jams the script at the change point. The code block tests for object rezz perms whether both none group and group. Several other issues have been noted by others regarding type message splitting.

I'm trying to understand this enough so I'd recognize it if it happened with my code. "Type message splitting" isn't a familiar term for me, but I'm still hung-up earlier: "it jams the script at the change point" means it doesn't get the CHANGED_TELEPORT event at all? But then... some other event is driving the rezzing?

Without seeing the code, I might guess that the CHANGED_TELEPORT fires, registers the parcel flags, but then the agent gets moved from the arrival point to a different parcel on the sim with more restrictive land settings before another event tries to trigger rezzing. But that definitely wouldn't happen on every sim with no rez. The alternative would be that this hypothetical "other event" is now firing sooner than the change() that includes a CHANGED_TELEPORT... but I'm consing-up castles of hypotheticals here.

[steph Arnott]

6 minutes ago, Qie Niangao said:

I'm trying to understand this enough so I'd recognize it if it happened with my code. "Type message splitting" isn't a familiar term for me, but I'm still hung-up earlier: "it jams the script at the change point" means it doesn't get the CHANGED_TELEPORT event at all? But then... some other event is driving the rezzing?

Without seeing the code, I might guess that the CHANGED_TELEPORT fires, registers the parcel flags, but then the agent gets moved from the arrival point to a different parcel on the sim with more restrictive land settings before another event tries to trigger rezzing. But that definitely wouldn't happen on every sim with no rez. The alternative would be that this hypothetical "other event" is now firing sooner than the change() that includes a CHANGED_TELEPORT... but I'm consing-up castles of hypotheticals here.

No matter how you write this it will fail.

changed(integer ch)
    {
        if( ch&CHANGED_TELEPORT )
        { //it stops here. The event has been dropped from the queue as soon as the agent is registered with the server
            integer Parcel_Flags = llGetParcelFlags (llGetPos ());
            group_id = llList2Key(llGetParcelDetails(llGetPos(), [PARCEL_DETAILS_GROUP]), 0);
            if (PARCEL_FLAG_ALLOW_CREATE_OBJECTS & Parcel_Flags)// could be here, But it will go no further
            {
                llMessageLinked(Link_num,Link_Filter_11,"TelePort",owner_id);
                llRequestPermissions(owner_id, PERMISSION_TRIGGER_ANIMATION);
            }
            else if((PARCEL_FLAG_ALLOW_CREATE_GROUP_OBJECTS & Parcel_Flags) && llSameGroup(group_id))
            {
                llMessageLinked(Link_num,Link_Filter_11,"TelePort",owner_id);
                llRequestPermissions(owner_id, PERMISSION_TRIGGER_ANIMATION);
            }
            else
            {
                llOwnerSay ("Parcel dissallows creating objects. Rezzer is now toggled to off");
                state default;
            }
        }

 

Edited January 25, 2019 by steph Arnott

[Qie Niangao]

13 minutes ago, steph Arnott said:

No matter how you write this it will fail.

changed(integer ch)
    {
        if( ch&CHANGED_TELEPORT )
        { //it stops here. The event has been dropped from the queue as soon as the agent is registered with the server
            integer Parcel_Flags = llGetParcelFlags (llGetPos ());
            group_id = llList2Key(llGetParcelDetails(llGetPos(), [PARCEL_DETAILS_GROUP]), 0);
            if (PARCEL_FLAG_ALLOW_CREATE_OBJECTS & Parcel_Flags)// could be here, But it will go no further
            {
                llMessageLinked(Link_num,Link_Filter_11,"TelePort",owner_id);
                llRequestPermissions(owner_id, PERMISSION_TRIGGER_ANIMATION);
            }
            else if((PARCEL_FLAG_ALLOW_CREATE_GROUP_OBJECTS & Parcel_Flags) && llSameGroup(group_id))
            {
                llMessageLinked(Link_num,Link_Filter_11,"TelePort",owner_id);
                llRequestPermissions(owner_id, PERMISSION_TRIGGER_ANIMATION);
            }
            else
            {
                llOwnerSay ("Parcel dissallows creating objects. Rezzer is now toggled to off");
                state default;
            }
        }

 

Thanks for the code. Unfortunately I have to run off to a RL appointment so I probably can't get deeper on this today. It would be very weird if it actually gets stuck in an event handler without a loop or anything. The script just halts, doesn't process any more events? or it just doesn't seem to follow any of the branches in this specific handler?

(Just in passing, that's not how llSameGroup() works, but that doesn't explain anything about this problem.)

[steph Arnott]

2 minutes ago, Qie Niangao said:

(Just in passing, that's not how llSameGroup() works, but that doesn't explain anything about this problem.)

I have re-written it so many times i am sick of looking at.

[Qie Niangao]

I managed to sneak in for a quick test and I think I'm misunderstanding, because the following script (which is intended to do the same thing as above) seems to say the right thing under each condition, at least wherever I've tried it:

default
{
    state_entry()
    {
        llRequestPermissions(llGetOwner(), PERMISSION_TAKE_CONTROLS);   // debug while attached
    }
    attach(key av)
    {
        if (NULL_KEY != av)
            llRequestPermissions(av, PERMISSION_TAKE_CONTROLS);
    }
    run_time_permissions(integer perms)
    {
        if (PERMISSION_TAKE_CONTROLS & perms)
            llTakeControls(CONTROL_FWD, TRUE, TRUE);    // just to keep running on no-script land
    }
    changed(integer change)
    {
        if (CHANGED_TELEPORT & change)
        {
            integer flags = llGetParcelFlags(llGetPos());
            if (PARCEL_FLAG_ALLOW_CREATE_OBJECTS & flags)
                llOwnerSay("rezzing permitted for all");
            else
            if (PARCEL_FLAG_ALLOW_CREATE_GROUP_OBJECTS & flags)
            {
                key parcelGroup = llList2Key(llGetParcelDetails(llGetPos(), [PARCEL_DETAILS_GROUP]), 0);
                key myGroup = llList2Key(llGetObjectDetails(llGetKey(),[OBJECT_GROUP]), 0);
                if (myGroup == parcelGroup)
                    llOwnerSay("rezzing permitted for this group");
                else
                    llOwnerSay("rezzing FORBIDDEN -- wrong group");
            }
            else
                llOwnerSay("rezzing FORBIDDEN FOR ALL");
        }
    }           
}

 

[animats]

Oh, I see. I think. Not that it's clear. The original poster is complaining that, after a teleport event is reported, the conditions in the new sim haven't settled yet. It may be too soon to perform some operations. I've run into that at region crossings, but I haven't looked at teleports.

The "changed" event occurs fairly early during a region change. The sim knows there's been a region change, but the viewers may not have gotten the update yet. Animations often stop when crossing a region boundary, and you may have to restart them. Restart them too soon and you get an error. Check "llGetPermissions()" after a teleport or region crossing before trying to do anything that needs permissions. You lose those permissions momentarily on every region change.

 

[Kyrah Abattoir]

On 1/23/2019 at 1:31 PM, steph Arnott said:

Does my head in. It is not logic.

"The bad workman blame his tools."

 

When I want a new LSL feature implemented I submit a detailed and well written feature request on the Jira.
Sometimes it gets approved, sometimes it doesn't. But if you don't try it...

@steph Arnott People who make themselves very unlikeable are less likely to receive help, inspiring some empathy goes a long way.

Edited January 26, 2019 by Kyrah Abattoir

[steph Arnott]

6 hours ago, Qie Niangao said:

I managed to sneak in for a quick test and I think I'm misunderstanding, because the following script (which is intended to do the same thing as above) seems to say the right thing under each condition, at least wherever I've tried it:

 

It outputs the messages. That is as far as i got so far with it.

[Qie Niangao]

7 hours ago, steph Arnott said:

It outputs the messages. That is as far as i got so far with it.

Right, well the script I posted doesn't actually do anything more than llOwnerSay() the appropriate text message, but I thought I was testing the ability to branch conditional on a parcel flag, etc -- until @animats post above, which notes a common problem with trying to animate the avatar soon after teleporting. That's something the originally posted script appears to do, but it requests PERMISSION_TRIGGER_ANIMATION first, which should prevent that problem.

(What I'm not sure about is what happens to an existing llTakeControls() once PERMISSION_TAKE_CONTROLS is lost, as it will be if only PERMISSION_TRIGGER_ANIMATION is requested. I need to test whether that will defeat the attachment's ability to continue running on no-script land.)

[Love Zhaoying]

13 hours ago, animats said:

Oh, I see. I think. Not that it's clear. The original poster is complaining that, after a teleport event is reported, the conditions in the new sim haven't settled yet. It may be too soon to perform some operations. I've run into that at region crossings, but I haven't looked at teleports.

The "changed" event occurs fairly early during a region change. The sim knows there's been a region change, but the viewers may not have gotten the update yet. Animations often stop when crossing a region boundary, and you may have to restart them. Restart them too soon and you get an error. Check "llGetPermissions()" after a teleport or region crossing before trying to do anything that needs permissions. You lose those permissions momentarily on every region change.

 

Gee..maybe the solution is to just wait a specified amount of time after the changed (teleport) event. What say ye to that?

[Kyrah Abattoir]

@steph ArnottIt has absolutely nothing to do with "how" you write. But what you write.

[Qie Niangao]

1 hour ago, Qie Niangao said:

... what happens to an existing llTakeControls() once PERMISSION_TAKE_CONTROLS is lost, as it will be if only PERMISSION_TRIGGER_ANIMATION is requested. I need to test whether that will defeat the attachment's ability to continue running on no-script land.)

So much for that theory. After the script transitions from PERMISSION_TAKE_CONTROLS to only PERMISSION_TRIGGER_ANIMATION it can't call llTakeControls() again, but existing controls still work and the script continues to run on no-script land.

[EDIT: In case the point of this is lost, I'm still unsuccessful in replicating the reported problem. I don't think it's due to @animats ' quite correct observation that animation permission is disrupted at region change because the posted script requests the permission afresh on teleport (assuming that happens before any animation takes place) -- and anyway that should have just thrown a familiar permissions error which doesn't seem to be the problem as reported. My now disproven hypothesis was that the script might quit working because it re-requested animation permission if that made it lose the ability to run on no-script land, which turns out not to be the case. Hence I'm back at the starting point, unable to produce the problem.]

Edited January 26, 2019 by Qie Niangao

[Estelle Pienaar]

OK, then it was a misunderstanding. The title "Why has LSL after all these years not sorted their arrant stupid code logic?" made me understand something different (a flaw at the core of the concept of LSL) than what you meant.

Can you shortly tell us how the problem has been sorted? I haven't seen a solution in this thread or in the "Inter sim catchup". And now I am curious.  🙂