Resource icon

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

Hello Flintlock, I still have a lot of fun with your great mod.

Today I tried the "Barbarian city" option in your mod. I created a CCM 3 Debug biq and set the Barbarian option in the scenario config file of R20 to true in the hope to see now at least one Barbarian city on the randomly created map.

Barbarians.jpg


Barbarian activity was enabled and the game was started. Unfortunately my hope did not come true. There was no Barbarian city on that map, even after several turns. When I added a Barbarian settler on the map, that settler did not found a city. At least the Barbarian settler was not disbanded by the game.
 
Last edited:
@Civinator wouldn't the barbarians on a random map have to actually capture a city from another civ in order to have one?

As for the starting settler, I'm not so sure the AI for barbarians is coded to handle non-combat units (settlers/workers/scouts) at all; perhaps for future consideration in the same way that the mod overwrites the barbarian level if it's set to 0, it should also overwrite the barbarian's AI with regards to these units if the option is turned on? I could be wrong on this one though.
 
I tested this feature quite a bit when it was first introduced. Yes, it changes behaviour when barbs attack a city. Barbs will indeed now capture and hold undefended cities. They can also be preplaced using Quintillus editor, but cities will not be spawned randomly on start.

The barb economy is fully functioning when they have cities, but it appears they pay maintenance on all the extra generated units so are always bankrupt!
 
@Civinator wouldn't the barbarians on a random map have to actually capture a city from another civ in order to have one?

Yes, this was my first thought, too, as the option is called "city_capture_by_barbarians" and not "city_founding". On the other side in the description of that option stands, that when this option is enabled, there is at least one barb city on the map. The description speaks of enabling that option (what is done by setting that option to "true" and not of capturing a city when this option is enabled.

All in all for me it would be much more important (and I will test this soon), if preplaced Barbarian cities on premade maps would work well. CCM and RARR need better worldmaps. :)
 
The barb economy is fully functioning when they have cities, but it appears they pay maintenance on all the extra generated units so are always bankrupt!
In this case the Barbarian units must be set to need no unit support costs and the buildings barbs can build to need no maintenance costs (what in CCM is the case).
 
In this case, the sentence 'there is at least one barb city on the map' is part of the requirements to turn the barb level from 0 to 1, so if you made a scenario with a barb city in it but with barbarian activity set to no barbarians, C3X would automatically turn the barbarian activity up to sedentary.
 
Randomly spawning in barb cities would be a good use for a Lua script. In fact, Lua could also be used to write an AI routine for barb settlers. In the base game, there is a separate AI routine for all barb units regardless of their AI strategy, and evidently it can't handle settlers.

Double Happiness Of, Gain in Every City and Gain in Every City on Continent. Would it be possible for these three features to switch the targeting from your own cities to everyone else's player cities on the continent or in the world? Which improvements this switched targeting applies to would be told in the config file. Or is it better to wait for LUA?
This would be possible and wouldn't require Lua or even really benefit from it. The game has a function that determines whether any given improvement is present in any given city. The way it works is it checks first in a table of free improvements for the city's owner and second in the city's list of improvements that it has produced itself. To allow wonders to add free improvs to other players' cities, I'd add another set of tables and modify the function to check them. I don't know about "double happiness of", it depends where that's implemented, but it probably wouldn't be difficult to make it check for wonders that other players have built.

The barb economy is fully functioning when they have cities, but it appears they pay maintenance on all the extra generated units so are always bankrupt!
This was fixed in R20, BTW. Now all units with a tribe ID set, which should cover all barb units spawned in camps, count as maintenance free units for the barb player.
 
