AdvCiv-SAS (Simple Advanced Strategy)

Joined
Jan 18, 2025
Messages
197
Hello,

Following the release of AdvCiv-SAS (in the Modpacks Downloads section), a mod based on AdvCiv 1.12 that aims to make the AI more challenging, enhance UI and documentation, as well as rebalance and focus on historical accuracy and such, here is the corresponding discussion thread i am opening, if you have questions you can ask them as well, although i don't guarantee i would be always available or would respond, the thread is still here i guess xd.

I want to first express proper thanks to @f1rpo for making AdvCiv which i base my mod on, i didn't properly or do it enough in mod general description but is maybe fine as such, as well as other mods i take assets from (mentionned in main readme in documentation, see above link for reference).

With that said, if you want to play AdvCiv-SAS, please make sure to lower diffculty, i don't want to overhype it, but i got rekt badly when playing it myself the first time at monarch, which was a difficulty i was comfortable with and consistently won on, although i am a bit rusty since i didn't play since then.

Below are the screenshots of how it went as a discussion opener perhaps, maybe you'll be more lucky than me or effective, but be prepared for war and blood maybe xd but anyways etc.

I didn't take them seriously enough after starting with a quite good early, i thought my 10+ stack was enough.. Lesson learned xd, but for now i'm more looking forward to hear from players who would try it, especially if they walkthrough it video, or generally feedback here if i reply though as it is not guaranteed i mean, thanks
 

Attachments

  • Civ4ScreenShot0014.JPG
    Civ4ScreenShot0014.JPG
    1.1 MB · Views: 160
  • Civ4ScreenShot0008.JPG
    Civ4ScreenShot0008.JPG
    1 MB · Views: 148
  • Civ4ScreenShot0003.JPG
    Civ4ScreenShot0003.JPG
    1,007.7 KB · Views: 113
  • Civ4ScreenShot0011.JPG
    Civ4ScreenShot0011.JPG
    1 MB · Views: 114
Last edited:
wow this is wonderful!

im so glad to see that someone picked up on advciv.
looks like you did an extreme serious work.

i love the detailed documentation and the order you kept. well done.
im eager to explore your changes.

my advc modmod has been around for years now, stopped working on it since f1 seem to be retired :(
so you give me new motivation.

is it ok if i use you mod with mine later on?
if so,
may i ask if your main branch of changes is named tech-rework?


anyway, amazing, good work!!!
i will watch this one closley.
 
hehe glad you like it :)

yes you can use my mod no problemo xd, i like to be named/mentionned but even that is not an obligation (although appreciated xd but again no obligation) as i said in (https://github.com/wonderingabout/AdvCiv-SAS?tab=readme-ov-file#license-and-reuse)

and yes indeed, tech-rework is the current main branch, no change since then (although i planned some (mostly/only in the future era) but bit tedious for now xd, i may or may not do them later)

if you base your mod on mine, then i may implement whichever fixes or tweaks i find relevant in yours too :) (crediting you xd)

edit 3: if you want to just take some ideas/code from my mod instead, this is fine as well as explained below hehe thanks

i did take some description from doto in the building xml field descriptions, it was nice and helpful although i didn't use it too much.

But yes starting from / or taking changes from my mod you'd get mostly an "advanced AI" and UI like sevopedia and such, there might be bugs or less likely crashes although i should have covered most or reverted unstable code, but it can always be improved, and there are some areas like sucidal war declarations, smarter tech trading i didn't touch (at least yet if i ever do), but i believe the changes i made are already very significant.

In the documentation, in particular known issues, i provide before/after screenshots for most, so all my changes are experiential based and only implemented if AI seems stronger after them for most if not all :)

If you want a tamer AI, you could for example make it more eager to build wonders by lowering the maximum turns threshold (edit: i mean increasing the max number of turns, say from 20 to 25 turns for example so AIs think a wonder is still good to go for if it takes 24 turns in their best hammer cities vs rejecting it as < or <= forgot which xd 20 for example anyways etc) to build a wonder before it thinks it's not worth it (i think i did like 20 turns), or comment out the whole building value block i added which shouldn't be too hard (or filter in it what you want) (but then it may do stupid buildings again xd)

In all cases if you have ideas i could improve my mod with your ideas too xd, i noticed in doto there is the hebrew/jewish civilization, if i ever added a civilization it would have been the next (no leader likes judaism in civ4!), but it's tedious to do, i even have leader and such ideas if you're curious xd i could mention here as well

in all cases thanks for your interest, yes advciv is overall a very good mod i'm glad to have expanded on :)

edit: like i said for the future it is unlikely i would make many more changes, but not totally off either i don't know, tempting but takes time xd, but i believe there is already plenty to browse and experiment with with the changes i made hopefully :) thanks for your interest too again hehe thanks :)

edit 2: as for advciv itself, it is unsure if @f1rpo retired or simply took a break or whatever i have no idea, but if he (assuming he is a he as i don't know else apologies xd but anyways etc) comes back to civ4 modding maybe he (same) could comment on my mod too xd and he (same) did help me for a few early issues i had when i started this mod hehe so thanks to him (or her if i took it wrong my bad xd) as well thanks i mean but anwyays etc :)
 
Last edited:
Unfortunately, I couldn't even launch the MOD.
 

Attachments

  • 2025-09-08_015157.jpg
    2025-09-08_015157.jpg
    92.3 KB · Views: 88
  • 2025-09-08_015208.jpg
    2025-09-08_015208.jpg
    26.9 KB · Views: 90
Yeah, it was the wrong folder name, thanks. Are 48 civs DLLs expected? I can't imagine the game without it to be honest xD
 
Since my mod is based on advciv no reason it cannot be (48 civs xd) (unless my code changes somehow would prevent it but very unlikely, but would need to try to be sure), just i never tried it / don't use it myself nor do i know how, so if you have instructions on how to, i may provide such a dll as well :)
 
Update :): Added the 48 civs DLL with info on how to download and use it :)

See https://github.com/wonderingabout/AdvCiv-SAS/blob/tech-rework/README.md#48-civs-dll for details

A few examples of how it went from the drive link there (no spoiler hopefully xd if want to keep the suspense but anyways etc) below in screenshots

Converting the very nice base advciv manual to .txt was very handy to do quick global searches with vs code in it too but anyways etc :)

Running the game end to end until X player won at turn Y but no spoil xd was also a good confirmation that all seemingly works well so all good (since my mod is based on advciv and it seems i didn't add anything that would make it crash in this test run at least xd so all good anyways etc)
 

Attachments

  • Civ4ScreenShot0033.JPG
    Civ4ScreenShot0033.JPG
    392.6 KB · Views: 65
  • Civ4ScreenShot0032.JPG
    Civ4ScreenShot0032.JPG
    399.8 KB · Views: 58
  • Civ4ScreenShot0030.JPG
    Civ4ScreenShot0030.JPG
    208.3 KB · Views: 48
  • 48 dll 2.PNG
    48 dll 2.PNG
    550.1 KB · Views: 44
  • 48 dll 1.PNG
    48 dll 1.PNG
    1.1 MB · Views: 38
  • 48-civs-dll-github-download-raw-file.PNG
    48-civs-dll-github-download-raw-file.PNG
    193.4 KB · Views: 66
Thank you so much, honestly, it was really fast
 
welcome hehe thanks, well your mention of "48" civ dlls (and previously your screenshot) helped me too to find it faster xd, i had thought of it (including 48 civ dll) at some point but then forgot it as i dont use it myself and didn't note to do it

ideally i would add some compile instructions so players can compile dll themselves, perhaps with the 48 civs example, but if we don't change advciv-sas too soon or at all then it is fine for me to provide it, after all it only takes 2 minutes to compile more or less on my computer once someone knows how, you'd need to test it in autoplay or such to be sure though as in some very rare cases you get very weird results, if curious about that, see:

- https://github.com/wonderingabout/A...ce-files-if-i-am-not-mistaken-but-anyways-etc
- https://github.com/wonderingabout/A...-else-maybe-or-whatever-maybe-but-anyways-etc

is bit tedious to write xd but maybe i'd do it (not guaranteed, i may or may not do it but anyways etc), in all cases thanks too i mean but anyways etc :)
 
quick extra info hehe, since some players are playing/trying this mod and maybe they'd want to know about this to or/and participate. Some/a player asked me (in private message but anyways etc) a question about how advciv-sas ai fares vs BTS AI, here is the reply i gave (without mentioning them or things related to them so i removed a bit of it but most is there anyways etc) if you'd want some extra info:

Hello, i didn't play BTS that much so it would be hard to say, but i guess that AdvCiv 1.11 (i played most) and then the 1.12 one do things quite a bit better if not more would be in terms of strength something like 120 to 140% the strength of BTS? (Again hard to say as i didn't play too much BTS and otherwise come/came from civ3 background i had much more experience about at monarch/emperor)

