Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0003009opensim[REGION] Scripting Enginepublic2009-01-19 01:402011-07-20 06:08
ReporterBob Wellman 
Assigned To 
PrioritynormalSeveritymajorReproducibilityalways
StatusconfirmedResolutionopen 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0003009: AllowScriptCrossing=true not working for prim moving itself across border
DescriptionI have AllowScriptCrossing=true and all is mostly well. I can drag a prim across a boundary and the script continues, I can attach a scripted prim and fly/walk across a boundary or even TP and it continues to run. Wonderful. Now all I have to figure out is how to make my scripted train move its self across a sim boundary and I will be a happy man.

However when the prims script (see below) itself moves the prim across the border the script freezes.

[Note: Both regions being run by the same Region Simulator instance using Unbuntu 8.1]
Additional InformationTry putting the script below into a prim in the middle of one sim with another sim to the east of it and clicking the prim. According the LSL wiki on llSetPos positions > 256 will move over the border (i.e 257 = +1 region and 1 meter in). So the prim should slowly cross to the middle of the adjacent sim and then come back again but it doesn’t. It gets to the border and freezes and a subsequent click jumps it to 2 meters from the west of the original sim and the script stops running and wont reset.

//lsl

default
{
state_entry()
{
llSay(0,”ready”);
}
touch_start(integer num_detected)
{
integer a = 0;
integer b = 255;
vector speed1 = ;
vector speed2 = speed1 * -1;
llSay(0,”Forward”);
for(1; a < b; ++a)
{
llSetPos(llGetPos() + speed1);
}

a = 0;
llSay(0,"Reverse");
for(1; a < b; ++a)
{
llSetPos(llGetPos() + speed2);
}
llSay(0,"Stop");
}
}

TagsNo tags attached.
Git Revision or version number
Run Mode Grid (Multiple Regions per Sim)
Physics EngineODE
Script Engine
EnvironmentUnknown
Mono VersionNone
Viewer
Attached Files

- Relationships
has duplicate 0004090closedTeravus llSetPos() out of region loops coordinates into same region 

-  Notes
(0009297)
BlueWall (administrator)
2009-02-10 09:20

OpenSimulator Server 0.6.2.8320 (OS ) ChilTasks:True PhysPrim:True
Linux 32 Bit / Mono 2.2

Script error report in client...
Traveller: Error compiling script:
Cannot find script assembly and no script text present
Traveller: Error compiling script:
Cannot find script assembly and no script text present


Console output...
12:09:55 - [HGScene]: Home user BlueWall Slade
12:09:55 - [SOG]: Finished deserialization of SOG Traveller, 4ms
12:09:55 - [XEngine]: Loaded script Traveller.New Script
12:09:55 - [XEngine]: Loaded script Traveller.Afterburn
12:10:03 - [INTERREGION]: Exception deleting the old object left behind on a border crossing for Traveller d6d0426a-b0d7-497c-9f4c-ae20e398b70c (<136.786, 250.936, 24.71538>), System.Threading.ThreadAbortException: Thread was being aborted
  at (wrapper managed-to-native) object:__icall_wrapper_mono_thread_interruption_checkpoint ()
  at (wrapper managed-to-native) System.Threading.Thread:Abort_internal (object)
  at System.Threading.Thread.Abort () [0x00000]
  at Amib.Threading.Internal.WorkItem.Abort () [0x00000]
  at Amib.Threading.Internal.WorkItem+WorkItemResult.Abort () [0x00000]
  at OpenSim.Region.ScriptEngine.XEngine.XWorkItem.Abort () [0x00000]
  at OpenSim.Region.ScriptEngine.Shared.Instance.ScriptInstance.Stop (Int32 timeout) [0x00000]
  at OpenSim.Region.ScriptEngine.XEngine.XEngine.OnRemoveScript (UInt32 localID, UUID itemID) [0x00000]
  at OpenSim.Region.Framework.Scenes.EventManager.TriggerRemoveScript (UInt32 localID, UUID itemID) [0x00000]
  at OpenSim.Region.Framework.Scenes.SceneObjectPartInventory.RemoveScriptInstance (UUID itemId) [0x00000]
  at OpenSim.Region.Framework.Scenes.SceneObjectPartInventory.RemoveScriptInstances () [0x00000]
  at OpenSim.Region.Framework.Scenes.SceneObjectGroup.RemoveScriptInstances () [0x00000]
  at OpenSim.Region.Framework.Scenes.Scene.DeleteSceneObject (OpenSim.Region.Framework.Scenes.SceneObjectGroup group, Boolean silent) [0x00000]
  at OpenSim.Region.Framework.Scenes.Scene.CrossPrimGroupIntoNewRegion (UInt64 newRegionHandle, OpenSim.Region.Framework.Scenes.SceneObjectGroup grp, Boolean silent) [0x00000]