This would be possible and wouldn't require Lua or even really benefit from it. The game has a function that determines whether any given improvement is present in any given city. The way it works is it checks first in a table of free improvements for the city's owner and second in the city's list of improvements that it has produced itself. To allow wonders to add free improvs to other players' cities, I'd add another set of tables and modify the function to check them. I don't know about "double happiness of", it depends where that's implemented, but it probably wouldn't be difficult to make it check for wonders that other players have built.
So, if it is simple to implement, it would be great to include it in the latest version as a very significant extension of what can easily be accomplished with a minor modification. I hope this is not a weird or extravagant request and the benefit will be appreciated by most modemakers. The idea behind all of this is to be able to build wonders that would only give other players an improvement that would give positive or negative effects such as that unhappiness that could even be doubled. If you don't mind, I have a couple of additional questions that I absolutely acknowledge are already a bit more narrow in nature, but I can't not ask because they are inevitably related to the original issue.

1. The effect of doubling happiness is NOT cumulative. That means that if I build more wonders doubling the happiness/unhappiness of the same improvement, I achieve at most 2x happiness/unhappiness and never 3x, 4x, etc. Would it be difficult to adjust this?

2. This would definitely fall into LUA territory in my opinion, but I'll give it a try anyway. What other things could EASILY be taken into account when deciding which other cities to put a given improvement in? In this regard, I'm thinking primarily of a WAR/PEACE state, so that wonders giving other players improvements "with negative traits" only go to enemy cities, and conversely wonders giving other players improvements "with positive traits" only go to allied cities. So would it be easy or difficult?

3. The unhappiness caused by improvements CANNOT GO BELOW the so-called number of citizens born content defined by difficulty. This means that no matter how many unhappiness-causing improvements you build in a city, there will always be a NONVariable MINIMUM and a Variable MAXIMUM number of content citizens. I don't know if this is an intention of the developers or an oversight, since in the base game improvements don't use the ability to cause unhappiness. Therefore, I think it would be more natural to remove this lower limit (NONVariable MINIMUM) preventing going below 1-4 depending on difficulty. Yes, of course there is a way to partially get rid of this lower limit with the current means available, and that is by setting the number of citizens born content to 0 in the editor for all difficulties and giving for example the Palace the creation of a few happy faces for itself and other own cities to compensate for the more difficult conditions. This will seemingly forcefully reduce the lower limit, as the number of citizens in a city cannot be non-positive, but I don't consider this to be an optimal solution. So, is this an intention or an oversight worthy of correction?
 
With the code I've inserted, it's possible to set the stack limit on a per-tile basis, so yes, it could easily be made to vary based on terrain type. This is again one of those features that would be easy to make work in terms of game logic but hard to read in from the config file. I suppose the best way to do it would be to have a list of percentages by terrain type so you could set something like [Desert: 50, Mountain: 50] so deserts & mountains have half the stack limit.

That sounds ideal.
 
Is it difficult to modify the resources in city radius requirement to not needing them to be connected into the city by roads? This way we can have offshore oil by creating an "oil rig" improvement requiring "sea oil" in the city radius. This "oil rig" improvement will then generate the strategic resource oil. Right now we can have offshore platforms/oil rigs generate oil. But there's no way to tie it to any resource on the map. Any coastal city could generate oil.
 
Is it difficult to modify the resources in city radius requirement to not needing them to be connected into the city by roads? This way we can have offshore oil by creating an "oil rig" improvement requiring "sea oil" in the city radius. This "oil rig" improvement will then generate the strategic resource oil. Right now we can have offshore platforms/oil rigs generate oil. But there's no way to tie it to any resource on the map. Any coastal city could generate oil.

As a convulted workaround, Harbors could generate the strategic resource "Sea Oil" in their city and the "Oil Rig" improvement which generates Oil could require Sea Oil in the radius? Downside is it'd also give all cities with a harbour the tile yields for the Sea Oil resource.
 
As a convulted workaround, Harbors could generate the strategic resource "Sea Oil" in their city and the "Oil Rig" improvement which generates Oil could require Sea Oil in the radius? Downside is it'd also give all cities with a harbour the tile yields for the Sea Oil resource.

