Resource icon

C3X: EXE Mod including Bug Fixes, Stack Bombard, and Much More Release 17

Flintlock updated C3X with a new update entry:

Release 12

New in this version:
- Support for the executable from PCGames.de
- Option to modify rules for retreat eligibility
- Automatically re-encode config file contents from UTF-8 to match Civ 3's internal encoding
- Accented Latin characters no longer separate words
- Fix crash when a building-generated resource triggers the advisor popup for first connection
- Fix workers in boats can do "extra" jobs (road-to, auto-irrigate, etc.) despite restriction

Read the rest of this update entry...



Edit with some more details about what's changed:
  • The mod now supports another executable: the one available through PCGames.de. This doesn't matter to those of you who already own the GOG/Steam versions but it means anyone who owns a CD version of Conquests can run the mod without needing to rebuy the game. The PCGames.de EXE should work as a drop-in replacement for Civ3Conquests.exe in any V1.22 install.
    The EXE itself can be downloaded here: https://www.pcgames.de/Civilization...-Civ-3-Vollversion-Hier-gibts-Abhilfe-401682/
    Here's a thread with more info about it: https://forums.civfanatics.com/threads/civ-3-windows-update-kb3086255-safedisc.552308/
    Thanks to @Vaughn for generously commissioning this work.
  • Rules for when units can retreat are now configurable. The options are standard, none, all-units, and if-faster. if-faster is what people have been asking for, it means units can retreat from an opponent as long as they have more movement points. standard means the vanilla game rules. none means no units can ever retreat and all-units means all of them can even if they only have one move. All of this only applies to combat on land. In the future I'll look into modifying the retreat probabilities in addition to the eligibility rules. I haven't done that yet because it's quite a bit more difficult.
  • I've addressed the text encoding issues with config files on non-English installs. Config files must now be encoded with UTF-8. They will be automatically re-encoded to match Civ 3's internal encoding (Windows-1252) by the modded EXE when loaded. This means anyone who saved their config files as Windows-1252 has to resave them as UTF-8, but config files should "just work" from that point on since all modern text editors default to UTF-8, even lowly Notepad. Also I changed how words are parsed so that all accented letters in Windows-1252 do not separate words. That means names that include letters like ä, ç, é, ü, etc. don't need to be wrapped in quotation marks.
 
Last edited:
Flintlock, in the config file the term "scenario data" is used several times (per example: building resource generation is calculated in the same order as the generated resources appear in the scenario data).

Does scenario data mean the sequence of the resources in the biq, the sequence of resources in the brackets of the config file [forge: iron, "steel mill": steel] or both ?
 
Does scenario data mean the sequence of the resources in the biq, the sequence of resources in the brackets of the config file [forge: iron, "steel mill": steel] or both ?
"Scenario data" refers to the contents of the BIQ file, so it's the first one. The order of the items in that bracketed list doesn't affect anything. By the way, have your troubles with the config file's text encoding been resolved? I tested R12 against that German BIQ you sent me, and it worked for me.
 
"Scenario data" refers to the contents of the BIQ file, so it's the first one.
Flintlock, thank you very much for your answer - and of course for your great work with R12. :)
By the way, have your troubles with the config file's text encoding been resolved? I tested R12 against that German BIQ you sent me, and it worked for me.
In my tests there were no remaining problems with the German "Umlaute" (ä,ö,ü) in R12. :thumbsup: I posted the new German version of your great mod today at civforum.de.
 
Greetings Flintlock,

Your new edits have enabled a multitude of options for the way that buildings and resources interact with each other. Thank you!

