However, the calls to the land management module to record prims need to remain, since they were also being used to return owner object lists, etc.
This is probably why prim counts were being done there in the first place.
The region spanning parcel shouldn't exist in this situation. If it does, when the land data is loaded it is repersisted with a local ID which comes after the ones loaded via the oar, which obliterates the oar loaded one.
Resaving the data we just loaded from the database is somewhat odd in itself (though this makes sense from the way that OAR loading was already using the same event).
Remove the too coarse CanEditParcel method in favor of a CanEditParcelProperties
method that takes a GroupPowers argument to specify what action is to be
taken. Also, make the method to set parcel data much more granular. Permissions
in a deeded setting should now work.
* It does this by tweaking the throttles on child agent connection to a megaregion and multiplying the land throttle by 50. (various bit and byte magic ensue)
* While, I doubt this will cause terrain crater sized potholes.. since it actually increases the bandwidth available for land in child regions when MegaRegions area active, more testing would be good.
* This, in theory, also shouldn't cause missing objects in child regions.. because all objects are in the root region anyway. As I said, more testing would be good.
Justin Clark-Casey (justincc)