Request: Platformer Object: TRIGGER JUMP

To be honest, I don't feel Platformer behavior is limitated. I already created all kind of complex Platformer Controllers only thanks to Event Sheets, the existing features of the Platform behavior and the other behaviors. (emulated almost all controller features of games likes Celeste and Dead Cells without issue)

Coyote Time could be handy to add by default for very beginners but it's very easy to implement by ourself ! It's not painful to do in any way contrary to many other things

Regarding the jump sustain I prefer to implement my own anyway to really control the feel of the character.

There are many things that could be improved in existing Construct features such as :

- fixing the slide along solids issues with all other Movement Behaviors (Bullet for example)

- a lot of missing ACE and expressions for existing things

- Better event search/Project search workflow

- Better Instance variables workflow

- Better Hierarchy workflow

- A way to get access to Object Template Name Lists thanks to expression

I'm not talking about missing features here, only the existing ones. But if we also take missing features into consideration I feel like there is a ton of things that are very difficult or even impossible to do thanks to eventsheets that should be higher priority than that kind of things.

As you stated already you want the official behavior altered because you consider doing it in events hacky.

Wrong, I stated (factually) that one aspect of the official behavior breaks another, and I proposed a very simple solution. Ashley did not intend for two built in features to fight like this, nor, I'm sure does he want pointless argumentation in threads he's already personally addressing.

I made a simple request, not a post asking for a philosophical and mostly semantical debate on whether or not my request was valid in the eyes of newt.

It can be done in events.

Nearly anything can, and all games can be done in Assembly, so why did Ashley make Construct and why did he give us behaviors? Construct and it's behaviors were made to offer people an easier way to get a lot of things done so they can spend more time on the creative side of things....

Do you need help figuring out your complex platformer engine?

No, but thanks for the offer.. As I've said, I could use the slightly hacky double use of double jump, as has been suggested, but I simply wanted to suggest a fix for the fact that right now, one built in feature breaks another. (using vector y to fake a jump causes jump sustain to not work at all during that faked jump).

It could very well be that Ashley decides he needs to prioritize other things for a long time, or that this isn't worth him doing ever, at which point I'll use the slightly hacky method. That has nothing to do with my suggestion. It won't pause or halt my project if he doesn't fulfil my request, but I and I'm sure many others would appreciate one platformer behavior feature not breaking another.

This is a perfectly valid request undeserving of the sarcasm and useless snarky responses.

"Simulate Jump" only works if the object is on the floor, and the built-in double jump feature is silly and shouldn't be used for coyote time anyway.

Instead "Simulate Jump" should just execute when it's called, allowing any amount of proper mid-air jumps and/or coyote time jumps determined by instance variables. If the player only wants "Simulate Jump" to work on the floor then they can pair it with the "Is On Floor" condition instead of it checking for them. It's not rocket science.

Also, not only does setting the y vector to a negative value not give you jump sustain, but it doesn't trigger "On Jump" either. Seems the only ways to trigger "On Jump" are by using "Simulate Jump" when on the ground, or by executing a built-in double jump...so, y'know, there's that.

I agree this is an interesting request but because of the limited dev ressources of Scirra, It would be frustrating if stuff that we can do by ourself pretty easily were pushed in priority.

This has to do with the big focus Construct Animate is getting recently that makes dev ressources allocated to Gamedev Construct even more scarce. But also the fact that recently a few updates added features for which i can't find a single use case. For example, the "Compare Child Count" condition, or the "Copy Picked" Function feature (well this second one can have limited use cases but not the first). I opened my biggest and most complex project and i didn't find a single valid use case for those 2 features, both are very limitating and error-prone.

It wouldn't be an issue if it had no slowdown impact on stuff that we're waiting for years and would be real game-changers.

In case anyone is wondering how to implement those platformer mechanics with existing features :

For coyote Time, I usually like to add a Timer Behavior to my Platformer Object. If it's not grounded anymore and it didn't "JustJump" (boolean set to true at the beginning of my Jump Function), I start a 0.3 second "Coyote" Timer.

If I press my jump button and either the Platformer is grounded or either the "Coyote" timer is running, I call my own Jump Function using vector Y. That function is also used for my Double Jump (or not, again depending on the game i'm working on).

I also implement my own Jump Sustain to really have full control on how it behaves as it can differ a lot from one game to an other. Sometimes i use a trick to "lower the gravity force" (by adding an opposite force for example) for the first 0.4 seconds the player sustain the jump button for example.

So I do think there needs to be a point where we draw a line and say "use the existing advanced customisation for that".

Right now one built in feature breaks an other in the same behavior. (using vector y to fake a jump breaks jump sustain. To me, that line you mentioned should be determined with how long it would take to fix the unfortunate fact that two or more built in features do not working together well at all.

Adding a force jump would solve this cleanly, but only you know how much work it would take to add this feature.

But, I know you're very busy and won't nag and pout or put my project on hold over it. I'll do the hacky work-around using double jump for both double jump and for the coyote fix.

We also get more "just do XYZ how hard can it be" requests than we can possibly deal with, and seemingly simple things routinely turn out to be unexpectedly complicated. (The Platform behavior is also extremely complicated and a source of nightmarish bugs even after about a decade of development, to the extent I dread making even small changes to it.) The feature request system is there to try and deal with all this, so post suggestions there and vote on the ones you want to see implemented.

I've lost count how many times I've thought something would take 10 minutes, and then spent the next 3-6 months in a mix of subsequent refactoring, fixing obscure edge cases, working out why regressions happened, talking to users who said actually it doesn't work exactly like they thought it would so actually it needs to be changed, and then the change causes a regression, and then there's more refactoring, more obscure edge cases, someone else finds it's not exactly what they need for their project so please just add another quick setting because how hard can it be, etc. etc...

Meanwhile this is already possible with "Set vector Y" and some of your own events, and you can definitely customise that to work with your specific project's requirements.

Software development isn't just "how long does it take to do it in the first place", it's "what are the long term maintenance implication of this". That's the point of that blog post I wrote, which summarises: in software, everything is always more complicated than you think!