Thanks @phosit, this is exactly the feedback I wanted. PRs. Fair. Those were low-priority fixes I made while setting up my local environment on macOS (not easy) and to test the AI-assisted workflow I'm using now. I'll reopen the ones that still make sense (#8976 fixes the still-open #8975; #8977 I owe you the commit split) and answer the pending reviews. No hard feelings. I agree, and I'd put the line here: the model never writes behaviour. Every stratagem, every question and every fallback rule is plain JS/Python you can read. The model only picks between options we wrote, and the rule arm (a hand-written distance rule) exists precisely so the model can be swapped out and compared. - i am building it now with laya, but it should allow easily swap to use other like Jev - At the end of the day the model will pick up which "function" in the system to use.   Two tasks in one system. Partly a misunderstanding on my side of the post: hero "playbooks" are strategy (Fabius = delay, Leonidas = hold the pass), not unit micro, and the actual fight stays Petra's. But you're right that "hold / strike / fall back" every few seconds sits between strategy and tactics. I'll keep the questions at the strategic level (which stratagem, where, when to commit) and leave "when to end an attack" to Petra's existing attack-plan logic unless the data says otherwise. Starting strategies. Looked at startingStrategy.js (configFirstBase): flags from land/food/wood plus the personality axis, chosen once, no civ or enemy input. That's a natural home for the civ-doctrine part (a named opening per civ instead of threshold flags), and a smaller, more upstreamable change than what I described. I'll start there for the early game. State as language. I won't feed raw commands. The state is a short readable summary ("enemy army of ~30 units, 80 m from the pass, moving toward our tower; our 25 units garrisoned"), which is what these classifiers are trained on. I measured Laya locally today: ~40 ms per question on a laptop CPU after a one-time 55 s load. I'll publish the exact input format with the dataset. Host-only model. You mean #8786, I think. That one moves all of Petra to the host and clients stop simulating it, so a modified AI would be undetectable; I understand why it stalled. This proposal is narrower: Petra keeps running on every client (so the OOS hash still covers it) and only the hint is a host command, the same class as any command a human host sends. The residual risk is a host sending sabotaging hints to an AI slot, which is a "bad ally" problem, not a desync one. It's not doable as a pure mod, agreed: the server must accept that one command type for AI slots. That's a small engine change, and single-player needs none of it. And yes, using a model to find where Petra is weak is a good use too; the labeled game states from this work could feed that. To be clear about the goal. Performance (Petra's or AI lag in general) is not what I'm trying to improve. The goal is a smarter Petra: strategies that fit the civilization and the hero it's playing, the way those armies actually fought. Whether that needs a model at all is an open question. Right now this is a prototype, there's plenty of room for improvement, and I'm fully open to dropping the model if a deterministic, hand-written way gets the same result.   

Ive been using AI to help improve Petra.  I have an "expert" version that comes with Classical Warfare AEA.  But I'm you could easily just download the AI files. ALthough it does specifically work with some of our overall changes.  It can randomly roll 4 strategies, p1 rush, p2 military tech push, p3 max pop max techs and I forget the 4th one  It beats very hard 95% of the time (and only has a 20% gather resource bonus instead of the 56% that VH has)  but I'm still trying to get it to be more efficient.  A lot of times it will basically break very hard by 10 min, but then it takes another 10-15m to actually finish the gam 

You are such a gigantic troll  But I'll bump on it still, and give some nerdy details. The collisions between units are not indeed like solid bodies that are impossible to overlap, even with this PR, this will remain true for most units. It's more a spring-like push that tries to make units keep distance to each others. This pushing just use a distance-to-center repulsion force. What's introduced here for boats and elephants is a different stronger pushing and that actually take the unit's shape into account. This is why on the video you see that the hulls act like actual solid bodies. However simulating this, is ~x1.5 time costlier then the simple radial spring pushing. So because that, for small units, the difference in visible behavior would be minor, better go with the simple pushing, and use the better one only for big units that get the most benefits from it. A fun fact is that before this PR, all units were treated the same, so you did had still this radial-pushing for boats (the collisions were spring-like and only a small circle at the center of the boat was even acting as the hitbox) but it was still much bigger then for, say infantry. To detect if units were colliding, the map had a grid that allowed each unit to search a limited area where it might be actually colliding with other units. This grid size had to be proportional to the largest pushing unit of the game : boats - who's pushing effects where questionable anyway. Even if you played on mainland map with no ships whatsoever, the grid was sized to work for boats too. And your unit had to check their distance with much more other units they needed to. So you can say that the lag you experience on mainland, was partially due to ships. This along a few other optimizations with the pushing and more resilient obstruction handling, make the PR a performance improvement for common scenarios (yey!).

Hi, i closed your PRs as you didn't reply for some months. Feel free to reopen them. Nice that you work on this. I also had plans to use AI to improve the Petra. (Not to integrate it but to use it to see where Petra is bad at.) Integrating it that much goes (for me) against the free software philosophy. Every code should be possible to understand. You want the AI to choose a strategy. But you also want the AI to say when to end an attack (fall back) and how a hero should fight. Thous seem pretty different tasks. I think it's bad to solve both with the same system. Currently there are starting-strategies witch are chosen from. It would be good when you take a look there. Maybe you can extend that. The model you choose takes language as "state". Yes it can be json formated and yes it's multilingual but i'm not sure it understands something like  {"type":"repair","entities":[177],"target":4030,"autocontinue":true,"queued":false,"pushFront":false,"formation":"special/formations/null"}   Why? There has recently been a PR wanting to do a similar thing for Petra. As i remember it the conclusion was to not continue the plan for now. I don't think that it is possible to do it in a mod.

This seems to now be used for the Gaul and Briton villagers. Not sure how accurate it is in that more lower status role (in any case, the villagers might work better as freemen/commoners. With the servants/slaves being portrayed by another type of villager once implemented).