Resource icon

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

Just spitballing here, but could you make the AI infinitely value them in trade negotiations? That would at least take care of single player.


That was the reason I asked about bombardment + collateral damage on a whole stack


...but I forgot about that part. Charm is a separate action from bombard though, right? Meaning I cannot have a unit charm a stack by/while bombarding it.

A unit can not bombard and charm bombard at the same time. If you tick charm in the editor, it will always halve the defense stats of all the units on a tile. But no HP loss will occur.
 
Do you guys want the stack limit to apply to cities or not? Just asking as an informal poll. I added the exemption for cities because, first, I'm not planning on modifying unit creation to handle the limit so cities could still violate the limit by building units, second, it stops land, sea, and air units from crowding each other out, and third, it probably helps the AI with loading up transports. But if it's what people want, I could easily make the stack limit apply to cities. They're exempted right now by literally two lines of code (here: https://github.com/maxpetul/C3X/blob/Release_21_Preview_1/injected_code.c#L4423) so it's trivial to change. I could even add that as another option if opinions are split. I'm also considering making the limit apply separately for each class of unit: land, sea, and air, so they don't conflict with each other.

I see that it appears that you have no knowledge of shore-based underwater listening stations monitoring submarine and surface ship movement. The US has a large network of underwater listening stations both near shore and in deep water. A number of other nations have them as well. They have been around since the 1970s. Other monitoring options are magnetic cables looking for metal passing near them, although those as primarily shallow water stations. As for ships monitoring shore activities, the use of small drones relaying TV images to the ships is now fairly common. If you have that as an option to be turned on or not, that is not a problem. If it is automatically turned on, and has to be manually turned off, that would be a problem.
A land-based submarine detection station would be better simulated in Civ 3 by a radar tower than a unit, except radar towers don't detect invisible units. Maybe they should. I thought they did for some reason and only discovered they don't while testing that change. It would make sense for surface ships to be able to detect invisible units on nearby land tiles, but not submarines, but that's awkward to implement since the game doesn't already have a distinction between surface and submarine sea units. In any case, the option stopping cross-shore detection is off by default, like all options that change the game rules.

We finally have a limit to the SOD problem. Civ4 counters SODs having collateral damage. Is there a way to implement that? Charm bombard does target every unit in the stack but instead of bombarding normally it halves the defensive value. Unfortunately charm bombard units don't bombard cities and it can only happen once a turn so the AI has no clue how to use it. But what if the charm targeting of all the units on the tile could be changed into regular bombardment?
I could probably figure out some way to do that since I have the bombard logic pretty well mapped out. I don't think adapting the charm bombard logic would be the best approach since it's a separate path from the one for regular bombard. It's better not to go down that path at all than try to modify it into something completely different. The easiest approach is probably to tack some additional code onto the end of the regular logic that does some extra combat rounds attacking other units on the tile. The hard part would be making sure the animations play correctly.

Just spitballing here, but could you make the AI infinitely value them in trade negotiations? That would at least take care of single player.
Well, I wouldn't know how to do that either. I would have to look deeper into the trade logic to figure out what's the easiest approach here. So far I've only really decoded the logic for the trade screen for the gold amount autofill and display of untradable techs features.

If a unit uses both types of roads during its movement in one turn, then a problem with the movement indicator may occur.
Thanks for the bug report. I'll look into it.

Also, workers who build improvements on a tile (roads, mines, irrigation, forts) do not allow other units to enter it. Is it possible to make an exception for all units working on a tile, or for a pre-defined list of units (engineers, workers or slaves)?
Sure, I could implement any rule within reason for the stack limit. Again, the most general solution is to have the limit be determined by a little Lua script.
 
A unit limit to cities could be good. The AI issues where sometimes it's artillery stack will be stuck there. In my test game it was a prime target for a tactical nuke. An exciting late game showdown ended by AI artillery technical difficulties and the overpowered nature of a very cheap 300 shields nuke wiping out 20 or more units.

