Are there any problems with running scripts?

[prootoxy]

Hello, how are you? I've been creating scripts for SL for a long time, and I've never encountered such a problem.

The problem I'm referring to is a simple "for", see the example:

 

test() {
   integer i = 0;
   for (; i <= 6; i++) {
        llOwnerSay((string)i);  
    }
}

default
{
    state_entry()
    {
        
    }

    touch_start(integer total_number)
    {

       test();
    }
}

This should give me an output from 0 to 6 but since yesterday this has been giving me strange outputs, follow the example:

Click 1: 

6
0
1
2
3
4
5

Click 2: 

3
0
1
2
4
5
6

I don't understand what's going on with my script, does anyone have a solution?

 

[Quistess Alpha]

16 hours ago, prootoxy said:

I don't understand what's going on with my script, does anyone have a solution?

the order you receive messages in is not guaranteed to be the order in which they were sent. Adding a short sleep after each message can increase the probability of a correct order, but in most cases, it shouldn't matter, and you can often consolidate the messages into a single message:

test() {
   integer i = 0;
   string send;
   for (; i <= 6; i++) {
        send+=(string)i+"\n";  
    }
   llOwnerSay(send);
}

[Love Zhaoying]

1 minute ago, Quistess Alpha said:

the order you receive messages in is not guaranteed to be the order in which they were sent.

Just in case the OP is wondering..

If the messages are sent via event (link_message, etc.) or certain other functions (llOwnerSay, llInstantMessage), or output to DEBUG_CHANNEL, the order seems fairly reliable.  However, those methods have a built-in delay, limit, and/or other coding requirements. 

Using llSay() to DEBUG_CHANNEL for instance, has a "throttle" that if you send too many messages in too short a time, the messages are ignored after the limit is reached.

I have only NOTICED an issue with llSay() and messages arriving "out of order".

 

[Quistess Alpha]

2 minutes ago, Love Zhaoying said:

I have only NOTICED an issue with llSay() and messages arriving "out of order".

Same with me, but there are too many variables to make general claims. It could even be weird internet connection flukes.

[Love Zhaoying]

19 minutes ago, Quistess Alpha said:

Same with me, but there are too many variables to make general claims. It could even be weird internet connection flukes.

Yeah, that's why I included the "NOTICED" caveat.

AFAIK, any function that uses "queueing" Events, is pretty reliable to get delivered "in order" since that is part of..the point..with "queuing".  IMO.

 

[Quistess Alpha]

19 minutes ago, Love Zhaoying said:

AFAIK, any function that uses "queueing" Events, is pretty reliable to get delivered "in order" since that is part of..the point..with "queuing".  IMO.

No matter what happens server-side (in LSL) I don't think there's any order verification in the client, (nor does the client send back received verification AFAIK) so, "pretty reliable" is the best you can hope for. I'm not sure what you mean by a "queueing event" but if you mean something like a timer() then it would be more reliable, if only because each event runs in a different 'frame' of computation, which adds an imperceptible delay.

Edited February 10 by Quistess Alpha

[Love Zhaoying]

27 minutes ago, Quistess Alpha said:

No matter what happens server-side (in LSL) I don't think there's any order verification in the client, (nor does the client send back received verification AFAIK) so, "pretty reliable" is the best you can hope for. I'm not sure what you mean by a "queueing event" but if you mean something like a timer() then it would be more reliable, if only because each event runs in a different 'frame' of computation, which adds an imperceptible delay.

I am mostly referring to messages sent between scripts, and by extension - especially with an llSleep() then to the viewer. The viewer is the least of my worries usually.

Not sure I saw it mentioned, but also without any scripts at all, chat between users is commonly delivered out of sequence.

[Quistess Alpha]

2 minutes ago, Love Zhaoying said:

I am mostly referring to messages sent between scripts

I've never had occasion to rapid-fire messages from one script to another, but I'd assume script-to-script order is somewhat more reliable than script to viewer?

[Love Zhaoying]

2 minutes ago, Quistess Alpha said:

I've never had occasion to rapid-fire messages from one script to another, but I'd assume script-to-script order is somewhat more reliable than script to viewer?

Yep. I've never had issues with script-to-script messages being "out of order", noting that I'm not talking about "listen()" so much as "link_message()".  It would be interesting if "listen()" messages can also get out of order like viewer-displayed messages.

..There appear to be 2 identical threads about this right now..

[Wulfie Reanimator]

1 hour ago, Quistess Alpha said:

No matter what happens server-side (in LSL) I don't think there's any order verification in the client, (nor does the client send back received verification AFAIK) so, "pretty reliable" is the best you can hope for. I'm not sure what you mean by a "queueing event" but if you mean something like a timer() then it would be more reliable, if only because each event runs in a different 'frame' of computation, which adds an imperceptible delay.

UDP network packets (which is used for all chat) have no built-in verification (unlike TCP), but LL has implemented its own "reliable" messages for certain UDP traffic. These have to be acknowledged by the receiver or they will be sent again. Reading material for nerds: Message, Circuit, Packet Accounting, Packet Layout

While the inherent delay from events and [something that takes time] might help with messages arriving in the expected order, things can always arrive out of order with enough network lag or packet loss or low bandwidth setting or simply a busy CPU.

Edited February 10 by Wulfie Reanimator

[Bleuhazenfurfle]

On 2/11/2024 at 4:51 AM, Love Zhaoying said:

Yeah, that's why I included the "NOTICED" caveat.

AFAIK, any function that uses "queueing" Events, is pretty reliable to get delivered "in order" since that is part of..the point..with "queuing".  IMO.

This is pretty much exactly it.  Within or between scripts, events are just shoved directly into the target scripts queue, and will happen in order.  But as soon as it touches the network...  Like llSay (also llOwnerSay and friends), prim updates, etc., that's where things can get out of order (all the UDP stuff Wolfie mentioned).

If I'm writing a lot of text (even llOwnerSay), I'll generally shove a 0.1s sleep between them — and still things occasionally get through out of order.  So try to make it order independent.