YesNoOk
avatar

command buffering (Read 5699 times)

Started by Bastard Mami, November 21, 2007, 10:51:19 pm
Email this topic
View printable version
Share this topic:
« previous next »
Page 1 of 21 2 >  All   Go Down

Bastard Mami

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.

PotS

Re: command buffering
#2  November 21, 2007, 11:13:54 pm
  • ******
    • Portugal
    • network.mugenguild.com/pots/
R[E]ika said, November 21, 2007, 10:51:19 pm
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.
You can help with Ikemen GO's development by trying out the latest development build and reporting any bugs on GitHub.
My Mugen and Ikemen content can also be found here.

Bastard Mami

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.

PotS

Re: command buffering
#4  November 21, 2007, 11:24:51 pm
  • ******
    • Portugal
    • 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.
You can help with Ikemen GO's development by trying out the latest development build and reporting any bugs on GitHub.
My Mugen and Ikemen content can also be found here.

Bastard Mami

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.

PotS

Re: command buffering
#6  November 21, 2007, 11:40:56 pm
  • ******
    • Portugal
    • network.mugenguild.com/pots/
You can help with Ikemen GO's development by trying out the latest development build and reporting any bugs on GitHub.
My Mugen and Ikemen content can also be found here.

Bastard Mami

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

Elix

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.

Bastard Mami

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.

Elix

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.

Bastard Mami

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.

Elix

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.

Bastard Mami

Re: command buffering
#13  November 22, 2007, 01:18:00 am
  • ******
  • [E]
    • Mexico
R[E]ika said, November 21, 2007, 10:51:19 pm
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.

Elix

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

Bastard Mami

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.

Elix

Re: command buffering
#16  November 22, 2007, 01:43:07 am
  • ****
  • "Moyashi tsuku shite yaru..."
Which games? :o
R[E]ika said, November 22, 2007, 01:36:50 am
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?

PotS

Re: command buffering
#17  November 22, 2007, 01:49:30 am
  • ******
    • Portugal
    • 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.

Elix said, November 22, 2007, 01:43:07 am
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.
You can help with Ikemen GO's development by trying out the latest development build and reporting any bugs on GitHub.
My Mugen and Ikemen content can also be found here.
Last Edit: November 22, 2007, 01:52:40 am by P.o.t.S.

Bastard Mami

Re: command buffering
#18  November 22, 2007, 01:59:58 am
  • ******
  • [E]
    • Mexico
Elix said, November 22, 2007, 01:43:07 am
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.

Elix

Re: command buffering
#19  November 22, 2007, 02:08:12 am
  • ****
  • "Moyashi tsuku shite yaru..."
Your feedback is never annoying, PotS.
P.o.t.S. said, November 22, 2007, 01:49:30 am
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? >_<
P.o.t.S. said, November 22, 2007, 01:49:30 am
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... ¬_¬ )
P.o.t.S. said, November 22, 2007, 01:49:30 am
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...
R[E]ika said, November 22, 2007, 01:59:58 am
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

PotS

Re: command buffering
#20  November 22, 2007, 02:21:04 am
  • ******
    • Portugal
    • network.mugenguild.com/pots/
R[E]ika said, November 22, 2007, 01:59:58 am
Elix said, November 22, 2007, 01:43:07 am
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.
You can help with Ikemen GO's development by trying out the latest development build and reporting any bugs on GitHub.
My Mugen and Ikemen content can also be found here.
Page 1 of 21 2 >  All   Go Up
« previous next »