OpenXR: Add support for binding modifiers #97140

BastiaanOlij · 2024-09-18T10:15:19Z

Adds support for OpenXR binding modifiers to the action map.

This allows you to add modifiers to inputs such as applying thresholds or offsetting values, etc.
Binding modifiers can add additional input paths or change the type of an input path.

Todos:

Create infrastructure for binding extension system to the action map
Make UI changes to the action map UI
Implement support for haptic triggers
Implement analog threshold extension (may move this into vendor plugin)
- implement resource class
- implement UI
Implement dpad binding extension
- implement resource class
- implement UI

Depends on:

There is now a demo for this project that can be found here:
godotengine/godot-demo-projects#1137

Some improvements that can be done (possibly in follow up PRs):

Should show our modifier button icon in a different color if there are modifiers defined.
Should find a way to limit the modifiers you can create to those that are applicable.

Contributed by Khronos Group through the Godot Integration Project

BastiaanOlij · 2024-10-14T03:22:14Z

Back working on this after dealing with a bout of the flu. Starting to get an interface together but need to change direction slightly.

BastiaanOlij · 2024-10-14T23:22:47Z

While some of this is a bit of an unknown (but likely) future, I changed our action map structure slightly so we can record binding modifiers both on interaction profiles and on individual bindings.

Right now the dpad modifier is a bit of the odd duckling being the only modifier that is linked to an action set/source path combination and is thus recorded on the interaction profile level.
The analog threshold modifier is linked to an action/source path combo which is recorded as a binding (hence the changes in #98163) and it is very likely that this is going to be true for future modifiers as well.

Right now they are all added to the next chain or XrInteractionProfileSuggestedBinding when calling xrSuggestInteractionProfileBindings however this may change/be enhanced in the future.

BastiaanOlij · 2024-10-15T07:17:17Z

UI is finally coming together. Binding modifiers are accessible either on the interaction profile (1) or for individual bindings (2):

Either button opens up a popup that allows for creating applicable binding modifiers on that level:

I still need to change the dialog for selecting a new binding modifier as it doesn't filter by type, and we only have the two modifiers right now but that will change in the near future.

BastiaanOlij · 2024-10-18T05:32:51Z

Some interesting feedback concerning the DPad modifier extension that we need to ensure gets documented well.

The extension actually does two things when enabled.

It adds new binding paths you can use for each thumbstick and thumbpad input. These paths are immediately usable even if you do not add a dpad binding modifier
And it adds the dpad binding modifier, which lets you customise the dpad behaviour

BastiaanOlij · 2024-10-20T11:47:43Z

All the new paths have been added to the meta data database. In doing this I've cleaned up a lot of the code to make it easier to manage. Still planning on adding a bit of extra logic in the UI when editing the action map so we only show bindings that are available based on which extensions have been selected in project settings so we don't get a whole bunch the user isn't using.

BastiaanOlij · 2024-10-21T07:48:08Z

Other then needing to do some more testing, this should now all work.

My only remaining issue is that I had to use the EditorInspector class to make the property editors work properly but these introduce the resource section into the UI and I haven't found a way to supress this:

These sections make no sense in this context so I hope there is a way to remove them.

BastiaanOlij · 2024-10-21T08:10:23Z

One more extra thing, this PR also introduces the OpenXRHapticBase base class and OpenXRHapticVibration class, currently only used for the new features in the action map. There are a number of vendor specific implementations of the haptic feedback OpenXR struct that forms the base of this implementation that are also used for triggering haptic feedback pulses from code.

I'm thinking of replacing OpenXRAPI::trigger_haptic_pulse with a version that takes an OpenXRHapticBase object as a parameter and we'll be able to perform different haptic effects as they are added to the OpenXR spec generically.
This is something we'll do in a separate PR however.

fire · 2024-10-21T08:27:08Z

Maybe you can figure out why the tests fail.


editor/editor_inspector.cpp:4098:57: runtime error: member access within null pointer of type 'struct EditorFeatureProfileManager'
editor/editor_inspector.cpp:4098:154: runtime error: member access within null pointer of type 'struct Node'

================================================================
handle_crash: Program crashed with signal 11
Engine version: Godot Engine v4.4.dev.gh-97140 (b26897c0a0f76a2c8ee1f48419e975911b95d691)
Dumping the backtrace. Please include this when reporting the bug to the project developer.
[1] ./bin/godot.linuxbsd.editor.dev.double.x86_64.san(+0x380b26f7) [0x55bd781cc6f7] (??:?)
[2] /lib/x86_64-linux-gnu/libc.so.6(+0x43090) [0x7fc58e828090] (??:0)
[3] EditorInspector::_notification(int) (??:?)
[4] EditorInspector::_notificationv(int, bool) (??:?)
[5] Object::notification(int, bool) (??:?)
[6] Node::_propagate_ready() (??:?)
[7] Node::_propagate_ready() (??:?)
[8] Node::_propagate_ready() (??:?)
[9] Node::_set_tree(SceneTree*) (??:?)
[10] Node::_add_child_nocheck(Node*, StringName const&, Node::InternalMode) (??:?)
[11] Node::add_child(Node*, bool, Node::InternalMode) (??:?)
[12] void call_with_variant_args_helper<__UnexistingClass, Node*, bool, Node::InternalMode, 0ul, 1ul, 2ul>(__UnexistingClass*, void (__UnexistingClass::*)(Node*, bool, Node::InternalMode), Variant const**, Callable::CallError&, IndexSequence<0ul, 1ul, 2ul>) (??:?)
[13] void call_with_variant_args_dv<__UnexistingClass, Node*, bool, Node::InternalMode>(__UnexistingClass*, void (__UnexistingClass::*)(Node*, bool, Node::InternalMode), Variant const**, int, Callable::CallError&, Vector<Variant> const&) (??:?)
[14] MethodBindT<Node*, bool, Node::InternalMode>::call(Object*, Variant const**, int, Callable::CallError&) const (??:?)
[15] GDScriptFunction::call(GDScriptInstance*, Variant const**, int, Callable::CallError&, GDScriptFunction::CallState*) (??:?)
[16] GDScriptInstance::callp(StringName const&, Variant const**, int, Callable::CallError&) (??:?)
[17] Object::callp(StringName const&, Variant const**, int, Callable::CallError&) (??:?)
[18] Variant::callp(StringName const&, Variant const**, int, Variant&, Callable::CallError&) (??:?)
[19] GDScriptFunction::call(GDScriptInstance*, Variant const**, int, Callable::CallError&, GDScriptFunction::CallState*) (??:?)
[20] GDScriptInstance::callp(StringName const&, Variant const**, int, Callable::CallError&) (??:?)
[21] Node::_gdvirtual__ready_call() (??:?)
[22] Node::_notification(int) (??:?)
[23] Node::_notificationv(int, bool) (??:?)
[24] Object::notification(int, bool) (??:?)
[25] Node::_propagate_ready() (??:?)
[26] Node::_set_tree(SceneTree*) (??:?)
[27] Node::_add_child_nocheck(Node*, StringName const&, Node::InternalMode) (??:?)
[28] Node::add_child(Node*, bool, Node::InternalMode) (??:?)
[29] void call_with_variant_args_helper<__UnexistingClass, Node*, bool, Node::InternalMode, 0ul, 1ul, 2ul>(__UnexistingClass*, void (__UnexistingClass::*)(Node*, bool, Node::InternalMode), Variant const**, Callable::CallError&, IndexSequence<0ul, 1ul, 2ul>) (??:?)
[30] void call_with_variant_args_dv<__UnexistingClass, Node*, bool, Node::InternalMode>(__UnexistingClass*, void (__UnexistingClass::*)(Node*, bool, Node::InternalMode), Variant const**, int, Callable::CallError&, Vector<Variant> const&) (??:?)
[31] MethodBindT<Node*, bool, Node::InternalMode>::call(Object*, Variant const**, int, Callable::CallError&) const (??:?)
[32] GDScriptFunction::call(GDScriptInstance*, Variant const**, int, Callable::CallError&, GDScriptFunction::CallState*) (??:?)
[33] GDScriptInstance::callp(StringName const&, Variant const**, int, Callable::CallError&) (??:?)
[34] Node::_gdvirtual__process_call(double) (??:?)
[35] Node::_notification(int) (??:?)
[36] Node::_notificationv(int, bool) (??:?)
[37] CanvasItem::_notificationv(int, bool) (??:?)
[38] Control::_notificationv(int, bool) (??:?)
[39] Object::notification(int, bool) (??:?)
[40] SceneTree::_process_group(SceneTree::ProcessGroup*, bool) (??:?)
[41] SceneTree::_process(bool) (??:?)
[42] SceneTree::process(double) (??:?)
[43] Main::iteration() (??:?)
[44] OS_LinuxBSD::run() (??:?)
[45] ./bin/godot.linuxbsd.editor.dev.double.x86_64.san(main+0x4a3) [0x55bd781cbf9c] (??:?)
[46] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf3) [0x7fc58e809083] (??:0)
[47] ./bin/godot.linuxbsd.editor.dev.double.x86_64.san(_start+0x2e) [0x55bd781cba3e] (??:?)
-- END OF BACKTRACE --

