-
Guess it's about time I publically released this.
http://www.mugenguild.net/~winane/tutorial/index.html (http://www.mugenguild.com/winane/tutorial/index.html)
Questions? Comments? Critiques? Concerns? Sexual favors?
Please make your characters' CMD files compatible, even if you don't intend to give them any AI. (See AI activation code.txt for a brief explanation.)
At the moment, I've basically only provided the code itself and directions for how to implement it. But once I find the time (and motivation), I plan to add some explanation of how it all works. If you don't entirely understand the whys and wherefores of the code at the moment, please don't let that scare you away from using it, for all will be revealed in due time.
Reasons to use this code instead of other AI activation code:
-The old palette-based method limits the number of palettes (and palette-based modes) a user can choose from.
-The old humanly-impossible commands method is slow, and doesn't work with Linux Mugen 04.14.2002.
-The XOR method alone is twice as effective as the old humanly-impossible commands method for any given number of CPU commands.
-None of the previously released versions of the helper method were reliable. All allowed the human user to activate the AI in certain circumstances.
-The previously used IsHomeTeam methods were good, but don't work in all situations.
Does anyone think it would be worth also providing stand-alone explanations/versions for each of the component methods? Would it significantly help people understand the code? Would it help them understand how to modify the code when necessary or desirable?
-
Does anyone think it would be worth also providing stand-alone explanations/versions for each of the component methods? Would it significantly help people understand the code? Would it help them understand how to modify the code when necessary or desirable?
It would help indeed.
Note that Clark already uses this method.
-
Damnit, that's not the answer I was looking for! >:( >:(
You were supposed to say "No, there's no need for that, it's quite clear as it is." :P :)
Anyway, is this sufficient?:
http://www.mugenguild.com/winane/tutorial/AIcomponents.rar
-
No, there's no need for that, it's quite clear as it is. >:( >:(
This should do it.
-
Okay, thanks for the feedback. :)
I just noticed that one of the more crucial paragraphs (the one below, in fact) wasn't very clear, so I uploaded an update just now.
Also, it occurred to me that if I want people to make their characters compatible regardless of whether they're giving their character any AI, I probably shouldn't be so lazy and make them find the relevant info. So, here's the part that I hope people will adopt:
The 11 standard Single Button and Hold Dir commands must be placed at the top
of the CMD, above all other commands, and in the standard order shown in the
code (the same order as has always been in Elecbyte's KFM),
in order for the "Compatibly Partnered" version (9742) of the helper AI
activation method to work with different partners in simul team mode.
(When the partner is not compatible, then it's best to just use the regular
version (9741) and rely on the XOR method for backup in case a human
partner's input turns off the CPU partner's AI.)
Now, even if you do not intend to give your character any custom AI, it
would still be nice if you would place the commands at the top of your CMD,
for the sake of other characters which do use this AI activation method.
And then, define Anim 9741 in your AIR file to indicate to other characters
that your character is compatible.
It may slightly increase the chances of faulty AI activation if the user is
using certain characters with a poor implementation of the old humanly-impossible
commands AI activation method when fighting against your character, but
other than that, there's really no particular reason not to.
And note that you can change the names of the commands if you want.
All that really matters is the "command" and "time" parameters.
-
I just made some tweaks, and uploaded an update.
Most significantly, I decided it would be silly to continually add character names and author names to the 9742 helper creation controller's triggers. So, I decided to just check whether Anim 9741 exists in the partner's AIR file. I scanned the 760 characters in my chars directory, and didn't find a single instance of that anim being used for anything else, so it should work most of the time. And if there are any incompatible characters with that anim defined, it doesn't really matter that much (as it would simply result in a little unnecessary processing for your CPU to do, and occasionally would slightly delay AI activation). Any objections?
I also realized that one little part of the code was kinda useless and removed it. And so, the dir commands don't really have to be placed at the top of the CMD anymore (the button commands still do, though). But, it would still be nice to keep them there, in case I change my mind about that (e.g. for a DOS-only version of the code), or in case anyone else wants to do anything involving partner or enemy basic command detection without placing anyone in a custom state.
If you've got some time, please test out the update thoroughly, just in case I screwed anything up.
Edit: In case anyone downloaded the code in the last couple hours, I just now noticed a couple more little things that needed fixing, and so uploaded another update.
-
About the helper method, I've just discovered that I can probably ditch the GameTime variable if I use hold button commands (e.g. "/x", which are not buffered during pauses/superpauses) instead of regular button commands (e.g. just "x", which have a single command buffer size during pauses/superpauses). That would eliminate the need to use a parent variable for the pause/superpause check, and I could use a couple parent,AnimExist triggers to replace the parent variable's custom state check functionality. So, what does everyone think would be better?:
Option 1:
GameTime parent variable required (might occasionally come in handy for your own stuff, but not usually).
No extra commands used beyond the 11 Single Button and Hold Dir commands found in KFM and used in most other characters. (More if you want to use the XOR method too, but that's irrelevant for the question.)
Easier to convince everyone to put those 11 commands at the top of the CMD, since they wouldn't be adding anything, they'd just be moving them. (Consequences of non-compliance are minimal, however--just a little unnecessary computation for your CPU, and every once in a while slower AI activation.)
A single blank anim required in the AIR.
Very reliable.
Option 2:
No GameTime parent variable required.
7 new commands required, which may come in handy for other stuff, but then again might not: /a, /b, /c, /x, /y, /z, and /s.
More difficult to convince everyone to put those commands at the top of their CMD, since they usually won't be using them.
Two blank anims required in the AIR (the second one only present to decrease the likelihood of a false compatibility detection).
Usually reliable, but if the character gets put in a custom state by an enemy character who just happens to have the two rare anims I've chosen to indicate compatibility, and yet isn't actually compatible, then the character's AI could be erroneously activated when controlled by a human. (Note that this would be the only false positive possible in all the code I've written, short of the AI variable directly getting overwritten in a custom state by a rude and poorly coded opponent/partner.)
Probably slightly more efficient code, and occasionally slightly faster-acting, but not really significantly so.
Note that each character can use up to 60 integer variables (minus at least 1 for the AI flag) and 40 float variables, and can have up to 128 unique command names. Which is more precious?
I suppose I could have two versions, two standards, so that everyone could choose depending on whether they're running out of variables versus running out of command names. Anim 9741 could indicate that the first 11 commands are the standard KFM commands, while the additional presence of Anim whatever# could indicate that those 11 are followed by the 7 hold button commands.
Thoughts?
-
1°) Stop bumping your own topic. You won't live fame with this. >:( ;)
2°) Option 1 is better IMO since option 2 only offers few improvment but is "harder" to put up (lazy creators :p) and there are fewer requirements for option 1. But the fact that you can offer 2 versions of your AI code is quite interesting. :)
3°) Why am I the only one to reply ? :(
-
I would go for option 2. Someone is more likely to have open command space than open variable space even if they don't need half the variables they use. :p
Maybe you could use a free float variable :huh: unless you need an integer.
-
One vote for each, so I think I'll go ahead and have both versions available (I actually kinda answered my own question above, but felt like asking it anyway =P ). I'll make the 1-variable version pretty soonish.
For the second Anim number, I think I'll use 74140108. I spent almost an entire minute reading through all 760 AIR files in my chars directory again, and didn't find a single instance of it. So, any objections to it?
(Note that this would be the only false positive possible in all the code I've written, short of the AI variable directly getting overwritten in a custom state by a rude and poorly coded opponent/partner.)
Dangit, that was supposed to be everyone's cue to prove me wrong. Seems my reverse psychology only worked on myself. :-\ :-\
I noticed that the AI could be erroneously turned on if a custom state was interrupted by a SelfState during a HitPause, so I've uploaded a fix. I also modified the XOR stuff to be more effective in Linux, using the commands for the upcoming 1-variable version of the helper method.
Maybe you could use a free float variable :huh: unless you need an integer.
A float would probably work for the AI var(s), but you only get 40 of those, and most people's AI code already makes use of an int so it would be a bit of a nuisance for them to replace all instances of it. As for the GameTime variable, GameTime is an integer value, so there'd be a type mismatch putting it in a float variable.
-
I vote 1 o/
It's only 1 extra variable and much easier to do.
Why is it required that the commands are in the top of the .cmd?
also.. the helper method will trigger the AI when the AI inputs any command right? But isn't that the same thing the XOR method does?
-
I vote both. :P And it's not really easier. It's just that the 1-variable method will be .0000000000001% less reliable, due to the possibility of a noncompliant character including both of those anims.
The CPU can either simulate a key press, triggering commands the way a human does; or, if AI.Cheat = 1, then it can also choose commands by name directly. It generally has a strong preference for simulated key presses, however. The helper method detects those simulated key presses (and 11 of the directly selectable commands), whereas the XOR method only detects the direct command name selection (and only for the commands you include in the XOR VarSet controller). The more commands you use for the XOR method, the faster it'll tend to be, but the helper method will usually still be faster than it.
Edit: Whoops, sorry, forgot to answer this:
Why is it required that the commands are in the top of the .cmd?
Short answer: Because of the way command processing works. :P
Fine, longer answer: Mugen creates an array of 128 command names for each character. If you try to detect a partner's or enemy's command (e.g. partner,trigger# = "x") without putting them in a custom state, then, Mugen doesn't try to find the command with the name you specified in their command list. Rather, it checks the array index of the command name you've specified in your CMD, and then checks whether the command with the same index in your partner's/enemy's command array is activated. So, in order to detect partner or enemy commands, you need to make sure that matching commands are in the same place in each character's command array. The way to do that, is to put them in a standard order at the very beginning of the array, which is done by putting them at the top of the CMD. (This is a little bit of a problem if such a character's opponent is flawed in that they have an impossible-command AI activation method VarSet in State -2 plus the AI activation commands defined at the top of the CMD (the combination of which is annoyingly common), resulting in the opponent's AI being erroneously activatable by a human while in your character's custom state. But that's easily fixable enough, simply by moving the VarSet to State -1 or State -3 where it belongs.) Putting the standard commands all at the end of the array wouldn't work, because different characters have differing numbers of commands, and it would be silly to pad the array with unused commands just to make sure the standard ones are all at the end.
-
1°) Stop bumping your own topic. You won't live fame with this. >:( ;)
I call it civil disobedience, just without the significance. 8) 8)
Anyway, it just occurred to me, might anyone find this useful?:
; CMD, wherever
[Command]
name = "AIswitch"
command = s,s ; Or change this to whatever, if you're using this command string for another command.
time = 12
; CMD, under [StateDef -1]
[State -1, AI Switch Helper Check]
type = ChangeState
trigger1 = IsHelper(9740)
value = 9740
; ST, under [StateDef -3]
[State -3, AI Switch Helper]
type = Helper
trigger1 = !NumHelper(9740)
trigger1 = RoundState = 2
trigger1 = Alive
HelperType = normal
name = "AI Switch"
ID = 9740
pos = 9999999,99999
StateNo = 9740
KeyCtrl = 1
PauseMoveTime = 2147483647
SuperMoveTime = 2147483647
; ST, wherever
[StateDef 9740]
type = S
movetype = I
physics = N
anim = 9741
ctrl = 0
[State 9740, Safety]; Just in case your opponent is very poorly coded.
type = SelfState
trigger1 = !IsHelper
value = 0
[State 9740, Switch]
type = ParentVarSet
trigger1 = command = "AIswitch"
;Enable the next line if you only want to be able to switch while you're in control of the character.
;trigger1 = Parent,command = "AIswitch"
var(59) = !(Parent,var(58)) ; Assuming var(58) is your primary AI variable.
[State 9740, Sayonara]
type = DestroySelf
trigger1 = !(Parent,Alive)
trigger2 = RoundState != 2
With this, you should be able to turn the AI on or off simply by hitting Start twice (or whatever) on player 1's controls whenever your character's TeamSide=1 (except when P2 in Team Co-op mode), or on player 2's controls whenever your character's TeamSide=2 (and when P2 in Team Co-op mode). And the CPU won't ever be able to do the same. You should definitely remove this bit of code before releasing a character. But assuming it works (haven't actually tested it yet--too lazy), it might make testing your character a little easier.
Edit: Mind you, this'll only work properly in DOS Mugen. In newer Mugen versions, KeyCtrl helpers occasionally detect CPU-issued commands, thus allowing the CPU to occasionally toggle the AI switch when in control.
-
For the second Anim number, I think I'll use 74140108. I spent almost an entire minute reading through all 760 AIR files in my chars directory again, and didn't find a single instance of it. So, any objections to it?
Are there instances greater than 5 digits? I really haven't seen a character with it and all you would have to search for is "######]" ignoring white space in all character air files.
Anyway, it just occurred to me, might anyone find this useful?:
:huh: maybe. If I had the time to sit down and look at it.
-
I really haven't seen a character with it and all you would have to search for is "######]" ignoring white space in all character air files.
As I said (in a sorta joking way :P ), I already did that (searching for any matching number, regardless of brackets or white space) with all the characters I've got in my chars directory. Don't feel like searching through the AIR files of characters I don't have installed.
:huh: maybe. If I had the time to sit down and look at it.
Eh? The purpose of that little bit of code is simply to provide the human with a way to turn any character's custom AI variable on and off, without giving the CPU access to the same. Figured it'd help in testing characters, so that you don't have to bother restarting the match (which would reset all other variables as well, some of which you might not want reset) just to turn off the AI; or so that you could control your character to set up some scenario, and then turn on the AI in order to test the custom AI's response to that scenario.
Anyway, I just found out that when P1 puts P2 in a custom state, P2 doesn't receive P1's AIR data unless/until a ChangeAnim2 controller is used, and thus a !(Parent,Anim(#)) trigger would be completely insufficient for checking for custom states. So, unless anyone has any other ideas for a way to check for custom states (though I doubt there is any other way, unless there's something like an undocumented SysVar that keeps track of that), the parent's GameTime variable is still necessary for the helper method.
Anyway #2, I've just updated kfm-ai.rar again. No major changes, mainly just added/modified a few comments; and decided to change the GameTime var set controller from a Null to a VarSet, just in case any future Mugen versions or Mugen clones decide to ignore triggers for Null-type controllers, and also due to the likelihood of someone removing the controller due to not reading the comment and assuming it does nothing. I assume the change only adds one or so CPU instructions per tick, anyway.
-
Ahh, crap. I just realized, I believe the XOR method (and, it's important to note, the old humanly-impossible commands method) requires a minimum of three of the root character's variable slots in order to guarantee no faulty AI activation. This due to the unusual but still quite possible possibility of a SelfState controller being executed during a hit pause while in a custom state. So, if your character can afford the three to four variable slots necessary, I'd suggest using this fixed up version of the code:
http://www.shinmugen.net/winane/tutorial/3var-AI.rar
The important changed part being:
; According to Roque, this method works in Mugen version 2002.04.14,
; whereas the old humanly-impossible commands method does not.
; It is very important that this controller NOT be moved to State -2.
; Note that this part won't work if AI.Cheat is turned off in mugen.cfg.
[State -3, XOR]
type = VarSet
triggerall = var(59)!=1
triggerall = !var(57)
triggerall = (var(58) = GameTime-1)
trigger1 = (command = "a") ^^ (command = "a2")
trigger2 = (command = "b") ^^ (command = "b2")
trigger3 = (command = "c") ^^ (command = "c2")
trigger4 = (command = "x") ^^ (command = "x2")
trigger5 = (command = "y") ^^ (command = "y2")
trigger6 = (command = "z") ^^ (command = "z2")
trigger7 = (command = "start") ^^ (command = "start2")
trigger8 = (command = "holda") ^^ (command = "holda2")
trigger9 = (command = "holdb") ^^ (command = "holdb2")
trigger10 = (command = "holdc") ^^ (command = "holdc2")
trigger11 = (command = "holdx") ^^ (command = "holdx2")
trigger12 = (command = "holdy") ^^ (command = "holdy2")
trigger13 = (command = "holdz") ^^ (command = "holdz2")
trigger14 = (command = "holdstart") ^^ (command = "holdstart2")
trigger15 = (command = "holdfwd") ^^ (command = "holdfwd2")
trigger16 = (command = "holdback") ^^ (command = "holdback2")
trigger17 = (command = "holdup") ^^ (command = "holdup2")
trigger18 = (command = "holddown") ^^ (command = "holddown2")
trigger19 = (command = "recovery") ^^ (command = "recovery2")
;Add more as desired. (See my notes in the CMD.)
var(59) = 1
; This controller must be placed here, after the above XOR VarSet
; controller and before the below GameTime VarSet controller.
[State -3, fiXOR]
type = VarSet
trigger1 = !HitPauseTime
trigger2 = (var(58) < GameTime-1)
var(57) = HitPauseTime
IgnoreHitPause = 1
; It is very important that this controller NOT be moved to State -2, as putting
; it there would defeat the entire purpose of the controller, allowing the
; helper method or the XOR method to erroneously set the AI variable.
; And within State -3, don't put any ChangeState controllers before this
; controller, lest you unnecessarily delay your character's AI activation.
[State -3, GameTimeVar]
type = VarSet
trigger1 = 1
var(58) = GameTime
IgnoreHitPause = 1
...necessarily in that order.
Or, can anyone think of any better solutions? The thing you need to know (in addition to the custom state command list inheritance stuff explained above) is: commands during a hit pause are registered on the tick that they're entered, and on every tick for the remainder of the hit pause, and also on the first tick right after the hit pause has ended.
Minor edit:
Just tweaked a line or two, added a little comment, and added a KFM patch to 3var-AI.rar.
One tiny little thing to note: With this newest modification, the XOR method won't work if you use frame advance with the pause menu minimized (until you unpause the game or display the menu), due to frame advance increasing GameTime by 2 per tick when the menu is minimized. (And slow motion effects done by using a Pause controller on every other tick will have the same effect.) So, if anyone gets the urge to compare the average amount time of various AI activation methods to activate the AI variable, you'll need to keep that in mind. =)
Also, it just occurred to me, I could move the HitPauseTime variable to an always-present helper, bringing the number of parent variable slots back down to a minimum of two. Does anyone think that would be worth the extra memory and processing required?
Edit 2:
It's generally a good idea not to download anything I post within 10 minutes of my posting it. :-[ :)
-
thanx for your tips about AI activation.
I would like to ask: what is the matter in use the IsHomeTeam trigger only? Its poor?
-
Outside of arcade mode, the IsHomeTeam trigger would return true for a human player: "In versus modes, P1's side (left) is the home team."
Another important point to be made, which I'll add to the tutorial after further testing, is that there are limits on what kind of command name overloading you can do, in order to ensure the reliability of the helper method. That is, if you redefine* any of the basic 11 command names used by the helper method, I believe you must follow these rules:
- Don't use any command string that includes any commas. (e.g. no "a,b")
- In the command string, don't include any direction that isn't preceeded by a slash. (e.g. no "F", no "$D")
- Don't put any non-slashed buttons in a command string overloading one of the Hold Dir command names. For example, don't add something like this:
[Command]
name = "holdback"
command = z
time = 1
- Completely untested as of writing this, but it's likely bad to use any time parameter greater than 1.
An example of what probably is permissible, is redefining the "z" button like so:
[Command]
name = "z"
command = y+b
time = 1
Other than that particular common type of redefinition, it's probably best to simply avoid overloading those 11 command names altogether. Anything that can be done with command name overloading should also be accomplishable by using a new unique command name, and then OR-ing the standard command name with the new one in your code.
(Yes, I know I didn't explain this very clearly. :P Let me know which if any parts you need me to clarify.)
(*I mean the word "redefine" in the additive sense, not the replacement sense. None of the basic 11 commands in question should be replaced at all.)
-
I will need your help to remake my mb-02 AI, could you help me later?
-
(I've already said it elsewhere, but yes, I'd be happy to help.)
Well, since no one said "no," here's a version of the code that stores the HitPauseTime variable in a helper instead of the root character:
http://www.shinmugen.net/winane/tutorial/2var-AI.rar
(And an extremely minor update to the 3 variable patch:
http://www.shinmugen.net/winane/tutorial/3var-AI.rar )
With the 2 variable version, the HitPauseTime helper sticks around until the AI is turned on when the CPU is in control (not very long, in other words), or until the end of the round when a human is in control.
If no one finds any problems with either of these two versions, I guess I'll go ahead and replace the old code on my site soon.
-
Guess I should mention here that I tweaked the code on my site just a tad.
No real functional changes, though. Just added a note about optionally using this code (http://www.mugenguild.com/forumx/index.php?topic=12751.msg131981#msg131981) to permanently disable the helper method in Training mode so that you can use the button jam feature without turning on the AI, and shifted the high variable indices down a notch to allow for more convenient implementation of the Training mode detection code.
-
Finally remembered to test a few more things, and updated the text stuff accordingly (no change to the code though). In particular, tried to clarify some language about command redefining, and added these bits in the CMD:
;[Remap]
;
; Note that if you modify the button remapping scheme, this character will
; still be able to correctly detect the basic commands of other characters
; complying with the basic command order specified below, as long as their
; buttons haven't been remapped. But no character (not even one with the same
; remapping scheme, not even another instance of this character) will be able to
; correctly detect this character's commands. This shouldn't ever result in any
; false positives, but it could delay correct positives, and could erroneously
; make the helper AI activation method trigger a false negative in team simul
; modes, in which case the XOR-ed commands method would be needed to provide
; backup. But of course, this isn't an issue in any version of Mugen prior to
; version 2002.04.14.
And as another restriction on command redefining:
; - The first definition of each of these commands must be in the order
; specified below. Any additional definitions can be placed anywhere after
; the first one.
since it's the first instance of any given command name that determines its place in the character's command array.
Also, didn't feel like adding this to kfm-ai.rar, but here's another little optional tidbit:
If you want to make the code a little more resistant to crappy characters that overwrite your variables in their custom states, you could add some thing like this:
[State -3, FailSafer]
type = VarSet
trigger1 = var(58)!=[-2,1]
var(58) = 0
It won't detect if the AI variable gets overwritten with a valid value, but it'll resurrect the AI helper if the variable gets set to anything else, thus allowing the helper method to quickly correctly set the variable.
It'll also need modification if you're using a multi-level AI system where var(58) can indicate different difficulty levels, but I'd recommend using the simplifier variable (var(0) in the example code) for that purpose instead anyway.
(Personally, I wouldn't bother using this little addition myself, as I figure it's best to just avoid any character that's rude enough to overwrite others' variables, but here it is in case anyone disagrees.)
-
I've just now updated the code to deal with screenpacks that set start.waittime to less than 2 (thereby skipping RoundState 0) in fight.def. The old version included a couple !RoundState triggers simply for the sake of slightly improving efficiency, but that rendered the IsHomeTeam and ID methods useless if start.waittime=0.
I also changed my mind and decided to remove most of the unnecessary parentheses, so the code isn't quite as bloated now.
Made a few other minor tweaks as well, but nothing significant.
I was in a bit of a hurry when making the changes, so please let me know if I screwed anything up.
-
Mugen creates an array of 128 command names for each character. If you try to detect a partner's or enemy's command (e.g. partner,trigger# = "x") without putting them in a custom state, then, Mugen doesn't try to find the command with the name you specified in their command list. Rather, it checks the array index of the command name you've specified in your CMD, and then checks whether the command with the same index in your partner's/enemy's command array is activated. So, in order to detect partner or enemy commands, you need to make sure that matching commands are in the same place in each character's command array.
I dunno... but tested against KFM, who has "recovery" (modified to /x) far down his .cmd and Gouki with a single "recovery" (y+z) command at the top of his .cmd. KFM is not in one of Gouki's states (but in common1.cns states). Aaand this under StateDef -3
[State -3, P2 Breakfall]
Type = TargetState
TriggerAll = Var(27) && P2Life && NumTarget && RoundState = 2 && Alive
Trigger1 = Target, Command = "recovery"
Value = 5220
can be triggered by KFM's recovery command, i.e. /x. And not by Gouki's y+z. I think I'm saying that "If you try to detect a partner's or enemy's command (e.g. partner,trigger# = "x") without putting them in a custom state, then, Mugen" does "try to find the command with the name you specified in their command list."
If it's there, fine, P2's it is, and if not, P1's.
Or was it something else you think I am wrong about with that list??
No matter whether you're having P2 in a state of yours and do command = "blah" or just do trigger_redirection, command = "blah":
- If "blah" exists only in P1's .cmd file, whatever P1 has defined for "blah" will evaluate true.
BUT
- If "blah" exists also in P2's .cmd file, only whatever P2 has defined for "blah" will evaluate true!
-
Could you upload+post the modified code files you used for testing that? And mention which of Gouki's moves you used to make KFM a target.
-
http://mugenguild.com/mcspace/Thrawn/kfm.cmd
Changed: [Command]
name = "recovery";Required (do not remove)
command = /x;x+y
time = 1
http://mugenguild.com/mcspace/Thrawn/commands.cmd
Changed: [Command]
Name = "recovery"
Command = y+z
Time = 1
.
.
.
;[Command]
;Name = "recovery"
;Command = x+y
;Time = 1
;[Command]
;Name = "recovery"
;Command = x+z
;Time = 1
Test relevant (Gouki's states.cns): [State -3, P2 Allow Flipping]
Type = VarSet
TriggerAll = !Var(27) && P2Life && NumTarget && RoundState = 2 && Alive && (Ctrl || MoveType = H)
Trigger1 = (Target, StateNo = 5030 || Target, StateNo = 5035 || Target, StateNo = 5050)
var(27) = 1
[State -3, P2 Disallow Flipping]
Type = VarSet
TriggerAll = Var(27) && P2Life && NumTarget && RoundState = 2 && Alive
Trigger1 = Target, MoveType != H || Target, StateType != A || Target, StateNo = 5200 || Target, StateNo = 5201 || Target, StateNo = 5210 || Target, StateNo = 5210
var(27) = 0
[State -3, P2 Breakfall]
Type = TargetState
TriggerAll = Var(27) && P2Life && NumTarget && RoundState = 2 && Alive
Trigger1 = Target, Command = "recovery"
Value = 5220
How? Quick versus, KFM vs. Gouki, KFM Stage. Gouki's hard punches/kicks for example make KFM fall when they are Counter Hits (no custom states, just an alternate hitdef). From there, KFM can use "recovery" as soon as Gouki has control back. Also from Hurricane Kick and so on, whenever the trigger conditions above are met.
Edit: Okay, I was wrong after all. "recovery" must be a special case, maybe because it is in the common1.cns and all that... because I tested the same thing with a new command:
[Command]
Name = "sex"
Command = /x
Time = 1
And no matter where I placed it in Gouki's .cmd, KFM could never be recover holding /x unless the command was placed inside KFM's cmd as well, and at the same friggin' place.
-
Gouki's hard punch/kick counters put KFM in State 5030, then 5035, then 5050. I couldn't recover before reaching 5050. So, what made you think it wasn't this:
[State 5050, 4] ;Recover near ground
type = ChangeState
triggerall = Vel Y > 0
triggerall = Pos Y >= -20
triggerall = alive
triggerall = CanRecover
trigger1 = Command = "recovery"
value = 5200 ;HITFALL_RECOVER
[State 5050, 5]; Recover in mid air
type = ChangeState
triggerall = Vel Y > -1
triggerall = alive
triggerall = CanRecover
trigger1 = Command = "recovery"
value = 5210 ;HITFALL_AIRRECOVER
in common1.cns instead of the TargetState in your Gouki that was allowing KFM to recover?
So, no, "recovery" isn't really a special case.
Anyway, I find DisplayToClipboard/AppendToClipboard controllers much more useful for testing this kind of stuff, rather than just testing whether some code appears to work.
By the way, in case anyone else comes along with the misinterpretation that I was incorrectly kinda expecting was going to be the explanation here:
Wherever I'm referring to a player being in a "custom state", I'm actually referring to the player being in another player's states, regardless of whether those states are defined in common1.cns or in the other player's own code files; that is, regardless of whether the state is truly "custom" or not. In other words, what I'm referring to is the time between when the player gets hit by a HitDef with a P2StateNo parameter (and without P2GetP1State set to 0) and when a SelfState controller then reverts the player back to its own states. I've just been using the term "custom state" as a not-entirely-accurate shorthand way of referring to that.
Edit: :-[
-
Anyway, Gouki's hard punch/kick counters put KFM in State 5030, then 5035, then 5050. I couldn't recover before reaching 5050.
That, sir, is because - when using hard punches/kicks - Gouki doesn't end the move and get control back before KFM has reached state 5050. ;)
So, what made you think it wasn't this:
[State 5050, 4] ;Recover near ground
type = ChangeState
triggerall = Vel Y > 0
triggerall = Pos Y >= -20
triggerall = alive
triggerall = CanRecover
trigger1 = Command = "recovery"
value = 5200 ;HITFALL_RECOVER
[State 5050, 5]; Recover in mid air
type = ChangeState
triggerall = Vel Y > -1
triggerall = alive
triggerall = CanRecover
trigger1 = Command = "recovery"
value = 5210 ;HITFALL_AIRRECOVER
in common1.cns instead of the TargetState in your Gouki that was allowing KFM to recover?
Why, Fall.Recover = 0
in Gouki's HitDefs of course.
So, no, "recovery" isn't really a special case.
Anyway, I find DisplayToClipboard/AppendToClipboard controllers much more useful for testing this kind of stuff, rather than just testing whether some code appears to work.
Like so (http://mugenguild.com/mcspace/Thrawn/mugen0.pcx)? ???
-
Holy crap, you're right. o_0
To summarize:
"recovery" does count towards the 128-command name maximum total: removing it allows the addition of another.
Its position in the command array is determined the same as any other command, and affects the positions of subsequently defined commands just like normal.
BUT: Redirecting command="recovery" triggers is completely different than redirecting other command triggers.
It always detects the redirected-to player's own "recovery" command rather than the detector's. And custom states have no effect on this.
And if the redirected-to player doesn't have a "recovery" command defined, "recovery" redirects will never return true.
Furthermore, detecting one's own "recovery" command uses one's own "recovery" command definition even when one is in another player's custom state.
Weird. I wonder how the internal representation and functioning of all this works.
Regardless, I think it's safe to conclude that Elecbyte was enjoying da shrooms or something while writing their command-related code. :P
Anyway, thanks for noticing that, Sepp! You rock.*
Hm, wonder if there's any interesting ways to take advantage of this...
That, sir, is because - when using hard punches/kicks - Gouki doesn't end the move and get control back before KFM has reached state 5050. ;)
Why, Fall.Recover = 0
in Gouki's HitDefs of course.
How dare you expose my laziness! >:( >:(
Anyway, I find DisplayToClipboard/AppendToClipboard controllers much more useful for testing this kind of stuff, rather than just testing whether some code appears to work.
Like so (http://mugenguild.com/mcspace/Thrawn/mugen0.pcx)? ???
Huh? ???
[size=5pt]*(But your Gouki doesn't. =P I found it amusingly pathetic watching him flop himself on his back repeatedly while testing this stuff...)[/size]
-
Anyway, I find DisplayToClipboard/AppendToClipboard controllers much more useful for testing this kind of stuff, rather than just testing whether some code appears to work.
Like so (http://mugenguild.com/mcspace/Thrawn/mugen0.pcx)? ???
Huh? ???
Eh, don't mind that. I was probably thinking DisplayToClipboard = Debug mode turned on. O_o"
-
Minor update uploaded, in light of this (http://www.mugenguild.com/forumx/index.php?topic=13998.msg211296#msg211296).
No code changes, just tweaked the text.
-
hi,
i'm trying to upgrade my char AI using Winane AI activation code. The links don't work anymore so I found a char, athena2002, that has it. It works but it seems to me that the AI is not "very fast" and my char is going on jumping even if I remove any jump and jump-attack from its AI (it has this problem also before but now it's worse).
Do you have any suggestion or can you provide me with a working link with Winane AI tutorials?
thanks
-
hi,
i'm trying to upgrade my char AI using Winane AI activation code. The links don't work anymore so I found a char, athena2002, that has it. It works but it seems to me that the AI is not "very fast" and my char is going on jumping even if I remove any jump and jump-attack from its AI (it has this problem also before but not it's worse).
Do you have any suggestion or can you provide me with a working link with Winane AI tutorials?
thanks
I suppose I could upload them to my site, but I'd need the ok from everyone else. Everyone?
It is in the mugen section of my site.
-
thank you very much, I downloaded it :P ;D
-
Hi, I read the tutorial added the "activation" code in the cns, fix the commands in the cmd for the Xor method .. and then I'm just using the var(0) for my AI.
Is it correct? It seems to me still "slow" and is going on jumping even if there is no AI-jump "defined".
Thanks you very much for your help
-
Hm, well, you haven't provided enough information for me to know what the problem is, but since it's been more than two months, I'll assume you've figured it out by now. :shrug:
Anyway, just thought I'd mention that I've updated the files, but I don't think I changed anything since the last version other than the URL to my site. However, to anyone who's downloaded the code from Jazzy's (aokmaniac13's) site, please note that the version of the code he uploaded was outdated, ugly, and somewhat flawed, so please be sure to use the latest version from my site instead.
-
However, to anyone who's downloaded the code from Jazzy's (aokmaniac13's) site, please note that the version of the code he uploaded was outdated, ugly, and somewhat flawed, so please be sure to use the latest version from my site instead.
Huuu, shit.
I'll have a look on that tomorrow and post here what parts must be updated.
EDIT :
* DEF file : nothing
* AIR file : nothing
* CMD file :
- [button remapping] : code and comments
- [Default values] : comments
- comment line above the -| CPU |- (may be already in Jazzy's version, not sure).
- comments modified above the -| Super Motions |-
* CNS file :
- States 9741/9742 : at least parenthesis removed, better copy/paste for safety.
- States -2 : idem but please note that an ATC sctrl has been added at the end
- States -3 : same again (ie state unfair, trigger1,1 changed)
* TXT file :
- Didn't check, anyway just copy/paste all files (unless you added your own comments in... in that case... good luck ! ;D)
It's pretty faster to update than I thought at first.
-
Updating soon :P
I had not realized your site was still functional.
-
For a while, it wasn't. :P
Thanks BDI!
[State -3, Unfair]; Is this reliable?
Answer: No, it is not. ><
Sorry, I hadn't realized it was possible for the human players to start on the right side in team co-op mode. :embarrassed: Thanks to Chosen_01 for pointing that out (http://mugenguild.com/forumx/index.php?topic=35304.msg336243#msg336243)!
So, I've removed the ID method. No big loss, as it only contributed in one specific situation anyway. To anyone who's been using it, please be sure to update your characters.
Furthermore, it turned out I'd forgotten to include this bit, now added:
Also, if your character overrides StateDef 5900, do make sure you clear
at least var(58) there when !RoundsExisted.
And do note that there may yet be a flaw in the helper method, as indicated by false positive reports from Cybaster (http://mugenguild.com/forumx/index.php?topic=27695.msg260626#msg260626) and Dracoroot7 (http://mugenguild.com/forumx/index.php?topic=27556.msg278214#msg278214). I'll try to investigate further, as time allows. If anyone wants to try figuring it out themselves first, my current best suspicion is that it might have something to do with having Game Speed set to faster than normal. Might be completely wrong, though.
-
If anyone wants to try figuring it out themselves first, my current best suspicion is that it might have something to do with having Game Speed set to faster than normal.
I'd say that's not it. :P All code needs to be executed while drawing can be skipped. I might have a look see, but don't expect fast results.
-
Blargity blargh. In Mugen 04.14.2001, commands entered during a hitpause persist for one tick beyond the end of the hitpause. But I've just discovered that in Mugen 11.01.2001+, commands entered during a hitpause persist for one plus the command's buffer.time beyond the end of the hitpause. My apologies, I have no idea how I could have overlooked that. >_< Thanks to Sepp for help identifying that issue!
I don't have time to fix the helper method accordingly right away, but I've gone ahead and fixed the XOR method. Both archives updated.
For the 2 variable/2 helper version:
[State 9743, HitPauseTime]
type = VarSet
trigger1 = !(Parent,HitPauseTime)
trigger2 = GameTime > Parent,var(57)
var(1) = Parent,HitPauseTime
changed to
[State 9743, fiXOR]
type = VarAdd
trigger1 = !(Parent,HitPauseTime)
trigger1 = var(1) > 0
var(1) = -1
[State 9743, fuXOR]
type = VarSet
trigger1 = Parent,HitPauseTime
trigger1 = Parent,var(57) < GameTime-1
var(1) = 2; Set this to your maximum command buffer.time + 1. If you haven't
; set command.buffer.time nor buffer.time for any commands, then set this to 2.
IgnoreHitPause = 1
For the 3 variable/1 helper version:
; This controller must be placed here, after the above XOR VarSet
; controller and before the below GameTime VarSet controller.
[State -3, fiXOR]
type = VarSet
trigger1 = !HitPauseTime
trigger2 = var(57) < GameTime-1
var(56) = HitPauseTime
IgnoreHitPause = 1
changed to
; These next two controllers must be placed here, after the above XOR
; VarSet controller and before the below GameTime VarSet controller.
[State -3, fiXOR]
type = VarAdd
trigger1 = var(56) > 0
var(56) = -1
[State -3, fuXOR]
type = VarSet
trigger1 = HitPauseTime
trigger1 = var(57) < GameTime-1
var(56) = 2; Set this to your maximum command buffer.time + 1. If you haven't
; set command.buffer.time nor buffer.time for any commands, then set this to 2.
IgnoreHitPause = 1
I haven't technically tested the update yet, but it ought to work properly.
-
Little tweak:
Instead of setting var(56)/helper(9743),var(1) to each specific character's maximum command buffer time + 1, I decided to just set it to the maximum possible buffer time + 1. That way, there's no need to worry about people like Sepp going and altering the buffer settings to their liking. And while a half-second might seem like a bit much of a delay, that delay should rarely be incurred.
So now the relevant controllers look like this (for 2 var version):
[State 9743, fuXOR]
type = VarSet
trigger1 = Parent,HitPauseTime
trigger1 = Parent,var(57) < GameTime-1
var(1) = 31
IgnoreHitPause = 1
and this (for 3 var version):
[State -3, fuXOR]
type = VarSet
trigger1 = HitPauseTime
trigger1 = var(57) < GameTime-1
var(56) = 31
IgnoreHitPause = 1
Both archives updated again.
Edit: Whoops, yep, thanks Kung Fu Man! Link fixed.
-
Whoops yet again; in my haste, I overlooked a couple mistakes in that code. So, archives updated:
In the 2 var version, changed this:
[State 9743, fuXOR]
type = VarSet
trigger1 = Parent,HitPauseTime
trigger1 = Parent,var(57) < GameTime-1
var(1) = 31
IgnoreHitPause = 1
to this:
[State 9743, fuXOR]
type = VarSet
trigger1 = Parent,var(57) < GameTime
var(1) = 31
IgnoreHitPause = 1
In the 3 var version, changed this:
[State -3, fuXOR]
type = VarSet
trigger1 = HitPauseTime
trigger1 = var(57) < GameTime-1
var(56) = 31
IgnoreHitPause = 1
to this:
[State -3, fuXOR]
type = VarSet
trigger1 = var(57) < GameTime-1
var(56) = 31
IgnoreHitPause = 1
So, that might sometimes significantly decrease the effectiveness of the code, but it's unfortunately necessary in Mugen 11.01.2001+. Note that when characters receive the opponent's command array in custom hit states, that includes the opponent's buffer.time settings. So even if your character doesn't use any buffer.time settings greater than 1, var(56) still needs to be set to 31 after custom states in case the opponent does.
(Now, I can't remember offhand whether there's any need to disable the XOR method after pauses/super pauses. If not, I might make it disabled only after custom states, though I suspect that would require yet another variable slot. Too lazy to research and think about it right now, though.)
Anyway, the XOR method is probably all done with now. Expect updates for the helper method soon.
And if anyone out there still only cares about DOS Mugen, you might want to take note that the 2006/1/30 versions of my code are as ideal as my code is going to get for Mugen 04.14.2001. All subsequent versions will slightly reduce the average quickness of AI activation for the sake of avoiding false positives in Mugen 11.01.2001+, at the expense of maximal speed in 04.14.2001. If anyone out there wants me to send them the 2006/1/30 code, just send me a PM or something. Edit: Partially nevermind, this paragraph only applies to the XOR method (and the humanly-impossible commands method), not the rest of the code.
-
Since the old humanly-impossible commands AI activation method is a bit more convenient (and still more popular) than the XORed commands method, I figured I ought to write up a safe version of it, since all prior versions I've seen occasionally allow false positives (especially in post-DOS Mugen versions). I've added it to ye old AIcomponents.rar (http://www.mugenguild.net/~winane/tutorial/AIcomponents.rar), in the file "CPU-only commands method.txt". The explanatory text is currently a bit lacking, as I mainly just wanted to get the code out there for now. I'll tidy up the text later (well, perhaps).
-
Okay, I believe I've fixed up the helper method. (Of course, I've thought that about 50 times before...) Buffer.time issues should be handled properly, now. It turned out there were actually still a couple flaws in the code with DOS Mugen too, now fixed. And I added a note about dealing with the button jam issue in training mode, thanks to P.o.t.S. (http://mugenguild.com/forumx/index.php?topic=35304.msg337615#msg337615) I've barely tested the updated code outside of the Mugen emulator in my head, but I think it should work. Both archives have been updated. Too many little tweaks to list here, so, I trust everyone already using my code has a good text file comparison utility?
(I would no longer call the helper code entirely optimized, but that's really not a significant issue. I might eventually tweak it just for fun and for the sake of tidiness. But proper functionality is the highest priority (http://www.brainyquote.com/quotes/quotes/d/donaldknut181625.html), needless to say, and I was afraid I might accidentally break something in the process of optimizing, and/or might make it more difficult to deal with any more problems, should they ever arise.)
Note that there is another way to deal with the buffer.time + XOR method problem, that would shorten post-custom-state/pause delays. But, it would be a bit messier, requiring extra processing in a negative state, and requiring more explanation ergo more opportunity for implementation error. If anyone's interested, let me know, and I'll try to whip up what I had in mind.
Additional note to people who like to oversimplify their code, in case I haven't already mentioned it:
It should be safe to use only the 9741 version or only the 9742 version of the helper state, if, for whatever reason, you'd prefer. But using only the 9741 version would greatly increase the probability of a false negative in simul team modes when partnered with a character with a compatible CMD, thus requiring the XOR method to provide backup. And using only the 9742 version would require extra processing for naught (when not partnered with a compatible-CMD character), and would sometimes unnecessarily delay AI activation (when partnered with a non-compatible-CMD character).
Now, to summarize, these are the issues my code tries to deal with properly:
-enemy command array inheritance in custom states
-hitpause command persistency
-pause/superpause command buffering
-command.buffer.time command persistency (11.01.2001+ Mugen only)
-autoturn back/forward reversal
-detection of partner input by KeyCtrl helpers
-various differences between hold commands and non-hold commands
-multiple definitions for command names
-destruction of helpers upon intro interruption
-the fact that DestroySelfs don't terminate processing of the current tick
-optional: training mode dummy button jam etc. issue
-all play modes
-etc?
-interactions between all of the above
So, did I succeed? That is, are there any flaws in the code that don't deal with the listed issues properly? And are there any issues that need to be dealt with which I haven't identified yet?
-
Another update uploaded, in light of the new behavior of player-type helpers (http://mugenguild.com/forumx/index.php?topic=23016.msg356536#msg356536). All I did was add a "!IsHelper" triggerall to all the controllers in States -2 and -3.
Edit:
Ah, I forgot to mention, it is possible (albeit generally a bad idea) for opponents to make your character spawn a player-type helper while in a custom hit state, so I'd suggest leaving the !IsHelper triggers in even if your character doesn't use any player-type helpers.
-
Extremely minor update uploaded:
http://www.mugenguild.net/~winane/tutorial/index.html
All I did was change the "Safety" SelfState controller's value from 0 to 5050, in both helper states. No need to update all your old characters for just that.
By the way, might as well mention that another advantage to using the "Simplifier" controller is that it ought to allow for more convenient adaptation of characters to InfinityCat. All that should be needed would be to change this:
[State -2, Simplifier]
type = VarSet
triggerall = !IsHelper
trigger1 = var(58) = 1
trigger2 = var(0):=0
var(0) = 1 ; Another option is to replace 1 with something like MatchNo, if
; you want to design your AI to have varying levels of difficulty.
IgnoreHitPause = 1
to something like this:
[State -2, Simplifier]
type = VarSet
triggerall = !IsHelper
trigger1 = IsAI
trigger2 = var(0):=0
var(0) = 1 ; Another option is to replace 1 with something like MatchNo, if
; you want to design your AI to have varying levels of difficulty.
IgnoreHitPause = 1
-
why would you use the ai code with infinity cat ???
-
more convenient adaptation of characters to InfinityCat.
In other words: You could just delete my entire code, and do a find/replace all to replace every instance of "var(58)>0"/"var(0)" with "IsAI" (or "IsAI*MatchNo", or whatever), which is what I would recommend doing for any of your own InfCat-only character releases. But if you happen to have a large collection of other people's Mugen character releases that use my code, and want to quickly update them for use with InfCat, the single-line fix I posted above would be more convenient. And it's also easier to explain to your users, if you release any characters primarily for Mugen, but decide to include InfCat updating instructions in the readme, or something like that.
-
Submit your M.U.G.E.N tutorials, tips and tricks, FAQs and so on.
Please post in the InfCat Tips and Tutorials section. ::)
-
Would anyone be willing to give this code a try?:
http://www.mugenguild.net/~winane/tutorial/kfm-xor.rar
Just report whether or not you can get it to misbehave in any way. As usual, this KFM doesn't have any AI, but his AI flag vars are displayed to the clipboard (var(58) and var(0)). If you know what you're doing, feel free to copy the code over to another character, to make testing more fun.
I made two changes to the XORed commands method, one of which I mentioned above, the other of which I should have thought of years ago but didn't. The former helps shorten activation delays after custom states. The latter should prevent activation delays caused by pauses and superpauses. (The fact that I apparently didn't think of it years ago makes me a little suspicious, which is why I haven't yet added it to the main archive. So, test plz.)
-
Major update uploaded.
1. Corrected a major error in the simul version of the helper method. Due to a missing line of code, all that was needed to trigger a false positive was to hold any direction at the very start of RoundState 2. :sweatdrop: Many thanks to YO MOMS KNOW ME for finally bringing that to my attention.
2. Modified a few comments, most significantly the bit about adding additional definitions for the 18 basic command names. In short: please don't do it.
Spanish translation coming soon, from LotF.
-
Spanish translation coming soon, from LotF.
Done ;). Check your PM/mail.
-
I could do with as much help with AI as possible at the moment.
Chars with stupid difficult AI is ruining the balance of my Mugen.
I need to find out how to disable the AI on chars, or add a line that works withthe difficulty level set in the game.
POTS makes great chars, but they are too good to play against. Just get beaten perfect every time. cant land a light punch even. :S
-
Hi Winane.
You seem to be the AI man, so please help me
How can i lower a characters custom AI? Is there a tutorial anywhere?
I've searched and have found nothing but other peope asking the same thing.
And then smart arses posting irrelevant comments.
i found one tutorial http://www.mugen-infantry.net/forum/index.php?topic=61699.0 (http://www.mugen-infantry.net/forum/index.php?topic=61699.0)
I just noticed that the AI i am trying to lower is your own AI. How can i get rid of it?
No offence, but i am looking for a balanced game. And Karen and Nash are too good. and i want everything to run off the standard AI
Please get back to me
Please help
-
I am pretty much brand new to both MUGEN and AI coding. While I think I understand the XOR method, or at least understand what code to put where, I don't understand how to make it work with speciffic moves. In other words, where/how do I get this method to recognize, say, KFM's Strong Palm Thrust?
Similarly, is there something like "A Complete Idiot's Guide to MUGEN AI" floating around out there that lists all commands and values and what they do or how they affect your character?
-
Edit: What follows is a result of bad reading comprehension. --;
In other words, where/how do I get this method to recognize, say, KFM's Strong Palm Thrust?
My best guess as to what you mean is:
How does my character know that KFM is performing his Strong Palm Thrust so that it can react accordingly?
It's not practical to know what move the other player is doing. You can do this using variables and trigger direction, but your variables would be depleted quickly. What you can know is if they enemy is attacking (enemyNear, MoveType), what their velocity and acceleration components are (or, where they're going), and whatever other information can be obtained using trigger redirection and triggers (http://www.mugenguild.com/docs/trigger.html).
Similarly, is there something like "A Complete Idiot's Guide to MUGEN AI" floating around out there that lists all commands and values and what they do or how they affect your character?
Probably not; maybe I should make one. It would have to include "Exploration of Mugen's Features for Those Who Don't Read the Docs and Find out How KFM Works" as preliminaries, of course. :S As for "listing all commands and values and what they do or how they affect your character," this doesn't make sense, and I have no idea what you might be talking about. The AI activation code does absolutely nothing aside from this:
AI activation code allows the programmer to determine whether the player is human- or computer-controlled.
The reason why the code is so convoluted is that it's a hack; Elecbyte never intended for the programmer to be able to make that determination. After that's working, you add your AI on your own using nothing from the AI activation code besides variables.
-
First of all, thanks for the reply.
In other words, where/how do I get this method to recognize, say, KFM's Strong Palm Thrust?
My best guess as to what you mean is:
How does my character know that KFM is performing his Strong Palm Thrust so that it can react accordingly?
It's not practical to know what move the other player is doing. You can do this using variables and trigger direction, but your variables would be depleted quickly. What you can know is if they enemy is attacking (enemyNear, MoveType), what their velocity and acceleration components are (or, where they're going), and whatever other information can be obtained using trigger redirection and triggers (http://www.mugenguild.com/docs/trigger.html).
Not exactly. What I meant is that how do you make the XOR code recognize the Palm Thrust as a move it can do? I saw this example in the kfm.cmd file included with the implementation files:
; [State -1, Haha!]
; type = ChangeState
; trigger1 = var(0) ; (Or use "var(58)>0" if you've chosen not to
; ; use the Simplifier variable/controller.)
; trigger1 = ctrl
; trigger1 = StateType = S
; trigger1 = MoveType = I
; trigger1 = P2MoveType = H
; trigger1 = NumEnemy = 1
; trigger1 = Enemy,GetHitVar(HitTime) > 60
; trigger1 = PrevStateNo != 195
; trigger1 = Random < 99
; value = 195
Do I just add the var and random to the existing move info in State -1?
Similarly, is there something like "A Complete Idiot's Guide to MUGEN AI" floating around out there that lists all commands and values and what they do or how they affect your character?
Probably not; maybe I should make one. It would have to include "Exploration of Mugen's Features for Those Who Don't Read the Docs and Find out How KFM Works" as preliminaries, of course. :S
Modify that to "Those Who've Tried to Read the Docs and Had a Hard Time Understanding Them." Especially since I've found so little about AI itself.
As for "listing all commands and values and what they do or how they affect your character," this doesn't make sense, and I have no idea what you might be talking about. The AI activation code does absolutely nothing aside from this:
- AI activation code allows the programmer to determine whether the player is human- or computer-controlled.
The reason why the code is so convoluted is that it's a hack; Elecbyte never intended for the programmer to be able to make that determination. After that's working, you add your AI on your own using nothing from the AI activation code besides variables.
I mean things like movecontact, numproj, statetype, etc. I know a lot of that info can be found in the sctrls file, but not everything has a very detailed explanation or an example of how it's implemented. I'd also like an explanation on how the different trigger numbers work. I think I get it, but I'd like to know for sure.
I guess what I'd really like is sample code on basic things. Blocking (which I've found), basic combos/chain moves (like Iori's Aoi Hana or Rolento's Pipe Twirl), Tech Rolls, etc. I know it's asking a lot, but once I figure this stuff out, I'd be more than happy to contribute to a project like that.
Also, I found the following piece of info rather confusing in the XOR - 3 var.txt file:
; Here add matching commands for any moves that must never be used randomly
; by the computer, such as suicide moves and super moves, and add the pairs
; to the XOR VarSet controller in State -3.
; If you're desperate to make sure that the AI always gets turned on as soon
; as possible, you can add more equivalents for your own commands here too,
; and add to the XOR VarSet controller's triggers accordingly. You should
; use button-only commands before using any commands with directional
; components, as the latter apparently doesn't work in Linux Mugen 2002.04.14.
How would I write a command that I wouldn't want the CPU to do in the commands section? Also, does this mean I put all special moves I want the CPU to do here, rather than edit the entries in State -1?
-
Well Winane's file seems pretty explanatory, but I'll try to make a helpful reply this time. :P
The XOR-ed commands method, serving as a backup in case the other methods fail... Reason why this works is that if you have duplicate commands -- two separate commands that consist of the same button press(es) -- a CPU player will execute only one of the commands instead of both simultaneously, whereas a human player would be executing both. I don't think it would make much of a difference to add more commands, but you can. All that's going to happen is that when the CPU player executes one of the commands, custom AI gets activated, provided it wasn't activated already.
1. In the CMD, define the command and its counterpart:
[Command]
name = "QCF_x"
command = ~D, DF, F, x
[Command]
name = "QCF_x2"
command = ~D, DF, F, x
2. In the XOR VarSet controller, add a new trigger for the commands:
[State -3, XOR]
type = VarSet
triggerall = var(58)!=1 && !IsHelper
triggerall = !var(56)
triggerall = var(57) = GameTime-1
;(snipped triggers 1 through 19)
;Add more as desired. (See my notes in the CMD.)
trigger20 = command = "QCF_x" ^^ command = "QCF_x2"
var(58) = 1
The only purpose this serves is to activate your custom AI. To make the AI-activated character do something, you simply use var(0) as the first trigger of a ChangeState controller in the CMD, which is what the "Haha!" example you posted is an example of. Basically, each trigger1 in that sctrl is a condition that must be met for the ChangeState to execute, and every trigger is documented in triggers.html.
I mean things like movecontact, numproj, statetype, etc. I know a lot of that info can be found in the sctrls file, but not everything has a very detailed explanation or an example of how it's implemented. I'd also like an explanation on how the different trigger numbers work. I think I get it, but I'd like to know for sure.
Those are just triggers that are fully explained in Mugen's documentation. As for trigger numbering, maybe this (http://www.mugenguild.com/~davidgee/chartutorial/part9/index.html) would be helpful, and this (http://mugenguild.com/forumx/index.php?topic=37742.msg264937#msg264937) for more info.
-
Cool. Again, thanks for the info. Hopefully I'll get things to work this time.
-
Well, just downloaded the three separated component methods and added to my character.
I haven't even started programming the AI yet because I noticed that when buttons are mashed, it gets activated.
This is the 2-Var method I'm using btw.
MEANING HELP PLEASE
-
Single Independent Post:
In PotS's chars that use Winane's Method, I notice that they have a tendency not to activate. I had brought the issue up before and he changed his activation method, but the same flaw still appears.
Elix and Winane had both said that, PotS's Activation was a modification (Not sure about after the change though), but when the code is installed by them, it works properly 100% of the time.
I recently dabbled in two new Activation types that depend on the default AI and the speed at which you play Mugen.
The one I'm posting is like this because the Default AI has a tendency to go into jumping states:
[State -1, AI]
type = VarSet
triggerall = var(59) != 1
trigger1 = roundstate = 2
trigger1 = stateno = 40
trigger1 = command != "holdup"
trigger1 = time < 2
var(59) = 1
I am also working on one that is mainly geared toward CvS chars, because the default AI has a major tendency to trigger only the "charge" (I think it's literally whatever command those quotes are designated to) so I'll try finishing that sometime soon.
These two codes will work based on:
- How 'impossible' (dead unlikely) it is for people to move on a single tick basis
- The speed at which mugen is Running
- and a few more things I do not have time to outline right now
If you have any potential flaws, please present them.
PotS, I think your [state -1] tick lapse belongs in this discussion if you are willing (and no I won't do what I did before).
-
Not too fond of the idea of a jump state activating AI. It just doesn't seem like it would activate as quickly.
-
Not too fond of the idea of a jump state activating AI. It just doesn't seem like it would activate as quickly.
Yeah, I understand that completely. I am really only using this method because I don't fully understand Winane's, nor how to implement it properly.
-
they have a tendency not to activate
That's a really weird way to phrase it, since I don't see it happening. Anyway, that's the problem, I haven't seen the AI failing to activate so I can't pinpoint the cause. ???
And the difference is that, in my little modification, it detects pressing a direction rather than holding it, and doing so can detect human players (in the original directions only detect CPU).
-
So is the 2-var XOR method a bit flawed, or am I doing something wrong?
-
You probably just missed or failed one of the steps, which is normal because the code is such a monster when you first see it. >_<
Tried redoing it?
-
Copied EXACTLY as-is, save for the variables, all of which are correctly assigned.