|
Christopher Omega
Oxymoron
Join date: 28 Mar 2003
Posts: 1,828
|
10-23-2004 23:32
Hello everyone! When browsing the llGetPrimitiveParams wiki page a few months ago, the metaphorical lightbulb over my head lit up. I posted this comment to the bottom of the page: From: someone Wouldnt a more intuitive implementation return the constants along with the data for that constant? That way, I could pass [PRIM_POSITION, PRIM_SIZE, PRIM_ROTATION] to llGetPrimitiveParams, and get [PRIM_POSITION, <x,y,z>, PRIM_SIZE, <x,y,z>, PRIM_ROTATION, <x, y, z>];? This way, there would be no worry about the number of arguments each constant will return; one can just do an llListFindList(returnedParams, [PRIM_SIZE]) to get the index of the size constant, increment that, and get the index of the size data. A more useful example would be something like llGetPrimitiveParams([PRIM_TYPE, PRIM_ROTATION]); In the current implementation, the script would have to know the number of values llGetPrimitiveParams would pass back to the script for PRIM_TYPE in order to get the return value of PRIM_ROTATION. What if LL ever wants to add more PRIM_TYPE data? It would kill all scripts that rely on their stored constant. Passing back the PRIM_* constants in the return list makes more sence, since then you'd be able to search the return list using llListFindList, and wouldn't have to worry about the number of values passed back for any given PRIM_* constant. Im just wondering why they implemented it the way they did. I hope Im making sence.  Recently observing that it wouldn't be read by many sitting at the bottom of a relitively well-hidden page, I decided to post it here. So what do you think? ==Chris |
|
Moleculor Satyr
Fireflies!
Join date: 5 Jan 2004
Posts: 2,650
|
10-23-2004 23:55
Ok... When it passes back PRIM_POSITION, how do you convert that string to a constant/integer? How do you do it for every single one it passes back? What if, by some fluke (or someone trying to screw with someone's script) they NAME the textures they're using PRIM_TEMP_ON_REZ?
I think the present implimentation would result in fewer foul-ups in rare cases. Basically a bit more sane. Yes, it's a pain to have to call llGetPrimitiveParams for EVERY SINGLE individual value individually, but... *shrug* I can't think of a safe or simple way of doing it with multiple types without running into the need to convert various strings into integers with long if() chains.
|
|
Jake Cellardoor
CHM builder
Join date: 27 Mar 2003
Posts: 528
|
10-24-2004 11:24
If there were a custom type for the PRIM_* constants, then llListFindList(returnedParams, [PRIM_SIZE]) would be unambiguous. But since the constants are just integers, that function call is treated as something like llListFindList(returnedParams, [8]). Is that guaranteed to return the desired result?
|
|
Strife Onizuka
Moonchild
Join date: 3 Mar 2004
Posts: 5,887
|
10-24-2004 16:59
I think it was done to make it harder to clone objects. And to tell the truth they haven't changed the number of attributes each flag has. When they updated PRIM_TYPE to support PRIM_TYPE_RING and the new formats for all the other flags they changed the value of PRIM_TYPE. (and no you can't use llGetPrimitiveParams with the old value  ) untested code :
//This code writen by Strife Onizuka
//Distributed in accordance to the LGPL (GNU Lesser General Public License)
//http://www.gnu.org/copyleft/lesser.html
list types;
list ruletypes;
list shapes=[6,6,6,5,11,11,11,0];
integer SPPAI;
list getPrimitiveParams(list rule)
{
// llSay(0,"---");
if((SPPAI&1)==0) initSPPAI();
integer a;
integer b;
integer c;
integer d;
integer e;
list f=llGetPrimitiveParams(rule);
while(a<llGetListLength(rule))
{
if (d<1)
{
if (llGetListEntryType(rule,a)!=TYPE_INTEGER)
return [a+1000];
b=llList2Integer(rule,a);
c=llListFindList(types,);
if(c==-1)
return [a+2000];
c=llList2Integer(ruletypes,c);
if(c<0)
{
c=llAbs(c);
if(PRIM_TYPE == b)
c+=llList2Integer(shapes, llList2Integer(f,e));
else if(PRIM_TEXTURE == b || PRIM_COLOR == b || PRIM_BUMP_SHINY == b)
d= llGetNumberOfSides() - 1;
else
return [a+3000];
}
++a;
}
else
--d;
if(c>0)
f=llListInsertList(f,,e++);
e+=c;
}
return f;
}
addflag(integer flag, integer rt)
{
integer a=llListFindList(types,[flag]);
if(-1==a)
{
ruletypes+=rt;
types+=flag;
}
else
ruletypes = llListInsertList( llDeleteSubList( ruletypes, a, a ), [rt], a);
}
initSPPAI()
{
//old PRIM_TYPE value not supported //1
addflag(PRIM_MATERIAL,1); //2
addflag(PRIM_PHYSICS,1); //3
addflag(PRIM_TEMP_ON_REZ,1); //4
addflag(PRIM_PHANTOM,1); //5
addflag(PRIM_POSITION,1); //6
addflag(PRIM_SIZE,1); //7
addflag(PRIM_ROTATION,1); //8
addflag(PRIM_TYPE,-1); //9
addflag(PRIM_TEXTURE,-5); //17
addflag(PRIM_COLOR,-3); //18
addflag(PRIM_BUMP_SHINY,-3); //19
SPPAI = SPPAI | 1;
}
_____________________
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
|
|
Christopher Omega
Oxymoron
Join date: 28 Mar 2003
Posts: 1,828
|
10-26-2004 07:57
From: Strife Onizuka it was done to make it harder  If that is the true reason, then shame on LL. They've done enough to make LSL harder to use for LIGITIMATE purposes. |
|
Christopher Omega
Oxymoron
Join date: 28 Mar 2003
Posts: 1,828
|
10-26-2004 08:00
From: Moleculor Satyr Ok... When it passes back PRIM_POSITION, how do you convert that string to a constant/integer? How do you do it for every single one it passes back? What if, by some fluke (or someone trying to screw with someone's script) they NAME the textures they're using PRIM_TEMP_ON_REZ? llListFindList differentiates between integer list elements and string list elements. Are there any integer parameters used in ll*PrimitiveParams? If so, would making PRIM_* constants really big or negative integers make up for it? ==Chris |