Protect unpacked Flux Nodes like Inspectors are protected

[SilvyPaws]

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

I don't think flux nodes should be grabbable and protected like inspectors are if you're not a builder.

Describe the solution you'd like

Protect unpacked flux nodes like inspectors are protected against non-builders.

Describe alternatives you've considered

N/A

Additional Context

No response

Requesters

SilvyPaws

[shiftyscales]

This will just require that spawned ProtoFlux nodes are properly assigned the Developer tag like other developer interfaces, and should be a quick add. Thank you for submitting this issue. :)

[JackTheFoxOtter]

Instead of assigning the "Developer" tag, it might be good to give them a distinct "ProtoFluxNode" tag instead, and assign that to the permissions component.

The reason for this was that I recall there were requests in the past to tag them distinctly so custom creations (like the RedPrint) can more easily identify them as such.

This would have the same effect (non-builders not able to grab them), but give more utility!

[shiftyscales]

give them a distinct "ProtoFluxNode" tag instead

That would require additional work and increase the scope of the request, @JackTheFoxOtter - as it would require retroactively applying that filter to the permission components across all existing worlds.

Overall your request sounds unrelated to this request- I'd recommend you please open a new issue if you wish for some mechanism that ProtoFlux / user-made tooling can use to identify and manipulate ProtoFlux nodes.

[JackTheFoxOtter]

It's relevant, because slots can only have one tag, and this would prevent a different tag from being used.

Actually I'm pretty sure this would break RedPrint (and potentially other node managing tools), as they explicitly are configured to NOT snap anything tagged "Developer" as to not steal inspectors / node browsers in front of them. I'd make sure to test this first.

[JackTheFoxOtter]

Yes I did quickly check - if you use the "Developer" tag on ProtoFlux nodes this will break every RedPrint in the game, as (new) nodes won't snap to them anymore. Both the current version up to the oldest version I could find in my inventory - this would affect thousands of saved objects and worlds. So you'll kind of have to use a separate tag unless you want to risk that much content breakage.

[Stellanora64]

I also believe just changing the tag to "developer" would break @RyuviTheViali 's grid snapping protoflux tip, although they would need to confirm on that.

[JackTheFoxOtter]

I also think this would probably have to apply to existing ProtoFlux nodes as well, otherwise every "old" piece of code would still be grabbable by non-builders, while "new" code wouldn't, which would create a lot of confusing behavior. (Or at least apply the tag on unpacking)

[ProbablePrime]

Woops, Froox already had this one. ^_^

[5H4D0W-X]

The way it works with inspectors is that the SceneInspector component itself prevents interaction, I don't think the Developer tag actually does anything (deleting SceneInspector removes the restrictions even with the tag in place iirc). So ideally any protoflux node component should just work the same way and it shouldn't break any functionality on custom tools

[SilvyPaws]

If adding a developer tag isn't the solution to this because it can break user content, and for some reason a Flux tag can't be added that does what Developer tag does, i'd suggest a dynamic component that is added to unpacked flux and removed when packed that can protect unpacked Flux. It doesn't have to be retroactively added to already unpacked flux (Though if froox thinks it should, then I wont be apposed).

[ProbablePrime]

We can easily handle this one.

The developer tag is just one tag that is added to grabbable and touchable perms on creation of a new world:

We can easily add additional default tags such as the one present on PF nodes.

However, this is potentially a bug in the existing setup, because PF Visuals are meant to be protected anyway:

Eitherway, I consider this one to be no biggie, that's why I assigned it to myself yesterday, before I noticed Froox had it. I dont want to step on his toes so I'll leave it to him but I'm confident we'll find a fix.

[SilvyPaws]

We can easily handle this one.

The developer tag is just one tag that is added to grabbable and touchable perms on creation of a new world:

We can easily add additional default tags such as the one present on PF nodes.

However, this is potentially a bug in the existing setup, because PF Visuals are meant to be protected anyway:

Eitherway, I consider this one to be no biggie, that's why I assigned it to myself yesterday, before I noticed Froox had it. I dont want to step on his toes so I'll leave it to him but I'm confident we'll find a fix.

I'd like his opinion on this then on what he was planning to do (unless it was to address the bug you mentioned, because I didn't know any of that till you said it haha)

[shiftyscales]

To clarify based on @ProbablePrime's observation above- are you able to interact with the ProtoFlux node in any capacity when you aren't a builder, @SilvyPaws? Or is it specifically just grabbing that's the problem?

As far as I know, "Touchable" would just cover the interaction half of it, @ProbablePrime - and I didn't see explicit confirmation yet the nodes could be directly interacted with in any way other than being grabbed- hence I don't think there's a bug?

[ProbablePrime]

Good catch Shifty.

Grabbable Permissions doesn't have any types in it, so it has different settings to "touch"

[SilvyPaws]

The contents can't be interacted with (i.e a string node's text content), the problem lies with being able to grab and delete them while not being a builder

[JackTheFoxOtter]

The Grabbable component is also on the node's slot itself, not on the visual, and that slot isn't tagged.