But then how do you tie any resource on the map to a specific harbor? Not all coastal places in the world have access to oil. Scotland, Norway and Brunei have hit the jackpot when it comes to offshore oil. And why not just have the coastal oil rigs generate oil instead for the same effect? Or have stock game's offshore platform generate oil?

Right now the best I can come up with is a city needs to have oil in its radius to be able to build the coastal only improvement "Offshore oil rig" that generates another oil. You need to have a land oil roaded within your coastal city radius. But now you get 2 oils in your trade network instead of one. The oil within the coastal city's radius represents you hitting the offshore oil jackpot. Think of it as if there's an oil source next to the sea then there should be more of it in the sea.
 
But then how do you tie any resource on the map to a specific harbor? Not all coastal places in the world have access to oil. Scotland, Norway and Brunei have hit the jackpot when it comes to offshore oil. And why not just have the coastal oil rigs generate oil instead for the same effect? Or have stock game's offshore platform generate oil?

Right now the best I can come up with is a city needs to have oil in its radius to be able to build the coastal only improvement "Offshore oil rig" that generates another oil. You need to have a land oil roaded within your coastal city radius. But now you get 2 oils in your trade network instead of one. The oil within the coastal city's radius represents you hitting the offshore oil jackpot. Think of it as if there's an oil source next to the sea then there should be more of it in the sea.

The "Sea Oil" should be a seperate strategic resource. All harbours or whatever would produce the resource "Sea Oil", which would allow the cities with both harbours and sea oil in the radius to build oil rigs, which produce oil. Remember - for the "requires resources in the city radius" flag, the resources in the radius don't actually have to be connected by road themselves, so long as the city has access to those resources from elsewhere.
 
The "Sea Oil" should be a seperate strategic resource. All harbours or whatever would produce the resource "Sea Oil", which would allow the cities with both harbours and sea oil in the radius to build oil rigs, which produce oil. Remember - for the "requires resources in the city radius" flag, the resources in the radius don't actually have to be connected by road themselves, so long as the city has access to those resources from elsewhere.
I see. So even if all harbors produce "sea oil", you'd still need to have an actual sea oil in the city radius for the mechanism to kick in. But the sea oil production solves the problem of not having a road connected.
 
BTW, all these numbers are for the save someone posted to this thread a while ago that was close to the limit. That save is a good example since it uses only the base game's art files, so that eliminates custom art right off the bat as a possibility for where the memory is going. I'm not sure what I can do, if anything, about the so-called 32 MB save limit (in reality it's not a limit and doesn't occur at 32 MB). The good news is that setting the Large Address Aware bit on the EXE allows it to use an extra gigabyte or so of memory and C3X already does that when you install it. I'd still like to investigate more to figure out where the memory is actually going, if only because I'm curious now.
As for Sound.dll being part of Bink
I have looked at a bit a Bink and because its also closed-source cool stuff like wasm sandboxing obviously doesnt work without major work. however there are newever versions of the Bink and some may be ABI compatible, OR can be made compatible by a translation layer. Accessing these newer versions of Bink obviously comes with the hurdle, that they are not publicly available. However Bink was so nice to list most games that use Bink on their website including CIV IV.
it may be worth trying to see what happens if one would just substitute the DLL with different versions (they also have a list of all versions ever released), and one can simply compare the ABI of the exported functions (only those imported by CIV of course) if simple substitution does not work.
This may fix such memory bugs and may also further increase performance

Another option i have playing with is simply replacing the whole graphics part of civ. i have a half functional tile renderer using shaders, so remaining work (which is more work) would be UI
 
The effect of doubling happiness is NOT cumulative. That means that if I build more wonders doubling the happiness/unhappiness of the same improvement, I achieve at most 2x happiness/unhappiness and never 3x, 4x, etc. Would it be difficult to adjust this?
This wouldn't be easy but it wouldn't be all that difficult either. The original logic for the doubling happiness effect isn't practical to modify. However it's inside of a relatively small function that could be entirely rewritten. That function's purpose is to sum the happiness from all buildings in a given city and it does that in a very straight forward manner.