(0009301)
BlueWall (administrator)
2009-02-10 09:51

Also, I get the same Script error dialog output when dragging the prim across the border - but, not the console output.

These regions are running in the same OpenSim instance
(0009312)
Diva (administrator)
2009-02-10 19:02

I don't think the desired behavior is here yet, but these latest commits may have made things a little better. The prim should cross and stop; clicking on it again makes it go forward again.

So there's still a bug or two here, because the prim doesn't continue, but it's not as bad as before. Please confirm.
(0009313)
Diva (administrator)
2009-02-10 19:11
edited on: 2009-02-10 19:14

Melanie may know this better than I do, but I think we're far from being able to support the behavior you want with that script. As far as I know, we're not storing the execution state of the script, only the data state.

You have the script on a for loop when it crosses:
for(1; a < b; ++a)
{
   llSetPos(llGetPos() + speed1);
}

We would have to know where exactly the script was running when it crossed the border, and then start it from that exact same point.

But I may be wrong.

(0009314)
Diva (administrator)
2009-02-10 19:35

oh, I have good news. So that script of yours doesn't work, but this does:
(place it in a prim 0000081:0000050 m from the border; it only goes ~90m)

vector pos;
integer a = 0;
integer b = 30;
vector speed1 = <3,0,0>;

default
{
    state_entry()
    {
        llSay(0,"Forward!");
        pos = llGetPos();
        llSetTimerEvent(0.5);

    }
    touch_start(integer num_detected)
    {
        llSay(0,"Forward");
        pos = llGetPos();
        llSetTimerEvent(0.5);
    }
    
    timer()
    {
        if (++a < b)
        {
            pos = pos + speed1;
            llSetPos(pos);
        }
        else
        {
            llSetTimerEvent(0);
            llSay(0, "Stop");
        }
    }
}
(0009321)
Bob Wellman (reporter)
2009-02-11 01:09

Hi Diva... thank you for looking at this and your positive comments.

I tried your script out(on SVN 8785 using Xengine) but unfortunately it also didnt work for me.

The object proceeds to the border but doesnt cross. Instead it disappears and reappears at a postion 2 meters into the original sim and then the script stops resonding.

My guess would be we have 2 problems here.
1) llSetPos should take positions > 256 and do the following
   a) postion = postion - 256
   b) sim = sim + 1
   It only seems to do a)and not b).
2) As you said the script does not resume activity in the new simulator where it left off in the first simulator. Instead it stops working.

We are due to upgrade our grids SVN soon (maybe a week or so) and when we do I will try it again and report back. I assume you are running a newer SVN than us.

Thanks for trying... Bob
(0009338)
Diva (administrator)
2009-02-11 08:30

There is no SVN 8785. The current head is 8336.
The script I pasted above would only work starting in 8331.
(0009345)
BlueWall (administrator)
2009-02-11 10:11

Running with OpenSim to allow binaries still throws errors. Running without allowing binaries causes the script to re-compile. There is no idea of state. Setting a timer by touch to start the process of moving works to move the prim until it is across the boundary. Then the script re-compiles and needs to be touched again to restart it.

Setting the timer in the state_entry restarts the timer after the crossing when the script compiles.
(0009346)
Bob Wellman (reporter)
2009-02-11 10:17

oops.. sorry for the typo .. I meant to type SVN 7875.... Thanks for the heads up. Ill try again after we upgrade beyond SVN 8331.
(0009347)
BlueWall (administrator)
2009-02-11 10:20

using the timer to move the prim isn't needed. It just needs to be able to continue what it was doing when it re-compiles
(0009350)
Diva (administrator)
2009-02-11 12:58

BlueWall, your last message was totally cryptic :-) What?? Can you give an example?
(0009362)
BlueWall (administrator)
2009-02-11 17:41
edited on: 2009-02-11 17:45

sorry about that, it was an observation I made after my other note. The object stops moving, I get a message telling me that the script compiled, then it took off again. Here is the script I used to test it...

Thanks!


vector BlueLake = <256000.000000,255744.000000,0.000000>;



