alRex-U
commented
1 year ago Concretely what do you think the control of ParCool with a controller should be like?
Open greysondn opened 1 year ago
alRex-U
commented
1 year ago Concretely what do you think the control of ParCool with a controller should be like?
greysondn
commented
1 year ago Well, let's start with "I'm on a computer and accessibility features and workarounds are hard to anticipate; try to make it as reconfigurable as possible, for the love of Nature".
Being said, I can tell you what I think. It will be a long read. Much of it can be skimmed until needed, but like anyone writing documentation, the hope is that it's enough and that if something is needed it will be consulted first.
I am clumsy; I may miss things that you've done in the mod as-is. I am sorry for that. Please try to understand that this report exists in part because of the accessibility workarounds used to address that clumsiness.
Here, by "clumsy", I don't mean inattentive - I mean physically clumsy. "Dyskinetic" - muscles don't do what they're told - sometimes it's the wrong one, or the right one the wrong way, or half a dozen other things - and I have random muscular twitches that can and have thrown computer mouses across the room. (It's likely caused by iatrogenesis and personal stupidity.)
This gives you an idea of who you're hearing from, and the limitations I'm personally under.
Other people are missing entire limbs, missing fingers, tire easily, move well but only if they don't move quickly, and the list goes on. Disability and accessibility planning is a nightmare. My advice borne from the last decade is to give us (people with the need for accessibility adjustments) the tools we need or find missing and trust us to know what we need to do with them. We need a box of parts more often than we need ready-made solutions - primarily because what is different about us isn't cookie cutter and so cookie cutter solutions won't work well compared to personalized ones... and it'd be absurd to think the whole world is a full-service shop so if we could just get "the parts" we can assemble our own solutions...
I say much of this because I fear that you may see it as one-and-done for accessibility when the reality is that I'm just one person. It would be a disservice to the communities that have helped me time and time again not to try to do right by them.
Granting: hopefully how close I am to "normal" would make controller support better for everyone, including the majority of people who are unaffected by such concerns.
I use a tired xbox 360 controller that I've clumsily repaired twice now. This means that LT and RT - the two triggers - are not available as a chord. (This is a limitation of the controller's design, not my repairs.) Otherwise the controller behaves in pretty much every way you'd expect, based on prior knowledge or research.
Anyway, that means the input reference (and language) in this set of notes is going to be xinput, displayed as though implemented on a 360 controller.
To begin with, Crayfish's basic, default mappings for the controllable mod while running around look like this:
This only gets more complicated as contextual inputs come into play. For example, the mod is smart enough to know I'm in a menu or an inventory, and to adjust my controls accordingly.
It's therefore necessary to not override controls in a way that would break this contextual behavior. Controls must observe context on a controller.
Okay. So let's talk actual implementation ideas here. These are in an order that's somewhere between "loose" and "dependencies".
Throughout the course of these notes, I will speak in terms of contexts, as controller input often has to be context sensitive (similar to changing controls in menus that I mentioned above by Mr. Crayfish).
Those contexts are:
Falling - by "falling", I mean experiencing a drop of one or more blocks in height.
Running - by "running", I mean any state that would permit performing fast running dependent actions. If an action requires fast running, this is a valid state to execute it.
Parcool offers the option to disregard fast running for vanilla sprint, right?
And, similarly, to disregard the vanilla sprint in favor for the fast running?
I appear unable to test the first of these two on controller; however, the second option, on testing, didn't even seem to work with M+KB. I believe I'm misunderstanding something. Here is how I configured those two options, for reference.
Note their details above, as they also seem swapped there.
Were these options to work, then a working model would be something like:
While fast running, consider a context of "running" to be active, which would change the way the controller interprets some controls. This will be spoken loosely moving forwards.
A better model for controller compatibility may be the three stage prone model from games like Metal Gear Solid V. Crawl can be entered and exited via the same button as sneak ("crouch") in a three-stage up-and-down maneuver:
This implementation is fairly standard, and a QOL adjustment would be to skip the middle step on standing back up (to go straight from crawling to standing again). I would recommend that QOL change to the standard arrangement, personally, but a toggle option may be the better way to go.
On controller, I'd recommend sneak's keybind being used to slide, contextually. Essentially, if you're in a running context and press sneak, you start sliding; to exit a slide, you can press crouch again (similar to the above mentioned in/out system for crawling).
This would mean you can not directly enter sneaking or crawling from a running context.
R while landing from a falling context.I'm going to advise using the sneak binding in a falling context, near the ground, as the breakfall input. This would mean that a controller user would no longer be able to land into a sneak from a jump.
Honestly, there's no reason this can't be interact on controller, as well. That's LT. A press of LT near the ledge the player wants to grab should be good enough.
Climb-up should be the jump button while hanging.
Skip for now.
I think double tapping on controller is fine, but permitting this to be mapped to a controller button may work well for people more used to playing, for example, Legend of Zelda or Kingdom Hearts. B on xinput may be an option here. (Remember to make it unbindable somehow!)
Why not hold jump button while near a wall and in air for this on controller? It will break certain double jumping scenarios and mods, but wall running is also not necessarily essential so much as nice. Players can disable it if it gets in their way.
(The gentleman testing "normal" controls for me noticed that even on KB/M, the same configuration I'm suggesting is a QoL improvement for him.)
So... breakfall while trying to move forwards on controller?
I see no reason why this can't work on controller as well.
Again, I see no reason this can't work on controller.
Again, I see no reason this can't work on controller.
They're flourishes. I've written quite a lot and I'm calling it okay to not show love to just one of these.
greysondn
commented
1 year ago I've forgotten Cat Leap. My gentleman friend tells me it's a long jump while running - specifically, the sneak key.
I would propose that early on during a slide, if the player hits jump, they cat leap. This would be similar to the long jump in many Mario games.
Sorry for forgetting that, woops!
alRex-U
commented
1 year ago Thanks for your detailed suggestion.
I may be able to answer why other actions like Wall-Jump do not work. As for Wall Jump, the key-bind for this action is mapped to "Space" key. yes "Space" key but not "Jump" key (this is because a certain player told it should be useful if able to bind them to other keys before) As same, Fast Running key is mapped to "Ctrl" key. Not "Sprint" key, so I think you cannot do Fast Run defaultly.
And I am so sorry! descriptions about config:"replace sprint with fastrun" and "substitute fastrun", they are swapped!! this is a bug. so "replace sprint with fastrun" is correctly a config: "you do Fast Run whenever you sprint"
About Dive, sorry it is not implemented yet in released version, yet. it will be added in next update.
Now I already did almost work for next update, so I cannot do this soon. This seems a somewhat big task. Thus it must takes time until I release it if I do.
greysondn
commented
1 year ago It's okay! The important thing is that you've taken the feedback and responded to it in a non-hostile way, honestly, because it's terrifying to spend a few hours to work on that knowing things can go badly.
I'll be here if you need more discussion, testing, whatever.
greysondn
commented
1 year ago a certain player told it should be useful if able to bind them to other keys before
That player wasn't wrong. The next step here, in terms of what I'm saying, is extending that towards the controller and providing some context awareness.
About Dive, sorry it is not implemented yet in released version, yet. it will be added in next update.
My gentleman friend, @gamefreq0 , will be relieved to hear. It was driving him a bit crazy trying to figure it out.
Now I already did almost work for next update, so I cannot do this soon.
The above comment covers this. (I had just gotten up, it was the most important thing to say.)
This seems a somewhat big task.
I honestly don't know. Contextual awareness is hard, but making controllable better aware of Parcool seems like it shouldn't be terribly hard.
Then again, I can see parcool's binds in the extended dialog [for controllable], they just don't work well without context awareness.
I'll toy around with that some and see how much is viable for workaround based on what I've said here already.
Thus it must takes time until I release it if I do.
Hey, I'm not paying you. In your own time, if at all, and I'm immensely grateful for a healthy response regardless.
alRex-U
commented
1 year ago Indeed controller support is not unnatural for mods like this. Thanks. I will consider.
This seems a somewhat big task. Excuse me, this mean "This seems a somewhat big task for me". Of course, Controllable is an Api provided by the great modder : Mr. Crayfish. it is undoubtable that it is not difficult to utilize. However I am new about this, and these days I do not work on any tasks of adding new dependencies to this project, so just it looks little troublesome.
alRex-U
commented
1 year ago alRex-U
commented
1 year ago The most hardest problem for realizing this is #135 .
Hi! I use a controller to play minecraft via Mr. Crayfish's Controllable mod. (Kb+m is not an option, disability/accessibility related)
I also run a minecraft server! I believe my players would enjoy this mod, but we have the rule that nobody should be excluded via the inclusion of a mod. Each of us has needs and issues, and so we try to make a space we can all enjoy.
The mod may as well not work at all with a controller; things half work or don't work at all, and it wasn't until I accidentally mistyped that I realized that double tapping would dodge roll me on a keyboard.
So I was hoping maybe you could either find a way to better universalize the control inputs (so that Crayfish's mod can hook it via custom inputs, as well as other mods) or support that mod directly? I have time to test things - ideally 1.16.5 as that is our server version target - and I have a background in computer science to help debug.
Running Environment