Main | My View | View Issues | Change Log | Roadmap | Summary | Docs | My Account
  

Viewing Issue Simple Details [ Jump to Notes ] [ View Advanced ] [ Issue History ] [ Print ]
ID Category Severity Reproducibility Date Submitted Last Update
0002853 [opensim] [REGION] Scripting Engine major random 2008-12-16 16:12 2009-08-10 07:52
Reporter WWWench View Status public  
Assigned To WWWench
Priority normal Resolution fixed  
Status closed   Product Version
Summary 0002853: several XEngine scripts break or run on restart
Description When I update tis a 'hope' if the boat scripts work. That also happens on a few Nebadon scripts as well as Owen's IceBoat and SailBoat. The break gives no debug they just break on arrow keys.
My workaround since the Grid will not allow revert to a solid svn is to restart/shutdown and restart until it runs properly which is :(
Additional Information is related to;
mantis
2842
2777

This also happens on my Linux mono server but I lock to a svn that runs there.

1)happens in scripts with Avatar interaction, not only boat,
2)breaks with instance loading.
Tags No tags attached.
Git Revision
SVN Revision 7734
Run Mode Grid (Multiple Regions per Sim)
Physics Engine ODE
Environment .NET / Windows32
Mono Version None
Attached Files

- Relationships
child of 0002869closed META - Script-Engine Events - Event Loss, event lag 

-  Notes
(0008027)
Teravus (administrator)
2008-12-17 14:33

 Try 7742 or later. I added something that might help. Then again, it might not. I'm not sure. but it at least fixes a locking issue which *could* cause events to not be received.
(0008578)
Chri5 Somme (reporter)
2008-12-31 01:10

 Using 7901 same Win32 .NET environment and have same issue. Problem is not resolved.
(0009151)
jfhopkin (reporter)
2009-02-04 04:35

 Have been experiencing total loss of scripting for many revisions now. Typically, it'll work fine for a few hours, then without any error message scripts will no longer run at all. Create a new box, create the default script in it and the code in state_entry() doesn't run (no llSay()), not does anything else. The workaround is to rerun the sim, when it will work again for a while.

It's possible that this is happening on a region-by-region basis - ie scripting works in one region but not in another run by the same instance of OpenSim.exe. I don't have enough information to be able to say this with certainty.

Various revisions of OS, running on Ubuntu 8.10 Intrepid with Mono 1.9.1 and 2.0, region server only, OSGrid's UGAIM, four/five regions on single instance of region server, MySQL database, XEngine running LSL only. Various simple LSL scripts for things like poseballs, lights, "teleporters", texture animation, sound playing, single, simple HUD radar, that sort of thing. No vehicles or other scripts using control keys.
(0009226)
jfhopkin (reporter)
2009-02-07 13:22

 Upgraded to 8270, same setup as before, additional information on same problem:

It certainly is region-by-region. Immediately fter a fresh restart, I logged into region B, and scripts were not working on arrival. Relogged into region T, and scripts were working fine there. Relogged again into B and not working there.

I can think of no obvious difference between the two regions that might explain this - both have a few hundred prims and perhaps 15 or so running scripts. None of the scripts in either region is particularly exotic or complex - in B, they're mainly poseballs and "teleporters" (avatar transporters using "warp" technique). There are no listening scripts, nor any chatty ones.

Log shows XEngine starting in region B, and loading the scripts there. Also shows objects containing scripts being saved. B's scripts happen to be loaded before T's (presumably, XML file order). No entry in log indicates any kind of failure from or of XEngine.

Continuing to monitor - we'd love this one to be sorted out.
(0009232)
jfhopkin (reporter)
2009-02-08 05:15

 Now running r.8242, removed one scripted object from region B, a swing using llTargetOmega(). Scripts in that region now worked. Rezzed object again, scripts still worked. Restarted, still OK. On checking, scripts in region T found not to be working - unsure if T was working before during this testing. Upgraded to r.8270, will test all regions from now on: B, T, C, H and R.

B OK
T OK
C OK
H OK
R Not OK

Noted that while scripts don't run in R, they do compile, including checking, reporting any errors and otherwise reporting successful compilation. Also noted that a script in R that handles touch_start() events causes mouse cursor to change to a hand when floated over. Only object in R is a simple touch-to-say-something scripted box, placed there just now to test if scripting works. Regions C and H contain roughly equivalent numbers and types of objects and scripts to B and T.

Will continue monitoring and report any more findings.
(0009252)
jfhopkin (reporter)
2009-02-08 17:24

 Still on 8270, rezzed "beacon" prims with LSL scripts on all five regions - scripts use llSetText() on a 1-second timer event to flash (glow) on and off and display result of llGetTimeStamp() (date & time), with another message in state_entry(). This is designed to show the time when script running stopped in each region and, in the event of a script never having started properly, whether the state_entry() event was processed. The server was restarted, and the five beacons examined in-world soon after restart was complete:

