As title,
can someone make or add a built in condition to GD for only declared key (or keys) pressed or released, pls.
Sometimes those conditions are really needed, since for example you don’t want any other keys/buttons pressed simultaneously, or unwanted combinations. eg: i want an hadoken with only A button pressed, but if you press all buttons A included the hadoken is triggered anyway…and damn…i don’t want it to happen…this is basic, so in GD i’ve to make Aaaaalll buttons with not keypressed conditions.
So instead to exclude manually other keys it would be great to have such conditions.
It would be great to have them in gamepad extension too. (i know that it can be done by GVAR)
I don’t think is an hard or difficult task…to implement…and it will simplify a lot the code in any game…mostly action/fighting ones
P.s: i forget tha should implement combo too;
eg: Only right and left ecc…
conditions should be called “Only key/s pressed” or something like that
This is a good idea but i’d ask you to look into string variable + the expression “lastkeypressed”
If you wanted to only be able to use one key and no other key, ever, and stop the event execution if another key is pressed, using a variable value that records key inputs (when needed) would reflect those needs. At least, this is what I would use personally.
Again, I don’t disagree in making a specific condition but I would assume what I stated above is more than enough to fill that need(s).
I’d imagine, as long as any other events also use this similar variable check, everything would run with only those specific inputs (single) and no others.
I’m ok with your suggestion,
but when you have a complex combination to make i dunno if it will simplify the problem.
I know there are workarounds, but i step in this issue in so many projects that i decided to go for a request.
In my project i’ve a FSM for some button keypress, but still when you trigger a FSM and don’t want the others you still need to check if the other is not triggered by keypress.or var…Its hard to explain, but…it’s what happened in my game…
eg if you press right to walk – you have a FSM for walk. if you press jump bt—you have FSM for jump…but—if you press right and jump at the same time there is no way to exclude the other if not with a “not keypressed” condition…or a fsm var …that is the same thing
So imagine you have to exclude all your gamepad combinations which include the jump button to just let your character jump…(“cos other buttons do other things”)
ofc it works, but imho it will turn the project into a mess…probably i’ve not asked properly the request.
But something that fix this should be added to GD.
I’ve recreated SOTN engine almost fully, and while it works…i spent most of the time to check which key do what, since the built in platform behaviour is made for low profile projects
What you are describing is why finite state machine (FSMs) logic exists, though.
You are supposed to set up each state and only allow the transitions that are valid from that state to go to the other valid states.
You have to do negations in your event logic but only when it applies. This is the basis of fsm and it shouldn’t be possible to have any logical conflicts unless you yourself have implemented them, or aren’t properly isolating your fsm states (eg, sharing state variables across multiple states, or trying to have multiple actions in one state, etc.)
As far as I can find in other engines Ive yested sith (unity, unreal, defold, godot, and now flax) this logical requirement is how it works everywhere else.
The engines cannot automatically"stop" other logic you have set up, you have to build those exclusions into your logic. Otherwise if you have multiple “only this key matters” logic, which takes precedence?
(Also fighting games absolutely require complex finite state machines because combos and special moves have to be accounted for completely separately from a single punch or kick. A defined chained combo in sf2 is like 10 different states because of each branch and required timing)
I may be wrong but i remember GM to works better on this matter, probably cos it was code only, and when you entered a FSM there, there was no way to exit without your input, no matter which key pressed…probably cos there were begin step, and after step,…or as they were called, in GD feels like the engine is reading each step even if youre no telling him to do it
but still i may be wrong,…many years have passed
Unless something is unusual with how you’re setting up your FSM in GDevelop, doing this in GML code is nearly the same.
You set up which actions a single state takes, which states it can transition to, and then the criteria of when it transitions.
Maybe compare what your FSM looks like/how it’s set up to the FSM in the Not-A-Vania example? Each state is segmented into an external event sheet and can only transition to defined other states, exclusions are only for that state’s potential scenarios. The only state that should have dozens of transition conditions is basically the Idle state.