Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0004163opensim[REGION] Physics Enginespublic2009-09-19 16:102019-02-05 12:25
ReporterPer Pegler 
Assigned Toadministrator 
StatusclosedResolutionwon't fix 
PlatformOperating SystemOperating System Version
Product Version 
Target VersionFixed in Version 
Summary0004163: Oar's not working properly in Megaregions
DescriptionOar loads ok in Root region SW
Loading an oar file in the other regions causes aprox 30% of prims to be phantom.
The prims that are phantom has not got the right coords.
(still maintaining the position they had in the original oar 256x256)
The prims have loaded but cant be edited since they do not exist?
Additional InformationSW region loads fine file size about 100mb and about 6000 prims
Mw much smaller file with about 200 prims loads with the above problem
SE similar size file as NW 120 mb and close to 7000 prims
SE all looks right only that 30 % or so is phantom and can't be edited

Ne terrain only so np
TagsNo tags attached.
Git Revision or version number“Diva Distribution” Metaverse Ink r-10708
Run Mode Standalone (Multiple Regions)
Physics EngineODE
Script Engine
Environment.NET / Windows64
Mono VersionNone
Attached Files

- Relationships

-  Notes
Per Pegler (reporter)
2009-09-22 12:36

When loading the same SE oar file in a non megaregion set up on the same server
the oar loads fine.
Peter13 (reporter)
2009-09-22 16:31

Yes i have notice this as well.

The se region is the first region where the coordinates are the same as on a normal region, for that i think they come to the right place. When you fly over the land you see that the x and y coordinates just go up by each region by 256 on x and y. maybe a solution might be to ad the region position on the know position to se with a facter 256+ meter for each other region. on x and/or y. When a region in selected in the console it might be the basic for that addition in the region map settings.

Was just a thought.

Kind regards
Per Pegler (reporter)
2009-09-23 12:58

Thanks Peter13 I will do some more testing in a few days from now. I have a feeling it could be a memory problem. The X and Y position is correct for about 50% of the loaded prims so it is working to a point, then fails and gives the original position in a 256x256 region?
TiaJaden (reporter)
2009-09-24 02:22
edited on: 2009-09-24 02:23

Also related to this (I think) prims moved from the SW corner to other regions snap back to max 512 in X and Y. You cannot load an oar in SW and then add 1024 to each to move them 5x5 regions across (within the same mega region).

See: [^]

Bob Wellman (reporter)
2009-09-29 12:17

Ok I have been testing load-oar into a megaregion and investigating the database prims table after the load. I think what I have found may help here.

I used a small oar file containing just 6 prims. That was 4 prims that were singles (i.e not part of a linkset) and 2 that were linked together as a 2 prim object.

The 8 sim megaregion was set up of sims like this.


When I loaded it into sim A all was fine. All 6 prims appeared where they should and all were non phantom as expected.

However when I loaded it into sim B I saw 6 prims but all the sinlge prims were phantom but the linked pair were not phantom.

So I looked at the prims file and this is what I saw the 2 linked prims had their region UUID set to sim A with GroupPositionX cordinates larger than 256, whereas the 4 unlinked prims had their region UUID set to SIM B with GroupPositonX cordinates smaller than 256.

So they all appeared where I expected them but it seems that only prims that are based on coordinates rooted in sim A (the root region) are considered by the physics engine to be there to collide with. Makes sense as all mearegions run exverything as root region it seems.

It seems like load oar should either base all prims on the root region or all prims on the region they are appearing in. It must be recalculating the coordinates and rebasing them but only if they are link sets. IT seems this is the cause of the phamtom problem and the problem of prims not remebering any editing as well.

I used SQL to rebase all prims on SIM A and they then stopped being phantom and remebered any edit actions too.

I will post more info on my tests for loading into other sims later.
Per Pegler (reporter)
2009-09-29 13:01

Thank you Bob
Yes this is what I have found also but I haven't had time to do more work on it. I will do some more testing myself also and let you all know how I go.
Have a good one!
Revolution (reporter)
2009-10-04 18:54

Just as a note, if you change an existing region to a mega-region with its neighbors, the objects will go phantom just like this bug. Same bug with loading prims in mega regions, but different way to create the bug.
Diva (administrator)
2009-10-05 07:45

Folks, I added a new command in the recent revisions that *may* fix this problem. Please test and report the result.

