Jump to content

No Sim Boudries???


You are about to reply to a thread that has been inactive for 687 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

Ok here's an idea for Linden. When two private estate sims are joined how about eliminating the sim boundary? Now I say two sims because the idea of joining more becomes i think a challenge though still possible.In effect this would allow more freedom in use of the sims. As for prims I suppose the two regions (known as VAR) could consolidate. So is this possible? If not why not? Thanks

  • Haha 1
Link to comment
Share on other sites

SL is designed around regions being stand alone defined chunks, everything they do is based around this and has been assumed true for the entire life of the product. These assumptions are baked into the entire codebase.

This is also why we can't have variable size regions. (LL have experimented with this internally).

Making the point of region crossing seamless is also impossible with the architecture as designed & implemented due to avatar handovers,  attachments and active scripts must be paused, packaged, passed, unpacked and reloaded. This can't happen instantaneously, although there are things LL could do to mitigate certain aspects.

 

There is no reason any of what you want can't be done, it is all just C++ after all, however accomplishing those goals requires a massive engineering project touching almost all aspects of the codebase.

  • Like 2
  • Thanks 3
Link to comment
Share on other sites

1 hour ago, Coffee Pancake said:

SL is designed around regions being stand alone defined chunks, everything they do is based around this and has been assumed true for the entire life of the product. These assumptions are baked into the entire codebase.

This is also why we can't have variable size regions. (LL have experimented with this internally).

Making the point of region crossing seamless is also impossible with the architecture as designed & implemented due to avatar handovers,  attachments and active scripts must be paused, packaged, passed, unpacked and reloaded. This can't happen instantaneously, although there are things LL could do to mitigate certain aspects.

 

There is no reason any of what you want can't be done, it is all just C++ after all, however accomplishing those goals requires a massive engineering project touching almost all aspects of the codebase.

Ok as I thought BUT code could be written so that knowing where the ONE sim is in the region code then a sim (chunk) could be sized (512 X 256) so that it exists as one region within the same location. One wonders if the massive engineering project would take as much time as was spent on Sansar? Opensimulator code is complex but I believe there are engineers that could accomplish the task. 👍

  • Haha 1
Link to comment
Share on other sites

LL did experiment with making variable sized regions and ran into a number of issues, everything from physics to scripting to the viewer is built on the core assumption that a region is always exactly as initially designed.

It's a huge project not because of the complexity, but because it would end up touching every single part of the entire product stack in some way and there would be a lot of unforeseen bugs and hitches along the way, everything would need to be resolved entirely before it could be rolled out for regular public use. It's probably harder than Sansar was as SL has a lot of long standing technical debt, and most of the people who designed the deep magic have moved on. A lot of the bugs along the way would be of the deeply weird variety too, ultimately simple to resolve, but intensely time consuming and complicated to research and unpick.

I really hope someone at LL is tinkering away to resolve some of the issues as I would really like to see mega (or micro) regions, even if they come with all the same caveats and constraints that regions have now (script time, limits, etc).

  • Like 3
Link to comment
Share on other sites

Thanks Coffee appreciate your input. I also hope that as the word "metaverse" starts spreading that maybe LL will start to tinkering. But they have Rosedale to bounce off of to maybe help 😉

Not sure if micro would be applicable but interesting. Lets hope that this would be the next great project that LL will take on. 👍

  • Haha 1
Link to comment
Share on other sites

10 minutes ago, Wallace Wirefly said:

Not sure if micro would be applicable but interesting. Lets hope that this would be the next great project that LL will take on. 👍

Micro regions would be a run away hit .. say something a quarter the size of a region with a quarter of a homestead's resources at a quarter of the price (1250Li, 5 avatars, $25 pm).. Just enough of a private little bubble for a home and a few friends

  • Like 8
Link to comment
Share on other sites

23 minutes ago, Coffee Pancake said:

Micro regions would be a run away hit .. say something a quarter the size of a region with a quarter of a homestead's resources at a quarter of the price (1250Li, 5 avatars, $25 pm).. Just enough of a private little bubble for a home and a few friends

Want.

  • Like 2
Link to comment
Share on other sites

