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

[Ozymandias]

IMO it's best to make all artillery units have token defense value and -4 HP. Captured artillery does not balance well at all in game play.

So, you wouldn't give mobile artillery a chance to retreat?

 

[Ozymandias]

Is there any way to disable a Town adjacent to a River automatically growing to a City?

 

[SayHayKid]

IMO it's best to make all artillery units have token defense value and -4 HP. Captured artillery does not balance well at all in game play.

I am going to have to try this once I wrap up the current game. Too much artillery floating around (which is good until captured). I love that the AI is being more aggressive and effective with artillery using C3X, but way unbalanced once I capture 50 in a couple of turns.

 

[Virote_Considon]

If you give every civ their own artillery that only they can build, then instead of being captured they'll just be destroyed. Don't even have to give them different pedia entries.

 

[Flintlock]

Unfortunately there's a nasty little bug in R17 and R18P1. It affects the part of the config loader that reads in the perfume specs and can cause all sorts of problems like crashes and config loading not working like it's supposed to, e.g. the scenario settings might not override the default settings. It's a memory bug, specifically what's called a "use after free", which tend to be weird like that. If you don't have any perfume specs set then this shouldn't matter, but if you do you should definitely switch to the fixed version to save yourself a lot of headache. The fixed version will be called 17C and I'll post it shortly.

So, I need to work out a balance. Maybe make it not able to be captured? Or maybe something simpler like artillery can't be upgraded. So, it can be effective for a short time, but after being captured outdated artillery can be converted to shields and act like booty from your victories.

For while now I've been thinking of making it so that units aren't always captured but rather have a chance to be. The chance would be set in the config and probably should be different for artillery vs other unit types. I agree that capturing large amounts of artillery off the AI lets the human player snowball too easily, but I think it's a shame to make artillery uncapturable entirely since capturing units is a fun mechanic.

And a few questions:
1. Motion and attack indicators are very useful in the game. But for stationary units they also show the ability to move and attack. Can this be fixed?
2. Reloading a saved game when using C3X_R18_Preview_1 freezes at 2%.

1. I never even thought of immobile units when I programmed the indicators. You're right it makes more sense for them to use the same indicator as units that can't move because they've spent all their moves. That's an easy change.
2. This might be caused by the bug I mentioned above if you have any perfume specs set. Or it might not be, I suspect there's another issue with R18P1 however I haven't been able to track it down yet.

Is there any way to disable a Town adjacent to a River automatically growing to a City?

It would be simple to edit the logic for city growth so that it ignores access to fresh water. The only issue is I'm not sure that edit would also allow players to build aqueducts in riverside cities or if another edit would be necessary. It should work for everything else since that logic is in a method (I named it City::requires_improvement_to_grow) that's used in many places including for example the worker AI.

 

[Flintlock]

Flintlock updated C3X with a new update entry:

Release 17C

This small update fixes a nasty little bug in the config loader affecting the perfume specs option. The bug can cause various issues including crashes and config loading not working as it's supposed to.

Read the rest of this update entry...

 

[Predator145]

So, you wouldn't give mobile artillery a chance to retreat?

I don't think they need it. Considering now artillery helps hold ground. You can run into a situation where you only have 2 real defenders holding a city plus 6 artillery pieces. The defenders get killed along with a couple artillery pieces. But the AI ran out of units to exploit the gap. That alone is a buff to artillery and balances the PTW targeting.

But it's a good idea to distinguish armored mobile artillery to unarmored ones. A M109 with its enclosed turret and 50 cal can defend itself better than a Caesar whose crew is exposed during firing. So armored artillery may get more HPs and even better defense value. But I don't do it in my mods because that would just make the unit more expensive while the def value and retreat ability would rarely ever come to use as both humans and AIs now escort their pieces. Instead, armored artillery have higher bombard value and less ROF compared to Wheeled artillery, which represents the ability to accompany armored formations more closely to give them defensive fire support.

Has anyone tested the function of artillery not needing escort? How does the AI use it? Does it work?

 

[Civinator]

Unfortunately R17C cannot fix the freeze when the AI, after a boot order, declares war to the human player.

 