As for my mod, it is definitely stronger than AdvCiv be it 1.11 or 1.12. As my mod is based on AdvCiv 1.12, i'd compare it to 1.12 rather. Its strength depends on maps, but it could be, if you compare it to BTS AI, something like 200 to 300. But i made many changes in my mod that make the game harder, so it is not obvious sometimes. For example, barbarians are much stronger (in one rare run they captured the entire map (all cities), i nerfed them a bit since then), so AIs in AdvCiv-SAS may seem like they are struggling if barbarians beat them too hard. I also thought it's a good idea to keep them in check else they would runaway quite often or have excess units which i thought barbarians could help trim. Then another big change is the reduction to era multipliers, in advciv and i assume bts as well, era multipliers are much smaller at later eras in particular, so before i changed them my AIs would quite often run around at industrial era with like 250 units facing each other which was insane xd so i had to nerf it somehow and help them not go bankrupt too soon (which surprisingly they didn't do that much). The handicap settings are overall easier than base advciv and i assume bts (no extra workers, less increment per difficulty, etc.), to have a fair game with humans, else they'd stomp the human too easily at least in the autoplay runs i made.

There may be other changes, but mostly, it may seem like my AI behaves quite similarly than base advciv AI, but i tamed it hard to do that, and the human should have same restricitons (e.g. era multipliers causing less runaway and slower production/research/etc later in the game if i'm not mistaken etc)

Also the final factor is fluctuation, in some runs the AI for some reason performs better than others, so if you take all these into account the AI may not seem too different than base advciv *in some runs* if i may say but anyways etc, but in some other runs like the first one i tried, they may surprise you with 20+ stack units at turn 120 or something like that, or say relevant later in the game.

Also, some bugs being solved in my mod like 50+ turns workboat loop in some cities and even capitals that were not that rare, no production turns replaced with decent units, etc, not building wonders especially early almost never, all make the AI stronger in subtle ways. In all cases thanks :)

edit: what you should also observe with my AI/mod is a stronger potential for comeback and relevance in later game, the game is not won even if you have some advantage early (for some reason Justin AI seems to be especially good at this, in the few autoplay runs i tried where he was towards the end of development of this mod, he would always either win, or comeback from a bad early game and win for some reason, could be coincidences (+/- 5 different maps autoplayed to turn +/- 300 until win or late game) or there is something that goes well with the settings of justin ai (i have observed hatshepsut does very well too for some reasons but could be coincidences too anyways etc)

edit 3.2: i did an autoplay test run at a large map (so research bit slower if i'm not mistaken anyways etc) in monarch difficulty, all leaders random, to see how AIs would perform :) https://drive.google.com/drive/folders/1J8w-LbeZrD2fuifSxT8vJOXYU1MQ_YDh

edit 3.3: also added since then after sending this message but anyways etc after win extra data (in autoplay test run 0) for fun xd if i may say but anyways etc

I'd like also to provide some feedback about which AIs seem stronger although it is hard to tell as starting point, luck throughout the game, etc, influence, but generally i have found in the few autoplays i tried, if not variation, justin ai to do especially well even if he has a bad or mid/worse start if i may say but anyways etc for some reason, hatshepsut ai too it seems, and cyrus ai and ewuare ai (actually ewuare was based inittially on cyrus ai so may explain why they perform quite/a bit similarly *maybe* but is just speculation/suspicion not sure but anyways etc) in particular among those i remember

I also started a game at prince, played much more carefully but also better as i was less rusty now xd after the stomp (did things like trading ressources/bonuses a lot more which i didn't do in my first advciv-sas game but anyways etc, despite otherwise doing really well with the starter i got i'd say but got caught offguard with their stacks and overall game progress (in techs too anyways etc), also had tech trading in this 2nd try unlike in my first advciv-sas game which helped me quite a lot, with a better starting location, so so far i'm ahead quite a lot, but other AIs are not too far behind, especially hatshepsut in this game as well, so playing careful xd and seeing (if i continue this game i mean but anyways etc), if you'd like you could also share your experience here, if not i added this message/info/talk i wanted to make since i wrote it anyway, hopefully helpful but anyways etc
 
Last edited:
update: in the development version (download zip to test it on github, should be stable since i didn't change much since then but check to be sure anyways etc (info how to download it here as well anyways etc), AI now is able to overcome this even better and could come back.

Instead of evacuating only 2 swordsmen, it now evacuates the whole 11 unit defending stack (so the 9 other units don't die, and we give up the city bloodless instead anyways etc), and as a result survives nicely, and makes a comeback in the middle game even, see for details: https://github.com/wonderingabout/A...-of-land-unit-type-in-cvunitaiai_evacuatecity

Sample screenshots from there below (see the google drive link in above known issue link for more screenshots or files anyways etc) are shown here as well of how it went from there in images anyways etc

Hard for monarch!!!! But AI did very well it seems xd, i have ideas how to improve it further xd as some behaviours are still weird (if i find how to code it xd and actually search it (and not guaranteed i would, i may ideally but may also not do so, anyways etc) but anyways etc)
 

Attachments

  • Civ4ScreenShot0229.JPG
    Civ4ScreenShot0229.JPG
    1.3 MB · Views: 28
  • Civ4ScreenShot0228.JPG
    Civ4ScreenShot0228.JPG
    1.3 MB · Views: 28
  • Civ4ScreenShot0227.JPG
    Civ4ScreenShot0227.JPG
    1 MB · Views: 26
  • Civ4ScreenShot0226.JPG
    Civ4ScreenShot0226.JPG
    1 MB · Views: 25
  • Civ4ScreenShot0225.JPG
    Civ4ScreenShot0225.JPG
    1 MB · Views: 25
  • Civ4ScreenShot0224.JPG
    Civ4ScreenShot0224.JPG
    1 MB · Views: 25
  • Civ4ScreenShot0223.JPG
    Civ4ScreenShot0223.JPG
    1.3 MB · Views: 24
  • Civ4ScreenShot0221.JPG
    Civ4ScreenShot0221.JPG
    1 MB · Views: 20
  • Civ4ScreenShot0213.JPG
    Civ4ScreenShot0213.JPG
    1.3 MB · Views: 19
  • Civ4ScreenShot0214.JPG
    Civ4ScreenShot0214.JPG
    1.3 MB · Views: 19
  • Civ4ScreenShot0218.JPG
    Civ4ScreenShot0218.JPG
    1.3 MB · Views: 18
  • Civ4ScreenShot0219.JPG
    Civ4ScreenShot0219.JPG
    1.3 MB · Views: 19
  • Civ4ScreenShot0220.JPG
    Civ4ScreenShot0220.JPG
    1.3 MB · Views: 19
  • Civ4ScreenShot0230.JPG
    Civ4ScreenShot0230.JPG
    1.3 MB · Views: 32
Last edited:
Since last time i made quite many improvements, in particular if not only to AI!

Still only in the development version as of now, but AI is quite a lot stronger.

Recent changes in: https://github.com/wonderingabout/AdvCiv-SAS/commits/tech-rework/

Key points (from memory xd anyways etc):
- fix/greatly enhance siege overproduction early (in particular trebuchets, but not only), so AIs are much more effective. Often noted by players; i also noticed it and some people mentionned it to me anyways etc
- same for overproduction of early defenders after our minimal defense needs are met. Much stronger early game in most cases or/and prepares better for middle game offense transition instead of having too many useless longbowmen or such if in excess that cripple our economy with unit cost instead of using them. More varied compositions (more spearmen, horse archers etc), generally favouring civ-specific units (except unitai_counter ones like the maya holkan that is not strong or effective enough at offense to overvalue it, so as of now valued normally anyways etc). Not entirely effective for some reason but when it is the most effective difference is scary good (hatshepsut ai having 30+ war chariots at turn 130 instead of 30+ longbows). Our autoplay ai didn't handle it well and collapsed xd but sometimes they do better based on various factors it seems, still rivals played strongly as well it seems but anyways etc.
- many or at least few other changes see log there above anyways etc and screenshots

I may make a new release at some point but i want to implement more changes or/and balance ones.

Stability:
- stable enough, we have one crash happen sometimes at turn 90-100 in autoplay, but it seems to be fixed reloading save file one or a few turns before and disappearing ("temporary crash"), see doc about this kind of crash there anyways etc: https://github.com/wonderingabout/AdvCiv-SAS/blob/tech-rework/README.md#temporary-crashes

Very very strong!! I tried another autoplay, the AI is not joke xd, appended a few samples here for teaser if i may say but anyways etc.

See for details with drive link for more screenshots or such anyways etc: https://github.com/wonderingabout/A...ways-etc-in-cvcityaiai_chooseunit-anyways-etc

Note: as of now only available in development version, would be in next release along with other changes if any, but ai sure is very strong, although i could enhance things more for sure but anyways etc (which i hope to in this case i mean but anyways etc)!

edit: the order of the screenshots is messed up in the attachments it seems (but seems ordered fine in the diaproama view whatever they call it anyways etc) as compared to order in which i uploaded them, read them unmerically (first lowest number to highest number: first few are sometime before last and possibly (didn't check in detail exactly when but around that time anyways etc) one few other previous changes in map 1, then after said changes in map 1, then after changes in a new map 2 for comparison of how it could otherwise go anyways etc)
 

Attachments

  • Civ4ScreenShot0616.JPG
    Civ4ScreenShot0616.JPG
    880.8 KB · Views: 21
  • Civ4ScreenShot0617.JPG
    Civ4ScreenShot0617.JPG
    1.1 MB · Views: 21
  • Civ4ScreenShot0618.JPG
    Civ4ScreenShot0618.JPG
    1.3 MB · Views: 19
  • Civ4ScreenShot0619.JPG
    Civ4ScreenShot0619.JPG
    1.1 MB · Views: 17
  • Civ4ScreenShot0620.JPG
    Civ4ScreenShot0620.JPG
    843.9 KB · Views: 14
  • Civ4ScreenShot0621.JPG
    Civ4ScreenShot0621.JPG
    773.7 KB · Views: 12
  • Civ4ScreenShot0623.JPG
    Civ4ScreenShot0623.JPG
    1.2 MB · Views: 21
  • Civ4ScreenShot0615.JPG
    Civ4ScreenShot0615.JPG
    881.9 KB · Views: 12
  • Civ4ScreenShot0614.JPG
    Civ4ScreenShot0614.JPG
    879.5 KB · Views: 11
  • Civ4ScreenShot0460.JPG
    Civ4ScreenShot0460.JPG
    1 MB · Views: 9
  • Civ4ScreenShot0462.JPG
    Civ4ScreenShot0462.JPG
    1 MB · Views: 8
  • Civ4ScreenShot0588.JPG
    Civ4ScreenShot0588.JPG
    1.1 MB · Views: 7
  • Civ4ScreenShot0591.JPG
    Civ4ScreenShot0591.JPG
    1 MB · Views: 9
  • Civ4ScreenShot0611.JPG
    Civ4ScreenShot0611.JPG
    1 MB · Views: 8
  • Civ4ScreenShot0612.JPG
    Civ4ScreenShot0612.JPG
    1 MB · Views: 8
  • Civ4ScreenShot0613.JPG
    Civ4ScreenShot0613.JPG
    885.8 KB · Views: 21
Last edited:
Updated new stable release from AdvCiv-SAS 4986 to AdvCiv 5030!

Many changes vs 4986 (reframes a bit what is written here but useful for clarity or reference i guess maybe hopefully but anyways etc):

- Much stronger/efficient AI than in AdvCiv-SAS 4986 (full evacuation of doomed cities, razing faraway cities early, fix/enhance happiness buildings priority when needed, emergency peace if in multi-war threat, better valuing of low value bonuses (e.g. pig = 1 health < wheat = 2 health (one from granary)), better / more varied military composition (reduced excess siege in particular, focus more on offense units generally after minimal defense needs are met, anti very cheap early units excess (in particular ancient macemen as very inefficient)) with various settings, added iAIObjective to key strategic bonuses (as of now copper, iron, horse, camel, low value for elephants for war elephants window, aluminium, uranium) with new AI logic on top of existing one in other areas for this setting (that was 0 in base advciv though if i'm not mistaken), now also in settling priorities, working tiles (improve it first), trade it better/smarter (e.g. horse is valuable at medieval era if we have iron, but not at classical if we have elephants, nor at renaissance even if we have iron (new units fallback (cannons, muskets, etc. if any more))
- adjusted timelines at each game speed for a slower/longer middle ages (was too short to really let units shine if i may say anyways etc) and late industrial era. In particular, GAMESPEED_MARATHON reduced from 1250 turns in base advciv to now 1000 turns in advciv-sas.
- fixed tech costs to match era modifiers removal (was using old logic so costs were too high)
- performance optimizations
- balance changes and reworks: new unit combat types to replace UNITCOMBAT_MELEE: UNITCOMBAT_MELEE_POLEARM (spears, pikes, etc.) and UNITCOMBAT_MELEE_SHOCK (axes, swords, maces, etc.). In continuation to the past split of UNITCOMBAT_MOUNTED into UNITCOMBAT_MELEE and UNITCOMBAT_RANGED that allowed pikemen to be strong against knight units but no longer against cuirassiers which was nonsensical, this new UNITCOMBAT_MELEE split allows for example axemen to now be barely stronger than swordsmen vs much stronger before which was too skewed (but they still remain strong against polearm), and many other things. Reworked and buffed spearman units.
- civ-specific units changes: replaced the mongol_keshik with the mongol_khishigten (horse knight based, meshes better with ger timing and historically more accurate) and the english_redcoat with the english_yeoman_archer (crossbowman based, better match with the english empire's defensive profile, nice cover if no bonus early)
- finer hammer cost tuning, now per 1 hammer no longer rounded to closest 5 multiple for the human player like in base advciv: e.g. sworsdsman cost increased to 42 (btw xd if i may say but anyways etc) stays at 42 not 40 (and 43 does not become 45), fairer vs AIs which did not have this and caused cost mismatches even at same handicap if these were to be changed to non 5 multiples, now fixed/enhanced. Also allows finer balance especially for early units (ancient macemen cost 18 not rounded to 20 anymore)
- bug fixes and tweaks
- new GlobalDefines_advciv_sas.xml file with some settings being now tunable in https://github.com/wonderingabout/A...ework/Assets/XML/GlobalDefines_advciv_sas.xml
- UI enhancements: in particular in sevopedia promotions (now shows as buttons = images the list of all units and the list of all buildings that have this promotion as free promotion), and in sevopedia civics (also shows as buttons the list of all leaders that have civic as their favourite civic) and beautified and refactored code
- 48 civs DLL included now
- various other tweaks and fixes

Strongly recommended to upgrade to this new version if you are using 4986 or an old version.

see for full changes: commit history from AdvCiv-SAS 4986 to 5030 viewable at https://github.com/wonderingabout/AdvCiv-SAS/commits/tech-rework/?since=2025-09-06&until=2025-10-03 or at https://github.com/wonderingabout/A...f8...e3ecaf41449b5a4415d3a98ff0c68c0d0ccd7738

Below are sample images showing some of the changes, AI is very strong, and UI very pretty if i may say but anyways etc! (autoplay sample is at monarch on a pangea map if i am not mistaken but anyways etc, AI very strong!!)
 

Attachments

  • 0.730_sevopedia_promotions_sample (3).JPG
    0.730_sevopedia_promotions_sample (3).JPG
    584.4 KB · Views: 19
  • 0.740_sevopedia_civics_sample (1).JPG
    0.740_sevopedia_civics_sample (1).JPG
    565.9 KB · Views: 17
  • Civ4ScreenShot1109.JPG
    Civ4ScreenShot1109.JPG
    874.2 KB · Views: 16
  • Civ4ScreenShot1110.JPG
    Civ4ScreenShot1110.JPG
    798.6 KB · Views: 21
  • Civ4ScreenShot0952.JPG
    Civ4ScreenShot0952.JPG
    1.1 MB · Views: 23
  • Civ4ScreenShot0950.JPG
    Civ4ScreenShot0950.JPG
    1.4 MB · Views: 43
Last edited:
so ,
i looked a bit in your code changes.

looks like you basically rewrote tons of it...
are you working with gemini mostly? which one 2.5?

i took a break from modding before agent ai was introduced...
it must be amazing letting the agent ai find all the unfound issues and less optimized code huh.
you can achive many strong changes.

may i ask,
how do you work with the agent ai - are you using vscode or something with an integration ? or simply giving google gemini some code to analyze and improve?
 
well yes i rewrote more than let on xd, but you can find these in code.

AI helps me a lot, but i do it all manually. While it's great at finding "solutions", it can very easily go astray, and the code it provides could easily make things worse or not solve the issue so i would not implement it.

I found what works best, or at least how i want to do it, is to go with save file issue (i notice behaviour X (example "a settler settles one tile away from coast, but city is in tundra! so it will starve at pop 2, need to make the settler move to coast no matter what!"), and then i would ask the AI, usually chatgpt (i started with 4o which worked great at the time, but it invented quite a lot and quite often, and i was not as experienced so frustration and such, but it is generally very helpful, especially since i don't know that much C++ to be honest :) (but enough to have a general idea of what it wants to do or ask it, then direct it for our needs)), and try to understand its code, implement what is minimally needed, then test it ingame, if the code doesnt solve the issue either tweak it or drop it. (Example recently (here: https://github.com/wonderingabout/AdvCiv-SAS/commit/6be6058aefbb9fe25a81a617e09b100822bdfd14) of promising code i threw away because the bug lead to AI being stronger xd (fixing the bug introduced by my extreme no production fix at end of turn makes AI very tame (few units) (i fixed the no production bug more or less by adding a fallback to produce a unit if no production, but this would bypass my own no excess unit logic sometimes (quite often), but removing it is worse than keeping it ingame (much worse), AI is very strong with it) so i base all my results on testing xd as i find it most reliable, but also on implementing code that makes sense at least to me else i ask chatgpt or other AIs if in doubt. (Also for this specific example i didn't like that we had to hardcode unit classes, it's not modular and redundant and heavy to maintain so one more reason i didn't want to implement it rather than indirect general logic like "the units that cost less than 20 hammer in xml cost" or "the buildings that give at least 1 happiness" which i favour much more when possible and relevant (for worker ai it seemed too tedious and we don't change terrains or features everyday, so much easier to hardcode them in worker logic (although i could externalize the parameters to global defines ideally but anyways etc) anyways etc)

So to answer your question, i don't know how to use agent ai, but i do use vs code. However chatgpt 5 (with plus subscription but anyways etc) allows to copy paste large amounts of code, it's great at finding bugs or enhancing logic, although i don't listen to it xd always and verify whatever i can, but it often makes nice suggestions or finds flaws in logic, i rely on it a lot and it helps ton, but all manual copy paste in the chat thread.

You could copy a 1000 (like short AIFoundValue::evaluate) or 2500 line of code like (void CvCityAI::AI_chooseProduction) easy peazy it seems.

It's also great at finding where to make changes, sometimes or often i would dig for something, like say "scrap" and tell it based on results in global search (targeted to *.cpp, *.h files for more accuracy for example), it would give something like this in vs code:

Spoiler global search sample with vs code of "scrap" in "*.cpp, *.h" files :

C:\Program Files (x86)\Steam\steamapps\common\Sid Meier's Civilization IV Beyond the Sword\Beyond the Sword\Mods\AdvCiv-SAS\CvGameCoreDLL\CvCity.cpp
10089,26: "TXT_KEY_AIR_UNIT_SCRAPPED" : "TXT_KEY_AIR_UNIT_MOVED").GetCString()));

C:\Program Files (x86)\Steam\steamapps\common\Sid Meier's Civilization IV Beyond the Sword\Beyond the Sword\Mods\AdvCiv-SAS\CvGameCoreDLL\CvCityAI.cpp
10742,32: // K-Mod. (cf. conditions for scrapping units in AI_doTurnUnitPost)
11286,94: // <!-- custom: note: all values here are linked to their counterpart/equivalent in the canScrap function e.g. to know which is the max (decisions to scrap or not are not directly symetrical to what we do here to produce them (e.g. don't produce naval units at war on land, but don't scrap exist ones though), but may often be or not, in all cases please refer to each function to see the link between them if i may say but anyways etc -->
11286,153: // <!-- custom: note: all values here are linked to their counterpart/equivalent in the canScrap function e.g. to know which is the max (decisions to scrap or not are not directly symetrical to what we do here to produce them (e.g. don't produce naval units at war on land, but don't scrap exist ones though), but may often be or not, in all cases please refer to each function to see the link between them if i may say but anyways etc -->
11286,287: // <!-- custom: note: all values here are linked to their counterpart/equivalent in the canScrap function e.g. to know which is the max (decisions to scrap or not are not directly symetrical to what we do here to produce them (e.g. don't produce naval units at war on land, but don't scrap exist ones though), but may often be or not, in all cases please refer to each function to see the link between them if i may say but anyways etc -->
11289,121: // <!-- custom: add our pre-checks to help improve the naval dementia of overproducing naval units and pangea or/and scrapping them as well possibly, then being invaded and losing top city while having spent needlessly hammers on 20+ mix of galleons/privateers on pangea, fixing the overproducing part of the issue here by setting sanity gates / pre-checks before we push the final order, and so we can control here all order if i'm not mistaken but anyways etc -->
11816,519: ⟪ 318 characters skipped ⟫are better and it would just bankrupt us or increase unit costs / reduce unit costs efficiency (i.e. maintenance gold per turn for the military units i mean but anyways etc)) anyways etc; note: don't scrap existing ones, they'll die fighting or maybe be upgraded eventually or be useful for some other purpose if hopefully not too numerous but anyways etc, but don't produce anymore if beyond this new cap after the very early game if i am not mistaken in my thinking (i think i am not as this is a good idea i think (but check if accurate or is but anyways etc) but anyways etc) -->
11853,283: // <!-- custom: let's limit certain types of naval units by map type (less on land heavy ones like pangea, more in naval heavy ones like archipelago, anyways etc), to help the known issue as of now 53 of having an AI player have 20+ galleons/privateers, yet producing them +/- scrapping them (dementia/insane like behvaiour if may say but anyways etc.., but not its fault, it just wasn't told better, so hopefully we can help AI have saner unit limits, and we'll ahndle the seemignly naval units scrapping elsewhere as we did in known issue as of now 52 for many units but anyways etc), so for now a few of the combat naval unit AIs (like max iNumCities per AI player seems very sane on pangea, possibly * 2 for naval heavy maps, no need to overproduce beyond that, nor to scrap before that potentially risking crazy loops but anyways etc, we hopefully maybe also save computation by implementing our check here before code is executed but anyways etc) ; code added with the help / thanks to chatgpt 5 as well, check if accurate (and check mine too i mean but anyways etc) anyways etc -->
11853,502: // <!-- custom: let's limit certain types of naval units by map type (less on land heavy ones like pangea, more in naval heavy ones like archipelago, anyways etc), to help the known issue as of now 53 of having an AI player have 20+ galleons/privateers, yet producing them +/- scrapping them (dementia/insane like behvaiour if may say but anyways etc.., but not its fault, it just wasn't told better, so hopefully we can help AI have saner unit limits, and we'll ahndle the seemignly naval units scrapping elsewhere as we did in known issue as of now 52 for many units but anyways etc), so for now a few of the combat naval unit AIs (like max iNumCities per AI player seems very sane on pangea, possibly * 2 for naval heavy maps, no need to overproduce beyond that, nor to scrap before that potentially risking crazy loops but anyways etc, we hopefully maybe also save computation by implementing our check here before code is executed but anyways etc) ; code added with the help / thanks to chatgpt 5 as well, check if accurate (and check mine too i mean but anyways etc) anyways etc -->
11853,779: // <!-- custom: let's limit certain types of naval units by map type (less on land heavy ones like pangea, more in naval heavy ones like archipelago, anyways etc), to help the known issue as of now 53 of having an AI player have 20+ galleons/privateers, yet producing them +/- scrapping them (dementia/insane like behvaiour if may say but anyways etc.., but not its fault, it just wasn't told better, so hopefully we can help AI have saner unit limits, and we'll ahndle the seemignly naval units scrapping elsewhere as we did in known issue as of now 52 for many units but anyways etc), so for now a few of the combat naval unit AIs (like max iNumCities per AI player seems very sane on pangea, possibly * 2 for naval heavy maps, no need to overproduce beyond that, nor to scrap before that potentially risking crazy loops but anyways etc, we hopefully maybe also save computation by implementing our check here before code is executed but anyways etc) ; code added with the help / thanks to chatgpt 5 as well, check if accurate (and check mine too i mean but anyways etc) anyways etc -->
12288,282: // <!-- custom: let's limit certain types of naval units by map type (less on land heavy ones like pangea, more in naval heavy ones like archipelago, anyways etc), to help the known issue as of now 53 of having an AI player have 20+ galleons/privateers, yet producing them +/- scrapping them (dementia/insane like behvaiour if may say but anyways etc.., but not its fault, it just wasn't told better, so hopefully we can help AI have saner unit limits, and we'll ahndle the seemignly naval units scrapping elsewhere as we did in known issue as of now 52 for many units but anyways etc), so for now a few of the combat naval unit AIs (like max iNumCities per AI player seems very sane on pangea, possibly * 2 for naval heavy maps, no need to overproduce beyond that, nor to scrap before that potentially risking crazy loops but anyways etc, we hopefully maybe also save computation by implementing our check here before code is executed but anyways etc) ; code added with the help / thanks to chatgpt 5 as well, check if accurate (and check mine too i mean but anyways etc) anyways etc -->
12288,501: // <!-- custom: let's limit certain types of naval units by map type (less on land heavy ones like pangea, more in naval heavy ones like archipelago, anyways etc), to help the known issue as of now 53 of having an AI player have 20+ galleons/privateers, yet producing them +/- scrapping them (dementia/insane like behvaiour if may say but anyways etc.., but not its fault, it just wasn't told better, so hopefully we can help AI have saner unit limits, and we'll ahndle the seemignly naval units scrapping elsewhere as we did in known issue as of now 52 for many units but anyways etc), so for now a few of the combat naval unit AIs (like max iNumCities per AI player seems very sane on pangea, possibly * 2 for naval heavy maps, no need to overproduce beyond that, nor to scrap before that potentially risking crazy loops but anyways etc, we hopefully maybe also save computation by implementing our check here before code is executed but anyways etc) ; code added with the help / thanks to chatgpt 5 as well, check if accurate (and check mine too i mean but anyways etc) anyways etc -->
12288,778: // <!-- custom: let's limit certain types of naval units by map type (less on land heavy ones like pangea, more in naval heavy ones like archipelago, anyways etc), to help the known issue as of now 53 of having an AI player have 20+ galleons/privateers, yet producing them +/- scrapping them (dementia/insane like behvaiour if may say but anyways etc.., but not its fault, it just wasn't told better, so hopefully we can help AI have saner unit limits, and we'll ahndle the seemignly naval units scrapping elsewhere as we did in known issue as of now 52 for many units but anyways etc), so for now a few of the combat naval unit AIs (like max iNumCities per AI player seems very sane on pangea, possibly * 2 for naval heavy maps, no need to overproduce beyond that, nor to scrap before that potentially risking crazy loops but anyways etc, we hopefully maybe also save computation by implementing our check here before code is executed but anyways etc) ; code added with the help / thanks to chatgpt 5 as well, check if accurate (and check mine too i mean but anyways etc) anyways etc -->
12303,174: // <!-- custom: note: as of now unhandled unitais here mean free production or let AI decide, the more the better: military land units, air units but anyways etc, see canScrap function for the handling of these produced units anyways etc -->

C:\Program Files (x86)\Steam\steamapps\common\Sid Meier's Civilization IV Beyond the Sword\Beyond the Sword\Mods\AdvCiv-SAS\CvGameCoreDLL\CvPlayer.cpp
6728,43: human players selling them lots of tech scraps.)

C:\Program Files (x86)\Steam\steamapps\common\Sid Meier's Civilization IV Beyond the Sword\Beyond the Sword\Mods\AdvCiv-SAS\CvGameCoreDLL\CvPlayerAI.cpp
521,53: int iCostPerMil = AI_unitCostPerMil(); // used for scrap decisions.
647,50: if (gUnitLogLevel > 2) logBBAI(" %S scraps %S, with %d exp, and %d / %d spending.", getCivilizationDescription(0), pLoopUnit->getName(0).GetCString(), iExp, iCostPerMil, AI_maxUnitCostPerMil(pLoopUnit->area(), 100));
648,22: pLoopUnit->scrap();
650,28: what extra work scrap() wants to do for us? */
20057,22: logBBAI(" %S scraps '%S' %S, at (%d, %d), with value %d, due to financial trouble.", getCivilizationDescription(0), szAITypeString.GetCString(), pDisbandUnit->getName(0).GetCString(), pDisbandUnit->getX(), pDisbandUnit->getY(), unit_values[iDisbandCount].first);
20060,19: pDisbandUnit->scrap();
28976,73: // <!-- custom: update issue is now solved by patching globally the canScrap, and below approach didn't solve anything, so i'll comment it out, enable it if need or want and see for related info known issue as of now 52 anyways etc -->
28977,55: // // B) Patch AI_disbandValue to strongly de-prefer scrapping new combat units & live garrisons
28979,14: // // Don’t scrap fresh combat units (prevents “we built one, ended with fewer”).
28984,14: // // Don’t scrap a unit actively defending one of our city tiles.

C:\Program Files (x86)\Steam\steamapps\common\Sid Meier's Civilization IV Beyond the Sword\Beyond the Sword\Mods\AdvCiv-SAS\CvGameCoreDLL\CvTeam.cpp
3673,9: u->scrap();

C:\Program Files (x86)\Steam\steamapps\common\Sid Meier's Civilization IV Beyond the Sword\Beyond the Sword\Mods\AdvCiv-SAS\CvGameCoreDLL\CvUnit.cpp
622,20: pCapturedUnit->scrap();*/
2181,10: if (canScrap())
2276,4: scrap();
3246,20: // <!-- custom: we scrap way too many military units in particular, as i have noticed it in the early game (+/- turn 40-50 but anyways etc, could and most likely happens in other circumstances but didn't check check to be sure and if i'm not mistaken anyways etc), so after we produce a unit we end up with 1 less, so this would mean we scrapped 2. Especially crippling early when barbarians are stronger, our military weak, and rivals dangerous as well potentially. Try to reduce scrapping with this tentative code change but anyways etc, while also not overdoing it in case it collapses our economy, here or/and in other places, see known issue as of now 52 for details anyways etc; also code provided by chatgpt 5 thansk to my prompts and code samples i fed it and or such, check if accurate, anyways etc -->
3246,338: // <!-- custom: we scrap way too many military units in particular, as i have noticed it in the early game (+/- turn 40-50 but anyways etc, could and most likely happens in other circumstances but didn't check check to be sure and if i'm not mistaken anyways etc), so after we produce a unit we end up with 1 less, so this would mean we scrapped 2. Especially crippling early when barbarians are stronger, our military weak, and rivals dangerous as well potentially. Try to reduce scrapping with this tentative code change but anyways etc, while also not overdoing it in case it collapses our economy, here or/and in other places, see known issue as of now 52 for details anyways etc; also code provided by chatgpt 5 thansk to my prompts and code samples i fed it and or such, check if accurate, anyways etc -->
3246,482: // <!-- custom: we scrap way too many military units in particular, as i have noticed it in the early game (+/- turn 40-50 but anyways etc, could and most likely happens in other circumstances but didn't check check to be sure and if i'm not mistaken anyways etc), so after we produce a unit we end up with 1 less, so this would mean we scrapped 2. Especially crippling early when barbarians are stronger, our military weak, and rivals dangerous as well potentially. Try to reduce scrapping with this tentative code change but anyways etc, while also not overdoing it in case it collapses our economy, here or/and in other places, see known issue as of now 52 for details anyways etc; also code provided by chatgpt 5 thansk to my prompts and code samples i fed it and or such, check if accurate, anyways etc -->
3247,96: // <!-- custom: the changes in CvPlayerAI::AI_doMilitary did not change the seemingly cyclical scrapping behaviour of new ancient macemen many turns on a row, so as advised by chatgpt 5 (genius idea it got, it may not seem to clean but great way to solve it xd thanks! But anyways etc), implementing our logic here as well, check if accurate anyways etc -->
3248,45: // Why here? Anything that eventually calls scrap() must pass canScrap() first. With this guard, your land combat units won’t be culled every other turn in the early game or under threat, matching the pattern you observed (6→5→6→5).
3248,66: // Why here? Anything that eventually calls scrap() must pass canScrap() first. With this guard, your land combat units won’t be culled every other turn in the early game or under threat, matching the pattern you observed (6→5→6→5).
3249,57: // <!-- custom: update!!! Tremendously fixed!!! No more scrapping and painful losing of these ancient macemen, will reduce handicap now to accomodate these and make sure we don't run abnkrupt at leats early, else i don't care too much or as much, and give AI best chances anyways etc, see known issue as of now 52 for details anyways etc; in short we only aded some more prechecks here as we usually do, in an attempt to help improve AI efficiency or/and correct or help improve significant AI flaws, so hopefully AI is now stronger as such and we have to adjust some things to match these but anyways etc, see known issue mentionned here in these code comments for details but anyways etc, and we otherwise kept function the same anyways etc -->
3250,17: bool CvUnit::canScrap() const
3257,97: // <!-- custom: update: the danger and not before turn 100 and other conditions anyways etc no scrapping gating here worked extremely great and solved the scrapping issue, see known issue as of now 52 for details anyways etc; now doing a less going overboard xd approach if i may say but anyways etc, we can just disable scrapping entirely and not waste computation, or in other cases tune it to be selectively disabled or such anyways etc, commenting-out this old code we added at first for that end since we don't need to check these now so kept as is commented-out in case if need (and note: untested or barely tested once in this case i mean but anyways etc), may remove it if uneeded, anyways etc -->
3257,157: // <!-- custom: update: the danger and not before turn 100 and other conditions anyways etc no scrapping gating here worked extremely great and solved the scrapping issue, see known issue as of now 52 for details anyways etc; now doing a less going overboard xd approach if i may say but anyways etc, we can just disable scrapping entirely and not waste computation, or in other cases tune it to be selectively disabled or such anyways etc, commenting-out this old code we added at first for that end since we don't need to check these now so kept as is commented-out in case if need (and note: untested or barely tested once in this case i mean but anyways etc), may remove it if uneeded, anyways etc -->
3257,323: // <!-- custom: update: the danger and not before turn 100 and other conditions anyways etc no scrapping gating here worked extremely great and solved the scrapping issue, see known issue as of now 52 for details anyways etc; now doing a less going overboard xd approach if i may say but anyways etc, we can just disable scrapping entirely and not waste computation, or in other cases tune it to be selectively disabled or such anyways etc, commenting-out this old code we added at first for that end since we don't need to check these now so kept as is commented-out in case if need (and note: untested or barely tested once in this case i mean but anyways etc), may remove it if uneeded, anyways etc -->
3258,21: // // only allow scrapping if actually over budget or burning gold
3268,324: // <!-- custom: no disband at all regardless, as well, for land military units (found by our preferred/corresponding unitais as as of now below but anyways etc), they are likely to be valuable one way or another at some point, unlike naval units or perhaps scouts or workers to a lesser extent, but what i mean is do not scrap them at all, hopefully fixes low midgame AI output or enhances it (handicap and such will be adjusted to match these changes as well but see for details or/and updated info known issue as of now 52 or other related docs anyways etc)
3297,46: // <!-- custom: as for naval units, do not scrap them at all, we had the workboat infinite loop issue in known issue as of now 23 if i'm not mistaken that we fixed, but then in known issue as of now 53 i noticed a privateer loop and AI dying because of it. Since we now handle properly max naval units among other units being produced, we don't fear overproducing them too much, at least not too hard, but we i.e. i xd but anyways etc fear invisible scrapping. There should almost never be good cases where scrapping is worth, and these should be handled as exceptions rather than the main rule. Just in known issue as of now 52, removing scrapping greatly improves AI military efficiency and performance, and it didn't go bankrupt at all (they can't produce that much units anyway, allowing to reduce handicap so they produce less units so they are less likely to be bankrupt and so they also nicely have a bit of buff and buffer (no pun xd but anyways etc). Really, i feel or it seems to me like scrapping should be handled as an exception not as a "i don't know what to do with this weird unit let's just scrap it xd". "No! Don't scrap it xd, figure out what to do with it, most often the risk of loop or such far outweigh having 1 or 2 extra units anyway i think but anyways etc), if fearing financial trouble or such, please implement it in your code, as for me as of now i consider/assume assume AIs develop well and build these formulas based on iNumCities or such for scaling but anyways etc, the benefits seem to far outweigh the risks/costs but anyways etc, and please read if i may say but anyways etc known isue as of now 53 for details anyways etc ; also, since we are only adding pre checks and not changing the logic otherwise, should be fine but anyways etc -->
3297,453: // <!-- custom: as for naval units, do not scrap them at all, we had the workboat infinite loop issue in known issue as of now 23 if i'm not mistaken that we fixed, but then in known issue as of now 53 i noticed a privateer loop and AI dying because of it. Since we now handle properly max naval units among other units being produced, we don't fear overproducing them too much, at least not too hard, but we i.e. i xd but anyways etc fear invisible scrapping. There should almost never be good cases where scrapping is worth, and these should be handled as exceptions rather than the main rule. Just in known issue as of now 52, removing scrapping greatly improves AI military efficiency and performance, and it didn't go bankrupt at all (they can't produce that much units anyway, allowing to reduce handicap so they produce less units so they are less likely to be bankrupt and so they also nicely have a bit of buff and buffer (no pun xd but anyways etc). Really, i feel or it seems to me like scrapping should be handled as an exception not as a "i don't know what to do with this weird unit let's just scrap it xd". "No! Don't scrap it xd, figure out what to do with it, most often the risk of loop or such far outweigh having 1 or 2 extra units anyway i think but anyways etc), if fearing financial trouble or such, please implement it in your code, as for me as of now i consider/assume assume AIs develop well and build these formulas based on iNumCities or such for scaling but anyways etc, the benefits seem to far outweigh the risks/costs but anyways etc, and please read if i may say but anyways etc known isue as of now 53 for details anyways etc ; also, since we are only adding pre checks and not changing the logic otherwise, should be fine but anyways etc -->
3297,510: // <!-- custom: as for naval units, do not scrap them at all, we had the workboat infinite loop issue in known issue as of now 23 if i'm not mistaken that we fixed, but then in known issue as of now 53 i noticed a privateer loop and AI dying because of it. Since we now handle properly max naval units among other units being produced, we don't fear overproducing them too much, at least not too hard, but we i.e. i xd but anyways etc fear invisible scrapping. There should almost never be good cases where scrapping is worth, and these should be handled as exceptions rather than the main rule. Just in known issue as of now 52, removing scrapping greatly improves AI military efficiency and performance, and it didn't go bankrupt at all (they can't produce that much units anyway, allowing to reduce handicap so they produce less units so they are less likely to be bankrupt and so they also nicely have a bit of buff and buffer (no pun xd but anyways etc). Really, i feel or it seems to me like scrapping should be handled as an exception not as a "i don't know what to do with this weird unit let's just scrap it xd". "No! Don't scrap it xd, figure out what to do with it, most often the risk of loop or such far outweigh having 1 or 2 extra units anyway i think but anyways etc), if fearing financial trouble or such, please implement it in your code, as for me as of now i consider/assume assume AIs develop well and build these formulas based on iNumCities or such for scaling but anyways etc, the benefits seem to far outweigh the risks/costs but anyways etc, and please read if i may say but anyways etc known isue as of now 53 for details anyways etc ; also, since we are only adding pre checks and not changing the logic otherwise, should be fine but anyways etc -->
3297,642: // <!-- custom: as for naval units, do not scrap them at all, we had the workboat infinite loop issue in known issue as of now 23 if i'm not mistaken that we fixed, but then in known issue as of now 53 i noticed a privateer loop and AI dying because of it. Since we now handle properly max naval units among other units being produced, we don't fear overproducing them too much, at least not too hard, but we i.e. i xd but anyways etc fear invisible scrapping. There should almost never be good cases where scrapping is worth, and these should be handled as exceptions rather than the main rule. Just in known issue as of now 52, removing scrapping greatly improves AI military efficiency and performance, and it didn't go bankrupt at all (they can't produce that much units anyway, allowing to reduce handicap so they produce less units so they are less likely to be bankrupt and so they also nicely have a bit of buff and buffer (no pun xd but anyways etc). Really, i feel or it seems to me like scrapping should be handled as an exception not as a "i don't know what to do with this weird unit let's just scrap it xd". "No! Don't scrap it xd, figure out what to do with it, most often the risk of loop or such far outweigh having 1 or 2 extra units anyway i think but anyways etc), if fearing financial trouble or such, please implement it in your code, as for me as of now i consider/assume assume AIs develop well and build these formulas based on iNumCities or such for scaling but anyways etc, the benefits seem to far outweigh the risks/costs but anyways etc, and please read if i may say but anyways etc known isue as of now 53 for details anyways etc ; also, since we are only adding pre checks and not changing the logic otherwise, should be fine but anyways etc -->
3297,1001: // <!-- custom: as for naval units, do not scrap them at all, we had the workboat infinite loop issue in known issue as of now 23 if i'm not mistaken that we fixed, but then in known issue as of now 53 i noticed a privateer loop and AI dying because of it. Since we now handle properly max naval units among other units being produced, we don't fear overproducing them too much, at least not too hard, but we i.e. i xd but anyways etc fear invisible scrapping. There should almost never be good cases where scrapping is worth, and these should be handled as exceptions rather than the main rule. Just in known issue as of now 52, removing scrapping greatly improves AI military efficiency and performance, and it didn't go bankrupt at all (they can't produce that much units anyway, allowing to reduce handicap so they produce less units so they are less likely to be bankrupt and so they also nicely have a bit of buff and buffer (no pun xd but anyways etc). Really, i feel or it seems to me like scrapping should be handled as an exception not as a "i don't know what to do with this weird unit let's just scrap it xd". "No! Don't scrap it xd, figure out what to do with it, most often the risk of loop or such far outweigh having 1 or 2 extra units anyway i think but anyways etc), if fearing financial trouble or such, please implement it in your code, as for me as of now i consider/assume assume AIs develop well and build these formulas based on iNumCities or such for scaling but anyways etc, the benefits seem to far outweigh the risks/costs but anyways etc, and please read if i may say but anyways etc known isue as of now 53 for details anyways etc ; also, since we are only adding pre checks and not changing the logic otherwise, should be fine but anyways etc -->
3297,1111: // <!-- custom: as for naval units, do not scrap them at all, we had the workboat infinite loop issue in known issue as of now 23 if i'm not mistaken that we fixed, but then in known issue as of now 53 i noticed a privateer loop and AI dying because of it. Since we now handle properly max naval units among other units being produced, we don't fear overproducing them too much, at least not too hard, but we i.e. i xd but anyways etc fear invisible scrapping. There should almost never be good cases where scrapping is worth, and these should be handled as exceptions rather than the main rule. Just in known issue as of now 52, removing scrapping greatly improves AI military efficiency and performance, and it didn't go bankrupt at all (they can't produce that much units anyway, allowing to reduce handicap so they produce less units so they are less likely to be bankrupt and so they also nicely have a bit of buff and buffer (no pun xd but anyways etc). Really, i feel or it seems to me like scrapping should be handled as an exception not as a "i don't know what to do with this weird unit let's just scrap it xd". "No! Don't scrap it xd, figure out what to do with it, most often the risk of loop or such far outweigh having 1 or 2 extra units anyway i think but anyways etc), if fearing financial trouble or such, please implement it in your code, as for me as of now i consider/assume assume AIs develop well and build these formulas based on iNumCities or such for scaling but anyways etc, the benefits seem to far outweigh the risks/costs but anyways etc, and please read if i may say but anyways etc known isue as of now 53 for details anyways etc ; also, since we are only adding pre checks and not changing the logic otherwise, should be fine but anyways etc -->
3297,1136: // <!-- custom: as for naval units, do not scrap them at all, we had the workboat infinite loop issue in known issue as of now 23 if i'm not mistaken that we fixed, but then in known issue as of now 53 i noticed a privateer loop and AI dying because of it. Since we now handle properly max naval units among other units being produced, we don't fear overproducing them too much, at least not too hard, but we i.e. i xd but anyways etc fear invisible scrapping. There should almost never be good cases where scrapping is worth, and these should be handled as exceptions rather than the main rule. Just in known issue as of now 52, removing scrapping greatly improves AI military efficiency and performance, and it didn't go bankrupt at all (they can't produce that much units anyway, allowing to reduce handicap so they produce less units so they are less likely to be bankrupt and so they also nicely have a bit of buff and buffer (no pun xd but anyways etc). Really, i feel or it seems to me like scrapping should be handled as an exception not as a "i don't know what to do with this weird unit let's just scrap it xd". "No! Don't scrap it xd, figure out what to do with it, most often the risk of loop or such far outweigh having 1 or 2 extra units anyway i think but anyways etc), if fearing financial trouble or such, please implement it in your code, as for me as of now i consider/assume assume AIs develop well and build these formulas based on iNumCities or such for scaling but anyways etc, the benefits seem to far outweigh the risks/costs but anyways etc, and please read if i may say but anyways etc known isue as of now 53 for details anyways etc ; also, since we are only adding pre checks and not changing the logic otherwise, should be fine but anyways etc -->
3304,102: // <!-- custom: note: all values here if any are linked to their counterpart/equivalent in the canScrap function e.g. to know which is the max (decisions to scrap or not are not directly symetrical to what we do here to produce them (e.g. don't produce naval units at war on land, but don't scrap exist ones though), but may often be or not, in all cases please refer to each function to see the link between them if i may say but anyways etc -->
3304,161: // <!-- custom: note: all values here if any are linked to their counterpart/equivalent in the canScrap function e.g. to know which is the max (decisions to scrap or not are not directly symetrical to what we do here to produce them (e.g. don't produce naval units at war on land, but don't scrap exist ones though), but may often be or not, in all cases please refer to each function to see the link between them if i may say but anyways etc -->
3304,295: // <!-- custom: note: all values here if any are linked to their counterpart/equivalent in the canScrap function e.g. to know which is the max (decisions to scrap or not are not directly symetrical to what we do here to produce them (e.g. don't produce naval units at war on land, but don't scrap exist ones though), but may often be or not, in all cases please refer to each function to see the link between them if i may say but anyways etc -->
3357,142: // <!-- custom: since we now already handle in CvCityAI::AI_chooseUnit when to produce them and how much, no need to worry too much about scrapping enough units. However, as shown in known issue as of now 53 but anyways etc, it seems scrapping still happens for privateers or such, although i am not sure and AI may have just been overproducing and i didn't check too much, still generally scrapping benefits should now far outweigh costs/risks, which include infinite loop of missing a unit we just created and/or such, and as happened in known issue as of now 23 as well with workboats in the past. It seems much simpler to disable scrapping altogether for most if not all, and see what happens and if we go bankrupt or not. By meeting our quotas sooner, we can then move on to other units or buildings or anything much more efficiently/effectively than scrap reproduce again, and 1-2 lone units are not a big problem vs the global risk of scrapping messing up, so disabling it at least for these units but anyways etc; chatgpt 5 also likes this change if i may say at least it said so so the change seems fine to it at least if not more but anyways etc -->
3357,238: // <!-- custom: since we now already handle in CvCityAI::AI_chooseUnit when to produce them and how much, no need to worry too much about scrapping enough units. However, as shown in known issue as of now 53 but anyways etc, it seems scrapping still happens for privateers or such, although i am not sure and AI may have just been overproducing and i didn't check too much, still generally scrapping benefits should now far outweigh costs/risks, which include infinite loop of missing a unit we just created and/or such, and as happened in known issue as of now 23 as well with workboats in the past. It seems much simpler to disable scrapping altogether for most if not all, and see what happens and if we go bankrupt or not. By meeting our quotas sooner, we can then move on to other units or buildings or anything much more efficiently/effectively than scrap reproduce again, and 1-2 lone units are not a big problem vs the global risk of scrapping messing up, so disabling it at least for these units but anyways etc; chatgpt 5 also likes this change if i may say at least it said so so the change seems fine to it at least if not more but anyways etc -->
3357,394: // <!-- custom: since we now already handle in CvCityAI::AI_chooseUnit when to produce them and how much, no need to worry too much about scrapping enough units. However, as shown in known issue as of now 53 but anyways etc, it seems scrapping still happens for privateers or such, although i am not sure and AI may have just been overproducing and i didn't check too much, still generally scrapping benefits should now far outweigh costs/risks, which include infinite loop of missing a unit we just created and/or such, and as happened in known issue as of now 23 as well with workboats in the past. It seems much simpler to disable scrapping altogether for most if not all, and see what happens and if we go bankrupt or not. By meeting our quotas sooner, we can then move on to other units or buildings or anything much more efficiently/effectively than scrap reproduce again, and 1-2 lone units are not a big problem vs the global risk of scrapping messing up, so disabling it at least for these units but anyways etc; chatgpt 5 also likes this change if i may say at least it said so so the change seems fine to it at least if not more but anyways etc -->
3357,638: // <!-- custom: since we now already handle in CvCityAI::AI_chooseUnit when to produce them and how much, no need to worry too much about scrapping enough units. However, as shown in known issue as of now 53 but anyways etc, it seems scrapping still happens for privateers or such, although i am not sure and AI may have just been overproducing and i didn't check too much, still generally scrapping benefits should now far outweigh costs/risks, which include infinite loop of missing a unit we just created and/or such, and as happened in known issue as of now 23 as well with workboats in the past. It seems much simpler to disable scrapping altogether for most if not all, and see what happens and if we go bankrupt or not. By meeting our quotas sooner, we can then move on to other units or buildings or anything much more efficiently/effectively than scrap reproduce again, and 1-2 lone units are not a big problem vs the global risk of scrapping messing up, so disabling it at least for these units but anyways etc; chatgpt 5 also likes this change if i may say at least it said so so the change seems fine to it at least if not more but anyways etc -->
3357,860: // <!-- custom: since we now already handle in CvCityAI::AI_chooseUnit when to produce them and how much, no need to worry too much about scrapping enough units. However, as shown in known issue as of now 53 but anyways etc, it seems scrapping still happens for privateers or such, although i am not sure and AI may have just been overproducing and i didn't check too much, still generally scrapping benefits should now far outweigh costs/risks, which include infinite loop of missing a unit we just created and/or such, and as happened in known issue as of now 23 as well with workboats in the past. It seems much simpler to disable scrapping altogether for most if not all, and see what happens and if we go bankrupt or not. By meeting our quotas sooner, we can then move on to other units or buildings or anything much more efficiently/effectively than scrap reproduce again, and 1-2 lone units are not a big problem vs the global risk of scrapping messing up, so disabling it at least for these units but anyways etc; chatgpt 5 also likes this change if i may say at least it said so so the change seems fine to it at least if not more but anyways etc -->
3357,946: // <!-- custom: since we now already handle in CvCityAI::AI_chooseUnit when to produce them and how much, no need to worry too much about scrapping enough units. However, as shown in known issue as of now 53 but anyways etc, it seems scrapping still happens for privateers or such, although i am not sure and AI may have just been overproducing and i didn't check too much, still generally scrapping benefits should now far outweigh costs/risks, which include infinite loop of missing a unit we just created and/or such, and as happened in known issue as of now 23 as well with workboats in the past. It seems much simpler to disable scrapping altogether for most if not all, and see what happens and if we go bankrupt or not. By meeting our quotas sooner, we can then move on to other units or buildings or anything much more efficiently/effectively than scrap reproduce again, and 1-2 lone units are not a big problem vs the global risk of scrapping messing up, so disabling it at least for these units but anyways etc; chatgpt 5 also likes this change if i may say at least it said so so the change seems fine to it at least if not more but anyways etc -->
3358,25: // asymmetric: don’t scrap existing boats
3364,296: // <!-- custom: as for settlers, see what happens but don't risk a loop of produce destroy again and again, very costly on city growth. Some code comment mentionned settlers confuse AIs; possibly, but we'd need to test to be sure, there is a risk AI overproduces them in the middle game then scrap and repeat. I didn't see it so far although i didn't see too much, but better not risk, disable scrapping and keep 1 lone extra settler and be done, and see what happens ingame anyways etc if needs adjustment or not (not sure i'd always be here ot make them hehe but i hope the comment helps raise awareness/info about this idea/concern i has if i may say but anyways etc) -->
3364,398: // <!-- custom: as for settlers, see what happens but don't risk a loop of produce destroy again and again, very costly on city growth. Some code comment mentionned settlers confuse AIs; possibly, but we'd need to test to be sure, there is a risk AI overproduces them in the middle game then scrap and repeat. I didn't see it so far although i didn't see too much, but better not risk, disable scrapping and keep 1 lone extra settler and be done, and see what happens ingame anyways etc if needs adjustment or not (not sure i'd always be here ot make them hehe but i hope the comment helps raise awareness/info about this idea/concern i has if i may say but anyways etc) -->
3388,37: // <!-- custom: similarly, avoid scrapping for these, prefer having a few extra than risking infinite loops of produce scrap, or other issues we may not be aware of if i am not in my assessment in this case i mean but anyways etc ; also if we happen to have a few extras for some reason, (hut, unit gifted, etc), do not mind it, assume it is not excessive and don't complexify logic for a few extra units that ultimately won't change hopefully game outcome but anyways etc (note: we may want though to add a preventive patch against gifting abuse if i may say but anyways etc, say if we are above limit, scrap any gifted unit to us, but may be a bit tedious or/and i don't know how, we'd need to scrap the unit received if worse than ours else one of ours if ours are worse etc, ideally would be very nice, but maybe leave it as such if not overboard may be fine and not worth the effort if i may say, although again would be very nice, but hopefully this note/reminder helps if someone other than me (or possibly me but less likely i'd do it again but who knows but i may very well not do it though, may or not not guaranteed, anyways etc) gets the idea from this or something but anyways etc) -->
3388,123: // <!-- custom: similarly, avoid scrapping for these, prefer having a few extra than risking infinite loops of produce scrap, or other issues we may not be aware of if i am not in my assessment in this case i mean but anyways etc ; also if we happen to have a few extras for some reason, (hut, unit gifted, etc), do not mind it, assume it is not excessive and don't complexify logic for a few extra units that ultimately won't change hopefully game outcome but anyways etc (note: we may want though to add a preventive patch against gifting abuse if i may say but anyways etc, say if we are above limit, scrap any gifted unit to us, but may be a bit tedious or/and i don't know how, we'd need to scrap the unit received if worse than ours else one of ours if ours are worse etc, ideally would be very nice, but maybe leave it as such if not overboard may be fine and not worth the effort if i may say, although again would be very nice, but hopefully this note/reminder helps if someone other than me (or possibly me but less likely i'd do it again but who knows but i may very well not do it though, may or not not guaranteed, anyways etc) gets the idea from this or something but anyways etc) -->
3388,608: // <!-- custom: similarly, avoid scrapping for these, prefer having a few extra than risking infinite loops of produce scrap, or other issues we may not be aware of if i am not in my assessment in this case i mean but anyways etc ; also if we happen to have a few extras for some reason, (hut, unit gifted, etc), do not mind it, assume it is not excessive and don't complexify logic for a few extra units that ultimately won't change hopefully game outcome but anyways etc (note: we may want though to add a preventive patch against gifting abuse if i may say but anyways etc, say if we are above limit, scrap any gifted unit to us, but may be a bit tedious or/and i don't know how, we'd need to scrap the unit received if worse than ours else one of ours if ours are worse etc, ideally would be very nice, but maybe leave it as such if not overboard may be fine and not worth the effort if i may say, although again would be very nice, but hopefully this note/reminder helps if someone other than me (or possibly me but less likely i'd do it again but who knows but i may very well not do it though, may or not not guaranteed, anyways etc) gets the idea from this or something but anyways etc) -->
3388,700: // <!-- custom: similarly, avoid scrapping for these, prefer having a few extra than risking infinite loops of produce scrap, or other issues we may not be aware of if i am not in my assessment in this case i mean but anyways etc ; also if we happen to have a few extras for some reason, (hut, unit gifted, etc), do not mind it, assume it is not excessive and don't complexify logic for a few extra units that ultimately won't change hopefully game outcome but anyways etc (note: we may want though to add a preventive patch against gifting abuse if i may say but anyways etc, say if we are above limit, scrap any gifted unit to us, but may be a bit tedious or/and i don't know how, we'd need to scrap the unit received if worse than ours else one of ours if ours are worse etc, ideally would be very nice, but maybe leave it as such if not overboard may be fine and not worth the effort if i may say, although again would be very nice, but hopefully this note/reminder helps if someone other than me (or possibly me but less likely i'd do it again but who knows but i may very well not do it though, may or not not guaranteed, anyways etc) gets the idea from this or something but anyways etc) -->
3420,27: // <!-- custom: don't scrap before renaissance anyways etc -->
3439,28: // <!-- custom: don't scrap existing unit just because we won't produce them (e.g. at war with some other conditions as of now but anyways etc), however track our max in all circumstances and scrap excess as game goes on but anyways etc -->
3439,198: // <!-- custom: don't scrap existing unit just because we won't produce them (e.g. at war with some other conditions as of now but anyways etc), however track our max in all circumstances and scrap excess as game goes on but anyways etc -->
3443,53: // <!-- custom: inferior or equal, as we don't scrap if just at max as nicely noted by chatgpt 5 thanks anyways etc (and despite it being superior or equal in the chooseUnit function hehe if i understood it correctly but anyways etc) -->
3448,80: // <!-- custom: else i.e. if we have too much units, go with the code and scrap if all goes as intended later before final order but anyways etc -->
3461,32: // <!-- custom: then do not scrap any unit at all before turn 150 (at normal game speed), the surplus is likely to be useful, if we go to war or get invaded, then numbers would dim at that time anyways etc -->
3481,63: // // <!-- custom: we already return false and never ever scrap land military units so no need to add them here inefficiently and most importantly unneededly if i may say but anyways etc -->
3502,24: // // We *disallow scrapping* during any of these conditions.
3520,26: // <!-- custom: do not scrap anything carrying units, nice idea by chatgpt 5 i didn't even ask this but just some ideas and it found this thanks. Also nice thing is but anyways etc this is compatible i think if i'm not mistaken but anyways etc with mod mods, if some weird weird xd but anyways etc mod makes swordsmen carry cargo, then don't delete the swordsman (it has ants or ant soldiers xd (not in our mod but maybe but anyways etc), so i find this sanity check very nice if it doesn't break anything, may uncover or/and solve unknown issues too maybe hopefully or prevent some maybe who knows so i like this very much if i may say but anyways etc thanks anyways etc -->
3521,12: // Never scrap anything carrying cargo
3529,40: // <!-- custom: sanity check: do not scrap great persons (hopefully doesn't happen but who knows, don't kill the great prophet or general or scientist or such anyways etc) -->
3544,40: // <!-- custom: sanity check, do not scrap ICBM (just in case but anyways etc), hopefully doesn't cause issues and helps (maybe solves unknown ones but in all cases anyways etc) but anyways etc -->
3562,14: void CvUnit::scrap()
3564,10: if (!canScrap())

C:\Program Files (x86)\Steam\steamapps\common\Sid Meier's Civilization IV Beyond the Sword\Beyond the Sword\Mods\AdvCiv-SAS\CvGameCoreDLL\CvUnit.h
106,10: bool canScrap() const; // Exposed to Python
107,7: void scrap();

C:\Program Files (x86)\Steam\steamapps\common\Sid Meier's Civilization IV Beyond the Sword\Beyond the Sword\Mods\AdvCiv-SAS\CvGameCoreDLL\CvUnitAI.cpp
2624,64: //FErrorMsg("advc.test: Just to see how frequently the AI scraps settlers"); // hardly ever
2625,6: scrap(); //may seem wasteful, but settlers confuse the AI.
2934,40: if (plot() != NULL) // May have been scrapped
3256,5: scrap(); // Don't let it stand around indefinitely
3307,52: scaled rLoadProb = 0; // advc.113: Needed for the scrap decision
3349,39: rLoadProb = 0; // advc.113: OK to scrap
3360,34: /* <advc.113> Want to base the scrap decision on the working city. Try retreating
3361,10: before scrapping if there is none. */
3378,30: not at all a reason to scrap. But having way too many
3394,68: // advc.113: Add 1 b/c e.g. 2 have, 1 needed shouldn't lead to scrapping
3402,15: // Never scrap if safe / new / still useful
3407,20: // Also avoid scrapping when we don't exceed need:
3415,10: /* Scrap eventually b/c the worker could be stuck in this area,
3417,14: scaled rScrapProb(iTotalHave, std::max(1, iTotalThresh));
3418,7: rScrapProb -= 1;
3419,7: rScrapProb *= rScrapProb;
3419,21: rScrapProb *= rScrapProb;
3420,15: // Don't scrap if waiting to load
3421,7: rScrapProb *= scaled::max(0, 1 - 3 * rLoadProb);
3422,11: if (rScrapProb > 0) // to save time
3425,8: rScrapProb *= per100(100 - std::min(iFinancialTroubleMargin, 85));
3427,27: if (SyncRandSuccess(rScrapProb))
3429,7: scrap();
6263,6: scrap();
7412,105: // <!-- custom: update: actually, as discussed with chatgpt 5, i think it's really maybe better to not scrap, we waste hammers doing so, but instead telling the AI not to produce these workboats if it judges it has enough but anyways etc -->
7413,265: // <!-- custom: it seems the needed vs existing workboats (sea workers but anyways etc) logic is (seemingly but looks fine although i didn't check but anyways etc) handled fine already in CvCityAI::AI_chooseProduction so no change needed there, don't worry about scrapping, and so just let AIs produce the unit as they want i mean but anyways etc, and then when produced but anyways etc, they would assess if they want one again, don't scrap a yet to be produced unit that tries to be produced again next turn endlessly or almost (few dozen turns oftentimes or such), if i understood enough of this bug correctly anyways etc -->
7413,438: // <!-- custom: it seems the needed vs existing workboats (sea workers but anyways etc) logic is (seemingly but looks fine although i didn't check but anyways etc) handled fine already in CvCityAI::AI_chooseProduction so no change needed there, don't worry about scrapping, and so just let AIs produce the unit as they want i mean but anyways etc, and then when produced but anyways etc, they would assess if they want one again, don't scrap a yet to be produced unit that tries to be produced again next turn endlessly or almost (few dozen turns oftentimes or such), if i understood enough of this bug correctly anyways etc -->
7425,9: // scrap();
7431,8: // scrap();
7515,9: bool bScrap = true;
7524,6: bScrap = false;
7528,8: if (bScrap)
7530,4: scrap();
8139,5: scrap();
8140,46: return; // advc.001: Always return after scrap
8268,38: // (advc.017b: Moved the transform/ scrap block down; try nearby exploration first.)
8310,55: // Moved the obsoletion test; now only required for scrapping
8369,5: scrap();
8395,4: scrap();
9278,26: // upgrade to galleons. Scrap galleys, switch unit AI for stuck Carracks.
9295,7: scrap();
20531,12: scaled rScrapOdds = per100(GC.getDefineINT(CvGlobals::
20533,28: // Be more reluctant to scrap expensive units
20534,5: rScrapOdds *= 50; // production cost baseline
20535,5: rScrapOdds /= kOwner.getProductionNeeded(getUnitType()) /
20537,25: if (SyncRandSuccess(rScrapOdds))
20539,5: scrap();

C:\Program Files (x86)\Steam\steamapps\common\Sid Meier's Civilization IV Beyond the Sword\Beyond the Sword\Mods\AdvCiv-SAS\CvGameCoreDLL\CyUnit.cpp
117,17: bool CyUnit::canScrap()
119,31: return m_pUnit ? m_pUnit->canScrap() : false;

C:\Program Files (x86)\Steam\steamapps\common\Sid Meier's Civilization IV Beyond the Sword\Beyond the Sword\Mods\AdvCiv-SAS\CvGameCoreDLL\CyUnit.h
49,10: bool canScrap();

C:\Program Files (x86)\Steam\steamapps\common\Sid Meier's Civilization IV Beyond the Sword\Beyond the Sword\Mods\AdvCiv-SAS\CvGameCoreDLL\CyUnitInterface1.cpp
38,12: .def("canScrap", &CyUnit::canScrap, "bool ()")
38,32: .def("canScrap", &CyUnit::canScrap, "bool ()")

C:\Program Files (x86)\Steam\steamapps\common\Sid Meier's Civilization IV Beyond the Sword\Beyond the Sword\Mods\AdvCiv-SAS\CvGameCoreDLL\WarUtilityAspect.cpp
4467,16: NB: The AI scraps Settlers eventually if it can't use them;


which i give to the ai, and i also describe our issue but anyways etc, then it would suggest me likely places, then i send it the code of the function it suggests plus some that seem relevant to me, then it gives me a draft and with trying to understand, testing it, etc, i implement it if it fixes or improves the issue and is safe.

One must be very careful with ai, it's great but it can easily mess the codebase, i believe my code is quite safe in that regard although could always be improved. I generally went for simplest braindead simple solutions as i understand them at least xd but anyways etc, and no reason to complicate if a simple fix is very effective, even if it approximates a bit (however sometimes i like to make the logic detailed like worker or settler logic, but sometimes simple is best i think at least works good enough and is effective and efficient and clean as i want it but anyways etc), it helps also save some computing power xd maybe too but anyways etc.

So yes AI is a huge relief. I have no affiliation with chatgpt xd, but chatgpt 5 works good and well enough, sometimes i need to iterate a few times, sometimes i ask other AIs like Grok AI (gemini 2.5 was in the past, i don't rely so much on it now as i found other ais to do better generally), for UI i like using claude like sevopedia tweaks, i like the code it provides to me but i only have free plan.

When issue is very hard (to me at least xd), i make AIs talk to each other i.e. share their solutions and even thinking sometimes and their reflection helps me solve or reflect on it too xd

So when it comes to civ4, AI is very great, it understands very well civ4 at least more than well enough as was nicely recommended to me thanks xd but anyways etc, but without experience it can easily be very frustrating and leading to mad rabbit holes xd (as was the case for me xd but i learned etc and was maybe fun in retrospect or not or yes or etc but anyways etc) if i may say but anyways etc.

Save file with issue, immediate code samples provided to chatgpt 5, understanding it, testing +/- refactoring for perf or simplification of logic, retesting, if good doing screenshots before/after if not lazy to do so (i did quite many in known issues), and then commit just this fix for reference and stronger code base point

I strongly advise against using agentic ai integrated to your ide if it would mean letting it freely modify your code (maybe it could work, but i fear it would ruin your code base way too easily trying to "fix" what is not immediate issues so better not touch if not needed, but otherwise AI is very great, i'm a big fan of it!). I'd like it to be able to read all our files and propose me code based on it rather, but as of now i don't know how to do it myself if it is ever possible (i guess so but not sure just a guess xd, and enver tried, check if accurate anyways etc), so for now i indeed send it code samples rather and it's very good/helpful at that i am very thankful thanks! But anyways etc.

I give it our global defines and it finds if one is missing or some value is unexpected. No need to tediously check; also since i dont know regexp, it provides me for example the regexp when i need xd like once for batch xml convert to dummy txt key.

And tons of other things. Basically very nice.

To have save files, make AI autoplay and watch what happens in cities, with workers, how the units move, do they make stupid decisions. If you find something really bad, try to fix this from save file (it needs to be reproducible too, and loading just the turn before often or sometimes doesn't reproduce the issue, i have found experimentally that you need at least 2 turns before a behaviour to reliably reproduce it in some cases it seems), and commit and then autoplay again xd, is how i do it and worked great so far, although could always be improved ofc i mean, but i like this experimental approach too :)

edit: its thoughts are also very helpful, in chatgpt website, you can click on "thought for xxm yys (time minutes seconds) and then it shows its thinking process, the data is incredibly useful and it says things there that don't always (quite often doesn't it seems anyways etc) about what it thinks of the problem, which helps me solve or enhance my code or/and thinking about the problem/solution too.

Also chatgpt 5 is great at viewing screenshots, not perfect but it can read unit compositions (military advisor), unitais in screenshots, it's not perfect but quite good at it and impressive (i've seen it crop in images to analyze parts of them, takes bit long but nice, also sometimes it tells you it doesn't have image analyzing ability, but if you ask it to do it then it does it, or it says that images are lost after prompt or something similar, yet many days later in same thread it can list me all screenshots (tried recently) and view them again it seems, so many useful tool and in many ways i consider it a friend too if i may say but anyways etc

edit 3: in chatgpt 5 there is a new as of now feature they quite recently added but anyways etc, click/set but anyways etc "Extended thinking", does not necessarily extend it a lot (although sometime once it thought for almost 15 minutes on a single prompt (before it timed out but had 99% finished and i could copy paste its thinking so next prompt took over; was for timeline remaking which chatgpt 5 is very good at with some patience (maybe i am bit too or not or yes or etc but anyways etc but it helps tons anyways etc) so it thinks longest it seems but anyways etc) but seems to help or possibly may (better put all chances on my side, and this is for any prompt so no extra cost in plus subscription plan (no publicity xd choose what you want/prefer but anyways etc)) or seems to be or may be so but check to be sure as this is just a guess of mine but i expect guessedly it does so but anyways etc.

edit 2: caution to anyone reading this who wants to do civ4 modding at least advciv-sas like modding for advciv based mod but anyways etc: it's very fun but takes tons of time even for simplest changes, please be aware of that to have smooth experience ideally i mean if i may say. But the good thing is once a solution is found it is permanent (assuming no bug or such), and AI is permanently better for all future games, which is a great motivator to try to "solve" civ4 at least getting closer to it by making AI smarter but anyways etc.
 
Last edited:
Updated new stable release from AdvCiv-SAS 5030 to AdvCiv 5055!

Not so long since last version but there are enough changes, fixes, and enhancements to make it a recommended to upgrade to version:

- Significantly stronger AI than in AdvCiv-SAS 5030, in particular in the early game offense, and renaissance to end game offense (heavily relaxed siege thresholds at renaissance and later eras (our gates were too strict at these eras, resulting in single digit or very low cannons count, even when no other alternative than pikemen was available, as a result AI now uses cannons a lot more, while still being conservative with catapults and trebuchets), relaxed early siege thresholds a bit (helps when catapults and trebuchets are our only offensive unit but not only, also helps supports early rushes better in autoplay it seems as well), removed UNITAI_COUNTER for units where it was bad/ineffective (chariots, cartage numidian cavalry), added offense only (default) and defense only logic in no production fallback unit code (in CvCity::doTurn anyways etc), both fallback as well to any eligible land combat unit if we have no offense unit in offense only or no defense unit in defense only: tunable in sas globaldefines (https://github.com/wonderingabout/A...ework/Assets/XML/GlobalDefines_advciv_sas.xml), added anti very cheap unit logic in the no production fallback unit code as well (reduces seemingly reliably ancient macemen or such that escaped the AI_ChooseUnit gates); results in significantly stronger early game (offense mostly if we can, else defense rather than always a bit too much longbowmen): e.g. De Gaulle AI has a 7 chariots + 3 catapults stack invading a rival at monarch at normal gamespeed at turn 100 vs not before we had too much longbowmen), e.g. 2: Charlemagne AI +/- 50 cannon class units at turn 250 vs less than 10 before this change (quite often spamming pikemen even when we have cannons available, and no muskets yet, which was very bad, although siege gates were nice especially against trebuchet spam, they are now more flexible))
- balance fixes (some units had the effects of other units: e.g. the persia_immortal and the greek_hoplite were in other units, so they were a bit too weak while other were too powerful, etc.) and adjustments (rebalance culture buildings to be stronger (colosseum class, etc.)), buffed or reworked several civ-specific units (cannon class (see below), french_musketeer, etc.)
- allow copper for some civ-specific units: roman_legionary, persia_immortal (the gallic_warrior had it, plus bronze at this era is plausible), and other units (see below). Not added to generic units (e.g. the generic unit_swordsman of all civs) to keep strategic importance of iron anyways etc.
- allow pikemen to upgrade to musketmen (they would use a nearby gun if they had it and not wait to die to cuirassiers, against which they are also useless now (unitcombat_polearm vs unitcombat_mounted_ranged is very ineffective)), helps AI produce less of them as well
- remove TRAIT_EXPANSIVE was overlapping with our more general TRAIT_PROTECTIVE (does not just protect defensively in our mod but also more generally protects health too and also has no anarchy (protects political stability more or less anyways etc)) and empire-expansion related TRAIT_IMPERIALIST (settler discount same, but also trade route based scaling yield modifiers), so TRAIT_EXPANSIVE was redundant. Also, it was among weakest (flat health not so helpful) and hardest to balance (most often weak or some (very in this case i mean but anyways etc) rare times op).
- overhaul all traits with a focus on historical accuracy most importantly, but also gameplay relevance (+/- civ-specific building and unit timing and effects as well but anyways etc) and overall civ theme to a lesser extent, with the help of chatgpt 5 and multiple rounds of review, +/- other AIs or not so much but anyways etc. For example, julius caesar has been changed from organized + imperialist to aggressive + imperialist (war theme and strength), hammurabi has been changed from organized + aggressive to organized + protective (more of an administrator + defensive civ overall if i'm not mistaken but anyways etc), saladin has been changed from protective + spiritual to spiritual + charismatic (more of warmonger in civ4 + historical warmonger and charisma), isabella has been changed from spiritual + expansive to spiritual + aggressive (very ruthless campaigns), charlemagne has been changed from imperialistic + protective to aggressive + organized (more controversial according to chatgpt 5 but he was focused on conquest and doing admin of his empire. He seems to perform nice in some games so i hope this helps mesh better with his more aggressive overall civ4 profile if i'm not mistaken but anyways etc), or hatshepsut has been changed from spiritual + creative to spiritual + financial (historically more accurate according to chatgpt 5, plus will most likely buff her if i'm not mistaken, which is nice i think if i may say but anyways etc). See for the list of all changes with a before vs after comparison as well as rationales the table at https://github.com/wonderingabout/A...-rework-with-rationale-andor-such-anyways-etc anyways etc. Note: as of now leaders' flavors unchanged for simplicity vs base advciv but anyways etc
- removed trait_expansive related building modifiers (they were the granary and harbor in advciv-sas before, removed as too generic and op plus no good/relevant candidate to replace them in a balanced way but anyways etc)
- fix missing FreePromotionUnitCombat in all unitcombats for trait_protective and some unitcombats for trait_aggressive.Hopefully works fine now in this case i mean but anyways etc and buffed the eleigible units' unicombar types since but anwyays etc
- swapped the imperialistic and organized traits' logos/icons
- buff and rework most traits (e.g. trait_spiritual is more about religion now, and trait_creative is more about cultural happiness anyways etc) anyways etc
- fix incorrect iron vs metal on renaissance bonus valuing logic (cannons need iron not no bonus, plus logic was checking for all metals, when copper is largely obsolete at renaissance (unlike in middle ages but anyways etc), so fixed logic)
- fix dual counting bug (as of now was only affecting siege units)
- replace the "HOLY_ROMAN_LANDSKNECHT" with the "HOLY_ROMAN_HOUFNICE (cannon-based, better match with holy roman empire's aggressive profile, medieval window was too tight, and the old landsknetch was obsolete too soon in combat by the time it was produced). Note: can also use copper for this civ-specific unit (as per above change: plausible bronze artillery). Note 2: as of now high copper value at renaissance for holy roman empire buyer trading logic not implemented as tedious. Note 3: overall very good results ingame it seems, in one run Charlemagne AI made a decisive push from turn 200 building many houfnice units and winning (see (note: i.e. here but anyways etc) https://forums.civfanatics.com/threads/advciv-sas-simple-advanced-strategy.699716/post-16875736) for example anyways etc.
- reduce tech costs a bit in the mid game until end game (they were still quite a bit too high for AIs and all players to keep up with timeline, now a bit better anyways etc. I don't want to reduce it too much to punish overbuilding military, so that players who build less units may be rewarded by higher tech advantage and possibly comeback (if they don't die xd but anyways etc)).
- performance optimizations
- minor UI enhancements in sevopedia
- 48 civs DLL included
- various other tweaks and fixes

Recommended to upgrade to this new version if you are using 5030 or an old version.

see for full changes: commit history from AdvCiv-SAS 5030 to 5055 viewable at https://github.com/wonderingabout/AdvCiv-SAS/commits/tech-rework/?since=2025-10-04&until=2025-10-10 or at https://github.com/wonderingabout/A...38...b8c861af13f28c070022e1bcca3c48e6040bc174
 

Attachments

  • 0.962_autoplay_about_5055_sample_monarch_1 (1).JPG
    0.962_autoplay_about_5055_sample_monarch_1 (1).JPG
    1.1 MB · Views: 12
  • 0.962_autoplay_about_5055_sample_monarch_1 (2).JPG
    0.962_autoplay_about_5055_sample_monarch_1 (2).JPG
    1.4 MB · Views: 13
  • 0.962_autoplay_about_5055_sample_monarch_2 (1).JPG
    0.962_autoplay_about_5055_sample_monarch_2 (1).JPG
    1 MB · Views: 14
  • 0.962_autoplay_about_5055_sample_monarch_2 (2).JPG
    0.962_autoplay_about_5055_sample_monarch_2 (2).JPG
    1.1 MB · Views: 15
  • Civ4ScreenShot1756.JPG
    Civ4ScreenShot1756.JPG
    1 MB · Views: 16
  • Civ4ScreenShot1757.JPG
    Civ4ScreenShot1757.JPG
    1 MB · Views: 16
  • Civ4ScreenShot1758.JPG
    Civ4ScreenShot1758.JPG
    818.8 KB · Views: 40
Last edited:

@civ4-advciv-oracle-bug :​

Maybe I missed it but how do you make the AIs talk with each other? Do you just copy-paste answers from one to the other or is there some other maybe more efficient way? :)
 
Yes more or less that's all, i can use their thinking as it gives some info that is not in their strict "reply", (espcially gemini ai who seems at least when i used it super chatty hehe xd but anyways etc), but yes just copy pasting "hey chatgpt thinks this about that issue but behaviour X or issue Y etc", and then do some back and forth, but it is rare i do so, as generally chatgpt 5 has enough replies for my prompts or such and to solve issues reliably/effectively enough i mean but anyways etc, and if i need to do such a thing, maybe my approach is wrong about how to approach the problem, or i'm tackling a too hard issue or one that i could do in several chunks or steps maybe.

There may / must possibly be a more efficient way to do this but i don't know about it, many things i don't know about AI, but i sure did use it quite a lot so far xd :) And i like doing so i mean if i may say but anyways etc.
 
Last edited:
hi there,
Well you inspired me to do some ai modding.

first im well experienced with LLM and ai agent (CURSOR) , i just didnt have the mood to go about civ4. but your work gave me the kick.
for now im just using gemini web.

i will compare your code to advciv 1.12 to see how i can cherry pick bulks of code you did and merge it to mine.
this is very interesting to what is achievable with LLm.

:)
 
Back
Top Bottom