YesNoOk
avatar

command buffering (Read 2934 times)

Started by Bastard Mami, November 21, 2007, 10:51:19 pm
Share this topic:
command buffering
#1  November 21, 2007, 10:51:19 pm
  • ******
  • [E]
    • Mexico
i really don't want to implement this, especially if it will change greatly my cmd code.. but i have been giving this some tought.

let's say p1 has got an attack animation, it hits on a certain elements, thus triggering a hitpause for both p1 and p2; yet, p2's behaviour is rather straightforward ; p1 animates completely disregarding the hitpause, but he can't cancel to another move while the hitpause is active; also, p1 changes to a different animation after hitting p2 though it is not noticeable except for it's timing.

i hope i made the case clear. now it is about implementation.

i make two animations let's say anim and anim+1, both have the same elements, but with different timing.
i change p1's hitpause to 0.
now, when a move hits i just do change anim to anim+1 and the elem will be the same, animelemno(0).
now, toa void cancelling on p2's hitpause i do, in the cmd trigger2 = stateno =cancellable attack && ! ( movehit = [1,11]) plus the necesary animelemtime triggers so it can't cancel during hittime1,11 that is when the hitpause happens.

problem; and this is the fun stuff, the moves should only be buffered, after the input has been detected, for 3 ticks, so, the previous code does not allow for proper cancelling, as the moves are emptied from the buffer, since my charatcer is not in real hitpause.

i can think on a few ways on how to solve that problem, like implementing custom command buffering, but i find it painful and not worth the trouble; so you got any simpler ideas on how to solve that, it does not matter if that breaks something else, any ideas will do as the simpler solution might be scaping me.

i am not posting the ideas i got right now, because i don't want to influence any possible replyes.
Re: command buffering
#2  November 21, 2007, 11:13:54 pm
  • ******
    • network.mugenguild.com/pots/
also, p1 changes to a different animation after hitting p2 though it is not noticeable except for it's timing.
???
As far as I've seen, P1 keeps animating until he reaches a certain key frame, which only resumes animating when the hitpause is over.

Example:


The first two frames when she punches just keep animating during hitpauses as if she missed, but when she reaches that last punching frame (with her hair still), she only resumes the animation when the hitpause is over.

I just use something like this:

