YesNoOk
avatar

AI Activation Code (Read 42269 times)

Started by Winane, April 24, 2004, 03:20:04 am
Share this topic:
AI Activation Code
New #1  April 24, 2004, 03:20:04 am
  • *****
  • Tends to lose track of things a lot. :/
    • www.mugenguild.com/~winane/
Guess it's about time I publically released this.
http://www.mugenguild.net/~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?
Still quite busy.

(Yes, I intend to deal with that stuff eventually, but kinda can't just yet, sorry. :/ )
Last Edit: March 17, 2009, 06:57:57 pm by Iced the 8BallS

OrochiKOF97

Re:Ai Activation Code
#2  April 24, 2004, 05:20:25 am
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.
Re:Ai Activation Code
New #3  April 24, 2004, 06:58:37 am
  • *****
  • Tends to lose track of things a lot. :/
    • www.mugenguild.com/~winane/
Still quite busy.

(Yes, I intend to deal with that stuff eventually, but kinda can't just yet, sorry. :/ )
Last Edit: February 29, 2008, 10:29:14 pm by [C]yanide

OrochiKOF97

Re:Ai Activation Code
#4  April 25, 2004, 01:05:59 pm
No, there's no need for that, it's quite clear as it is.  >:(  >:(
This should do it.
Re:Ai Activation Code
#5  April 26, 2004, 04:11:20 am
  • *****
  • Tends to lose track of things a lot. :/
    • www.mugenguild.com/~winane/
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.
Still quite busy.

(Yes, I intend to deal with that stuff eventually, but kinda can't just yet, sorry. :/ )
Last Edit: May 02, 2004, 02:37:16 am by Winane
Re:Ai Activation Code
#6  May 02, 2004, 03:30:46 am
  • *****
  • Tends to lose track of things a lot. :/
    • www.mugenguild.com/~winane/
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.
Still quite busy.

(Yes, I intend to deal with that stuff eventually, but kinda can't just yet, sorry. :/ )
Last Edit: May 02, 2004, 03:32:20 am by Winane
Re:ONO! Another bump!
#7  May 05, 2004, 01:42:02 am
  • *****
  • Tends to lose track of things a lot. :/
    • www.mugenguild.com/~winane/
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?
Still quite busy.

(Yes, I intend to deal with that stuff eventually, but kinda can't just yet, sorry. :/ )

OrochiKOF97

Re:Ai Activation Code
#8  May 05, 2004, 01:47:10 am
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 ? :(
Last Edit: May 05, 2004, 01:49:35 am by Ouate De Phoque
Re:Ai Activation Code
#9  May 05, 2004, 01:51:32 am
  • ******
  • In after lock
    • mugenguild.com/~messatsu/index.html
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.


Many people risk their lives everyday by having Mugen.
Last Edit: May 05, 2004, 01:58:37 am by Messatsu
Re:Yay! Other people bumping for me! :D
#10  May 06, 2004, 05:35:33 am
  • *****
  • Tends to lose track of things a lot. :/
    • www.mugenguild.com/~winane/
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.
Still quite busy.

(Yes, I intend to deal with that stuff eventually, but kinda can't just yet, sorry. :/ )
Last Edit: January 25, 2005, 04:34:39 pm by Dante Alighieri

VIB

Re:Ai Activation Code
#11  May 06, 2004, 06:26:21 am
  • **
  • Hi, I am the "Personal Text"
    • www.geocities.com/vibhp/mugen/
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?
http://www.geocities.com/vibhp/mugen/

GREAT people talk about IDEAS.
Average people talk about Things.
small people talk about other people.
Re:Ai Activation Code
#12  May 06, 2004, 07:39:50 am
  • *****
  • Tends to lose track of things a lot. :/
    • www.mugenguild.com/~winane/
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.
Still quite busy.

(Yes, I intend to deal with that stuff eventually, but kinda can't just yet, sorry. :/ )
Last Edit: May 06, 2004, 08:07:25 pm by Winane
Re:Ai Activation Code
#13  May 06, 2004, 10:01:58 am
  • *****
  • Tends to lose track of things a lot. :/
    • www.mugenguild.com/~winane/
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?:

Code:
; 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.
Still quite busy.

(Yes, I intend to deal with that stuff eventually, but kinda can't just yet, sorry. :/ )
Last Edit: February 15, 2006, 09:18:24 am by :nink:
Re:Ai Activation Code
#14  May 06, 2004, 03:43:20 pm
  • ******
  • In after lock
    • mugenguild.com/~messatsu/index.html
Quote
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.

Quote
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.


Many people risk their lives everyday by having Mugen.
Re:Ai Activation Code
#15  May 11, 2004, 10:14:47 am
  • *****
  • Tends to lose track of things a lot. :/
    • www.mugenguild.com/~winane/
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.

Quote
: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.
Still quite busy.

(Yes, I intend to deal with that stuff eventually, but kinda can't just yet, sorry. :/ )
Re:Ai Activation Code
#16  May 19, 2004, 07:13:27 am
  • *****
  • Tends to lose track of things a lot. :/
    • www.mugenguild.com/~winane/
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:
Code:
; 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.  :-[ :)
Still quite busy.

(Yes, I intend to deal with that stuff eventually, but kinda can't just yet, sorry. :/ )
Last Edit: May 19, 2004, 10:54:42 am by Guild Master
Re:Ai Activation Code
#17  May 19, 2004, 07:08:48 pm
  • ******
  • The Old Dog
  • 14 years of MFG and counting :)
    • Brazil
    • www.brazilmugenteam.com
thanx for your tips about AI activation.

I would like to ask: what is the matter in use the IsHomeTeam trigger only? Its poor?
Re:Ai Activation Code
#18  May 19, 2004, 07:32:19 pm
  • *****
  • Tends to lose track of things a lot. :/
    • www.mugenguild.com/~winane/
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:
Code:
[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:
Code:
[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.)
Still quite busy.

(Yes, I intend to deal with that stuff eventually, but kinda can't just yet, sorry. :/ )
Re:Ai Activation Code
#19  May 19, 2004, 08:26:57 pm
  • ******
  • The Old Dog
  • 14 years of MFG and counting :)
    • Brazil
    • www.brazilmugenteam.com
I will need your help to remake my mb-02 AI, could you help me later?
Re:Ai Activation Code
#20  May 24, 2004, 10:17:49 am
  • *****
  • Tends to lose track of things a lot. :/
    • www.mugenguild.com/~winane/
(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.
Still quite busy.

(Yes, I intend to deal with that stuff eventually, but kinda can't just yet, sorry. :/ )