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

[Flintlock]

Flintlock updated C3X with a new update entry:

Release 19

New in this version:

• Option to stop pollution from appearing on impassable tiles
• Rework UnitRCMIcons.pcx so busy & combat units can be given special icons
• Fix bombers not doing stack bombard and not showing as attack-capable on right-click menu
• Fix crash when opening right-click menu with fleeing automated workers
• Fix lethal ZoC setting allowing coastal fortresses to knock the last hit point off passing units
• Fix dont_escort_unflagged_units option interfering with...

Read the rest of this update entry...

 

[Arexander]

That state works similarly to the states for worker actions. Workers with queued jobs only consume their movement to do the work when they're activated by the unit cycler, which visits them last after all the units that were idle at the beginning of the turn. So if you check in on a worker with a queued job before moving all your units, you'll see it's still unmoved for that turn, the same as a unit that's waiting to fortify. I wouldn't consider this a bug since it's working as designed. Arguably it should have been designed differently, but it's not like it's some mistake. It could have worked differently, the game processes every unit at the beginning of each turn to heal them, to sink galleys on ocean, etc. It could fortify the waiting units then but it's not programmed that way.

But it doesn't work, though. I let the units be for the whole next turn, and instead of fortifying at the end, they just popped up normally after all the other units were done, just like an idle unit would. So it didn't even fortify them. And technically there's no issue with them not fortifying at the start of the turn, since no-one's going to attack them anyway on your turn, whereas healing them at the start makes sense since you might want to use them to attack instead.

 

[Erlend Philip Wood]

But it doesn't work, though. I let the units be for the whole next turn, and instead of fortifying at the end, they just popped up normally after all the other units were done, just like an idle unit would. So it didn't even fortify them.

Arexander is right. Like he said in an earlier post, the units that are out of movement does not fortify on the next turn. They wake up idle instead. So it would be better if "Activate" was swapped for "Idle". Right now it looks like the units have fully fortified on the turn before they regain their movement, which isn't true. Being fortified carries with it certain defensive bonuses, and the units wouldn't wake up by themselves then.

Another solution would be to make the units actually fortify on the next turn, but that might be more complicated and perhaps not worth the extra effort.

 

[Flintlock]

But it doesn't work, though. I let the units be for the whole next turn, and instead of fortifying at the end, they just popped up normally after all the other units were done, just like an idle unit would. So it didn't even fortify them.

I see. I thought you were saying they just don't fortify at the beginning of the next turn. For some reason I thought the game let you fortify units with no moves left using fortify all, but you're right, that doesn't work. So I'm not sure what state 34 is for. Looking through the method that actually puts units in given states, it assigns state 34 instead of the requested state whenever the target unit has no moves, the game mode is not online MP, and the requested state is not any of the auto-bombard ones. The code for fortify all doesn't ask for state 34 directly, that's just what it gets by trying to fortify exhausted units. I don't know if there's any other way than fortify all to put a unit in state 34.

The method that makes units work, basically what the game runs when the unit cycler picks a unit, doesn't do anything for state 34. It simply resets the unit to idle. Because all I have is decompiled code, I can't tell if that was programmed explicitly or if it was just the default catch all case for units that don't match any of the states with real work to do.

By the way, I figured out state 33. It's auto precision strike.

Another solution would be to make the units actually fortify on the next turn, but that might be more complicated and perhaps not worth the extra effort.

The code modification would be easy, I'd insert a bit of code that runs before the work method to fortify any units in state 34. The problem is that might break something if anything else uses state 34. I could search for any other uses by checking every call to the state setter method, but there are 196 calls, so it would take a while.

 

[bacchant]

At the risk of sounding nit-picky or ungrateful...
Is it possible for an updated patch to incorporate any changes already made to the previous config?

BTW, thanks for the update. Gonna give it a spin in a few.

 

[Flintlock]

Is it possible for an updated patch to incorporate any changes already made to the previous config?