This would definitely fall into LUA territory in my opinion, but I'll give it a try anyway. What other things could EASILY be taken into account when deciding which other cities to put a given improvement in?
I think the hard part here would be knowing when to recompute city economies because a building may have been added or lost due to some weird rule. For example, if you want a wonder that adds an building to only enemy cities, it would be simple to modify the has_improvement function to check for that but you'd also have to make sure to recompute city happiness whenever wars started or ended to make sure the building appears when it's supposed to. Other than that, modifying has_improvement to consider additional conditions is no more difficult than programming those conditions anywhere else. E.g., if you want buildings to appear based on the surrounding terrain, the traits of the civ that owns the city, the distance to some other city, etc., that would all be pretty easy.

The unhappiness caused by improvements CANNOT GO BELOW the so-called number of citizens born content defined by difficulty. This means that no matter how many unhappiness-causing improvements you build in a city, there will always be a NONVariable MINIMUM and a Variable MAXIMUM number of content citizens. I don't know if this is an intention of the developers or an oversight, since in the base game improvements don't use the ability to cause unhappiness.
I'm not sure what's going on here. The function to sum happiness from buildings doesn't directly limit unhappiness to that content citizen number, so it doesn't look like the developers programmed that specific rule you describe. I can see that the content citizens from difficulty does contribute to the happiness computation one level higher but I'd have to study the recompute_happiness method to figure out exactly what it's doing because it's surprisingly complicated.


As for Sound.dll being part of Bink
What makes you say sound.dll is part of Bink? From what I've seen, it looks like something Firaxis wrote themselves. For example, AMB files are loaded and played by sound.dll and I haven't been able to find anything online about that sound format outside of Civ 3. The backend for sound.dll is Miles Sound System, which is in Mss32.dll.

Another option i have playing with is simply replacing the whole graphics part of civ. i have a half functional tile renderer using shaders, so remaining work (which is more work) would be UI
Don't forget about animations! I thought about this briefly a while back but decided it wasn't worth the effort, although that was before I knew about the memory issue. One approach would be to replace just jgl.dll, the game's own little graphics library that was written by Firaxis for Civ 3 then never used for anything else as far as I can tell. JGL is a wrapper around Windows GDI. I don't believe it even handles animations on its own, though I'm not sure about that. I don't know much about how animations work, which is too bad since unit animations are likely one big reason the game wastes so much memory. Fun fact: jgl.dll has had a copy of libpng compiled into it and can load PNG as well as PCX textures. Unfortunately I couldn't see any way to take advantage of that from within Civ 3, as the EXE is hardcoded to only ever work with PCX.
 
Most improvement flags where it makes sense work cumulatively. However, there are still exceptions such as +1 Ship Movement and +2 Ship Movement. A special case is the Treasury earns 5% given to "Wall Street", but is limited to a maximum earning of 50 gold. In practice, this means that if you have one "Wall Street", you only need to keep 1000 gold in your treasury to maximize this effect. If you had two "Wall Streets", 5% becomes 10% and you only need to keep 500 gold in your treasury to maximize this effect. My point is that I find the 50 gold maximum earnings limitation to be OVERLY STRICT. As it stands, using this flag for multiple improvements is practically pointless and I'd like to change that. Therefore, I would suggest three things:
1) The option to set your own maximum earnings. (Possibility of removing it entirely via the -1 value, the default being 50.)
2) The option to set your own interest percentage. (The default being 5%.)
3) The option to increase this limit for each additional "Wall Street" built. (Which means that if the default value for 1 "Wall Street" is 50, for 2 is 100, for 3 is 150, etc.)
Points 1) and 2) shouldn't be too difficult in my opinion, since it should be a rewrite of one number in one place in the code.
I consider point 3) to be more challenging, so if it turns out to be something considerably more complicated, I would be perfectly happy with implementing points 1) and 2).

