6 replies to this topic

[Acguy]

Press and hold shift, S (or A/D), and spacebar all at the same time, then release everything but the spacebar once the animation finishes. In spite of the fact that you're holding down the spacebar and no longer in an animation which prevents you from jumping, your mech will stay grounded until you release space and press it again.

 

Whenever you hold down the spacebar through the animation of a dash or 180, the input is completely ignored, and to make the game realize you're holding it down you have to redo the input. There's no real reason for that. I think holding the spacebar during those animations should make you jump as soon as the animation ends provided you're still holding it down. 

 

You can see this demonstrated with things like jump pads; if you go on the pad and hold down spacebar during the travel animation, your mech will start boosting upwards as soon as the animation finishes. It's really odd that you can que the input while locked into a jump pad animation but not a dash or 180 since games usually either go one way or the other with input ques; it really looks like a mistake that we can to it in some cases but not others.

 

Ultimately this shouldn't be a very hard thing to implement, and on the off chance someone doesn't like this suggestion, implementing it won't affect how they play anyway, so it's all positive.

[Amidatelion]

Press and hold shift, S (or A/D), and spacebar all at the same time, then release everything but the spacebar once the animation finishes. In spite of the fact that you're holding down the spacebar and no longer in an animation which prevents you from jumping, your mech will stay grounded until you release space and press it again.

 

Whenever you hold down the spacebar through the animation of a dash or 180, the input is completely ignored, and to make the game realize you're holding it down you have to redo the input. There's no real reason for that. I think holding the spacebar during those animations should make you jump as soon as the animation ends provided you're still holding it down. 

 

You can see this demonstrated with things like jump pads; if you go on the pad and hold down spacebar during the travel animation, your mech will start boosting upwards as soon as the animation finishes. It's really odd that you can que the input while locked into a jump pad animation but not a dash or 180 since games usually either go one way or the other with input ques; it really looks like a mistake that we can to it in some cases but not others.

 

Ultimately this shouldn't be a very hard thing to implement, and on the off chance someone doesn't like this suggestion, implementing it won't affect how they play anyway, so it's all positive.

 

I could go either way on this, but just a heads up, about 85% of the fuzz that goes on with jumppads is unintended and due to janky coding.

[6ixxer]

It seems like a minor thing to retap the spacebar

 

I honestly never keep holding it so I never noticed.

 

You must drive a zerker...

 

#Don'tFeedTheSpaceBarWarrior

[coldform]

It seems like a minor thing to retap the spacebar

 

I honestly never keep holding it so I never noticed.

 

You must drive a zerker...

 

#Don'tFeedTheSpaceBarWarrior

He's actually a Raider main, with about 30 hours in match total, and about 13 of that as a raider.

 

Press and hold shift, S (or A/D), and spacebar all at the same time, then release everything but the spacebar once the animation finishes. In spite of the fact that you're holding down the spacebar and no longer in an animation which prevents you from jumping, your mech will stay grounded until you release space and press it again.

 

Whenever you hold down the spacebar through the animation of a dash or 180, the input is completely ignored, and to make the game realize you're holding it down you have to redo the input. There's no real reason for that. I think holding the spacebar during those animations should make you jump as soon as the animation ends provided you're still holding it down. 

 

You can see this demonstrated with things like jump pads; if you go on the pad and hold down spacebar during the travel animation, your mech will start boosting upwards as soon as the animation finishes. It's really odd that you can que the input while locked into a jump pad animation but not a dash or 180 since games usually either go one way or the other with input ques; it really looks like a mistake that we can to it in some cases but not others.

 

Ultimately this shouldn't be a very hard thing to implement, and on the off chance someone doesn't like this suggestion, implementing it won't affect how they play anyway, so it's all positive.

 

Honestly, Amid kinda nails it on the head, but considering that most pilots that stick around to really learn the game work on timing of input, so having this little option to "beat the finish" on jumping from a dodge/180 would be on par with using double tap to dodge.  it's there if you like it, but further player improvement would negate the effect.  the concept of learning to chain boosts and dodges together seamlessly requires keen timing, chaining a jump from a dodge would be a lateral move, figuratively speaking.(yes yes, I know, there's a pun there.)

 

On the flip-side, I bet this could be achieved with some creative scripting. we already have some community scripts for "lite" bunny-hopping and the toggle for repair, so I dunno...

[Acguy]

It seems like a minor thing to retap the spacebar

 

I honestly never keep holding it so I never noticed.

 

You didn't understand what I was talking about. If you're already hovering and you dodge, you can continue to hover. If you dodge on the ground and begin to hold space mid-dodge, you won't begin to hover afterwards.  I don't own a zerker and only use AC on my infiltrator; quite frankly, the fact that you assumed I was talking about AC spam and said in your own words that you "keep holding it" suggests you might be projecting your own habits.

 

For what it's worth, my username isn't "A.C. guy"; it's just all one word, "acguy," the name of an aquatic mobile suit from the original gundam series.

 

I could go either way on this, but just a heads up, about 85% of the fuzz that goes on with jumppads is unintended and due to janky coding.

 

Sure, but that's still essentially a moot point. If I say "hey, this one particular part of this one particular thing happens to work," the fact that "85% of the parts of that particular thing are janky" doesn't negate the fact that the one particular part which I had in mind might be beneficial.

 

most pilots that stick around to really learn the game work on timing of input

 

the concept of learning to chain boosts and dodges together seamlessly requires keen timing

 

On the flip-side, I bet this could be achieved with some creative scripting. we already have some community scripts for "lite" bunny-hopping and the toggle for repair, so I dunno...

 

I mean yeah, fair enough; if you like having an execution barrier, then you've got one. I'm just personally not a fan of those. Let's take dark souls 1 for example: in high level pvp, you could open up your equipment menu, click on one of your active rings, scroll through your list of rings and change it, and even switch to a larger weapon as well. People who could do this quickly would swap to the hornet ring and a great club right before a backstab or riposte animation. Sure, flipping through a handful of menus in order to instakill someone takes quite a bit of practice, but it isn't really a PvP skill you're developing there; it's just player-versus-menu. Battling my controller just doesn't feel competitive. I get that you can have a time-trial and see who can make it work the fastest, but if I'm running around doing time trials against a ghost in mario cart, I may as well just be doing them alone. It's single player. I would rather compare each player's ability to make decisions. If I'm playing a good match of chess, I don't want to beat my opponent because they weren't strong enough to lift up one of their pawns; I want to outplay their decisions. 

 

You could script this relatively simply though. All you would need to to is read whenever you press shift S/A/D, then set a timer which matches the length of the animation, and during that timer's duration prevent the game from realizing you've pressed the spacebar to trick it into thinking you'd pressed it the instant the animation ended. Alternatively, if you could detect when the game accepted the input and let make you jump, you could just make holding spacebar spam the input until it worked so that you hit the end of your animation.

edit: for some reason the word "shift" was replaced with "fuzzy bunny," is that just the profanity filter? Might have accidentally left out the F the first time around.

Edited by Acguy, 16 December 2016 - 11:30 AM.

[wischatesjesus]

Just to clarify, the "lite bunny hopping" and toggle repair are actually bindable actions built in to the game, but can only be bound in the ini files as they are not shown in the in game menu. I don't think they are really "scripts", and neither of them are even close to being impactful enough that they need any attention from the devs.

 

Also I would argue that pretty much all of the jump pad shens make at least some sense in the context of the game mechanics that are interacting. I find being able to throw items and holotaunts up pads to be an interesting interaction with compelling fringe use cases, and I think being able to air dodge during a pad trajectory is more interesting than not.

 

Comparing having to tap the hover key at any time between the termination of a dodge and the end of time to start hovering to going through menus to switch items during an combat animation is a bit of a stretch. They hit on a similar concept, but are on entirely different orders of magnitude in terms of difficulty and actual impact.

 

I have no objection to allowing that particular input to be queued, but it seems really trite. If its something that takes more than a few man hours I wouldn't consider it worth the effort to actually implement.

[Acguy]

it seems really trite

 

You're right, it is. I just figured a simple suggestion like this had a higher chance of being accepted compared to something overly complex or oddly specific.

 

As someone who's worked with game devs, the more useful suggestions are the ones which are specific but brief, and the ones which just get at general ideas and highlight overall objectives, opposed to the long winded and overly specific deviantart OC-doughtnutsteel character/mech implementation suggestions. Not to say that ideacrafting a mech in thorough detail isn't enjoyable in its own right or anything.