The easiest solution here would be to allow for a third config. That way you could put your changes there and copy the file over to each new version. You can already do the same sort of thing using a scenario config, but of course that's not convenient when playing a scenario that already has its own config.

 

[Erlend Philip Wood]

bacchant said:

Is it possible for an updated patch to incorporate any changes already made to the previous config?

The easiest solution here would be to allow for a third config. That way you could put your changes there and copy the file over to each new version.

What if we just append all the new options in each release to the very end of the config? Like this:


; RELEASE 18B =======================================================================================

; Removes barracks/harbor/airport requirement from upgrades
allow_upgrades_in_any_city = false

; Stops the game from placing volcanos during map generation. Any tiles that would have been volcanos will be mountains instead.
do_not_generate_volcanos = false


; RELEASE 19 =======================================================================================

; Stops the game from placing pollution on impassable tiles
do_not_pollute_impassable_tiles = false


Then it would be easy to just copy what's new, and paste it to the end of the existing Default.cfg and Scenario.cfg. For example, if you already have R16 installed, and upgrade to R19, then you can just grab the sections from R17 to R19 and then you're done.
As it is now, the full files have to be compared side by side, then the process must be repeated for Scenario.cfg. Since the configs are getting increasingly complex, it's easy to make a mistake. A simplification of the process would be appreciated.

 

[bacchant]

What if we just append all the new options in each release to the very end of the config? Like this:

Then it would be easy to just copy what's new, and paste it to the end of the existing Default.cfg and Scenario.cfg. For example, if you already have R16 installed, and upgrade to R19, then you can just grab the sections from R17 to R19 and then you're done.
As it is now, the full files have to be compared side by side, then the process must be repeated for Scenario.cfg. Since the configs are getting increasingly complex, it's easy to make a mistake. A simplification of the process would be appreciated.

I like this idea, then no matter what version you're upgrading from, it's just a simple copy/paste (after backing up the original version, of course). If you change a previous entry, maybe a simple warning on the download page so we know to copy over it.

And now the probable stupid question: what's the Scenario.cfg for? I've only paid attention to the Default.cfg.

 

[tjs282]

The scenario configs allow you to have different patch-settings for mods than you're using in e.g. the epic game.

For example, if you're playing the Napoleonic Conquest, no-one can build Settlers -- so you might want to turn on the NoRaze option just for that scenaro, while continuing to allow razing when playing with other .biqs where Settlers are available to build (and razed towns can therefore be replaced).

 

[SG52]

As far as I know, most diplomatic decisions are entirely governed by the principle of randomness and there is no deeper calculus yet. So I was wondering about adding complexity to AI warfare and if it would be possible to add subcategories to warfare. Subcategories like defensive war, allied war, attrition war, offensive war, total war, and so on. These categories would decide the type of troops (land, sea, air, (HNs, Cruise Missiles, Nuclear Weapons)) deployed in a certain territory (own, allied, enemy, no one).

I know, maybe that sounds too ambitious and it would take a lot of work to implement a lot of rules associated with it that I'm not even aware of at the moment. Rules like under what conditions to switch from one kind of war to another based on variables like total number of cities. total productive power, total number of troops, scientific advancement, cultural maturity, aggressiveness of civilization, aggressiveness of government type, mutual civilization annoyance, total casualties during conflict, and so on. In other words, lots of data that I don't even know if the game itself records in order to refer to it for decision-making functions. I would imagine the functioning of the proposed war categories to be something like this:

Defensive war: allows deployment of all types of units only in one's own territory + a maximum of 10 tiles from one's own borders into no-man's territory.
Allied war: allows the deployment of all types of units only on own and allied territory + a maximum of 10 tiles from own borders into no-man's territory.
Attrition war: allows the deployment of all types of units only in own and no-man's territory + allows the deployment of naval and air forces only in enemy territory.
Offensive war: allows the deployment of all types of units only in own, no-man's and enemy territory.
Total war: allows the deployment of all types of units in any territory.

