OpenSimWorld is the directory of 3D Virtual Worlds based on OpenSimulator and connected through the HyperGrid. Learn More
New Members
DracoBathory, RespawnPending, AnastasiaEgal, DeeRyder, Kej0raMoondancer, Nikki Bellini, AnielStarchild, LinkUp, Juliarios2027, Iska Palmer, Jayden Palmer, Lolla, ReinaFae, AllenStone222, LoganNorton, TequilaVale, Chulis17, HugoGoldbarow, JolieBluefire✦, AllenStone22Likes
Estate / Region management interface showing a few regions and then a region popped up for management (clearly not many options yet!!)
From here it will be possible to restart a region. Depending on your configuration of simulators this will either restart or shutdown - if its set to shutdown you need something else to start your region back up (monit is a good option).
Also OARs will be downloadable and uploadable from here. Due to the risks of operations like OAR backups / restores they will be configuable by constants on the config.php with at least restores disabled by default.
Still deciding what other tools to build in here.
There will also be some estate wide tools but that's not been started at all.
Map tiles are cached and not updated unless you request new ones. As they are calculated based on region size and downloaded in 256x256 chunks and stitched together getting them fresh each time is "expensive" especially on regions like the 4096x4096 I tested - thats a lot of chunks!
From here it will be possible to restart a region. Depending on your configuration of simulators this will either restart or shutdown - if its set to shutdown you need something else to start your region back up (monit is a good option).
Also OARs will be downloadable and uploadable from here. Due to the risks of operations like OAR backups / restores they will be configuable by constants on the config.php with at least restores disabled by default.
Still deciding what other tools to build in here.
There will also be some estate wide tools but that's not been started at all.
Map tiles are cached and not updated unless you request new ones. As they are calculated based on region size and downloaded in 256x256 chunks and stitched together getting them fresh each time is "expensive" especially on regions like the 4096x4096 I tested - thats a lot of chunks!
Liked by: 
Comments
This is likely related to what InworldRestartShutsDown is set to in Opensim.ini.
If it's set to false (default) then the simulator doesn't shutdown, only the region specified hosted by the simulator process. However due to bugs in opensim this (while easier) can sometimes cause issues.
If it's set to true then the simulator process itself shuts down totally. This option means that the simulator starts fresh with no memory leaks or other stuff "hanging around" causing problems.
However the second option only really works if you have only one region per stimulator process. You can't have all your regions going down just because you restart one of them! Additionally if you use this option the region will not come back online by itself. The simulator process can't start the region back up if it itself has shut down.
InworldRestartShutsDown = true then relies on some third party mechanism to start the simulator (and therefore the region) back up. One of the most common ways of doing this is to use monit to monitor the simulator processes and to start them up when it notices a region is offline.
This way the simulator totally shuts down and then comes back online in a couple of minutes. Totally fresh, no memory leaks or other problems caused by the "normal" in world restarts.
like(0)
If it's set to false (default) then the simulator doesn't shutdown, only the region specified hosted by the simulator process. However due to bugs in opensim this (while easier) can sometimes cause issues.
If it's set to true then the simulator process itself shuts down totally. This option means that the simulator starts fresh with no memory leaks or other stuff "hanging around" causing problems.
However the second option only really works if you have only one region per stimulator process. You can't have all your regions going down just because you restart one of them! Additionally if you use this option the region will not come back online by itself. The simulator process can't start the region back up if it itself has shut down.
InworldRestartShutsDown = true then relies on some third party mechanism to start the simulator (and therefore the region) back up. One of the most common ways of doing this is to use monit to monitor the simulator processes and to start them up when it notices a region is offline.
This way the simulator totally shuts down and then comes back online in a couple of minutes. Totally fresh, no memory leaks or other problems caused by the "normal" in world restarts.
maybe resize and rename region, rename estate, assign new estate, and parcel management, prims per parcel report, delete parcel. all that stuff is in land table. creating parcels probably best done inworld i guess. also maybe transfer ownership of all prims in region. some ideas :)
like(2)
Some of these I would of course only want to give to a full administrator: I wouldn't want an estate owner or estate manager to change the size of their region, or how many prims were assigned to them etc. At the moment what I am working on is the "My Estates" menu option for owners/managers so a lot of those would not want to be there.
Later on, I will be working on estate/region management from the administrator’s point of view, and those options make more sense there.
However, this presents one of my dilemmas: Every opensim grid is different. Just to give two example:
Simulators/Regions: Some people have several regions on one simulator. This means they can’t shut down the simulator when they restart a region (as all the regions on that simulator would go down), others (like me) have one region per simulator process meaning shutting down the whole simulator works well to do restarts. However, it also then relies on a third-party tool such as monit to restart the simulator process (and the region) when it notices its offline. This also means that taking a region offline (not just restarting it) becomes more of a task as doing so will just mean monit restarts it. Additionally, if you are using Remote Admin Console on the simulator to restart regions (and other tasks) what IP address/port do you use? If you have one simulator with multiple regions, you will need a port for the simulator in addition to the actual regions (or you could use the first port of the first region). What if you have several simulators with various numbers of regions on each? How does the web app know which IP:Port to talk to for each region restart? Alternatively, if you have one region per simulator you can just use the region port to talk to the remote admin console on the simulator (this is the most straightforward approach and the one on my grid). All of these options are viable with different pros and cons. Making a front end flexible to work with all of them is “challenging”. The most obvious way would be to have a lookup table, region, region port, simulator, remote admin port etc. When wanting to restart a region the lookup table will tell you which remote admin console to talk to when sending commands to restart a region. How is the lookup table built? At the moment I am just using the region port. It’s simple, it works, but it requires all regions to be on their own simulators with no second port for remote admin. It works for MY grid, and for anyone with a similar setup. It WONT work for those who have a different arrangement, however.
Startup/Stop/Configuration: My grid is currently arranged using a set of configs that are based on a design created/distributed several years ago by snik snoodle. I have a grid folder in opensim/bin and inside that a folder for each region. Each region folder has a log file, an OpenSim.ini file, a start_sim.sh, a stop_sim.sh and a Regions folder with a single Region.ini file in. Monit monitors my simulator processes and if a region is down it uses the start_sim.sh command to start it back up. I have a create_simulator.sh script that creates a new region based on prompts for settings (I did have one that just too command line arguments, but I need to redo that). However almost everyone else will likely have a very different arrangement. Renaming a region isn’t as straightforward. It needs to manipulate the Region.ini file to edit the name at the top. This needs the web front end to know where to find this file, with different setups this becomes less than straight forward. Additionally, if I change the region name in Region.ini this is no longer consistent with the folder name for that simulator. I may originally have a folder called “MyFirstRegion” and call the region itself in the Region.ini file “My First Region”. They ARE different – but clearly related. However, when I change the region name to “This Must Be Thursday” it’s now one region name running on a totally unrelated simulator process. Manually I would use sed to update all references of the simulator folder name as well, I COULD do similar from the web front end – but that completely ties it into MY setup. Again, this comes down to “My Grid, or General”? Because of this I have already decided that SOME options I won’t be putting into the version of this I distribute – its just too much of a headache.
For region restarts – I will be making two options available: In the config there will be a config constant for Simulator Remote Admin Port. If a port is stated there, then it will be used for talking to a single simulator process for all things like region restarts. If there is no port mentioned there, then it will instead use the region port to talk to the simulator processes – one per region – and assume that the simulator is configured to use the standard region port.
Sorry for the wall of text – but hopefully you can see the dilemma I have with some of this. Ultimately, I want this tool to be as useful as it can be to as many people but for grid/simulator/region management the more you offer the easier it breaks with different configurations. I did after all start this to provide my own grid with a front end that works for me but have already put in features I am unlikely to use myself (I do not offer signups for local users for example, but I have built that into the system). A simple login, see your profile, see your friends, view offline messages, even partner: All very simple and works with all configurations (all standard configurations at least), but grid management throws a whole toolbox of spanners in the works!
like(0)
Later on, I will be working on estate/region management from the administrator’s point of view, and those options make more sense there.
However, this presents one of my dilemmas: Every opensim grid is different. Just to give two example:
Simulators/Regions: Some people have several regions on one simulator. This means they can’t shut down the simulator when they restart a region (as all the regions on that simulator would go down), others (like me) have one region per simulator process meaning shutting down the whole simulator works well to do restarts. However, it also then relies on a third-party tool such as monit to restart the simulator process (and the region) when it notices its offline. This also means that taking a region offline (not just restarting it) becomes more of a task as doing so will just mean monit restarts it. Additionally, if you are using Remote Admin Console on the simulator to restart regions (and other tasks) what IP address/port do you use? If you have one simulator with multiple regions, you will need a port for the simulator in addition to the actual regions (or you could use the first port of the first region). What if you have several simulators with various numbers of regions on each? How does the web app know which IP:Port to talk to for each region restart? Alternatively, if you have one region per simulator you can just use the region port to talk to the remote admin console on the simulator (this is the most straightforward approach and the one on my grid). All of these options are viable with different pros and cons. Making a front end flexible to work with all of them is “challenging”. The most obvious way would be to have a lookup table, region, region port, simulator, remote admin port etc. When wanting to restart a region the lookup table will tell you which remote admin console to talk to when sending commands to restart a region. How is the lookup table built? At the moment I am just using the region port. It’s simple, it works, but it requires all regions to be on their own simulators with no second port for remote admin. It works for MY grid, and for anyone with a similar setup. It WONT work for those who have a different arrangement, however.
Startup/Stop/Configuration: My grid is currently arranged using a set of configs that are based on a design created/distributed several years ago by snik snoodle. I have a grid folder in opensim/bin and inside that a folder for each region. Each region folder has a log file, an OpenSim.ini file, a start_sim.sh, a stop_sim.sh and a Regions folder with a single Region.ini file in. Monit monitors my simulator processes and if a region is down it uses the start_sim.sh command to start it back up. I have a create_simulator.sh script that creates a new region based on prompts for settings (I did have one that just too command line arguments, but I need to redo that). However almost everyone else will likely have a very different arrangement. Renaming a region isn’t as straightforward. It needs to manipulate the Region.ini file to edit the name at the top. This needs the web front end to know where to find this file, with different setups this becomes less than straight forward. Additionally, if I change the region name in Region.ini this is no longer consistent with the folder name for that simulator. I may originally have a folder called “MyFirstRegion” and call the region itself in the Region.ini file “My First Region”. They ARE different – but clearly related. However, when I change the region name to “This Must Be Thursday” it’s now one region name running on a totally unrelated simulator process. Manually I would use sed to update all references of the simulator folder name as well, I COULD do similar from the web front end – but that completely ties it into MY setup. Again, this comes down to “My Grid, or General”? Because of this I have already decided that SOME options I won’t be putting into the version of this I distribute – its just too much of a headache.
For region restarts – I will be making two options available: In the config there will be a config constant for Simulator Remote Admin Port. If a port is stated there, then it will be used for talking to a single simulator process for all things like region restarts. If there is no port mentioned there, then it will instead use the region port to talk to the simulator processes – one per region – and assume that the simulator is configured to use the standard region port.
Sorry for the wall of text – but hopefully you can see the dilemma I have with some of this. Ultimately, I want this tool to be as useful as it can be to as many people but for grid/simulator/region management the more you offer the easier it breaks with different configurations. I did after all start this to provide my own grid with a front end that works for me but have already put in features I am unlikely to use myself (I do not offer signups for local users for example, but I have built that into the system). A simple login, see your profile, see your friends, view offline messages, even partner: All very simple and works with all configurations (all standard configurations at least), but grid management throws a whole toolbox of spanners in the works!
Ive had a think about one of these things:
Simulator/Region remote admin ports. My current thinking is a lookup table for RegionName, RegionPort, SimulatorName, SimulatorIP, SimulatorPort, Notes. There can be an admin option to populate this lookup table.
If the config constant REMOTE_ADMIN_PORT is given a port - then each region will be entered in here with the SAME SimulatorName, SimulatorIP, SimulatorPort. If REMOTE_ADMIN_PORT is null or blank, then the SimulatorName, SimulatorIP and SimulatorPort will be the same as the Region. This simple option on the management screen will add any regions that do not currently have an entry, while allowing existing entries to be deleted or edited.
By editing an entry you can CHANGE the SimulatorName, SimulatorIP, SimulatorPort to whatever you need for each region. It's a manual process but allows you to OVERRIDE what would be defaults to allow multiple simulators each with multiple regions. EVERY remote admin call will use this lookup table to route the command to the correct simuator process.
For simple "one simulator multiple regions" or "multiple simulators each with one region" setups - no manual work is required other than going to the admin screen and clicking "update lookup table" (which also needs to be done every time new regions are added). The only real manual changes are for cases with multiple simulators each with multiple regions.
like(0)
Simulator/Region remote admin ports. My current thinking is a lookup table for RegionName, RegionPort, SimulatorName, SimulatorIP, SimulatorPort, Notes. There can be an admin option to populate this lookup table.
If the config constant REMOTE_ADMIN_PORT is given a port - then each region will be entered in here with the SAME SimulatorName, SimulatorIP, SimulatorPort. If REMOTE_ADMIN_PORT is null or blank, then the SimulatorName, SimulatorIP and SimulatorPort will be the same as the Region. This simple option on the management screen will add any regions that do not currently have an entry, while allowing existing entries to be deleted or edited.
By editing an entry you can CHANGE the SimulatorName, SimulatorIP, SimulatorPort to whatever you need for each region. It's a manual process but allows you to OVERRIDE what would be defaults to allow multiple simulators each with multiple regions. EVERY remote admin call will use this lookup table to route the command to the correct simuator process.
For simple "one simulator multiple regions" or "multiple simulators each with one region" setups - no manual work is required other than going to the admin screen and clicking "update lookup table" (which also needs to be done every time new regions are added). The only real manual changes are for cases with multiple simulators each with multiple regions.
everything in regions database table i think.
SELECT JSON_OBJECT(
'serverIp',serverIp,
'serverUri',serverUri,
'serverPort',serverPort,
'locx',locx,
'locy',locy,
'serverHttpPort',serverHttpPort,
'serverRemotingPort',serverRemotingPort
) AS json_row
FROM regions WHERE regionName='Sweet Sanctuary';
{"serverIp": "dyn.holoneon.com", "serverUri": "http://dyn.holoneon.com:9000/", "serverPort": 8044, "locx": 260352, "locy": 257536, "serverHttpPort": 9000, "serverRemotingPort": null}
like(0)
SELECT JSON_OBJECT(
'serverIp',serverIp,
'serverUri',serverUri,
'serverPort',serverPort,
'locx',locx,
'locy',locy,
'serverHttpPort',serverHttpPort,
'serverRemotingPort',serverRemotingPort
) AS json_row
FROM regions WHERE regionName='Sweet Sanctuary';
{"serverIp": "dyn.holoneon.com", "serverUri": "http://dyn.holoneon.com:9000/", "serverPort": 8044, "locx": 260352, "locy": 257536, "serverHttpPort": 9000, "serverRemotingPort": null}
I only work with Linux. Besides Fred has Windows covered with Dreamgrid I think!
Having said that - there is probably nothing in the base version I am writing that WONT work with windows. If the grid is running on a MySQL database.
The web portal DOES need to either be on the same server as the grid database and robust/simulators. While you can get round that with clever use of Nginx and port forwarding that would be an excercise for someone to work out themselves. Anyone running a grid large enough to split their simulators up onto several servers can probably work that part out themselves easily enough though.
The system runs on php. So long as you have that and can connect to the DB and Robust/Simulators it SHOULDNT care what you are running OpenSim on.
like(1)
Having said that - there is probably nothing in the base version I am writing that WONT work with windows. If the grid is running on a MySQL database.
The web portal DOES need to either be on the same server as the grid database and robust/simulators. While you can get round that with clever use of Nginx and port forwarding that would be an excercise for someone to work out themselves. Anyone running a grid large enough to split their simulators up onto several servers can probably work that part out themselves easily enough though.
The system runs on php. So long as you have that and can connect to the DB and Robust/Simulators it SHOULDNT care what you are running OpenSim on.
I have been following your posts on this with great interest... I like where this rabbit hole is leading!
like(3)