# fix-phantoms
Revolution (reporter)
2009-10-05 16:45
edited on: 2009-10-05 16:49

This fixes objects in a 512 by 512 mega-region, but on a larger one, like a 768 by 768, it will only fix the 4 most south-west sims, in the area of a 512 by 512 mega-region. It does fix the objects correctly in the sims though.

Per Pegler (reporter)
2009-10-06 13:52

Diva thank you for the update, even with the "fix-phantoms" I still have problems with prims that are not in a linked set. As Bob pointed out a linked set gets the new x and y position OK. A single prim retains the x and y position from the original 256x256 region the oar file came from, at least that it is what is happening in my case, cant be to more help right now but will do more tests :-)
Bob Wellman (reporter)
2009-10-07 08:20
edited on: 2009-10-07 10:52

OK here are some more test results on load_oar with megaregions. Please read my earlier post above as this follows on from the same scenario:

This time I loaded the same 6 prim OAR file as before but this time into region C. The result was that the load-oar command failed (it hung and eventually reported a stack overflow).

In world I could see the 4 single prims (phantom of course as before) but no linked pair of prims, in region C. Looking at the database I see the 4 single prims on the prims file showing as RegionUUID B and offset < 256 so no wonder they are phantom again. However there was no sign of the 2 linked prims on the prims table at all. So I can only assume the attempt to rebase the linked prims on region A and calculate the now greater than 512 offsets had failed.

Retried this test but this time loading into region D with exactly the same results except the single prims were of course now in region D visually and according to the database.

My theory at this stage was that the recaluations had blown up trying to calculate offsets greater than 512 so I did another test to see if that held true.

I now loaded the same 6 prim oar into region G. If my theory was true this should have the same issues as the region C, but it didnt. The load-oar completed OK and all 6 prims were visible in region G. The four single prims were phantom as before, but this time the linked ones were also phantom. Looking at the databse I saw the 4 single prims were based on a RegionUUID of G which is consistent with my earlier tests. However the 2 prim linked set was based on region B (big suprise) and offset far enough for them to appear in region G. So whilst they appeared correctly in world they were also phantom as they were not based in region A that has the physics engines focus in the megaregion.

So now my theory is that linked prims that need recalulation are using the region thats one less in each direction as a base rather than the root region A and if that is not a valid region it blows the load_oar command up too.

I am hoping that some kind dev will check this theory out and tell me if I am right or wrong.

Per Pegler (reporter)
2009-10-09 02:38

Megaregions the situation after updating to Diva-r11056

2x2 512 x 512

Sw- root region
Nw region 2
Se region 3
Ne region 4

Loading an Oar in to root region works fine (Tested with 6000 + prims) no problem

Loading an Oar to region 2 also works for all linked prims
all single prims become phantom and all gives an error when starting the simulator
Prim crossing failed for ...... name of prim
all linked prims are fine and the overall impression is that everything is just right(looks right:-))

region 3 and 4 same as region 2

New observations

When loading an Oar in to root region it cleaned all prims from region 2, 3, and 4
region 2 had an oar loaded with about 250 prims
region 3 had a linked set loaded from Meerkat about 50 prims
and region 4 had a linked set about 80 prims loaded from Meerkat.

When replaced after the root region had been loaded they persist using the same method as above

I must admitt I have only tested this once so it might not happen all the time more to follow when I have more time :-)
Diva (administrator)
2009-10-11 13:52

I committed code in ref6aa444bfa8 that addresses this problem. It still not completely solved, but now it's salvageable. Here is what works for me:

1) Before loading oar, with the empty region, set CombineContiguousRegions=false

2) Startup your sim and load all the oars you want into the regions you want

3) Shutdown the sim

4) Set CombineContiguousRegions=true and startup the sim again

5) Type the console command
   and wait about a minute until you see all prims being stored in the DB

At this point, the prims should be in the right positions, and with the right properties.

Please try it and let me know how it works.
Per Pegler (reporter)
2009-10-12 02:46

Diva I followed your instructions, well almost I had to login and see how it all looked after all prims had loaded, before giving the command fix-phantom.
And yes the it was no change the prims still phantom even tho I had no errors at all loading it all up and during the start up with CombineContiguousRegions=true.
After fix-phantom 100% good all prims solid and have the right x and y position in the megaregion
Wonderful could not be better. I think a good test because I loaded over 14000 prims in to the 4 regions. Thank you very much will keep you all posted of new adventures...... :-)
Per Pegler (reporter)
2009-10-13 04:18


