I splashed out on a new server, this one is even more powerful than my development rig, and used it to set up an even bigger Mars simulation.
This is comprised of four 8×8 regions arranged in a square. An 8×8 region means that it occupies 64 grid coordinates, so with four of them that means the new landmass is the equivalent size as 256 standard regions.
When you arrive at such a large region, it takes a while for the height-map to download and render, which is why such large regions are usually used for sailing (water is always rendered instantly - the terrain then covers the water). It's a pain, but the only solution is to divide them into smaller regions for faster rezzing. That means there are many more region boundaries to cross, which is immersion-disruptive. The fact that these huge regions have very few crossings means that once a region has rendered, it'll be a while before you get rubber-banded again.
I did make some seamless height-maps, creating them in L3DT, then loading them into GiMP, creating a monolithic map of all four regions, then editing the boundaries so they became seamless. Then it's a case of splitting the monolithic map back out into the individual maps - GiMP has all the tools to make this an easy and rapid process. It would take about 15 mins from creating the first map in L3DT to loading the finished maps into the region servers.
The only problem is they tend to make rather bumpy ground, even when that map is relatively smooth and boring. I've seen some work done in Blender to make both meshes and height maps and exporting them as PNG files. I could create a monolithic map that way and then load the PNG into GiMP to divide into into individual maps. I might try that later. In the meantime, I've decided to use the default flat landscape, and decorate it with a mixture of terraforming and mesh landscapes.
The roleplay damage system was designed to work on a single region. Now it has t cop with not one but five. When an avatar crosses from one region to another, they need to be able to take the current health and oxygen levels with them.
This means there needs to be a central server managing all the avatars in all the appropriate regions. It is best if the HUDs remain doing very little work - at the moment they allow the user to change their type (Human/biological, Cyborg, Robot) and other than that it just displays their health/oxygen status which the server sends them.
I want to keep the HUDs remain as detached as possible from the actual data, because then the server can track avatars not wearing a HUD.
That would then require a satellite server in each of the RP regions (the central server can be anywhere on the grid), which would perform the following operations:
This then raises the spectre of the persistence of data. Currently with the single-region model, if you leave the region and return, all your stats get bumped back up to 100%.
The multi-region model will dispense with this, but a script can only hold so much data, so it is entirely possible to crash the script over time. Even using LinksetDataStore only buys more time. There is still the limit of (64+128) 192k available for both code and data.
One option is to store avatar data in notecards, but you'd have to make one for each avatar, and finding and loading a notecard from an inventory of 10k notecards is going to be slow. It's unlikely that the situation will ever get that bad, but an efficient storage/retrieval system pays dividends.
The obvious solution is to store the data in a database: MySQl/MariaDB, PostgreSQL, SQLite etc. I don't like using http-in because of the inherent security risks, but the grid has an external website which I use to proxy back into the grid network, so I can either run the database from that website or locally.
To support this I just need to make one small change the HUDs - when they are worn, and whenever there is a region change, it announces itself to the local relay.
The local servrs can then track the avatar position, and when they leave the region send an update to the central server. If the avatar is still associated with that region, their data is saved back to the data store and dropped from the active list. If they arrive in a new region while they are still in the active list, their region ID is updated (so a 'left region' message from the previous region doesn't remove them from the active list).
If they arrive in a region and they're not in the active list, their data is fetched (or created) from the data store.
As usual, all things are possible as long as you can correctly identify where the problems lie and provide a workable solution. The main thing is to keep things as efficient as possible with minimal communications traffic.