BastiaanOlij · 2024-10-21T23:34:16Z

Maybe you can figure out why the tests fail.

Looks like a failure to check for NULL parameters with standard unit tests. Sadly on a part of the API that is completely unrelated to this work, so I don't know why it's suddenly failing.

BastiaanOlij · 2024-10-21T23:39:25Z

Hmm I wonder, the line of code that fails is EditorFeatureProfileManager::get_singleton()->connect("current_feature_profile_changed", callable_mp(this, &EditorInspector::_feature_profile_changed));
I'm guessing the testing doesn't setup the editor classes so possibly me using the EditorInspector in classes that are exposed as they are designed to be subclassed in the vendors plugin.

dsnopek

Thanks!

This PR is epic in size, but it looks great! All my code review comments are very nitpick-y things.

I tested the new editor stuff, and it all seemed to work fine. I didn't attempt to test it functionally - I see that SteamVR and Monado reportedly support it, so I may attempt to give it a try later.

Since PR #98163 has been merged, this should be rebased. That'll make reviewing a tiny bit easier.

modules/openxr/action_map/openxr_action_map.cpp

modules/openxr/action_map/openxr_interaction_profile.cpp

modules/openxr/action_map/openxr_interaction_profile.h

modules/openxr/doc_classes/OpenXRAnalogThresholdModifier.xml

