Resource icon

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

Another suggestion to help modding city defenses would be to change the hardcoding making improvements with land bombard value disappear when the town becomes a city. This way, you can have "walls" that have land bombard values and absorb bombardments until hit and destroyed and "citadels" like the stock game Civil Defense that will only be targeted first by artillery after all the defenders have been redlined.
There's also the, "Doubles City Defenses" GW Flag - and defending in a City already gives you a 100% defense bonus.
 
There's also the, "Doubles City Defenses" GW Flag - and defending in a City already gives you a 100% defense bonus.
I'm not quite sure what that flag does. Does "city defenses" include the bonus received by being a city and metro besides city improvements?
 
Quick bug report concerning the no trespassing option:

It is still possible to attack an enemy unit inside someone else's territory without a RoP. When you do so and win the battle, the attacking unit will move halfway between the two tiles and stop in between, still with a movement point (this unit moves 1 tile/turn). You can then move the unit back to its original square. Very strange behavior I have not yet seen in this game! :crazyeye:

Thankfully, it does not cause a crash or otherwise disrupt gameplay.

Also, there does not seem to be an issue with placing units in the editor inside another civ's territory, as long as they are on the border and can move into an friendly, neutral, or enemy-controlled square, or I suppose can sign a RoP.

Lastly, hidden-nationality and invisible units can go wherever they please.
 
Last edited:
I'm not quite sure what that flag does. Does "city defenses" include the bonus received by being a city and metro besides city improvements?
Yes. You get a 100% bonus for being in a Metropolis and another 100% for that Flag.

Most combat seems to take place at a ratio of about 3:2. The CRT ("Combat Results Table") is geared to the "common wisdom" (since WW2) that it takes a ratio of about A:D ratio of 3:1 to prevail in an attack. Looking at the CRT also makes evident why the infamous " :spear:" sometimes occurs.
 
Great stuff! With regards to adding new attributes to Improvements (and Wonders), how tedious would it be to add e.g. "Increases Shields in Land Tiles" (+1 shields on land), "+1 Food in Every Food Producing Tile", etc. just to add a bit more variation to the improvement and wonder attributes?
Thanks. Simply adding some extra yield to tiles would be relatively easy but not trivial. Adding yields only for tiles that are already producing some would be difficult, unfortunately. The problem here is the despotism penalty. I've already located the base game function that computes tile yields and it accounts for the penalty internally. That means I can't simply modify it to tack some yield on after the computation since it would have no way of determining if that additional yield is supposed to be lost to the penalty. The solution is to add the yield in the middle of the function, which is possible with a bit of work, except then I wouldn't be able to make that additional yield depend on the tile's base yield, since that wouldn't have been determined yet, at least not at the location that it's easy to modify. This could be made to work anyway with some custom machine code edits, but it's surprisingly difficult for such a simple modification.
It is still possible to attack an enemy unit inside someone else's territory without a RoP. When you do so and win the battle, the attacking unit will move halfway between the two tiles and stop in between, still with a movement point (this unit moves 1 tile/turn).
I'll have to look into this, thanks for reporting it. I remember there was a similar issue with hidden nationality units. I didn't exactly solve it, or even look into what caused it, I dodged it by deciding to exempt HN and invisible units from the trespassing restriction. We discussed it in this thread and several other modders asked for the exemption since those kinds of units are intended to be able to operate behind enemy lines.
 
Thanks. Simply adding some extra yield to tiles would be relatively easy but not trivial. Adding yields only for tiles that are already producing some would be difficult, unfortunately. The problem here is the despotism penalty. I've already located the base game function that computes tile yields and it accounts for the penalty internally. That means I can't simply modify it to tack some yield on after the computation since it would have no way of determining if that additional yield is supposed to be lost to the penalty. The solution is to add the yield in the middle of the function, which is possible with a bit of work, except then I wouldn't be able to make that additional yield depend on the tile's base yield, since that wouldn't have been determined yet, at least not at the location that it's easy to modify. This could be made to work anyway with some custom machine code edits, but it's surprisingly difficult for such a simple modification.
Thanks for the reply. So basically adding new attributes that give flat yields would be somewhat trivial (e.g. "Increases Shields in Land Tiles by +1"), but then the more conditional ones are a bigger headache (e.g. the "+1 Food in Every Food Producing Tile") and might not be worth the hassle really.
 
@Flintlock You my friend, and you alone are responsible for getting me playing again civ 3.

I became so addicted that I start making some mods that I will soon release.

Thanks for your work.

Especially the feature that AI actually use and attacks you with artillery units.

Now you can be very profitable at war times since, if you play tactical and smart you can capture a lot of catapults and get slaves for free.

Keep it up.
 
I have a question, when its said the 31 civ limit can't be removed does that mean how many civs can exist simultaneously on a map, or would it be possible to have more than 31 civs while still observing the normal map size number of players, say in a custom game. Or in other words, increasing the pool of civs that have a chance at being spawned into a game.