This further I assume is more something that would be done or expanded in the future using LUA, but I could be wrong. The "Wall Street" principle is simply the MORE money you have, the MORE you make. That's why I thought of expanding the economic complexity to include the following:
a) Add a bit of code to implement a possible INVERSE principle of the MORE money you have, the LESS you make. Which I also think shouldn't be a big deal, just tweak the equation for calculating earnings a bit, with it reaching maximum efficiency with a treasury at 0 gold and zero efficiency with a treasury over 1000 gold under current conditions of 5% interest and maximum earnings at 50 gold.
b) Add a bit of code to implement the principle of VARIABILITY/INSTABILITY of earnings depending on the SINE function. The adjustable value of the maximum earnings would actually mean the maximum amplitude of the function. Next, we would need to specify the second parameter and that is the period of the function. So under current conditions, the amplitude is 50 gold with the period set to 10000 gold:
- the treasury would earn 0 gold on 0 gold,
- the treasury would earn +50 gold on 2500 gold,
- the treasury would earn 0 gold on 5000 gold,
- the treasury would earn -50 gold on 7500 gold,
- the treasury would earn 0 gold on 10000 gold,
- the treasury would earn +50 gold on 12500 gold,
- the treasury would earn 0 gold on 15000 gold,
- the treasury would earn -50 gold on 17500 gold,
- the treasury would earn 0 gold on 20000 gold, etc.

c) Same as for b), but for COSINE. So under current conditions, the amplitude is 50 gold with the period set to 10000 gold:
- the treasury would earn +50 gold on 0 gold,
- the treasury would earn 0 gold on 2500 gold,
- the treasury would earn -50 gold on 5000 gold,
- the treasury would earn 0 gold on 7500 gold,
- the treasury would earn +50 gold on 10000 gold,
- the treasury would earn 0 gold on 12500 gold,
- the treasury would earn -50 gold on 15000 gold,
- the treasury would earn 0 gold on 17500 gold,
- the treasury would earn +50 gold on 20000 gold, etc.

d) If something like Sine/Cosine is too complicated, a function alternating linear increase and linear decrease would suffice for case b)/c).

Just for the record, all of the cases mentioned (growth, a) regression, b) sine, c) cosine, d) linear inc & dec) would still be triggered by the "Treasury earns 5%" flag, and only in the config file would you be told which "economic model" to use for which improvement instead of the standard growth.

This wouldn't be easy but it wouldn't be all that difficult either. The original logic for the doubling happiness effect isn't practical to modify. However it's inside of a relatively small function that could be entirely rewritten. That function's purpose is to sum the happiness from all buildings in a given city and it does that in a very straight forward manner.
If you're still actively keeping your list with suggestions, I hope you'll add it.

I think the hard part here would be knowing when to recompute city economies because a building may have been added or lost due to some weird rule. For example, if you want a wonder that adds an building to only enemy cities, it would be simple to modify the has_improvement function to check for that but you'd also have to make sure to recompute city happiness whenever wars started or ended to make sure the building appears when it's supposed to.
Isn't this something that's actually already partially happening? When war breaks out, it is common to lose active trades such as resources of luxury for money, which will inherently affect happiness in cities. In fact, the very act of war at the beginning will affect the happiness in cities and you don't even need to have an active trade to lose. I mean, I'm assuming that the game is already doing some checks the moment the diplomatic status between civilizations changes. Likewise, checks are made due to the change of ownership, becoming obsolete, or destruction of the city in which the wonder is located or to which the free improvement is given. So recalculations of the city economy also happen during such situations. I'm not quite sure what kind of WEIRD RULES you're referring to? For example, if barbarians took over a city, they are perhaps at war with everyone all the time. Or is the problem whether things happen when you're ON or OFF your turn?