These categories would, of course, work independently of the algorithms for building towns, scouting or fighting barbarians. Likewise, there would be some understandable exceptions; for example, in a defensive war, the defending side would attempt to recapture captured cities that were then in enemy territory. For simplicity's sake, it would be enough for the time being that military superiority is the decisive factor in waging war. Thus, if I have more troops (+10) than my opponent, I choose offensive war, if not, I choose defensive war. If I am drawn into a conflict through a military alliance or mutual protection pact, I choose allied war. If, in addition, I have military superiority (+25) over our common adversary after accounting for the military strength of the ally, I choose attrition warfare. If the conflict has been going on for a long time, relations are terrible, and I still have military superiority (+1) or at least production capabilities comparable to my opponent, I choose total war.

This is, of course, just a sketch of possible categories and rules, which would at best be at least partially configurable via a cfg file. I would appreciate any comments both positive and negative or any suggestions for improvement.

 

[Thorvald of Lym]

I love the concept; Civ4 differentiates between "limited" and "total" war, though I don't know the nuts and bolts of how the AI sets limited objectives.

Unfortunately this would probably require a summary rewrite of AI logic beyond what the game is designed to handle. You may want to pitch this to the C7 team.

 

[bacchant]

The scenario configs allow you to have different patch-settings for mods than you're using in e.g. the epic game.

For example, if you're playing the Napoleonic Conquest, no-one can build Settlers -- so you might want to turn on the NoRaze option just for that scenaro, while continuing to allow razing when playing with other .biqs where Settlers are available to build (and razed towns can therefore be replaced).

Ah, got it. I'm just playing around with the GUI editor for an epic game right now. But I can see wanting different configs in different situations. If you don't mind satisfying a newbies curiosity a bit more, how exactly does that work. I probably should just look for a readme or the Scenario config file for info, huh. I'm just involved in a fun playthrough and don't wanna take the time away.

 

[Flintlock]

What if we just append all the new options in each release to the very end of the config? Like this:
...
Then it would be easy to just copy what's new, and paste it to the end of the existing Default.cfg and Scenario.cfg. For example, if you already have R16 installed, and upgrade to R19, then you can just grab the sections from R17 to R19 and then you're done.
As it is now, the full files have to be compared side by side, then the process must be repeated for Scenario.cfg. Since the configs are getting increasingly complex, it's easy to make a mistake. A simplification of the process would be appreciated.

This would either break with the existing categories or require me to go back and figure out when each option was added to reorganize them all. I think the existing categories are useful, for example if someone wants to play with only the bug fixes. I see how it could be awkward to find what the new options are in each release, I usually put them at the end of each category but not always. Also I sometimes rename settings when changing how they work, but that's rare. An easier solution to that problem would be to note every added option in the changelog. I'll try to remember to do that.

As far as I know, most diplomatic decisions are entirely governed by the principle of randomness and there is no deeper calculus yet. So I was wondering about adding complexity to AI warfare and if it would be possible to add subcategories to warfare. Subcategories like defensive war, allied war, attrition war, offensive war, total war, and so on. These categories would decide the type of troops (land, sea, air, (HNs, Cruise Missiles, Nuclear Weapons)) deployed in a certain territory (own, allied, enemy, no one).

Unfortunately this is much easier said than done. So far I know very little about the code that governs the AI's internal decisions. I don't know if it even makes any strategic decisions at all. As far as I've seen it simply marches its units toward the nearest enemy. "Operations" like naval landings are very basic, units will load onto a transport if they just so happen to be in the same city as one and have nothing better to do. Adding in strategic decision making from scratch would be a lot of work since it would touch so many different things. I often think about replacing the unit AI but that's still far off in the future if it ever happens.

If you don't mind satisfying a newbies curiosity a bit more, how exactly does that work. I probably should just look for a readme or the Scenario config file for info, huh.

It is in the readme, but to sum it up: you put a file named scenario.c3x_config.ini in the scenario's search folder and in that file specify the settings you want to change just for that scenario. Here's a little demo: https://forums.civfanatics.com/thre...rd-and-much-more.666881/page-28#post-16212316

 

