Raw Controller Input Sensor
The current Controller Sensor is great, especially for non-technical people who just want to wire up controls without thinking too much about conditions and/or mathematical operations that need to be considered for controller mapping into gameplay (for example analogue sticks input that Dreams converts to output values relative to the camera, thus saving both time and in-game resources to additionally calculate for ex. where the character should go towards in a 3D space) and - if needed - have additional options like Local Stick Inputs which disregard the camera position for more direct input mapping, etc.
There's also quite a few technical people which seek to push Dreams to the absolute limits, like myself. To be completely transparent, I have been working on a side project outside of Dreams which utilizes Remote Play functionality in order to virtualize a DualShock/DualSense controller which handles both controller mappings and rumble handling. And thus far I've discovered that regular Controller Sensor does have a fair amount of limitations, which is a bummer. Examples of those include:
- predefined (but sometimes inconsisent) deadzone on analogue stick input (either Local or Relative to camera) - measuring it bit-wise (since X and Y axis of both sticks carry an 8-bit output each), it is approximately 13 units -> 13 * 2 / 255 = ~10% of pushing the analogue stick on any direction.
- X and Y axis convertion from square to circle coordinates for either sticks - I get the idea behind limiting both axis for circular area of sticks, especially for something like mapping a character movement, however the consequence of that is for example: "pushing" a left stick to values 255 of X and 255 Y does not translate to 1.0 of X and 1.0 Y in-game, but ~0,71 of X and Y instead (it's basically 1 divided by square root of 2).
Some of the limitations are found even without the external tools, like for example - no local version of Motion Sensor input which already described in this thread: https://forums.indreams.me/hc/en-us/community/posts/4404281612305-Add-a-local-space-Motion-Sensor-output-to-the-Controller-Sensor
To solve this, I would love for the game to have a seperate Gadget called Raw Controller Input Sensor - which would give the creator the input values that are directly parsed from the Controller input itself.
The format of signal pushed out by this new gadget doesn't matter all that much, it can be values of 0 to 255 or percentage going either from 0-100% or in case of analogue sticks - -100% to 100%. What matters is the consistent values of controller input.
This new gadget could allow the advanced creator to define their own set of behaviours when it comes to certain controller mappings and think of their own solution regarding how to handle controls with a lot less restrictions.
On top of that, it would be cool to receive stuff like full touchpad controls - also suggested here: https://forums.indreams.me/hc/en-us/community/posts/360015887337-Full-touchpad-support-in-controller-sensor ... or controller's LED colour mapper gadget.
Speaking of controller output mapping like Rumble, I would also love to have an option to specify which controllers should the gadget affect. Currently it is not possible to specify that and it would just cause a rumble on all connected controllers.
P.S. I would most likely put these two last suggestions on seperate idea threads, however since they are also tied to Controller handling in Dreams I thought I should put it up there 👆
-
If you power a rumbler with a player info wire (eg. from a trigger zone) only the players indicated by the wire will rumble. I have a tutorial of this on patreon for supporters. https://www.patreon.com/posts/player-specific-61358111
And it is explained in my documentation. https://tapgiles.com/docs/#gadget-rumbler
-
Are you sure the normalisation of the inputs are not done by the console's OS? Or the remote play application? It would make sense, as it is strictly impossible for a real stick to do this. There has to be some sanitisation of inputs somewhere along the line, if only to prevent hacking and cheating in online competitive play. But this isn't necessarily something Mm has put in place in which case they wouldn't be able to do anything about it. I'd personally think it's much more likely to be a system-wide thing as an anti-cheat measure, that kind of thing.
The same could theoretically be the case for the deadzone? But I don't really know to be honest. Just a possibility.
It's a shame all of these things are lumped up into one post; I'd upvote some of them at least. I'd agree on more touchpad, LED colour, and motion sensor outputs--but just as part of the same gadget. Those things have nothing to do with "raw" inputs or anything; just the way they're packaged. Same for any of the other ideas to be honest.
請登入寫評論。