// Pass a global position to this function, and the object
// will move there.
setGlobalPos(vector globalDest) {
    vector localDest;
    do {
        localDest = globalDest - llGetRegionCorner();
        llSetPos(localDest);
    } while (llVecDist(llGetPos(), localDest) > 0.1);
}

default {
    state_entry() {
       llSetTimerEvent(10);
       setGlobalPos(BlueLake + <128, 128, 30>);
    }

    timer() {
        llSay(0,"<>");
    }
    
    on_rez(integer _parm) {
        llResetScript();
    }
}

(0009364)
WWWench (reporter)
2009-02-11 18:35

The details in sailing club's Mantis 3017 may help.
(0009366)
Diva (administrator)
2009-02-11 18:59

yes. What seems to be happening is that the script is always compiled and restarted on the other side. That is, state_entry is called again on the other side. This is, of course, different from what happens in SL. But those of you who care about these self-moving prims, you can use this to your advantage, for now.

I have a feeling that global variables are restored to their last values, though.
(0009385)
OwenOyen (reporter)
2009-02-12 08:33
edited on: 2009-02-12 08:37

Not sure I have followed this thread precisely. The object in question is non physical and not applicable to sailing simulation, but the fundamental problem is certainly either very similar or identical for the physical objects we are using to float across borders for this testing in the sailing regions growing on OSG. (Re mantis 3017)

A reset of scripts in objects traversing borders so that state-entry is re-executed would be devastating to the sailing simulation we are doing. The boat would be once again awaiting an unmoor command, reset virtual wind to the default (which might not be the wind selected for a race) and go non physical awaiting permission to assign controls to the AV. All very bad.

If the global variables are restored, this addresses some of these issues. Why do things happen differently in SL?

(0009386)
melanie (administrator)
2009-02-12 08:54

Currently, execution state is not preserved, but data state is. That means, all global variables are restored and the script is run on the other side with the state it had. If state_entry is re-executed that is an error that points towards a bad start flag being passed on region crossing. Normally, this recompile and restart is meant to be transparent, it should not run state_entry and should not give a "compile successful" message.
If there is a binary, even the recompile should not happen at all.
However, as was observed above, the for loop in the first example script would indeed forcibly be aborted (that ThreadAbortException should be caught and ignored, though!) and the script will be re-run in the new sim with the event following the event that was aborted. In the case of the first sample script, that would mean the for loop never gets started again.
After Diva stabilizes the region crossing stuff, I will look into these issues again. Right now, I'm pretty hands-off so I don't step on her feet.
(0009387)
Diva (administrator)
2009-02-12 09:12

Melanie: please go ahead, I'm done with prim crossing. I've introduced a new thing that will help pass any missing information from xml2: look at SceneObjectGroup.ExtraToXmlString / ExtraFromXmlString. In remote calls, that string is passed as another field, separate from the xml2 field. You can add more stuff there, whatever is missing.

We can chat more on the IRC about new comms details.
(0009563)
Bob Wellman (reporter)
2009-02-18 15:37
edited on: 2009-02-18 15:39

I have now updated to SVN 8437 and retried the script suggested by Diva. It still doesnt work for me.

What now happens is I start the prim at 206 meters in region A and it moves to 257 metres (this is what I see if I edit the prim) and it stops. If I edit the prim postion back to 206m it carries on running and steps to 257m again. This can be repeated until the number of prescribed steps have completed and then it stops.

So it appears the script refuses to cross over to the new region B (A+1)and reset 257m to 1m.

I must be missing something as it works fine for Diva but not for me ... any ideas?

BTW we are running both regions in the same Opensim.exe instance on Unbuntu 8.1 if that makes any difference

(0019008)
makopoppo (manager)
2011-07-20 06:04

I tested it with current 0.7.2-dev, the issue still exists. Setting "AllowScriptCrossing = true" and "TrustBinaries = true" doesn't change its behavior. Not megaregion.

This issue would be critical for pets creators, sim border crossing will blow off their pets every time...
(0019009)
makopoppo (manager)
2011-07-20 06:08

Reminder sent to: Instant Blue, Teravus

Integrated 0004090 into 0003009

----
Summary 0004090: llSetPos() out of region loops coordinates into same region
Description OpenSim 0.6.6.f9ee8be

The goal is to get a prim to cross a region boundary using llSetPos. The object started at <255, 125, 45>. I set it to move to <260, 125, 45>. It ended up jumping to <4, 125, 45> within the same region. Not only is this unexpected, but it is a 251 meter jump (way past the 10 meter limit). Both regions are hosted on the same sim.
Additional Information Hippo OpenSim Viewer 0.5.1 (LL 1.22.11) Mar 24 2009 17:47:38 (Hippo Release)
Release Notes