[dark_pretender]

Hello Flintlock, just to say thanks for fixing the stack bombardment on the bombers, (havent had the opportunity to test it yet, since I just started a new game.)

Not being ungrateful, nor picky, but I tried to change the option that shows the action the unit is performing, but even after setting it up as false, its not working, it keeps showing the unit as "moving, building road, mining" etc. I have even tried removing the modded exe, and patching again the unmodded one, but for some reason it doesnt work. Below how the option looks in my config file (just changed the word true for false) I understand that if this option is set to false, it should show the unit as activate or wake right?

; Replaces the "Wake" or "Activate" text on the right-click menu with more descriptive words indicating what the unit is currently doing. For example,
; "Moving", "Intercepting", or "Working".
describe_states_of_units_on_menu = false

The sword and "led" icons, work great! thank you very much again for all your great work and the effort you are doing in this mod..

 

[bacchant]

This would either break with the existing categories or require me to go back and figure out when each option was added to reorganize them all. I think the existing categories are useful, for example if someone wants to play with only the bug fixes. I see how it could be awkward to find what the new options are in each release, I usually put them at the end of each category but not always. Also I sometimes rename settings when changing how they work, but that's rare. An easier solution to that problem would be to note every added option in the changelog. I'll try to remember to do that.

Anything that reduces having to pour thru each new config would be appreciated. Before you mentioned maybe having a third (config?) file would accomplish this. Could you explain that a little more. I didn't quite grasp what you meant (too few brain cells due to age and, umm, other things).

It is in the readme, but to sum it up: you put a file named scenario.c3x_config.ini in the scenario's search folder and in that file specify the settings you want to change just for that scenario. Here's a little demo: https://forums.civfanatics.com/thre...rd-and-much-more.666881/page-28#post-16212316

Thanks for that. It'll make things much easier once I get around to trying Conquest's scenarios or other mods.

 

[Flintlock]

I tried to change the option that shows the action the unit is performing, but even after setting it up as false, its not working, it keeps showing the unit as "moving, building road, mining" etc. I have even tried removing the modded exe, and patching again the unmodded one, but for some reason it doesnt work.

Man, I have been making so many sloppy mistakes recently. This is another little bug, I must have accidentally deleted the check for that config setting or maybe I never even remembered to add one to begin with. It's a trivial fix. It requires inserting a single line, so you can easily patch the mod yourself if you care to. Just insert the following code:

if (! is->current_config.describe_states_of_units_on_menu) return false;

on line 9365 of injected_code.c, which is the first line of the function get_menu_verb_for_unit.
In other words, modify this part of injected_code.c:

bool
get_menu_verb_for_unit (Unit * unit, char * out_str, int str_capacity)
{
    struct state_desc {
        enum c3x_label label;
        bool is_doing_worker_job;

so it looks like this:

bool
get_menu_verb_for_unit (Unit * unit, char * out_str, int str_capacity)
{
    if (! is->current_config.describe_states_of_units_on_menu) return false;
    struct state_desc {
        enum c3x_label label;
        bool is_doing_worker_job;

Anything that reduces having to pour thru each new config would be appreciated. Before you mentioned maybe having a third (config?) file would accomplish this. Could you explain that a little more.

Sure, my idea for the third config is that it would be another config file you could drop in the C3X folder that would get loaded after the first one or two configs in all games. The way config files work is that they are layered on top of one another. The default config has all the options listed because it's a reference for what's possible, but config files don't have to do that. In a scenario config you only have to include the options you want to change. Anything the scenario config doesn't set will be left as it was in the default config.

The third config would come after the default and scenario configs and again you could include there only the settings you want to change. In fact you wouldn't need to modify the default config at all, just put your changes in the third config. Then when moving to a new version of the mod, you would simply copy over the third config file to the new folder. Old config settings almost always work with newer mod versions, I think I've only once or twice had to break backwards compatibility over 19 versions and 3.5 years.

 

[bacchant]

Sure, my idea for the third config is that it would be another config file you could drop in the C3X folder that would get loaded after the first one or two configs in all games. The way config files work is that they are layered on top of one another. The default config has all the options listed because it's a reference for what's possible, but config files don't have to do that. In a scenario config you only have to include the options you want to change. Anything the scenario config doesn't set will be left as it was in the default config.

The third config would come after the default and scenario configs and again you could include there only the settings you want to change. In fact you wouldn't need to modify the default config at all, just put your changes in the third config. Then when moving to a new version of the mod, you would simply copy over the third config file to the new folder. Old config settings almost always work with newer mod versions, I think I've only once or twice had to break backwards compatibility over 19 versions and 3.5 years.

If you could bear with me, I still have a couple of questions:

To daisy-chain in a third config, wouldn't it need to be named something other than the default? Or do you simply mean we'd add the updated stuff to a config we've made with our changes, and copy over the default in the patch folder? Of course to do the latter, it'd be a lot easier to add the updates if we didn't have to pour thru the whole patched config, instead those changes being included (as lines for the config) in either the readme or, e.g., in a, gasp, third file -- did I just have an epiphany, or engage in circular thick-headedness?

 

[ZergMazter]

Would it be easy to make it so that when a player (Human or AI) plants a forest the LM forest terrain is used for plains and grass, and LM pines for tundra instead of the normal terrain?

I've managed to manipulate the AI into planting trees by manipulating the tile resource yield for cattle and horses. Having a tile with cattle and then planting trees makes it equivalent to irrigating cattle in normal civ 3 as far as resource yield. The point of this is purely aesthetic since I dont like the irrigation texture under the animals. I've also made a texture for the LM forests so that it looks like animal pens (See below).

The problem is since I cant force the game to plant a LM forest/pine I have to do it in reverse and It wont work when you create a randomly generated map. If I give animal pen texture to forests then the whole map will have pens instead of forests. To overcome this I have to give my texture to regular forests, custom make a map and replace all forests with LM terrain to retain the forest look, that way when the AI or myself plant forests on the tiles it looks like we encased the cattle in an animal pen. It's limited, time consuming, and annoying. I dont wanna have to do this with every map I wanna play.

 

[Flintlock]

To daisy-chain in a third config, wouldn't it need to be named something other than the default? Or do you simply mean we'd add the updated stuff to a config we've made with our changes, and copy over the default in the patch folder? Of course to do the latter, it'd be a lot easier to add the updates if we didn't have to pour thru the whole patched config, instead those changes being included (as lines for the config) in either the readme or, e.g., in a, gasp, third file -- did I just have an epiphany, or engage in circular thick-headedness?

That's right, the third config would be stored in its own file. I've been referring to it as the "third config" instead of its file name because I haven't decided on a name yet. Maybe "custom" dot c3x_config, or maybe "user" or "preferences". I'm not sure.

Would it be easy to make it so that when a player (Human or AI) plants a forest the LM forest terrain is used for plains and grass, and LM pines for tundra instead of the normal terrain?

Probably. I haven't looked into LM terrain myself but Antal decoded some things related to it, such as how the game tracks whether each tile is LM or not. It should be easy to figure out how to change LM status. I thought about doing something like this back when I was poking around the map generator, specifically creating plains hill tiles like in Civ 4. If the only point is to change the appearance of irrigation on tiles with cattle or horses, that could probably be done more easily by directly swapping to a special irrigation texture for those tiles.

What I really want to do, for requests like this, is to get Lua scripting working in the game. Ideally you could insert or modify a little Lua script to change how tiles appear. That way you could make them look however you want based on any arbitrary criteria. If I were to add this right now, it would have to be controlled by a config setting, which wouldn't allow for much flexibility.

 

[dark_pretender]

Hello Flintlock.

Awesome, I applied the changes, and now its working correctly!

Thank you very much!!