New Component: Save Block

[JackTheFoxOtter]

Is your feature request related to a problem? Please describe.

Currently, DuplicateBlock and DestroyBlock exist as transform tagging components and can be used to control wether an object can be duplicated or destroyed manually. There is however no way to prevent manual saving of a grabbable object in the same way.

Describe the solution you'd like

I'd like a new component SaveBlock that when enabled prevents the slot it is on from being manually saved. This should ONLY affect direct manual saving while holding the object, not the world itself being saved, the object being saved as part of another object it's parented under, or saving it through the inspector. It pretty much should just turn off the "save" button in the context menu and inventory, the same way you can't save an object into a folder you don't own. It should probably also prevent exporting the object through the file browser, and bringing the object to another world while holding it. I basically want to prevent the object from being manually removed from the world.

Describe alternatives you've considered

I can't really think of any from the top of my head.

Additional Context

This is NOT a permission / protection / security feature. Some objects break when they are removed from a world in a certain way. An example of this are the items in Cloudscape Harvest, which when saved and spawned out manually will not function properly, as the entity manager in the world doesn't have a reference to them. I would like to suppress the manual save option of those objects for that reason.

Requesters

No response

[TisFoolish]

the object being saved as part of another object it's parented under

This would allow for trivially defeating this in a number of ways.

EG spawning an object with a GrabbableReceiverSurface and save that

Grab the item and use flux that parents anything in your grab spheres to a different object and save that.

Same as above, but instead it parents it to your avatar and you save it.

It'll give users a false sense of security

[JackTheFoxOtter]

This is NOT a security mechanism!

There are plenty of ways to "defeat" this, but that's fine.

[Nytra]

I think the proper way to deal with this would be Hard Permissions #1103

[TisFoolish]

That doesn't change the fact it'll give users a false sense of security. You can't fix that with how you want it implemented

[OfficialXau]

I have an idea that might help - try driving the persistency of the item to an IsNull(User) that's connected to a GetActiveUserSelf.
It's only three nodes and it should make it so the only way you can save the item correctly is through a ReferenceProxy.

[OfficialXau]

Like this, for instance. It seems to work well. ^^

[JackTheFoxOtter]

THIS IS NOT A SECURITY MECHANISM!

The goal is to just disable the ability to save the object in a way that's easy to communicate to the user. I just need something that prevents saving it, preferrably just turning the save button off.

I'm requesting a simple tagging component for any grabbable object to disable the "save" button when the object is held. This isn't any protection mechanism, it doesn't provide any security, it's just so I can say "hey, this is part of the world, you can't save it manually as that would break it".

The problem I want to solve is people saving items from Cloudscape Harvest on their own and then getting sad that they won't work. Making the object non-persistent would not solve that problem, as it would look to the user like they can save the object, but will save an empty record. That's even more confusing to the user!

[JackTheFoxOtter]

Of course it can easily be defeated. But it doesn't matter, that isn't the point. People can also just inspect the object and remove the component. Like... as I said, this isn't for security. It's not intended to be. It's to prevent game objects that depend on a hard reference in a game world from being moved outside of that game world, since they would break. It's also useful for a variety of other grabbing interactions, like sliders and such.

[AmasterAmaster]

Almost like a notification system just to warn the user that things may break when saving said item? (Although it wont stop dedicated users from ignoring the warning and saving anyways >.> people do that sometimes)

[OfficialXau]

