ylg_hke
Skirmisher
posted 09-30-18 00:22 AM
EDT (US)
276 / 406
Not sure if you misread, I meant official campaigns not 3rd party scenarios, there's a lot of (kbGetCiv() != cCivSPCJapanese) etc in the original AI, so I think official campaigns do use aiMain.xs
OK I will keep that in mind but honestly it has little to do with my preference, for example, how am I supposed to make "shoot huntable" mod-unfriendly? LOL, there's no place for cCiv, cTech, cTactic in this rule. On the other hand, there's no way I could make monitors of market/mill/plantation/dance/house...etc mod-friendly.
ylg_hke
Skirmisher
posted 09-30-18 03:06 AM
EDT (US)
278 / 406
In that case I guess its fair to say no good AI would be fully mod friendly, you definitely need a lot of cCiv to make a good AI.
Oh I see, I misinterpreted "overwrite the aiMain.xs". Yes my AI will replace the original aiMain.xs. It will give Out of Sync if I don't name it as aiMain.xs. Draugur AI gives OOS even I renamed it to aiMain and with cvOkToBuildDeck removed though.
AlistairJah
Skirmisher
posted 09-30-18 03:30 AM
EDT (US)
279 / 406
Yeah, it's not really like in other games where computer players always perform well ("perform well" *derp*), no matter how complex the mod is.
Does my script or Zen Master cause OOS too?
ylg_hke
Skirmisher
posted 09-30-18 05:07 AM
EDT (US)
280 / 406
Havent tested your AI on ESO yet, and ZenAI is not for supremacy so I probably wont test it online.
Atomiswave
Skirmisher
posted 09-30-18 05:21 AM
EDT (US)
281 / 406
When will you release your new AI? Looking forward to it....
ylg_hke
Skirmisher
posted 10-01-18 07:05 AM
EDT (US)
285 / 406
No, actually not directly, but indirectly related to the file name ,because modified ailoaderStandard will cause OOS, cant say I'm 100% sure though.
Damn...its just weird, why heroes' tc build plan is totally fine?
Congrats on sloving that problem =]
AlistairJah
Skirmisher
posted 10-01-18 07:33 AM
EDT (US)
286 / 406
I think it's related to cPlanTownBell... I can also be completely wrong.
I tested the "auto-create plan" event handler. It seems to be fired by cPlanGather and cPlanTownBell only. Even missions don't trigger it. There is also a super long delay between the plan auto-creation and the event handler's execution (more than 2 seconds!)... so sad...
Also... Not sure if I already told you this, but kbUnitPickSetDesiredNumberUnitTypes is not really respected once one of the "preferred" units (those which are specified in setUnitPickerPreference) is upgraded.
If you specify 'numberBuildings>=1', it seems to try to make >=1 military building per base (that's why they sometimes populate the forward base even if there is no cPlanBuild in the script which tells them to do so). And finally it doesn't really respect the 'preference factor'. It does, but not really. It's perhaps affected by the function 'updatePrice'.
AlistairJah
Skirmisher
posted 10-01-18 11:25 AM
EDT (US)
288 / 406
Alright, the latest version is out!
So, build plans place foundations even without builders? That'd be useful, thanks!
ylg_hke
Skirmisher
posted 10-01-18 11:41 AM
EDT (US)
289 / 406
@AlistairJah: OK that is a bit messy.
kbUnitPickSetDesiredNumberUnitTypes is not really respected once one of the "preferred" units (those which are specified in setUnitPickerPreference) is upgraded.
==> What does that mean exactly? Once Musketeers(or other preferred unites) upgrade to Veteran state, kbUnitPickSetDesiredNumberUnitTypes will then become meaningless?
'numberBuildings
==> Do you mean kbUnitPickSetDesiredNumberBuildings ?
And finally it doesn't really respect the 'preference factor'.
==> I guess you mean kbUnitPickSetPreferenceFactor ? To what extent kbUnitPickSetPreferenceFactor is not being respected? So far i dont have any problem with kbUnitPickSetPreferenceFactor, UnitPicker trains predefined unit types exactly.
@Panmaster2014:
Is it for treaty or supremacy or DM?
Just tested it in supremacy team games + record game
Well I'm not being rude, but...decks need redesign and overall its not fast enough for supremacy.
Also, its very unfortunate that the recorded game gave out of sync error instantly. (I actually recorded 3 times...)
The ideal would be to first run a placement, then a build plan using the placement position without any builders to avoid freezing and then task a settler to the foundationID.
==>Thanks!
ylg_hke
Skirmisher
posted 10-01-18 09:18 PM
EDT (US)
292 / 406
@AlistairJah:
Once a Hussar becomes veteran the AI tends to ignore other unit types.
==> Does that mean it would be fine as long as we have forced upgrade cPlanResearch? eg: forced hussar + musket cPlanResearch
kbUnitPickSetDesiredNumberUnitTypes(int upID, int number, int numberBuildings, bool degradeNumberBuildings)
==> have 0 knowledge about this one. So..it means the number of barracks/stables they will make per base. But honestly IIRC I haven't seen original AI building barracks/stables around the forward base.
if you put 0.5 skirmisher and 0.5 pikeman, are you really sure the AI will get that proportion
==> OK I get it. No, they wont, Even kbUnitPickSetCombatEfficiencyWeight is set to 0, the proportion is still rather fluctuating. It seems AI will adjust the proportion according to "kbUnitPickSetEnemyPlayerID(upID, aiGetMostHatedPlayerID());"
@Panmaster2014:
OK I did it on expert level. I have just recorded 2 games on hard level, and recorded games are fine now, no OOS error. So, somehow it doesn't work on expert level.
Regarding decks, the following cards are not that useful
Germans:
team cheap stables
colonial militia (AI cant use levy so this card is useless even for Portuguese)
native warriors
stonemasons
1 heavy canon(infinite)
British:
team fast building houses
advanced artillery
native warriors
extensive fortifications
Generally, AI take 7-8 mins to reach age2, it really is not fast enough for supremacy.
ylg_hke
Skirmisher
posted 10-02-18 03:42 AM
EDT (US)
294 / 406
I see.
IIRC, we cant not put -1 in kbUnitPickSetEnemyPlayerID, or the AI wont train army.
BTW, right now i think you are about gather plan, not 100% sure though, but it seems plans get overwritten constantly. And i guess that's why villagers spend more time on walking than working.
Eventually we either have to solve this problem or import econ-management from Zen AI.
@Panmaster2014
Just to avoid any ambiguity, there's no OOS error when i was "recording the game" on expert level, it occurs only when i watch the recorded game.
AlistairJah
Skirmisher
posted 10-02-18 06:18 AM
EDT (US)
295 / 406
Yes we can't, unless we use 'auto-update enemy' (bool).
Even with priority 100 the crateMonitor is still kinda powerless compared to RGP's... I'm already using Zen's ManualGathering rule for WoME. It's super powerful and bugs pretty rarely but... I still can't figure out the best way to simulate the town bell plan (since it's now ignored).
I'm surprised it's not heavy at all on computer resources! I had already tested it, months ago, on Improvement Mod, but I had to re-use the old TAD's gathering methods because it caused frame drops each 5 seconds...
ylg_hke
Skirmisher
posted 10-02-18 10:14 AM
EDT (US)
298 / 406
@AlistairJah
unless we use 'auto-update enemy' (bool).
==> cant find anything about "auto-update enemy"
I'm surprised it's not heavy at all on computer resources! it caused frame drops each 5 seconds...
==> Wait...they don't add up, frame drops = heavy on computer resources....
So far, it seems gatherplan(or gatherGoal ?) constantly adjust the villager-ratio on each resource, its totally different from how humans handle it.
Usually, we will simply add newly trained villagers to the resource we need the most, with minimum villager redistribution.
It would be great if we were able to prolong gatherplan's update frequency(aka. villager redistribution), and then focus on adding idle/newly trained villagers to the existing gather plans according to our resource forecast.
@Panmaster2014
Oh...that's a bit too high.
There are many low level players on ESO, their HC are far from LV100, so personally I would like to keep the HC requirement as low as possible.
Expert OOS could be due to changing handicaps after 1 second instead of immediately.
==> Nice, at least its something easy to fix. =]
ylg_hke
Skirmisher
posted 10-02-18 10:27 PM
EDT (US)
300 / 406
auto-update enemy
==> The closest one seems to be cGoalPlanAutoUpdateAttackPlayerID.
This one is not really a 'stand-alone' thing though, it requires aiSetMostHatedPlayerID(i);. Just disable rule mostHatedEnemy, mute all xsEnableRule("mostHatedEnemy"); & mostHatedEnemy(); , put kbUnitPickSetEnemyPlayerID 's enemy id to -1, and then AI wont train army anymore. So, precisely, in the end we have to somewhat set enemy id for it one way or another, or it wont work.
ManualGathering also handles all of that.
==> What do you mean exactly?
After a few tests, now I have no idea how AI run their econ. I put the minInterval of econMasterRule, 3 breakdowns to 300 or so. (also rule reInitGatherers is disable after first run) and so far they run it just fine, no idle villager at all, and fairly static.