[State 200, anim]
type=changeanim
trigger1= movecontact=1 && hitpausetime
trigger1= animelemtime(2)>=0 && animelemtime(3)<=0
trigger1= hitpausetime<=7; (P1 Hitpause - Frame's Timing)
value=200
elem=3
ignorehitpause=1

This way you don't have to make any adjustments to command buffering, cancel points, corner push, etc, because P1 suffers from hitpause like he should.
Use anything you want from my works.  If you need to contact me use email, not private messages.
Re: command buffering
#3  November 21, 2007, 11:19:06 pm
  • ******
  • [E]
    • Mexico
let's assume i do not want to pause it at all...

but yeah, that one is a solution, just pause; and it has been considered too.
Re: command buffering
#4  November 21, 2007, 11:24:51 pm
  • ******
    • network.mugenguild.com/pots/
Then I think all you can do is, indeed, adding a custom command buffering system (and custom cornerpush).

Or increase the command.buffer.time values, but well... that screws them up most of the time.
Use anything you want from my works.  If you need to contact me use email, not private messages.
Re: command buffering
#5  November 21, 2007, 11:39:39 pm
  • ******
  • [E]
    • Mexico
yeah, increasing command buffer time screws time up, while it is a posibility, it is a no.

for a custom command buffering, it might require to completely modify the whole cmd, as in make the changestates varsets instead, setting the var both to a counter or something as well as the state value to change to.

another option might be forcibly animating through the hitpause, while using the hitpause of 11 for p1.
Re: command buffering
#6  November 21, 2007, 11:40:56 pm
  • ******
    • network.mugenguild.com/pots/
Use anything you want from my works.  If you need to contact me use email, not private messages.
Re: command buffering
#7  November 21, 2007, 11:47:17 pm
  • ******
  • [E]
    • Mexico
yeah, i mean tick by tick, as if the hitpause lasted 0 ticks...sorry for not explaining it completely... hten agian is almost exactly the same as your method, concept wise.

the secondary anim was going to be tickwise split, anyway. so i guess it should look something like this.

animX

previously
1,0,...,10
1,1,...,2
1,2,...,10
now
1,0,...,10
1,1,...,1
1,1,...,1
1,2,...,10

animX+1

same for this one

previously
1,0,...,10
1,1,...,2
1,2,...,8
now
1,0,...,10
1,1,...,1
1,1,...,1
1,2,...,8

anyway, the important thing is that they are aligned...

now, then

type =changeanim
value = anim +1; actually (anim + anim%2)
elem = elem +1
trigger1 = hitpause

i guess, easier to animate through the hitpause, than to mess up with a command buffer and rewrite the whole cmd
Last Edit: November 22, 2007, 12:15:51 am by R[E]ika
Re: command buffering
#8  November 22, 2007, 12:23:54 am
  • ****
  • "Moyashi tsuku shite yaru..."
I wonder what R[E]ika is trying to accomplish... It slips aways from me now. ;D
Custom command buffering rules. But in order to implement it you have to overdo your .cmd. Ah, come on, don't look for lazy ways. :sugoi:
What I do is very simple. Create a helper, set variables for directions, buttons, simple commands and their respective VarAdds as a countdowns. Then I control them in .cmd as I like.
Re: command buffering
#9  November 22, 2007, 12:41:44 am
  • ******
  • [E]
    • Mexico
the point is about having slipping hit pauses; it seemed like one of the best solutions was to implement a custom command buffer, but it  would require to recode a whole cmd; whiel animating through the hitpause does not require any cmd change.
Re: command buffering
#10  November 22, 2007, 12:48:44 am
  • ****
  • "Moyashi tsuku shite yaru..."
I doubt your version will work. While it might imitate command buffering in some cases, what about these ones:
1) You jump, enter a command near the ground, the move will be triggered after landing, or;
2) You do a jump-in, air kick, then kick before landing.
You see, there might not be an easier way. It is not so difficult after all. It will only take you approximately few hours to remake your .cns. Add a few more commands, create a helper, then replace all 'command' triggers with 'helper,var()' triggers.
Re: command buffering
#11  November 22, 2007, 12:57:48 am
  • ******
  • [E]
    • Mexico
??? i  think i did not make the point clear, most likely the topic's title is misleading for obvious reasons. the intention is having an animation that slips through the hitpause, one way to hae it was setting the hitpause to 0, but that will mess up with command buffering, hence the need of a custom command buffer. now, forcing the animation to cahnge, even on hitpause, while using the proper hitpusetime (11), works better as it won't need a custom command buffer, as mugen should buffer the commands in hitpause.
Re: command buffering
#12  November 22, 2007, 01:06:01 am
  • ****
  • "Moyashi tsuku shite yaru..."
...¬_¬''
Then stop misleading KOF players and rename the topic.
You should have started with explaining the reasons why you need this done. You still haven't mentioned it by the way.
Re: command buffering
#13  November 22, 2007, 01:18:00 am
  • ******
  • [E]
    • Mexico
i really don't want to implement this, especially if it will change greatly my cmd code.. but i have been giving this some tought.

let's say p1 has got an attack animation, it hits on a certain elements, thus triggering a hitpause for both p1 and p2; yet, p2's behaviour is rather straightforward ; p1 animates completely disregarding the hitpause, but he can't cancel to another move while the hitpause is active; also, p1 changes to a different animation after hitting p2 though it is not noticeable except for it's timing.

i hope i made the case clear. now it is about implementation.

i make two animations let's say anim and anim+1, both have the same elements, but with different timing.
i change p1's hitpause to 0.
now, when a move hits i just do change anim to anim+1 and the elem will be the same, animelemno(0).
now, toa void cancelling on p2's hitpause i do, in the cmd trigger2 = stateno =cancellable attack && ! ( movehit = [1,11]) plus the necesary animelemtime triggers so it can't cancel during hittime1,11 that is when the hitpause happens.

problem; and this is the fun stuff, the moves should only be buffered, after the input has been detected, for 3 ticks, so, the previous code does not allow for proper cancelling, as the moves are emptied from the buffer, since my charatcer is not in real hitpause.

i can think on a few ways on how to solve that problem, like implementing custom command buffering, but i find it painful and not worth the trouble; so you got any simpler ideas on how to solve that, it does not matter if that breaks something else, any ideas will do as the simpler solution might be scaping me.

