1. Firaxis celebrates the "Asian American and Pacific Islander Heritage Month", and offers a give-away of a Civ6 anthology copy (5 in total)! For all the details, please check the thread here. .
    Dismiss Notice
  2. We have selected the winners of the Old World random draw and competition. For the winning entries, please check this thread.
    Dismiss Notice
  3. Old World has finally been released on GOG and Steam, besides also being available in the Epic store . Come to our Old World forum and discuss with us!
    Dismiss Notice

Sub Bug Fix and other Adventures in EXE Modding Release 10B

EXE mod featuring stack bombard, bug fixes, and more

  1. Flintlock

    Flintlock King

    Joined:
    Sep 25, 2004
    Messages:
    860
    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.
     
  2. tjs282

    tjs282 Stone \ Cold / Fish

    Joined:
    May 19, 2009
    Messages:
    4,189
    Gender:
    Male
    Location:
    Inside my skull
    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: Nov 18, 2021
  3. Flintlock

    Flintlock King

    Joined:
    Sep 25, 2004
    Messages:
    860
    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.
     
  4. Virote_Considon

    Virote_Considon The Great Dictator

    Joined:
    Jul 7, 2004
    Messages:
    9,394
    Location:
    Skaville UK Reputation: 1
    Yes, and so too are all units which are the result of enslavement
     
    Flintlock likes this.
  5. tjs282

    tjs282 Stone \ Cold / Fish

    Joined:
    May 19, 2009
    Messages:
    4,189
    Gender:
    Male
    Location:
    Inside my skull
    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).
     
  6. SteamCiv

    SteamCiv Warlord

    Joined:
    May 18, 2012
    Messages:
    131
    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: Nov 24, 2021
  7. Takhisis

    Takhisis Rum and coke.

    Joined:
    Jul 11, 2005
    Messages:
    54,362
    Location:
    up yours.
    As somebody who has just played a game with Korea I must say that this must be borne in mind.
     
  8. Flintlock

    Flintlock King

    Joined:
    Sep 25, 2004
    Messages:
    860
    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
    I don't see any problems with grouping those together except for leaders & armies so I added an exception for those. Any complaints?
     
  9. Civinator

    Civinator Blue Lion Supporter

    Joined:
    May 5, 2005
    Messages:
    7,621
    Gender:
    Male
    Are workers and enslaved workers (with only 50 % worker strength) now in the same "zero strength" group ?
     
  10. Flintlock

    Flintlock King

    Joined:
    Sep 25, 2004
    Messages:
    860
    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.
     
  11. Civinator

    Civinator Blue Lion Supporter

    Joined:
    May 5, 2005
    Messages:
    7,621
    Gender:
    Male
    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.
     
  12. Flintlock

    Flintlock King

    Joined:
    Sep 25, 2004
    Messages:
    860
    I'm planning to separate captured and native units anyway, so that won't be a problem.
     
  13. Civinator

    Civinator Blue Lion Supporter

    Joined:
    May 5, 2005
    Messages:
    7,621
    Gender:
    Male
    That´s great and thank you very much for your answer. :)
     
  14. Flintlock

    Flintlock King

    Joined:
    Sep 25, 2004
    Messages:
    860
    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:
    Code:
    bool __thiscall City::should_irrigate (City * this, int tile_x, int tile_y, int terrain_type_id, int param_4)
    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.
     
    Sutsuj, Nathiri, Node60 and 3 others like this.
  15. Lord Malbeth

    Lord Malbeth Emperor

    Joined:
    Feb 28, 2006
    Messages:
    1,854
    Location:
    Tower of Fornost
    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.
     
  16. Civinator

    Civinator Blue Lion Supporter

    Joined:
    May 5, 2005
    Messages:
    7,621
    Gender:
    Male
    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.
     
  17. Vuldacon

    Vuldacon Dedicated to Excellence Supporter

    Joined:
    Nov 14, 2001
    Messages:
    7,024
    Gender:
    Male
    Location:
    USA
    "all is Fair in games for the Human Players vs the AI" ... After all, the AI is Not as smart as YOU :)... yet
     
  18. Lord Malbeth

    Lord Malbeth Emperor

    Joined:
    Feb 28, 2006
    Messages:
    1,854
    Location:
    Tower of Fornost
    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! :)
     
  19. Lord Malbeth

    Lord Malbeth Emperor

    Joined:
    Feb 28, 2006
    Messages:
    1,854
    Location:
    Tower of Fornost
    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!
     
  20. vmxa

    vmxa Deity Supporter

    Joined:
    Feb 9, 2004
    Messages:
    14,049
    Location:
    Oviedo, Fl
    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.
     

Share This Page