The Mugen Fighters Guild
M.U.G.E.N Central => M.U.G.E.N Discussion => Development => Topic started by: recruta42 on July 06, 2007, 02:25:38 am
-
I didn't opened this topic to talk about 'A.I. Activation method!!!'
I opened this topic to discuss about implementing and adaptative algorithm for a "learning" A.I. for mugen. Anyone already had this idea, or know a good article concerning it ?
-
As you may know, Elecbyte had started implementing "AI" , which you can do by creating an AI file, writing "ai = whatever.ai" in the def file. However, the AI file generated doesn't do much, even though people tested it a lot. At it's best, we saw that Orochi herman's Orochi guarded quite well.
Other than that, Mugen doesn't overwrite any file of any character.
Hence, an adaptative AI would only be possible during one single match : at the beginning of the match, the opponent has only the AI you actually coded, and he learns during the match. Once this match is over, he won't remember what he has just learned, since you came out of the match, and Mugen didn't overwrite any file.
Anyway, to make the AI learn something, I believe the way to do it is create one or several helpers (for the different sets of moves for example), and use the variables specific to these helpers.
During the fight, depending on how the opponent fights, the values of some variables would change, and the coded AI would react depending on the value of these variables.
For example (lame one, but whatever) : after 3 seconds of attacks, if none of the attacks touches the opponent, while p2bodydistx and p2bodydisty <15, then it means he's guarding. Set variable 1 of the helper called adaptative_ai to 1.
Then, in the already coded AI, the randomization for throw would change depending on the value of this var(1).
In a full game as yours, it may be possible to see if the opponent keeps jumping, or keeps using the same attacks, or whatever, keep record of that, and set variables to act accordingly to the opponent's style... but it's seems like a very hard work.
You may want to ask r[E]ika about this one. IINM, he was interrested in developping such kinds of AI, and may have thought a bit about it.
-
as cyb said, you can't really make an adaptative one, as it can't remember anithing form figh to figh, a helper tree based system seems like the best answer, as, based on certain atributes of the fight, it can slightly adjust the strategy. like, stand close to the oponent when hw is about to wake up, then do a meaty attack, if the character gets grabbed, it should be now aware he is fighting against a grappler and take the encesary measurements.
-
Isn't that the way everyone codes AI? Using decision trees?
-
We're talking decision trees based on your actions rather than your position and proximity.
If you tend to always throw out a super when p2 is waking up the AI will react to this by standing up blocking as any human would do. That sort of thing.
Current AI's would make that random.
-
I thought the game's difficulty would overwrite the AI.Then what's the point of a Difficulty level then?
-
It still works for chars that don't have custom A.I., which I believe is the majority of them.
-
Anyway, to make the AI learn something, I believe the way to do it is create one or several helpers (for the different sets of moves for example), and use the variables specific to these helpers.
Specific to that helper? What do you mean, this?
triggerall = NumHelper(1000) && var(1)
I forgot, will setting a variable inside a helper overwrite parent' s var? Or does helper have its own variable set? Meh, unlikely.
-
Latter. Each helper has its own set of vars, fvars, sysvars and sysfvars.
-
Latter. Each helper has its own set of vars, fvars, sysvars and sysfvars.
:o This is... l337! ;D
-
the problem wiht learning is that the vars get reset before any real learning can happen.
-
the problem wiht learning is that the vars get reset before any real learning can happen.
Not at all. Properly written AI would be able to learn really fast. It won't be so noticeable in Round 1, but the more rounds played, the smarter will be the AI. It was clear from the beginning that AI cannot save its experience throughout the battles so we don't even speak about it.
Or what did you mean? When do vars reset?
-
unless you use the ai as a companion for simul, it's vars willo only last 2 or 3 rounds, even less in turns mode; so a learning ai is pointless in that situation. on the other hand, an adaptative ai, and better methods to write ais are completely worth discussing.
-
Why would vars exist 2-3 rounds?
-
???
Unless you reset them at the beginning of each round, the variables for a character last a whole fight. But they don't stay beween fights.
They even last between matches in arcade mode for example, as long as you don't lose a match (in win and lin mugen) and as long as you press continue in DOS Mugen.
That's how the Level system works for Randy Mc Green by Splode, and how the shop system works for Link (Zelda) by RMX Silencer and Mike Werewolf.
-
???
Unless you reset them at the beginning of each round, the variables for a character last a whole fight. But they don't stay beween fights.
Yes, that's why R[E]ika's post confused me.
And do you know about survivor (endless) mode? Do vars persist between fights?
-
Good question. I'd have to check using Randy or Link tonight after coming back from the office.
-
guys, guys, guys, we are talking about ai's there, there is no point on the vars lasting more than one fight, if teh character for the next fight is going to be a different one.
-
guys, guys, guys, we are talking about ai's there, there is no point on the vars lasting more than one fight, if teh character for the next fight is going to be a different one.
There IS point in that :P As I've said, it takes only one time for AI for it to learn. P1 got hit under certain conditions -> it won't happen again (roughly).
-
oh, then now i get what you mean by "learn", let's not use learn, but use adapt, shall we ?
-
guys, guys, guys, we are talking about ai's there, there is no point on the vars lasting more than one fight, if teh character for the next fight is going to be a different one.
Not agreed (even though I know it's impossible in Mugen).
When Kasparov plays chess against the almighty I_don't_remember_its_name computer, the computer has "learned" many strategies from all the previous matches he has done, whether it was against Kaparov or not.
The computer learnt from his mistakes and won't make them again.
That's what would be nice in a Mugen AI : always learning. And even if the character you meet after is different, if the AI can recognize some bits of strategy in your fighting style from a previous fight he had 5 months ago, then he would use a strategy he had developped to counter you.
But yeah, as I said, it's impossible to do in Mugen, and such sort of learning AI is impossible to code correctly without spending months (or years) on it.
-
oh,i tried to keep this in the mugen context, so i agree wiht you on most points, but now, let's talk more about what can actually be done (in mugen).
ai activation code. let's not talk about this , as R put it, is boring and deceiving to read an ai topic expecting tips and strategies and end up reading onyl implementation issues. let's assume we already have an isAi trigger or a varN that signals the ai is on.
the ais that i have seen are pretty much random trigered, based on the current instant situation; for starters, has anyone seen anithing different?
-
I'm just wondering this, you know....everyone's been so concerned with "Mugen's AI"....you know? It's Mugen "this" and Mugen "that," but what about the characters themselves? I mean, it's the AI of the character, isn't it?
The AI of mugen would be that it learned how you fought, and for this character, he would recognize it and adapt accordingly, but it's unfair to the player if the computer learns how he fights and then keeps that knowledge in the next battle, eventually, you'd never win! The character should learn individually.
Is this possible?
What if an additional AI code or something were added to each character so that it learns what people do, and then at the end of the fight, after Mugen has been upgraded to hold some sort of Doc-reading/saving program, the engine saves the information in the Mugen character file, then the next fight begins, and that character learns as well, so on, so forth.
That's the way I'd see it happening...the only way as well...
-
yeah, that's nice theory, but since it is not going to happen unless elecbyte udpates mugen wecan discount that.
a regular limitation with character ais is that their reactions are tick wise, and the character's state coding has nothing to do witha mindset state. emulating a mindset state is necesary to make better ais.
-
If we are to speak about terms, I prefer the term "dynamic" AI over "learning" and "adaptive".
I started to think about a dynamic AI long before this topic was created. I guess these thoughts often visit some seeking creators. So I decided that my Serious Kyo will have a dynamic AI for sure.
As I've been studying MUGEN for quite some time, I know its possibilities. And preserving AI's experience in MUGEN files is impossible so let's not even discuss it anymore.
ai activation code. let's not talk about this , as R put it, is boring and deceiving to read an ai topic expecting tips and strategies and end up reading onyl implementation issues. let's assume we already have an isAi trigger or a varN that signals the ai is on.
Have you forgotten WinAne's AI activation method? It rules and solves the problem of AI activation.
the ais that i have seen are pretty much random trigered, based on the current instant situation; for starters, has anyone seen anithing different?
What do you mean by random triggering? I call random triggering the default MUGEN's AI. If a ChangeState controller have triggers like this I wouldn't call that random triggering:
[State -1, Shippu Jinrai Kyaku AI]
type = ChangeState
Value = Ifelse(var(1) = 3, 3400, 3200)
TriggerAll = var(9) && random < 100*var(9)
TriggerAll = StateType != A
TriggerAll = Power >= 1000 || var(15)
TriggerAll = p2Life >= 150
Trigger1 = (p2bodydist x = [50, 70]) || (var(1) = 3 && p2bodydist x = [50, 100])
Trigger1 = ctrl || stateno = 100 || (stateno = [120,131])
Trigger1 = p2statetype != A
Trigger1 = p2movetype = A
Trigger2 = p2bodydist x <= 50
Trigger2 = movehit
Trigger2 = var(3)
Trigger2 = (StateNo = 300 || StateNo = 310 || StateNo = 500)
Trigger2 = !var(1) || var(1) = 3
Trigger3 = movehit
Trigger3 = P2StateType != A
Trigger3 = power >= 1000+1000*(var(15) = 0)
Trigger3 = StateNo = 1100 && AnimElem = 4, >= 0
Trigger4 = projhit1000 = 1, = [1,5]
Trigger4 = P2StateType != A
Trigger4 = power >= 1000+1000*(var(15) = 0)
Trigger4 = StateNo = 1000 && var(18)
Trigger4 = p2bodydist x = [50, 70]
This is taken from Don Drago's Ken Masters. And although his AI is really great (one of the most sophisticated AIs out there) there is no dynamic AI in there.
The idea of a DAI came up to me when I remembered my own AI patches to fall for the same traps over and over again. I though it would be good to at least have some variables that describe the conditions of those traps. Here's one of the simplies examples of a DAI that I'm going to use in my Kyo:
1) Kyo does a jump-in and attacks P2;
2) But he gets hit on his own attack frames;
3) Kyo does a jump-in again and makes sure he's as close to P2 as possible;
4) But he gets hit again;
5) Each time a variable increases, which leads to decreasing the chances of jump-ins triggering. (trigger1 = Random < 500/var(10))
You would agree that it's always harder to fight an unknown enemy. Because you don't know what to expect. It takes you many times before you would know this enemy. After that you can effectively oppose him. For AI this process goes much faster. I can even do so that Kyo will never do jump-ins on that opponent after he gets hit once, but that would take away the human-like feel of AI.
-
yeah, we are getting on topic again, you can use several ai vars, for each and every factor you want to take into account, that means it can be memorized between round. iirc helpers get destroyed between each round, so the ai will be reset when the round start IF you put the vars in the helpers. for some situations using a state map so the character knows more about the current status of the fight can optimize the ai code and maybe even give it unique twists. so the ai can be split in two.
1. instant reaction. ai code in state-2 (or -3 or -2) this is a set of changestates to the normal moves evaluated form top to bottom, if one of them evaluates true the rest should stop being evaluated if the ai rules are properly coded, talking about ai rules, the ai should obbey the same conditions as the player.
so, a start for this ai would be copy pasting your regular changestates used in st-1. ideally your player's changestates are structured like this.
type= changestate
value = value of the move
triggerall = command
trigger1 = situation 1 in which the move can be performed; example you have control
trigger2 = situation 2 in which the move can be performed; example combo cancel.
[EDIT]
so, you take out the command in the trigger all and put the ai ctrl condition there.
that will make it so whenever the ai is in ctrl it will perform the move which is bad, even if it will follow player rules. after the situational conditions are written or to be more clear appended. so it now looks like this.
type= changestate
value = value of the move
triggerall = commandai is in control
trigger1 = situation 1 in which the move can be performed; example you have control
another trigger1 = situations that make this move a prefered move if the situation is 1
trigger2 = situation 2 in which the move can be performed; example combo cancel.
another trigger2 = situations that make this move a prefered move if the situation is 2
using a random factor or the variables you talk about to modify the new "another triggers".
-
So with all of this you can alter a character's AI?
-
more like, general guidelines on how to code an ai...
-
Ok so what do I have to do to make a character smarter or dummer?
-
give hima smarter or dumber ai...quoting form one of my previous posts
1. instant reaction. ai code in state-2 (or -3 or -2) this is a set of changestates to the normal moves evaluated form top to bottom, if one of them evaluates true the rest should stop being evaluated if the ai rules are properly coded, talking about ai rules, the ai should obbey the same conditions as the player.
so, a start for this ai would be copy pasting your regular changestates used in st-1. ideally your player's changestates are structured like this.
type= changestate
value = value of the move
triggerall = command
trigger1 = situation 1 in which the move can be performed; example you have control
trigger2 = situation 2 in which the move can be performed; example combo cancel.
if you want to have more control you cahnge the triggerall to
triggerall = command
triggerall = ai is NOT in control
so the character will only do what the ai does.
-
Ok I see.Thanks girl for the info.
-
back to topic:
to get the ai into a mindset without using too many variables, i think it's easier to use states. but since the character already has it's own states for it's code, a helper that enters the ai states should be better, that way it's states can be checked by the player for reactions, and more complex decisions can be made whitout overcomplicating the parent's code.
[EDIT]
let's have the helper with if 100,000 and start instate 100,000, i will slkip the 100,000 but it can be assumed that all statenos i talk about are + 100,000.
so, for helper state 0 , it means the initial state, full health, if the character is a close range fighter it shoudl try to get near p2, so the helper changes to state 1, which hints the parent's ai that he should do stuff that makes him move closer to the oponent. inside the helper states you can check for different conditions that make hint the parent ai to perform differently.
this would look a lot better with drawings.
-
Helpers really do destroyself at the end of the round :-X So then, helper's vars should be used to define inbattle tactics, depending on properties true only in this round (P1 & P2 life and so on). Player's vars should be used to store valueable information about P2 which is not better be lost after a single round.
-
yes , exactly, i will try to come out wiht more examples on using helper's states as state maps for the ai later, might evne edit this post.
-
actually as far as i know, ai is all about triggers...
but first you'll have to make the ai not able to exicute some moves in the cmd filer to have the best ai lvl possible.
var(0)= 1
:P
afterwards it all depends on teh triggers you use.
for an example
[state-1:****(what ever the command of the attack is]
type: changestate
value:(you can use a normal value, but this is to make things more accurant)IfElse(p2bodydist X < 10, 201, 200)
trigger1: it could be anything, p2dist x<=> any number you choose
could be power(your power)<=> ****
life, ,roundstate, p2statetype...you can use id trigger to make your character chain combos, and if done very accurantly, you'll come with something close to unending combos, like drak athena for example/
as for guarding, well instead of putting them in state -1..id trigers depend of the id of teh last hit def of each attack :P
you should try to put them isntead -3 cause it never worked for me in state -1 .
and again it all depends on triggers.
then come matters more complicated like generating parries after defense, which follows a base smilar to id triggers.
-
The discussion is about Dynamic A.I,not linear a.i.
-
on a similar topic, using a single var's values to randomize chances is easier to code and read that relatively complex random expressions.
having something like:
varset: value = random % 6
for 6 different outcomes, based on the current situation.
-
I tried reading all of teh topic and I got to a page and a half before getting frustrated. Sorry if teh following isn't completely informed due to that
The idea of a DAI came up to me when I remembered my own AI patches to fall for the same traps over and over again.
"Over and Over again" will continue to occur because presumably you character is getting "hit". It is a well known fact that the "counting hits" in any form for mugen is a major drawback for the engine. So the char will more than likely fall into the same traps over and over no matter what you code.
About the issue of assigning var(?)s
Well from what I've read so far it seems like what we really want to code in is:
authornames, enemy names, etc. for adapting to players, at least :S. Only thing I could think of that could last for a long enough term for an AI to become 'semi-adaptive.'
Vars, yes, would always be necessary in every situation though.
If this issue was between player vs. AI (which is more likely, because AI is completely set in its ways, whereas a player can change his/her strategy very easily) then I believe that there are only a few scenarios in which AIs can be made adaptive.
1. enemy, bodysist x < ? && time > ? && life < ?
2. enemy, numproj >= ? && time > ? && life < ?
3. enemy, statetype = A && X (rarely gonna work) - hitcount >= ? or counter >= ?...
4. A few others that I'm too lazy to type.
Also just a side-note for player/AI differenciation, I guess you'd have to have every character you faced defined under two specific vars. A var where teh AI for a char is present and a var for where it is not.
But, yes, as Cyb said, many situations would arise where a randomly activating var would have to activate which could screw up the whole thing or else you'd have to create a cheating AI
E.G.:
http://www.youtube.com/watch?v=ng2kfKE-8is
If that were to be fixed then regular situations would become 'broken' (in both senses) in the char so it wouldn't be a completely effective idea.
Var overriding, as I believe PotS said, is almost impossible to avoid. Mugen can activate it's own and 'disobey' (shocker :o), in the form of some glitches that still lie in the system.
As for constant adaptation goes, The most I could probably think of for that would be only as far as new rounds come, but probably not match to match.
Mugen does store information as it quits, but also seems to lose it, just as well/easily (LOL). If the program could be rewritten to write this info based on teh creator's choice into specifc chars with the addition of new commands, then there possibly would be a way to force the AI to adapt, but as is... Doubt It's Possible. Mugen does have it's overload points
Just a question:
Does anyone have a proposal as to how to activate new AI vars based on what event happened at the end of a round?
I know that a few chars can change forms based on the roundnos but, can this be done based on teh event?
-
I'm not really sure how accurate a lot of what you're saying is.
Var overriding, as I believe PotS said, is almost impossible to avoid. Mugen can activate it's own and 'disobey' (shocker Shocked), in the form of some glitches that still lie in the system.
Mugen does not ignore variables. I've never seen anything i've coded using variables ignore them unless i've done something dumb that allows it to. If this is to do with your AI experiments i'm sure we explained this.
Mugen is able to store variables between rounds using the intpersistindex and floatpersistindex settings in the .cns file. I use these on the characters i give AI so second and 3rd rounds don't require activation again.
I suppose with some effort you could save a set of variables (10 or so) in your character and use specific values on them that describe the actions of your opponent
var(10) = 1, opponent is a proj whore who tends to block.
var(10) = 2, opponent is a proj whore who doesn't block
and so on. Rather a long process trying to implement every play style into a few variables. Mixing up the variables with each other and different values could give you something saveable, for 1 fight.
Full game, p1 could have a helper setting it's own variables and the CPU could read the values on those and know how to act from that.
enemynear(0), var(10) = 2> processing> enemy is in crouch state> processing> block low followed by block high, evade.
enemynear(0), var(10) = 1 && enemynear(0), var(11) = 8, enemy is using jump attack block high, block low, use close range super.
I believe this is possible but the amount of effort you put in wouldn't REALLY differentiate it that much from someone with a good random system and enough counters in place.
-
Var overriding, as I believe PotS said, is almost impossible to avoid. Mugen can activate it's own and 'disobey' (shocker :o), in the form of some glitches that still lie in the system.
what
I don't remember saying anything like that, Mugen will only "activate its own and disobey" if you're using sysvars without adapting the common states or if the opponent is flawed and messes with your vars during custom states.
-
i would rather use a state map , it has to be put in the helper, though otherwise it will mess up the player. another good point of those is that you can immediately move to a different map if you detect special opponents.
(yet another) example of a statemap.
fight starts. my player calls helper "AIstatemap" , and that helper's starting state is state 100,000.
[statedef 100 000]
;this is the starting state, herewe can check soem stuff and guess possible future actions.
;a lot of this can be reused for later states in the statemap.
; even some general checking can be added in state-2 with an ishelper 100 000 trigger to cover more stuff.
; the point of this is getting the ai code as apart from the char as possible.
; this changes to getting away from p2
type =changestate
value = 100 001
trigger1 = p2dist X < 100
; this changes to getting near to p2
type =changestate
value = 100 002
trigger1 = p2dist X > 100
; you keep on coding like that inside the helper's states for more situations
;then in the parent you check the helper state to know about the ai current mindset
type = changestate
value = shoryuken
triggerall= AI
trigger1 = helper 100,000 , stateno = 100,001 ; i.e., if we are geting away, we have higher chances of retaliating with a dp because
; p2 is near and he is following us
-
Var overriding, as I believe PotS said, is almost impossible to avoid. Mugen can activate it's own and 'disobey' (shocker Shocked), in the form of some glitches that still lie in the system.
Mugen does not ignore variables. I've never seen anything i've coded using variables ignore them unless i've done something dumb that allows it to. If this is to do with your AI experiments i'm sure we explained this.
My comment really is as far as my own experience goes.
I'm someone who hates coding in states dealing with AIR so I usually have a code in each of the chars I create and AI for, that triggers a dodge state as soon as stateno = 40 (if a char does have this as the jumpstart anim/state) is triggered randomly by the default AI, to be activated 100% of the time.
I have seen many of my AIs disobey what I have coded, a really low percentage of the time mind you. I'd have to guess it would be about 2% of the time, because I've run over 300 trials of this (by simply watching my AIs fight) where the dodge state triggers more times than the jump, but where the jump may still complete itself.
Var overriding, as I believe PotS said, is almost impossible to avoid. Mugen can activate it's own and 'disobey' (shocker :o), in the form of some glitches that still lie in the system.
what
I don't remember saying anything like that, Mugen will only "activate its own and disobey" if you're using sysvars without adapting the common states or if the opponent is flawed and messes with your vars during custom states.
That's my bad. It wasn't you and I believe I misread the post that I was referring to. I'm too lazy to re-read this topic right now, but again, I'm pretty sure I must have misread something. :S
Side-Note:
We need a :shrug: smiley.
And I wanted to type a :huh get it: smiley or a :beg: smiley after that little side-note.
-
I have seen many of my AIs disobey what I have coded, a really low percentage of the time mind you. I'd have to guess it would be about 2% of the time, because I've run over 300 trials of this (by simply watching my AIs fight) where the dodge state triggers more times than the jump, but where the jump may still complete itself.
And as i stated in the other thread, this would be because there is also an evade state the human player can use. Just because AI is on does not mean this state will never be used. The default mugen AI is still in effect. Thats why moves that aren't specified in your AI code can still occur.
That would be something to consider for adaptative AI, disabling basic changestates if you plan to use it. Simple but not thought of.
-
I have seen many of my AIs disobey what I have coded, a really low percentage of the time mind you. I'd have to guess it would be about 2% of the time, because I've run over 300 trials of this (by simply watching my AIs fight) where the dodge state triggers more times than the jump, but where the jump may still complete itself.
And as i stated in the other thread, this would be because there is also an evade state the human player can use. Just because AI is on does not mean this state will never be used. The default mugen AI is still in effect. Thats why moves that aren't specified in your AI code can still occur.
That would be something to consider for adaptative AI, disabling basic changestates if you plan to use it. Simple but not thought of.
I do disable the default AI states.
I always put in
triggerall = !var(59)
For commands I don't want to activate when the AI already has.
And as i stated in the other thread, this would be because there is also an evade state the human player can use. Just because AI is on does not mean this state will never be used. The default mugen AI is still in effect. Thats why moves that aren't specified in your AI code can still occur.
BTW I wasn't the one who asked about that. I think you may be mixing up my post about "Problems with Mugen Creation" with something else.
-
there are hard coded commands, like walking and jumping that still occur, as cyanide pointed out. you can try to ctrlset to 0 when the ai is on.
-
there are hard coded commands, like walking and jumping that still occur, as cyanide pointed out. you can try to ctrlset to 0 when the ai is on.
Yeah, but sometimes that leads to glitches or else freezing @_@
I usually just run over it by coding in a dodge state whenever the jump is triggered where I don't want it.
BTW R[E]ika got some new info for you ^_^
-
Make ChangeStates for standard commands. That could prevent AI from random changestates. Am I wrong? Examples:
[State -1, Jump]
type = ChangeState
value = 40
triggerall = !var(0)
triggerall = StateType != A
triggerall = Ctrl || StateNo = 100
trigger1 = command = "holdup" && command != "holddown"
trigger2 = command = "highjump"
[State -1, Walk]
type = ChangeState
value = 20
triggerall = !var(0) && Ctrl
triggerall = StateType = S
;triggerall = Pos Y = 0
triggerall = P2MoveType != A && !InGuardDist
triggerall = command != "holddown" && command != "holdup"
trigger1 = (command = "holdfwd" && command != "holdback") || (command = "holdback" && command != "holdfwd")
[State -1, Crouch]
type = ChangeState
value = 10
triggerall = !var(0) && Ctrl
triggerall = StateType = S
;triggerall = Pos Y = 0
triggerall = P2MoveType != A && !InGuardDist
trigger1 = command = "holddown"
-
Make ChangeStates for standard commands. That could prevent AI from random changestates. Am I wrong? Examples:
[State -1, Jump]
type = ChangeState
value = 40
triggerall = !var(0)
triggerall = StateType != A
triggerall = Ctrl || StateNo = 100
trigger1 = command = "holdup" && command != "holddown"
trigger2 = command = "highjump"
[State -1, Walk]
type = ChangeState
value = 20
triggerall = !var(0) && Ctrl
triggerall = StateType = S
;triggerall = Pos Y = 0
triggerall = P2MoveType != A && !InGuardDist
triggerall = command != "holddown" && command != "holdup"
trigger1 = (command = "holdfwd" && command != "holdback") || (command = "holdback" && command != "holdfwd")
[State -1, Crouch]
type = ChangeState
value = 10
triggerall = !var(0) && Ctrl
triggerall = StateType = S
;triggerall = Pos Y = 0
triggerall = P2MoveType != A && !InGuardDist
trigger1 = command = "holddown"
The thing about that is that sometimes the code for the jump isn't located anywhere within the character.
I don't know why, (me being a lazy person, I never put a lot of effort into checking), but I assume the common.cns can take care of the jump at default.
Moreover, many chars I've seen don't even define the jump ( [statedef 40] or otherwise ) which has left me stumped. Nowhere in the CNS, nowhere in the CMD and I'm just lost as far as that goes.
-
mugen's internal ai will sstill trigger the jump as long as you have control, that's why the assert specials for nowalk were created.
-
mugen's internal ai will sstill trigger the jump as long as you have control, that's why the assert specials for nowalk were created.
Thank You :wall:
Man that makes everyting so much harder. @_@
BTW I sent you a PM ^_^
-
yah, i noticed. about the prevstateno thingie, that's why i suggest statemaps, though i know implementing statemaps just like that is hard.
-
though i know implementing statemaps just like that is hard.
I'll learn.