i am not posting the ideas i got right now, because i don't want to influence any possible replyes.

i think i mentioned it ..

anyway, let's talk about a real, simple command buffer.

let's say i change all the changestates to varsets; that would be bad, as command priority etc.. will not work properly, unless the var is added as a trigger to the var sets, ..humh.. even so  in 11 ticks of hitpause,one can enter a qcf in the start of it, then another qcf near the end, or any other compatible sequences that would not allow for var buffering to work.. so yeah, a helper dependant system will be better.
Re: command buffering
#14  November 22, 2007, 01:30:50 am
  • ****
  • "Moyashi tsuku shite yaru..."
I don't understand the use of nullifying hitpause, adding another anim... What for?
Speaking of real command buffering, I guess I'll just show some pieces of my code.
[State -1, Command Buffering Helper]
type = Helper
triggerall = !var(0); AI var
triggerall = !NumHelper(52087)
trigger1 = Alive
HelperType = Normal
Name = "KOFcmd"
ID = 52087
Pos = 99999,99999
PosType = Left
StateNo = 52087
KeyCtrl = 0
PauseMoveTime = 2147483647
SuperMoveTime = 2147483647
[Statedef 52087]
anim = 52087

;-------------------------------------------------------------------------------
;-------------------- D I R E C T I O N A L  C O M M A N D S -------------------
;-------------------------------------------------------------------------------
[State 52087, 2xQCB]
type = VarSet
trigger1 = parent,command = "2xQCB"
IgnoreHitPause = 1
var(31) = 16

[State 52087, 2xQCF]
type = VarSet
trigger1 = parent,command = "2xQCF"
IgnoreHitPause = 1
var(30) = 16

...

[State 52087, QCB]
type = VarSet
trigger1 = parent,command = "QCB"
IgnoreHitPause = 1
var(21) = 16

[State 52087, QCF]
type = VarSet
trigger1 = parent,command = "QCF"
IgnoreHitPause = 1
var(20) = 16

...

[State 52087, Back]
type = VarSet
trigger1 = parent,command = "holdback" && parent,command != "holdfwd" && parent,command != "holddown" && parent,command != "holdup"
IgnoreHitPause = 1
var(12) = 4

[State 52087, Forward]
type = VarSet
trigger1 = parent,command = "holdfwd" && parent,command != "holdback" && parent,command != "holddown" && parent,command != "holdup"
IgnoreHitPause = 1
var(11) = 4

;-------------------------------------------------------------------------------
;-------------------------- B U T T O N  C O M M A N D S -----------------------
;-------------------------------------------------------------------------------
[State 52087, AB]
type = VarSet
trigger1 = parent,command = "ab"
IgnoreHitPause = 1
var(7) = 4

...

[State 52087, B]
type = VarSet
trigger1 = parent,command = "b"
IgnoreHitPause = 1
var(2) = 4

[State 52087, A]
type = VarSet
trigger1 = parent,command = "a"
IgnoreHitPause = 1
var(1) = 4

[State 52087, Start]
type = VarSet
trigger1 = parent,command = "start"
IgnoreHitPause = 1
var(0) = 4

;-------------------------------------------------------------------------------
;------------------------- B U F F E R  C O U N T D O W N ----------------------
;-------------------------------------------------------------------------------
[State 52087, Countdown]
type = VarAdd
trigger1 = var(31) > 0
IgnoreHitPause = 1
var(31) = -1

[State 52087, Countdown]
type = VarAdd
trigger1 = var(30) > 0
IgnoreHitPause = 1
var(30) = -1

[State 52087, Countdown]
type = VarAdd
trigger1 = var(21) > 0
IgnoreHitPause = 1
var(21) = -1

[State 52087, Countdown]
type = VarAdd
trigger1 = var(20) > 0
IgnoreHitPause = 1
var(20) = -1

[State 52087, Countdown]
type = VarAdd
trigger1 = var(12) > 0
IgnoreHitPause = 1
var(12) = -1

[State 52087, Countdown]
type = VarAdd
trigger1 = var(11) > 0
IgnoreHitPause = 1
var(11) = -1

[State 52087, Countdown]
type = VarAdd
trigger1 = var(7) > 0
IgnoreHitPause = 1
var(7) = -1

[State 52087, Countdown]
type = VarAdd
trigger1 = var(2) > 0
IgnoreHitPause = 1
var(2) = -1