I was only applying a solution for saving for the time being, wasn't thinking of outright security. :(
Plus, if I'm being honest... If they're getting sad that the item won't work after saving and bringing it out again, they'll also be sad if they just outright can't save it. If you really want to inform a user that it can't be saved (at least, for the duration of time that we don't have a component like this), I'd suggest for the time being making a context menu item clearly displaying that it shouldn't be saved.

[Foxxboxx]

I think a better option for this, based on what you have described, is to add a new function to the Grabber component. The option would be "Disable save on held" and would be a check box. Then when a user picks it up to save they see the save option is disabled with the text "Item not savable". So they know they can't just save it that way. It won't stop experienced users of course as pointed out. But it would stop new users from going to save it and saving a broken item.

[JackTheFoxOtter]

Almost like a notification system just to warn the user that things may break when saving said item? (Although it wont stop dedicated users from ignoring the warning and saving anyways >.> people do that sometimes)

No, that's just overcomplicating the issue. We already have DestroyBlock and DuplicateBlock, this would be analogous to those. You often have grabbable sub-elements of larger systems, like the sliders on things (for example the cloud home media player), or the items in Cloudscape Harvest. They are not designed to be independant of their parent system, that's why you can specifically tell it to prevent destroying / duplicating them through the grabbable transform component.

Plus, if I'm being honest... If they're getting sad that the item won't work after saving and bringing it out again, they'll also be sad if they just outright can't save it. If you really want to inform a user that it can't be saved (at least, for the duration of time that we don't have a component like this), I'd suggest for the time being making a context menu item clearly displaying that it shouldn't be saved.

Not really. I want to prevent people from accidentally breaking systems. They cannot know that this object is standalone, they don't have knowledge of the system. Right now it's easy for people to accidentally break Cloudscape Harvest by saving items to their inventory and spawning them out again. They cannot know that will break the system, but it will. If they want to save a copy of the game, they need to save a copy of the entire world. (At least until we have a standalone version, but even then I'd like to make the system a bit more robust.)

If someone really wants to save an object they can always equip a dev tool and do so, but that's fine, that's not something I want to restrict whatsoever.

[JackTheFoxOtter]

I think a better option for this, based on what you have described, is to add a new function to the Grabber component. The option would be "Disable save on held" and would be a check box. Then when a user picks it up to save they see the save option is disabled with the text "Item not savable". So they know they can't just save it that way. It won't stop experienced users of course as pointed out. But it would stop new users from going to save it and saving a broken item.

I don't see how this would be a better solution than sticking to the existing pattern of tagging components for interactable transform components (Grabbers, Sliders etc.)

[TisFoolish]

THIS IS NOT A SECURITY MECHANISM!

That still doesn't change the fact it'll give users a false sense of security. It not being a security mechanism isn't important, you're still going to give users a false sense of security. "Save Block" heavily implies to a user that it'll prevent users from saving the item, not that it disables the Save context menu entry.

In other words, the name needs to be different. Something like "Context Menu Save Block"

Not to mention that if in the future there is an actual component to block saving items completely the name of it would butt up against "Save Block"

EG

What the hell is the difference between "save block" and "full save block"

[JackTheFoxOtter]

I mean if your concern is people misunderstanding what the component does, just put a disclaimer on it, like is also on SimpleAvatarProtection or the CharacterController component. I don't really care about what the component is called, but if it's analogous to DuplicateBlock and DestroyBlock then SaveBlock seems logical. It's not like people assume DuplicateBlock makes it impossible to duplicate an object by any means. It's just turning off the manual duplicate functionality through the context menu while holding it. (That's why it's in Transform > Tagging, after all)

[AmasterAmaster]

Not all "blocks" are equal. There are components called MaterialPropertyBlock, which don't in fact block materials, they provide them. It is strange, but here is some information on that: https://wiki.resonite.com/Material_Property_Block

[kulzae]

Not all "blocks" are equal. There are components called MaterialPropertyBlock, which don't in fact block materials, they provide them. It is strange, but here is some information on that: https://wiki.resonite.com/Material_Property_Block

its because block implies like a block of text and not the function of blocking but yes its confusing

I think having a disclaimer on the component is fine. something like this is useful for situations where if someone does save the object it doesn't really matter but is something someone might try doing because there's nothing implying they shouldn't otherwise. yes they can always save it and spawn it via other means but doing so would be doing it intentionally rather than semi unintentionally

[Dusty-Sprinkles]

It's not like people assume DuplicateBlock makes it impossible to duplicate an object by any means. It's just turning off the manual duplicate functionality through the context menu while holding it. (That's why it's in Transform > Tagging, after all)

As someone who did just that for destroyblock the first time I saw it I guarantee these types of components are misunderstood regularly

[ProbablePrime]

The block components are most suited for non-builder interactions, where users cannot just pop open inspectors.

If you're making a game, you'd place Duplicate Block on a Health Pack, to prevent them cheating
You'd put DestroyBlock on vital game objects such as keycards, mission objectives etc.

There could be a way to name this component so that its clearer, but without making that clear I agree it would be confusing. We do have some somewhat generic support to add warnings etc to components but as much as I like those warnings we can't add them everywhere or things will become unwieldy.

[ultrawidegamer]

@JackTheFoxOtter
One way to get the results you're after is to use the GrabValueSet component to turn off persistence when you pick up the item and turn it back on when you let it go. It's a super useful and underutilized component.

[XDelta]

I'll mention another options here for those looking. Being able to save items can be blocked entirely via permissions so say spectator/guests/moderator won't be able to save at all while builder/admin can save. Not as granular as a per item setting but could be used in a game world. The above mentioned GrabValueSet seems to also be a reasonable way to make trying to save the object atleast not work despite showing the option.

As for a slightly better name. GrabbableSaveBlocker or GrabbableSaveBlock could be used similar to the ChildrenSaveBlocker and GrabbableReparentBlock. Including 'Grabbable' in the name I think helps convey what interaction it is actually stopping.

[Frooxius]

I think GrabbableSaveBlock would work okay here, with a disclaimer that it's not a safety feature on the component itself, just a convenience one. We'd also reject any requests to make this component's protections "stronger" if they come up.

The false perception of it being a safety feature is definitely something we want to avoid, but I believe the usecase that has been presented of it avoiding game breakage is a valid one, similar to the DestroyBlock and DuplicateBlock components.

[ProbablePrime]

With @Frooxius 's stipulations, plus a warning text on it. i'll be happy to add the component. I think we're good here. This won't take me long and it is fun. So Its going onto my Fun list.