But what happens if the AI is already at the limit and wants to produce troops? Better to have it as a separate option to test. We're still in the process of testing how the regular unit limit works out in gameplay.
 
Do you guys want the stack limit to apply to cities or not? Just asking as an informal poll. I added the exemption for cities because, first, I'm not planning on modifying unit creation to handle the limit so cities could still violate the limit by building units, second, it stops land, sea, and air units from crowding each other out, and third, it probably helps the AI with loading up transports. But if it's what people want, I could easily make the stack limit apply to cities. They're exempted right now by literally two lines of code (here: https://github.com/maxpetul/C3X/blob/Release_21_Preview_1/injected_code.c#L4423) so it's trivial to change. I could even add that as another option if opinions are split. I'm also considering making the limit apply separately for each class of unit: land, sea, and air, so they don't conflict with each other.
I don't know yet. If anything probably a separate option for cities. Logically, fewer units would be able to cram into a city than open land, but that's a whole other can of worms for gameplay. (That is, assuming this is simulating physical maneuvering space and not say, supply logistics...)

Results so far:

Fundamentally it's working. I like that pathfinding handles it seamlessly. Maybe a message banner to the effect of "this tile is fully occupied" would be helpful if you try to order another unit into it.

Unlimited units can load into transports but can only be unloaded up to the limit even if by "unload all", which I suppose is what I'd expect. That's a case where a message would be really helpful because it's not obviously that the order did not complete.

Unlimited air units can rebase onto an airfield, but no land units can enter it once there are too many air units. So maybe that's an argument for separate limits per class, or just ignoring air units entirely.

Likewise unlimited units can airlift into an airbase, but not airdrop.

Units can retreat into a full tile.

Units can only attack a full tile as a surprise attack! Once at war, the stack cannot be attacked. :ack:
 
Last edited:
I'm afraid the PTW targeting issue still remains.

The AI will also not use artillery units that require an escort if that unit hasn't been assigned an escort yet. They wouldn't just not move out, but also not fire on enemies within their range. It seems like the best way for the AI to use the Artillery Flag is to have them not require any escort and then disable the escorting function in the config patch. But that would leave them unprotected. That works well with cruise missile type units esp if you have them move fast. But for artillery pieces, the only thing I can think of is to combine the defense stats and cost of a contemporary defender with the bombardment unit, quite a departure from stock game.
 
Last edited:
But what happens if the AI is already at the limit and wants to produce troops? Better to have it as a separate option to test. We're still in the process of testing how the regular unit limit works out in gameplay.
In that case, the unit would simply get produced like normal, violating the stack limit. I'll probably add an option about whether or not to apply the stack limit to cities just because it's so easy. Maybe I won't if everyone's in agreement one way or the other.

Fundamentally it's working. I like that pathfinding handles it seamlessly. Maybe a message banner to the effect of "this tile is fully occupied" would be helpful if you try to order another unit into it.
Unlimited units can load into transports but can only be unloaded up to the limit even if by "unload all", which I suppose is what I'd expect. That's a case where a message would be really helpful because it's not obviously that the order did not complete.
Unlimited air units can rebase onto an airfield, but no land units can enter it once there are too many air units. So maybe that's an argument for separate limits per class, or just ignoring air units entirely.
Likewise unlimited units can airlift into an airbase, but not airdrop.
Units can retreat into a full tile.
Units can only attack a full tile as a surprise attack! Once at war, the stack cannot be attacked. :ack:
Thanks for testing this. I had forgotten about retreating and airfields. I didn't restrict rebase missions because I thought that if they can only go to cities or carriers, there's no point. Totally forgot about airfields.
It might be difficult to add a little message saying the tile's full after a unit's been blocked from moving onto it. The stack limit applies relatively deep in the movement logic, where it's decided whether a move is allowed or not, so it might be hard to percolate that information upward to wherever the order to move came from.
I definitely should have thought that the stack limit might block attackers, oops. The reason sneak attacks still work is because moving onto a tile occupied by a foreign unit at peace is already sort of disallowed. Because the stack limit is only checked for fully allowed moves, it gets skipped there.