[State 52087, Countdown]
type = VarAdd
trigger1 = var(1) > 0
IgnoreHitPause = 1
var(1) = -1

[State 52087, Countdown]
type = VarAdd
trigger1 = var(0) > 0
IgnoreHitPause = 1
var(0) = -1

[State 52087, Clear Vars]
type = VarRangeSet
trigger1 = NumTarget
trigger1 = !target,Alive
IgnoreHitPause = 1
Persistent = 0
value = 0
[State -1, Goufu You]; f + A
type = ChangeState
value = 325
triggerall = !var(0)
triggerall = var(15) = 2; conditions for this move; I use cancel vars
trigger1 = Helper(52087),var(1) && ifelse(fvar(23) = 0, Helper(52087),var(11), Helper(52087),var(12)); 'fvar(23) = 1' means behind the opponent; it's for reverse commands
Last Edit: November 22, 2007, 01:38:21 am by Elix
Re: command buffering
#15  November 22, 2007, 01:36:50 am
  • ******
  • [E]
    • Mexico
let's say that in certain games, when p1 hits p2, p1's animation keeps on going during the hitpausetime, but p1 can't cancel to another move until the pausetime is over.
Re: command buffering
#16  November 22, 2007, 01:43:07 am
  • ****
  • "Moyashi tsuku shite yaru..."
Which games? :o
let's say that in certain games, when p1 hits p2, p1's animation keeps on going during the hitpausetime, but p1 can't cancel to another move until the pausetime is over.
Doesn't that mean you may cancel only on certain frames? Is it vital to consider P2 hitpause? Won't 'numtarget && target,HitShakeOver' work then?
Re: command buffering
#17  November 22, 2007, 01:49:30 am
  • ******
    • network.mugenguild.com/pots/
Some annoying feedback on your buffer code:

I don't think that's all there is to KoF's buffering, there was more to it than the system taking longer to read commands than Mugen. Or did you ommit other stuff (that wasn't repeating what you have for other commands)?

And the way you reset it probably causes problems in simul mode, i.e. KO'ing one opponent resets the buffer until you get a new target (?), but then there's still the second opponent.

Plus you don't need all those ignorehitpause=1, since the helper isn't ever hitting anyone.

Which games? :o
CvS series, MvC series, SF3 series... The smoother an attack's anim the more likely it'll have it in those games.
Use anything you want from my works.  If you need to contact me use email, not private messages.
Last Edit: November 22, 2007, 01:52:40 am by P.o.t.S.
Re: command buffering
#18  November 22, 2007, 01:59:58 am
  • ******
  • [E]
    • Mexico
Doesn't that mean you may cancel only on certain frames? Is it vital to consider P2 hitpause? Won't 'numtarget && target,HitShakeOver' work then?

humh.. the frames thing is interesting,i will take that into account for the cmd;  but the main problem is that skipping hitpause screws up command buffering.
sadly, hitpauses are not always even, p2 and p1 can get different values depending on the type of hit, that is pretty common in kof's 10,12 for aerial and sliding attacks and 8,12 for fast attacks; and i am very likely going to adapt big part of it for my game anyway.
Re: command buffering
#19  November 22, 2007, 02:08:12 am
  • ****
  • "Moyashi tsuku shite yaru..."
Your feedback is never annoying, PotS.
I don't think that's all there is to KoF's buffering, there was more to it than the system taking longer to read commands than Mugen. Or did you ommit other stuff (that wasn't repeating what you have for other commands)?
Huh? >_<
And the way you reset it probably causes problems in simul mode, i.e. KO'ing one opponent resets the buffer until you get a new target (?), but then there's still the second opponent.
Oh, that -_- I added this when writing previos topic. So it isn't tested, and you're right, it will cause errors. Anyhow, I need to to clear command buffer at the end of each match, this is how it is in KOF. Should 'RoundState > 2' work? (Three months of not being with mugen... ¬_¬ )
Plus you don't need all those ignorehitpause=1, since the helper isn't ever hitting anyone.
That is correct, I will remove them. They were not working anyways...
sadly, hitpauses are not always even
Why is it sad? You can always control hitpauses with HitPauseTime and HitShakeOver. Check the triggers.
Last Edit: November 22, 2007, 02:12:58 am by Elix
Re: command buffering
#20  November 22, 2007, 02:21:04 am
  • ******
    • network.mugenguild.com/pots/
