Making Cradle 3+ fully compatible with the Apolyton Edition

[Kull]

This is going to be a rambling thread, which meanders here and there but hopefully winds up achieving the goal as stated in the the thread title. I started playing around with this several months ago and have made quite a bit of progress, but it always feels like "one step forward and two steps back". Probably because the goal isn't simply to make Cradle compatible with AE, but additionally to make use of many of the new AE features and to add some new bells and whistles. Assuming this beast can be wrangled, it will still be recognizably "Cradle", so rest easy on that count.

Anyway, first some kudos to the Source Code guys for all their great work. The more I dug into this, the more it became obvious that they've added loads of new modding functionality which - sadly - has gone largely unutilized. One exception to that rule is BureauBert's "Modern Times" mod which is worth looking at even if you don't speak German! Even more so, his CTP Bureau is a wonderful resource, and my halting progress would have been impossible without it.

That's a good segue, because my particular journey began with BureauBert's version of Cradle 3.03 which he modified so it did not require Modswapper and would run from the "Scenarios" folder. Long story short, I found several problems with that approach:

1) When you start a New Game, it ALWAYS defaults to the base game's "civilisation.txt" file (the one in ctp2_data\default\gamedata) when presenting the list of civs to choose. This has several effects, none of them good (although you can work around the problem):
- You will always see "Aborigine" first, even though that is not a "Cradle" civ
- The base game file has 72 civs while Cradle has 33
- If you choose any civ that is numbered 34 or above, the game will CTD. For example, "Aborigine" is #60 on the AE list, even though - alphabetically - it appears first on the selectable list.
- The workaround (which is not intuitive) is to select a starting civ based on the Civ number in the Cradle "civilisation.txt" file. For example, if you want to play as the Egyptians (Cradle Civ #12) you have to select the Russians (Civ#12 on the AE list).

2) The Great Library uses the file in the Scenario folder on new games, but when loading a save game it reverts to the base game's GL file (the one in ctp2_data\english\gamedata). Again there is a workaround, and again it's not intuitive. Start a new Cradle Scenario campaign and then IMMEDIATELY load your Cradle save game.

There may be more problems like those, but that was enough for me. This is supposed to be fun, not an ordeal. There had to be a better way, and in fact there is.

[Kull]

The solution is to add a Cradle folder just one level down from the base game folder (i.e. the same level as "Scenarios" or "ctp2_data"). In order for the game to "see" this new folder (which I call "Cradle3"), you have edit the "Ruleset" line in the ctp2_program\ctp\userprofile.txt file.

