[sldev] Sim Size Limits?

SignpostMarv Martin me at signpostmarv.name
Fri Oct 31 10:27:58 PDT 2008


Well I'd imagine the ZERO_VECTOR origin assumption should be baked in as 
long as llGetRegionCorner() in global co-ords always corresponds to 
ZERO_VECTOR in local co-ords.

Otherwise I'd recommend llGetRegionDimensions() return [<x,y,z>,<a,b,c>] 
where a refers to how far away the point of origin is from 
llGetRegionCorner()- if a 512x512 sim had a point of origin in the 
center, so that llGetPos() would return values betwee <-256,-256,0> and 
<256,256,4096>, <a,b,c> would be <128,128,0>. Similar future proofness 
for stacking sims vertically, <0,0,1024|2048|4096|etc.>.

Assuming that there's no issue with dropping lists in as global 
constants, something such as REGION_DIMENSION_CLASSIC would return 
[<256,256,4096>,ZERO_VECTOR], enabling any current script to do a quick 
check of if(llGetRegionDimensions() == REGION_DIMENSION_CLASSIC){ // use 
old code }else {// put new code here, or warn of potential borkage }


~ Marv.

Soft wrote:
> It's an interesting thought and very easy to implement. Is there a JIRA on this?
>
> Also - should the <0,0,0> origin assumption be baked in, or should it
> be min and max sim extents?
>
> On Fri, Oct 31, 2008 at 7:15 AM, Argent Stonecutter
> <secret.argent at gmail.com> 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
>>
>>     
> _______________________________________________
> 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 --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3244 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.secondlife.com/pipermail/sldev/attachments/20081031/e23dcd30/smime.bin


More information about the SLDev mailing list