Sim sizes need to change!!!!

[Qie Niangao]

If regions were larger, you just know folks would make their avatars enormous. And they're already freakishly large.

Smaller regions, please, so realistic human-scale avatars can be the norm.

[Profaitchikenz Haiku]

3 hours ago, Qie Niangao said:

Smaller regions, please,

Uuhh, you realise you're just incentivising the tiny avatars?

[Qie Niangao]

1 hour ago, Profaitchikenz Haiku said:

Uuhh, you realise you're just incentivising the tiny avatars?

Heaven forfend!

In fact, I do have an opinion on the real subject, which is that if they ever go to the considerable trouble of changing from 256x256, they shouldn't limit regions to square or even necessarily simple rectangular shapes, but they should always be assembled from contiguous 256x256 units aligned with the current grid.

Even with that restriction, any change would break a huge amount of user-generated content.

But at least this would make it feasible to reassign existing grid geography to different region configurations, instead of just being a vapid virtual world size-queen competition.

[Sprout Evergarden]

Being honest, a full sim is huge to a tiny you could build a whole tiny including airport on a full sim

[Ardy Lay]

I have been told that the tiny Residents move the decimal point in their minds.

[Miller Thor]

Let's look at the matter from the point of view of a region operator who does not see Second Life as an alternative to the flight simulator or as a replacement for various shipping simulators. In itself, enlarging the regions would be an optimal thing, only then would Linden Labs have to make some adjustments. If I assume the status quo, that although it is possible to have 30,000 land impacts for an additional charge, but still leave the script performance at the level of a 20,000 region according to the outdated algorithms, I hardly see any even when enlarged to e.g. a quarter square kilometer There is a chance that Linden will ever adapt the script values and from today's point of view it seems pointless to me to even think about it. As long as Linden Labs, for example, only looks at a script level of approx. 3500 active scripts for a 20,000 region in order to achieve full performance, you cut off all those who design their regions beautifully but also functionally and reduce the possibilities for you to use the functions that the manufacturers offer us today. Nowadays, for example, the operation of a multiseasonal region is only possible with the use of numerous designated and scripted objects, since otherwise the seasonal redesign would take dozens of hours in which the region would not be accessible. If we assume a quadrupling of the size of the region, the script performance should increase by eight times. To do this, however, one would have to completely rethink Linden Labs and finally adapt to the new demands that the technology offers. Technically, that would mean that one would have to rent far more servers, since the use of the processor cores on which today's regions are puddled would then also change for each region. Sure, you wouldn’t care much, as long as you have a cheap replacement for the flight simulator and also for those who prefer to enjoy shipping here instead of buying a multiplayer-compatible shipping simulator. But it is not indifferent to the thousands of other regional operators who want to operate their regions multifunctionally, multi-seasonally and with a very good performance. And that's why I first ask for a far-reaching adaptation of the script performance before one even thinks about enlarging the individual regions.

[Coffee Pancake]

4 minutes ago, Miller Thor said:

Let's look at the matter from the point of view of a region operator who does not see Second Life as an alternative to the flight simulator or as a replacement for various shipping simulators. In itself, enlarging the regions would be an optimal thing, only then would Linden Labs have to make some adjustments. If I assume the status quo, that although it is possible to have 30,000 land impacts for an additional charge, but still leave the script performance at the level of a 20,000 region according to the outdated algorithms, I hardly see any even when enlarged to e.g. a quarter square kilometer There is a chance that Linden will ever adapt the script values and from today's point of view it seems pointless to me to even think about it. As long as Linden Labs, for example, only looks at a script level of approx. 3500 active scripts for a 20,000 region in order to achieve full performance, you cut off all those who design their regions beautifully but also functionally and reduce the possibilities for you to use the functions that the manufacturers offer us today. Nowadays, for example, the operation of a multiseasonal region is only possible with the use of numerous designated and scripted objects, since otherwise the seasonal redesign would take dozens of hours in which the region would not be accessible. If we assume a quadrupling of the size of the region, the script performance should increase by eight times. To do this, however, one would have to completely rethink Linden Labs and finally adapt to the new demands that the technology offers. Technically, that would mean that one would have to rent far more servers, since the use of the processor cores on which today's regions are puddled would then also change for each region. Sure, you wouldn’t care much, as long as you have a cheap replacement for the flight simulator and also for those who prefer to enjoy shipping here instead of buying a multiplayer-compatible shipping simulator. But it is not indifferent to the thousands of other regional operators who want to operate their regions multifunctionally, multi-seasonally and with a very good performance. And that's why I first ask for a far-reaching adaptation of the script performance before one even thinks about enlarging the individual regions.

