Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0005803opensim[REGION] Scripting Enginepublic2011-11-30 02:142012-12-04 07:08
ReporterSatomi Ahn 
Assigned ToBlueWall 
PrioritynormalSeveritymajorReproducibilityalways
StatusacknowledgedResolutionopen 
PlatformLinuxOSOpenSim 0.7.2 Release OS Version0.7.2
Product Version 
Target VersionFixed in Version 
Summary0005803: llMinEventDelay eats link messages
DescriptionI apologize in advance, for I am submitting a duplicate of issue 4370
http://opensimulator.org/mantis/view.php?id=4370 [^]
I would have commented there, but it seems comments on that ticket are closed.

Indeed, that ticket was resolved as "no change required", with no more explanations than "I believe this is the proper behavior".

I would kindly ask BlueWall to elaborate on this statement, with which I tend to strongly disagree (as you may already suspect ;)).

I do not pretend knowing the exact specification of OSSL/LSL, but if this was the expected behavior, then this would be a case were the actual behavior differs a lot from SecondLife, where no link message is ever lost (except when queues are full).

In SecondLife, in all appearance, llMinEventDelay() only postpones link_message events (and other events), so that they arrive with the specified rate, without destroying them.
Steps To ReproduceSee http://opensimulator.org/mantis/view.php?id=4370 [^]
Additional InformationI need this to be fixed for porting OpenCollar leash script to OpenSim, since it seems it is the last part that prevents it from fully working.
https://github.com/nirea/ocupdater/blob/master/lsl/OpenCollar%20-%20leash.lsl [^]

In this script, there is potentially a lot of at_target and not_at_target events triggered, increasing script time a lot if events were not throttled by llMinEventDelay().
However, like all other OpenCollar scripts, this script communicates with others using link messages, many of which can be triggered during initialization and after each user command.
llMinEventDelay() makes the leash script deaf to a majority of these messages, making it completely useless.

