CCM2 Epic Mod

vmxa, thank you very much for all those interesting informations about the Remnants of the Precursors project. :)

And now back to CCM 2.50: Has anybody tried this mod with the Flintlock patch? Are there any suggestions about a good railroad movement rate for CCM2 in combination with this patch ?
 
Let's start over. I tried without the Flintlock updates and with it, but I do not get an icon for workers to mine. I have it for irrigation. I see the pedicons for Mine. I do not see any tech required
to gain the mine command. This is for the Gog version of complete.

I had played a game out to 3 towns, but never got the ability to mine any terrain. Just road and irrigate. I tried on a scenario map and a normal map.

This was from a new download of CCM.
 
Last edited:
Civinator, I did not check to see if this was previously reported, Balloons cannot be upgraded to Zeppelins. The biq file entry for Balloons does not have the "upgrade flag" checked.
 
Let's start over. I tried without the Flintlock updates and with it, but I do not get an icon for workers to mine. I have it for irrigation. I see the pedicons for Mine. I do not see any tech required
to gain the mine command. This is for the Gog version of complete.

I had played a game out to 3 towns, but never got the ability to mine any terrain. Just road and irrigate. I tried on a scenario map and a normal map.

This was from a new download of CCM.

vmxa, sorry for the delay in the answer. To activate the stack worker commands of the Flintlock patch you have to press the control key on your keyboard. Than the worker stack buttons are appearing, even the mine button. Please take into account, that in CCM you cannot mine grassland. Here is a screenshot with the R7 version of the Flintlock patch:

Worker Stack Mine.jpg


Here is the instruction from the readme file of the Flintlock patch:

STACK WORKER BUTTONS:

Hold the control key (STRG) to turn all standard worker buttons into stack buttons. Clicking a stack button will issue the command to all workers on the same tile.
 
Civinator, I did not check to see if this was previously reported, Balloons cannot be upgraded to Zeppelins. The biq file entry for Balloons does not have the "upgrade flag" checked.
That's deliberate, IIRC. I seem to recall Balloons not upgrading in several of the CCM games.

In CCM it is intended, that the balloon cannot upgrade to planes. The main task of the balloons in CCM was to help finding the houseboat when the houseboat bug appears. As this bug now is fixed with the Flintlock patch, :worship: in the next version of CCM I reflect about setting the balloon to a scout that can cross land and water, but has no defense against attacks.

The balloons were - and are - never intended be the base of a big airforce.
 
I had no problem with the stack commands in non ccm games, it works fine. You still would see the icon for mining in std, with Flintlock patch. I had forgotten you cannot mine grass in 2.5, will have to go back and see, if I was on grass or not, thanks for the reminder.
 
Last edited:
In CCM it is intended, that the balloon cannot upgrade to planes. The main task of the balloons in CCM was to help finding the houseboat when the houseboat bug appears. As this bug now is fixed with the Flintlock patch, :worship: in the next version of CCM I reflect about setting the balloon to a scout that can cross land and water, but has no defense against attacks.

The balloons were - and are - never intended be the base of a big airforce.
I have no problem with balloons not upgrading.
The Civilopedia page for Balloons shows they upgrade to Zeppelins. Which is the reason I mentioned balloons not upgrading.
 
The Civilopedia page for Balloons shows they upgrade to Zeppelins. Which is the reason I mentioned balloons not upgrading.

It is always the same situation with the wrong hardcoded link. The civilopedia describes it as precise as possible:

Obsolescence.jpg
 
In my current CCM 2.50 testgame a somewhat strange situation occured:

I attacked a Japanese pikeman, who was transporting a supply shipment to the Japanese capital with my German lawyer to gain that supply shipment. The lawyer won and I directed the captured Japanese supply shipment towards my own capital and guarded my damaged lawyer with a German pistolrider. Now a Japanese Yogi appeared from the Japanese territory and occupied the tile in my territory containing the supplyshipment.

Strange1.jpg


I tried to attack the Yogi with my pistolrider but to my astonishment the German pistolrider didn´t attack the Japanese Yogi, but shared the same tile with the supply shipment and the Yogi.
Strange2.jpg

Now I could draw out the Japanese supply shipment again towards the direction of my capital, moved the pistolrider on the road on my territory out of the tile that he had shared with the Yogi and was able to attack the Yogi (now from the opposite direction where I had started that attack).

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

...and another item: Worker stacks in CCM and the Flintlock Patch

It seems when playing CCM with the Flintlock patch and using the worker stack commands, these commands must be done several times when different kinds of workers are in the same tile. I had to give the command for groups of workers on the same tile for the slaved workers, the upgraded workers for the civ and the normal standard workers. I also sometimes had to give that command separately to enslaved Barbarian workers.
 
Last edited:
Civinator... Unless I am missing other settings you are working with it seems to me that Because the Supply is a Japanese Unit, it is allowing another Japanese Unit to occupy the same tile.
Set the Supplies to be captured by any Civ then the Supply will belong to the Civ that captures it.
 
Vuldacon, in CCM the supply shipments can be captured by any civ - and the supply shipments can be moved without an escort over the map. Only for the last turn into the capital an escort is needed.

The ownership of that supply shipment (the civ who can give movement orders to the supply shipment) changed 3 times in two turns: First from Japanese ownership after the attack of the lawyer to German ownership, in the next turn from German ownership to Japanese ownership by the yogi attack and in the same turn, when the German pistolrider moved into the tile with the yogi and the supply shipment, the German civ was able to gain control over the supply shipment again and to move it out of that tile and than the pistolrider after leaving the tile with the yogi was able to return and to attack the yogi on that tile, what was not possible in the first attempt of the pistolrider. It seems the Yogi didn´t push the escort button for the supply shipment.