Doesn't that mean you may cancel only on certain frames?
humh.. the frames thing is interesting,i will take that into account for the cm
Cancellable attacks (as in 2-in-1, not kara cancels) in Capcom games are cancellable from the moment they start to the moment the char starts recovering (exceptions here and there), meaning that window always includes the time where the hitpause would be, which sucks right now if you're [E]. ;P

Except in MvC, where all that goes to hell. :buttrox: But you're not using MvC's combo system are you?

Quote
Huh? >_<
Like the jump-in example you mentioned, I recall that if you input a command right before you land you'll get an aerial normal according to the button you pressed, but if you hold that button until you land you'll get the aerial normal and the ground normal of the same button, so that's two attacks with a single button press which is useful if you screw up the timing of a jump-in special.

Quote
Anyhow, I need to to clear command buffer at the end of each match, this is how it is in KOF. Should 'RoundState > 2' work? (Three months of not being with mugen...  )
Why do you need to reset it? Roundstate triggers in the changestates should be enough I suppose.

Quote
Your feedback is never annoying, PotS.
Oh I bet it can be. ;P Especially when out of place like this.
Use anything you want from my works.  If you need to contact me use email, not private messages.
Re: command buffering
#21  November 22, 2007, 11:57:11 pm
  • ******
  • Legendary XIII
  • I am the eye of the storm to come!
    • New Zealand
    • network.mugenguild.com/cyanide/
Ok, so how about

Movecontact > number.

Movehit > 20 for eg would be very similar to an attack triggering after the hitpause. You're making movehit take the place of it.

Technically you're setting the cmd up partially in the .cns. You could assign variables directly to the moves in the cmd when they're activated.

Then use that variable to changestate if it's set in the .cns.

Urgh, i can't explain that in text but it makes perfect logical sense in my head.

I'd have to try it out, but can't right now. Sounds less awkward than the other methods.


In M.U.G.E.N there is no magic button

They say a little knowledge is a dangerous thing, but it's not one half so bad as a lot of ignorance.
Re: command buffering
#22  December 08, 2007, 12:21:58 am
  • ******
  • [E]
    • Mexico
back to the topic's title.. let's talk about real command buffering.

i think the helper approach is good, so, in the changestate instead of checking for command="ASSAD", you check for helper, stateno = asasdd...now,a bout actual imlementation, this is theoric and based only on my experience with a helper based ai.

we use state 200,000 for the initial helper state, state 200,000, in a way would be a "no command" condition.

if parent, command = X , we change to state 200,100; now, to buffer the command, after 5 ticks of being in state 200,101 , now  in the cmd, we change command = X to helper,stateno = 200,101.. this way we manage to offtime the commands so they trigger later.

now, to make them false, we just changestate, when time > 3 on stateno 200,101 to stateno 200,000.

now, there is a big problem, if we only check for commands in state 200,000, we can't input more complex commands while we are in the inside states... so the helper must have access to the negative states. another way would be using varsets, as if the vars were states.
Re: command buffering
#23  December 09, 2007, 03:49:52 pm
  • ****
  • "Moyashi tsuku shite yaru..."
another way would be using varsets, as if the vars were states.
This is what I've been proposing all the time.
Like the jump-in example you mentioned, I recall that if you input a command right before you land you'll get an aerial normal according to the button you pressed, but if you hold that button until you land you'll get the aerial normal and the ground normal of the same button, so that's two attacks with a single button press which is useful if you screw up the timing of a jump-in special.
You set the buffer time accordingly. You should not make it too large or too small. So when you press kick button right before you land character will start executing aerial kick but will never reach past 1st frame. Instead, standing kick will be executed on landing. I set buffer time to '4' for all button presses.
Why do you need to reset it? Roundstate triggers in the changestates should be enough I suppose.
Hmmm. That indeed could be enough. But I want everything to be rational in my code. Besides, resetting a var will save much text in .cmd :)
Re: command buffering
#24  December 09, 2007, 04:33:28 pm
  • ******
  • [E]
    • Mexico
if the var/state is used as a command, there will not be the "aerial attack trigger on the ground" problem.
Re: command buffering
#25  December 10, 2007, 01:32:14 am
  • ****
  • "Moyashi tsuku shite yaru..."
Who said there was such a problem?