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

[Sutsuj]

Yes, Sima posted, that it is for hotseat and PBEM games (both multiplayer games) - and you have only asked about multiplayer games with more than eight civs. I´m not playing multiplayer games and therefore, unfortunately, cannot answer your now much more specific additional question.

True, true. You're quite right that my original question was much broader than what I intended: specifically, internet real-time games. I update my wish-list-item-if-Flintlock-has-the-time to be: Enable filling the non-human-player civilization slots in a real-time multiplayer game with as many AI as a custom scenario allows, rather than the standard max of (8 - number-of-human-players).

 

[Flintlock]

In my eyes it is too early to say generally, that your mod/patch is not working with the CD version of Civ 3 Complete, because there were sold several different CD versions of Civ 3 Complete, some of them without the old copy protection that is no longer supported by microsoft and therefore don´t have the installation problemes, that other CD version of Civ 3 Complete and C3C have. I surely know this about the Civ Chronicles version of Civ 3 Complete and I was told, that the German Green Pepper version of civ 3 Complete is another version with this change.

I didn't know there were so many different versions of Complete. I highly doubt that any version that requires a CD is compatible, which probably rules out most of them. Not much else to say unless we get other versions to test.

I know the wishlist is already super long, but in case you have time to get to it, I'd be super excited if multiplayer games could have more than 8 players.

Added to the list. I haven't looked at the multiplayer code at all yet so I can't say how plausible this would be.

Flintlock, I'm adding my wish list here as well, if any of these are areas you would like to explore.

Added too, the list is now about 30 things. Adding prereqs to city builds should be easy, I'm pretty sure I already know how to do it. Changing the graphics is not something I've looked into in detail yet. I'm not sure what you mean by "decoupling city icons from current building mechanics and assigning them elsewhere"? Can you elaborate on that?

 

[Civinator]

Flintlock, Tony Boscia´s suggestions make a lot of sense for modders.

Adding prereqs to city builds should be easy, I'm pretty sure I already know how to do it.

This would make the new feature you have added to Small Wonders (SW) even more powerful. Imagine any colonization scenario. You have a SW for every continent that adds a special building to that continent. The continent-specific production of units with this new feature is only possible for units that are autoproduced by these continent-specific buildings. With the additional settings even the direct production of different continent specific units would be possible.

One problem with this new powerful feature would be, to have an editor that is able to handle this feature. The prerequisites for the direct production of units are not tied to buildings in the Firaxis C3C editors (only the indirect production of units by buildings is possible in these editors).

The Quintillus editor has a connection in the direct production of units to buildings, but this is the telepad setting, a feature that was never made public in the official release of C3C. It allows units, that have a setting to that building, to teleport to that building from anywhere on the map.

Changing the graphics is not something I've looked into in detail yet. I'm not sure what you mean by "decoupling city icons from current building mechanics and assigning them elsewhere"? Can you elaborate on that?

I think meant are especially these two graphics in the art\cities folder for harbors and airports:

Both buildings have important double functions:
a) They allow to produce veteran units and heal ships or planes in one turn and
b) open the tradenet over water (habors) or over air (airports)

The problem with the connection of those graphics appears when both functions are separated for buildings, what mostly makes a lot of sense, as cuts in the trade-net make the interturn gamespeed significantly faster. Unfortunately both icons are connected to the function to open the tradenet and not to the function to heal units in one turn and to produce veteran units. In most scenarios, especially war scenarios, it is much more important to find a city where the damaged ships and planes can be 'healed' in one turn than to have an optical sign on the map for cities providing sea- or airtrade.

An improvement of the situation would even be, if the aircraft symbol would be connected to the 'heal and produce' veteran aircraft option instead of the option allowing air-trade and the anchor symbol be connected to the option to produce 'veteran ships and healing ships' option instead of the option to allow watertrade.

 

[AnthonyBoscia]

Thanks, Blue. You detailed very precisely and accurately what I meant about the icons. My initial thoughts were exactly as you described, which was to make the icons appear with the veteran flag rather than the trade node flag. But if those icons could be connected with any flag, then they would be open to the modders' original ideas and needs.

Flintlock, thanks for taking a look. I have both the original discs and the steam version so I am going to play around some with the current patch and see what happens.

 

[Flintlock]

One problem with this new powerful feature would be, to have an editor that is able to handle this feature.

I was just planning to have these sort of rules specified in a text file but that's a good idea about the telepads. I could instead implement a rule like if a unit type has a telepad set then it can only be built in cities with that telepad. That would be easier for me to implement, b/c I don't yet have the code in place to read complex things from the INI, and it sounds like it would be easier for modders to use too.