After yesterdays fix-phantom I wanted to do some more work.

I wanted to see how a save oar worked in the megaregion. I Saved NW region but it was clear it only saved the terrain and textures, I went on to save NE and SE terrains. Then went back to SW root and saved oar Sw and yes it saved all prims in the megaregion.

Created a new DB and loaded oar Sw and all prims ended up in the right place in the entire megaregion.
Then went on to load oar NW,NE,SE and it worked just fine all terrain back to normal and the buildings stayed.

One odd thing on start up I get a lot of errors, prim crossing fail I suspect that is the old phantom prims I had before the fix-phantom command, the dB still the same size so maybe a null thing?

So it works well. However improvements can always be made, it would be nice to be able to save each region or even a parcel as an Oar. I know I am not the first to think that way so for now What we have is just fantastic thank you all so much .... have a good one
Diva (administrator)
2009-10-14 08:05

Yesterday teravus added something that further fixes these problems. Now oars also work for megaregions greater than 2x2.

I was able to load oars even with CombineContiguousRegions=true, and then issue a fix-phantoms
Zonja (reporter)
2009-11-07 10:04

I'm also getting a long list of "prim crossing failed" messages after migrating to Diva r11324 and applying your procedure on each subsequent Opensim startup, but all prims seem to be non-phantom.
Per Pegler (reporter)
2009-11-07 12:12
edited on: 2009-11-07 12:15

Zonja I get the same long list of "prim crossing failed" running Diva 11399.
Every time the Simulator starts up with all the red text "prim crossing failed"
the start up goes well, the regions are OK, prims in the right position and not phantom. However when the start up for some reason excludes all the "prim crossing failed", what I would call a normal start up, the prims that once ware phantom (so I suspect) are now missing all together. It is not a big deal and I simply restart and things go back to normal and strangely I am starting to like red text :-)

Diva (administrator)
2009-11-07 15:26

I get those messages too. Not entirely sure what prims those are. I looked at my DB, the prims table, and there were a few prims with very suspicious coordinates. Just to test, I deleted them from the DB, and this made the red "prim crossing failed" messages go away. Not entirely sure if they all went away, though. (Note: don't do this in your main DB, you may mess it up)

Something's still fishy. But I've been finding it workable for the most part.
Zonja (reporter)
2009-11-15 09:52

FWIW, today I wanted to play with megaregions, so that I first took a MySQL backup. I played a little, then restored the backup, and started Opensim. Then, in place of the red messages, I got a bunch of info and debug messages like the following:

--------------cut here-------------------
2009-11-15 18:12:31,218 INFO - OpenSim.Framework.Communications.Clients.RegionClient [REST COMMS]: Posted ChildAgentUpdate request to remote sim [^]
2009-11-15 18:12:31,218 DEBUG - OpenSim.Region.CoreModules.ServiceConnectorsOut.Interregion.RESTInterregionComms [CONNECTION DEBUGGING]: ObjectHandler Called
2009-11-15 18:12:31,234 DEBUG - OpenSim.Region.CoreModules.ServiceConnectorsOut.Interregion.RESTInterregionComms ---------------------------
2009-11-15 18:12:31,234 DEBUG - OpenSim.Region.CoreModules.ServiceConnectorsOut.Interregion.RESTInterregionComms >> uri=/object/86f454aa-7f6b-4730-b9ac-f3deb4378fa8/8562996559113472/
2009-11-15 18:12:31,234 DEBUG - OpenSim.Region.CoreModules.ServiceConnectorsOut.Interregion.RESTInterregionComms >> content-type=application/json
2009-11-15 18:12:31,234 DEBUG - OpenSim.Region.CoreModules.ServiceConnectorsOut.Interregion.RESTInterregionComms >> http-method=POST
2009-11-15 18:12:31,234 DEBUG - OpenSim.Region.CoreModules.ServiceConnectorsOut.Interregion.RESTInterregionComms ---------------------------
--------------cut here-------------------

I normally *don't* get these on startup.

Then I logged in, and half of the objects were not there. Of course I was plain scared :-) Logged off, cleared the cache, logged back in. Still nothing.

Then I shut down Opensim and restarted it. *This time* I got the usual red messages instead of the above. Logged back in, and all the objects were there (phew! :-)).