Coffee is right... it's just code which is mod. I can imagine a "compatibility-mode"  implementation where a "simulator" is not bound to  one region (256mx256m) but rather a collection of contiguous regions, such as 64 regions in an 8x8 square. Scripts and users would still see region-based addressing but transfer of state between simulators would happen only when you left a region set. All this depends upon computing machinery that is MUCH faster than the current stuff.

A less compatible way of doing things would be to change the addressing model that users and scripts act upon... having named regions that are a size other than 256m by 256m. This would break all scripts and other code that deal with addresses.

Curiously, the current implementation sits upon a global coordinate system which is defined to be "precise enough for ~109 regions on an edge with same precision as region-local coordinates." That is a billion billion regions, probably bigger than what you need for the Oasis as described in Ready Player One.

Edited by diamond Marchant
  • Like 4
Link to comment
Share on other sites

2 minutes ago, Coffee Pancake said:

I wouldn't be upset if variable regions came with a with a whole ton of script breakage.

I'd like to see LL put in llGetRegionSize, working just like http://opensimulator.org/wiki/OsGetRegionSize in OpenSimulator. All it would do now is return <256, 256, 0>, but scripts could stop hard-coding 256 meters and be ready for future expansion.

  • Like 3
Link to comment
Share on other sites

There's talk here of the issue of all of the various code-bases making a key assumption that the region is always 256 by 256.

My (stupid) thought is maybe it would reduce some of the code alteration required if say the simulator could pretend to be many regions. Like a 512 by 512 region would expose itself as 4 sims to the map service, to legacy clients and SL's various web services. When an old client connects to the sim, the sim just plays along and does all the standard handover 'region crossing' protocols etc.

But the sim would have some special flag that newer clients recognize to indicate the region is part of something bigger and not to bother with handshakes etc when 'region crossing' within the same sim. That way most of the logic in the viewer and sim can remain unchanged.

  • Like 1
Link to comment
Share on other sites

15 hours ago, Extrude Ragu said:

But the sim would have some special flag that newer clients recognize to indicate the region is part of something bigger [...]

This might be useful for purposes broader than just the oversized sim thing, which has never interested me all that much anyway. The "something bigger" could have a single unified landing point and addressing, and even someday have coordinates in that "bigger" system.

There's a lot to be decided if we simply bloat-up regions, which works fine in OpenSim because nobody goes there anyway, but here we'd need to decide how (and whether) to scale up avatar and/or object limits, and some LSL region-scale functions like llGetAgentList and llRegionSayTo (and listen handlers) may suddenly lag. (That's in contrast to stuff that's merely a coordinate system shift like llSetRegionPos that shouldn't take extra computing to scale up.)

Link to comment
Share on other sites

On 5/7/2022 at 4:14 AM, animats said:

I'd like to see LL put in llGetRegionSize, working just like http://opensimulator.org/wiki/OsGetRegionSize in OpenSimulator. All it would do now is return <256, 256, 0>, but scripts could stop hard-coding 256 meters and be ready for future expansion.

 

Might I suggest returning <256,256,4096> just in case.. :)

On 5/8/2022 at 3:04 PM, Qie Niangao said:

but here we'd need to decide how (and whether) to scale up avatar and/or object limits

So like in my mind the relationship goes like this

One Simulator (Computer program) > Many regions (Squares on the map) -> Each with many parcels

Obviously the computer has finite resources, so the prim limit, script time etc would be one shared resource pool for all of the regions that run under the same sim.

A region crossing becomes different to a sim crossing - Crossing a region doesn't necessarily mean that you cross a sim, and might involve no network actions at all and be completely seamless if they're both on the same sim.

A private land owner would have the option to buy a sim instead of a region. They can then choose how many regions they want to split their sims resources amongst. If one particular area needed more resources they might get an extra sim just for that area. The idea being to de-couple performance requirements and space-requirements. Later down the line LL might then develop higher power sims that have more resources, for people that need both no sim crossings and lots of resources, assuming they can make it economic.

  • Like 1
Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 687 days.

Please take a moment to consider if this thread is worth bumping.

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
 Share

×
×
  • Create New...