You are at 2558203.4, 2556027.5, 44.4 in Brianreavis located at c-76-100-8-247.hsd1.va.comcast.net (76.100.8.247:9011)
OpenSim 0.6.6 (Dev)

git# f9ee8be 2009-08-21 11:01:23 -0700 (OS Microsoft Windows NT 5.1.2600 Service Pack 3) ChilTasks:True PhysPrim:True


CPU: Intel Pentium III/Pentium III Xeon (0.25 micron process) with external L2 cache (3177 MHz)
Memory: 4095 MB
OS Version: Microsoft Windows Vista Service Pack 1 (Build 6001)
Graphics Card Vendor: NVIDIA Corporation
Graphics Card: GeForce 9600 GT/PCI/SSE2
OpenGL Version: 3.1.0

libcurl Version: libcurl/7.16.4 OpenSSL/0.9.7c zlib/1.2.3
J2C Decoder Version: KDU
Audio Driver Version: FMOD version 3.740000
LLMozLib Version: [LLMediaImplLLMozLib] - 2.01.26552 (Mozilla GRE version 1.8.1.13_0000000000)
Packets Lost: 286/24635 (1.2%)

(0013113)
Instant Blue (reporter)
2009-09-02 00:14

In OpenSIM.ini, AllowScriptCrossing = true
(0013114)
Teravus (administrator)
2009-09-02 02:08

Seems to be resolved in git head/master
(0013122)
Instant Blue (reporter)
2009-09-02 19:17
  
Updated OpenSIM to OpenSim 0.6.6 (Dev)

git# 994c5e2 2009-09-02 05:04:24 +0100

Problem still exists.
----

- Issue History
Date Modified Username Field Change
2009-01-19 01:40 Bob Wellman New Issue
2009-01-19 01:40 Bob Wellman SVN Revision => 8785
2009-01-19 01:40 Bob Wellman Run Mode => Grid (Multiple Regions per Sim)
2009-01-19 01:40 Bob Wellman Physics Engine => ODE
2009-01-19 01:40 Bob Wellman Environment => Unknown
2009-01-19 01:40 Bob Wellman Mono Version => None
2009-02-10 09:20 BlueWall Note Added: 0009297
2009-02-10 09:51 BlueWall Note Added: 0009301
2009-02-10 19:02 Diva Note Added: 0009312
2009-02-10 19:11 Diva Note Added: 0009313
2009-02-10 19:11 Diva Note Edited: 0009313
2009-02-10 19:14 Diva Note Edited: 0009313
2009-02-10 19:35 Diva Note Added: 0009314
2009-02-11 01:09 Bob Wellman Note Added: 0009321
2009-02-11 08:30 Diva Note Added: 0009338
2009-02-11 10:11 BlueWall Note Added: 0009345
2009-02-11 10:17 Bob Wellman Note Added: 0009346
2009-02-11 10:20 BlueWall Note Added: 0009347
2009-02-11 12:58 Diva Note Added: 0009350
2009-02-11 17:41 BlueWall Note Added: 0009362
2009-02-11 17:45 BlueWall Note Edited: 0009362
2009-02-11 18:35 WWWench Note Added: 0009364
2009-02-11 18:59 Diva Note Added: 0009366
2009-02-12 08:33 OwenOyen Note Added: 0009385
2009-02-12 08:35 OwenOyen Note Edited: 0009385
2009-02-12 08:35 OwenOyen Note Edited: 0009385
2009-02-12 08:36 OwenOyen Note Edited: 0009385
2009-02-12 08:37 OwenOyen Note Edited: 0009385
2009-02-12 08:37 OwenOyen Note Edited: 0009385
2009-02-12 08:37 OwenOyen Note Edited: 0009385
2009-02-12 08:54 melanie Note Added: 0009386
2009-02-12 09:12 Diva Note Added: 0009387
2009-02-18 15:37 Bob Wellman Note Added: 0009563
2009-02-18 15:39 Bob Wellman Note Edited: 0009563
2009-09-02 00:14 Instant Blue Relationship added has duplicate 0004090
2011-07-20 06:04 makopoppo Note Added: 0019008
2011-07-20 06:04 makopoppo Status new => confirmed
2011-07-20 06:08 makopoppo Note Added: 0019009


Copyright © 2000 - 2012 MantisBT Group
Powered by Mantis Bugtracker