There are many parts of the SL infrastructure that don't just universally scale up. A mega region with lots of land might be the easy part, more Li is again just a number in a database.

It all falls over when you want to scale up the number of avatars or amount of physics and script time. You actually get more computing resources by creating many smaller regions.

Put that in our hands and what happens? Land barons will simply buy mega regions, carve them up in dozens and dozens of rentable plots and then cram as many people in as possible, we have seen this with homesteads, and the end result wont be pretty from a technical, user experience or financial perspective for LL.

[Qie Niangao]

4 hours ago, Miller Thor said:

Nowadays, for example, the operation of a multiseasonal region is only possible with the use of numerous designated and scripted objects, since otherwise the seasonal redesign would take dozens of hours in which the region would not be accessible.

This particular example at one level points to a simulator design problem that may well improve in the next year or so: the high impact of completely idle scripts. Those season-change objects aren't doing anything at all, just waiting for the possibility of being able to do something, briefly, every few months. It's just crazy that the scheduler effectively checks forty five times a second whether now is the time the script might have something to do. (It's even crazier than that. Even scripts that can never get an event to process—bare state_entry scripts—also get checked forty five times every second. And these make up a significant share of the scripts on a sim, including fire-and-forget particle emitters, texture animators, sound loopers, sit-target setters, etc. Ideally these property-setting scripts would remove themselves after running, but this would confuse end-users who couldn't shift-drag their objects to get a complete copy.)

At another level, it's a failure of commercial incentives for user-generated content in SL. Even if the script scheduler stayed as silly as it is now (and it's stayed that way for eighteen years), there's a fairly straightforward scripting approach that would substantially reduce the number of idle scripts on many sims; scripts that perform extremely infrequent season-change effects are the perfect example. Instead of the objects containing a script the whole time they're not changing seasons, there can be a single season-controller that keeps track when any object is rezzed that will need season-changing, and then pushes the corresponding script to those objects exactly and only when they're needed, to automatically remove themselves when the operation is complete. This process incurs a brief performance penalty while the scripts are being re-populated, but over the duration of the season would be a huge savings. Thing is, it only makes sense for regions with enough scale and sophistication to motivate the owner to take an extra step or two during set up, so there's less demand for such systems when it's easier to complain about how SL is old and slow.

[Extrude Ragu]

12 hours ago, Miller Thor said:

And that's why I first ask for a far-reaching adaptation of the script performance before one even thinks about enlarging the individual regions.

 

22 hours ago, Qie Niangao said:

Smaller regions, please

If I were Linden Labs I would look at the issue like this:-

• There is demand for flexibility in region size. Some residents want lots of space, others only want something very small
• There is demand for flexibility in region performance. Some residents only want to rez a few things, others want to build a fully scripted replica of Tokyo

In my eyes, the easier to implement of the two is the region size. It's just a number in a database and a viewer. You don't need to change the script resources allocated to the region, how many parcels can be created or how many objects or avatars can be rezzed.

Then of course is performance offerings. Some people want to do more with their space than others. Space and performance needs are not necessarily related. Linden Lab could work on new performance offerings, some low-power offerings for people who need fewer prims than a homestead, and higher power offerings for those who want to make something wild.

The more flexibility you can give to residents the better, because it is more likely it is that you will have a size/performance/cost offering that a resident will purchase. I know personally that I would be tempted by a cheap low performance sim for a private get away. Similarly, there might come a day where I want more resources available for my roleplay sim that currently SL just doesn't offer.

 

[Coffee Pancake]

56 minutes ago, Extrude Ragu said:

It's just a number in a database and a viewer.

It's not. Had they been developing SL from scratch today and thought to make regions variable size, then sure, it would be as simple as a number in a database.

Regions have always been assumed to be a set size, right from the start. So this was never set up as coming from a database.

The 256 x 256 number is hard coded into everything, and not just as a single number they can just search and replace. It's been a fundamental assumption that goes right into the deep magic.

