Possible restrictions to llGetPrimitiveParams

Hi all =)

So it looks like there are scripts out there which use llGetPrimitiveParams to make permissive copies of (no copy) and (no transfer) objects. This is, of course, not the intended use of this function ^_~.

I am thinking of putting a few restrictions on this function, and was wondering how this would affect you all. How about this: The call fails (probably puts out a warning message) if it is run by a script in an object that is either (no copy) or (no transfer) EXCEPT in the case that the creator of the script matches the creator of the object.

How does this sound to everyone?

Hi

Myself, I don't use llGetPrimitiveParams except in scripts I don't distribute, so it works okay for me.

But won't this be exploitable if you can find an open script that bears a certain person's creator tag? To this day, I still get help requests for scripts I didn't write

What the hell?

Did I not see dozens of people SCREAMING for LL to limit this function in PRECISELY this way back when it was first suggested?

Sounds wondeful, hehe.. I cant think of anything it would hurt.

Don,

A slightly modified version of your suggestion, but have it read from (no modify) instead. The reasoning behind this is, you can copy-by-numbers on a modifiable object, so the scripted equivilent should match.

-Adam

How about this: The call fails (probably puts out a warning message) if it is run by a script in an object that is either (no copy) or (no transfer) EXCEPT in the case that the creator of the script matches the creator of the object and the script is no mod.

I would say this should only effect PRIM_SIZE, PRIM_ROTATION & PRIM_POS for secondary prims in objects.

while on this issue.
could we get some object permission functions?

//
integer llGetObjectPermissions()
integer llGetInventoryPermissions(string InventoryName)
key llRequeestInventoryPermissions(string InventoryName)

these would return a bit feild with the objects permissions of the owner and the next owner. These would allow for the creation of scripts that check there own attributes and act accordingly.

one possible bit feild configuration could be

1. owner mod
   
2. owner copy
   
3. owner transfer
   
4. next owner mod
   
5. next owner copy
   
6. next owner transfer
   
7. share with group
   
8. allow anyone to copy
   

These commands would would create great posabilities for script security and error checking. Imagine a vender telling it's owner that it had incorrectly set the permissions on an item. Or script side enforcement of the GPL.

Sounds good.

I agree with Strife. Don't give us cool functionality, then take it away. Make it fail in situations where it should, like when people mark it with permissions not to allow certain things.

oh i was browsing the wiki and i found the commands i want. Just wish they would be implemented.

llGetObjectPermMask
llSetObjectPermMask
llGetInventoryPermMask
llSetInventoryPermMask

*lights small fire*

I have created a vendor system that would make very very good use of these permission functions, thank you very much.

As far as the getting of prim params goes, I like being able to get the prim params. Rather than closing the ability to get the params by other creators (yeah yeah, quick and easy fix), rather add a permission that turns on or off non-creator getting prim params.

The permission should be gettable and settable in script and in the (Ctrl 3) Edit dialog.

10 out of 10 for asking, but let us have the choice on who we let do what instead of removing what could potentially be a useful/fun feature. Thanks.

If the object is no-modify, you can't put your copy script in it anyway. Moot point.

Sounds good, Don.

All this sounds like PRECISELY the same stuff we all said back when llGetPrimitiveParams was first conceptualized.

I think this is also exploitable, if you can find an open script with the right creator tag.

1) Get a prim-copying script that uses llGetPrimitiveParams.
2) Paste it into Joe Foo's script, so it looks like he wrote it
3) Give the script to your friend, who sets the nomod bits and gives it back to you.
4) Put your new nomod script that looks like it was written by Joe Foo into the prim

It's hard to de-invent the wheel

There might be a few cases where it can be got around, but that shouldn't stop you from doing it anyway.

Heh, I was wondering how long it would take for that to be noticed. Not long, apparently =). Anyways, I just enabled llGetObjectPermMask and llGetInventoryPermMask, so it should be available in 1.6.



Tiger has a point, if it is (no modify) you normally can't inject a script into it anyways. Also, as you say, since you can 'copy-by-numbers' on a modifiable object, putting in these restrictions only really results in making it harder to manually copy an object.



This seems like a good idea. While Francis is right that this can be worked around, I'm only trying to make it less trivial to 'copy-by-numbers'.




I would rather not increase the complexity of object permissions unless it is absolutely needed, and not just because it would take more time to do so. Adding something to the edit window to make it harder to people to duplicate what they can do manually is a misuse of UI real-estate, and may alienate non-scripters.

Thanks for all the input all! Keep it up =)

My only concern with adding these restrictions is that it will make using prim attributes as EEPROM difficult or impossible. While i don't use this in any of my projects, it is something i don't want to see go.

The reason i didn't list PRIM_TEXTURE as a flag for restriction is that you can pilfer textures without the use of a script (but i aint telling). Just going to say it's related to a bug report i sent back in April or May.

While I see the problem this change is intended to fix (namely, the SL-equivalent of script kiddies duplicating no-copy or no-transfer moddable objects) I'm becoming more hesitant about the side-effects of putting in such a restriction.

This won't stop duplication-by-numbers, it will just make it harder. At the same time, it completely prevents some legitimate uses.

So is the shut-down of (admittedly rare) possibilities worth making it a little harder to copy moddable objects?

If you REALLY don't want something to be copied, make it no-mod. You can allow customization through scripts. The only thing a script can't do is resize a linked object as a single unit. That can only be done with the mouse. Add THAT to the UI and give it a script function, and the problem would be solved by EXPANDING out options instead of limiting them.

( And it's probably easier to implement llSetLinkedScale() than it is to make the llGetPrimitiveParams self-break cleanly for certain permission combinations. )

Actually, as a side note to this, I need to set inventory object perms. The only other thing that would make it complete is the ability to rez an item and then suck it back into inventory of the object it was rezzed from. Any chance of that?

*starts pushing his luck*
oh could we also get this too, please
key llGetInventoryCreator(string name)

Sorry for the delayed response.... been busy with the holidays =)

So, I've talked it over with Cory, and we've decided to keep llGetPrimitiveParams as it stands. Thanks again for the input, all!



Hmm sounds useful. I'll see about getting it by 1.6.

I fully endorse this solution!

igh: I wish they gave us llSet/GetLinkPrimitiveParams so we could do something like llSetLinkedScale ourselves

Thank you!

One benefit of this would be the ability for me to sell a notecard that contains keys hidden in MD5 format. When these notecards are dropped onto a scripted object, it would generate an action (give an item, display a texture, etc). Right now, someone could simply duplicate the notecard data making this pointless.

But by using llGetInventoryCreator(string name), I could ensure that only notecards created by me would work in such objects.