[Ozymandias]

It would be simple to edit the logic for city growth so that it ignores access to fresh water. The only issue is I'm not sure that edit would also allow players to build aqueducts in riverside cities or if another edit would be necessary. It should work for everything else since that logic is in a method (I named it City::requires_improvement_to_grow) that's used in many places including for example the worker AI.

It should be easy enough in the editor to reassign attributes, e.g, Aqueducts can only be built adjacent to Rivers & allow growth to Size 2 (or 3) cities (obviously, there would need to be other Improvements allowing the same.)

 

[Sakharov]

Hello again!
Do game engine differ forest terrain by base terrain? Would it be possible to restrict settling cities on tundra-forest or so?

 

[Erlend Philip Wood]

This gave me a new idea. What about replacing text instead? The game starts every line with one of two words: "Wake" or "Activate". Neither are very informative, and could mean many things each. For example, "Activate" in relation to a Worker could mean it is working, it is automated, has unfinished move orders, or currently has no orders and is ready to be given some. Those two words could be replaced with the current orders instead. Such as: Idle, Expended, Fortified, Sentry, Transported, Automated, Working, Moving, Exploring, or Intercepting.

Using modified LED indicators from the upcoming C3X R18, and some text file manipulation, I managed to create a screenshot of how I'm hoping our right-click menus could turn out:

While there's a wealth of information, it should be easy to read and almost self-explanatory: The tiny swords indicate units that can still attack. The green, yellow and red LEDs indicate movement left, and are exactly the same as those on top of the health bar of every unit on the map. They should be familiar to players, and require no further explanation. And finally, the orders of units are explicit, so you can look at any stack and immediately know what all the units on the list are doing.

Note that I removed the blue LED indicator, since it is redundant with the added text. The problem with having blue lamps indicating not only intercepting aircraft, but also Workers, auto-bombardment, or any unit that is busy, is this: If you look at the screenshot, they are in fact all busy, or occupied somehow. Only the ones marked as "Idle" are not. So having a whole bunch of blue lamps would just add complexity and cause confusion in my opinion.

We probably wouldn't need the blue light then; it would just be necessary for the lights to indicate attack ability and movement left.

Anyway, I can see how this would not be obvious to players. It probably is better to drop the blue LED and indicate busyness using text instead.

Below is exactly the same list of units, but without the icons or text replacements (like the vanilla game, or C3X prior to R18):

• There is no way to tell which units can attack, and there is limited information on movement. Movement can to some extent be determined from the numbers at the end of each line, but this method doesn't work on aircraft or immobile units, doesn't take into account partial movement from road movement etc, and it's much quicker for the eye to just look for a certain color. The icons added in R18 pretty much solves this issue.
• But even with the icons, you still can't tell which units are busy carrying out long-term orders, or are currently doing nothing and need to be given orders (idle units). You might inadvertently activate units that are doing something useful; or important even. But you would never know, because there is no way to tell. So you might end up giving the same unit the same orders multiple times in the course of a game.
• It is possible to deduce some of the unit orders by looking at the first words (Wake or Activate). For example, a unit preceded by "Wake" will either be Fortified, Sentry, or Transported. Thus, units with "Wake" can never be Idle. Interpreting "Activate" is much worse; it could mean anything from the unit having spent its entire movement for the turn, to just sitting there being Idle, or a whole range of long-term orders keeping it busy. See the list below.

I don't think it is necessary to be more specific about what a Worker is doing other than simply "Working", because you can just click on the Worker (without interrupting it) to learn its current task and how many turns are left. You can also tell by looking at its unit animation.

And a few questions:
1. Motion and attack indicators are very useful in the game. But for stationary units they also show the ability to move and attack. Can this be fixed?

1. I never even thought of immobile units when I programmed the indicators. You're right it makes more sense for them to use the same indicator as units that can't move because they've spent all their moves. That's an easy change.

