Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0003017opensim[REGION] Physics Enginespublic2009-01-19 14:212013-10-16 09:46
ReporterOwenOyen 
Assigned To 
PrioritynormalSeveritymajorReproducibilityalways
StatusconfirmedResolutionopen 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0003017: Scripts stop functioning on sim border crossing, a sitting avatar is pushed off of seat as well
DescriptionThis Has Nothing To Do With Vehicles.

No LSL vehicle declaration is involved. No LSL vehicle functions are used.

The sailboat will not cross sim borders. More simply, a cube with an llSetForce executing within it to push the cube across a sim border will cross the sim border but lose all propulsive force once in the other sim. The script does make the trip across, but it stops executing.

Here is simple code to test it:

default
{
    state_entry()
    {
        vector pos = llGetPos();
        llSetPos(<pos.x, pos.y, 25>);
    }
    
    touch_start(integer param)
    {
        llSetStatus(STATUS_PHYSICS, TRUE);
        llSetForce(llGetMass() * <0.5,0,9.8>,TRUE);
     }
    
}

Place this in a cube rezzed near an east border and click the cube, it will drift across the border, and fall to the ground as gravity is no longer compensated and no forward force remains. If you then cross the border and reclick, the cube resumes motion.

This happens even with the correct setting in the sim .ini software set to permit object entry.

Worse, for sailing, if you sit on that cube before clicking, when you reach the border you will be pushed off the cube, often to a considerable distance away and the cube's function dies.

Additional InformationDetails about region software largely unknown, but Hiro Protagonist witnessed the tests and instructed sim .ini settings and requirements, which were met.
TagsNo tags attached.
Git Revision or version number
Run Mode Grid (Multiple Regions per Sim)
Physics EngineODE
Script Engine
Environment.NET / Windows64
Mono Version2.0.1
Viewer
Attached Files

- Relationships

-  Notes
(0008931)
OwenOyen (reporter)
2009-01-21 17:02
edited on: 2009-01-21 17:03

Refined observations make it clear that scripts DO function in the object that traverses the sim border. What does not function . . . or what is not retained in the object . . . are parameters associated with it (some sort of attributes) like force and rotational velocity and even altitude of a physical prim.

The new code that demonstrates this is:

integer gi;
default
{
    state_entry()
    {
       llSetStatus(STATUS_PHYSICS, FALSE);
         vector pos = llGetPos();
        llSetPos(<pos.x, pos.y, 25>);
        llSetTimerEvent(0.2);
        llSetBuoyancy(1.0);
    }
    
    timer()
    {
        llSetForce(llGetMass() * <0.1,0,0>,FALSE);
        llSetStatus(STATUS_PHYSICS, TRUE);
        llSetBuoyancy(1.0);
        
        gi++;
        if (gi > 100)llDie();
        
     }
    
}

Again, rez near an east border in a water sim and observe the object's behavior at border crossing.

(0008941)
Twitch (manager)
2009-01-22 03:56

I can confirm this behaviour from direct observation of Owen's scripted prim tests on Fredo Chaplain's regions.

The object I observed would approach the region border, cross the border, the3 fall to the seafloor about 1m beyond the border.
(0008946)
FredoChaplin (reporter)
2009-01-22 08:20

Same for me. This is easily reproductible. Object and script passing, but not dynamic context of the prim.
(0008974)
FredM (reporter)
2009-01-23 05:03

Can confirm that. I have this since svn7901 (maybe it was there before, or never...can not say).

Best example Radar Hud script. Teleporting or flying over regions disable the script. Does not return to normal anymore. Have to relog.

OpenSim.ini has scripts over regions enabled.
(0009179)
OwenOyen (reporter)
2009-02-05 10:15
edited on: 2009-02-05 10:17

I am re-commenting on this for attention. Sailing in general and SLsailing enthusiasts' desire to migrate to OSG is largely obstructed right now by the inability of sailboats (which are NOT vehicles in the OSG implementation) to traverse sim borders.