Apologies if this has been answered already, I didn't find an answer to this exact question across the forum.
 
@Flintlock You my friend, and you alone are responsible for getting me playing again civ 3.
I became so addicted that I start making some mods that I will soon release.
Glad to hear it! And I'll keep an eye out for those.
I have a question, when its said the 31 civ limit can't be removed does that mean how many civs can exist simultaneously on a map, or would it be possible to have more than 31 civs while still observing the normal map size number of players, say in a custom game
When I talk about the 31-civ limit I'm usually thinking of the number of players in a game rather than the number of civs available to choose from. Removing the limit on available civs would be easier, but still probably would not be practical. One of the challenges there is that the scenario format itself assumes a 31-civ limit. For example, the availability of each unit type to each civ is stored in 32-bit segments inside the unit type objects. The size of those segments is fixed so the availability bits for the extra civs would have to be stored elsewhere. I can think of various ways to do that but all come with downsides:
1. Store the extra bits somewhere else in the BIQ file -- assuming I could find a suitable place, this would require the use of a third-party editor.
2. Specify extra availability info in another file separate from the BIQ -- this would be awkward to edit & keep in sync with the BIQ itself.
3. Use two BIQ files with the same rules but different selections of civs, the mod could present all the civs across both files as options to choose from then merge the ones that were actually chosen into a single BIQ for the game & save file. -- I expect this would be difficult to implement, and prone to bugs.
And this is all just for unit type availability, there are probably other ways that the 31-civ limit is baked into the format that I don't know about. It's fun to think about removing that limit but I doubt it's something I could do.
 
did a quick search to see if anyone's mentioned this and didn't find anything

I wonder how easy it would be to implement attack bonuses/maluses between different units. Something like listing a "unit type" in the config for particular a unit and maybe specifying a multiplier for combat between unit types.

eg:

["Panzer IV": "Medium Tank", "Bazooka": "Anti Tank"]

where units are specified as a type, and

["Medium Tank": "Anti Tank" 0.75]

where a multiplier is specified for combat between types. Here, the combat value of units with the "Medium Tank" flag are multiplied by 0.75 when in combat with the listed unit type ("Anti Tank").
 
Can it be possible to modify a land unit that can transport other land units that the AI can use? And maybe it uses naval transport AI as a template....
 
