Add REZ_REMOTE_SCRIPT_ACCESS_PIN to llRezObjectWithParams
tracked
Jasdac Stockholm
Basically it does the same as putting a script with llSetRemoteScriptAccessPin in the object's on_rez
Right now if you have a project that relies on updating scripts of rezzed objects, you'll need to make a script that sets the pin and requests an update via the llSay system. This makes said script a major failure point because llSay has a tendency of being dropped during lag spikes, forcing you to set up a syn/ack system. And if you later discover that your syn/ack system wasn't as robust as you thought, or want to change it in any way, you may potentially have hundreds of items that you need to manually rework.
Being able to set the remote script access pin directly on rez would eliminate the need for a syn/ack system entirely. Because you could:
- Rez object with pin
- Remote load the script(s) immediately in object_rez
- Profit!
Another added benefit of this system is that you could rez the object without the scripts that you intend to overwrite with remote loading, saving time rezzing the object.
Log In
Jasdac Stockholm
Getting back to this because we're about to get the ability to pass strings on rez, which would make spawners a lot easier to make. Basically to make a robust and flexible spawner system today, it may look something like.
- Spawner receives a message that it should spawn a monster. The message includes position, rotation, and metadata such as HP.
- Spawner stores the data in LSD and rezzes the monster within 10M of the spawner, assigning a unique ID that it can pass as the on_rez param.
- The monster has a script that handles updates, this script needs to be updated remotely, so it asks the spawner for a new version of the script. This bit is crucial, because listener messages are often dropped. A lot of programmers may not realize this, and assume that simply sending a request to the spawner will work. However, if you don't make a redundancy system where the initial monster script keeps asking the spawner over and over until it receives said script, you may have to go back and recompile hundreds if not thousands of scripts down the line. This is a MAJOR pitfall that I'm hoping REZ_REMOTE_SCRIPT_ACCESS_PIN will solve.
- Once the script is received, it uses the original rez ID to request the metadata from the spawner. This also requires a redundancy system, where it keeps requesting every now and then since listeners may be dropped. It needs a time-out in case something unforeseen happens with the spawner.
- The spawner starts sending the metadata every now and then with another redundancy system since we can't assume that the message is received. The system needs a time-out in case something unforeseen happens to the object.
- The monster sends an ACK whenever it receives the metadata. And can then set position, rotation, and HP etc based on the metadata.
- The spawner removes the spawn from LSD and the spawn is finally complete.
There's a TON of redundant code in this that's solved by being able to set a remote script access pin and send the metadata directly on rez. Assuming we have both the ability to pass strings (which we will soon), a spawner could look like this:
- Spawner receives a message that it should spawn a monster. The message includes position, rotation, and metadata such as HP.
- The spawner rezzes the object within 10M of the spawner, passing along the metadata and setting a remote load pin.
- In object_rez, the spawner remote loads the monster script since we already know the pin.
- Done.
Spidey Linden
tracked
Issue tracked. We have no estimate when it may be implemented. Please see future updates here.
Extrude Ragu
It would need a special rule to handle no-mod objects.
Rezzing a no-mod object with a remote script pin would allow the owner to modify an object they do not have permission to modify, breaking the permissions system.
I propose if this is implemented, that it only works if the owner has permission to modify the object, to avoid breaking core promises of the permissions system.
Jasdac Stockholm
Extrude Ragu: llRemoteLoadScriptPin only works if the script owner can modify target.
Extrude Ragu
Jasdac Stockholm: Ah, yes you are right. Although, makes me wonder about the case the object already has a script pin..
Jasdac Stockholm
Extrude Ragu: You could manually drop a script into the object and do the same thing. This is basically just allowing the user to do the same thing with a rezzer instead of by hand.
Journey Bunny
This seems to walk a tricky line for the sake of saving oneself time fixing a mistake; there might be better reasons. If the rezzable prims were designed from day 1 with a remote pin, then that is the system the customer bought; if not, then not and this feature would break those expectations.
Currently, the ability to overwrite or load new scripts within an object is granted by the object that would be altered by the change. With this alteration, any rezzer object would be able to inject this overwrite behavior into an object that had not originally been designed to have it.
Plenty of reasons it's desirable; it's a new power. At present, no object can change the scripts inside a "child" object inside its own inventory without that object having been explicitly set up to work like that, and this would permit all kinds of "forced update" systems.
I can also see an undesirable component, and a simple one: if this power was needed, then objects should have been set up with a script pin. If they were not, then it should be expected that these objects cannot have their scripts manipulated externally. Adding a backdoor to turn on that power in things that haven't had it will produce unintended behaviors.
In the use case described, I understand it could be a huge amount of work to go through and add script pins to all past products that should have had it but this seems like an issue that is separate from the larger question of whether the new powers are worth the new implications. I do like the things I could do with this, but wanted to put a voice to the concern too.
Jasdac Stockholm
Journey Bunny: Would a simple workaround of ignoring said param on no-mod items suffice? That's the only way I can think of this being exploited, and I assume that's what you mean?
I'm curious how the llRezObjectWithParams deals with REZ_FLAGS, since you'd technically be able to set alter phys/phantom settings on a no mod item.
Talia Tokugawa
Journey Bunny
Having rezzed an object from within its inventory how does that object get the rezzed object back into its inventory. You would be able to get the contents of the item back but you couldn't get the item itself back in the items inventory.
I would love to see this implemented, My primary use case would be in unpacking shopping, just my initial "to be opened" folder has over 2k items in it, I would be insanely happy to be able to make an unpacking device that would sequentially check perms on an item, if copy rez item, send unpacker script click accept, I have an entire modular "Ms Automate" style sorting system that got put on the back burner when I realised do exactly this to get the stuff out the initial boxes.
How about... As you wouldn't want to break any pre-existing update systems, if you were to only check for a script pin after the on_rez if a script pin is set during the on_rez then Script pin could only be set by the creator of the item?
Another potential idea... setting -1 as the script pin would enforce a state where you would not be allowed to change the script pin and sending scripts to the item would fail.