Dunno if this can help or not, but I thought I'd better report it here.
TechnoShaman (reporter)
2010-02-08 01:29

some additional info:
a similar problem seems also to appear not only on megaregions.
A load OAR of a grid region on my standalone with more than 6000 prims leads to some invsiblible prims on the standalone.
From the size of this invisible prims, i can tell, that it must be some misplaced original prims, although all the original prims seem to be at the right place; nothing is missing. Some kind of invisible misplaced ghost copies.

save and load oar both on Version
Grid region running on Win Webserver 2008, 64 bit
Standalone running on WinXP
Dolma Dollinger (reporter)
2010-03-29 23:30

I get both the "prim crossing" and Zonja's message without an oar being involved. I often need several sim restarts to get rid of the "Objecthandler called" and get the nornal "Prim Crossing" red lines (and get all my prims rezzed). The coordinates arent suspicious at all. Hope this helps

4 regions megaregion, 0.6.8 (Post Fixes) /Ubuntu 9.10 64 bit/ mysql (one server)
tampa (reporter)
2019-02-05 05:45

Megaregions have been removed.
BillBlight (developer)
2019-02-05 12:25

Old Issues, closed, can be reopened if they still exist

- Issue History
Date Modified Username Field Change
2009-09-19 16:10 Per Pegler New Issue
2009-09-19 16:10 Per Pegler Git Revision => “Diva Distribution” Metaverse Ink r-10708
2009-09-19 16:10 Per Pegler SVN Revision => 0
2009-09-19 16:10 Per Pegler Run Mode => Standalone (Multiple Regions)
2009-09-19 16:10 Per Pegler Physics Engine => ODE
2009-09-19 16:10 Per Pegler Environment => .NET / Windows64
2009-09-19 16:10 Per Pegler Mono Version => None
2009-09-22 12:36 Per Pegler Note Added: 0013601
2009-09-22 12:36 Per Pegler Description Updated
2009-09-22 16:31 Peter13 Note Added: 0013605
2009-09-23 12:58 Per Pegler Note Added: 0013612
2009-09-24 02:22 TiaJaden Note Added: 0013615
2009-09-24 02:23 TiaJaden Note Edited: 0013615
2009-09-29 12:17 Bob Wellman Note Added: 0013662
2009-09-29 13:01 Per Pegler Note Added: 0013663
2009-10-04 18:54 Revolution Note Added: 0013743
2009-10-05 07:45 Diva Note Added: 0013750
2009-10-05 16:45 Revolution Note Added: 0013755
2009-10-05 16:49 Revolution Note Edited: 0013755
2009-10-06 13:52 Per Pegler Note Added: 0013772
2009-10-07 08:20 Bob Wellman Note Added: 0013780
2009-10-07 10:51 Bob Wellman Note Edited: 0013780
2009-10-07 10:52 Bob Wellman Note Edited: 0013780
2009-10-09 02:38 Per Pegler Note Added: 0013789
2009-10-11 13:52 Diva Note Added: 0013830
2009-10-12 02:46 Per Pegler Note Added: 0013834
2009-10-13 04:18 Per Pegler Note Added: 0013845
2009-10-14 08:05 Diva Note Added: 0013861
2009-11-07 10:04 Zonja Note Added: 0014117
2009-11-07 12:12 Per Pegler Note Added: 0014120
2009-11-07 12:15 Per Pegler Note Edited: 0014120
2009-11-07 15:26 Diva Note Added: 0014122
2009-11-15 09:52 Zonja Note Added: 0014173
2010-02-08 01:29 TechnoShaman Note Added: 0014955
2010-03-29 23:30 Dolma Dollinger Note Added: 0015228
2011-08-26 00:58 makopoppo Assigned To => justincc
2011-08-26 00:58 makopoppo Status new => assigned
2019-02-05 05:45 tampa Note Added: 0034139
2019-02-05 05:45 tampa Status assigned => resolved
2019-02-05 05:45 tampa Resolution open => won't fix
2019-02-05 12:11 BillBlight Status resolved => assigned
2019-02-05 12:11 BillBlight Assigned To justincc => administrator
2019-02-05 12:25 BillBlight Note Added: 0034241
2019-02-05 12:25 BillBlight Status assigned => closed

Copyright © 2000 - 2012 MantisBT Group
Powered by Mantis Bugtracker