For me the most astonishing fact was, that the attack of the pistolrider against two enemy units (yogi and supplyshipment) didn´t lead to a fight but to a sharing of the same tile.
 
Civinator, 2 comments about pages in the Civilopedia:
a) I just noticed that the entry for "The Great Iron Mine" lists one of the benefits is to increase shield production by 25%. However, the biq file does not provide this benefit.
b)
It is always the same situation with the wrong hardcoded link. The civilopedia describes it as precise as possible:

View attachment 605799

The section, just below the area you highlighted, shows: "Cost: 40 Upgrades To Zepplein"

Why not just remove the phrase "Upgrades To Zepplein" ?
 
Why not just remove the phrase "Upgrades To Zepplein" ?
Unfortunately not possible: as Civinator points out, that part of the unit-description screen (along with the "Stats" section below) is generated from entries in the labels.txt file:
Code:
Stats
Attack
Defense
Movement
Operational Range
Population Cost
Bombard
Range
Rate of Fire
Anti-Air Defense
Transport Capacity
Air Superiority Radius
Upgrades To
...and the executable extracts the respective information directly from the .biq, to fill in the 'blanks' after these labels.

So even if one were to replace "Upgrades To" label with a blank line, the "Zeppelin" would still be displayed, but without any explanation.

However, it would certainly be possible to edit the text-line, from "Upgrades To" to e.g. "Replaced By" -- which would (kinda sorta) cover both upgrades and obsolescence.
 
Last edited:
What does it parse to figure out what a unit upgrades to? Not all units upgrade!

Whatever connection to Zeppelins that Balloons have -- break that connection? Or is that impossible with some trickery about Civ3 air units?
 
What does it parse to figure out what a unit upgrades to? Not all units upgrade!
The Units tab in the Editor contains 2 attributes: an "Upgrades to" pull-down text-box (populated by a list of all the units in the mod), and the unit-action "Upgrade" check-box (along with check-boxes for "Fortify", Load", "Capture", etc.).

For any given unit, if the Modder fills in the former, and ticks the latter, the unit will be upgrade-able, and (when an outdated unit is in a Barracks-town, with all required resources available) the "Upgrade" unit-action button will show on the main game screen.

To generate the Civilopedia entry, the executable reads the "Upgrades To" box, and follows along the upgrade-chain until it finds the first valid unit which is available to that Civ, to fill in the blank for the next available unit in the upgrade-chain. But it does that regardless of whether or not the "Upgrade" action is also ticked.

So when the Mod-maker doesn't tick the "Upgrade" action, the prior unit will simply become unbuildable -- and non-upgradeable -- once the next unit in the chain becomes available.
Whatever connection to Zeppelins that Balloons have -- break that connection? Or is that impossible with some trickery about Civ3 air units?
The only way to break the connection, would be to remove "Zeppelin" from the "Upgrades To" box for the Balloon unit.

But then, after the Zeppelin-tech is researched, a player would still be able to build Balloons.
 
Last edited:
The Units tab in the Editor contains 2 attributes: an "Upgrades to" pull-down text-box (populated by a list of all the units in the mod), and the unit-action "Upgrade" check-box (along with chack-boxes for "Fortify", Load", "Capture", etc.).

For any given unit, if the Modder fills in the former, and ticks the latter, the unit will be upgrade-able, and (when an outdated unit is in a Barracks-town, with all required resources available) the "Upgrade" unit-action button will show on the main game screen.

To generate the Civilopedia entry, the executable reads the "Upgrades To" box, and follows along the upgrade-chain until it finds the first valid unit which is available to that Civ, to fill in the blank for the next available unit in the upgrade-chain. But it does that regardless of whether or not the "Upgrade" action is also ticked.

So when the Mod-maker doesn't tick the "Upgrade" action, the prior unit will simply become unbuildable -- and non-upgradeable -- once the next unit in the chain becomes available.
So why in the biq file does the entry for Balloon have in its Upgrades To" box, "Zeppelin"? As Elephantium suggested: Why not replace "Zeppelin" with "None"?
 
I just noticed that the entry for "The Great Iron Mine" lists one of the benefits is to increase shield production by 25%. However, the biq file does not provide this benefit.

Jersey Joe, thank you very much for reporting this error. :) For that SW I wrongly enabled 1 pollution instead of 1 production (= 25 %). This is fixed now for the next version of CCM 2.50.

Why not just remove the phrase "Upgrades To Zepplein" ?

Unfortunately not possible: as Civinator points out, that part of the unit-description screen is hardcoded (as is the "Stats" section below), and the executable extracts the respective information directly from the .biq, to fill in the 'blanks' after the labels in the labels.txt file.

However, it would certainly be possible to edit the text-line from "Upgrades To" to "Obsoleted By" -- which would cover both upgrades and obsolescence.

As tjs282 pointed out, the wrong entry (in this case Zeppelin) unfortunately is hardcoded and until today nobody had found a way to wipe this hardcoded wrong entry completely out of the civilopedia when a unit cannot be upgraded, but becomes obsolete. Experiments with a super long labels text for that entry, in the hope, that this will push that entry out of the readable era of the civilopedia, were not done by me, as that entry also must fit the mostly happening upgrade situation, too.

In the past the wrong hardcoded entry in CCM caused confusion especially with battleships becoming obsolete by aircraft carriers.

What can be changed is the short labels text in that hardcoded entry. A labels text, as tjs282 suggested it, would be possible (edi:

Ballon-obsolete with.jpg


Edit: The text in the link for obsolescence will be reworked for autoproduced unit lines.

Obsolescence.jpg
 
Last edited:
Top Bottom