Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0006821opensim[REGION] Scripting Enginepublic2013-10-28 13:142013-11-01 19:35
Assigned To 
PlatformOSWindowsOS Version2008 Server 6
Product Versionmaster (dev code) 
Target VersionFixed in Version 
Summary0006821: Vector - Value switch / Value loss in scripts while using global vector coordinates
Descriptioni notice and error which at first does not look dangerous.
I had some scripts in my regions where i used llSetText.
As i not constanty look at those texts nor do i need to often restart my regions,
i sometimes noticed that the text color had changed.

But when i observed that objects i set via a global vector coordinate
rezzed at wrong postions i started to investigate this further.

It looks like Vectors used in Scripts are 'switched' and lost
after region restarts. This is a very dangerous behaviour
which is present in 0.7.6 DEV (2013-08-09 osgrid distribution)
as well as in 0.8.0 DEV (2013-10-19 osgrid distribution) versions.
Steps To ReproduceRezz a prim and add this script to it:

vector gColor = <128,64,0> / 255;

    touch_start( integer fNum )
    { llSetLinkPrimitiveParamsFast(LINK_THIS, [ PRIM_COLOR, ALL_SIDES, gColor, 1.0 ]);
     llOwnerSay("Color:" +(string)gColor);

If you click on the prim it will turn brown and says
Primitive: Color:<0.501961,0.250980,0.000000>

Now restart your region. You will notice that after you
restarted the region the prim is still brown, BUT
when you toch the prim it will turn green
because the vecotors have changed and the prim says:

Primitive: Color:<0.000000,501961.000000,0.000000>
Additional Information
As i said before this is very 'dangerous' and can
besides on color changes result in loss of objects
depending on its vector position.
TagsNo tags attached.
Git Revision or version number0.7.6 DEV (2013-08-09) / 0.8.0 DEV (2013-10-19) OSGRID distribution
Run ModeStandalone (1 Region) , Standalone (Multiple Regions) , Grid (1 Region per Sim) , Grid (Multiple Regions per Sim)
Physics EngineODE
Script Engine
Environment.NET / Windows32, .NET / Windows64
Mono VersionNone
Viewerall viewers affected
Attached Filestxt file icon xengine.txt [^] (8,472 bytes) 2013-10-31 10:59 [Show Content]

- Relationships

-  Notes
SeanSB (reporter)
2013-10-30 15:57

I believe you will find that your state information is not persisting a restart. You set the vector at compile time and that's it. Anything that causes state to be lost will scrub the vector.

This is why Collars and the like are so painful, state gets lost - a lot.
The fix is to add the effectively-essential on_rez and changed events to detect a region restart and llScriptReset()

I am sure an opensim dev can tell you what you have done wrong though in your [XEngine] section. Use my suggestion as a workaround till then, but also get into the habit of doing it.
WordfromtheWise (reporter)
2013-10-31 11:14

SeanSB: I have no idea what you are talking about. Why should a on_rez or the change_event fix this ? Mayby you can provide a 'enhanced' script version based on my simple script to investigate further.

And, i use the standard settings from the osgrid distribution. I have uploaded my XENGINE section for your and the devs 'enlightenment'. (i have cut the OSSL FUNCTION BLOCK to make the attachment smaller).

If finally a Dev would talk over this Mantis.
Mata Hari (reporter)
2013-10-31 16:07

He's suggesting an addition that is very common for scripts where you want to ensure correct behaviour on region restart. I almost always include this in my scripts as well as the on-rez that he suggests (more useful for attachments) and another one I do is on change of ownership like this:


    changed(integer change)
        if (change & CHANGED_OWNER) llResetScript();
        if (change & CHANGED_REGION_START) llResetScript();

    on_rez(integer nullValue)
zadark (reporter)
2013-10-31 16:45
edited on: 2013-10-31 17:12

I cannot reproduce this issue.

Followed the steps to reproduce the issue. Every restart the prim remained brown.

Config: Standalone, single region.
Platform: PC Win8.1x64, SQLLite (maybe this is the difference)

WordfromtheWise (reporter)
2013-11-01 12:01

Zadark: yes like i wrote, it stays brown until you touch the prim again ... and if it does not which opensim version and which OS are you using .. maby this helps to dig down the bug ..
zadark (reporter)
2013-11-01 13:20
edited on: 2013-11-01 13:29

WordfromtheWise: I followed your instructions including touch the prim again after sim restart. The output from llOwnerSay("Color:" +(string)gColor);

The simulator: updated whenever dev/master updates.
Region (fun) # show version
Version: OpenSim 0.8.0 Dev ce94f99 (interface version 7)

Possible difference is SQLLite.

As above: Operating system Windows 8.1 Professional x64 i7 etc
Opensim.exe invoked from within Visual Studio 2012 Professional

WordfromtheWise (reporter)
2013-11-01 13:43

i use a mysql database .. interesting finding ... mayby i can reproduce this when using sqlite as well .. .. i report back with more infos ..
SeanSB (reporter)
2013-11-01 19:35

The root cause of the bug might be XEngine not working 100% but there is a workaround to get you out of your immediate problem.

You intialise your vector in the variable definition area thus
vector gColor = <128,64,0> / 255;

Just as Japanese hovertext does not survive a reboot of the sim (it turns to ????), then you should do what I do. Initialise in your state_entry() and ensure you have a changed event, as Mata Hari shows above.

Corrected script:
vector gColor;

        gColor = <128,64,0> / 255;    
    touch_start( integer fNum )
    { llSetLinkPrimitiveParamsFast(LINK_THIS, [ PRIM_COLOR, ALL_SIDES, gColor, 1.0 ]);
     llOwnerSay("Color:" +(string)gColor);
    changed(integer change)
        if (change & CHANGED_OWNER) llResetScript();
        if (change & CHANGED_REGION_START) llResetScript();

    on_rez(integer nullValue)

I know, I can hear you say "So what, it's a bug" Reason I say this is one of ettiquette... you marked the ticket as Major impact with Urgent Priority. Meaning; for you this is a pretty huge deal. You have a script that fails to work after a reboot and can't work out a work-around.

Use my suggestion and the issue can drop in severity, just as Japanese hovertext not surviving a reboot is effectively only low priority. Means the devs can focus on far more important things.

- Issue History
Date Modified Username Field Change
2013-10-28 13:14 WordfromtheWise New Issue
2013-10-30 15:57 SeanSB Note Added: 0024589
2013-10-31 10:59 WordfromtheWise File Added: xengine.txt
2013-10-31 11:10 WordfromtheWise Note Added: 0024596
2013-10-31 11:13 WordfromtheWise Note Edited: 0024596 View Revisions
2013-10-31 11:14 WordfromtheWise Note Deleted: 0024596
2013-10-31 11:14 WordfromtheWise Note Added: 0024597
2013-10-31 16:07 Mata Hari Note Added: 0024598
2013-10-31 16:45 zadark Note Added: 0024599
2013-10-31 17:12 zadark Note Edited: 0024599 View Revisions
2013-11-01 12:01 WordfromtheWise Note Added: 0024600
2013-11-01 12:03 WordfromtheWise Note Added: 0024601
2013-11-01 12:06 WordfromtheWise Note Deleted: 0024601
2013-11-01 13:20 zadark Note Added: 0024603
2013-11-01 13:29 zadark Note Edited: 0024603 View Revisions
2013-11-01 13:29 zadark Note Edited: 0024603 View Revisions
2013-11-01 13:43 WordfromtheWise Note Added: 0024604
2013-11-01 19:35 SeanSB Note Added: 0024605

Copyright © 2000 - 2012 MantisBT Group
Powered by Mantis Bugtracker