Normally that line looks like this: "RuleSets=" (that's right, nothing comes after the = sign)

However, if you change it to this: "RuleSets=..\..\Cradle3", the game will now process all files found in that folder before looking for equivalents in the ctp2_data folder. An immediate cure for the Civ list and GL bugs noted above.

Worth noting that "..\..\ is NOT shorthand notation for "type in your actual folder structure". Type those EXACTLY as they appear - a set of periods and slashes. I spent an inordinate amount of time typing in new and altered folder structure variants before - like Gandalf at the Gates of Moria - I realized the solution was as simple as it appears. Der.

Anyway, this allows you to install the full range of customized features one would theoretically get from the Scenario system, but with none of the headaches and without altering ANYTHING in the base game folder....well, other than "userprofile.txt", of course. Oh, and should you desire to play a non-Cradle game, just edit the "Rulesets" line back to it's original setting.

[Kull]

Cradle 4 added an interesting new Wonder ("Dynastic House") which provided the "Great King" Wonder unit. Unlike all the other Cradle Wonder Units, this was not a historical figure, but a somewhat generic character meant to represent the leaders of the first Empires of the ancient near east. I liked the idea, but it seemed a shame that - as with all Wonders - only one civilization could have such a leader.

My concept was a structure (and Wonder Unit) available to all civs - and much earlier in the game - so that you begin to see more AI cities with slaves (currently rare), and a way for even the weakest civs to acquire a powerful leader unit. And with the new AE modding options, this idea is now a reality:

- "Dynastic House" is now an improvement listed in "buildings.txt"
- It has the new "oneperciv" attribute (thus ensuring only per civ) but also can only be built in a city with a "Capital" building (which avoids a multiple build queues exploit)
- It requires the Dynasty advance (so it appears at the right time, early in the game)
- The cost is much lower than a typical Wonder and the AI priority is high.
- The building provides a 20% reduction in anti-war sentiment (oppose the Great king at your own risk) and gives 1 gold per citizen (war loot always comes to the capital city first). Worth noting that I originally used the Cradle building attributes but not only are they purely for Wonders, they keep the building from appearing in the Great Library!
- A small slic file generates the Great King unit
- As in Cradle 4, the GK uses the "slavemaster" record in the GL (and units.txt & gl_str.txt)
- The sprite and 2D pix were shifted from Legion to Chariot (more appropriate for this era)
- Potentially (not coded yet) the Great King will "expire" with the advent of the first "modern" gov (i.e. after Tribunal Empire)

I've tested this and everything works, so hopefully it will be a nice new feature in Cradle 3+

[Kull]

City Specialists: The sliders that allow you to assign citizens to specific tasks (Entertainer, Farmer, etc) are controlled by Pop.txt (in Cradle it's "CRARR4F_Pop.txt", although - for the record - I'm not using any of the Cradle prefixes in the Cradle3 subdirectory system). Specifically, which Advances turn on each slider. The Cradle GL did not address this properly, since in the "Specialists section" many of the listed advances are those from the base game, and there was nothing in "Advances section" (both are now fixed).

As an aside, Pop.txt is not a file that was changed by the Source Code team, but the Cradle version has an additional piece of code titled POP_ZERO_IGNORED which is included because "Mayors ignore the first pop record, this fixes the problem with low happiness not being handled correctly by mayors."

I haven't removed it (at least for now), although this portion of the "Apolyton_README.txt" indicates that the issue may have been resolved:

Fixed: Basic AI population assignment.
- If cities has slaves the number of pops to assign is calculated correctly.
- The first pop in the database can now be used, meaning AI can use entertainers.
- The minimum amount of calculated entertainers can now be assigned.
- However this are only basic fixes, population optimisation has still to be done.

[Kull]

City Size: This is rather complicated, and took me quite a while to figure out.

- First of all there are SIX "difficulty-setting" files named "citysize0.txt" through "citysize5.txt". However, the Cradle values are identical in all of them, so difficulty levels have no effect on this facet of the game.

- The other file which controls City Size is "buildings.txt", more specifically the "RaiseMaxPopulation" code assigned to the six buildings needed in order to grow beyond a particular city size limit. For example, "Apothecary" has a RaiseMaxPopulation value of 8.

- Returning to the "citysize*.txt" files, they contain a "BaseMaxPop" level which is assigned to each city-size level. Which is where the problem arises, since that number is 12 for city levels 1 and 2 (i.e. the base value is 12 at Level 1 while Level 2 is 12+8 after the Apothecary is constructed). However, at Level 3 the "BaseMaxPop" level changes from 12 to 16. Which means the city sizes are ACTUALLY capped as follows:

- Level 1: City size is capped at 12 until Apothecary (+8)
- Level 2: City size is capped at 20 until Physician (+10)
- KEY POINT: The BaseMaxPop changes from 12 to 16 at the next level. So although the Great Library tells you the new cap is 30, it's REALLY 34!
- Level 3: City size is capped at 34 until Bath House (+10)
- Level 4: City size is capped at 44 until Drug Store (+10)
- Level 5: City size is capped at 54 until Hospital (+14)
- Level 6: City size is capped at 68 until Arcologies (+12)

Obviously this means there's a disconnect between the actual city level population caps and those cited in the GL, where most max populations supposedly rise in increments of 10 (from 20 to 30 to 40, etc.) Accordingly, I'm going to adjust the "BaseMaxPop" level from 16 down to 12 in all the Level 3 and above cities, and will do so in all six "citysize*.txt" files.

[Kull]

I'll post more on the topic in a different thread, but I was able to create a new "Camel" sprite as you see below. It's not currently intended for use in Cradle, but that could change.

[Kull]

SLIC Files: A number of SLIC files are no longer needed, thanks to Source Code improvements. BureauBert's Cradle scenario eliminates or replaces 3 of them, and I've followed his lead with Cradle 3+.
- "Frenzy.slc" was developed in order to make the AI more aggressive, but that is no longer necessary in AE, given the new AI improvements.
- "Diplomod.slc" has been replaced by "diplomacy.slc" (a file included with the AE update)
- "Goods.slc" is not needed either, since the additional goods are now part of the base game.

He also commented out a fourth file ("pw_cheat", which adds gold and public works for AI civs), but that appears to be an incomplete action. The MoT mod uses a similar file called "pwcheat.slc", which features improved coding, and I suspect that BB planned at some point to implement a similar replacement for his Cradle scenario. Anyway, Cradle+ will use the file from MoT.

Lastly, BB developed a new slic file for MoT ("settling.slc"), which adds a strategic component to the AIs city selection algorithms. A "Cradle-specific" version of this file was included with his scenario pack, and that will be part of Cradle3+ as well.

Given the new Cradle 3+ folder structure, most of the slc files are activated by code located at the bottom of "script.slc", and that's where you'll see these and additional changes that I'll discuss in upcoming posts. Worth noting that although "frenzy" has been deactivated, BB created a "new and improved" version for his MoT mod, and I'll include that file with the Cradle 3+ download, but leave it unactivated. Those players who desire an even more aggressive opponent can edit "script.slc and remove the "// " from the #include "frenzy2.slc" row.

[Kull]

"Const.txt": As the name implies, many of CTP2's "constants" can be found in this file. A comparison of the Cradle file vs. the AE version (Winmerge is very helpful in this regard) identified a number of improvements (AE has 8 new settings appended at the bottom of the file), so Cradle 3+ uses the new AE file. Although I kept a majority of the Cradle settings (most of which come from the base game or were borrowed from MedMod), in a few cases I went with the AE settings or my own. For example, I altered the river settings and now you see more of them (and longer) in Cradle 3+ games.

[Kull]

Unit Upgrades: One of the best new features of the Apolyton Edition is the built-in unit upgrade system. It's controlled by a button on the interface, and the human player can update units at any time and in any order. The AI has this benefit applied to all affected units immediately after discovering the associated advance, which definitely adds to the "degree of difficulty". After a lot of research, all "non-Special" Cradle units now have the complete upgrade path added to units.txt. Transport-type ships now upgrade from Coracle-to-Crawler, artillery types from Belfroi-to-War Walker, missile units from Slinger-to-Hover Infantry, etc.

[Kull]

Updater.slc: Unfortunately the new system does not apply to the Cradle Militia (garrison units created when a city is founded) or Cradle Elite units (government-specific land units which who can receive "battlefield promotion" into non-government-specific units of an improved type). Because these Militia/Elite units are - by definition - unbuildable, there's no way to upgrade them normally, so the SLIC system is still utilized for this subset of unit types. The good news is, it has been improved! The old code only gave you one chance to upgrade, for example, from Elite Legion to Elite Pikeman. Miss that opportunity and you were stuck with Elite Legions forever. But stripping out all the non-Elite/Militia upgrade code (now handled by the built-in upgrade system described in the post above) cut the file size by more than half, and allowed me to add upgrades from every lower level to any higher one. For example, Hoplite Elites can be upgraded directly to the highest available level. So upgrades from Hoplite Elite to Pikeman Elite, Arquebusier Elite, Infantryman Elite, Machine Gunner Elite and even Hover Infantry Elite are all possible.

This increase in the number and types of possible upgrades identified a problem with the original update code. For some reason, if you choose a "partial update" - upgrading some units of a particular type instead of "All" - the code shuts down without warning after the second time it runs. And that applies whether the "second time" is in the same series of updates or those chosen during a different turn. Fortunately this does not cause a CTD, and you'll only get a warning message if Debugslic=Yes (see below). I've looked at the code but the complexity is well beyond my ability to understand, much less fix. The only solution I can suggest (and remember - this is not a new issue, but one that has always been present in the code as verified by testing a non-AE Cradle install) is to avoid "partial updates". If you don't have the money to do all of them, wait until the next opportunity - of which you now have plenty!

[Carolus V.]

Hello Kull. First of all I want to say, that this is a very ambitious venture. Respect for that. And maybe I can help you a bit with this Elite.slc Problem, if it is a Problem for you anyway. There are two lines in the Const.txt file which will give you on the one Hand Elite Units, and on the other Hand Leader Units. These are namely:
COMBAT_ELITE_CHANCE 0.20
COMBAT_LEADER_CHANCE 0.05
0.20 and 0.05 are the Chances to get either an Elite Unit or an Leader Unit (out of an Elite Unit) if succsseful in Battle, no matter if you are the Attacker or the Defender. One Thing wiith Leaders is you have to specify this (Leader) Unit in Units.txt.
So maybe, I could´ve helped you a bit, and if you knew this already than my apologies.
Finally I´m very pleased that CTP II isn´t truly dead.
Thank you for your Afforts.

Walter

[Kull]

Hello Kull. First of all I want to say, that this is a very ambitious venture. Respect for that. And maybe I can help you a bit with this Elite.slc Problem, if it is a Problem for you anyway. There are two lines in the Const.txt file which will give you on the one Hand Elite Units, and on the other Hand Leader Units. These are namely:
COMBAT_ELITE_CHANCE 0.20
COMBAT_LEADER_CHANCE 0.05
0.20 and 0.05 are the Chances to get either an Elite Unit or an Leader Unit (out of an Elite Unit) if succsseful in Battle, no matter if you are the Attacker or the Defender. One Thing wiith Leaders is you have to specify this (Leader) Unit in Units.txt.
So maybe, I could´ve helped you a bit, and if you knew this already than my apologies.
Finally I´m very pleased that CTP II isn´t truly dead.
Thank you for your Afforts.

Walter

Thanks for looking into that. There's definitely a terminology issue at work here, because there are two completely different meanings for "Elite Units"

1) In Cradle, victory in battle can result in some units being upgraded from "normal" to an entirely different unit. For example, the basic Spearman could be "promoted" to a new unit called "Elite Spearman". Different stats, different entry in units.txt, everything. All this is handled by a SLC file called "updater.slc".