I'm afraid the PTW targeting issue still remains.
Is this on a new save or one created from before R21 Preview 1? The fix for the PTW targeting issue can't fix old saves because all the unit types in the embedded BIQ have already had their charm bombard bits cleared.
 
Something is happening with these 2 options below.... They cannot both be true. One of the other, or both have to be false or game crashes.


; Stops invisible units from being targeted by stealth attacks. They can still be targeted if they've been revealed by the attacking civ.
exclude_invisible_units_from_stealth_attack = true

; This option makes it so that only sea units with the "detect invisible" ability can reveal invisible sea units, and likewise for non-sea units.
no_cross_shore_detection = false
 
Last edited:
Something else... This one is not a big deal because it's working the way I have it in bold below, but I used to just write [all] with the brackets and have no issues, but it started to crash this time around until I changed them to what's shown here.


; A list of modifications to the rules for defensive bombard. "Defensive bombard" is the free shot a bombard unit gets when the stack it's in is
; attacked. The possible options are:
; lethal: Attackers may be destroyed by defensive bombard if the bombarding unit has the appropriate lethal land/sea bombard ability.
; aerial: Air units may perform defensive bombard if they can perform bombing missions.
; not-invisible: Attacking units are immune to defensive bombard if they are invisible and not detected.
; blitz: Units with blitz may perform defensive bombard multiple times per turn, once for each move they have.
; docked-vs-land: Docked ships (i.e. in a city) can perform defensive bombard against land units attacking their city.
; For example, to activate all options, set to [lethal aerial not-invisible blitz docked-vs-land]. The order of items in the list does not matter. You
; can also activate all options by setting to [all] (with or without the brackets).
special_defensive_bombard_rules = [lethal aerial not-invisible blitz docked-vs-land]

; A list of modifications to the rules for zone of control, like above for defensive bombard. The possibilities are:
; amphibious: Land units may exert zone of control over sea units and vice-versa. This can only be done using bombard strength, not attack
; strength. It also requires non-zero bombard range.
; lethal: Units may be destroyed by zone of control. The intercepting unit must have the lethal bombard ability in order to do this, even if it's
; using its attack strength to exert ZoC.
; aerial: Air units can exert zone of control if their type has the "Zone of Control" option checked. Additionally, they must be able to perform the
; bombing mission, have non-zero bombard strength, and non-zero operational range.
; Like for defensive bombard, all options can be activated by setting to [all] (with or without the brackets), and order does not matter.
special_zone_of_control_rules = all
 
I definitely should have thought that the stack limit might block attackers, oops. The reason sneak attacks still work is because moving onto a tile occupied by a foreign unit at peace is already sort of disallowed. Because the stack limit is only checked for fully allowed moves, it gets skipped there.
Yes, it's a bit funny you can attack the stack to declare war, but not if you are already on war with that civ.
Otherwise, thumbs up for this great achievement!!

Also I want to report a minor bug.
With modified retreat-rules "all-units" or "if-faster" it is possible for units flagged "immobile" to retreat. This makes it possible to push immobile units with more than one hp across the entire map (if they heal one hp every turn). This is strange, for example, with pre-placed immobile units in some scenarios (bunkers or similar). Is it possible to check if units are immobile, before allowing their retreat?
 
Last edited:
Looking forward to trying the new version, hope I don't overwrite my custom icons again.

I think I understand movement now. Speed on roads gives you the ratio for fast road travel, the default is 3. If railway speed is limited by C3X and you select fast roads, then that limit becomes the new ratio. Sorry to be slow here. I set road speed to 2, so if I set max railways speed to 2 and fast roads on then all will remain the same. If I set it to 3 things get faster, perhaps a bit too fast but then I gave a lot of units a base speed of 4.
 