B Never run
T OK - running
C OK - running
H OK - running
R Never run

The server was again restarted, with no changes made:

B OK - running
T OK - running
C OK - running
H OK - running
R Never run

Appears to be intermittent, at least for region B; no significant difference between the way the two tests were conducted.

At this point it was noted that even though the beacon in T continued to run, flashing and updating the time on the timer() event, if a new prim was rezzed and "New script" added to the contents, this failed to be compiled or start. Other scripts already in progress on T continued to run. This isn't as simple as a "all on or all off" situation!

Server restarted a third time, and:

B OK - running
T OK - running
C OK - running
H OK - running
R Never run

Testing continues.
(0009383)
jfhopkin (reporter)
2009-02-12 08:19

 Not had time to do formal testing, but noticed a pattern that may help. Working on something else region B last night, no objects created or rezzed from inventory had scrips that would run or compile, but objects already in-world on startup were working fine. A workround was to rez the objects I'd be needing, then restart the region server and carry on working.

Hope this helps diagnose the problem.
(0010127)
jfhopkin (reporter)
2009-03-25 06:45

 To bring this up-to-date, all but one of the regions has been working fine for the last few upgrades over several weeks. Three more regions have been added, all of which are also working well in this respect.

Scripts in the "R" region, however, still do not run. In the simplest case, rezzing a cube, and clicking "New Script", will compile the script but not run it; the llSay() command in the state_entry() event is not executed. The "beacon" script in that region (see previous notes) has not run since the 8th February, according to its floating text.
(0012291)
jfhopkin (reporter)
2009-06-29 14:01

 This is no longer an issue for me. As far as I'm concerned, it's resolved - thanks to everyone.

- Issue History
Date Modified Username Field Change
2008-12-16 16:12 WWWench New Issue
2008-12-16 16:12 WWWench SVN Revision => 7734
2008-12-16 16:12 WWWench Run Mode => Grid (Multiple Regions per Sim)
2008-12-16 16:12 WWWench Physics Engine => ODE
2008-12-16 16:12 WWWench Environment => .NET / Windows32
2008-12-16 16:12 WWWench Mono Version => None
2008-12-17 14:33 Teravus Note Added: 0008027
2008-12-17 17:09 WWWench Note Added: 0008036
2008-12-17 17:14 WWWench Note Edited: 0008036
2008-12-18 12:33 justincc Issue Monitored: justincc
2008-12-18 13:04 Teravus Relationship added child of 0002869
2008-12-18 21:50 WWWench Note Added: 0008092
2008-12-18 21:54 WWWench Note Edited: 0008092
2008-12-30 19:20 WWWench Note Added: 0008574
2008-12-30 19:21 WWWench Status new => resolved
2008-12-30 19:21 WWWench Resolution open => fixed
2008-12-30 19:21 WWWench Assigned To => WWWench
2008-12-30 19:21 WWWench Note Added: 0008575
2008-12-31 01:10 Chri5 Somme Status resolved => feedback
2008-12-31 01:10 Chri5 Somme Resolution fixed => reopened
2008-12-31 01:10 Chri5 Somme Note Added: 0008578
2008-12-31 01:11 Chri5 Somme Status feedback => confirmed
2008-12-31 03:35 WWWench Note Added: 0008580
2009-01-04 06:16 WWWench Note Added: 0008609
2009-01-04 06:17 WWWench Note Edited: 0008609
2009-02-04 04:35 jfhopkin Note Added: 0009151
2009-02-04 22:45 WWWench Note Deleted: 0008036
2009-02-04 22:45 WWWench Note Deleted: 0008574
2009-02-04 22:46 WWWench Note Deleted: 0008575
2009-02-04 22:46 WWWench Note Deleted: 0008580
2009-02-04 22:46 WWWench Note Deleted: 0008609
2009-02-04 22:46 WWWench Note Deleted: 0008092
2009-02-07 13:22 jfhopkin Note Added: 0009226
2009-02-08 05:15 jfhopkin Note Added: 0009232
2009-02-08 05:15 jfhopkin Issue Monitored: jfhopkin
2009-02-08 17:24 jfhopkin Note Added: 0009252
2009-02-12 08:19 jfhopkin Note Added: 0009383
2009-03-25 06:46 jfhopkin Note Added: 0010127
2009-06-29 14:01 jfhopkin Note Added: 0012291
2009-06-29 23:11 WWWench Status confirmed => resolved
2009-06-29 23:11 WWWench Resolution reopened => fixed
2009-08-10 07:52 chi11ken Status resolved => closed

Mantis 1.1.1[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker