The evidence is out on the table above. You have argued with me about what hitstun is. You have tried to explain programming to a programmer. You have tried to explain what hitstun is to me.
I'm sorry you have a problem with society... but you are on Smashboards arguing with me, not before the High Court. Chasing me down and arguing with me for 3 pages isn't going to change how the world is, it's going to piss me off lmao.
Literally what the ****.
I can't truthfully address your post completely because you seem to miss everything I explain. You aren't a programmer as you claim to be, you don't seem to grasp the things I am trying to explain because you are trying to view them from too high level of programming. You are thinking of Unity/Unreal, when I am thinking of C++, Java, C. Basically you are thinking more of programming tools for designers (which is normally what modders use as you don't normally open up the actual code the game was written on) while I am thinking of actual code structure.
A state is not an action. A state is the behavior the player is currently having, although we might just be arguing semantics here, I am not being "too technical".
You want me to be technical? An animation is defined by a set of bones and joints from a model which are moved in model space to another position. You can use one of various techniques to blend the animation from one frame to the other by moving the joints using transformation matrices which contain position, rotation and scaling values correspondent to a specific axis and then adjusting the bones depending on the movement of the joints that specific bone is dependent on.
Nowhere on that explanation is there any type of coding for a character's behavior. I was trying to explain how behavior != visual. You can have a character move in idle stance, it doesn't make him idle. You can have a character loop his walking animation while remaining still, it doesn't make him walk. I thought you understood this and made a simple mistake of claiming the animation "held" the code, which is why I said "it was probably just a semantics mistake".
The animation has nothing to do with the behavior code, the behavior code calls an animation when you tell it to.
Now what you meant to say is that reeling is a behavioral state. Also in that state there is a certain timer which is calculated based on knockback and damage which tells the state when to stop. This timer is calculated equally in all Smash games.
All of that I agree with, but here's the thing:
In 64/Melee that state did not allow you to act, whether it be because it had code purposely stopping you from acting, or whether it be because it didn't have the code that allowed you to act, it doesn't matter. Fact is while in this state you could not act.
In Brawl though the state did not stop you from acting at all. There was a separate variable/function/state stopping you from acting for 13-25 frames which was independent of how much time the reeling state would last. This is completely obvious by the fact that reeling continues for a while if you don't "cancel hitstun".
There is no timer saying "you can't do anything". The reeling animation (subaction) simply does not have the code that says you CAN act out of it. However, fighter.pac's reeling "action" contains the code that would allow canceling.
If it didn't have the code to act, and there was in fact no timer which counted when you could act out then as soon as you got hit you would be frozen forever, don't you think?
Whether there's a timer to allow you to act again, or there's a timer that doesn't allow you to act, its the exact same concept.
It's...kind of like that. I'm starting to think I'm just failing to explain what's happening (or you're arguing for sake of my calling it hitstun which is really dumb).
When you hit someone, Brawl's engine calculates the number of frames of hitstun. The reeling animation is the visual representation for the frames of hitstun. If a player presses nothing, this "hitstun" formula tells the game to play the reeling animation and count down to 0. Then you go into tumble. The code that is linked to this reeling animation in fighter.pac that automatically plays forces that, once you're on a certain frame, you can airdodge/attack out of it. Note that those are the only things that you can do, there is no jumping or etc - these are specific interrupts. This is not a formula. The code looks something like this:
Asynchronous Timer=9
Allow Specific Interrupt - Airdodge
Asynchronous Timer=23
Allow Specific Interrupt - Aerials
This means that, no matter what, if you are in the reeling animation and you hit frame 10, you will airdodge.
When you hit someone in Melee/64, the engine calculates the number of frames of hitstun. The reeling animation is the visual representation for the frames of hitstun. This "hitstun" formula tells the game to play the reeling animation and count down to 0. Then you go into tumble.
Literally the only thing you're arguing is if the hitstun formula is called the hitstun formula. Which it is, according to Smash Lab & the like. This independent code that is in the reeling animation does not exist in other games and is not a formula
This isn't actual code or code structure. Again think of how it is actually programmed into the game, not what designer tools were made to look like.
Independently of HOW it was programmed I am not talking about that. I am talking about CONCEPT.
If it makes you understand my point better, I'll explain it with your own code.
------------------------------------------------------------------------------------------------------------------------------------------------
Lets assume asynchronus timers will stay exactly as they are for SSB4, but instead of being a set number, they will now be a completely new formula Sakurai made up (not the same one as reeling). Smoke will now be a visual representation of this ssynchronus timers. The code will look exactly the same but instead of AT = 23 it will be AT = X + Y - Z;
See..., now smoke is made to be a representation of the asynchronus timer (how long you have to wait before you can act out of the reeling animation).
This is what I have been telling you could be happening since the beginning, I tried not using the term hitstun and using "other formula" , which was the formula for the Asynchronus Timers (In Brawl's case its a set number), so you would understand better. Do you understand now?
------------------------------------------------------------------------------------------------------------------------------------------------
I can't put it any more clearer than that.
There is a very simple way. I'm not sure how I can make gifs to show you, but watch gameplay clips closely.
Brawl has a system called buffering. This means that if you do an action before you are "able" to do it, the game will keep trying for a couple frames. If you, for example, do a down smash, and then during the last couple frames of endlag, you press A, that input will be "buffered". The first frame that you are able to jab, the game will automatically jab for you.
How is this relevant, you ask? Watch the gameplay clips from the Direct, and also watch the Mega Man vs. Mario video. When these characters suffer knockback, they go into reeling. Fine and dandy. Then they go into tumble.
Now watch closely, slow the video down during knockback. This was especially clear for me during a point in the MM vs. Mario video where MM hits Mario over to the left near the platform. I slowed this down to .25x speed and watched as Mario went into reeling, then into tumble for one frame, and then airdodge immediately. This behavior is mirrored many other times during the match, and also in the gameplay clips from the Direct. So this leaves us with two possibilities:
1. For some reason, the players are ALWAYS choosing not to cancel reeling into airdodge even though they can, and then are impossibly-accurately and consistently cancelling the first frame of tumble into airdodge.
or, the more likely option:
2. Buffering is back, and momentum/hitstun cancelling is not.
It is very clear when someone is not buffering the airdodge, as you can see the tumble animation for more than one frame. This does happen quite a few times. The first frame of tumble looks radically different from reeling, so it's easy to pick out in slow speeds. They are being later than the transition, but never sooner. Another strike to back up my evidence.
I did do that, but I cannot claim to be able to tell 1 frame difference, nor was I able to see them entering their tumble animation. It might just be that I wasn't paying enough attention or that I just can't tell. I was trying to tell if the smoke was dissapearing the very last frame before they air dodged. If you did go through the videos you would have noticed though that the smoke does dissapear right before they air dodge, at least in 4-5 different cases (didn't check the whole video) and that I can assure you because I actually looked at it. I cannot assure it was frame perfect as the game moves at 60 fps and slowing it to 0.25x means you are watching 15 frames per jump (from my understanding at least, I don't do video editing, I don't know how video editing works), but I was unable to see one single time the smoke ended way too early or way too late, it always seemed to be perfectly aligned with the air dodge. Maybe you should watch it again and check that out, see if you can actually disprove that theory as I tried to do.
Point is this is a good argument to back up a claim, unfortunately I cannot actually value its worth because I am horribly bad a video editing and I cannot believe in you because I already don't trust you because you've already claimed things that were false to be true. If you posted a video showing exactly when they go into tumble and airdodge right away I would believe you.
For now it stays as a possible theory, not a fact.
I'm sorry, but that is awful justification. I'm sorry you have a personal vendetta against educated conclusions, but that's not my problem, dude. Yes, it could be different. But it doesn't look like it is. And the players aren't playing like it is. And the frame counts aren't looking like it's any different. I don't need to see the code to see that the hitstun modifier percentage is the same as Brawl/Melee, I just need to slow the video down. Why would I need to see the code or have the controller in my hands to come to the conclusion that smoke isn't linked to it?
Yet from slowing the video down, it does look like its linked to it, which is how we came to the theory. You don't need to have a controller in your hand but you need some type of actual facts or evidence.
How is your conclusion educated? All you are saying is that it is that way because it was that way in Brawl. You literally have 0 evidence, NONE about whether its the same or not, all you have is: "Brawl did it this way". Aspects of the game can change, your point holds no merit at all.
You backed up your claim by saying that "IF" the trail spawned with the same properties as the smoke they would be equal, yet you didn't say IF, you said they do. When I asked you to explain how they spawn with the same properties you went back to saying it was because they were programmed the same. You do not know if they were. And you are just going in circles.
"Can't you tell when your character is spinning and flailing their arms and when they aren't, dude? Really? It's been like that for three games, too... If it was unclear, we would have a lot more people complaining and we would have had a fix by now, probably."
Not really because you never want to be in tumble, so from a gamer's perspective it doesn't really matter how much hitstun lasts as you'll cancel it as soon as you can. It's like hit trajectories, you don't really need smoke or trails as you can clearly see your character flying off screen, the character itself should be more than enough visualization for you to tell what direction you are flying. But guess what, making things easier and obvious is most of the times good design (as long as it doesn't dumb down the game).
It's also the direction the game itself is going as a whole. Did we need a visualization to see who got the kill? If you were paying attention you should have been able to tell who hit him. Do we need to know the hitboxes and animations of moves? After a while playing you will be used to them so there is no need for that, no one has complained until now!
Yet, all those things are being added to the game too. I am not discussing whether I think smoke trails = hitstun duration is a good idea or not (although I have made it very clear that I do), if you think it is a bad idea that is your own opinion. What I am discussing is that it is a possibility and it in fact is a possibility (just a possibility though, you might be right and the smoke just acts the exact same way). If you have a surefire way to prove to me that it isn't right now why don't you prove it instead of claiming you know better. (Which is what you are doing by providing 0 evidence)
And now, so that you can understand why I think it is a better way to show hitstun and what I mean by making the TIME clearer:
Now, from that picture, can you tell me how many frames or milliseconds is left for Ganon's hitstun?
Would it not be easier to know this if you had a trails of smoke which each represented a set amount of frames/milliseconds and you could instantly tell by looking at the smoke?
You said: "Yeah, you have facts, but that doesn't prove anything! Stop drawing conclusions!" I'm starting to wonder why this conversation is even still a thing. This is ridiculous.
What? No I did not say that. I said you have no facts, you use facts that have nothing to do with something to make a point and I call you on it. You have not made a single argument which has an actual fact that isn't speculation. If you had an actual fact there would be no way for me to actually debate you since it would be a fact not an idea, don't you think?
Brawl is an example of a past game and you can deduce things will be done similar to Brawl, but saying "This is how it was done in Brawl and it will be done exactly the same in Smash 4" is completely wrong, it isn't even close to being right and you need to understand that. Things change and have already changed.
![[TSON]](/data/avatars/l/114/114196.jpg?1360761019){kind=avatar}
