SIM border crossing experiments in OpenSim 0.9.0.0

[Kayaker Magic]

The short version: WOW! SIM border crossings in OpenSim 0.9.0.0 work GREAT! Well, great for my non-physical vehicles. You have to do your own experiments if you can't script your own physics...

I set up some regions in OSGrid using the new 0.9.0.0 version of OpenSim and I have been doing some experiments there. I set two var-regions next to each other and tried sailing some of my non-physical boats across the border.

My first attempt, a windsurfer, crossed the border with hardly a bump! It was smoother than crossings in InWorldz where the devs pride themselves on their SIM crossing code! These two SIMS were running on the same instance of OpenSim on a single server, which might make this easier. If you try to run off the edge where there is no other SIM to cross into, you just bounce harmlessly off the edge until you turn away. (This used to cause all kinds of problems with the viewer and the SIM).

My second attempt, a catamaran, could not cross the border at all, stopped there screaming debug messages at me. Something about an instance of an object not being the object of an instance. What is the difference between the two vehicles?

The windsurfer arrived in the region as part of an OAR, an old copy of my Kitely Panthalassa world. The windsurfer script had failed to compile when it arrived and had to be recompiled. The catamaran arrived in My Suitcase folder from Kitely. It should have had the same problems, but didn't force me to re-compile it. So I did re-compile it, then it worked well and crossed SIM borders with ease.

I hope this doesn't mean that some scripts will have to be re-compiled or modified for 0.9.0.0! Lots of other scripted objects arrived with no errors and worked without re-compiling them. I'm looking at these two vehicles to see if there is a good reason this happened to me.

Ilan will be amused to hear that I am having other problems with my server. My scripts are running unevenly, the boats move fast and slow, fast and slow. Are some of my scripts hogging too much CPU time? But when I cross the SIM border, the lag goes away. I'm running both regions in the same instance of OpenSim, which seems to indicate it is NOT script time that is lagging me. More testing will be needed!

[Kayaker Magic]

The vehicle scripts that I had trouble with were both compiled with the FireStorm pre-processor. But so were most of the rest of my scripts. The difference was that these two referred to an #include file that no longer existed. This should not matter since the output of the pre-processor contains the contents of all #include files at the time I compiled it last in Kitely, when that #include file did exist. It is almost as if when I carry a scripted object in my suitcase and give it to my OSgrid avatar, OpenSim tries to re-compile it using the pre-processor again. On most scripts this succeeds because my OpenSim Avitar has the processor enabled and the #include files are available. I tried one experiment: I repaired the script in Kitely (correct #include file name) and made sure it compiled there. I carried it (the boat with the script in it) in my suitcase to OSgrid. I gave it to my OSgrid avatar, who then sailed it around successfully, bounced off SIM edges without debug errors, and crossed SIM borders nicely. I am going to have to try several more experiments with avatars that don't have the pre-processor enabled to nail this down. It would be bad if I could deliver scripts to people who don't have the pre-processor on, but could not deliver products to people who do have it on! Worst case, I could use the pre-processor for ease of development, then edit its output to use only the results in deliverable products. Switching to a pre-processor that runs on my host PC might be another way of getting around this problem.

I also tried out my Race Course System in OpenSim 0.9.0.0. This was written originally in InWorldz and was designed to work across multiple SIM borders. The race gates communicate with a server using llHTTPRequest since they cannot do llRegionSay across SIM boundaries. (Duh!). I brought copies across (in my suitcase) and they ran correctly in a single region, but failed to connect up across a border. Looking at the code I was reminded that I failed to get llRequestURL() to work correctly for me in Kitely, and #ifdefed that code out, replacing it with llRegionSayTo messages. This worked in Kitely because border crossings were not possible, but soon they may be. When I enabled the llRequestURL() code and tried it out in OSGrid, I got a debug error message:

llHttpRequest: Request to http://Magrathea.Magrathea:9000/lslhttp ... 5c4455db1/ disallowed by filter

Magrathea is the name of my server where I host my OSgrid regions, so that looks like the return value from llRequestURL(). But it is unclear to me what computer is filtering out which request: The OSgrid asset servers? My home server Magrathea? The router I am using at home? (It has port 9000 opened up for running an OpenSim server). The server at my ISP that hosts the database the race gates are successfully sending llHTTPRequests to all day long? I'm going to have to step through the code and figure out where the error is happening. This will be hard because the system works by bouncing messages back and forth between the script in the prims and the scripts on the ISP server. I seem to recall that the script can send HTTP Requests to the ISP server, the ISP server can reply to those, but when the ISP Server makes an unsolicited HTTP Request to the script in Kitely, the request timed out without working. If I made the unsolicited request from my browser, it worked correctly, and when the ISP server makes an unsolicited HTTP request to a prim in InWorldz it works every time. Did I post a Mantis about this?

It is coming back to me: This inability to send unsolicited HTTP requests to prims was the main stumbling block to writing a vending machine that could work in-world and take PayPal payments. My PayPal dontation box works without a handshake because it doesn't matter if you fail to complete the transaction on the PayPal WEB site. The donation just never happens. But a vending machine needs to know if the PayPal transaction finishes before it delivers a product. It needs to get a message when that happens. I experimented with a vendor that polls my ISP server asking it if the transaction finished, but this is hard on the OpenSim server and hard on my ISP's server. (Like Ilan, they get upset with me from time to time).

[Kayaker Magic]

The problem with llRequestURL() turned out to be a setting in the OpenSim.ini. When I added my DNS address to that, I was able to send HTTP requests to a prim in my OSgrid regions.

