Yes, call:
InvokeAction<DeviceAxis, double>("Serial/0::Axis::Range::Minimum::Set", DeviceAxis.Parse("L0"), value);
there is also ::Maximum::Set, ::Middle::Set and ::Size::Set.
The actions are the same as for the shortcuts.
1 Like
Much appreciated!
Not sure if it’s just me but on the Patreon and public release I’m experiencing a bug.
When random motion is turned on for R1 and R2 AND invert is also on for R1 and R2, Roll and Pitch axis values from scripts do not get read (and therefore sent to the device).
Anyone else?
Final question :). Is it possible to listen for deovr haptic button events? It would be great if I could register an event listener or something
This will be fixed in the next release, tho the invert option will only invert the script, it will not invert motion providers because thats the source of the bug.
You can’t directly listen for input events, but you can register a shortcut action:
RegisterAction("Plugin::Test", () => {
// handle action
});
And then you just create a normal shortcut with your plugin action.
Note that there is an issue with current version where the plugin action will be removed from the shortcut on restart because the plugin is not yet loaded when launching MFP, this is fixed in next version.
It would be nice to allow plugins to just listen for input gestures but it currently would require exposing like half of the classes from the input system to the plugins. I’ll see if it can be added in some reasonable way.
Cool, thanks! Should be fine for now, but will be looking forward to the next version then 
Got it, good to know it’s in the works! I
yeah it’s just a QoL thing where one would have to toggle the random motion on and off when switching between media that has and doesn’t have roll and pitch scripted.
Not looking to invert the random motion as it’ll just be as random haha 
@Yoooi recently started using your free player, and i use osr2 connected via serial, and quest3 connected wirelessly, with deovr option as i use slr site on it. All works good but problem im having is lets say i take my quest3 off my head for a minute or 2, multifunplayer will disconnect from deovr. than i have to put my quest3 on my head and than click connect on multifunplayer for it to reconnect, which is annoying. Any way to have the player stay connected to deovr, even if i take my headset off?
There is auto-connect button next to the connect button, toggle it on and MFP will try to connect automatically every few seconds.
That disconnect is probably some quest3 behavior I cant control.
MultiFunPlayer v1.32.0:
Download: timed patreon only exclusive
Patreon build: https://www.patreon.com/posts/118304718
Additional patreon only changelog:
- Support SLR login using login code
- Allow connecting DeoVR even when SLR login fails or credentials are empty
- Don’t use cached session if username is different
- Fix “wrong password” error when logging in to SLR
- Fix SLR api sending local scripts causing double sync
Changelog:
- Rework and simplify plugin system
- Allow placing plugins in subfolders
- Expose available actions and properties to plugins
- Allow plugins to create their own UI
- Improve performance of creating assembly references for plugins
- Register missing properties for plugins where possible to match registered actions
- Sample plugins: MultiFunPlayer Sample Plugins · GitHub
- Update to .net 9 (performance improvements)
- Allow assigned actions to be in disabled state instead of getting removed from shortcuts if plugin or output target action is unregistered (#88)
- Add support for auto-home and speed limit when using PolledUpdate (#180)
- Fix unable to place breakpoints in plugins due to plugin assembly embedded source not including BOM
- Fix nested dialogs getting stuck invisible in certain situations
- Fix custom curve motion provider tiling when using makima interpolation
- Fix manual axis transitions loosing steps with shortcuts in relative mode
- Fix axis value flipping repeatedly with invert option enabled by reverting it to invert script only
- Fix auto-home taking shorter time to complete than configured
- Fix SyncOnMediaResourceChanged not having any effect when set to false
- Fix MotionProvider::Custom Curve::Points::Set actions not updating display name
- Fix MotionProvider::Custom Curve::Points::Set actions adding additional point on each launch
If you like what I’m doing, please consider supporting me on Patreon
https://www.patreon.com/yoooi
3 Likes
did some testing, with auto-connect button on, it still disconnects, but helps it reconnect after putting back the headset on. But forgot to mention another bad thing about when it disconnects is it looses the loaded script, so have to reload script in player whenever it disconnects. Pretty sure its disconnecting beacuse headset goes to auto sleep, can increase that time but ofcourse that drains battery. Before it lost slr support, I used to use joyfunplayer connected to slr and it never disconnected even with the headset off for long period of time, so perhaps some way to get it to stay connected is possible dunno.
edit: Or at least if could make it so player doesnt loose the script when disconnects would also be an improvement
besides that all perfect loving the player and its awesome flexibility/functionality
Thanks
The actual issue might be that if you first start a SLR video+script in DeoVR and only after that connect MFP it wont load the script.
The disconnect/reconnect due to auto sleep should not matter as MFP receives new state on connect.
Or it also might be a bug in DeoVR where you need to set the script again for the api to reset inside DeoVR.
Lemme ask a stupid question
Could MFP be a buttplug.io server (i.e. to have buttplug input source) in the further future (e.g. 2028)?
My Intiface Central experience with OSR2 where you can only use a single unconfigurable axis is pretty meh compared to MFP axis configs/hotkeys/mapping/randomiser
(Note: I remember finding an archived C# buttplug server implementation somewhere on buttplug github)
@Yoooi so I made a nice plugin that communicates with a web overlay for quest that contains stuff like range sliders, an edging mode, etc. which are mapped to the DeoVR buttons to make it pretty much on par with the native handy toy controls in the DeoVR app, thanks for the help!
Only thing that I find weird is that I need to press the DeoVR haptic buttons twice to trigger an action. Why is that? Can this be changed / improved or am I just overlooking something?
Sure, should be done by 31.12.2028 depending on how difficult it is to make a dummy server.
Tho this would be a good feature for a plugin.
Cool! I actually wanted to make something very similar, like a dashboard/tile style page you can use to invoke actions. Using AvailableActions, AvailableProperties you should be able to make this fully dynamic/configurable.
So the buttons are really toggles, so you toggle on/off edge mode, so for a full click (off → on → off) you have to press the button it twice.
At least thats the behavior I got pressing the buttons in the UI, maybe they behave differently if you make shortcuts for them in DeoVR. You can enable trace logging and see the button events.
If there is a way to get events for on/off and the UI button press/release separately (press → release → on → press → release → off) I could add it but from my testing DeoVR only sends the feature state not button state.
1 Like
Also make sure it doesn’t say “Click count: 2” (why is that even a default?)
1 Like
The default is now changed to 1. The default was 2 because at first this was a DoubleClick shortcut that then changed to configurable amount of clicks but the default value remained.
1 Like
Ahh, that explains it. Checked out the log and this is what I see for the edging button when using it bound to my controller.
First click
Received command “{“Time”:“2024-12-20T18:14:28.172029Z”,“IsHolding”:false,“IsDown”:true,“Type”:3}”
Second click
Received command “{“Time”:“2024-12-20T18:14:28.594306Z”,“IsHolding”:false,“IsDown”:false,“Type”:3}”
I think MFP only triggers the button action on IsDown true or false or something.
Personally I think it would make more sense if it triggered on each command that is received regardless of the parameters as this is more usuable. It’s pretty inconvenient to double click some button combinations and also different from how the rest of the DeoVR app works.
In the future it would be nice to get the IsHolding and IsDown parameters as input too as that would allow us to sync with the deovr switch state and to add logic for hold for edging like DeoVR has with MFP too. This will also align with single click behavior.
Anyways, cool this is possible regardless and curious to hear your thoughts about triggering the action each time a command for a specific haptic button is received.
Repeat count: 0.5 lol
You know, I know your joking but even that would be fine with me. I just want to be able to register each button event so I can implement the logic I want (a single press toggle). Now you don’t have that choice.