So Delnar I've been using your mod since day one, but I don't know if it's just me or the one game I played, but the Ai in Siesta's mod during battles was actually spot on.. Perfect moving with ranged and melee.. Just thought it might be worth seeing if he's changed combat from yours!
I have looked at those myself: the only difference between our mods regarding tactical unit control is that Siesta's tries to reorder tactical moves by assigning them values, while I try to reorder tactical moves by physically reordering them within the database. Since vanilla Civ6 orders moves by the order in which they appear in the database and doesn't assign them any values, my method will work for that, and I don't know if Siesta's will (if the DLL is OK with using values instead of primary key order to determine move order, then both should work).
In any case, neither of our mods actually changes tactical unit control. If you are indeed saying that the AI was using perfect unit control (rather improbable unless you've got low standards, since there are some unit control options that the AI flatout has no access to, e.g. moving and shooting with a ranged unit not adjacent to the target or swapping two units), then it's a result of the core game itself and has nothing to do with any mods. Indeed, unless we're talking about a Lua mod that recreates CvTacticalAI and overwrites it (i.e. an event forces units to move around and run commands, and this event is placed into a listener that is called once per player turn before CvTacticalAI but after core player turn processing), unit control cannot be modded for now.
Ah those. Well, I've seen a -50 in some vanilla stuff before, which suggests it at least does something more for higher numbers, but how exactly the two variables work is indeed beyond me. It's possible that they don't do anything different and that some slightly different behavior I appeared to see in testing may just be placebo.
Check the reference in my signature. The Operation Change Target node type's second argument (which is the thing you're altering, since the node you're changing is an Operation Change Target node and the DefnID is 1, indicating second argument) is called "Failure Amount". IIRC, in Civ5, the retargetting function for operations contains a large loop that attempts to retarget the operation based on a virtual function, with the loop terminating if a new target is found or if a new target is failed to be found after N attempts. I'm fairly confident that the argument we're talking about control such a loop, and if the internal, retargetting virtual function returned no new target after being run from beginning to end twice, I don't think you'll gain anything by having it run five or 48 more times.
The citybuilds log suggests that the final step done to choose between options is a choice between the various build contracts that are made through operations, each with its own value assigned. My guess is that an operation is necessary for an option to be available, and that all the systems we can see (pseudoyields, favored, flavors) only affect the internal decision making that ends up supplying that number.
It's certainly rather confusing what the exact method is. In the case of settler production, we have pseudoyields, the expansion flavor, the behaviortree for the settle operation, some sort of decaying thing that requires a minimum number (which relates to plotevaluations and some kind of distance based algorithm we cant see), some function in the rapid expansion strat that checks whether there's a settle spot, a limit on settle operations that can be running, other operation settings like its team, and possibly the 'favored' mechanic and probably some stuff we can't see in the dll.
It's honestly bizarre that they introduced so many systems here, yet failed to make the standard settling behavior anywhere near competent and do stuff like completely ignore all the yields beyond the first ring...
No, that sounds about right. Civ5's flavor system basically just involved looping through all flavor types, generating the products (leader flavor + player strategy flavor + city strategy flavor)*(entry flavor), summing those products, applying a few conditional modifiers to the sum (e.g. doubling the sum if the entry is a building with no maintenance cost and the current city is a puppet), and multiplying the sum by the output of a power function of production time to determine the entry's total flavor, then building the entry with the highest total flavor. Units requested for operations (remember, Civ5 had operations, too) had modifiers applied through the conditional modifiers section, with a fairly large boost to flavor for sneak attack operation requests at high AI difficulty IIRC.
What I'm guessing is that this overall structure is still in place, albeit with the flavor summing and product system replaced with an internal scoring system that determines baseline favor from the entry information itself, rather than use pre-defined flavors, and the values you're reading in the log files are the total flavor values I mentioned (they're renamed "pseudoyields", but otherwise they're the same). The favored/disfavored system, as well as all the other values you can use as a part of AIFavoredList, simply feed in as either conditional modifiers in addition to the conditional modifiers we don't have access to, or as a stratification system where the entries are sorted into 3 lists (favored, neutral, unfavored), each of which get their highest value entry determined, and an extra scoring step at the end determines which of the items will be chosen (the favored one, the neutral one, or the unfavored one).
Any idea how you would figure out in the lua that a settler targets a certain spot?
Create an event in a listener that triggers once per player turn, have that event run through all active operations and filter out any non-settle ones, pass the target of each operation to whatever zone-generation function you plan on implementing.
. Omiting the cross over with Default Tactical and Default Homeland, seems to play great, hats off to you both!