• I don't think it would be wise to gray out immobile units the same way as units that have spent their entire movement for the turn. Remember that all aircraft in the game are immobile. If you gray out all the aircraft, or give them an indicator that makes it look like they've spent all their movement and unable to attack, it would undermine the arguably greatest benefit of having the indicators in the first place: You have no other way of knowing which aircraft have moved, and which ones have not. So if you've got a list of 50 aircraft, you'll have to click each one in turn till you find one that's idle.
• ICBMs are immobile too, technically they are land based artillery units. Why should they be grayed out, while Tactical Nukes and Cruise Missiles wouldn't be (because they can move)?
• All immobile units are able to perform some kind of action, be it bombardment, reconnaisance or whatever. You need the indicators present to tell whether or not you still can perform these actions, be it attacking through bombardment (like aircraft or ICBMs), or non-hostile actions, like the Satellite in my first screenshot, which is a pure reconnaisance unit and has a green lamp but no sword.
• It's hard to account for everything, but you can tell that a unit is immobile by looking at its stats. A normal unit will have A.D.M listed, an immobile one just A.D (no movement). For example, you've got the line: "Satellite (0.0)", revealing that it is immobile. If it was not, it would be something like: "Satellite (0.0.1/1)".

Wow, my longest post yet! But I do think the right-click menu is very important, since such a large portion of the game centers around moving troops and giving orders. Sometimes you have no other way of knowing what is going on than through the menu. I honestly believe the game can be played better and faster if you have easy access to all the information that might form your decisions.

 

[LKendter]

Any ETA on the fix for Civinator's issue with war declarations?

​

 

[Civinator]

Any ETA on the fix for Civinator's issue with war declarations?

​

Flintlock needs the CCM 3 files to reproduce the freeze and to find a fix.

 

[Flintlock]

Hello again!
Do game engine differ forest terrain by base terrain? Would it be possible to restrict settling cities on tundra-forest or so?

Hello. I'm not sure how terrain types are recorded inside the engine since I've never had to look into it in detail. Based on Antal's decoding of the Tile object, there are two fields, a "SquareType", which is one of the base terrain types you see in the editor, and a "Terrain_Overlay", which presumably includes forests somehow. I don't know whether a grassland forest is stored as grassland base + forest overlay or simply forest base terrain. In any case, it would be possible to prevent settling on tundra forest once it's determined how tundra forests are recorded. Again it would be nice to call out to a little Lua script to determine which tiles can be settled, that way anyone could insert whatever arbitrary rules they'd like.

While there's a wealth of information, it should be easy to read and almost self-explanatory: The tiny swords indicate units that can still attack. The green, yellow and red LEDs indicate movement left, and are exactly the same as those on top of the health bar of every unit on the map. They should be familiar to players, and require no further explanation. And finally, the orders of units are explicit, so you can look at any stack and immediately know what all the units on the list are doing.

I agree that the best way to minimize player confusion would be to match the movement LEDs on the menu with the LEDs already on top of the HP bars. That does complicate things somewhat since the base game LEDs have five different colors, three in between green and red. I could of course ignore two of those and use the middle yellow for everything in between, but if I'm going to replicate the base game's LEDs then I'll feel compelled to replicate them exactly. That means I'd have to look up exactly how the game picks which color to use. Not really a big deal.

The thing I liked about the red and white LEDs is they remove the need for the little sword icons to show which units can still attack. The sword icons are eyesores in my opinion. Though I can't think of any better way to indicate attackers with the base LEDs. Maybe give the attackers' LEDs a red outline instead of black? Or leave the black outline and make the non-attackers' outlines white? Maybe the attackers' LEDs could be brighter? I don't know that those would look good and they might confuse players which would defeat the point.

Note that I removed the blue LED indicator, since it is redundant with the added text. The problem with having blue lamps indicating not only intercepting aircraft, but also Workers, auto-bombardment, or any unit that is busy, is this: If you look at the screenshot, they are in fact all busy, or occupied somehow. Only the ones marked as "Idle" are not. So having a whole bunch of blue lamps would just add complexity and cause confusion in my opinion.