Current workaround: removing llMinEventDelay(), which I don't like since it means taking much script time again, which is not acceptable (at least not acceptable for SecondLife, but it would not be a good thing if OpenCollar scripts had to be different in the two environments).
TagsNo tags attached.
Git Revision or version number(I don't know)
Run ModeStandalone (1 Region)
Physics EngineBasicPhysics
Script Engine
EnvironmentMono / Linux64
Mono Version2.8
Viewer
Attached Files

- Relationships

-  Notes
(0020423)
Satomi Ahn (reporter)
2011-11-30 02:48
edited on: 2011-11-30 03:00

Further data:

* http://wiki.secondlife.com/wiki/LlMessageLinked [^]
Where it is said that *all* link_messages received during a delay should be executed when the delay is over, supporting my claim.

* According to http://lslwiki.net/lslwiki/wakka.php?wakka=scriptdelay [^] , different events behave differently with respect to script delays.

* In my case, I realized that using llSleep in at_target and not_at_target events might be equivalent to llMinDelayEvent in terms of script time. Maybe link_messages would still be eaten after one of those events, but at least a link_message won't cause such a sleep, which means that in a quick sequence of link_messages (typical in OpenCollar, where LMs often arrive in bursts), none will be missed. [EDIT] aaah it actually makes things even worse: no LM goes through now, since there are always at_target and not_at_target events blocking the event queue with their llSleep :(.

(0020424)
BlueWall (administrator)
2011-11-30 05:34
edited on: 2011-11-30 05:36

You can probably remove the function altogether, because calling it from state_entry will only delay once. The function must be called inside the event you want to delay. Test it with these scripts. Name the transmitter prim "transmit". It should be the root prim in the linkset too.

It seems that the wiki are wrong about this. So is our implementation ...


//
// transmit
//
integer count;

default
{
    state_entry()
    {
       count = 0;
    }
    
    touch(integer detected)
    {
        count++;
        llSay(0, "Count: " + (string) count);
        llSay(-10, "Say Count: " + (string) count);
        llMessageLinked(LINK_SET, count, "Link Count:" , NULL_KEY);
    }
}


//
// receive
//
default
{
    state_entry()
    {
        
        llListen(-10, "transmit", "", "");
    }
    
    listen(integer chan, string name, key id, string msg)
    {
        llMinEventDelay(10.0);
        llSay(0, msg);
    }
    
    link_message(integer src, integer nval, string sval, key kval)
    {
        llSay(0, sval + (string) nval);
    }
}

(0020425)
BlueWall (administrator)
2011-11-30 05:37

This function does not behave as stated on the Wiki, and our implementation doesn't work as SL.
(0020426)
Satomi Ahn (reporter)
2011-11-30 07:17

Only once?
According to the wiki, and to my experience (in both implementations), llMinEventDelay() has a permanent effect.
What would be the difference with llSleep() if llMinEventDelay() worked only once?
Or were you actually answering about llSleep()?
(0020427)
BlueWall (administrator)
2011-11-30 18:30

did you try the scripts in SL?
(0020428)
Satomi Ahn (reporter)
2011-11-30 23:39

Just did.
Ah, I see: putting a llMinEventDelay inside an event (other than state_entry) will make the min delay only affect that event.

This is undocumented but can be useful.

However, in state_entry, llMinEventDelay will affect all events (I just verified again in your example, by moving llMinEventDelay to touch_start).
(0023123)
Satomi Ahn (reporter)
2012-11-14 06:11

The patch below suffices to fix the problem, making listen and link_message event ignore min event delays. Not sure whether this is the exact behavior in SL though (I wonder if the event are not supposed to just be enqueued, waiting until the end of the delay to be all dequeued... which I fail what good it would achieve, having everything happening at once.... so I hope this interpretation is wrong).

Anyway, link messages events are not lost anymore, I believe this is the essential point.

Patch:

diff --git a/OpenSim/Region/ScriptEngine/Shared/Instance/ScriptInstance.cs b/OpenSim/Region/ScriptEngine/Shared/Instance/ScriptInstance.cs
index 5793cc9..06e2f3b 100644
--- a/OpenSim/Region/ScriptEngine/Shared/Instance/ScriptInstance.cs
+++ b/OpenSim/Region/ScriptEngine/Shared/Instance/ScriptInstance.cs
@@ -585,7 +585,7 @@ namespace OpenSim.Region.ScriptEngine.Shared.Instance
             // If min event delay is set then ignore any events untill the time has expired
             // This currently only allows 1 event of any type in the given time period.
             // This may need extending to allow for a time for each individual event type.
- if (m_eventDelayTicks != 0)
+ if (m_eventDelayTicks != 0 && data.EventName != "listen" && data.EventName != "link_message")
             {
                 if (DateTime.Now.Ticks < m_nextEventTimeTicks)
                     return;
(0023190)
Satomi Ahn (reporter)
2012-12-04 07:08

Additional comment, after re-reading this thread.

My first comment mentions llSleep and how it also makes the script engine discard events that arrive during a llSleep.
This behavior is also wrong (or different from SecondLife's): events should still be queued.

- Issue History
Date Modified Username Field Change
2011-11-30 02:14 Satomi Ahn New Issue
2011-11-30 02:48 Satomi Ahn Note Added: 0020423
2011-11-30 02:51 Satomi Ahn Note Edited: 0020423 View Revisions
2011-11-30 03:00 Satomi Ahn Note Edited: 0020423 View Revisions
2011-11-30 05:34 BlueWall Note Added: 0020424
2011-11-30 05:36 BlueWall Note Edited: 0020424 View Revisions
2011-11-30 05:37 BlueWall Note Added: 0020425
2011-11-30 05:37 BlueWall Assigned To => BlueWall
2011-11-30 05:37 BlueWall Status new => acknowledged
2011-11-30 07:17 Satomi Ahn Note Added: 0020426
2011-11-30 18:30 BlueWall Note Added: 0020427
2011-11-30 23:39 Satomi Ahn Note Added: 0020428
2012-11-14 06:11 Satomi Ahn Note Added: 0023123
2012-12-04 07:08 Satomi Ahn Note Added: 0023190


Copyright © 2000 - 2012 MantisBT Group
Powered by Mantis Bugtracker