Moderators: hoijui, Moderators
Code: Select all
spring.exe
AI/
Skirmish/
AAI/
KAIK/
RAI/
XAI/
0.123/
cfgs/
BA704.sd7-CometCatcherRedux.smf.lua
AIInfo.lua
SkirmishAI.dll
libSkirmishAI.so
Code: Select all
/home/karl/.spring/AI/Skirmish/XAI:
0.123 AIInfo.lua libSkirmishAI.so SkirmishAI.dll
/home/karl/.spring/AI/Skirmish/XAI/0.123:
cfgs
/home/karl/.spring/AI/Skirmish/XAI/0.123/cfgs:
BA704.sd7-CometCatcherRedux.smf.lua
If you mean it isn't listed in the menu, I had the same problem until I made this engine change:Auswaschbar wrote:Yet it doesn't detect your AI. What amI doing wrong?Code: Select all
/home/karl/.spring/AI/Skirmish/XAI: 0.123 AIInfo.lua libSkirmishAI.so SkirmishAI.dll /home/karl/.spring/AI/Skirmish/XAI/0.123: cfgs /home/karl/.spring/AI/Skirmish/XAI/0.123/cfgs: BA704.sd7-CometCatcherRedux.smf.lua
Code: Select all
index 9f729ec..2c8d018 100644
--- a/rts/System/FileSystem/FileSystem.cpp
+++ b/rts/System/FileSystem/FileSystem.cpp
@@ -859,7 +859,7 @@ std::vector<std::string> FileSystem::FindDirsInDirectSubDirs(
CFileHandler::SubDirs(*dir, pattern, SPRING_VFS_RAW);
mainDirs.insert(mainDirs.end(), localMainDirs.begin(), localMainDirs.end());
}
- //found.insert(found.end(), mainDirs.begin(), mainDirs.end());
+ found.insert(found.end(), mainDirs.begin(), mainDirs.end());
// and add all subdriectories of these
for (dir = mainDirs.begin(); dir != mainDirs.end(); ++dir) {
This test release is like a (more limited) version of NTAI I suppose, but using Lua it could become fully scriptable, such that peeps could override core runtime logic with their own mod-tailored functionality like Spring itself allows gadgets to do. Before going further down that path I need to know if the current setup is up to it though.1v0ry_k1ng wrote:whats the concept behind XAI? A lua version of NTAI?
Oops, missed that one. I've updated the archive link, fixed binaries are inside it.Umrug wrote: Assertion Failed!
File: AI/Skirmish/XAI/src/tasks/XAIMilitaryTaskHandler.cpp line 106
Expression:
attackTaskCountsForUnitID[tasksIt->second->GetObjectID()] > 0
One disadvantage with the unit-oriented style though is that configs can quickly grow quite large, making them more difficult to write and maintain. But it seemed best to give as much direct control as possible from the start.AF wrote:I quite like the way your lua configs are defined, its nice and clean to have a unit oriented layout defining a unit and its stats, rather than a stat oriented layout defining what stats to assign to units.
"999999" doesn't actually represent infinity, I just needed a large number for purposes of illustration.Umrug wrote: OK so lets avoid some noobtrap here: infinite value should be explicitly available to user :) nothing like "maxGameFrame = 999999" plz :)
Sorry, "not mentioned = +infinity" is exactly the current logic for all recognized max*** parameters. Treating -1 as such too is fine with me though.(i suggest -1 or better yet some special keyword of course. Also, saying "not mentioned = +infinity" is also not good. It should be explicit value)
The solar appears in two places because it is a buildee object of two different builders (armcom and armcv), each of which supplies a different set of parameters. And as for the comments, I didn't think you'd be interested in reading them twice.Armsolar appears at two places in the config, and is only described in-depth in one of them. It's not really clear why its described in CVs list and not in coms one. Perhaps better to put it into so separate section in the file?
I'm not so sure about supporting map-independent configs; BA on CCR is played very differently than BA on DSD to name one obvious example. Splitting them into dependent and independent parts would also add complexity, so for now this setup isn't going to change. But yes, it's probably not ideal.Also - you know that you will need map-independent file, riiiiiight? Riiiiight? And map file should be able to override some values of that file, and use some values. I guess if you are planning on going on with map-configs only you are making a mistake (imagine maintaining 10-50 configs)
So, (regardless of what was my point, which I probably failed to explain) - even when processing commanders build in-game, the values defined in CVs build (and the ones that didn't get overridden by coms section) are taken into account? (I hope that's so). And if solar is built by 3 different constructors (real case - com, CV, conbot), and commanders _and_ a CV's sections contain different values, and conbots one only defines count - which values will be taken - from CV or from com?The solar appears in two places because it is a buildee object of two different builders (armcom and armcv), each of which supplies a different set of parameters. And as for the comments, I didn't think you'd be interested in reading them twice.
BA on CCR is played exactly the same like BA on: Inculta, Red Comet, Moon Quartet Remake, all the other Comet remakes and all the other Basics Incluta-like maps. I guess its about 10 at least.I'm not so sure about supporting map-independent configs; BA on CCR is played very differently than BA on DSD to name one obvious example. Splitting them into dependent and independent parts would also add complexity, so for now this setup isn't going to change. But yes, it's probably not ideal.
There are no overrides between the build-items of any two builder types; all of them get processed independently. The conditions under which an idle armcv may build a solar can differ completely from the conditions that govern when an idle armcom may build one.Umrug wrote: So, (regardless of what was my point, which I probably failed to explain) - even when processing commanders build in-game, the values defined in CVs build (and the ones that didn't get overridden by coms section) are taken into account? (I hope that's so).
If the solar is built by one of the three constructors and assisted by the other two, then the restraints are read from the list-item of the con that wants to start the build.And if solar is built by 3 different constructors (real case - com, CV, conbot), and commanders _and_ a CV's sections contain different values, and conbots one only defines count - which values will be taken - from CV or from com?
What I can do is extend the config format so that the builder- and attacker-subtables can be defined in separate files, and included into the main ModMap.lua by referencing their names. Acceptable?BA on CCR is played exactly the same like BA on: Inculta, Red Comet, Moon Quartet Remake, all the other Comet remakes and all the other Basics Incluta-like maps. I guess its about 10 at least.
BA on DSD is played exactly the same like BA on: Tabula v2, Tau 10 Dry, LLTA complex etc etc etc like 30 maps. But wait, not exactly! Def placement will differ! (Do you have a support for it?) Also, some minor things will differ (better to go bot lab if you started there and there, better to go veh if you started there and there). Num of flashes needed to take out an LLT will remain.
I'll see about a spacing option.- Def placement needs either exact values set from config (you really need that anyway imo) or at least a min-spacing ( (c) AF). Right now it just builds 10 llts right next to each other.
The algorithm is correct, but AI's do not have the most recent resource state available to them at all times. Thus they can be mislead into thinking construction is affordable to start or continue (based on their out-of-date income and usage values) when it actually is not, or vice versa. Those wait orders are a result of that.- Some rogue wait commands are given to units at weird times - for example, commander receives several wait commands while building first lab. Economy algorithm going crazy? Anyway, that didn't seem to hinder its gameplay on any significant scale.
What? So CV (in the example file you provided) is going to make this smart choice with all the "MinGameFrame" and "MinEnergytorage" awesomeness, and commander will just make one regardless? And if I want conbot to make one I'll have to copy over the entire block from CV? Nonononono.... Can there be a separate section in the file? (I don't see any problem with that, so if you don't understand this I'm probably not explaining this correctly). This will also make all the builders buildlists so much easier to read, change, navigate... Again - separate section with "buildees", from where all default values are read, and any specific builder can override some of them in his personal section.Kloot wrote:There are no overrides between the build-items of any two builder types; all of them get processed independently. The conditions under which an idle armcv may build a solar can differ completely from the conditions that govern when an idle armcom may build one.
Oh, you decide :) I just wanted to make point about necessity of per-mod configs. (And then wow! How easy is support for every new map! You just copy-and-rename some existing config! Hooray!)Kloot wrote:What I can do is extend the config format so that the builder- and attacker-subtables can be defined in separate files, and included into the main ModMap.lua by referencing their names. Acceptable?
Suggestion (style mocking your cfg format):Kloot wrote:I'll see about a spacing option.
yepUmrug wrote: What? So CV (in the example file you provided) is going to make this smart choice with all the "MinGameFrame" and "MinEnergytorage" awesomeness, and commander will just make one regardless?
You'll only have to copy the entire block if you want the exact same restraints (or as many) for the conbot as for the conveh, of course.And if I want conbot to make one I'll have to copy over the entire block from CV?
I understand, but IMO this is not much more convenient unless you intend for something to be built by _many_ different types of units that must all adhere to the exact same set of parameters. Do you really think that would be a common situation?Nonononono.... Can there be a separate section in the file? (I don't see any problem with that, so if you don't understand this I'm probably not explaining this correctly). This will also make all the builders buildlists so much easier to read, change, navigate... Again - separate section with "buildees", from where all default values are read, and any specific builder can override some of them in his personal section.
Sure, this is doable, but it will have to wait until after more basic infrastructure (like the threatmap itself) is in place.Suggestion (style mocking your cfg format):
[porcStructType="llt"]
[0] Placements = "300, 200"; "12, 435"; "50, 125"; "45, 90" ....
[1] MinSpacing = 10
[generalPorcPlacement]
[0] Placements = "400, 100"; "122, 43"; "61, 325"; "5, 900" ....
And when certain con has this structure in his current task, it will:
- look for the closest of the "Placement" spots, if possible (not occupied, can reach this spot, threatmap etc) build it there
- look for the closest of the "general porc" spots
- if none of the spots is available, will build it elsewhere, but not closer then 10 units from any other llt.
1. Check out how long are buildlists of: commander, CV, conbot, aircon, hover con, con ship in BA, (6 units!) and how many similar items? T2 stuff in BA: 3 t2 land cons - same stuff. (Also seaplane con and adv con sub). NOTA - check this out - commander, air/bot/veh/def t2 towers, and a generic t2 tower all have most of their things common (that's 5 units!). And I don't care if its a bot building the estorage or construction vehicle, most probably I want all the parameters to be the same.Kloot wrote:I understand, but IMO this is not much more convenient unless you intend for something to be built by _many_ different types of units that must all adhere to the exact same set of parameters. Do you really think that would be a common situation?
