|
cutflower Oh
Gardener
Join date: 5 Apr 2007
Posts: 46
|
06-17-2009 17:08
anyone know if theres any info anywhere on the new slice function for prim paramaters?
|
|
Void Singer
Int vSelf = Sing(void);
Join date: 24 Sep 2005
Posts: 6,973
|
06-17-2009 23:24
there's a new function within lsl? that'd be new... giving us the function with an inworld editor change at the same time... normally it takes 6mos or so to get script access added for new inworld function (like glow)
_____________________
| | . "Cat-Like Typing Detected" | . This post may contain errors in logic, spelling, and | . grammar known to the SL populace to cause confusion | | - Please Use PHP tags when posting scripts/code, Thanks. | - Can't See PHP or URL Tags Correctly? Check Out This Link... | - 
|
|
Strife Onizuka
Moonchild
Join date: 3 Mar 2004
Posts: 5,887
|
06-20-2009 22:01
And the script access for this one is controversial. The three suggestions on the floor are:
* Release a new PRIM_TYPE (change the value of the constant; give the PRIM_TYPE_* flags their new parameters and) and make the old interface deprecated (done once before).
* Release new PRIM_TYPE_* flags with the new parameters
* Release new PRIM_SLICE flag
IMHO the first suggestion is the best. It's the cleanest.
Once upon a time PRIM_TYPE and it's PRIM_TYPE_* flags were very limited. Prims at that time couldn't do much. With the release of SL 1.5, they added a new prim type and expanded the prim attributes. Instead of just updating the PRIM_TYPE_* constants and breaking old code, they implemented an entirely new constant, CHANGED the value of the PRIM_TYPE constant to point to that new interface and kept the old interface. This meant that code already compiled would continue to use the old interface, code newly compiled would use the new interface unless the scripter inlined the value for the old interface. The change over was remarkably painless.
The first suggestion is to do the same thing again, create a new interface and reassign the PRIM_TYPE constant to point to it.
The problem with the second suggestion is that it complicates the internal handling of prim types, you either have two prim constants that create the same type of prim, or you have an ambiguity when it comes to llGetPrimitiveParams.
The problem with the third suggestion is that it disconnects the slice from the rest of the shape of the prim. It's conceptually ugly. Either split out all parameters or none at all.
_____________________
Truth is a river that is always splitting up into arms that reunite. Islanded between the arms, the inhabitants argue for a lifetime as to which is the main river.
- Cyril Connolly
Without the political will to find common ground, the continual friction of tactic and counter tactic, only creates suspicion and hatred and vengeance, and perpetuates the cycle of violence.
- James Nachtwey
|
|
Void Singer
Int vSelf = Sing(void);
Join date: 24 Sep 2005
Posts: 6,973
|
06-21-2009 00:38
From: Strife Onizuka Either split out all parameters or none at all. I kinda wish they'd do that... it'd free up lots of processing for things like a multi set of a single flex, light, or type properties without requiring you to set all of them (,aking it useless in cases where you might have other different properties in the same set of prims) on the other hand I see people throwing a fit because it makes their lists bigger...
_____________________
| | . "Cat-Like Typing Detected" | . This post may contain errors in logic, spelling, and | . grammar known to the SL populace to cause confusion | | - Please Use PHP tags when posting scripts/code, Thanks. | - Can't See PHP or URL Tags Correctly? Check Out This Link... | -
|