llRezObjectWithParams() changes properties of no mod objects
tracked
Azuris Fairelander
Using various REZ_FLAG's (and other parameters) in the llRezObjectWithParams-function let's you rez objects without modify-permissions, changing some of their properties in the process.
Despite rezzing no mod objects, you can:
• make them temporary (REZ_FLAG_TEMP)
• make them physical (REZ_FLAG_PHYSICAL)
• make them phantom (REZ_FLAG_PHANTOM)
• have them deleted upon collision (REZ_FLAG_DIE_ON_COLLIDE)
Further changes are possible with some of the other parameters (e. g. REZ_SOUND_COLLIDE).
These flags should silently fail and maybe also give an error message on the debug channel since it allows changes of no mod objects that are not otherwise possible.
Log In
Maestro Linden
tracked
Thunder Rahja
Rider brought this issue up in server user group today. I believe some creators are already relying on llROWP's ability to change some of the properties of objects set to no modify, in lieu of a script in the rezzed object, most notably in weapons and other combat-related scripts.
In most cases, these specific properties you listed seem largely inconsequential to preserving the creator's rights over that object. llROWP doesn't let the owner change the color of a piece of clothing or make a vehicle somehow move faster.
To enforce these properties regardless, a script could be embedded in the concerned object with an
on_rez
event to set its correct properties in the rare case that they should not be changed, or automatically derez if the object was rezzed by another object instead of directly from its owner.Azuris Fairelander
I've talked to a creator who sends out roughly 200'000 no mod/no copy items per day, and while there sure are more serious concerns on their mind (like copy-bots), they very much hope that this behavior is not intended.
Since these REZ_FLAGS persist even when you put the rezzed objects back into your inventory (or an objects inventory), they could still be used for bullets and alike, without a script in the projectiles. If the projectiles need to have certain properties, a creator should be able (and arguably is able) to give them these properties beforehand.
Overall I just think it's not a good idea to create an exception here. "No mod" has a meaning, and having a new(-ish) function that circumvents part of that should only be done with very good reason. (It's hard to tell how it'll come back to bite you in the future, too.) I'm thinking of control events working in no script regions, stuff like that. Since having the flags in question fail for no mod objects doesn't prevent creators from making the projectiles they want, I personally do not see that very good reason here.
Personally I really like that function. Whether this particular aspect of it gets changed or not, it hardly affects me. But I also can't claim to know all the possible implication for the near endless objects and systems that get created in SL...
Maestro Linden
under review
Hi Azuris, thanks for the report. I do see that the phantom/physical/temporary parameters can be _enabled_ on objects by calling llRezObjectWithParams() on no-modify inventory items.
On the other hand, it seems that they can't be disabled; rezzing an object with
REZ_FLAGS, 0
on a temporary/physical/phantom object does not disable those bits.