The verb should be last, so "action_set_create". I know this isn't what existing code in this file does (I usually prefer the verb first), it doesn't follow our convention. Better to follow it for new code though.

).

I would really prefer keeping this more dynamic, so that we don't have to hardcode how many controllers are available. But also, can you receive the same data via get_action_state()/get_pose_action_state()?

To avoid the harcoded controller count this just be a function. Maybe controller_state_get("location", 0), or controller_location_get(0). Or actually, wouldn't it be better to keep this more general, allowing you to pass the action name or such? But then we basically get get_action_state() again, so I'm a bit unsure too.

Multiple return values are supported with RNA_def_function_output(). In Python they can be received as tuple then. So this could return a (location, rotation) tuple.

Avoid the "=" here, it reads weird. Could just be: "Optional OpenXR user path. If not set, the action will be applied to all paths"

Same here, avoid the "=". E.g.: "Haptic duration in seconds, whereby 0 is the minimum supported duration"

Avoid "=".

Avoid "=".

Can use LISTBASE_FOREACH_MUTABLE() here (just continue for non-matching items).

Renamed to GHOST_XrGetCustomdataArray().

Removed cleanups.

Using SubactionIndexMap.

Moved action maps to wmXrRuntimeData.

The flags were merged into a single bit field for convenience, but they are now split into separate flags (eXrOpFlag, eXrActionFlag, eXrAxisFlag, eXrHapticFlag).

Although the action maps are not stored in files, I believe the DNA declaration here is necessary for the RNA functions, which interface with the XrActionMap collection/ListBase (see rna_def_xr_actionmap()/rna_def_xr_actionmap_items() in rna_xr.c).

If there's another solution though, please let me know.

Same as above (declaration needed for RNA).

Removed forward declared functions.

Will revert this change here (unintentionally changed during rebase).

Refactored this to take in an XrActionMap struct pointer instead of individual parameters. This way, all the necessary actions/action spaces/bindings can be created with a simple Python function call. The XrActionMap should already be set up correctly after loading from the Python script.

Improved descriptions.

Renamed description.

Renamed properties to avoid using the term "flag".

Removed unnecessary descriptions.

Standardized ranges based on D9771.

Renamed functions to keep verb last.

Oops, missed this.
It will be changed to "Apply haptics to the same user paths for the haptic action and this action".

Missed this one too...

The "default frequency" was actually referring to the default haptic frequency of the OpenXR runtime, not the property's default value, but this was unclear.

Will be changed to "Frequency of the haptic vibration in hertz. 0.0 specifies the OpenXR runtime's default frequency".

Replaced hardcoded controller accessors with controller_location/rotation_get() functions.

Controller pose actions get special treatment in that they need to convert the "raw pose"/action state returned by the runtime into one that takes into account eye offsets, base pose, navigation, etc.

At this point, I think we can assume that all poses will be controller poses, so for the time being I removed get_pose_action_state() since it wasn't very useful by itself.

I could be mistaken, but I don't think I can use BLI_findstring() since the ListBase stores LinkData, not wmXrAction. So the "offset" parameter used for BLI_findstring() doesn't work.

Could make wmXrAction into a link-able struct, but it's actually stored in a C++ container in GHOST so I didn't want to cause confusion.

Actions are guaranteed to be unique though.

Using LISTBASE_FOREACH_MUTABLE().

Removed unused function.

Issue is that this still will unnecessarily add the structs to SDNA. So the struct information will still be written to files, just no data for it.

If you want to avoid that like I said, you'd have to remove the RNA_def_struct_sdna() calls and do all the DNA struct access manually through callbacks. This would create a lot of boilerplate code in this case, so I'm not sure if that is a better alternative really. Checking with other devs.

This function is super long. IMO logic in RNA callbacks should be minimal. If more advanced stuff is needed that should go to a dedicated module. So I'd suggest putting this to WM-XR. Even then I'd suggest splitting it in a few functions.

It confuses me a bit that a float input is represented as "button". A "button" to me usually has an on/off state only. Generally I'd prefer to keep the same name for RNA identifiers as we do internally, so "FLOAT" in this case. Any reason for not doing that? (Same for the other identifiers.)

Should be "location and rotation". A / usually implies "or".

Why not call this "VIRBRATION"? Makes it more direct and clear.

You're right, in that case this is fine. One more reason to switch all this code to C++, which we should probably do rather sooner than later.

I read some of the discussion on #blender-coders. Was adding the struct to SDNA the preferred option?

Ok, makes sense. I split the function into separates ones again to reduce complexity (action_set_create()/action_create()/action_binding_create()).

Now using same action type identifiers for RNA as internally. There wasn't a particular reason for doing otherwise.

You're right that it is used as an "active index" internally, however I didn't want to cause confusion since "active" has another meaning with respect to action maps ("active" means that the action map is the one currently used for the VR session).

This is similar to the landmarks in the Python add-on, where there is both a selected landmark (to which UI edits are applied) and an active landmark (the one used for the VR session): https://docs.blender.org/manual/en/2.83/addons/3d_view/vr_scene_inspection.html?highlight=virtual%20reality