|
|
|
Linked to other related deficiancies in the ll*PrimitiveParams system.
It is time this code was re-visited and all the missing functionality added. llGet*PrimitiveParams & llSet*PrimitiveParams functions need to support all of the properties for the current prim and for linked prims to be truly usefull functions. They are currently crippled by all the missing prim properties or inability to access all the parametors for the child prims. I wouldn't call it broken, it is working exactly as it was designed. The design on the other hand is stale.
Either this is a bug and is the expected behavior because it is working as designed. I know the design was intentional because I have been petitioning LL for 5 years to get them to add support for this (bringing the necessity of prim torture to an end... but LL, they have no hearts, making us torture poor defenseless prims, oh the humanity), since BEFORE the current iteration of PRIM_TYPE. So I know for a fact they intentionally left it out... I did succeed in getting twist on spheres exposed ^_^. Sigh, back when the world was flat and crashing sims with tortured prims was the sport of kings, of kings; sigh. Or it's a duplicate as there are already at-least TWO features suggestions (currently open) for adding slice support for scripts. Sorry. You could make it a Meta-Issue... "Inequality in script and client build tools" that *might* work. My prefered solution is the one they chose almost 5 years ago when they unleashed SL 1.5. They made an entirely new interface to be used with llSetPrimitiveParams, it was accessible with the integer value 9. The PRIM_TYPE of that time was set to the value 1. With 1.5 they released the new interface and set the changed the value of PRIM_TYPE from 1 to 9. This meant that scripts that were compiled prior to 1.5 were compiled with the value 1 for PRIM_TYPE (the compiler inlines language constants). Anyone who wanted to compile scripts from before 1.5 only needed to change all instances of PRIM_TYPE to the value 1 for the script to run (or change the script to use the new PRIM_TYPE parameters).
So my proposal is to use what is tried and true. Make a new iteration of PRIM_TYPE and retiring the old value. Give it the value 10 or 26 (I think those are available). Keep the parameter lists the same for all the types except add "vector slice" onto the end of PRIM_TYPE_BOX, PRIM_TYPE_CYLINDER and PRIM_TYPE_PRISM. If that is done, I'll make a new special table just for the PRIM_TYPE's. And there will be much celebrating. While we are at it, could we get a constant name for the legacy interface(s)? It makes it hard to refer to them in the documentation. Interface 1 and 9 doesn't sound as good as PRIM_TYPE_LEGACY_1 and PRIM_TYPE_LEGACY_2. It would be nice to be able to read/write all the prim params with a function by that name.
I consider this to be more of a bug than an oversight because moving the slice onto the cube menu makes it a supported setting rather than an unsuported prim torture. Yes we want all the other stuff too, which is why I linked it to other problems with the function, and I encorage everyone to link to any other ones they may know about too. It is time for an overhall! It's been time for an overhaul for a very long time.
This would be cool, but there are many more shapes that can be made in addition to slice.
What would be even more useful is an interface similar to the ObjectShape packet http://wiki.secondlife.com/wiki/ObjectShape That would give LSL access to slice, and would make it trivial for LL to add additional shapes (unsupported, but they already exist). I was "delighted" to find this. WHY are the tools out of synch with the feature set? This is terrible.
Like I said over on MISC-2847:
I think Strife is on the right track, but I'd rather have a new constant than a shifting constant value. After all, that's what 'constant' means. Having to track down bugs that came about because LL changed the constants and their meaning since I last compiled is a cruel trick to play on someone. I suggest PRIM_TYPE_COMPLETE as a new constant. 'Complete' here meant to communicate that all of the possible geometry is returned so that all types have the same number of data items. Note that PRIM_TYPE_TORUS, PRIM_TYPE_TUBE and PRIM_TYPE_RING all have same-sized data structures. PRIM_TYPE_COMPLETE would make all data structures returned have the same size. Even sculpt would return the same number of list items, with only the first two used. We might even consider adding a few reserved slots for future developments. Then legacy code authors, or those worried about memory constraints, could still use PRIM_TYPE. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Open
Major
llGetPrimitiveParams is not returning the new SLICE values 
My personal preference is for a new vector to be added to the end of the list of data returned to scripts. If possible it should only be given to scripts that have been compiled after the change. Adding to the end of the list will not alter the index values for any of the current params.
If altering the number of params returned proves to be a problem, there are several unused values inside the vectors currently returned that could hold the two new float values for SLICE.