Other than that, modifying has_improvement to consider additional conditions is no more difficult than programming those conditions anywhere else. E.g., if you want buildings to appear based on the surrounding terrain, the traits of the civ that owns the city, the distance to some other city, etc., that would all be pretty easy.
If it's that pretty easy, I'm surprised it hasn't been implemented yet. This is definitely not the first time I've heard of being dependent on the surrounding terrain or traits. Conditions with distance would be interesting again in relation to Allied/Hostile/Own cities.

I'm not sure what's going on here. The function to sum happiness from buildings doesn't directly limit unhappiness to that content citizen number, so it doesn't look like the developers programmed that specific rule you describe. I can see that the content citizens from difficulty does contribute to the happiness computation one level higher but I'd have to study the recompute_happiness method to figure out exactly what it's doing because it's surprisingly complicated.
I was wondering if maybe this could be a similar problem to calculating the overall culture in a city, where the order of improvements matters, and therefore improvements giving negative culture should be after improvements giving positive culture, so that everything is counted correctly, since the growth of culture in a city cannot be negative. (By the way, could something be done about the possibility of a declining culture?)

However, this is probably not the case. I tried adding unhappiness for a few basic improvements and the order in which either the happy or unhappy improvements were built didn't play a role and the results were correct, except of course those that fell below the number of citizens born content. It was also interesting to note that as the number of unhappy improvements increased, the explanatory notes "Some improvements in this city are annoying" and "Some improvements in another city are annoying" in "Unhappiness Causes" kept increasing, so this part of the code obviously records something well, it's just not interpreted correctly on the citizens of the city.

I think there's no doubt that something isn't working quite right here probably because it hasn't been properly tested. If I had to guess, I'd say it would have to do with some constraint on natural numbers, since city size can't be non-positive. I think it's definitely something worth revisiting at some point if not now. But I don't really know how many other people have experience with this problem and how much demand there is to solve it? (Hello, anyone?)
 
Hello Flintlock, I still have a lot of fun with your great mod.

Today I tried the "Barbarian city" option in your mod. I created a CCM 3 Debug biq and set the Barbarian option in the scenario config file of R20 to true in the hope to see now at least one Barbarian city on the randomly created map.

Barbarian activity was enabled and the game was started. Unfortunately my hope did not come true. There was no Barbarian city on that map, even after several turns. When I added a Barbarian settler on the map, that settler did not found a city. At least the Barbarian settler was not disbanded by the game.
Shame it couldn't work, seems like a really cool concept
 
Most improvement flags where it makes sense work cumulatively. However, there are still exceptions such as +1 Ship Movement and +2 Ship Movement.

This, and also for consideration: it would be nice if the defensive Combat Values for improvements could be cumulative.

However, this is probably not the case. I tried adding unhappiness for a few basic improvements and the order in which either the happy or unhappy improvements were built didn't play a role and the results were correct, except of course those that fell below the number of citizens born content. It was also interesting to note that as the number of unhappy improvements increased, the explanatory notes "Some improvements in this city are annoying" and "Some improvements in another city are annoying" in "Unhappiness Causes" kept increasing, so this part of the code obviously records something well, it's just not interpreted correctly on the citizens of the city.

The percentage on the explanatory notes measures how much of a percentage of the unhappy population are unhappy due to that reason, and this should always add up to 100%. It doesn't measure how much of the population of the city are unhappy vs not unhappy, nor does each reason necessarily have to be represented by a proportional amount of popheads - if only one popheads' worth of citizens is unhappy, but there are 3 reasons to be unhappy in that city, then 3 reasons of varying percentages will be given.
 
Flintlock updated C3X with a new update entry:

Release 21

New in this version:
- Allow perfume amounts to be specified as percentages
- Option to limit how many units can share each tile, named limit_units_per_tile
- Adjustable chance for max one HP units to be destroyed by nuclear strikes
--- Controlled by config option chance_for_nukes_to_destroy_max_one_hp_units
- Add limited_railroads_work_like_fast_roads option which does just that
- Option to allow sale of buildings like aqueducts that uncap population growth, named...

Read the rest of this update entry...
 
Back
Top Bottom