I tried to play a little with the ban on "rubber tiles" limit_units_per_tile. Before that, I removed three lines of code from the injected_code.c file (4423-4425). Everything works.
Here are the wishes for the restrictions:
1. Separate restrictions for each type of unit: land, sea, air.
2. An army is one unit.
3. Exclusion of workers (with an attack value of 0, or through lists for exclusion).
4. Exclusion of combat units that are busy building roads, railways and forts on a tile.
5. Skipping units passing further through a filled tile, without stopping them on the tile.
6. After a battle, a unit with HP 1/X can retreat to a filled tile.
7. Restrictions for cities (if possible, then depending on their size).
8. Cities can produce units in excess of the limit. These units can remain in the city, but once they leave it, they cannot return back. Or they must be thrown outside the city, except for stationary units.
9. Transport ships and planes with loaded units can enter a full city, but units cannot be dropped from transports in the city itself, but can only leave the city.
 
Would it be possible for the respawn ai character option on the game rules to spawn them but not spawn at war? In my experience this is more detrimental to the ai than the player.
 
I tried to play a little with the ban on "rubber tiles" limit_units_per_tile. Before that, I removed three lines of code from the injected_code.c file (4423-4425). Everything works.
Here are the wishes for the restrictions:
1. Separate restrictions for each type of unit: land, sea, air.
2. An army is one unit.
3. Exclusion of workers (with an attack value of 0, or through lists for exclusion).
4. Exclusion of combat units that are busy building roads, railways and forts on a tile.
5. Skipping units passing further through a filled tile, without stopping them on the tile.
6. After a battle, a unit with HP 1/X can retreat to a filled tile.
7. Restrictions for cities (if possible, then depending on their size).
8. Cities can produce units in excess of the limit. These units can remain in the city, but once they leave it, they cannot return back. Or they must be thrown outside the city, except for stationary units.
9. Transport ships and planes with loaded units can enter a full city, but units cannot be dropped from transports in the city itself, but can only leave the city.

It looks as if there's quite a lot to sort out before it's really playable. For me:

1. Yes please, adds a lot of flexibility. Technically possible?
2. Don't care.
3. For gameplay you probably need, although does allow huge stacks of workers, which must take up some room, preferably an option.
4. Don't care, if they are also combat units they probably should count.
5. Ideally yes please, but could live without, presumably you just need to be one unit under the limit, so not so bad, if you move them one at a time. Would that work?
6. Could live without, if you can't retreat you get caught out seems fair enough. Also another reason not to completely fill a tile.
7. Yes, only really half done if you can store massive stacks in a city and your oppo can only attack with a limited number.
8. Needs fixing one way or another, again, a reason not to stuff every title. Could be missused to create big defender stacks if they are left in the city. Can summoned/produced creatures be delayed until there is room? Seems logical. A message would be useful, so you could move units out to make room.
9. Yep, although you can 'cheat' a bit by storing a reserve in transports to deploy after any losses, bet the AI won't think of that. Don't see an easy way to stop a player though.