Again, the object's (class or array of parameters) attributes are not all traversing the border. The object traverses the border but its velocity, force opposing gravity, rotation rate etc are not traversing. The new object appears in the new sim without these values and sinks to the sea floor. If the script is timer based, the next execution of instructions will resume motion, but from velocity zero and altitude 0.

This should be an easy fix for someone.

(0009180)
mohax (reporter)
2009-02-05 10:19

I inadvertently confirmed this as well on ReactionGrid when bouncy balls, fully scripted (essentially just AOs with attachment) stop working as soon as sim border hit. Users have to detach and reattach (by the way, the detach from the pie menu does not work, only works from inventory, will submit another bug on that).
(0009181)
cfk (administrator)
2009-02-05 10:24

I think the next step is to get the consoles on both sides of this crossing when it is happening and add to the Mantis. I suspect we will see some null references based on some work daTwitch did a week or so ago.

Those exceptions and messages may help to converge on a solution.

By the way, Diva tells me that the region module she build moves prims just fine across a region boundary, so I believe we can get there from here, but there are a few nuances we dont understand yet.
(0009193)
coyled (reporter)
2009-02-05 21:52

Owen and I did a couple more tests just now... here's some info:

Test 1:

Prim started in region Castle Rock (OSGrid). Win2K3 server, OpenSim r8236, .Net version...??. Prim started just inside the eastern border, and traveled east. When the prim hit the region's eastern border, it disappeared and reappeared on the western border, still traveling east. Some people have been referring to this as the "pacman" effect.

When it hit the eastern border, I saw the following on the region server console:

20:56:28 - [Scene]: Failed with exception System.IO.IOException: The process can
not access the file 'E:\opensim_r8236\opensim_r8236\bin\ScriptEngines\5f683d51-5
b82-4ed1-be22-d448d0103f4a\CommonCompiler_compiled_f0a75339-45fa-4d1c-ae98-904b2
321efa9.dll' because it is being used by another process.

-----

Test 2:

Prim started in region Brigantine (OSGrid). Ubuntu 9.04, OpenSim r8236, Mono 2.0.1. Prim started just inside the eastern border, and traveled east. When the prim hit the region's eastern border, it lost its velocity and height, dropping to the sea floor.

When it hit the eastern border, I saw the following on the region server console:

00:18:43 - [INTERREGION]: A new prim ae044424-807d-483e-98f3-0f5977b3149f arrived from a neighbor
00:18:43 - [INTERREGION]: Prim state data arrived from a neighbor
00:18:43 - [XEngine]: Loaded script Border Tester.New Script
(0009194)
coyled (reporter)
2009-02-05 22:02

More info from OpenSim.log from Test 1 above:

2009-02-05 20:56:28,151 ERROR - OpenSim.Region.Environment.Scenes.Scene [Scene]: Failed with exception System.IO.IOException: The process cannot access the file 'E:\opensim_r8236\opensim_r8236\bin\ScriptEngines\5f683d51-5b82-4ed1-be22-d448d0103f4a\CommonCompiler_compiled_f0a75339-45fa-4d1c-ae98-904b2321efa9.dll' because it is being used by another process.
   at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
   at System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, Int32 rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions options, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy)
   at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share)
   at OpenSim.Region.Environment.Scenes.SceneObjectGroup.GetStateSnapshot()
   at OpenSim.Region.Environment.Scenes.Scene.CrossPrimGroupIntoNewRegion(UInt64 newRegionHandle, SceneObjectGroup grp, Boolean silent)
   at OpenSim.Region.Environment.Scenes.Scene.CrossPrimGroupIntoNewRegion(Vector3 attemptedPosition, SceneObjectGroup grp, Boolean silent)
   at OpenSim.Region.Environment.Scenes.SceneObjectGroup.set_AbsolutePosition(Vector3 value)
   at OpenSim.Region.Environment.Scenes.SceneObjectPart.PhysicsRequestingTerseUpdate()
   at OpenSim.Region.Physics.Manager.PhysicsActor.RequestPhysicsterseUpdate()
   at OpenSim.Region.Physics.OdePlugin.OdePrim.UpdatePositionAndVelocity()
   at OpenSim.Region.Physics.OdePlugin.OdeScene.Simulate(Single timeStep)
   at OpenSim.Region.Environment.Scenes.SceneGraph.UpdatePhysics(Double elapsed)
   at OpenSim.Region.Environment.Scenes.Scene.Update() On Region: Castle Rock
