[sldev] Sim Size Limits?

Dahlia Trimble dahliatrimble at gmail.com
Sat Nov 1 12:27:05 PDT 2008

Given that the grid defines each slot as 256x256, I cant see that other
sizes are likely. What is more likely is a 256x256 region being cut up into
smaller pieces and each assigned to a different host processor. Somehow the
viewer and the protocol would have to be fooled to make the viewer think
that it was all a single region. Opensimulator is already experimenting with
this with a load balancing module. In this case the size isn't really
constant, it can fluctuate dynamically in response to region load. Another
possibility that may be useful is having multiple 256x256 regions combined
into a single region. This would again need to fool the viewer into thinking
it was talking to multiple simulators. Opensimulator does this now by
assigning each region to a different IP port. If the protocol and the viewer
could assume that multiple 256^2 regions could exist on the same simulator
it may offer a way to improve the region border crossing delays we see now,
even on regions that are hosted on the same simulator instance.
This all assumes a script would need to know that it's running on a
simulator that is not a 256^2 square, which may not be useful information.

On Sat, Nov 1, 2008 at 7:50 AM, Kent Quirk (Q Linden) <q at lindenlab.com>wrote:

> There are things that are worth abstracting, and things that aren't.
> Writing a function that returns pi in case its value changes someday is the
> extreme example. This isn't quite in that category, but it's closer to that
> than to, say, the gravitational acceleration.
> Here's my real objection -- you're asking for adding a special-purpose
> function to the LSL namespace that returns one value that's unlikely to
> change. Granted, on other platforms like OpenSim, it may well change
> (although as Doug said, it's also baked into our protocols, so it's not
> quite so easily changed as one might think). Designing for every future
> possibility has a name -- overdesign -- and it can be the death of projects
> as people try to keep up with all the things they thought they might need
> someday.
> With that said, though, I think there could be a reasonable middle ground:
> something like llGetWorldConstant(int identifier) where you can look up
> values of certain world constants, like gravity, direction of gravity, size
> of sim, coordinate of the center of the sim, and so forth. We'd want to
> define a namespace for the constants -- similar to the way OpenGL has GL
> constants -- so that developers of compatible platforms could have their own
> specific constants, there could be standard values implemented by all, and a
> place for proposed future standards.
> I would be prepared to support a well-developed proposal for such a
> function (provided it also included a proposal for how to manage the
> namespace of constants). I still don't think I'd support a specific function
> for this particular issue.
>        Q
> On Oct 31, 2008, at 8:15 AM, Argent Stonecutter wrote:
>  Likely or not, a routine that simply returns the vector "<256,256,4096>"
>> right now seems to be a cheap way of making it possible for you to change
>> your mind in the future.
> _______________________________________________
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/SLDev
> Please read the policies before posting to keep unmoderated posting
> privileges
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/sldev/attachments/20081101/7b3ee0d7/attachment.htm

More information about the SLDev mailing list