If I modify the Activate/Wake text, which I plan to do, the blue indicators would become redundant and I agree should be dropped. My original idea was that blue would indicate units that are not necessarily busy but busy in a way that the player probably doesn't want to interrupt. For example, you wouldn't want to interrupt intercepting fighters since putting them back in the intercept state causes them to lose a turn (although C3X fixes that bug). Similarly you probably wouldn't want to interrupt a worker doing an action since it would lose its progress. On the other hand, interrupting an automated worker that's not invested in any action doesn't cost anything, so that wouldn't be marked blue.

I don't think it would be wise to gray out immobile units the same way as units that have spent their entire movement for the turn. Remember that all aircraft in the game are immobile. If you gray out all the aircraft, or give them an indicator that makes it look like they've spent all their movement and unable to attack, it would undermine the arguably greatest benefit of having the indicators in the first place: You have no other way of knowing which aircraft have moved, and which ones have not.

Huh, I never knew all aircraft are immobile. You can even remove the immobile flag then move them around the map like normal units, over both water and land. That's neat. Anyway it would have been a simple matter to carve out an exception for immobile air units and ICBMs, etc. When I posted that I was thinking of immobile land defender units, like in Tides of Crimson there are tower units you can build whose only function is to defend the city they were built in. Also I wasn't going to gray them out entirely, as in make them non-clickable, just give them the gray "off" LED indicating they can't move.

Any ETA on the fix for Civinator's issue with war declarations?

Is this affecting you too? Like @Civinator said, I'm waiting for the CCM 3 files so I can reproduce the issue. He already sent me the save. I have an idea for how to fix the problem, based on a guess as to what's causing it, but if I can't reproduce the problem then I can't check my guess, and couldn't even verify that any fix I implement actually works.

 

[Civinator]

Huh, I never knew all aircraft are immobile. You can even remove the immobile flag then move them around the map like normal units, over both water and land. That's neat.

Yes, this would be an especially interesting setting for helicopters. The big problem since the release of Civ 3 is, that in Civ 3 there is a special programming, that destroys every mobile air unit when a land unit of another civ is drawing on the tile with the mobile air unit without any regard to the defense values of the mobile air unit (exception HN air units with defense zero, explained here in German language in 2008). I think it is the same programming, that destroys all air units in a city that is captured by an enemy land unit.

Is this affecting you too?

LKendter organizes a team of dedicated Civ 3 players in the CFC succession games. In a succession game each player plays several turns in a game and writes down meticulously all actions of the player and against the player in a turn of that game. Since many years the team plays with the mod CCM, what is a great help in developing and improving that mod. The succession games played with the mod CCM mostly have the suffix CCM in their titles and (in addition) carry several additional hundreds of thousands of views of CCM-experience in them.

The team is waiting for the CCM 3 files in combination with the R17C version of the Flintlock mod to start their next succession game - and if the upload of the CCM 3 files will work well, they won´t have to wait long for it.

 

[Erlend Philip Wood]

I agree that the best way to minimize player confusion would be to match the movement LEDs on the menu with the LEDs already on top of the HP bars. That does complicate things somewhat since the base game LEDs have five different colors, three in between green and red. I could of course ignore two of those and use the middle yellow for everything in between, but if I'm going to replicate the base game's LEDs then I'll feel compelled to replicate them exactly. That means I'd have to look up exactly how the game picks which color to use. Not really a big deal.

It is true that the game provides 5 different shades for movement LEDs, but in practice it only uses the green, yellow and red ones. The yellow-green and orange ones are not in use. You can check this by giving a unit very high movement, say, a Warrior with 20 moves. It will start green, then stay yellow throughout every move, before it turns red on the last one.

The sword icons are eyesores in my opinion. Though I can't think of any better way to indicate attackers with the base LEDs. Maybe give the attackers' LEDs a red outline instead of black? Or leave the black outline and make the non-attackers' outlines white? Maybe the attackers' LEDs could be brighter? I don't know that those would look good and they might confuse players which would defeat the point.

I think there are a couple of advantages to using a sword symbol. First, it is easy to understand: Sword = combat. Second, having a symbol that is separate from the LED is easy for the eye to pick out. If you are attacking with a stack, and only need to know which units are available to attack with, you can just look at the swords and ignore the rest.

