Old Prims

Prims older than September 2004 have different definitions from modern prims.

When I call:
list flex = llGetPrimitiveParams([PRIM_FLEXIBLE]);
in an old prim I get a flex true no matter what.
Then I call:
llSetPrimitiveParams([PRIM_FLEXIBLE]+flex);
and the prim is set flexible even thoug it was not before the call.

I can't use this to determine if a prim is old or not, it could be a modern prim with flex set true.

Is there a simple, safe way a script can detect if a prim is old or new?

I did run into a case where somebody used a script of mine with an object made of old prims
The script is not designed for old prims

not sure, since it was the PRIM_TYPE flag that was changed, not the constants for the individual PRIM_TYPE_* and I think it'll return the same for either.

.... you could force it into the new version though by setting the prim type to it's already determined type (although this could have the effect of losing some manipulations that were done on the prim, due to newer limits)

Looks like i better start saving my old prims for the historical records...

I haven't tried, but the list returned for the new prim types may be longer than the old, since the old do not have a value for hole shape... or it just may be a similar case to the flexi flag

It looks as if the list is filled even if you get parameters from an old prim.

Lists returned for Old prim:
Prim Type: [0, 0, <0.0, 1.0, 0.0>, 0.0, <0.0, 0.0, 0.0>, <0.65, 1.0, 0.0>, <-0.15, 0.0, 0.0>]
for New prim:
Prim Type: [0, 0, <0.0, 1.0, 0.0>, 0.0, <0.0, 0.0, 0.0>, <0.65, 1.0, 0.0>, <-0.15, 0.0, 0.0>]

Lists for Flexible, Old prim:
Prim Flexible: [1, 0, 0.0, 0.0, 0.0, 0.0, <0.0, 0.0, 0.0>]
and New prim:
Prim Flexible: [0, 2, 0.3, 2.0, 0.0, 1.0, <0.0, 0.0, 0.0>]

does it differ if you use the old prim_type constant (1) instead of the new (9) in the get call?

When I do that I get an empty list for an old and for a modern prim
So that does not open a way for detection.
The problem is not huge since old prims are few and nobody make them anymore
I would have liked a detection though, so my script could tell the user when it was used in an old prim.
Now I just have to make a note and tell my customers about it when they run into the problem.

shame, although forcing it is workable for some scenarios... fwiw, people do still use/make old prims when in some torturing schemes.

*hums the song "Old Friends" by Simon & Garfunkel*

Void, the old PRIM_TYPE value (1) cannot be used in llGetPrimitiveParams.

I've always had the impression that they gutted the old PRIM_TYPE and it just reroutes the call through the new PRIM_TYPE.

Check to see if the object is phantom too. You aren't supposed to be able to have phantom off and flexible on at the same time.

You may want to check the nature of some of the PRIM_* status flags: PRIM_PHYSICS, PRIM_TEMP_ON_REZ, PRIM_PHANTOM. In the dark ages it was possible to store full integer values in these boolean fields. They may have changed this. I do recall there being some durability issues with using this across sim boarders.

wasn't sure it'd work, and didn't have time to get inworld and check, figured it was worth a shot.

PS Can you imagine us years from today.... damn you I have that song in my head now

Hi

If the creator of the object is younger than sep 2004 the object cannot be old.

Of cause some old ones still create objects fortunately so you cannot tell the other way around.

-- Boreal

not really going to work since scripting calls could change a prim to the old type after that change

And Copy Bots and some scripts can make copies with the owners name as the creator
Even if no old prims were made after a certain date the only test that could be made were:
if ( creator born after date ) llOwnerSay("Hurray! this is a new prim";
else llOwnerSay("This prim is old or it is new, I don't know";
I still miss a testable feature that is on the one and not on the other.

Men tak for buddet

I guess one could make the argument that we need a new function... llPrimCreationDate() ???

I'm wondering why one would need to know this information besides curiosity.

Any script that manipulates prim attributes 'would like to know'

A script made for a new prim type, may fail when used in an old prim type and vice versa.

that the problem, even after they could be made directly, the could be created as new type, and changed to old type.... date really isn't going to solve anything