I think meant are especially these two graphics in the art\cities folder for harbors and airports:

Thanks, Blue. You detailed very precisely and accurately what I meant about the icons. My initial thoughts were exactly as you described, which was to make the icons appear with the veteran flag rather than the trade node flag. But if those icons could be connected with any flag, then they would be open to the modders' original ideas and needs.

Thanks for explaining, I get it now. This sounds like an easy change to make but I'd have to look into it to be sure.

 

[Civinator]

I was just planning to have these sort of rules specified in a text file but that's a good idea about the telepads. I could instead implement a rule like if a unit type has a telepad set then it can only be built in cities with that telepad. That would be easier for me to implement, b/c I don't yet have the code in place to read complex things from the INI, and it sounds like it would be easier for modders to use too.

Flintlock, sorry but to connect it to telepads is no good idea, as the telepad itself in nearly every case is no good idea. Units can teleport to their telepad from everywhere from the complete map. This in nearly all cases destroys the complete game. Additionally, if an enemy unit can teleport into a city with a telepad, this city is conquered immediately and it doesn´t n matter how many units were based in that city for defense. There is a reason, why the telepad never made it into the official C3C release.

If it is possible to implement these sort of rules in a text file, this would be the proper solution.

 

[Flintlock]

Flintlock, sorry but to connect it to telepads is no good idea, as the telepad itself in nearly every case is no good idea. Units can teleport to their telepad from everywhere from the complete map. This in nearly all cases destroys the complete game. Additionally, if an enemy unit can teleport into a city with a telepad, this city is conquered immediately and it doesn´t n matter how many units were based in that city for defense. There is a reason, why the telepad never made it into the official C3C release.

Oh, I didn't know teleportation was actually possible in the game. I figured it was all stubbed out.

 

[Civinator]

Oh, I didn't know teleportation was actually possible in the game. I figured it was all stubbed out.

Yes, you can teleport to other buildings over the complete map or to other units with adjustable teleportation range. The building telepad (with one exception) seems to be a real gamebreaker. You can read more about teleportation in C3C here: https://forums.civfanatics.com/threads/a-study-on-teleportation.187949/

There is another hidden function in C3C, called charm attack, what is more useful in the game.

 

[Sutsuj]

Added to the list. I haven't looked at the multiplayer code at all yet so I can't say how plausible this would be.

Thank you Flintlock!

 

[Flintlock]

Progress report: The past week I've been working on modifying the AI's artillery usage. I had hoped this would be a simple matter of making the AI treat all artillery as if it had been captured but annoyingly it's not. The critical variable in AI artillery behavior isn't even captured status, instead it's whether the arty unit is in a city or not. Basically the way the AI is programmed, arty units in a city will never leave that city unless there are too many of them in it (the limit is about 1 or 2 depending on city size). Arty units outside of a city have more complex AI that can move them around.

After figuring that out, I tried bypassing the in-city check so all AI artillery acts as if it's outside of a city. That helps but it's only a partial solution, the problem with it is that artillery pieces even with the outside-city AI only check a small area around themselves for targets and if they don't find anything they fortify in place. So the arty units the AI builds in its core cities still mostly just sit there. Another solution I tried is to run the offensive unit AI on the arty units when they're far from the front line, hoping it would move them forward. That didn't work either, they mostly didn't move and even worse the AI started sending them, unescorted, on naval landings.

Not being able to cut corners, I finally just starting writing my own replacement AI artillery code. At minimum it needs to be able to move artillery units to the front line then let the base game outside-city AI take over. So far I have a basic version working. I observed the AI using it in debug mode and saw one actually smart usage of artillery, AI Japan moved several cannons into a city that was being pestered by Indian frigates then got a chance to soften up the frigates before sending in its own navy to finish them off. I saw some stupid usage too, like a stack of 2 cannons getting captured and recaptured several times because neither of the two warring AIs knew to defend it properly. With some more polish I think this approach could be acceptable, but it's tempting to replace the artillery AI completely. One of the major limitations to this approach is that it doesn't enable the AI to send stacks of artillery far from its cities, which is a problem when it's at war with a civ it doesn't border.

