Good points. I could make an exception for artillery with lethal bombard, or I could avoid all problems of that kind by ignoring experience only on workers. Also you mentioning modded games reminds me that I never looked into how the menu grouping interacts with sacrificing or escorting of princesses. Right now a unit with a princess attached will get grouped up with others, which should definitely be changed. I don't know about sacrificial units, it's been so long since I've played a mod with that mechanic I don't even remember how it works.
Resource icon
- Thread starter Flintlock
- Start date
tjs282
Stone \ Cold / Fish
The unit-type has to have the "Sacrifice" unit-action checked in the Editor, and only foreign units (whether captured or enslaved) may be sacrificed.
The mods I'm familiar with that use this mechanic (Mesoamerican Conquest, CCM, Tides of Crimson) use the generic Worker, or specialised unit-types (captured or enslaved) as their sacrificial units, so given that C3X already sorts by unit-type, this should already happen, broadly speaking — or it will once you distinguish between foreign and domestic units (in CX3 v.8, sometimes the native workers get 'hidden' by foreign workers).
A unit carrying an immobile princess/treasure-type unit gets exclamation-marks (I think 3, but I don't remember exactly) appended to its name (which is also shown in red in the drop-down unit-list), so if CX3 also already sorts units by name(?), those would be set apart as well. If not, then maybe it could be set to look for that "!!!" suffix, or the red text.
EDIT:
@Knightfall posted this link in another thread:
https://www.pcgamingwiki.com/wiki/Civilization_III
It included a link to Antal's patch (the later versions of which didn't actually work properly), so I have edited that page to also add a link to this thread; I hope you don't mind?
Last edited:
Alright. I'm guessing there's never any reason to sacrifice captured units of one nationality over another so all captured units can be safely grouped together separate from the native ones. Should this separation be limited to workers and sacrificial units? Are all captured units (thinking of artillery here) maintenance free like workers? I'd like to keep captured and native artillery together unless there's some reason to separate them.
Right now it doesn't separate units with different names, but maybe it should? For me personally it doesn't make any difference either way but it would be easy to make happen so if someone wants it that way, just ask. I've already figured out how princess escorting is recorded in the unit data so units can be grouped that way independently of their names.
Thanks. I don't mind at all.
Virote_Considon
The Great Dictator
Yes, and so too are all units which are the result of enslavement
tjs282
Stone \ Cold / Fish
Once a sufficient stack of foreign replacements has been acquired, separation would make it easier to selectively remove/disband the natives (to save on unit-maintenance).
I probably would not want this for my games, because I like to rename units for convenience (loadable units) or entertainment-value (Elite* units).
SteamCiv
Warlord
- Joined
- May 18, 2012
- Messages
- 131
Flintlock, one more time thank you very much!
While waiting for the C3X Release 9, I made another testgame with your version 8 and the upcoming German C3C version (the translated standard C3C with updated graphics). Now I cannot stop this game as it is very interesting.The offensive artillery in version 8 is a real game play changer. Here is a screenshot of an offensive Iroquois stuck in era 4, containing 34 artillery (bombard range 2), 67 infantry and 1 flak. Absolutely devastating!
How you can play games with 60 stack units on largish performance intensive maps is amazing in itself.
I took my old CCMS 1.7 world 100x100 31 player map and updated it for your excellent CCMs 2.50 (had to make some changes, ie 2x auto-building time else map is overrun in a short time)
Testing it now with the new Flintlock release.
----------------------------
Edit Wed Nov 24 2021
As far as I can tell Flintlocks version is working very well with CCMS2 (and actually, I made NO changes to CCMS except import it to may map), more detail for CCMS2 specific stuff will be added in that thread,
Last edited:
As somebody who has just played a game with Korea I must say that this must be borne in mind.
I'll sum up the changes, partially for my own future reference:
Zero strength means zero attack, defense, bombard, and air defense. In the base game the zero strength units are:
- workers
- settlers
- scouts & explorers
- tactical nukes & ICBMs
- princesses
- leaders & armies
- Joined
- May 5, 2005
- Messages
- 8,884
Are workers and enslaved workers (with only 50 % worker strength) now in the same "zero strength" group ?
Yes. Zero strength units are supposed to be all units whose experience level can be safely ignored. "Zero combat strength" would be a more specific name for them, except nuclear weapons are included which arguably have combat strength. Now that I think of it, cruise missiles could be included too even though they have non-zero bombard strength, but they're used so rarely I don't think they're worth the effort.
- Joined
- May 5, 2005
- Messages
- 8,884
Flintlock, in the sucession games of CFC the players frequently separate workers (with 100 % worker strength) and enslaved workers (with only 50 % worker strength) and I think this makes a lot of sense. So the experience level here can be ignored, the level how fast they can finish their worker jobs shouldn´t be ignored.
- Joined
- May 5, 2005
- Messages
- 8,884
Since posting R9 I've been looking into the AI worker routines to see if I could allow the AI to replace tile improvements. I was hoping this would be a simple matter of flipping a bit somewhere, but it's not. Maybe that's for the best since it's led me to making deeper changes to the worker AI, and while I'm doing that I can hopefully get the AI to make better decisions overall about when to irrigate, like stopping it from irrigating grassland in despotism.
You might guess that the AI automates its workers but technically it doesn't, at least not for the core jobs. It does use the road building, pollution clearing, and forest chopping automation states, but for irrigating and mining it orders its workers around "manually". Though the functions it uses to determine what to build are probably reused for automation of human workers, I haven't looked into that. Drilling through several layers of AI decision making, at the bottom there's one critical function that determines whether to mine or irrigate a tile. For anyone following along at home, its GOG address is 0x42B820 and its signature is:
This function's job is to answer the question "does this city want the tile at (tile_x, tile_y) irrigated?". If it answers no (false), that's interpreted to mean the tile should be mined instead.
This function is responsible for the two big problems with AI worker management: under the standard game rules it will never tell a worker to replace a mine with irrigation or vice-versa, and it fails to properly account for the despotism penalty when deciding what to build. It won't replace mines<->irrigation because it's programmed to always preserve the existing improvement as long as the nominal yield of the replacement is the same. I.e., if a city is surrounded by mined plains, the function reasons it could replace a mine worth 1 shield with irrigation worth 1 food and since 1 = 1, they're the same, not worth replacing. The problem of course is that it doesn't account for what the city needs. Note that the AI actually can replace improvements but only if you mod the game so that the replacement is nominally better. For example, set up a scenario with an AI city surrounded by mined plains and make irrigation worth 2 food on plains, you'll see the AI will irrigate over the mines where possible.
About the tile penalty, the should_irrigate function does contain some logic to deal with that, except it's bugged. At the beginning of the function, it multiplies the food and shield values of irrigation and mines by some factor that was presumably supposed to be variable but in the end it's fixed at 4.0 for both. The bug is that the logic to handle the despotism penalty uses the scaled yields instead of the raw yields. So the logic for irrigating grassland in despotism goes something like this: irrigating would be worth 4.0 * 1 food = 4 food, hitting the penalty, but mining would be worth 4.0 * 1 = 4 shields, also hitting the penalty, so the penalty doesn't matter.
The tile penalty issue could be fixed by setting the scaling factor to 1.0, assuming that has no negative side effects, but I don't see any way to fix the replacement issue without overhauling the logic since there the fundamental problem is that the function tries to compare the value of food and shields without checking what the city actually needs. So I plan to replace should_irrigate entirely like I did for the leader unit AI, and I'm doing it for the same reason that the logic's buggy but even without the bugs I don't like what it's trying to do. My idea for a replacement algorithm is that tiles owned by some city will be irrigated in order of their potential until the city has enough food to reach its target population (plus a little) then all remaining tiles will be mined.
So far I've implemented the basic algorithm and checked that it basically works. It was surprisingly tricky to get it working well, an easy failure mode to fall into is AI workers getting trapped in cycles of irrigating over mines then mining over irrigation, back and forth, on the same tile for potentially dozens of turns. The fundamental problem is a feedback loop between the amount of food the city has and the improvements surrounding it. To break that loop I had to make the irrigation logic dependent not on how much food the city has but rather only on the surrounding terrain. Even then there were subtler issues like the fact that the set of tiles available to irrigate changes depending on which ones are already irrigated, and that if a tile can be worked by different cities then it can get contradictory instructions for improvement.
Anyway, like I said it's basically working. The next steps are: (1) Define the target population for AI cities. Right now it equals the number of tiles owned by the city, which works well as a baseline, but ideally the definition would include limits imposed by buildings & freshwater and maybe happiness too. (2) Better prioritize irrigatable tiles. It needs to account for the fact that most tiles can either be mined or irrigated so when choosing to irrigate there's an opportunity cost for not mining. (3) Run some more experiments with the new algorithm. In particular I'm planning to create a scenario with starting areas designed to test the AI so I can compare with vs without the new irrigation logic.
You might guess that the AI automates its workers but technically it doesn't, at least not for the core jobs. It does use the road building, pollution clearing, and forest chopping automation states, but for irrigating and mining it orders its workers around "manually". Though the functions it uses to determine what to build are probably reused for automation of human workers, I haven't looked into that. Drilling through several layers of AI decision making, at the bottom there's one critical function that determines whether to mine or irrigate a tile. For anyone following along at home, its GOG address is 0x42B820 and its signature is:
Code:
bool __thiscall City::should_irrigate (City * this, int tile_x, int tile_y, int terrain_type_id, int param_4)This function is responsible for the two big problems with AI worker management: under the standard game rules it will never tell a worker to replace a mine with irrigation or vice-versa, and it fails to properly account for the despotism penalty when deciding what to build. It won't replace mines<->irrigation because it's programmed to always preserve the existing improvement as long as the nominal yield of the replacement is the same. I.e., if a city is surrounded by mined plains, the function reasons it could replace a mine worth 1 shield with irrigation worth 1 food and since 1 = 1, they're the same, not worth replacing. The problem of course is that it doesn't account for what the city needs. Note that the AI actually can replace improvements but only if you mod the game so that the replacement is nominally better. For example, set up a scenario with an AI city surrounded by mined plains and make irrigation worth 2 food on plains, you'll see the AI will irrigate over the mines where possible.
About the tile penalty, the should_irrigate function does contain some logic to deal with that, except it's bugged. At the beginning of the function, it multiplies the food and shield values of irrigation and mines by some factor that was presumably supposed to be variable but in the end it's fixed at 4.0 for both. The bug is that the logic to handle the despotism penalty uses the scaled yields instead of the raw yields. So the logic for irrigating grassland in despotism goes something like this: irrigating would be worth 4.0 * 1 food = 4 food, hitting the penalty, but mining would be worth 4.0 * 1 = 4 shields, also hitting the penalty, so the penalty doesn't matter.
The tile penalty issue could be fixed by setting the scaling factor to 1.0, assuming that has no negative side effects, but I don't see any way to fix the replacement issue without overhauling the logic since there the fundamental problem is that the function tries to compare the value of food and shields without checking what the city actually needs. So I plan to replace should_irrigate entirely like I did for the leader unit AI, and I'm doing it for the same reason that the logic's buggy but even without the bugs I don't like what it's trying to do. My idea for a replacement algorithm is that tiles owned by some city will be irrigated in order of their potential until the city has enough food to reach its target population (plus a little) then all remaining tiles will be mined.
So far I've implemented the basic algorithm and checked that it basically works. It was surprisingly tricky to get it working well, an easy failure mode to fall into is AI workers getting trapped in cycles of irrigating over mines then mining over irrigation, back and forth, on the same tile for potentially dozens of turns. The fundamental problem is a feedback loop between the amount of food the city has and the improvements surrounding it. To break that loop I had to make the irrigation logic dependent not on how much food the city has but rather only on the surrounding terrain. Even then there were subtler issues like the fact that the set of tiles available to irrigate changes depending on which ones are already irrigated, and that if a tile can be worked by different cities then it can get contradictory instructions for improvement.
Anyway, like I said it's basically working. The next steps are: (1) Define the target population for AI cities. Right now it equals the number of tiles owned by the city, which works well as a baseline, but ideally the definition would include limits imposed by buildings & freshwater and maybe happiness too. (2) Better prioritize irrigatable tiles. It needs to account for the fact that most tiles can either be mined or irrigated so when choosing to irrigate there's an opportunity cost for not mining. (3) Run some more experiments with the new algorithm. In particular I'm planning to create a scenario with starting areas designed to test the AI so I can compare with vs without the new irrigation logic.
Lord Malbeth
Emperor
Hey, don't meant to jump in here in the middle of stuff, but is there any way you could look at hidden nationality units, specifically how the player can use them? I'm annoyed that you cannot use them to capture cities... while the AI can.
- Joined
- May 5, 2005
- Messages
- 8,884
Lord Malbeth, the human player can capture cities with HN land units, but only after declaring war to the owner of the city. The AI HN unit can capture the city without declaring war - that´s the difference.
Lord Malbeth
Emperor
Let me rephrase what I meant: I'm aware of the dif, I just want the AI and the human to be on the same level: either both can use HN to capture cities without declaring war, or neither can. Hopefully that is better worded!
Lord Malbeth
Emperor
Sorry to jump back here, but is this still a possibility? I'd love to have settings for a mod I'm working on not adjust the base game if I can. This would be an awesome fix!
Maybe it would be easier to just add a flag to the ini for NORASE. Then they could use it or not and you would not have to update for any new scenario that comes out.
Similar threads
