|Anonymous | Login | Signup for a new account||2020-09-28 23:29 PDT|
|Main | My View | View Issues | Change Log | Roadmap | Summary | My Account|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0008366||opensim||[GRID] Hypergrid||public||2018-09-11 21:48||2020-05-01 23:27|
|Target Version||Fixed in Version|
|Summary||0008366: Attached scripts lose all state on first hypergrid jump|
|Description||On the first HG jump to a foreign grid, scripts in all attachments cease working. They don't even receive a state_entry or CHANGED_REGION event. AO's, pose and photography HUD's, followcams, opencollars, mesh body HUDs will all stop working.|
While still in the destination at the foreign grid, if we then cross or TP into another region on the same destination grid, scripts will start working again but have totally reset, lost all stored state like variable contents that they still had when leaving our own grid initially.
- Scripts are enabled on the destination grid regions
- Happens between fast grids as well as slow grids
- Happens even with one single scripted attachment with a small script
- I've heard this DID work between two hypergridded OS 0.8 regions, yet to confirm
I don't know whether this bug is limited to specific viewers (in this testcase I used the latest Firestorm)
|Tags||No tags attached.|
|Git Revision or version number|
|Run Mode||Grid (1 Region per Sim)|
|Environment||Mono / Linux64|
|Attached Files||0001-Mantis-8366-Attached-scripts-lose-all-state-on-first.patch [^] (1,853 bytes) 2020-05-01 23:27 [Show Content]|
|Doesn't work either for the first jump from a 0.8 region to another grid's 0.8 region so this issue has been around for a while.|
|Dupe of 8049 (I am not allowed to add that relationship)|
don't think viewers have anything to do with it
Sounds like just another HG "glitch"
Note that scripts transfer can only be expected to work between regions running similar versions, and same script engine. Xengine to Yengine may work, reverse will not.
There are also the diferent permissions settings...
But your observation that if failed already on old 0.8<->0.8 does point to a origianl issue somewhere on HG code
made a simple test wearing a box with this script
integer a = 0;
integer lastEv = 0;
llSay(0, "Script running");
llOwnerSay((string)a++ +" "+(string)lastEv);
lastEv = ch;
tested HG teleports btw my test grid and a a osg region almost on master
both on Yengine, but the issue should be on code paths shared by all engines.
on first HG tp the script did seem dead
repeating back and fw it did work fine
[04:09] Grid: The region you have entered is running a different simulator version.
Current simulator: OpenSim 0.9.1.1 osC2_master_b3690c_111151_091819 (Unix/Mono)
Previous simulator: OpenSim 0.9.1.0 Snail Dev (Win/.NET)
[04:09] Object: 32768
[04:09] Object: 256
[04:09] Object: 512
[04:10] Object: 11 512
[04:10] Object: 12 512
[04:13] Object: 32768
[04:13] Grid: Teleport completed from hop://127.0.0.1:9004/Dev%20Outreach/360/386/23 [^]
[04:13] Grid: The region you have entered is running a different simulator version.
Current simulator: OpenSim 0.9.1.0 Snail Dev (Win/.NET)
Previous simulator: OpenSim 0.9.1.1 osC2_master_b3690c_111151_091819 (Unix/Mono)
[04:13] Object: 256
[04:13] Object: 512
[04:14] Object: 13 512
tp to lbsa did a full reset, because lbsa is on Xengine.
return, worked fine.
btw don't make my mistake, always edit scripts on ground, not wearing them :)
thats another old issue
|Script working on the second try makes sense, the destination has the asset at that point, but during the first jump the asset arrives after you get there at which point the state cannot be retrieved anymore, you have arrived already. Sending the attachments over before doing the jump would likely solve this, but that would mean redesigning the protocol.|
I don't have the bug after changing the following setting from co-op (default) to abort for the destination region, but there is a warning there in the comment about possible stability issues:
; Controls whether scripts are stopped by aborting their threads externally (abort)
; or by co-operative checks inserted by OpenSimulator into compiled script (co-op).
; co-op will be more stable as aborting threads can cause instability.
; abort was the default option in OpenSimulator 0.8 and before.
; If this setting is changed between co-op and abort, then existing scripts will automatically be recompiled if necessary.
; However, the setting change will not take affect until the next time you restart the simulator.
; Setting changes will not affect state information stored for scripts.
; ScriptStopStrategy = co-op
ScriptStopStrategy = abort
This is on XEngine btw, I never really tried YEngine.
thx for the feedback
Yengine to Xengine will always reset scripts and lose state.
X to Y may work, because now Y can read X state, at least most the time.
but there are HG thingies..
My case is about XEngine hypergrid to XEngine (which works with 'abort' but not the default 'co-op'). That it fails with HG'ing YEngine to YEngine as well is interesting.
Be careful with testing, as you said once an attached script is cached it's fine on a return visit. Best test with fresh scripts.
I've attached a patch:
- Scripts work when TP from local to a HG region for the first time
- Scripts work when TP from local to the same HG region next times
Script state is preserved
Latest patch is better, although the previous one already worked really well. See date to attached patches for which is the latest.
I feel this bug is really severe because it breaks content/attachments and degrades the overall user experience regarding hypergridding. Re-attaching your attachments manually after a HGTP is NOT a solution!
I know it's a bit of a edge case and therefore difficult to test, but not impossible. Note that the hypergrid *destination* region (not local departure region) must have this little patch to see the fix in action.
Only the case of TP'ing from Y->X will have scripts restart but that's because no converter exists yet for the state Y->X (X->Y does work, as well as X->X of course)
|i did look to that, but got distracted by other code i seen ;)|
|2018-09-11 21:48||Lotek||New Issue|
|2018-09-12 06:35||Lotek||Note Added: 0032930|
|2019-09-20 01:13||Lotek||Note Added: 0035684|
|2019-09-20 03:36||UbitUmarov||Relationship added||has duplicate 0008049|
|2019-09-20 03:38||UbitUmarov||Note Added: 0035685|
|2019-09-20 04:14||UbitUmarov||Note Added: 0035686|
|2019-09-20 04:16||UbitUmarov||Note Added: 0035687|
|2019-09-20 04:21||UbitUmarov||Note Added: 0035688|
|2019-09-20 04:50||tampa||Note Added: 0035689|
|2019-12-05 10:44||Lotek||Note Added: 0035942|
|2019-12-05 10:49||UbitUmarov||Note Added: 0035943|
|2019-12-05 11:30||Lotek||Note Added: 0035944|
|2020-02-25 10:14||Lotek||File Added: 0001-Mantis-8366-Attached-scripts-lose-all-state-on-first.patch|
|2020-02-25 10:17||Lotek||Note Added: 0036227|
|2020-02-27 10:42||Lotek||File Deleted: 0001-Mantis-8366-Attached-scripts-lose-all-state-on-first.patch|
|2020-02-27 10:43||Lotek||File Added: 0001-Mantis-8366-Attached-scripts-lose-all-state-on-first.patch|
|2020-03-01 09:42||Lotek||File Added: 0001-0008366-Attached-scripts-lose-all-state-on-first-hyp.patch|
|2020-03-01 09:52||Lotek||Note Added: 0036231|
|2020-03-01 15:35||UbitUmarov||Note Added: 0036235|
|2020-05-01 23:27||Lotek||File Deleted: 0001-Mantis-8366-Attached-scripts-lose-all-state-on-first.patch|
|2020-05-01 23:27||Lotek||File Deleted: 0001-0008366-Attached-scripts-lose-all-state-on-first-hyp.patch|
|2020-05-01 23:27||Lotek||File Added: 0001-Mantis-8366-Attached-scripts-lose-all-state-on-first.patch|
|Copyright © 2000 - 2012 MantisBT Group|