Making different size regions would require going though the entire product stack and finding every single place where that assumption was written in. It would be a major undertaking on the scope of allowing users to change their user names (a similar fundamental assumption). The debugging process would be as big a job again, everything would break, often in weird and non obvious ways. (and that's not even considering the breakage that will happen to user content where that same assumption is forever locked away).

When the scope of a project is so large, far reaching, and fundamental, the question that will inevitably be asked is would it be better to design an entirely new architecture from scratch (with the benefit of 2020 hindsight). This is in part what lead to the creation of Sansar. SL is a giant house of cards, and region size is one of the very central foundational pieces - messing with that directly as you're under the impression they could, would bring the entire house down.

 

The statement from the lab on this is that while totally possible (it's just C++, anything is possible), it's too big of a project to take on at the moment. Doesn't mean it can't or wont happen or that they wont do some of the work incrementally as regular development touches the various systems.

Edited July 15, 2021 by Coffee Pancake

[Aria Aurelia]

It most likely will remain the fact that they wont ever be able to rebuild secondlife from the ground up either.  The time and the money to rebuild a platform this size would be astronomical and would take years to redo. 

[Mazidox Linden]

On 6/26/2021 at 5:31 PM, Adam Huntsman said:

A homestead and full sim need to change to the size of the ark evolved map with a height of 4000. Paying 125 a month or 350 a month is a lot of money for a small private island. I think second life needs a major update to keep up with the times. I think second life can be updated. Instead of a premier house maybe second life should consider the old style homestead and full sims being the new premier home. While make a new type of full sim the size of ark evolved. Food for thought. That would get millions of people to come on second life.

As mentioned on a recent Lab Gab, we have looked at changing the size of regions in Second Life, and even made a prototype, but it was extremely difficult to even get that far because the assumption that a region is exactly 256m by 256m is baked into many, many places in Second Life, both in the simulator and services that support it. You couldn't cross regions anymore, you couldn't manage parcel settings, you couldn't modify terrain properly, and many other issues. I'm not saying it could never happen, but it would be a very large initiative.

[Qie Niangao]

13 hours ago, Mazidox Linden said:

As mentioned on a recent Lab Gab, we have looked at changing the size of regions in Second Life, and even made a prototype, but it was extremely difficult to even get that far because the assumption that a region is exactly 256m by 256m is baked into many, many places in Second Life, both in the simulator and services that support it. You couldn't cross regions anymore, you couldn't manage parcel settings, you couldn't modify terrain properly, and many other issues. I'm not saying it could never happen, but it would be a very large initiative.

I wonder, though, if there might be another solution, preserving the 256x256 unit, while permitting those individually addressable units to be combined for the purposes of processing. So while X and Y dimensions are still in the same range, the stuff on those units are handled by the same threads and share the same memory. Obviously it's not at all a trivially simple solution, but it may be simpler, and achieve folks' "larger region" objectives (e.g., longer-range travel with fewer handoffs), avoid some of the compatibility problems for existing user-generated content, and sidestep the inherent floating point precision problems of larger in-region coordinates.

[bigmoe Whitfield]

17 hours ago, Mazidox Linden said:

As mentioned on a recent Lab Gab, we have looked at changing the size of regions in Second Life, and even made a prototype, but it was extremely difficult to even get that far because the assumption that a region is exactly 256m by 256m is baked into many, many places in Second Life, both in the simulator and services that support it. You couldn't cross regions anymore, you couldn't manage parcel settings, you couldn't modify terrain properly, and many other issues. I'm not saying it could never happen, but it would be a very large initiative.

that was the gist of it I got from ebbe on the tweet he replied too, that I sent him. 

[Flea Yatsenko]

On 7/16/2021 at 9:14 AM, Qie Niangao said:

I wonder, though, if there might be another solution, preserving the 256x256 unit, while permitting those individually addressable units to be combined for the purposes of processing. So while X and Y dimensions are still in the same range, the stuff on those units are handled by the same threads and share the same memory. Obviously it's not at all a trivially simple solution, but it may be simpler, and achieve folks' "larger region" objectives (e.g., longer-range travel with fewer handoffs), avoid some of the compatibility problems for existing user-generated content, and sidestep the inherent floating point precision problems of larger in-region coordinates.

You are basically just advocating for updates to sim crossing performance. I don't think we're ever going to see the current Second Life have regions larger than 256x256. The fact they created homesteads which still are 256x256 should give you insight to how difficult working with this is.

The only chance they have for different sim sizes is to make smaller sim sizes, but it would just be pretending to divide a 256x256 simulator up into smaller sims. Which wouldn't really be worth the time or effort to do because you'd still be constricted by other people on the sim. i.e. there are 4 people with 128x128 fake mini sims and you want to expand your 128x128 to 128x256, well too bad someone else has that quarter. So they'd have to be moved or something. I really want to see it happen and I thought the move to AWS would make things easier since they are virtual private servers so you can add CPU cores, RAM, etc at will, but the code won't allow it. The only way we're going to see sims "expand" is raised limits for maximum number of avs on a sim, higher land impact capacity, etc, probably at a higher cost.

The sim size is not changing, maybe we could some day see sims that have different priorities or levels you can buy (i.e. script performance, number of avatars, prim capacity, etc). But I think it's always going to be 256x256 until someone at LL really wants a big project. And to be honest, if 256x256 is baked so far into SL, going around and changing it is going to make a ton of bugs in other things. I actually wonder if the issues making these huge changes to support sims other than 256x256 would be worth it, because if it's that deep into it changing it is going to break a lot of things no one at LL can foresee.

[Coffee Pancake]

2 hours ago, Flea Yatsenko said:

You are basically just advocating for updates to sim crossing performance.

The only way we get better region crossing performance now is to add a buffer zone at the border that once entered preemptively sends an avatar (or a part of) to the neighboring region, perhaps making scripts the only part to really be moved at the instant of crossing.

[Qie Niangao]

3 hours ago, Flea Yatsenko said:

You are basically just advocating for updates to sim crossing performance.

No, but I don't much care.

I'll just note that there are at least two separable topics here conflated into "bigger sims pleeze":

1. Make it possible to travel longer distances without incurring border-crossing risks, and
2. Make new Land products that distribute costs differently across virtual acreage and simulator performance

both of which may be valid objectives but neither necessarily entails big-ass square regions.

 

[Chris Corvinus]

On 6/26/2021 at 10:20 PM, Lucia Nightfire said:

The only way millions would flock to SL is if they were offering full regions at $19.95 a month.

Actually, that price makes more sense since it’s all in the cloud now. 

[animats]

On 7/15/2021 at 11:35 AM, Coffee Pancake said:

The 256 x 256 number is hard coded into everything, and not just as a single number they can just search and replace. It's been a fundamental assumption that goes right into the deep magic.

There's also the assumption that each sim has four neighbors. Adjacent sims of different sizes would need some viewer work. Not insurmountable, though.

There are lots of technical fixes possible, all hard.

• Fix the idle-script problem. (That might actually happen.)
• Regions with heavy traffic could have extra CPUs devoted to them. Big win for events and clubs if you could order more compute power and get maybe 200 people in. You'd probably have to take a sim restart and move to a new server to get more compute, but that's the whole point of AWS. This is only useful with some of the following fixes.
• Support using multiple threads in a sim to run scripts. LSL could support this, because few calls both read and write world state without a delay. So you could run scripts based on world state at frame start, and then do all the system state updates at frame end. Any script which writes and then reads world state waits one sim frame at that point. Most calls which do that already have an official delay. Under that set of restrictions, concurrency is possible. Properly coded scripts should not break. Somewhere, though, it would break a badly coded script.
• Enable concurrency in Havok. It's supported, but SL doesn't use it. Although physics time for a sim is seldom high. May not be worth the trouble.
• The impact of an avatar entering a region is larger than it should be. Find out why and fix that. Inter-sim networking is faster than it used to be, and we see that for objects crossing region boundaries. But not, as yet, for avatars.
• Stop for double region crossings at corners, which just don't work. Don't let a second crossing start until the first has completed.
• Provide some automatic overlap for objects at the edge of prims. I'd suggest tying this to the navmesh updater, so that, on navmesh update, all walkable objects within a few meters of the sim edge get duplicated invisibly into the neighboring sim. Never fall through at a region crossing again.

The effect would be that region sizes would matter less. If you needed more resources, you could buy them.

All this requires about two more Simon Lindens. 

[Coffee Pancake]

 

18 minutes ago, animats said:

• Regions with heavy traffic could have extra CPUs devoted to them. Big win for events and clubs if you could order more compute power and get maybe 200 people in. You'd probably have to take a sim restart and move to a new server to get more compute, but that's the whole point of AWS. This is only useful with some of the following fixes.

200 avatars on a region would be game over for the client, it would tank the event experience entirely. The imposed asset load would would bog the viewer down and then animating all the additional rigged objects would make sure it stayed dead.

18 minutes ago, animats said:

• The impact of an avatar entering a region is larger than it should be. Find out why and fix that. Inter-sim networking is faster than it used to be, and we see that for objects crossing region boundaries. But not, as yet, for avatars.

(assuming this hasn't changed and I'm remembering it correctly) Avatars are zipped in transit between regions. Assuming LL are just calling zip and waiting for it to finish before processing the data,  that will have a locking effect on the thread running a region, this translates to a micro pause in the execution of that frame (inserting script microcode from that avatar into the mono runtime likely also comes with a momentary pause). This is also why avatar's leaving a region have the same impact.

Multithreaded unzipping is possible, however avatars aren't large enough from a data perspective to really give the time needed for this to show any gains, if anything I would expect it to cause a slightly shorter stutter to all region threads on the simhost.

 

18 minutes ago, animats said:

• Provide some automatic overlap for objects at the edge of prims. I'd suggest tying this to the navmesh updater, so that, on navmesh update, all walkable objects within a few meters of the sim edge get duplicated invisibly into the neighboring sim. Never fall through at a region crossing again.

A region loading object physics for items placed along a neighboring region borders would resolve the border crossing 'drop' effect that's seen on all Horizons roads, so would reworking and replacing the roads so prims didn't end exactly at the region border. I reported this, some came out and walked up and down .. and then that was the end of that .. probably got filed away under "expected behavior".

[Mr Amore]

Since the 'uplift' to the cloud, I've wanted to see instanced regions which are:

• Online when you need them
• Offline and off the grid when you're gone.
• Disconnected from other sims with no neighbors, perhaps not even part of the world map.

LL could trial new technologies in 'instanced sims' without worrying about breaking old content, such as larger sims.

And there could be a pay-as-you-go pricing structure, for instance paying $60/month for a sim I've used for 40 hours makes more sense than $200'ish for a sim I'll use for 40 hours/month.

Sansar had the right idea with instanced 'Experiences', it should be possible in SL too.

 

 

[Tonia Amore]

LL have there reasons for wanting the region size to stay as it has been for many years now. I myself has chosen to have a small holding on the  Jeogeot continent but run my own region simulator on Osgrid 1024x1024 in size. For me running your own simulator is very rewarding and teaches you a lot about how it all works. I also use tight VNC in server mode on my Server PC and in Viewer mode on my other PC. So when not in either virtual world I can monitor my server from downstairs without having to go to where my server PC is upstairs. Sometimes the answer maybe to enjoy the much superior content in SL but to also try out the hypergrid enabled opensim world where land is cheap but there is so many positives and negatives about both systems. I myself would love to be able to TP from one system to the other which they did back in 2008.

[animats]

On 7/25/2021 at 9:09 PM, Coffee Pancake said:

A region loading object physics for items placed along a neighboring region borders would resolve the border crossing 'drop' effect that's seen on all Horizons roads, so would reworking and replacing the roads so prims didn't end exactly at the region border. I reported this, some came out and walked up and down .. and then that was the end of that .. probably got filed away under "expected behavior".

Yes, the joints between road parts in Horizons and Zindra were totally botched. There are a few bad spots on other continents, but not many.

There's also a problem with Bellessaria road corners not being level, which is a problem for some vehicles.

LL needs a search and replace tool for semi-automatically fixing such problems. It would be cool if that was done in world by LDPW maintenance vehicles, slowly traversing the roads, examining road prims, looking up which UUIDs had an improved replacement available, lifting out the old prim, putting in the new prim, and continuing on. Like this one:

SL needs something like this.

[bigmoe Whitfield]

over here chuckling at the 19.95 a month for a sim,  well that's not going to end well for any one if they do that.   Stop and put the brakes on for a moment,  Sim sizes are locked to 256m,  back end requires it,  not easily changed,  aws costs more to operator, per oz linden talking about it on lab gab,  their physical presense was cheaper but they were using 10 to 12 year old servers and other equipment, which those costs are costly, ask me how I know...

So it's nice to dream though but,  there would require so much to do to make 256m goto 1024 or bigger,  this is not opensim and is not easy to do.