Can it be possible to modify a land unit that can transport other land units that the AI can use? And maybe it uses naval transport AI as a template....
I am not quite clear about what you mean by "uses navel transports AI as a template" but Yes, you can do that. The main problem is that the AI Does Not use ANY land transports. Good for Players but not the AI :(
 
I am not quite clear about what you mean by "uses navel transports AI as a template" but Yes, you can do that. The main problem is that the AI Does Not use ANY land transports. Good for Players but not the AI :(
I was asking Flintlock if the code for the .exe could be changed to accommodate this.
 
@Flintlock I have a question to make.

Is it possible for you to edit the visibility range?

Outposts have visibility range of 2. Is it possible when they are build on a hill to gain 1 more point of visibility and when build on a mountain gain 2 more points?

Something similar happens when a unit climb a hill, it gain visibility, so it does when climb a mountain.

Also is it possible artillery units gain +1 range bombardment when located on hills and +2 when on mountain?
 
Last edited:

It appears that war weariness is bugged. In single player a war between two AIs means that the AI later in the turn gets all the ww points that either of the 2 civs should get. In PBEM the same bug seems to apply to wars between 2 human players.
 

It appears that war weariness is bugged. In single player a war between two AIs means that the AI later in the turn gets all the ww points that either of the 2 civs should get. In PBEM the same bug seems to apply to wars between 2 human players.
Does that mean that the AI's unhappiness rises far faster than it should? WW is already very destructive to the AI because it tries to hold on to representative gov while putting half its citizens on being entertainers.
 
Does that mean that the AI's unhappiness rises far faster than it should?
Well, the AI earlier in the turn order gets no WW points from the war and thus no war weariness. The AI later in the turn gets the WW points that it should get and the WW points its enemy should get on top of that. So for the later AI maximum WW is reached faster and switching to fascism etc. will occur as AI deems that to be preferable to high WW.

The bug is simply outright unfair.

PS: It is possible that i am not correctly describing the bug or that what i described as one bug are actually two seperate bugs. It is well known that it is bugged, but less clear how exactly it is bugged.
 
I deliberately programmed it so that buildings won't generate a resource that is still hidden behind a technology requirement. I'm curious, is that how you expected/want it to work? Because I could change it if most modders would prefer that buildings can generate resources before they're revealed by tech. I recall that's what @Civinator preferred, at least at first, when we discussed this back when I was first working on it. I added the tech restriction because in all the examples I could think of, it made sense for a resource to be harvested/mined first before it could be generated artificially.

I didn't know you wanted to use the tech requirement to prevent trading of generated resources. It's not difficult to add an option to avoid the requirement so I'll go ahead and do that for R13. I could even do it on a per-resource basis, though I don't like how complicated the config file format is becoming.
I think your solution to this is great! I can absolutely see use-cases for both the no-tech-prereq and the tech-prereq options.

I hope this isn't too off topic. But is the resource in city radius requirement in the editor mean that the resources have to be connected to that city by roads? I'd like to make the offshore platform generate stock game oil if it has an "offshore oil" in its radius. This "offshore oil" shall be a strat res spawning water terrain.
The city does not have to be connected to the instance of the resource within its radius. It just has to get the resource from somewhere, and the resource needs to exist within the radius. But those two can be different sources. :D Still, that's a very niche functionality, and not useful for your use-case, as you'd then still need to get sea-oil to the city from some other (land) source to qualify for the building.

Speaking of that replace flag and perfumed powerplants. Has anyone tested how the AI would behave with 2 powerplants heavily perfumed? I'm afraid they'd be trapped in a circle of rebuilding them over and over.
I am wondering the same! Since AIs sadly don't value prod +% at all it seems, a lot of perfume is necessary. It would be amazing if we could get some conditional scripting logic for unit/building choice values, such as
Code:
Coal Plant
{
    if (has researched "Electronics" or has researched "Nuclear Power") and has river or has researched "Ecology"
        value = 0
    else
        value = 200
}

Nuclear Plant
{
    if has "Coal Plant"
        value = 150
    else if has "Hydro Plant" or as "Solar Plant"
        value = 100
    else
        value = 200
}
But that would of course be some immense work, probably unfeasible. :D


@Flintlock I have a question to make.

Is it possible for you to edit the visibility range?

Outposts have visibility range of 2. Is it possible when they are build on a hill to gain 1 more point of visibility and when build on a mountain gain 2 more points?

Something similar happens when a unit climb a hill, it gain visibility, so it does when climb a mountain.

Also is it possible artillery units gain +1 range bombardment when located on hills and +2 when on mountain?
Outposts already have a vision range of 1 on ground, 2 on hill and 3 on mountain, no? What IS strange about them, however, is how they don't gain any extra LOS when looking at water, unlike normal units.

@Flintlock
A while ago I asked about having ground-AA play its attack animation rather than the generic one when it destroys an air unit. No rush about this at all, I don't think anyone but me asked for this. But I have another idea to add to this: Would it be possible to make ground AA use "operational range" to be able to cover more than its own square? Then basic AA with an operational range of 0 could defend only its tile, while SAM systems could be given a 1 to also cover the surrounding tiles and highly sophisticated and potentially stationary end-game AA could even cover another ring around this. Could be really cool for cold war or modern day scenarios. :D

Edit: And another tiny request: Can you add an option to stop agricultural from being exempt to the despotism penalty if the city has fresh water? It seems very inconsistent that only this particular combination of conditions simply ignores the despo tile penalty.
 
Last edited:
I think your solution to this is great! I can absolutely see use-cases for both the no-tech-prereq and the tech-prereq options.


The city does not have to be connected to the instance of the resource within its radius. It just has to get the resource from somewhere, and the resource needs to exist within the radius. But those two can be different sources. :D Still, that's a very niche functionality, and not useful for your use-case, as you'd then still need to get sea-oil to the city from some other (land) source to qualify for the building.


I am wondering the same! Since AIs sadly don't value prod +% at all it seems, a lot of perfume is necessary. It would be amazing if we could get some conditional scripting logic for unit/building choice values, such as
Code:
Coal Plant
{
    if (has researched "Electronics" or has researched "Nuclear Power") and has river or has researched "Ecology"
        value = 0
    else
        value = 200
}

Nuclear Plant
{
    if has "Coal Plant"
        value = 150
    else if has "Hydro Plant" or as "Solar Plant"
        value = 100
    else
        value = 200
}
But that would of course be some immense work, probably unfeasible. :D


Outposts already have a vision range of 1 on ground, 2 on hill and 3 on mountain, no? What IS strange about them, however, is how they don't gain any extra LOS when looking at water, unlike normal units.

@Flintlock
A while ago I asked about having ground-AA play its attack animation rather than the generic one when it destroys an air unit. No rush about this at all, I don't think anyone but me asked for this. But I have another idea to add to this: Would it be possible to make ground AA use "operational range" to be able to cover more than its own square? Then basic AA with an operational range of 0 could defend only its tile, while SAM systems could be given a 1 to also cover the surrounding tiles and highly sophisticated and potentially stationary end-game AA could even cover another ring around this. Could be really cool for cold war or modern day scenarios. :D

Edit: And another tiny request: Can you add an option to stop agricultural from being exempt to the despotism penalty if the city has fresh water? It seems very inconsistent that only this particular combination of conditions simply ignores the despo tile penalty.
I wrote plus 1 for hills and plus 2 for mountains.

As you correctly wrote, hills get visibility of 2 so my question is if he can modify the game to use visibility of 3 for hills and 4 for mountains (or as many visibility tiles we want, ex. visibility 3 for hills and 6 for mountains).
 
Back
Top Bottom