Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve behavior of Locomotion node in ProtoFlux #955

Closed
Fukuro99 opened this issue Dec 21, 2023 · 4 comments
Closed

Improve behavior of Locomotion node in ProtoFlux #955

Fukuro99 opened this issue Dec 21, 2023 · 4 comments
Labels
already exists The requested functionality already exists in some form enhancement Suggested addition of a new feature.

Comments

@Fukuro99
Copy link

Fukuro99 commented Dec 21, 2023

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

I tried to change Locomotion using ProtoFlux, but was confused because I did not know the module name to enter in the node.
Noclip and teleport can be switched by entering the slot names as they are, but walk and fly cannot be switched by entering the slot names.
This is because the slot names for walk and fly are translated and changed to the names in each language.
Also, custom locomotion modules are also changed by slot name.
This tiggly situation is confusing and leads to unexpected Flux behavior.

Describe the solution you'd like

Change module switching to be specified by slot name.
Or add a node to Flux to get the module name directly.

Flux has a node to get information about the currently used module, but it is not possible to get the module name using this node and is limited to getting the slot name. For this reason, we need to look in the inspector to know the module name.

Describe alternatives you've considered

We can work around this by implementing a link between the slot name and the module name, but it is very difficult to support multiple languages. This can produce unexpected behavior.
For example, a Japanese implementation of Flux may not work properly in a Korean-speaking country. (because the slot names are different in Japanese and Korean)

Additional Context

No response

@Fukuro99 Fukuro99 added the enhancement Suggested addition of a new feature. label Dec 21, 2023
@shiftyscales shiftyscales added the already exists The requested functionality already exists in some form label Jan 9, 2024
@shiftyscales
Copy link
Collaborator

It's not really documented at the moment the wiki (#1) will hopefully be up next week so these sort of things can be documented. But the best way to handle locomotion switching at the moment is to use the locale keys for the locomotion names. https://github.com/Yellow-Dog-Man/Locale

Locomotion.Noclip.Name
Locomotion.Teleport.Name
Locomotion.Fly.Name
Locomotion.WalkRun.Name
Locomotion.WalkRunGripping.Name
Locomotion.ZeroG.Name
Locomotion.GrabWorld.Name
Locomotion.Slide.Name

If you use the locale keys in place of the name, it will ensure that the locomotion nodes will work regardless of locale used, @Fukuro99.

@shiftyscales shiftyscales removed their assignment Jan 9, 2024
@Fukuro99
Copy link
Author

I understand that the locomotion can be switched without any problems by using the locale key.
The problem is that PhotoFlux does not know which locomotion the user is using.
This makes it impossible, for example, to temporarily change the locomotion and then change it back.
I mentioned in another issue that we need a node to get the locomotion module name (independent of locale).

@Fukuro99
Copy link
Author

I eagerly await the arrival of the WIKI!

@shiftyscales
Copy link
Collaborator

I see- #1089 would probably meet your needs then, @Fukuro99. Until then- there are some heuristics you can account for to store the most likely locomotion the user was in, e.g.

Using the Find Character Controller From User node, you can determine if the user is in a physical locomotion (walk, fly, zero-g, etc.)

You can then also check Character Gravity to then determine if the user is in walk (gravity <0) or fly/zero-g (gravity = 0), etc.

It's not a perfect solution, obviously- but generally speaking- tooling that changes locomotion on the user is best reserved for worlds experiences rather than in tooling that can be used in any arbitrary session as you can not guarantee the existence of a given locomotion module in any world that isn't your own. For those cases- you should know exactly what each slot is called (or tagged) and work with that accordingly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
already exists The requested functionality already exists in some form enhancement Suggested addition of a new feature.
Projects
None yet
Development

No branches or pull requests

2 participants