Another thing I'm working on is forcing the AI to build more artillery in general. This is much easier, like I mentioned before, I know what function is responsible for making the AI's build choices so I can intercept its return and adjust its decision. I am concerned that all this effort is going to backfire, though, by making the AI an easier opponent. If the AI builds a lot of artillery and sends it into battle but doesn't defend it properly, against a human player it's just donating units. The only way I can think to solve this problem would be to replace the defensive unit AI too, because, as far as I can tell, in the base game there isn't any coordination between units. Specifically, artillery units will move somewhere to attack on their own (if outside a city) then it's up to some defensive unit to notice they're exposed and move to cover them, but there's no guarantee that any will decide to or that any will even be available to. I wonder if the AI's inability to use artillery is actually an intended behavior to avoid these kinds of problems. If so the only proper solution would be a thorough overhaul of the unit AI, which would be a lot of work, but it's just plausible enough to be tempting. But it will probably never happen.

 

[Civinator]

Flintlock, even when you have not found a proper solution for a working landartillery, your post provides some new knowledge to us. Thank you very much for this. Your finding about the splitting of the AI routine for landartillery in two different strategies is interesting and now some of the observations that were done in the past (including my observations when using the naval power AI strategy for landartillery) makes much more sense. It is a pity, that tom2050´s theory about the different nationality of artillery (especially barbarian nationality) is not working, that was posted in this thread: https://forums.civfanatics.com/threads/using-barbarians-to-get-ai-to-use-artillery.407459/ and your posts have the same findings as Sima Qian has written it in this post of tom2050´s thread: https://forums.civfanatics.com/thre...-to-use-artillery.407459/page-3#post-10181307

The critical variable in AI artillery behavior isn't even captured status, instead it's whether the arty unit is in a city or not. Basically the way the AI is programmed, arty units in a city will never leave that city unless there are too many of them in it (the limit is about 1 or 2 depending on city size). Arty units outside of a city have more complex AI that can move them around.

Does this mean city size 1 = 1 needed arty unit in the city until there is a chance, that the second arty unit is moved out of the city and city size 2 = 2 needed "garrison" arty units, until an arty unit is moved out of the city by the AI (city size 3: 3 garrison arty units) or is one or two arty units before the AI decides to move a unit outside a city only a generell rule of thumb?

...as far as I can tell, in the base game there isn't any coordination between units.

The base game holds a coordination between units, but only for naval units: The "requires escort flag", in the base game used for transport ships and carriers.

There exist some some other working artillery strategies in the base game (besides the air bombard, that causes a different use of the graphics) that could be worth some reflections:

The naval power strategy:

With the Quintillus editor it is possible to assign the naval power strategy (with its mostly proper use of bombardment) even to landunits when lowering the safety level in that editor. I made a thread about it, that can be found here: https://forums.civfanatics.com/threads/land-artillery-new-ai-routine.551972/ The acting of the AI units mostly was the same as you described it for the "outside city strategy" you have found.

The cruise missile strategy:

There are several reports, that the AI is using cruise missiles well. I don´t have much experience with using cruise missiles in the game outside of cities, but if they should work properly, there is the problem, that they are destroyed after attack. In Civ 2 ToT ( the version of the Civilization series before Civ 3 was released), there was a simple function to override that missile units are destroyed after the attack.

In Civ 3 the prerequisites for the AI cruise missile strategy are the same as for the landartillery plus cruise missile ability. It could be interesting to see, what happens if the "destroyed after attack" setting could be overwritten as in Civ 2 TOT, too. Would such a unit act like a landartillery unit with the "outside city" strategy, or would it act different ? Only some thoughts.

 

[tjs282]

I saw some stupid usage too, like a stack of 2 cannons getting captured and recaptured several times because neither of the two warring AIs knew to defend it properly.

There is a naval-unit flag "Requires escort", which tells the AI to stack 3 "Naval power" units per "Naval transport" unit, in the late Medieval and beyond (Galleons and Transports both have that flag).

Could that flag possibly be applied to bombardment-units as well, so that the AI doesn't leave them uncovered (although with an inverted ratio, if possible, e.g. up to 2 Arty per land-unit)?