Already wondering on what stack limit I would use! 15-30 on grassland? I hope/assume it will be by terrain type (if not that's my number 10, it adds a huge tactical change).

If it works this would change the game a good deal, big jump in the importance of unit quality, maneuvering and combined arms, over 'build a big stack of tanks/dragons'. Sweet.
 
Also, just came to my mind. I remember from Civ 1, when a nation had civil unrest under Democracy after 3 turns if I remember correctly, the revolution happened and a nation sometimes split to two equally technologically advanced nations. Or better, when a nation loose its capitol part of its country can rebel against it. Is it doable in Civ3?
Out of curiosity, did you look into that? Is it easy to do or rather not?
 
I recently found out about this mod. It looks fantastic, and I was wondering if anyone could advise on the following changes:
  • Non-unlimited railroad movement: I understand this is possible, but I'm not sure how the INI logic works, particularly if it also affects regular road movement. Can road movement be left as is, and make railroads twice or thrice as efficient?
  • Non-overlapping city fields: As far as I could tell, one can increase the minimum distance between cities to prevent overlaps (would be 4 or 5 tiles depending on whether it counts the last tile as a valid city location). The question is the ramifications on the game's pace, and how those could be amended in the context of fewer cities per civ...
  • The greater unknown is whether it'd be possible to avoid entire continents being carpeted in roads and later railroads. Later Civs tweaked that, imposing additional costs and reducing the benefits. Could this mod in any way approach that without breaking the game, and especially the AI?
 
Okay, I was running some tests when I came across something weird. I created a wonder called X that was putting a building called Y into cities. Then I applied some perfume to X, but to my surprise, the AI refused to build X. When I looked at the AI's production ranking in their cities, I soon realized why, because instead of X there was Y, which had no perfume applied to it, which is odd because Y isn't even on the list of things the AI can build. So when I applied perfume to Y, the AI finally decided to build X. I don't think it's supposed to work that way.

Antal's EXEs also had features like expanded city radius and altered naval movement rules, and maybe some other things I'm forgetting, I haven't bothered including that stuff because it would require significant effort and no one's mentioned that they want it.
It's funny because I kind of thought that was part of your mods and I was already using the extended city radius as such a given, but it turns out I just forgot that wasn't the case when I switched from version 13 to version 20 and the game started crashing the first time I tried to move a unit. Turns out I had used version 13 back on Antal's original EXE and everything was compatible, or at least the game didn't crash on my attempts. But version 20 didn't seem to maintain that compatibility.

Do you guys want the stack limit to apply to cities or not? Just asking as an informal poll.
In the future, I guess for sure, but I don't want to keep throwing crazy complicated ideas at you.

I'm also considering making the limit apply separately for each class of unit: land, sea, and air, so they don't conflict with each other.
Splitting by class is good, but I certainly wouldn't give up the one common to all. For example, to say a maximum of 10 ships (determined by port size), 15 aircraft (determined by airport size), 30 ground units (determined by barracks size), and a maximum of 50 total (determined by city size), so 5 some units wouldn't fit. Yes, I was thinking about linking the limits in cities to the corresponding buildings and... I know, I'm getting too complicated again.

On a complete side note: The rows with production shields in cities are not displayed correctly for buildings costing more than 1080 shields.
I know, it's just a small cosmetic thing, but after you managed to compress the strategic and luxury resources, I thought something could be done with this as well. Or is this something else that can't be done?
 
This would be my first time commenting on this project, while following it for a while. I want to provide a bit of a controversial opinion on this, after reading a bunch of posts, especially recently. I believe this thread (and the efforts put here by it's sole developer) are getting exceedingly derailed by a lot of very narrow and, in some cases, just plainly weird requests.

I think that there has been a lot of suggestions for very narrow, and, I dare say, extravagant, things here. Things focusing on specific scenarios and types of play that, frankly, I personally (as a casual player still loving Civ 3 since 2001) don't really like seeing in general, much less getting someone who is doing their best effort at improving the game overall, wasting their time with. Stuff like, most recently, limiting the number of units per type/terrain/city on a given tile, AI value on specific units + many more extravagant (to me - plainly useless) options.

While stuff like hardcoded limits (on civs/eras/techs, etc.) and other base mechanics, while taking far greater time to resolve, but would improve the game much further than minor things (as I see them), have been burried under the wight of over 120 pages. And the whole conversation shifted to stuff including very peculiar/taste based things. Things that are, at least to me, are a complete waste of time, given the effort of one single person that is trying to balance the requests of the community.

I do realize that the community of this game that is left here in its current form is pretty hardcore, and, in many regards, pretty narrowly focused after playing this game for what is decades at this point - but one has to realise bigger implications at hand.

To me, given that Flintlock has recently brought up a possibility of him intoriducing a new scripting language, that would allow to greately improve his ability to modify the game - that takes precedence over whatver 'improvement' (and I do mean the ''s) anyone can come up with at this point.
 
Top Bottom