(0009195)
coyled (reporter)
2009-02-05 22:22

A few more bits...

* For the two tests I mentioned above, both region servers had:

  AllowScriptCrossing = true
  physics = OpenDynamicsEngine
  DefaultScriptEngine = "XEngine"

* I used the same binaries and configs for both the Ubuntu and Win2K3 boxes (binaries compiled on a separate Linux box).

* On Castle Rock (the Win2K3 box) I've seen the "process can not access the file" error before with a different OpenSim version. Here's a log snippet from r8088 on the same Win2K3 box:

2009-02-01 12:22:49,454 ERROR - OpenSim.Region.Environment.Scenes.Scene [Scene]: Failed with exception System.IO.IOException: The process cannot access the file 'D:\opensim_r8088\opensim\bin\ScriptEngines\5f683d51-5b82-4ed1-be22-d448d0103f4a\CommonCompiler_compiled_60312370-184e-4777-88d2-5564502cdd64.dll' because it is being used by another process.
   at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
   at System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, Int32 rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions options, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy)
   at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share)
   at OpenSim.Region.Environment.Scenes.SceneObjectGroup.GetStateSnapshot()
   at OpenSim.Region.Environment.Scenes.Scene.CrossPrimGroupIntoNewRegion(UInt64 newRegionHandle, SceneObjectGroup grp, Boolean silent)
   at OpenSim.Region.Environment.Scenes.Scene.CrossPrimGroupIntoNewRegion(Vector3 attemptedPosition, SceneObjectGroup grp, Boolean silent)
   at OpenSim.Region.Environment.Scenes.SceneObjectGroup.set_AbsolutePosition(Vector3 value)
   at OpenSim.Region.Environment.Scenes.SceneObjectPart.PhysicsRequestingTerseUpdate()
   at OpenSim.Region.Physics.Manager.PhysicsActor.RequestPhysicsterseUpdate()
   at OpenSim.Region.Physics.OdePlugin.OdePrim.UpdatePositionAndVelocity()
   at OpenSim.Region.Physics.OdePlugin.OdeScene.Simulate(Single timeStep)
   at OpenSim.Region.Environment.Scenes.SceneGraph.UpdatePhysics(Double elapsed)
   at OpenSim.Region.Environment.Scenes.Scene.Update() On Region: Castle Rock
(0009196)
OwenOyen (reporter)
2009-02-05 22:33
edited on: 2009-02-05 22:34

Thank you for posting that collected data, Dave.

The object used was scripted as above, positioned at altitude 25 meters (sometimes manually) just above water height and clicked to begin its drift eastward to the border.

(0009367)
Diva (administrator)
2009-02-11 20:32
edited on: 2009-02-11 20:33

Going back to the original issue (not the exceptions, which I think are now gone as of yesterday): a lot of those properties are not being copied over. If you could tell me what properties should be copied -- preferably with the names used in EntityBase/SceneObjectGroup/SceneObjectPart, I can try to make this happen.

(0009369)
OwenOyen (reporter)
2009-02-11 22:48
edited on: 2009-02-11 22:50

Thank you for your attention and work on this matter.

We have some new observations (Bri and I) completed on the latest SVN on Bri's sims.

The test object crosses the border and falls to the seafloor, which is a behavior we are accustomed to seeing. There is a new behavior and symptom, however.

The script within the test object generates a script error message saying it could not compile and that the script text was empty. We have not seen this before tonight. Examining the script in the object (in the crossed into sim) shows the text present. A reset does not reactivate the script. Adding a space to a line and re-saving(compiling) yields restored functionality.