Out of the other alternatives suggested, I think it might work if there was an easily recognizable black ring around the LEDs of units that can attack (as a halo, sort of). I don't think any colors other than black, white or gray would work because they might interfere with the colors of the LEDs themselves.

Anyway it would have been a simple matter to carve out an exception for immobile air units and ICBMs, etc. When I posted that I was thinking of immobile land defender units, like in Tides of Crimson there are tower units you can build whose only function is to defend the city they were built in. Also I wasn't going to gray them out entirely, as in make them non-clickable, just give them the gray "off" LED indicating they can't move.

I suspect this would have caused more problems than it solved. What would determine which units qualify for the exception? The standard game and almost every mod have many immobile air units. If an exception were to be made, I think standard behavior should be the norm, and rare cases such as immobile land units with limited abilities, the exception. Units can have many special properties. In cases such as this, I think it would be better to just write it in the Civilopedia. Most of the potential for misunderstanding which units can move or not will disappear once the text with explicit orders is implemented.

Yes, this would be an especially interesting setting for helicopters. The big problem since the release of Civ 3 is, that in Civ 3 there is a special programming, that destroys every mobile air unit when a land unit of another civ is drawing on the tile with the mobile air unit without any regard to the defense values of the mobile air unit. I think it is the same programming, that destroys all air units in a city that is captured by an enemy land unit.

I've also experimented with unrestricted movement ability for helicopters (and airships). But their lack of ability to defend themselves is a problem, and the AI seems to have trouble taking advantage of this ability. So I gave up on the idea.

I wish helicopters could do something like an Airdrop/Rebase mission to any tile on the map instead (within its operational range). Let's call the ability Land or Relocate or something. Then the ability of helicopters to land and rebase anywhere would be their special power that separates them from other aircraft. Transport helicopters could land somewhere within 6 tiles, and pick up infantry to evacuate them or move them quickly to a new location. Or you could land a helicopter on the coast, to shuttle infantry across a narrow strait to a different continent. Attack helicopters with limited range could be compensated by placing them closer to the front lines. Just some thoughts I had while creating Attack Helicopters for my mod, but it probably isn't doable.

 

[Ozymandias]

I wish helicopters could do something like an Airdrop/Rebase mission to any tile on the map instead (within its operational range). Let's call the ability Land or Relocate or something. Then the ability of helicopters to land and rebase anywhere would be their special power that separates them from other aircraft. Transport helicopters could land somewhere within 6 tiles, and pick up infantry to evacuate them or move them quickly to a new location. Or you could land a helicopter on the coast, to shuttle infantry across a narrow strait to a different continent. Attack helicopters with limited range could be compensated by placing them closer to the front lines. Just some thoughts I had while creating Attack Helicopters for my mod, but it probably isn't doable.

I don't think that limiting Airdrop/Rebase missions to helicopters is a good idea, unless it is an option. Better yet (except that I imagine that both are too deeply embedded in the code to address) would be:

1. To have aircraft "properly" use aircraft carriers, and,
2. To have helicopters be able to land on an aircraft carrier, while carrying troops.

 

[Ozymandias]

I've also experimented with unrestricted movement ability for helicopters (and airships).

The only instance of an aircraft having "unlimited movement" is in the WW2 Pacific scenario - where the B29 is flagged as a nuke

 

[Erlend Philip Wood]

I don't think that limiting Airdrop/Rebase missions to helicopters is a good idea, unless it is an option.

I wasn't thinking of removing other aircraft's abilities. Just that helicopters could have an entirely new skill which is special to them, to be able to land (rebase) on any land tile on the map (within operational range). Then that location would become its new base of operations. Which isn't too unrealistic, one of the advantages of a real life helicopter is its ability to land virtually anywhere.

 

[Ozymandias]

I wasn't thinking of removing other aircraft's abilities. Just that helicopters could have an entirely new skill which is special to them, to be able to land (rebase) on any land tile on the map (within operational range). Then that location would become its new base of operations. Which isn't too unrealistic, one of the advantages of a real life helicopter is its ability to land virtually anywhere.

What do you think about my idea re: Loaded Choppers landing on Carriers? This would be the equivalent of any modern assault ship carrying marines.