frame skip values

[Ramond]

I myself believe as well that wait: 0 represent a 1-frame duration, wait: 1 will take 2 frames, wait: 2 will last 3 frames and so forth. I cannot back this up with hard proof sadly, but I recall that when coding certain timing-critical moves in RAEG! LF2, it always worked out when I calculated the total frame time with the above.

(Just my opinion, take it with a grain of salt. I believe YinYin would have much more insight into these technical details than I do.)

[A-Man]

I myself believe as well that wait: 0 represent a 1-frame duration, wait: 1 will take 2 frames, wait: 2 will last 3 frames and so forth. I cannot back this up with hard proof sadly, but I recall that when coding certain timing-critical moves in RAEG! LF2, it always worked out when I calculated the total frame time with the above.

I am pretty sure that's how it works too. Also, quoting my edit of my previous quote so no one misses it:

So what wait: value will have a frame wait for exactly 1 second?

Edit: http://www.lf-empire.de/lf2-empire/data-...characters
Got my answer (wait:29 makes a frame last one second as I thought).

Then either, wait:0 ==1/30th of a second, or LF2 doesn't run at 30 FPS. Supposing its the first, then a (1/30)*3 != (2/30), right?

[YinYin]

Right - I should be knowing this because of my time background ...
too much trial and error on these things every time so I forget :D

[hell fightter]

so bassically nein :C what a shame but thank you all for the responce.

[TheNave]

you're all wrong, wait 0 isn't half a frame, 'nor is it 1 frame and wait 1 like 2 frames... wait 0 is abit more tricky
when you use a wait 0, in that frame the game runs through it normally, calculating all the bdys and itrs and stuff, but after that, it already sets the frame to the 'next' value in the exact same cycle, which actually causes the game to NOT show f.e. the pic you used for the wait-zero-frame because at the end of the calculating cycle it's already set to the next frame... the game basically kind of skips the wait: 0 frame...
though, if you use two wait 0's after eachother, in the first cycle, the first one gets calculated, then changes to the second one, but due to the game only doing one cycle per char, the second one is not instantly skipped, so you can actually see the pic of the second wait 0 frame... the same thing happens if the first frame of a special attack or something is a wait 0, because the player input is calculated After all the frame stuff, it would have only calculated the previous frame, the one which had the hit_something in it, but not actually the first one of the special attack (this is also the reason why opoint doesn't work in the first frame of a move)

hope you could understand that, I'm not good at explaining such stuff, but that's how it works
tl;dr -> use wait 0 as first frame of an action or after another wait: 0 and it'd show as 1 frame, use it between other frames and it'll not show atall and be skipped instantly (bdys and itrs and stuff would still work though)

[hell fightter]

i think im actually getting it... ill keep on getting it then i guess. just kidding im getting it! still cant do much :C thanks for explanation tought

[A-Man]

I am not going to say you're wrong, just yet, but I would like you to explain to me, with logical statements, how does that work. What I say is that wait:0 behaves as you said ONLY if the current frame wasn't a result of a next; and that's the real reason opoints requires a next. Here is an elaborated explanation:

The engine most likely handles the main loop in this order:
1-InputsStuff; handles the hit_a,j,d and the F,U,Da,j
2-CollisionDetectionStuff; for the current frame.
3-UpdateStats; it updates the frame if the "wait_counter" is 0, else "wait_counter" is decremented.
4-RenderObjectsOnTheScreen; it show the sprites.

I assumed that order because that is the conventional order of operations for almost every game's main loop.

Now lets say at a frame you were hit and sent into injury frames with a wait:0:
1-InputsStuff()=> No keys were pressed, so we go on. You're still at that whatever frame.
2-CollisionDetectionStuff()=>Collision detected, you were sent to frame 223 with wait 0; therefore, "wait_counter" is set to 0
3-UpdateStats()=>"wait_counter"==0; 0==0 is true; so the frame is actually updated on the same cycle here.
Somewhere under that must lie the opointing process. The frame was already updated, it won't actually opoint.
4-RenderObjectsOnTheScreen()=> the wait:0 frame was skipped as you theorized.

But, when a wait:0 frame was a result of a next, it should show and collide and do everything normally without any exceptions. We're going to start at step 3, where the frame just updated to a new one through a next with a wait 0:
3-UpdateStats()=>"wait_counter"==0? True, and therefore we update to frame y with a new wait:0; "wait_counter" is set to 0.
4-RenderStuff()=> And there it is rendered.
1-InputsStuff()
2-CollisionDetectionStuff()=>And there, Inputs and Collisions were handled normally.
3-UpdateStats()=>The frame updates and the cycle continues.

you're all wrong,

Eeh?

Edit: And if you based that theory on LF2's F2 skip function, then I would like you to know that it actually skips 2 frames, not one.

[TheNave]

I didn't look into lf2 related stuff for the past 3 years, that's just something I remembered of my hex'ing times back then, I have no real proof or anything, but that's just the thing I think I figured out 3 years ago, it might not even be true, I could have remembered it incorrectly or maybe even figured it out wrong in the first place back then, so I'm sorry to dissapoint you but I cannot give you any further explanaition or proof on this one^^

But I'm almost 100% certain wait: 0 does not equal 1 Frame, or 1/3 Frame or something, it had some complicated special cases

[YinYin]

you're all wrong,

Eeh?

It's just too satisfying to say that.

I have no real proof or anything, but that's just the thing I think I figured out 3 years ago, it might not even be true, I could have remembered it incorrectly or maybe even figured it out wrong in the first place back then

Welcome to the club.

But I'm almost 100% certain wait: 0 does not equal 1 Frame, or 1/3 Frame or something, it had some complicated special cases

I'll trust you on the special case thing instantly, but it's gotta have an average fraction of wait 1 when used in sequence.

[A-Man]

But I'm almost 100% certain wait: 0 does not equal 1 Frame, or 1/3 Frame or something, it had some complicated special cases

I'm sure it is 1 frame. One can do some tests with THIS program. I don't know why, but the program doesn't seem to function for me anymore :\.