I am not able to quote to you individual object parameters or properties that should accompany the object across borders because I know nothing of the sim software. In general, prior to this most recent test, we presumed the object was losing state information beyond position and rotation (velocity? force/acceleration? rotational velocity/acceleration?). I am probably asking from ignorance, but if there are properties associated with an object, why would one ever want to lose any of them (other than the previous region's East, North, Vertical position coords) when crossing a border?

(0009374)
FredoChaplin (reporter)
2009-02-12 00:54

Diva,

I agree with Owen's position regarding object's properties. We must probably look at a moving object in the same way as an avatar. The moving object crossing the border will be fully transfered as a whole to the new region, with absolutely all the parameters he had in the former region, and will continue its life in the new region as if it was created in this new region.

From my point of view, avatar behaviour should probably be applied to moving object, with the same scheme as the root/child organisation. I could imagine that moving object arriving near to one border should be parallelised(root/child) with the next to come region a few meters before crossing, duplicating all properties changes in both regions, so that the crossing is from that point of view "just" a matter of inverting root/child attribute...

In this way and after all that enormous work done, my already mentionned request (mantis 3126) regarding sitting avatar, and aknowledged by Melanie as non yet coded, should be quite easy to implement.

We really do appreciate your efforts in this area of work. Dynamic objects and vehicles are so important to metaworlds.
(0009381)
Diva (administrator)
2009-02-12 07:57

It will be hard to help you if you don't give more useful and effective information. Opinions and wish-lists are worth about zero for the purpose of fixing this. I don't know much about LSL and the expectations that people have about moving objects, but I'm willing help if you give me the information I need to help you. First of all, all details matter. How are you doing your experiments?

a) Are the 2 regions on the same sim or different sims?
b) Are the sims Windows or Linux?
c) Are the sims on the exact same OpenSim version?
d) Do you have TrustBinaries = true?

Second, please edit EntityBase/SceneObjectGroup/SceneObjectPart and take a look at the properties defined there. Which ones do you guess are important for the scripts you use? If you don't want to look at C#, just say a list of properties on the top of your head that you think should be preserved, and I'll try to match that to the code.

At the moment, the only object information that is being passed is that that is preserved with 'save xml2'. If you need more, tell me what you need.
(0009384)
coyled (reporter)
2009-02-12 08:20
edited on: 2009-02-12 08:24

The "test 1" I mentioned above was crossing from 1 region on a sim running on Windows to another region on another sim running Linux. Both were running r8236. For "test 2" I mentioned, that was crossing between two regions on the same sim on Linux, running r8236. TrustBinaries=false because of the big scary warning in OpenSim.ini.example . There isn't an explanation there or in the wiki about what enabling this actually does... what does it do? I'll set it to true if it should be.

I'll recreate the tests this evening on trunk and posts the results, since as you said, Diva, the exceptions should be gone.

I'll also take a look at EntityBase/SceneObjectGroup/SceneObjectPart and try to figure out what exactly needs to be passed.

Thanks.

(0009388)
FredoChaplin (reporter)
2009-02-12 09:18

Sorry to give my opinion once more. I do understand you have plenty of things to fix and no time for chatting, and please be sure how grateful we are about all the work you all do for the community.

But we are not only talking in this issue of fixing small things. I did browse EntityBase/SceneObjectGroup/SceneObjectPart, trust me, and i gave you the answer you asked for: every property has to be passed !

The key point here is we are talking about fundations for the handling of dynamics objects. They cannot be handled as static objects, because they must be associated with a corpus of properties which must move with the object from region to region, as complete as if the object has been created natively in the destination region. And it must not be advertised too late, otherwise copying of properties and restarting of scripts will pause too much. So it must be designed in the InterRegion dialog.

Fixing one property now and the other tomorrow wont help this much.

I understand opinions are sometimes waste of time, but the wasted time might maybe be gained later....
(0009389)
melanie (administrator)
2009-02-12 09:26

The root/child paradigm cannot be applied to objects. The viewer won't have any of that. So, serialization, passing via message and re-instantiation is the correct way to go. However, there should really be a breakaway from the xml2 format, either that format needs to be made extensible aor another created that reflects all properties of the prim, not just specific chosen ones.
However, certain properties need to be acten on to work, e.g. force has to be communicated to the physics engine, etc. Sitting avatars need to be re-sat on the new LocalID (the LocalID MUST change, or the viewer will have issues!)
So, not trivial and not solvable short-term
(0009390)
Diva (administrator)
2009-02-12 09:37