I had a huge problem with the new physics engine ubODE failing to work in some OSgrid regions. This turned out to be caused by some of my scripts changing the physics shape of the legs of critters. Changing the physics shape is frowned upon by grid managers, but it does work under ODE or BulletSim. I submitted a Mantis showing how to make ubODE fail because of this and submitted a Mantis.

One way to temporarily fix this problem is to change the shape-shifting prims to Physics Shape Type None. But when running ubODE the drop-down in FireStorm for doing this does not appear! Apparently ubODE lacks some handshake that FireStorm needs to implement this. I submitted a Mantis suggesting that adding this should be a priority.

Changing the Physics Shape Type of the legs should not have been necessary, I did that for this critter a long time ago. But I transferred it to OSgrid by saving it in an OAR and loading that back up. Perhaps Physics Shape Type on child prims is not restored properly from an OAR? I will test that and submit yet another Mantis.

I started a second instance of OpenSim on the server in my barn, so I now have two regions next to each other that are not running on the same simulator. My non-physical sailboat still crosses back and forth across the border with ease! Only one more test: two instances of Opensim that are not running on the same server. I'll find some water somewhere in OSgrid and temporarily set my region up next to it for that test.

[Kayaker Magic]

There is an LSL function, llEdgeOfWorld, that is supposed to tell you if there is another region next to yours. This always returns 1 (for the edge, instead of 0 for "you have neighbors") in Kitely because you cannot place two Kitely regions next to each other.

Well now that border crossings work so well, it would be nice for a scripted boat to know if it is about to fall off the edge of the world, or if it is safe to proceed. So I started calling llEdgeOfWorld and discovered that in var regions it always returns 1 (edge) even when there was a neighboring region. I submitted a mantis for this. Oh, well, if you do try to move off the edge (with the non-physical llSetKeyframedMotion call) you just bounce harmlessly off the border.

llEdgeOfWorld is supposed to work in regular 256x256 regions, so I went to verify this in 0.9.0.0. It works, but only in some very constrained conditions, like unit vectors pointing exactly (don't be off by more than 1e-6!) in the cardinal directions (N S E or W). Point in any other direction and if fails. I submitted another mantis.

I can't test it to see if it fails in 0.8.x.x in Kitely 'cause we can't have neighboring regions! I can't test it in 0.8.x.x in OSgrid 'cause they all switched over to 0.9.0.0!

One big problem that I have with border crossing is that it definitely means that I will have to change my boat scripts to take it into account. Then I'll have to send updated versions to everyone who bought a boat from me. And everyone who bought a boat script from me. And everyone who bought a boat from someone who bought a resalable boat script from me. So I'd better get it right the first time! This is why I am testing in 0.9.0.0 long before Kitely upgrades.

I agree with Ilan that 0.9.0.0 has not been tested enough. (I'm trying to rectify that a little). Like Ilan I'm conservative about new versions of software (and especially 0.9.0.0 which had 3000 changes from 0.8.x.x!!!). For example: I'm so conservative I have never sold a script that used any osSL function. Even osGetRegionSize, which was written by our very own developer, Oren. I don't call osSL functions because if I became dependent on them, my code won't work in SL and InWorldz. Also because most of these functions have such scary threat levels that most grid managers disable them all. (Even osTickleBunny() seems to have a threat level of SUPER_PROMPT_CRITICAL). But I'm about to start using osGetRegionSize. It does have a threat level of "none". And with var regions everywhere and the advent of border crossings in 0.9.0.0, it is becoming embarrassing that my scripts need to get the size from the user via a dialog.

[Constance Peregrine]

Metropolis is currently running .8.3.0 DEV plus Met (which by using the Metro version it connects better to the grid) and you can run your own simulator instances for free, just as in OSG.

You can run any versions also, if you wish. There is a test grid also https://hypergrid.org/metropolis/wiki/e ... e=Testgrid

So maybe you can test there.

[Kayaker Magic]

I reported successful border crossing in a vehicle, but that was between two regular sized regions.
When I put two var regions next to each other in a single instance, vehicle crossings also work.
But when I put two var regions next to each other in separate instances (separate copies of the OpenSim code) I can't even fly an avatar back and forth across the border. Other people don't report this issue, but I tried re-installing 2 new copies of OpenSim fresh from the zip file (and with minimal changes in the setup) I got crossings to fail with two vars in two instances. I submitted a Mantis. Then discovered that a new version of the OSGrid distribution zip file was released the week after I downloaded mine! I'm going to have to start all over and test with that.

In the mean time I am testing crossing vehicles back and forth between two regular sized regions. (Poor baby, has to make do with only 131,072 square meters to sail over). I have found what I think is the optimal way to script forthis and got it working in all my boats. I was debating when to release these new versions, when I thought of a simple experiment: I took one of these new scripts back to OpenSim 0.8 in Kitely. The boat has menu items for choosing how to set up border crossings, it has code for returning to the dock across multiple SIM borders. None of that code can work in Kitely, but the good news is that it doesn't crash either. This means I can start releasing upgrades anytime (after some more testing) and those new versions will work now and will work better when run on a 0.9 system!

So now I've installed two regular regions in OSgrid, two 3x3 var regions, then two more 3x3 regions to verify the no-cross problem. I how have the equivalent of 38 old style 256x256 regions running on the server in my barn! I almost feel like a grid manager! Fortunately There is very little content in most of these, and rarely more than two avatars. My Kitely avatar delivering vehicles to convert and my OSGrid avatar working on them.