modules/openxr/doc_classes/OpenXRDpadBindingModifier.xml

modules/openxr/editor/openxr_binding_modifier_editor.cpp

BastiaanOlij · 2024-10-30T21:53:48Z

editor/editor_inspector.cpp

@@ -4095,6 +4095,7 @@ void EditorInspector::_notification(int p_what) {
 		} break;

 		case NOTIFICATION_READY: {
+			ERR_FAIL_NULL(EditorFeatureProfileManager::get_singleton());


Now that CI testing runs through this, and we're not fully setting up the editor, we need to exit here as the EditorFeatureProfileManager singleton does not get constructed.

doc/classes/ProjectSettings.xml

m4gr3d · 2024-10-31T13:27:51Z

modules/openxr/action_map/openxr_action_map.cpp

@@ -156,6 +175,10 @@ void OpenXRActionMap::remove_interaction_profile(Ref<OpenXRInteractionProfile> p
 	int idx = interaction_profiles.find(p_interaction_profile);
 	if (idx != -1) {
 		interaction_profiles.remove_at(idx);
+
+		ERR_FAIL_COND_MSG(p_interaction_profile->action_map != this, "Removing interaction profile that belongs to this action map but had incorrect action map pointer."); // this should never happen!
+		p_interaction_profile->action_map = nullptr;


Do you need to call p_interaction_profile->action_map->remove_interaction_profile(p_interaction_profile) before you reset the action_map?

No, the design is that an interaction profile always belongs to a single action map. The action_map member is only null momentarily in 2 conditions:

when we're creating a new interaction profile right before it's added to an action map

when we're destructing an interaction profile where it's remove from the action map just before.

The check to see if the actionmap pointer is different is just to catch errors in usage, someone who later on adds code that would attempt to add an interaction profile to multiple action maps, and these checks just erroring out.

m4gr3d · 2024-10-31T13:33:50Z

modules/openxr/action_map/openxr_interaction_profile.cpp

+Array OpenXRIPBinding::get_binding_modifiers() const {
+	Array ret;
+	for (const Ref<OpenXRBindingModifier> &binding_modifier : binding_modifiers) {
+		ret.push_back(binding_modifier);
+	}
+	return ret;
+}


Why not directly returning the binding_modifiers?

Because we're converting from a Vector<Ref<OpenXRBindingModifier>> to an Array. I don't think there is an implicit conversion or was that added at some time?

m4gr3d · 2024-10-31T13:35:14Z

modules/openxr/action_map/openxr_interaction_profile.cpp

+		binding_modifiers.remove_at(idx);
+
+		ERR_FAIL_COND_MSG(p_binding_modifier->ip_binding != this, "Removing binding modifier that belongs to this binding but had incorrect binding pointer."); // this should never happen!
+		p_binding_modifier->ip_binding = nullptr;


Similar comment; should p_binding_modifier be removed from ip_binding before resetting it?

m4gr3d · 2024-10-31T15:06:01Z

modules/openxr/doc_classes/OpenXRBindingModifier.xml

+				Return [code]false[/code] if binding modifiers of this type are recorded on an interaction profile.
+				Return [code]true[/code] if binding modifiers of this type are recorded on bindings within an interaction profile.


The description is a bit confusing.

Basically there are two types of binding modifiers, those recorded on the interaction profile, and those recorded against a specific binding on the interaction profile. This flag simply indicates which type we're dealing with.
This really won't get a lot cleared until more binding modifiers become public.

m4gr3d · 2024-10-31T15:09:07Z

modules/openxr/doc_classes/OpenXRDpadBindingModifier.xml

+			If [code]false[/code], when the joystick enters a new dpad zone this becomes true.
+			If [code]true[/code], when the joystick remains in active dpad zone, this remains true even if we overlap with another zone.


Also hard to understand what this field is for at first read.

I had real difficulty describing this in text, you really need to look at the diagrams in the API spec and even there the description is overly technical.

Are those diagrams publicly available? Can you link to them in this description?

If you scroll to the top of the help page you'll notice that on both modifiers, I link to the specification for the modifiers.

For the DPad modifier its this one: https://registry.khronos.org/OpenXR/specs/1.1/html/xrspec.html#XR_EXT_dpad_binding

Totally open to suggestions on how to work that more user friendly and embed that into our documentation.

modules/openxr/editor/openxr_action_map_editor.cpp

modules/openxr/editor/openxr_binding_modifier_editor.cpp

m4gr3d

Logic looks good, although I'd like us to iterate on the documentation as in their current state, they're hard to parse.

@BastiaanOlij Is there a test project that can be used to help validate those changes?

BastiaanOlij · 2024-11-22T08:35:11Z

Did some more testing with this while addressing some of the feedback, found out that when both modifier extensions are enabled in the settings, one wouldn't work because both extensions require the base modifier extension. Fixed that up so Godot will react properly if multiple wrappers ask for the same extension to be enabled.

BastiaanOlij · 2024-11-22T09:07:13Z

@BastiaanOlij Is there a test project that can be used to help validate those changes?

@m4gr3d, I added a demo project on godot-demo-projects, see link in OP.

dsnopek

I skimmed the latest code, and mostly just found more little nitpicky stuff.

I haven't tested the binding modifiers at runtime, but I did re-test the editor stuff again. I'm able to add an OpenXRAnalogThresholdModifier, and that seems to be working fine. However, when I try to add an OpenXRDpadBindingModifier I get this error:

ERROR: Condition "!new_binding_modifier->record_on_binding()" is true.
   at: _on_dialog_created (modules/openxr/editor/openxr_binding_modifiers_dialog.cpp:134)

Is that expected? If so, how should dpad modifiers be added?

dsnopek · 2024-12-02T21:13:45Z

modules/openxr/openxr_api.cpp

-	// Append the extensions requested by the registered extension wrappers.
-	HashMap<String, bool *> requested_extensions;
+	// We can request an extension multiple times if there are dependencies
+	struct request_extension {


Even though this is a very local struct, I think we always use camel case for struct names - using snake case feels a little weird

dsnopek · 2024-12-02T21:25:26Z

modules/openxr/action_map/openxr_binding_modifier.h

+	GDVIRTUAL0RC(bool, _record_on_binding)
+	GDVIRTUAL0RC(String, _get_description)
+	GDVIRTUAL0R(PackedByteArray, _get_ip_modification)


These feel like they should be required? So:

Suggested change

GDVIRTUAL0RC(bool, _record_on_binding)

GDVIRTUAL0RC(String, _get_description)

GDVIRTUAL0R(PackedByteArray, _get_ip_modification)

GDVIRTUAL0RC_REQUIRED(bool, _record_on_binding)

GDVIRTUAL0RC_REQUIRED(String, _get_description)

GDVIRTUAL0R_REQUIRED(PackedByteArray, _get_ip_modification)

This will make it an error if GDVIRTUAL_CALL() can't find the method, and mark them as required in the extension_api.json.

This won't have any effect on the sub-classes within Godot that override these methods; only for GDExtension classes that do.

dsnopek · 2024-12-02T21:26:25Z

modules/openxr/action_map/openxr_binding_modifier.h

+class OpenXRBindingModifier : public Resource {
+	GDCLASS(OpenXRBindingModifier, Resource);
+
+private:


This superfluous private: could be removed:

Suggested change

private:

dsnopek · 2024-12-02T21:32:21Z

modules/openxr/editor/openxr_binding_modifier_editor.h

+#include "../action_map/openxr_action_set.h"
+#include "../action_map/openxr_binding_modifier.h"
+#include "editor/editor_inspector.h"
+// #include "editor/editor_properties.h"


Delete this?

Suggested change

// #include "editor/editor_properties.h"

dsnopek · 2024-12-02T21:40:00Z

modules/openxr/extensions/openxr_valve_analog_threshold_extension.h

+	void set_off_threshold(float p_threshold);
+	float get_off_threshold() const;
+
+	void set_on_haptic(const Ref<OpenXRHapticBase> p_haptic);


I think this might have meant to be a const reference? So:

Suggested change

void set_on_haptic(const Ref<OpenXRHapticBase> p_haptic);

void set_on_haptic(const Ref<OpenXRHapticBase> &p_haptic);

dsnopek · 2024-12-02T21:40:12Z

modules/openxr/extensions/openxr_valve_analog_threshold_extension.h

+	void set_on_haptic(const Ref<OpenXRHapticBase> p_haptic);
+	Ref<OpenXRHapticBase> get_on_haptic() const;
+
+	void set_off_haptic(const Ref<OpenXRHapticBase> p_haptic);


This one too:

Suggested change

void set_off_haptic(const Ref<OpenXRHapticBase> p_haptic);

void set_off_haptic(const Ref<OpenXRHapticBase> &p_haptic);

dsnopek · 2024-12-02T21:41:07Z

modules/openxr/extensions/openxr_dpad_binding_extension.h

+	void set_is_sticky(bool p_sticky);
+	bool get_is_sticky() const;
+
+	void set_on_haptic(const Ref<OpenXRHapticBase> p_haptic);


And this:

Suggested change

void set_on_haptic(const Ref<OpenXRHapticBase> p_haptic);

void set_on_haptic(const Ref<OpenXRHapticBase> &p_haptic);

dsnopek · 2024-12-02T21:41:17Z

modules/openxr/extensions/openxr_dpad_binding_extension.h

+	void set_on_haptic(const Ref<OpenXRHapticBase> p_haptic);
+	Ref<OpenXRHapticBase> get_on_haptic() const;
+
+	void set_off_haptic(const Ref<OpenXRHapticBase> p_haptic);


And here:

Suggested change

void set_off_haptic(const Ref<OpenXRHapticBase> p_haptic);

void set_off_haptic(const Ref<OpenXRHapticBase> &p_haptic);

BastiaanOlij added enhancement topic:xr labels Sep 18, 2024

BastiaanOlij added this to the 4.x milestone Sep 18, 2024

BastiaanOlij requested a review from a team September 18, 2024 10:15

BastiaanOlij self-assigned this Sep 18, 2024

AThousandShips changed the title ~~OpenXR: Adding support for binding modifiers~~ OpenXR: Add support for binding modifiers Sep 18, 2024

BastiaanOlij force-pushed the xr_action_map_enhancements branch 3 times, most recently from 45f85cf to 17a009e Compare September 26, 2024 04:57

BastiaanOlij force-pushed the xr_action_map_enhancements branch 2 times, most recently from e3aeb3b to a419e71 Compare October 14, 2024 03:29

BastiaanOlij mentioned this pull request Oct 14, 2024

OpenXR: change bindings to 'flatten' source paths #98163

Merged

BastiaanOlij force-pushed the xr_action_map_enhancements branch 2 times, most recently from 0b77271 to 577c7ef Compare October 14, 2024 23:06

BastiaanOlij force-pushed the xr_action_map_enhancements branch from 577c7ef to 924f137 Compare October 15, 2024 07:13

BastiaanOlij force-pushed the xr_action_map_enhancements branch from 924f137 to 050d3cf Compare October 15, 2024 07:32

BastiaanOlij force-pushed the xr_action_map_enhancements branch from 050d3cf to 3db345a Compare October 20, 2024 11:44

BastiaanOlij force-pushed the xr_action_map_enhancements branch 2 times, most recently from 4fb4d9a to 00c39d2 Compare October 21, 2024 07:44

BastiaanOlij force-pushed the xr_action_map_enhancements branch from 00c39d2 to ff9ffb0 Compare October 21, 2024 07:49

BastiaanOlij marked this pull request as ready for review October 21, 2024 07:50

BastiaanOlij requested review from a team as code owners October 21, 2024 07:50

BastiaanOlij force-pushed the xr_action_map_enhancements branch 2 times, most recently from cb7dd7a to 2129833 Compare October 21, 2024 08:02

BastiaanOlij force-pushed the xr_action_map_enhancements branch from 2129833 to cb20fb6 Compare October 21, 2024 21:10

BastiaanOlij force-pushed the xr_action_map_enhancements branch from cb20fb6 to 3ac09bc Compare October 21, 2024 23:59

dsnopek reviewed Oct 29, 2024

View reviewed changes

BastiaanOlij force-pushed the xr_action_map_enhancements branch 4 times, most recently from 5654653 to 7d8bef8 Compare October 30, 2024 21:52

BastiaanOlij commented Oct 30, 2024

View reviewed changes

m4gr3d reviewed Oct 31, 2024

View reviewed changes

BastiaanOlij force-pushed the xr_action_map_enhancements branch from 7d8bef8 to ba417e9 Compare November 6, 2024 09:48

BastiaanOlij requested review from m4gr3d and dsnopek November 19, 2024 10:54

m4gr3d reviewed Nov 19, 2024

View reviewed changes

BastiaanOlij force-pushed the xr_action_map_enhancements branch from ba417e9 to 5ff3002 Compare November 22, 2024 08:33

BastiaanOlij mentioned this pull request Nov 22, 2024

Add XR demo for binding modifier logic godotengine/godot-demo-projects#1137

Open

OpenXR: Add support for binding modifiers

a304355

BastiaanOlij force-pushed the xr_action_map_enhancements branch from 5ff3002 to a304355 Compare November 22, 2024 09:11

BastiaanOlij requested a review from m4gr3d November 27, 2024 02:39

dsnopek reviewed Dec 2, 2024

View reviewed changes

		Return [code]false[/code] if binding modifiers of this type are recorded on an interaction profile.
		Return [code]true[/code] if binding modifiers of this type are recorded on bindings within an interaction profile.

		If [code]false[/code], when the joystick enters a new dpad zone this becomes true.
		If [code]true[/code], when the joystick remains in active dpad zone, this remains true even if we overlap with another zone.

	void set_on_haptic(const Ref<OpenXRHapticBase> p_haptic);
	void set_on_haptic(const Ref<OpenXRHapticBase> &p_haptic);

	void set_off_haptic(const Ref<OpenXRHapticBase> p_haptic);
	void set_off_haptic(const Ref<OpenXRHapticBase> &p_haptic);

OpenXR: Add support for binding modifiers #97140

Are you sure you want to change the base?

OpenXR: Add support for binding modifiers #97140

Conversation

BastiaanOlij commented Sep 18, 2024 • edited Loading

BastiaanOlij commented Oct 14, 2024

BastiaanOlij commented Oct 14, 2024

BastiaanOlij commented Oct 15, 2024

BastiaanOlij commented Oct 18, 2024

BastiaanOlij commented Oct 20, 2024

BastiaanOlij commented Oct 21, 2024

BastiaanOlij commented Oct 21, 2024

fire commented Oct 21, 2024

BastiaanOlij commented Oct 21, 2024

BastiaanOlij commented Oct 21, 2024

dsnopek left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

m4gr3d left a comment

Choose a reason for hiding this comment

BastiaanOlij commented Nov 22, 2024

BastiaanOlij commented Nov 22, 2024

dsnopek left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

BastiaanOlij commented Sep 18, 2024 •

edited

Loading