All this can now be done with ExtraTo/ExtraFrom.
It's just a matter of figuring out what needs to be preserved and what needs to change.

All of this should be tested and verified *first* on crossings within the same instance, because those are not being serialized, but simply Copy-ed. If the Copy method is not doing all it should, we should fix it.
(0009399)
WWWench (reporter)
2009-02-12 19:18

a) Are the 2 regions on the same sim or different sims?
(Same, in Owen and my tests.We think crossing to different sim would confuse the data.)
b) Are the sims Windows or Linux?
(Both, we test on a Debian and a Centos Mono 2.0.1 and a Win2008 Net 3.5 sp1, all hosted 4gb)
c) Are the sims on the exact same OpenSim version?
(yes, typically we are on trunk head, unless we revert to verify)
d) Do you have TrustBinaries = true?
(Yes)

Bri
(0009401)
WWWench (reporter)
2009-02-12 21:10
edited on: 2009-02-13 03:28

r8374 has excellent crosses with a walking Avatar with attachments.

Scripted prim crosses are viewer fatal, off world, and difficult instance recovery. I could see the prim briefly with a compile error message about 2m inside targeted region. After a recovery dropping the prim and compile in either region was successful. However crossing with it was repeatably fatal.

Debian/lenny Mono 2.0.1 4gb dedicated, 4 regions started. r8374 Trustbin true.
( I was able to get the Linux error message after a few trys)
boatprim: Error compiling script:
Cannot find script assembly and no script text present

(0009404)
WWWench (reporter)
2009-02-13 03:26
edited on: 2009-02-13 03:28

r8374 on Win2008 Net 3.5 sp1 is different than my above Linux note.
(Av walking crosses are excellent as is the mono instance.)

Sitting on the boat scripted prim at cross threw my Av to another region not involved with the cross. However a script compiled message did appear. The viewer was not responsive.
After a relog to the origin cross region, I could see the prim in the area I’d expect in the target region side.
I could sit on the prim, initiate and sail on as normal in the target region.

(0009420)
coyled (reporter)
2009-02-13 22:43
edited on: 2009-02-13 22:47

I sent a physical object across a region border (both regions in same sim, r8373, Win2008) and did "save xml2" in the origin and destination regions. After crossing the border the object loses its:

- Velocity
- RotationalVelocity
- AngularVelocity

(I'm not entirely clear on the difference between RotationalVelocity and AngularVelocity... as I understand it they describe the same thing. But they're listed as separate attributes in the xml2 dump even though they have the same values.)

(0009422)
M1sha (reporter)
2009-02-14 00:50

I created a new sim instance with 2 regions - Win2003 x64, running 32 bit, version 8386. Regions are water at the crossing point. Different effects flying east/west west/east for some reason, both position the AV incorrectly afterwards:
(a) west/east - the AV transitions to a fast walk over the region cross. On completion of the cross the AV is underwater and just above the sea bed
(b) east/west - cross appears normal (i.e. continue flying). Again on completion of the cross the AV is underwater and just above the sea bed.
(0009425)
melanie (administrator)
2009-02-14 03:09

Please understand that sitting on a prim while crossing is not yet possible, nor are long running events possible in OpenSim. Repeatedly testing the boatprim will not help any, we know it's not working yet.
(0009427)
WWWench (reporter)
2009-02-14 04:24

Melanie,
What direction do you suggest we can test or assist?
or
Should we wait to participate or provide feedback?
(0009429)
melanie (administrator)
2009-02-14 04:27

At this time, it's mostly with Diva and myself, and it is actively being worked on. We appreciate any and all new information, but reiterating the known facts doesn't help, neither does filing new Mantii.
This is not a customer support forum, making more reports doesn't put "pressure" on anyone. All it does is to make the Mantis a disorganized mess.
So, please, report only new, not previously reported information, and report it on existing Mantii when possible.
(0009430)
M1sha (reporter)
2009-02-14 07:07
edited on: 2009-02-14 07:08