I had another idea for creating more modding options that I hope would be relatively easy to implement (though I can't know for sure). The idea is that while at least one of a unit with the same name as a building is in a city, then the city gets the corresponding building provided for free. Alternatively, instead of being based on the unit and building names, the unit-->building relation could be specified in the C3X scenario config file.

This one change, combined with the changes you've already made, would implicitly enable a wide number of new modding possibilities:

* Mobile unit-buildings (e.g. cattle herd), and thus more broadly nomadic Civilizations
* Unit-buildings with HP
* Unit-buildings that upgrade to others via the unit upgrade mechanic (can upgrade your existing building and/or can't build the old building)
* Mobile "resource" or "figurehead" units that provide a resource to a City when stationed there via your new building-resource mechanic.
* Etc.
 
I have some more ideas for possible new features changes!

A hotkey for toggling unit animations, also something like a combat log for when animations are turned off?

And the ability to adjust the values military units have of preventing a culture flip in cities! Perhaps 1.5 to 2 military units are needed per citizen to prevent the city ever culture flipping so long they are garrisoned there ( I believe in game currently military units can never reduce the value of culture flipping to zero) . Along that note, if starved citizens increased the chances of culture flipping (if that isn't already factored in via unhappiness).

Also what are people's experiences using the mod specifically with artillery? Thus far the downside of improved AI artillery use has been sometimes it will degenerate into artillery slugfests that achieve exactly nothing, mostly because the AI will escort one defensive unit per artillery and never ever use them to attack even if it makes sense to do so, say to capture unescorted guns. Ive given artillery lethal bombardment and health bars and this makes up for it somewhat, slugfests will still happen if that stacks are fortified and large enough especially with 2 range artillery, but this makes doomstacks absolute nightmares which is great. Im wondering if I should further increase artillery RoFs.

2022-08-12 (5).png


AI artillery doomstack, if I didn't cheese the AI by cutting the roads to Zabalam (mountains are impassable for most units in this scenario) this war would have turned out very differently. Later my own artillery doomstack of 40 artillery guns with more modern units wasn't able to deal with it either, but it allowed me to pin the stack in an endless artillery duel so I could attack on another front. After the roads were cut the AI seemed to leave the stack there, and in general AI artillery likes to sit in positions they found and never ever reposition - a great example here where they wouldnt even with no way to advance and no targets.
 
Last edited:
And the ability to adjust the values military units have of preventing a culture flip in cities! Perhaps 1.5 to 2 military units are needed per citizen to prevent the city ever culture flipping so long they are garrisoned there ( I believe in game currently military units can never reduce the value of culture flipping to zero) . Along that note, if starved citizens increased the chances of culture flipping (if that isn't already factored in via unhappiness).
Starving actually helps against flip risk and flip risk can be reduced to zero, but it takes uneconomically many units unless your culture is clearly superior.

 
Starving actually helps against flip risk and flip risk can be reduced to zero, but it takes uneconomically many units unless your culture is clearly superior.

Yup, both these things I dislike! The cost of starving a population in games terms is minor and micromanagement intensive (and logically should increase the chance of flipping but thats besides the point), while stationing units is both uneconomical, risky, and arcane in how many are actually needed (formula aside!)
 
I have some more ideas for possible new features changes!

A hotkey for toggling unit animations, also something like a combat log for when animations are turned off?

And the ability to adjust the values military units have of preventing a culture flip in cities! Perhaps 1.5 to 2 military units are needed per citizen to prevent the city ever culture flipping so long they are garrisoned there ( I believe in game currently military units can never reduce the value of culture flipping to zero) . Along that note, if starved citizens increased the chances of culture flipping (if that isn't already factored in via unhappiness).

Also what are people's experiences using the mod specifically with artillery? Thus far the downside of improved AI artillery use has been sometimes it will degenerate into artillery slugfests that achieve exactly nothing, mostly because the AI will escort one defensive unit per artillery and never ever use them to attack even if it makes sense to do so, say to capture unescorted guns. Ive given artillery lethal bombardment and health bars and this makes up for it somewhat, slugfests will still happen if that stacks are fortified and large enough especially with 2 range artillery, but this makes doomstacks absolute nightmares which is great. Im wondering if I should further increase artillery RoFs.

View attachment 636591

AI artillery doomstack, if I didn't cheese the AI by cutting the roads to Zabalam (mountains are impassable for most units in this scenario) this war would have turned out very differently. Later my own artillery doomstack of 40 artillery guns with more modern units wasn't able to deal with it either, but it allowed me to pin the stack in an endless artillery duel so I could attack on another front. After the roads were cut the AI seemed to leave the stack there, and in general AI artillery likes to sit in positions they found and never ever reposition - a great example here where they wouldnt even with no way to advance and no targets.
If you didn't give artillery lethal bombard the AI would be very bad at taking advantage of your units being redlined because the escorting riflemen would never be used to attack. They'd need attackers to arrive from the back to kill your defenders. Sure, the city will be reduced to rubble but you can fix this huge mass of units in place with a relatively small defending force while your own offensive artillery doom stack makes real gains somewhere else.

The next breakthrough would be to somehow get the AI to including an offensive unit to the stack.
 
I must say that I'm very much with Sula when it comes to Lethal Bombardment;

Spoiler Sulla's Thoughts On Lethal Bombardment :


1) Lethal Bombardment: This change, without a doubt, was by far the worst thing that BreakAway Games did to Civ3. The stand-alone game offered a great balance between artillery and regular units, with artillery being able to damage other units but unable to defend themselves. Most importantly though, they could NEVER kill other units; the only unit which could was the pricey, one-time use cruise missile. Regular units were the only ones which could actually kill units or capture other artillery pieces, so it was necessary to use a combination of both to achieve best results. Intelligent use of combined arms like this added a great deal of strategy to Civ3, and helped elevate it quite a bit beyond its two predecessors (where catapults were 6/1/1, for example). Bombardment on ships and planes worked the same way, and intelligent players fighting wars in the Modern Age would frequently use both. Bombers, for example, could hit targets much further away than artillery but had the weakness of being shot down or having the city they were based in captured. Battleships could defend themselves against attack without need of a protecting unit, but could only hit targets along the coastline. Bombardment in standard Civ3 was thus able to offer a very large advantage to the player, but the fact that units still had to expose themselves to attack in order to finish off another unit for good kept bombardment units from running away in strength and the player from exploiting his/her edge in artillery to ridiculous degrees.

Any such balance has been thrown out the window in Conquests.

I suppose I should explain how it started. I'm in a unique position to do so since I was part of the beta test for Conquests and read all of the discussions on the bulletin boards which are now sealed away forever on some Atari server. Apparently the folks at BreakAway didn't think that players were using air power enough in Civ3, so they decided to emphasize it in the expansion. Thus it was proposed to double the range of all planes (OK with me) and give all planes lethal land and sea bombardment (whaaat?!) Now anyone who has invested a significant amount of time in Civ3 should have been able to see instantly what the implications of such a decision would be. I envisioned stacks of 100s of bombers pounding Deity civs to a pancake and then cavalry walking into the undefended cities. I pointed this out immediately. I played a test game that drastically showed that this design change would destroy any balance after the discovery of Flight. Here's what I said about it, pulled right from a game I submitted during the testing:

Finally, another issue that needs to be dealt with is lethal bombardment for airplanes. It's just excessive and extremely overpowering in the hands of a human player against an inhuman AI. When the Aztecs sneak-attacked me, I had just built my first bomber that very turn and had no air force to speak of. 10 turns later, even with just a dozen bombers I was able to redline and then KILL every defender in an Aztec city, which my cavalry then proceeded to walk into untouched. What could I have done with 20 bombers - or 50? I could have killed all the defenders in every city and let my units walk into them one by one without ever fighting a battle. Combining non-lethal artillery with lethal bombers is even worse, which I was able to do routinely as well. I don't even want to THINK about what radar artillery plus stealth bombers could do. Suggested Fix: No planes should have lethal land bombardment. Sea bombardment yes, but never land bombardment. This was what I said when I first read the desciption of that change, and my testing has only proven it out. Lethal land bombardment of any kind is simply too overpowering for any units to have it. Maybe that makes you unhappy - deal with it, it IS too powerful. The fact that the range for air units has been greatly increased already massively increases their power. Adding lethal land bombardment on top is way, WAY too much.
 
I had another idea for creating more modding options that I hope would be relatively easy to implement (though I can't know for sure). The idea is that while at least one of a unit with the same name as a building is in a city, then the city gets the corresponding building provided for free. Alternatively, instead of being based on the unit and building names, the unit-->building relation could be specified in the C3X scenario config file.
That's an interesting suggestion. It would be tricky to implement though. One approach would be to edit the function that determines if a given improvement is present in a given city to also check if the improvement is provided by any unit on the city's tile. That might noticeably slow the game down since that function is called a lot, but the real catch is that certain improvement effects wouldn't be applied because they need to be manually recalculated. For example, if that improvement provides happiness that effect wouldn't be visible until the city's happiness is recomputed, which happens between turns, when the luxury slider is moved, etc. If the improvement provides a local resource that would appear immediately but a non-local resource wouldn't appear until something triggers a reevaluation of the trade network.

An alternative approach is to actually add a building to cities those special units enter and delete the building when the units leave. The catch there is I'd have to intercept every point in the code where a unit could enter a city and every point where it could leave. I don't know where all those points are, and I don't know of any common method I could edit, like one that's called to change a unit's location. Another catch is that players could sell the building or it could get destroyed by bombardment (this likely isn't a problem using the first approach b/c that function I mentioned can distinguish between built and free improvements). Again, an interesting suggestion, and an interesting challenge to implement too.
A hotkey for toggling unit animations, also something like a combat log for when animations are turned off?
You mean like making shift skip combat animations? I'd thought of doing that at least during stack bombard, as often while playing I forget to turn off combat animations before ordering a big stack to bombard then get stuck watching the animations slowly play out. It's especially annoying with bombers. Adding a combat log would be doable, I already know where in the code combat begins. The hard part would be making the log viewable through the interface since there's nothing like that already in the game that I could modify. Though your screenshot gave me an idea, maybe I could list all the combat events in a menu like the right-click menu. Clicking an event could take you to the location.
And the ability to adjust the values military units have of preventing a culture flip in cities! Perhaps 1.5 to 2 military units are needed per citizen to prevent the city ever culture flipping so long they are garrisoned there ( I believe in game currently military units can never reduce the value of culture flipping to zero) . Along that note, if starved citizens increased the chances of culture flipping (if that isn't already factored in via unhappiness).
Sure, that would be easy to do. Another thing I was thinking of, related to culture flips, is to display the flip chance somewhere on the city screen.
 
That's an interesting suggestion. It would be tricky to implement though. One approach would be to edit the function that determines if a given improvement is present in a given city to also check if the improvement is provided by any unit on the city's tile. That might noticeably slow the game down since that function is called a lot, but the real catch is that certain improvement effects wouldn't be applied because they need to be manually recalculated. For example, if that improvement provides happiness that effect wouldn't be visible until the city's happiness is recomputed, which happens between turns, when the luxury slider is moved, etc. If the improvement provides a local resource that would appear immediately but a non-local resource wouldn't appear until something triggers a reevaluation of the trade network.

An alternative approach is to actually add a building to cities those special units enter and delete the building when the units leave. The catch there is I'd have to intercept every point in the code where a unit could enter a city and every point where it could leave. I don't know where all those points are, and I don't know of any common method I could edit, like one that's called to change a unit's location. Another catch is that players could sell the building or it could get destroyed by bombardment (this likely isn't a problem using the first approach b/c that function I mentioned can distinguish between built and free improvements). Again, an interesting suggestion, and an interesting challenge to implement too.

Thanks for considering it! And thanks for providing your analysis. With regards to the first method, my guess is that it would generally not be a problem if a building's effects are not applied until the following turn (though I see what you mean about global resources). Interesting point about computation time; are you saying that every turn each city loops through all buildings, calling a function for each building to double-check if the city has that building?
 
Just a couple things I have been playing around with that currently do not work:
1. You cannot combine only foot units and only aircraft tags
-> i added drones (weak multi attack aircraft without rebase capabilities) and set them as food units. i then added a land based carrier unit with both above tags set. unfortunately also non foot units (normal jets and bombers) could be loaded and rebased onto these drone bases destroying the mechanic

2. giving the automate action to a unit able to bombard: if a human clicks automation the unit will try to attack units of other civs you are at peace with

3. adding "transporter units". i added units that can transport foot units on land, helping with transporting slow units faster
-> the ai does not use them at all (i have not tried now with the army bug fixed tho)
-> it would be better if the loaded units would lose movement similar to how you implemented railways now. if the transporter moves the unit loses the same total proportion of its movement. e.g.: road movement = 3. transporter moves=2 loaded moves=1. if the transporter moves one tile on road it goes from 2/2 -> 5/3 over 2. the loaded would go from 1/1 to 5/6 of 1

4. AI does not use amphibious artillery units from ships

5. AI does not use hidden nationality artillery units against civs it is at peace with.

Also a feature request and a bug fix request:
1. great wall bug: bombarding a city with a wall given by a wonder will instead destroy random other buildings including *wonders*
-> i would prefer if instead the -to be destroyed- free building would be disabled in the city till the city is not attacked for one turn
2. in the game second tier factories cannot be build in parallel aka "replace others with this flag". it would be awesome if this mod would allow more separable groups of buildings where the player has to choose one of.


edit: i just remembered another thing:as far as i understand big worlds are mostly limited by one thing: the trade recalculation scales exponentially with then number of cities in the world. so in large worlds over time a city trades hands it can mean a 10 minute wait. if you are ever ambitious it would be amazing if you could replace it with a better faster algorithm. i had worked out an algorithm that should essentially be able to do it in linear time a while back when i had time to write on my civ-like game engine (for running civ3 in the end) but i never got around to implement it (yet). it does require metadata per tile tho
 
Last edited:
Bug report: Using stack-move/stack-rebase on a land unit that is immobile but posesses the "rebase" ability will crash the game. This is a vanilla feature, so nothing you did, but you worked on movement a lot, and maybe it would be an easy fix.
Oh, also, ability hotkeys don't seem to work when from the "wrong" domain. On a land unit with recon ability, you have to click the recon icon, pressing R does not work. :/


I just had an idea regarding barbarians. Would it be possible to do the following:
1. Have a list of technology - unit pairs in a config file, (priority increasing in one direction), where you can put technology prerequisites and units to be built afterwards
2. Hijack the unit creation logic of barbarian camps to check the nearest civilisation for the technology list, and pick the highest available unit in that list to spawn

Example:
Config:
Construction - Swordsman
Military tradition - Musketman
Mass production - Guerilla
Barbarian camp closest to Greeks who are in early industrial decides to spawn a unit. Checks list: Construction and M.Trad are there, but Mass Prod is not, so a musketman is spawned. Same turn, a camp closest to the Byzantines in late industrial follows the same logic and after checking successfully for Mass Prod, spawns a guerilla.

Idea behind this being that the "barbarians" of a civ are comparable to the local progress. Initially I thought just checking globally for whether any civ had the tech, but that could lead to situations where a runaway civ triggers industrial barbs near some poor medieval countries.

You mean like making shift skip combat animations? I'd thought of doing that at least during stack bombard, as often while playing I forget to turn off combat animations before ordering a big stack to bombard then get stuck watching the animations slowly play out. It's especially annoying with bombers.
When using your own stacks, you can at least go to the preferences and turn it off for the next stack command. But when watching an AI stack of 32 artillery pieces bombard a city into oblivion, you cannot access those, and are forced to wait until the next turn. Maybe caps lock could be used to skip these animations, just like it speeds up movement, too? While holding shift would only speed up movement while held, but not combat. (One typically being used to skip through entire rounds, the other to skip through some movement temporarily)

Another thing I was thinking of, related to culture flips, is to display the flip chance somewhere on the city screen.
Excellent idea!
 
Last edited:
Interesting point about computation time; are you saying that every turn each city loops through all buildings, calling a function for each building to double-check if the city has that building?
It's not really a double-check, it's more like the normal check. That function is the standard way that the game determines if a given improvement is present in a given city. To process all improvements in a city, the game considers all improvements defined in the scenario data and calls that function to filter out only the ones that are present. That kind of thing is pretty common, for example when a city finishes a unit it checks all present improvements to see if there are any that give the unit a bonus experience level. It does the same thing when computing city production, commerce, corruption, happiness, pollution, defensive bonuses, available build options, and so on.

But what really concerns me is the cost of the unit AI. Imagine an AI battle where a large stack of units is attacking a city with a large stack of defenders. Each attacker must find the top defender in the city, which means evaluating the defense strength of each defending unit, which means finding the defensive bonus provided by the city, which means checking every present improvement. If checking every improvement requires checking every unit in the city, you'd be considering every defending unit, times every possible improvement, times every defender, times every attacker. That could easily be a drag on turn times. Though I should point out this is all speculative. Maybe the combat code doesn't work that way, or maybe the slowdown caused would be drowned out by some other factor. The only way to know would be to test an actual implementation.
Just a couple things I have been playing around with that currently do not work:
I'll add all of these to the list, though I can already say some of them would be pretty difficult.
2. Does the automated artillery seek out targets, or does it bump into them as it's going about its business?
3. The fixes related to armies wouldn't affect this. Land transports would need a new unit AI written for them. That's doable, in fact I've already done it for the leader unit AI, but it would be difficult. It would require some logic to determine where to take transported units to, I can't think of any simple way to do that. And it would require units to decide when it's a good time to load themselves onto a transport. That would require integrating with the existing offensive/defensive unit AIs somehow.
4. I'm not sure what you're referring to here. Do you mean artillery units with the amphibious flag? As far as I know that flag does nothing for artillery units. If you mean bringing artillery along for naval landings, the mod already allows the AI to do that since version 9.
Also a feature request and a bug fix request:
I didn't know about the great wall bug, though I'd heard it's possible to destroy wonders through bombardment under some circumstances. That's a good idea about temporarily destroying the free building instead of another random one. Unfortunately the problem with that is it would require storing information about the temporarily destroyed buildings in the save file, at least to do a proper job. Right now I don't have any way of adding things to the save file, it's something that's come up a few times over the past year and a half but I haven't gotten around to figuring it out yet.
the trade recalculation scales exponentially with then number of cities in the world. so in large worlds over time a city trades hands it can mean a 10 minute wait. if you are ever ambitious it would be amazing if you could replace it with a better faster algorithm
Unfortunately the way I have the mod set up makes this difficult, beyond just optimizing the calculation. The problem is that the mod works like a script, even though it's written in C which isn't normally considered a scripting language. The mod compiles itself and the code to inject on the fly with TCC. TCC is a nice, small, and fast compiler but the catch is that it only does minimal optimization. This isn't a problem right now since the mod doesn't do anything performance-critical, but if it were to I'd need to compile that code ahead of time and include it with the mod in a DLL or something. That's totally possible, but it does discourage me from attempting something like this.

Setting aside that small technical roadblock, I have looked over the trade net calculation logic once before but not closely enough to know what algorithm it's using exactly. It certainly doesn't feel like something that's been well optimized. However the slow part might not be the trade net algorithm per se, but the pathfinder that it depends on.
I just had an idea regarding barbarians. Would it be possible to do the following:
Sure. Changing the types of units spawned by the barbs would be easy. I've already found the location where the barb logic calls the unit spawning method, and it would be easy to intercept that call and swap out the unit type.
Maybe caps lock could be used to skip these animations, just like it speeds up movement, too? While holding shift would only speed up movement while held, but not combat. (One typically being used to skip through entire rounds, the other to skip through some movement temporarily)
That makes sense. I usually forget caps lock even exists since on my keyboard I've rebound it to work like another control key. I'll try to look into this for R13 since it's something I've been thinking about doing for at least a year now.
 
Flintlock, sorry it's taken me so long to reply, but I just finished a game with the airborne unit improvements I requested, and I was very satisfied. They made paratroopers (and helicopters) go from "worse than useless" to "marginal", which is what I wanted. Captured some workers (and executed them), tore up a road to a resource, and took a city (after 40 bombers wasted it). Most times the paratroopers died on the subsequent turn.

Theoretically you can jump a paratrooper onto your own turf, take the railroad back home, and jump again, but this doesn't seem to be an exploit as A) this is like doing multiple "training" jumps which certainly happens in the 1-5 yr time span for turns. B) not really much different from riding the rails in circles with regular units.

Also, the AI formed multiple capable single-unit armies and killed several of mine. I did have some ideas how to further improve the AI's combat skillz, and I'll try to articulate them coherently in a subsequent post, but in the meantime, I just wanted to say thank you for an amazing job and doing your part to keep an old game endlessly fresh and interesting. (I emailed Suede about your mods as he could definitely benefit from the negotiation shortcuts and stack bombard but he was worried about a virus :( )
 
Thank you so much for your continuous efforts and considering our ideas! :)

I can also agree to Ruin, paratroopers are actually good for some specialised jobs now. When I raised their attack value and gave them all terrain as roads (the AI loves this trait so much) and perfumed airports for the AI, they actually liked making lots of them and had them land everywhere in enemy territory (Without the perfume, they make paratroopers but barely any airports, so they just walk around randomly). While the AI is not great at deciding good targets for them or massing several of them in the same landing tiles, it is at least capable to do paradrop insertions for some effect.
 
Top Bottom