Blocking the new "Physical Fly" is challenging and not watertight

[ProbablePrime]

In some worlds, I don't want physical fly to be a thing. NoClip is for Builders and walking is for users. Examples:

1. Games - Battle Royales, Prop Hunt, Murder
2. Adventure Maps - Innocent's Maze, My Unfinished Vigil Puzzles(:'( one day I'll finish them)

Prior to physical fly existing it was easy to block this by blocking the fully qualified name of "NoClip" "FrooxEngine.FlyLocomotion". Now though, its a little harder.

The only way I could come up with is easily broken:

1. Create a new world using a template
2. Re-configure the permissions to require a tag for physical locomotion(https://youtu.be/sn1iF8zs5P4)
3. Give your owned Physical Locomotion the tag as configured in the permission system

This will prevent other "FrooxEngine.PhysicalLocomotion"'s from being used but it isn't effective, to circumvent this: Add logix to your avatar which:

1. Installs the PhysicalLocomotion you want to use using the "Install" node
2. Scans other locomotion slots which have tags on them
3. Copies those tags to the new locomotion module that was installed.

Done right this could allow Physical Flying in any world. Irrespective of the permissions setup.

Boiled Down: How can I ensure and enforce that users are using the world creators Physical Locomotion, while also allowing their custom avatars.

[Frooxius]

I see, I understand the issue, but it's actually not something new. The Physical Fly is just a preset for the Physical Locomotion, that you could've recreated before it as well (although without the damping it would be a lot harder).

I think the main issue here might be just having ability to install custom locomotion in the first place. It doesn't matter if it's the physical fly, since users could just make another custom configured one that's somewhat different, but still lets you do the same thing.

In those scenarios, is it important to have ability for users to self-install locomotion modules? Easiest solution might be to add a field, which provides a list of locomotion modules that are allowed to be installed in a particular world. Anything not in that list won't be installable.

[ProbablePrime]

Thanks Froox, I understand that its not new its just a lot easier now there's a preset for it :).

Preventing installing in the method you describe sounds suitable.

Can the install node be bypassed though? What happens if I manually(Set Parent Nodes) copy the locomotion modules into the appropriate hierarchy?

[Frooxius]

Ok, I'll see about adding that then! Copying the locomotion module in the hierarchy is insufficient, it needs to be registered with the LocomotionController.

[ukilop]

sorry to poke more holes but, you could also circumvent it by not using locomotion in the first place, logix node: apply character force eg. gearbell's flight logix, or if that gets shut down, could still manipulate user root global position

[ProbablePrime]

I can protect against a lot of those in other methods.

[Frooxius]

@ukilop That's a separate issue, it's not a responsibility of the locomotion system to handle that, that's something that'd be properly handled by parts of the hard permission system, e.g. stripping particular LogiX: https://github.com/Frooxius/NeosPublic/issues/289

[flarn2006]

Just to put it out there, I'm only in favor of limits like this if the session owner can override the world creator's configuration. That is, the limits would be for the session owner to configure, and the world creator would only be setting the defaults.

[Dirko3000]

Just to put it out there, I'm only in favor of limits like this if the session owner can override the world creator's configuration. That is, the limits would be for the session owner to configure, and the world creator would only be setting the defaults.

That logic doesn't hold up for things like puzzle worlds where the creators really don't want anyone going out of bounds or editing anything to cheat, even if they host the session for the puzzle world.

[flarn2006]

If someone wants to ruin the puzzle for themselves, isn't that their choice?

On Wed, Oct 13, 2021, 8:12 AM Sloppy McFloppy @.***> wrote:

Just to put it out there, I'm only in favor of limits like this if the session owner can override the world creator's configuration. That is, the limits would be for the session owner to configure, and the world creator would only be setting the defaults.

That logic doesn't hold up for things like puzzle worlds where the creators really don't want anyone going out of bounds or editing anything, even if they host the session for the puzzle world.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/Neos-Metaverse/NeosPublic/issues/884#issuecomment-942239203, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAFHZUM3CCMZCVMIW76GG5DUGVZUJANCNFSM4P2GEJKQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[Dirko3000]

If someone wants to ruin the puzzle for themselves, isn't that their choice?

When a person or multiple people put weeks or months even into working on a world, with all of the assets and scripting to make everything work perfectly, they should have absolute say on the limits of how it is to be experienced by anyone. It is their world; they own it. As for the puzzle world example, if someone just shows up, and cheats to skip to the end, that's a colossal "F you" to the people who worked hard on everything they intentionally cheated to skipped over. Anyways, not going to waste time spamming up this old github post. When you launch a session, you are, and should be, bound to whatever limitations that the world's creator put in place, as it is still their world; you are merely visiting.

[flarn2006]

How a person experiences something for themselves is none of anyone else's business, because it doesn't affect anyone but the person experiencing it. Art is in the eye of the beholder, after all. Telling people "experience this my way, or not at all" is an even bigger "F you" to anyone whose desired experience isn't the intended one—because not being able to experience what you want actually impacts the person, unlike merely being annoyed that someone is enjoying your work in the "wrong" way, which has no effect on you.

[flarn2006]

An analogy: if you're watching a video on YouTube, and the uploader starts talking about something you aren't interested in, wouldn't you agree that you can and should be able to skip past that part, no matter how much that part means to the uploader? If you're reading a book, shouldn't you and you alone have the freedom to decide which chapters you want to read? Why should it be any different here?

[Dirko3000]

A better example would be the Parkour world (I think by PolyLogix?), where when you reach the end of each course, you are awarded with $KFC, sent from their account to yours, that you keep forever. There is absolutely no circumstance where one should be allowed to cheat that and steal tons of $KFC from their account.

[flarn2006]

That's a major security fail on the creator's part, if movement and world logic is handled in the client. While I agree that stealing from someone else's account is bad, I only consider it a valid argument for this purpose if movement is handled on a non-attacker-controlled server; otherwise, such limits would only strengthen a false sense of security, and perhaps encourage what people won't necessarily realize is bad security practice.

[ProbablePrime]

We prioritize the world creators permissions and control in many maps and that's most likely what we'd do here. As other have said if this is a puzzle or game map and the creator will not allow no-clip then they can disable this.

There are several published maps that benefit from this and need it to continue functioning.

Its the same as some published maps not allowing builder permissions.