Melanie - not sure if your latest comment was referencing my comment or not. My report was not related to prim usage at all - just a normal border crossing (but flying rather than walking) and over water (rather than land). That used to work prior to the recent border crossing changes, hence I added a comment here rather than a new Mantis.

(0009433)
Diva (administrator)
2009-02-14 08:31

@M1sha: this mantis is about prim/script crossing. If you're seeing a new behavior on *avie* crossing, report it elsewhere, as detailed as possible so it can be reproduced.
(0009434)
OwenOyen (reporter)
2009-02-14 08:52

From Dave Coyle's post above (thanx Dave), responding to Diva's request for specific properties of the object that should traverse crossing.

>>
I sent a physical object across a region border (both regions in same sim,
r8373, Win2008) and did "save xml2" in the origin and destination regions.
After crossing the border the object loses its:
 
- Velocity
- RotationalVelocity
- AngularVelocity
>>

Useful to note that loss of these properties alone will not explain the object (scripted as at the top of this mantis, not the boat prim) dropping to sea floor.

Perhaps previous region Z position coordinate should be retained after script execution resumes in the new region? The sinking of the object to sea floor is not instantaneous, but it is also not a slow drift. In fact, it looks like 9.8 meters/sec^2, suggesting the object traverses to the new region and the new region's gravity drops the object before the script can resume function with its counter-gravity llSetForce.
(0009481)
WWWench (reporter)
2009-02-15 15:33

r8404 observation

When kicking or carrying a scripted prim across a region line there is a difference.

One (1) test prim will malfunction and display,

testprim: Error compiling script:
Cannot find script assembly and no script text present
------------------------------------------------------------------
Three (3) test prims will function and display,

Compile successful
-----------------------------------------------------------------
Replication..
Drop identical scripted prims in Origin and Target regions (2)
Carry or kick the third prim through the region cross.

Debian/lenny mono 2.0.1, 4gb dedicated, trusted binaries true
Win2008 .Net 3.5 sp1, 4gb dedicated, trusted binaries true
(occasionally, the Win server will message “Compile successful” with One perhaps indicating timing, superior speed of .Net.)
(0009845)
WWWench (reporter)
2009-03-05 07:25

A r8700 inadvertent scripted cross creates a situation where the Av goes off world and the origin or target region go into a Physics (object out of bounds) loop. The sim crashes with a difficult recovery. A process kill and restart won’t stop the runaway due to persistence. The client side has to get a cache clear prior to restart for it’s full recovery.

The only workaround is building walls around each region to achieve sanity equal to a level of months ago, revert is out due to OSGrid db changes forcing current versions.

mono 2/net 3.5 trusted binaries true, hosted quads
(0019049)
makopoppo (manager)
2011-07-23 21:50

Issue still exists on OpenSim 0.7.2-dev.
(0020953)
slow putzo (reporter)
2012-02-23 16:15

I just tested this script in a cube on my region and the cube does not stop after crossing the border.

In fact it crossed over a couple of regions without any problem.

I did not try sitting on the cube, but the cube does not fall after crossing the border.

Version tested in is: OpenSim 0.7.3 Dev OSgrid 0.7.3 (Dev) a27e5a9: 2012-02-21 (Unix/Mono)

Region tested on running this code version was "Sanctuary".
(0020980)
kenvc (reporter)
2012-02-25 08:06

Just tried this same script/prim test using the latest dev master as of today (r18178). I am only reporting this because the behavior I got seemed to be different than I've seen described above. If I find anything different in the logs, I'll attach that shortly.

I used a very large 50x50x1 prim with the latest example script above with my AV standing on it. When it drifted accross the border, the prim totally vanished and my AV dropped to the ocean bottom remaining in the starting sim. My AV did not cross to the next sim. My AV continued moving along the ocean floor as though it was still standing on the prim that has now vanished, but it was now moving in a different direction that was more to the northwest rather than to the east. After it hit the next sim crossing, it appeared to cross the sim border and then stop moving. I scanned for the missing prim on all sims within 3 of this spot and the prim simply no longer exists. These sims had 0 prims on them prior to this test.
(0024464)
dz (reporter)
2013-10-13 09:19

