The d-gun controller is a really basic predictive algorithm (it measures the positions of an enemy at frames f and f + 5, then derives speed and direction from that), good enough to hold off a bunch of Flashes or Jeffies but not much else. It could also take down slower planes like Brawlers (and pesky Atlases) with a bit of luck, at least until a recent engine commit blocked giving attack/dgun orders with arbitrary mid-air coordinates. I'd love to know how you made your routine nail Hawks though.
Kloot wrote:I may bump 0.12 to 0.13 if and when extractor upgrading is implemented, but renaming it entirely is not an option.
I don't understand why this is so. You have forked the code and are maintaining a separate branch - that entitles you to a rename, or at least some extension like KAI 0.12-kloot.
As it stands, a user will very frequently go and download 0.23, despite it being worse. They are doing this exactly because you are inadvertantly telling them to; it doesn't matter how many forum threads you post with explanations buried in the text, 0.23 > 0.12 and people naturally assume that KAI 0.23 > KAI 0.12.
How would attaching my name to it change that though? I'm not going to artificially raise the version number just to rack up more downloads, nor will I rename 0.12 just so people might be more inclined to download my fork than 0.23. It's not a popularity contest, users can easily find out which AI is "better" (however you define that) by simply playing against them, and if they decide that's 0.23, well, then a new name won't suddenly change their minds either.
Version numbers are not a popularity contest tool, they're for differentiating stuff. You have released 3? 4? updates of KAI-0.12 and all of them are called the same - that's the problem, users don't know which of your own updates they have and don't know if they should upgrade or what to downgrade to. Even tagging your 0.12 releases with a svn revision number would be enough.
... and they will be (a little late, I freely admit):
starting with the next release of Spring, all 0.12 binaries will print a version string on initialization
That however doesn't address Yokozar's point of contention, that 0.12 will be seen as inferior to 0.23 (and in many ways it is, another reason not to nudge it up) because people assume higher == better, which is what I was responding to.
Hey, Kloot, how does KAI 0.12 determine that it should go ahead and build a Metal Extractor? I have Mexes and Fusions in my mod, using some non-traditional values for some things (costs, extraction rate), yet KAI never builds these buildings, and thus just moves around, building an utterly-useless mobile unit (er, utterly useless for mining metal, that is) near each metal spot. Very bizarre behavior!
Kind've a problem, frankly, as I really like KAI's aggressive metal-spot behavior as a tool to test against when doing game-balance stuff, along with more base-centric AIs.
And all I get, in the log, is this:
All Class pointers initialized
InitAI() complete
...is there a way to get more detailed feedback? What's causing it to do this strange behavior?
<tries KAI 0.23>
Well, KAI 0.23 identifies the Unit as a mine and sees that the fusion generates power, however, it just sits there, and doesn't even do anything stupid.
OHO! Now I know what's wrong! KAI is using the Category defined in the FBI! That's a bit silly, but easily enough fixed, I guess.
<tests> Nope, that didn't do it, neither did the TEDCLASS declaration (both of which are legacy crap and aren't even necessary except for a few situations).
So, what's up? Why are these two versions of KAI getting stuck? Checking against RAI, I can see that all three AIs are using a very similar process to determine what a Unit is for, and what it can do (all three of them make some very funny "decisions" about relative Unit combat power, though, lol... one of these days... maybe I should write my rant on this)... but KAI doesn't get past this initial step- or, rather, it does, but then makes a completely irrational decision.
One last bit of info, that might be helpful (I'd send you complete KAI 0.23b1 logs, but I dunno how much the code differs): everything in the game design takes anywhere from 100X to 1000X more Workertime to build than in traditional OTA mods. This is a legacy from NanoBlobs, but it should be irrelevant to an AI- they should either assess their Workertime against a given object's Buildtime, to determine "yes, I can build it, but it'll be next year"... or they should just assume that the game designer knows what they're doing...
Kloot wrote:... and they will be (a little late, I freely admit):
starting with the next release of Spring, all 0.12 binaries will print a version string on initialization
That however doesn't address Yokozar's point of contention, that 0.12 will be seen as inferior to 0.23 (and in many ways it is, another reason not to nudge it up) because people assume higher == better, which is what I was responding to.
This is not my main point of contention. The problem is that it's confusing for no good reason.
A higher version number generally means an upgrade. Going from KAI 0.12 to 0.23 is at best a sidegrade - may be better, may be worse. It is not, however, older, which lower version numbers always imply.
Worse still, you've released several different things and called them 0.12. It should make sense to ask "Which version of KAI do you have?" and respond with "Oh, I'm running 0.12."
Why not at least do 0.12.1, 0.12.2, etc? There are an infinite amount of numbers between 0.12 and 0.13 here, there's no need to conserve them.
0.12 considers a unit an extractor if it has the extractsMetal tag set in its fbi (there are a few other considerations, but that's the most important one). If you open CUnitTable.log in AI\KAI\ after running KAI with your mod and search for "METAL-EXTRACTOR", you can see which units it thinks fall into that category and whether anything was misclassified. The actual decision process of building a mex is somewhat more complicated, but as long it (the extractor) is on the chosen idle builder's menu there shouldn't be any construction glitches. Without knowing more about your mod's hierarchy it's hard to really pinpoint though.
@Yokozar
Again, the identifier string that new KAI 0.12's will print presents just that information, only in the form of a code revision date instead of a minor version number. The simple fact is however, 0.12 and 0.23 are related projects (one being an offshoot of the other) that now lead separate lives, it's unfortunate people might get confused by that but IMO not enough reason to rename either.
I don't see a CUnitTable.log, just CUnitTable Debug.log. I assume that's what I'm looking for? And I see absolutely nothing about METAL-EXTRACTOR, so it's obviously not getting this right. Hmm. YOu sure all it cares about is the FBI line: ExtractsMetal=SomeNumber? Is it possible that there's something preventing the AI from reading the Units correctly? I mean, I don't get any crashes, from Spring itself... so it's obviously something in the way that KAI is reading the Units here, and I can't imagine what would cause this behavior. I'll try turning up the debugging output from Spring and see what I get...
Again, the identifier string that new KAI 0.12's will print presents just that information, only in the form of a code revision date instead of a minor version number. The simple fact is however, 0.12 and 0.23 are related projects (one being an offshoot of the other) that now lead separate lives, it's unfortunate people might get confused by that but IMO not enough reason to rename either.
Even if I know some things about the AI-s as I have been around for a while this new 'versioning scheme' is totally strange for me.
I went to UF and I saw 4 versions of KAI 0.12 and KAI 0.2*, KAI 0.23 and KAI 0.23 bugfix 1.
I do not want to dig to find out about what each means. I would expect a project to have a 'last version' and that is it.
If you do not want to rename, ok (even if I do not understand why, you could name it KAIK or something if you want to keep the root), but if KAI 0.12 is the name of the project you should add a version like KAI 0.12 0.1 (damn, this doesn't sound good, but you do not want to rename it :) )
I will probably try the AI but it would be really nice to have a nice naming versioning scheme...
If you don't have CUnitTable.log (without the "Debug"
attached to it) then you're running a *cough* older
*cough* build of 0.12, get the 31/7 release.
@malric
I can only guarantee there's only ever one version
of 0.12 (identifiable by date and code revision) up
on UF, but the other files weren't uploaded by me
and so are beyond my control (not to mention that
some of them are pretty ancient, and aren't going
to suddenly turn invisible whether I rename KAI or
not). And I don't know if you've noticed, but there
are quite a few RAI's and NTAI's lingering around
there as well, so don't lay it all on me.
Last edited by Kloot on 14 Dec 2007, 02:29, edited 3 times in total.
For me renaming would be a bit easier because then you will not have others uploading things with the same name (ok, I know they can, but I guess nobody has bad intentions, it is just they uploading with the same name is easier).
And about the rest... if they are doing something not right, you shouldn't follow the example . (and I will tell them that if I see a thread about it)
Dumb things KAI 0.12 does in Balanced Annihilation:
Build hovercraft plants on Tumult
Build metal extractors right next to ones I've already built
Build jellyfish on the top ridge of Rain Shadow Ridge (ie, out of range of any water)
Have the commander attempt to "retreat" from my guys down a sheer cliff edge that he can't climb
The hovercraft issue is an interesting one. It's obviously dumb to build hovers on Tumult, which has only a very small pond in the middle, but it's also foolish to build them in the center on Rain Shadow Ridge (where they won't go near the water).
I think the only way to solve the hovercraft problem is to have the AI estimate the path units will take once a factory is built, and then only build the hover platform if it involves water.
To place Jellyfish turrets intelligently AI's need to have a notion of the map's layout (where shorelines are and what constitutes a large watermass etc, ie. one that an enemy might conceivably deploy subs in), which KAI in its present form doesn't. Hovercraft plants require a similar mechanism, in an ideal world the decision to build those would be moderated by the geography of the map (eg. whether there are few or many ponds / islands) but no such terrain analyzer exists in KAI.
Units can be given orders to move to locations they can't reach (try to drive a Flash up a hill on Small Divide), there's no AI-side solution for that.
I'll investigate builders going after already claimed metal spots, it's probably an artifact of the threatmap not being updated for unarmed units.
It craps all over itself when you give it storage out the wazoo. It thinks it has no resources and gets stuck and won't build any mexes.
About the storage thing. In funta, the first thing you build is your base defense. It gives you 10k10k storage. Every mex you build gives you 1000 metal and energy storage. 0.12 deals with this very badly.
Note I can unstick it if I .give it some lv1 factories, and especially if I give it lv2 factories and attack it just a little.
Yeah, 0.12 looks at the ratio between resource
levels and storage capacity to decide if it's low
on something and what to build next, so if it
suddenly gains a huge boost in either metal
or energy storage the decision process gets
thrown off until the balance is restored (which
can take quite a while if every extractor adds
+1000 of each ). Shouldn't be hard to fix.
It could also take down slower planes like Brawlers (and pesky Atlases) with a bit of luck, at least until a recent engine commit blocked giving attack/dgun orders with arbitrary mid-air coordinates. I'd love to know how you made your routine nail Hawks though. 