(It might also be necessary to switch off the "Cancel Orders for enemy combat-unit" AI-preference for D=0 (land-bombard) units, if possible — or we would have to mod all land-bombard units to at least D=1 — so that the AI doesn't retreat them as soon as the enemy approaches, like it does with its Workers)

This is much easier, like I mentioned before, I know what function is responsible for making the AI's build choices so I can intercept its return and adjust its decision. I am concerned that all this effort is going to backfire, though, by making the AI an easier opponent.

Could your "Build (more) bombardment-units"-function be somehow tied to the unit-speed of the AI-Civ's fastest available unit, i.e. could it be directed to build bombardment-units only if its fastest available land-unit has M=1?

That way, if it could build M>1 units (either fast foot-units like JagWarriors, or Horse-/Oil-requiring units, in the epic game), it wouldn't 'need' any bombardment-units.

But if it could only build M=1 units, then any (M=1) bombardment-units it also built, would then be more likely to be included in (and covered by!) its attack-unit stacks (assuming that the bombardment-units would use the same pathfinding algorithm*) — which is more like how a human would do it (the so-called "poor man's army").

*This is without factoring in Impassable-to-Wheeled terrain, but it would be a start.

If the AI builds a lot of artillery and sends it into battle but doesn't defend it properly, against a human player it's just donating units.

Not necessarily an ideal solution to this particular problem, but... if bombardment-units are given D=1 in the Editor, they will be destroyed instead of captured.

 

[Civinator]

Not necessarily an ideal solution to this particular problem, but... if bombardment-units are given D=1 in the Editor, they will be destroyed instead of captured.

... and the same happens, if the civ is not able to build that otherwise captured unit.

 

[Predator145]

Does the AI ever move its cruise missile AI strat units outside? I don't think so based on my tests. It will use them against targets within range of the city it's garrisoned in. But moving out in an escorted manner? I've never seen that.

I think the best AI strat to let the AI move the arty pieces to where they need them is "air power" with rebasing. Give the arty pieces operational range as well.

 

[Rômulo Prado]

In my humble opinion, if you will allow me, I believe that a good solution would be to write an escort routine for the artillery pieces, in which each piece of artillery had the escort of three defense units. but detail, but to be able to configure this escort model in the mod configuration file.

 

[Flintlock]

Does this mean city size 1 = 1 needed arty unit in the city until there is a chance, that the second arty unit is moved out of the city and city size 2 = 2 needed "garrison" arty units, until an arty unit is moved out of the city by the AI (city size 3: 3 garrison arty units) or is one or two arty units before the AI decides to move a unit outside a city only a generell rule of thumb?

The code for this is very strange for something so simple. I didn't look at it in detail and figured the limit was 1 or 2 partially based on observing the AI play. Looking at it again, the limit for metropolises is only 1 and the code for smaller cities does some pointless comparison that means it will always come up with a limit of 0.

The base game holds a coordination between units, but only for naval units: The "requires escort flag", in the base game used for transport ships and carriers.

I can't believe I forgot about escorts. There is also at least one case where the AI will escort land units, when it's moving settlers into position to found. And now that I think about it I recall seeing the AI occasionally escort artillery units when I was observing it play, but I didn't think much of it at the time. This must be why the AI keeps its artillery in cities even with the limit bypassed: it's waiting for an escort. It's interesting that when escorting units, the AI moves each of them one tile at a time instead of moving one completely before moving the next one. Interesting because this sort of thing should be easy to see in the code, that fact that I haven't noticed it in the artillery AI means it's probably in the defensive unit AI. I'll have to do more investigation into this.

Could your "Build (more) bombardment-units"-function be somehow tied to the unit-speed of the AI-Civ's fastest available unit, i.e. could it be directed to build bombardment-units only if its fastest available land-unit has M=1?

Sure, accounting for unit speed is no problem. I haven't finalized the logic yet, I'll make a note of that for when I do.

Could that flag possibly be applied to bombardment-units as well, so that the AI doesn't leave them uncovered (although with an inverted ratio, if possible, e.g. up to 2 Arty per land-unit)?

In my humble opinion, if you will allow me, I believe that a good solution would be to write an escort routine for the artillery pieces, in which each piece of artillery had the escort of three defense units. but detail, but to be able to configure this escort model in the mod configuration file.

Hopefully I can reuse escort routines from the base game and don't have to write my own. The first thing I'm going to try is getting escorts for the artillery pieces sitting in cities, assuming I can confirm that that's what their problem is. I suspect that's what those unknown unit states 1C and 1D are for, I'd guess one is "waiting for escort" and the other is "being escorted." One thing I'm going to try, if I can figure out if/when an artillery unit is waiting for an escort, is to force the city it's sitting in to build an escort for it.

 

[Nanuk]

A shameless hijack here, but I just wanted to say I love reading over this thread. Thank you to everyone for sharing very useful knowledge, and especially to you Flintlock. Also as we were discussing a few days ago about the minimum distance for cities, please let me know if you ever find that. I would love the ability to set the limit higher by one or two tiles. For now I'm just gaming the terrain but I believe this just handicaps the AI.

 

[register]

I had in plans to open a new tread for it but might as well write it here instead. I noticed that AI, when there is treasury built, only it needs to grab it and transport to the capitol to gain money, instead it holding it in a city without taking a profit. I was not sure if there something in editor settings or that's another bug.

 

[ynot56]

As long as we are talking about really out there stuff, like the management of battles by the AI...

I have noticed that the AI will attack with very weak units even when there are stronger units available. This allows the defender to "level up" due to combat victories so that later stronger attackers will face stronger opponents. So, just like the aforementioned artillery order of attack, the land unit order of attack might be improveable.

Likewise, although sometimes the AI heals one hit point units through either returning them to a city or leaving them in place to heal, it will often attack with them. Attacking with one hit point units is often ... counter productive. Changing the probability of attempting to heal would be advantageous.

 

[Sutsuj]

Greetings Flintlock,

I thought of several opportunities related to unit movement that could be quite valuable to modders. I expect the first several suggestions would be simple fixes. The last suggestion would be significantly more involved, but might open up many modding opportunities relative to the amount of coding work required. Of course, I completely understand if you never pursue these ideas - just thought I'd present them in case they pique your interest (or the interest of some future modder). Thank you for the work you're already doing!

All pictures are from the Quintillus scenario editor.

-----------------------------------------------

Smaller fixes:

1. Allow teleportation of "immobile" units. There's no reason for applying the teleport ability to an immobile unit unless teleportation is supposed to be an exception to the immobility.

2. As an alternative to 1 (or in addition), the scenario editor allows for scenario designers to remove the "go to" action from units. This would hypothetically be another way to make a unit immobile in certain respects. However, if "go to" is unchecked, the AI can still move the unit freely, and humans can still move the unit via pressing the arrow keys.

3. [Not exactly a fix:] Allow any (land?) unit to retreat if faster than the unit it is fighting. Right now a fast unit can only retreat if attacking a movement 1 unit.

4. Fix the game crash when someone (including an AI) attempts to unload an immobile unit from a ship onto land (and from a land carrier onto land?).

-----------------------------------------------

The Big Addition:

I have thought of a way to make terrain have unit stack size limits while leaving older scenarios' gameplay unchanged. Stack limits would open up many, many tactical options for scenario design.

Give all terrain a base unit "capacity" of 3600 (or some other large number - more on why I mention 3600 below) divided by the movement cost of the terrain.

Give each unit a "size" parameter via the unused scenario parameter which defaults to 0 for all units:

Require that a unit cannot move to a terrain square unless there is enough room. That is, the unit can only enter a square if the size of the unit plus the sum of the sizes of the units already on the square is less than or equal to the capacity of the square.

Because the parameter is zero by default, all existing scenarios' behavior will be unchanged. However, if someone wants to implement limited unit stack sizes, they can do so! Further, the option to customize each unit's size allows for many complex combinations and possibilities.

Because the size parameter can be set to negative values, you can even have "supply chain" units which increase the capacity of a square!

Here are some details that would likely need to be addressed if this change were to occur:

0. Units need to be able to attack squares that are full.
1. Ships should probably have a distinct space usage from air and land units.
2. If cities have a unit capacity limit, then perhaps city production should wait to produce a unit until there's space (like with settlers and population).
3. If such a limit applies to citiies, perhaps it should also be applied to buildings which produce units.
4. Perhaps city unit capacity can be based on city size?
5. Movement restrictions would need to be coded for all the kinds of movement - airdrop, teleport, rebase, ship-unload, land-carrier-unload, etc.
6. The reason I suggested 3600 for the basic terrain capacity is that it is divisible by many useful numbers. Thus, the scenario designer can easily assign unit sizes to partition the capacity space. The prime factors of 3600 are 2, 2, 2, 2, 3, 3, 5, 5. This means 2, 4, 5, 6, 8, 9, 10, 12, 15, 16, 18, 20, 24, 25, ... and many many more numbers divide 3600 cleanly. For example: Want 12 units per standard tile, 6 per hill and 4 per mountain? Then assign units sizes of 3600 / 12 = 300.
7. Consider having the "unit X ignores movement cost of terrain Y" option in the scenario editor also make the unit not count toward the size constraint on squares of that particular terrain type. Not sure if that would be a good addition or not.
8. Consider not making a square's capacity based on the terrain's movement cost and instead having a fixed capacity (e.g. 3600) for all terrain types. I personally think the extra constraints would enhance scenario design options, but maybe not...
9. The AI's pathfinding code might get much more complicated?