Is there a mantis issue with this??? Last update shows yesterday but the Issue history still shows the last comment as 9 months ago... What gets updated without posting to Issue history???
(0024483)
shy (reporter)
2013-10-16 09:46

I guess it was me, when I clicked the [Monitor] button.

- Issue History
Date Modified Username Field Change
2009-01-19 14:21 OwenOyen New Issue
2009-01-19 14:22 OwenOyen SVN Revision => 0
2009-01-19 14:22 OwenOyen Run Mode => Grid (Multiple Regions per Sim)
2009-01-19 14:22 OwenOyen Physics Engine => ODE
2009-01-19 14:22 OwenOyen Environment => .NET / Windows64
2009-01-19 14:22 OwenOyen Mono Version => 2.0.1
2009-01-21 17:02 OwenOyen Note Added: 0008931
2009-01-21 17:03 OwenOyen Note Edited: 0008931
2009-01-22 03:56 Twitch Note Added: 0008941
2009-01-22 05:41 WWWench Note Added: 0008943
2009-01-22 08:20 FredoChaplin Note Added: 0008946
2009-01-23 05:03 FredM Note Added: 0008974
2009-02-05 10:15 OwenOyen Note Added: 0009179
2009-02-05 10:17 OwenOyen Note Edited: 0009179
2009-02-05 10:19 mohax Note Added: 0009180
2009-02-05 10:24 cfk Note Added: 0009181
2009-02-05 21:52 coyled Note Added: 0009193
2009-02-05 22:02 coyled Note Added: 0009194
2009-02-05 22:22 coyled Note Added: 0009195
2009-02-05 22:33 OwenOyen Note Added: 0009196
2009-02-05 22:34 OwenOyen Note Edited: 0009196
2009-02-06 21:20 WWWench Note Deleted: 0008943
2009-02-11 20:32 Diva Note Added: 0009367
2009-02-11 20:33 Diva Note Edited: 0009367
2009-02-11 22:48 OwenOyen Note Added: 0009369
2009-02-11 22:50 OwenOyen Note Edited: 0009369
2009-02-12 00:54 FredoChaplin Note Added: 0009374
2009-02-12 07:57 Diva Note Added: 0009381
2009-02-12 08:20 coyled Note Added: 0009384
2009-02-12 08:24 coyled Note Edited: 0009384
2009-02-12 09:18 FredoChaplin Note Added: 0009388
2009-02-12 09:26 melanie Note Added: 0009389
2009-02-12 09:37 Diva Note Added: 0009390
2009-02-12 19:18 WWWench Note Added: 0009399
2009-02-12 21:10 WWWench Note Added: 0009401
2009-02-13 03:26 WWWench Note Added: 0009404
2009-02-13 03:28 WWWench Note Edited: 0009401
2009-02-13 03:28 WWWench Note Edited: 0009404
2009-02-13 22:43 coyled Note Added: 0009420
2009-02-13 22:47 coyled Note Edited: 0009420
2009-02-14 00:50 M1sha Note Added: 0009422
2009-02-14 03:09 melanie Note Added: 0009425
2009-02-14 04:24 WWWench Note Added: 0009427
2009-02-14 04:27 melanie Note Added: 0009429
2009-02-14 07:07 M1sha Note Added: 0009430
2009-02-14 07:08 M1sha Note Edited: 0009430
2009-02-14 08:31 Diva Note Added: 0009433
2009-02-14 08:52 OwenOyen Note Added: 0009434
2009-02-15 15:33 WWWench Note Added: 0009481
2009-03-05 07:25 WWWench Note Added: 0009845
2011-07-23 21:50 makopoppo Note Added: 0019049
2011-07-23 21:50 makopoppo Status new => confirmed
2012-02-23 16:15 slow putzo Note Added: 0020953
2012-02-25 08:06 kenvc Note Added: 0020980
2013-10-13 09:19 dz Note Added: 0024464
2013-10-16 09:46 shy Note Added: 0024483


Copyright © 2000 - 2012 MantisBT Group
Powered by Mantis Bugtracker