2) The Source Code project added a new in-game promotion possibility for units which goes one step beyond "Veteran". In that case, Veterans can be promoted to "Elite", but it's the same unit, just with improved stats. This is the "Elite" code you spotted in Const.txt, but it has no effect on the "Cradle Elite" issue.

That said, the two systems are fully compatible, and eventually I expect that we'll see in-game instances where some "Cradle Elites" are promoted to "Source Code Elites".

Anyway, the updater.slc code works fine under normal circumstances, but it collapses when trying to do partial upgrades (i.e. when the player is given the choice of updating some (but not all) Cradle Elites to a higher unit level. I probably can't fix that, so eventually - unless a SLIC coding expert shows up and is able to identify the problem in the code - I'll try to identify and remove the offending portion of the code, although I'm not a coder by training.

[Kull]

Two different "Emerald Goods": Unique among the on-map Goods there are two Emeralds, each with a different "sprite". Those in polar regions feature a bluish triangle-shaped gem, while those in mountain terrain use the original CTP rectangular green. They have the same stats, but importantly, Emeralds aren't found in polar regions, nor do they look much like the triangular ones we see in-game. This seemed like a good opportunity to substitute something a little more "region-appropriate".

Which is what you see in the attachment. A newly created "Polar Bear" sprite replaces the Polar Emeralds, with new stats and a write-up in the Great Library. As a helpful by-product, I spotted a statting problem with the "Mountain Emeralds" which prevented them from appearing in the GL, but that has been fixed as well.

[Kull]

Veteran Stacking "Bug": Several of the Wonder Units are said to "grant veteran status" to any units they are stacked with. This is not a built-in game feature, but is controlled by slic code in the "wonderunits.slc" file. That in turn is modified code from the Activision-created Alexander scenario. I've always been a bit intrigued as to how that would work, since the code itself seemed to be very simple in nature, mostly focused on identifying those units to which it would NOT apply.

I spent some time studying the Alexander scenario, looking for evidence of the code in action, and there's no doubt that it works. Units which start a turn in the same hex with the Alexander unit ALL had Veteran status, clearly visible with the Veteran unit flag. This status wasn't conditional on staying with Alexander DURING the turn - they remained "Veterans" even when moving separately. However, any units which were not stacked with Alexander at the end of the turn, LOST VETERAN STATUS at the beginning of the next turn.

Which explains why the code is so simple. It completely alters the Veteran mechanism, assigning and removing it ENTIRELY on the basis of whether a unit is stacked with a "Veteran-status-granting" unit. For example, even units that gained Veteran status normally - during combat - lost it at the start of the next turn.

Interestingly, the code never actually worked in Cradle. Units that supposedly granted the status - did not. So rather than try to impose a questionable mechanism, I've opted to remove all mention of it from those Cradle units which allegedly had this power.

[Kull]

Stone Roads graphics issue: A very minor issue, but the "Tile" tab on the selection interface is where the player chooses which Tile Improvements to build. Although the Cradle picture directory includes a Stone Road graphic, even in Cradle4 the visual menu showed the same graphic (top image) for Roads and Stone Roads - and the GL entry did as well. Both issues have been fixed in Cradle 3+ (bottom image).