OpenXR Action Map loses unsaved changes easily

[lyuma]

Godot version

4.0beta3

System information

Windows 10

Issue description

While editing OpenXR Action Map, I might make a change, like add an action "palm_pose" to the Action Set. If I press Ctrl-S or save the project, the changes do not get written to disk.

Furthermore, if I double-click another action map resource and then click back to the action map, the changes I just made seem to be missing.

There is a special Save button in the top right of the action map editor which seems to work, but its location is not intuitive (inconsistent with other Godot resource editors) and there is no warning when changes are being lost.

Steps to reproduce

1. Open a default Godot project.
2. Create a default action map or use the attached one
3. Create another new default action map (New Resource -> OpenXR Action Map)
4. Click the + button on the action set to add a new action named palm_pose.
5. press ctrl-s to save the project (including all unsaved resources)
6. double-click the new default action map.
7. double-click the original action map we were editing
8. the data was lost.
9. Do the same without saving the project. it still loses data.
10. Do the same and use the Save button in the top right corner. This will work properly.

Minimal reproduction project

put this named as .tres into any project. openxr_action_map.tres.txt

[BastiaanOlij]

Thanks @lyuma , I'll have to see what I can do to fix that, won't have time for it this week but I plan to do some polish up on the action map system soon and will take this along.

[ModularNucleus]

I'm not sure to what extent my issues are directly related to the issue in the OP, but I do think they are at least somewhat related, so I'll add them here. Let me know if they need their own issue.

When editing the default action map, or creating a new one (and saving), some entries do not seem to get added to the .tres file:

E.g. when setting the action type (i assume this is an enum?), all types, except float, get added as "action_type = 0/2/3/4". When setting an action as type float, no entry seems to get added. I would expect "action_type = 1" to be added?

Some bindings do not seem to add the "toplevel_paths" PackedStringArray entry. E.g., in the HPMR profile, binding X, Y and A click adds the entry, but binding the B click (right controller) does not add any entry. I would expect it to enter "toplevel_paths = PackedStringArray("/user/hand/right")"? This also results in the output message: "Action b_button isn't part of an action set!".

I do not know if the pending PR targets these issues.

[BastiaanOlij]

As for the original problem, this should be solved. @lyuma would be good if you could confirm.

As for @ModularNucleus issues. It's logical it is omitting the action type FLOAT. This is the default value and we tent not to save properties set to their default.

I need to look into why the toplevel paths aren't saved, might want to spin this off into its own issue.

[ModularNucleus]

@BastiaanOlij I justed tried with RC5 and I don't think I can reproduce the missing toplevel paths issue there.

Only odd thing I noticed this time (may not be an issue), is that if I delete the default action map and create my own, all controllers have empty bindings except for the trigger binding. This binding cannot be deleted, and will result in the following console error when attempting to delete it:

"modules/openxr/editor/openxr_interaction_profile_editor.cpp:98 - Condition "action.is_null()" is true."

But again, I do not know if this is an issue per se.

[BastiaanOlij]

Hmmm, that looks like their may at some point have been some actions joined to interaction profiles where the action was removed but the link to the interaction profile was not.

I'm actually thinking of changing how this works for 4.1 and just save the action names. Possibly even simplifying the whole storage of action sets. Will need to think about that some more.

[akien-mga]

Can you still reproduce this in 4.0.3 and 4.1-beta3 or later?

[YuriSizov]

So the OP should've been fixed by #68528. Lacking any further confirmation, let's assume that happened. Feel free to comment if the original issue is still reproduceable.