Making Cradle 3+ fully compatible with the Apolyton Edition

[Kull]

Special Attacks Project Overview: To give you some idea of the process being utilized as the "Special Attack" sub-project continues, we'll start with the "orders.txt" file which has 47 orders or "attacks". Nineteen of these are standard unit orders (Move, Attack, Settle, Board, Unload, etc) or obsolete (Airlift, Ranged Attack, etc). The remainder can be categorized as follows:
1) Religious Attacks (5)
2) Commercial Attacks (2)
3) Legal Attacks (3)
4) Espionage Attacks (3)
5) Diplomacy "Attacks" (3)
6) Slave-related Attacks (4)
7) Terror Attacks (6)
8) Military Special Attacks (3)

Of that group, I'm conducting a DETAILED analysis on each individual Order or Attack:
- How (and if) it works.
- Whether the graphics, messages, and sounds follow the same theme (and which are wrong, don't mesh, or don't work at all)
- Determine if the graphics, messages, and sounds are appropriate for all eras, and if not what can be done?
- Does the AI use each attack, and if not, why not (as much as that can be determined)
- Study the impact of each attack's "cost to perform" on whether a given attack is used by the AI.
- Look at the capabilities of the units which deploy each attack and see if they help or hinder.
- Deal with "other problems" that pop up during testing.

As each analysis concludes, I then go through and make the improvements and changes resulting from that review, and then run playtests to see if those changes actually work. In short, it's exhaustive and exhausting, especially since so many of these orders or attacks are, well, problematic.

Coming down from the overview level, let's take a look at Diplomacy. There are three purely diplomatic "attacks": "Establish Embassy" (provides better intelligence on the target civ), "Hold Reception" (aka "Throw Party"; improves relations with the target civ), and lastly "Hear Gossip" (possibility of learning one of six categories of information about the target civ). The diplomat can also "Investigate City", but that's more of an Espionage Attack and will be reviewed as part of the Spy group analysis.

1) "Establish Embassy": At first glance, this "attack" seems like a no-brainer. It's used by three units (Diplomat, Ambassador & Empathic Diplomat) and has a Button icon (building w/flag), Messageicon (flag), Cursor (building w/flag), Sprite (trumpets), Sound (trumpet fanfare) & Messages (all of which exist and display when required). Best of all, the AI knows how to do this, and builds Diplomats and deploys them appropriately (see attachment).

The problem is that AI civs tend to have very few established embassies. Part of the problem is they are at war with so many of their neighbors, and the Embassy Mechanism does not operate when that is the case between sending and receiving civs. The cost was low enough not be an issue (250 gold), but the real problem - as testing eventually showed - involved the unit capabilities.

Diplomats are not Stealthy, so when the AI would see a foreign Diplomat, inevitably they would Expel it from their country. Oddly enough, Diplomats could see stealthy units, but did not have invisibility themselves. So I reversed the capabilities. With the new settings, Diplomats can't see stealth units since, after all, they aren't spies. But now they are stealthy and while they retain the ability to move two squares, they no longer have a vision range of 2. In the same way that "stealth vision" is more appropriate for spies, "distance vision" is a feature of Military Scouts - and Diplomats shouldn't be statted like that. With these altered capabilities, the Diplomat should be able to arrive in a foreign country, move to a city without interference, and once there, establish an embassy. If the two civs are at war, the Diplomat can park nearby, where it is unlikely to be seen and expelled. And once the war is over? Embassy.

And that's what testing showed. In a twenty civ game, by 1000 BC there were less than one embassy per civ, in spite of having potentially 19 "neighbors" each. By contrast, after altering the diplomat unit stats, a follow-on playtest resulted in an average of 4 embassies for every civilization. And they were much less likely to be at war or stay at war with distant civs, as indicated by a large number of ceasefire icons.

[Kull]

Liberate City Issue:

One of the new features added by the SC team are three options after the player captures an enemy city: 1) Keep it, 2) Raze it, or 3) "Liberate" it. The last choice gives the city to the Barbarians, which is a neat option. I played around with this during a playtest, and used it to hamstring an AI opponent by capturing a group of cities and "liberating" all of them. Which gave that civ something besides me to worry about for a while. The problem (as reported elsewhere) is that your victorious army is trapped inside the city, and can't leave - at least not by "walking out".

The attachment has 4 screenshots, and the first three illustrate the problem. After conquest, you can't even select your army. The following turn it's still directly unselectable, but if you hit the space bar, eventually it will be that army's turn to move, and the game selects it for you. Trying to move the army into an empty tile doesn't work (2nd pic) as indicated by the red line. If you have a unit in an adjacent tile - and even though the line is now green (3rd pic) - movement is still prohibited. The ONLY way to evacuate the army is to load the units into a ship (4th pic). Which means that if you plan to "Liberate" any cities, it's only feasible with cities on the coast.

There is ONE OTHER OPTION. If you add "NoZoc" as an attribute for "UNIT_CITY" in units.txt, that solves the problem, and the entire army can leave without any difficulty. The problem is that cities have a ZOC specifically so that units and armies can't just waltz past them. As a possible alternative, I removed "NoZoc" from the Cradle Militia units (which are immobile city garrisons), but that didn't make any difference. Their ZOC effect is countered by the lack of same from the city. Anyway, while it's possible to remove ZOCs from cities, it would require extensive playtesting in order to determine if there are any unintended consequences. Or rather, how MANY there are, and how serious might they be? All in order to preserve the functionality of a little-used human player option, and one which the AI will NEVER use.

Accordingly I'm not going to make any changes here, other than putting a warning into the GL and identifying the "load into a ship" workaround for coastal conquests.

[Kull]

Special Attacks - Assassinate Ruler:

Getting some of these Special Attacks to work properly requires (to borrow a quote from one of the CTP2 programmers) "more workarounds than you could shake a lemur poo at", and there's no better example than "Assassinate Ruler". The attack itself is quite interesting (more on that later), but we'll begin by examining the MANY graphics and messaging issues:
- "AssasinateRuler" is not listed in specattack.txt, but rather borrows pieces from two that are - ConductHit and BombCabinet.
- There are two "success" messages listed in script.slc, and of those one doesn't work (it's not part of the executable) and the other one plays on every ATTACK, not every SUCCESS ("misleading" aint the half of it)
- There are also two "failure" messages, one of which does not work.
- The two that "work" utilize different "messageicons", one for ConductHit and the other BombCabinet.
- The sprite comes from the BombCabinet attack - literally a bomb with a burning fuse.
- The sound comes from the same attack, and features a "ticking clock" <facepalm>
- The cursor (which displays over the target) is the "skull-and-crossbones" from ConductHit.
- The attack icon on the buttonbar is the same "skull-and-crossbones" (albeit from a different file)

I'll spare you the details on the long convoluted process which finally unearthed that trove of information, and in all honesty, most of the issues involved a dog's breakfast of mixed up graphics. The BIG problem was the messaging. How would you EVER know if the attack was successful or not? Not to worry, it all came together:

- Both messages were re-written. Since you're going to see the success message no matter what, it now serves as a precursor, "reminding" the player that there won't be a notification if the attack succeeds, only if it fails (see attachment). In addition, the message code was altered to "pop-up" the "success" message first, while the "failure" message just appears in the messagelist (which reverses the earlier, more confusing order of message receipt)
- As noted above, there were two different messageicons ("success" was MessageType "Conduct_Hit" (MGMI031.tga) while "failure" was MessageType "Bomb_Cabinet" (MGMI028.tga)). To synch them up, the "success" message type was changed to Bomb_Cabinet and now both display a new "knife" messageicon (MGMI048.tga).
- A new sprite (GX30.spr) was created, showing the knife in a downward plunging motion (see red arrow). It replaces #23 (bomb-with-fuse) as the "effect" sprite associated with SPECEFFECT_PLANTBOMB in speceffectid.txt.
- An existing knife/sword sound (GUAX04.WAV) was linked to SOUND_ID_BOMB_CABINET in sounds.txt, but it didn't work! I had to rename it to GXXX23.WAV (the existing "ticking bomb" sound) in order to make it play during the attack.
- A pair of new "knife cursors" were created and replaced the two "bomb-in-briefcase" cursors as linked in orders.txt (i.e. they use the same numbers, UC050.tga and UC051.tga, since the game won't accept new ones). Worth noting that the cursor numbers listed in orders.txt have to be two digits higher than the actual cursor numbers (thus "52" and "53"). Why? Why not! <facepalm>
- The skull-and-crossbones button icon (upsi22.tga) was replaced by a new "knife" button (upsi45.tga) in the ORDER_ASSASSINATE section of orders.txt (see red arrow)

The result of all this is a coherent era-independent attack, with messaging that won't confuse the player and which uses a common set of graphics.

As I mentioned earlier, this attack is very interesting since it switches the target nation's gov-type over to "Anarchy". Under the previous Cradle rules, that was a KILLER attack since it would automatically disband EVERY government-specific unit, and hence the price was astronomical (10,000 Gold per attack). That also meant the AI would NEVER use it even if they might otherwise be coded to do so. Thus it was a human-only attack, and roughly akin to nuking your opponent - worse, actually, since the AI opponent would lose a large portion of it's entire army. Under the new system, Anarchy is now an included gov-type for all Gov-specific units, and thus the attack is no longer as devastating - although it's still pretty painful! Anyway, I haven't figured out what to use for the cost, but that will be tested. If it's low enough that the AI will actually use this Attack, that would be a feat all by itself!

[Kull]

Nubian AI - An Interesting Religious Attack:

Speaking of religious attacks, the AI is really good at building prophets and launching religious attacks during the early game. They prefer City Conversions (which is good, because that religious attack has the best long term value), and I've seen many instances of ships dropping off prophets for coastal city attacks. But what the Nubian AI is doing with the Patriarch in this screen shot is SERIOUSLY impressive.

Some background. The Patriarch is a powerful religious unit that cannot be built, but is granted as a Wonder Unit when various early-game religious Wonders are built. The Nubians received theirs after building the Code of Hammurabi at an inland location (not visible in the attached screenshot). After which the Patriarch moved to a coastal location where it embarked on a Coracle.

From there, the Coracle proceeded to move West, South, and North along the coast of the continent which Nubia shares with the Sumerians (orange). Along the way, the Patriarch disembarked and converted Ur (bottom of screen shot) and then got back on board and headed for the Western coast. There we see the same pattern - disembark and convert Eridu, get back on board and do the same at Nina (both circled) and then continue up past Umma - without stopping. Which is REALLY smart because that city is "watchful" (blue eye) following a Slaving attack.

Anyway, I noticed this while running a new test game (20 civs this time) and it's a nice counterpoint to the earlier rant.

[Kull]

Special Attacks: "A rat's nest of unparalleled proportions":

That's a pretty strong statement, I'm sure you'll agree, but is it accurate? Well, let's take a close look at the "Soothsay" attack which is performed by religious units and causes unhappiness in the target city. Looking at just one example, here's the pertinent code for the "Cleric" as listed in units.txt:

CanSoothsay {
Sound SOUND_ID_CONVERT_CITIES_CL
Effect SPECEFFECT_CONVERT_CITIES
}

Seems pretty straightforward. The "Sound" section points toward the sounds.txt file and sure enough there's a listing for SOUND_ID_CONVERT_CITIES_CL and the associated wave file. That particular file (a thunder clap) is used in a number of places, so for test purposes I subbed in the "elephant" sound, so we can be certain that things are working as indicated.

Next we'll look at the effect (SPECEFFECT_CONVERT_CITIES), which can be found in two files. "SpeceffectID.txt" lists the number of the sprite (similar to the way "newsprite.txt" assigns numbers to unit sprites) while "specattack.txt" assigns both sound and sprites to various special attacks. Which certainly seems superfluous, since that is ALSO being done in units.txt.

Strange, but...whatever. We run a test and have the Cleric "soothsay" in a foreign city. And the sprite we see is NOT the "clouds-with-sunbeam" convert city effect, but rather a puff of blue smoke. And the sound is NOT the elephant but rather....no sound at all! What?

Weird. Well, looking again at the "perhaps-not-superfluous-after-all" specattack.txt file, it does have a listing for the "Soothsay" special attack:

SOOTHSAY { SoundID SOUND_ID_CAN_SOOTHSAY SpriteID SPECEFFECT_CAN_SOOTHSAY }

Maybe that's what's controlling this? So I change both settings to match the Cleric listings in units.txt, and NOW we'll certainly hear the elephant and see the clouds-and-sun, right? Wrong. Blue smoke & silence.

Ooooh boy. So, looking once again at the Cleric entries in units.txt, we see there's a rather odd special attack called "CauseUnhappiness". There aren't ANY buttons for ANY units for this particular attack, but it IS the end result of a "Soothsay" attack. And sure enough, there is a listing for this in specattack.txt:

CAUSEUNHAPPINESS { SoundID SOUND_ID_CAUSE_UNHAPPINESS SpriteID SPECEFFECT_CAUSE_UNHAPPINESS }

So once again I copy in the Cleric's soothsay settings from units.txt, and FINALLY it works. Clouds-and-sunbeams and the triumphal cry of the elephant. So what does that mean? Well this for one: The special attack links for sound and sprites in units.txt DO ABSOLUTELY NOTHING. And not just for Soothsay...for EVERY special attack. In fact, Special Attack sound and sprite effects (to the extent you can control them at all - and for some you can't) are entirely controlled by the settings in specattacks.txt. Period.

But wait! It gets worse! As you saw, even though "Soothsay" IS a Special Attack and IS listed in specattacks.txt, the effects are actually controlled by CAUSEUNHAPPINESS. Which is also true for the "Advertise" Special Attack. Meaning that you have a Commercial AND a Religious attack, and both will play the identical sprite and sound, and there is literally nothing you can do to separate them. Kill.me.now.

If this were the only oddity in the bunch, well, OK. But it's not. It turns out that all the Special Attack messages are launched from Script.slc, and EVERY ONE OF THEM is hard coded in the executable. Not the text itself, but the fact that a success or failure message even exists. If you add new ones? They don't play. And why do some message texts have code that indicates the location of the attack or the unit which launched it while others are just text? Surely you can stick that same code in other messages, right? Wrong. The ability of some messages to handle code (and only certain kinds of code) is buried somewhere in the executable. What about new special attack cursors? Sorry, the game allows numbers 1 to 89, and that's it. New messageicons? Sorry again, there's 106 entries in that file and no more are allowed, nor can you reference any special attacks other than those which are listed, EVEN IF THEY EXIST.

All that said, it's true that most of the special attacks work as intended. Sprites, Sounds, Cursors, Button Icons, Messagicons & Messages all exist or can be modified. And for those which are problematic (like our good friend "Soothsay") there are workarounds being tested and tested and tested again. And then there's the whole issue of whether the AI will build the special units and perform the special attacks. Which is a whole other animal...

[Kull]

Fixing CTDs: The source of the unrecoverable CTDs was identified (more on that to follow). The first test game used 12 civs and was played on "Hard" difficulty, and in the screenshot below you'll see the "end state" when the playtest terminated in 1500 AD. There were a few CTDs near the end of the game, but all of them were resolved simply by loading the Autosave. I suspect they were the result of a resource overload, as the screenshot sort of attests. Even so, the CTDs were anywhere from 40 to 5 turns apart and all happened on hitting the end-turn button. So not too inconvenient...or surprising. OK, let's talk about what was done and why.

1) First thing! If you plan to run a long test game - especially with this many civs - it's best to "play" as the Barbarians. Which is surprisingly easy to do. For those unaware of the mechanics:
- Start off as any normal civ, choosing all the options you'd like to include in the test game (don't select any of the "extra Barbarian" options as that will only slow things down).
- After the game loads, I usually found the first city immediately, but it's probably not necessary.
- Hit the <esc> key and click "Cheat Mode" in the resulting menu.
- Click through the next two windows and when the "Scenario Editor" window finally appears, click the "EMPIRE" button (top right)
- In the next screen, go to the "Player" choice in the top left and click the left-facing arrow until the number is "0" (i.e. the Barbarians)
- Now click the "Exit" button (bottom right) and you'll return to the game screen (now completely black, since the Barbarians don't have any units on the map).
- Hit the apostrophe key to bring up the chat window.
- Type /rnd ## (meaning: /rnd<space><the number of turns you want the AI civs to play against each other> and hit Enter (then click anywhere on the map and hit the apostrophe key to close the chat window). That will start the game off, and the first batch of turns will pass VERY quickly, since Barbarian units won't appear on the map for quite a while. Your starting civ will proceed under full AI control, so don't think of it as anything more than an AI civ.
- Usually my chat window values are "/rnd 100", but later in the game that drops to 50 or even less. After each set number of turns, the game halts on the Barbarian turn and you can use the cheat menu to look around and see what's going on or just repeat the process for the next 50-100 turns.
- If you notice anything interesting during an auto-play sequence, just hit the ESC key and the game will halt on the next Barbarian turn.
And that's it! Easy peasy, and the turns will fly by....well at least for a while!

2) So what about those CTDs? I spent a LOT of time reading through the Source Code playtest threads, and noticed in particular some comments from BureauBert. He kept "finding" new CTDs and other errors, and every time it happened after he'd made changes to one or more files in the aidata folder. As you'll recall, that was a big project (discussed in Post #80) where the Cradle AI files were merged with those that are now part of the AE base game. And on further reflection, it was pretty obvious that I hadn't done a really thorough job. Many of the files were huge and I had no idea what most of the settings meant, and so there was a fair amount of "by guess and by golly". Accordingly all the files were restored to the original Cradle settings (while making necessary changes for things like new units and advances). And when that was done, the very first test game was the one you see here. In short, that was the problem.

3) Going forward, I will have to become EXTREMELY FAMILIAR with all the aidata files, and make changes only where the implications are fully understood. Especially where code sequences from one file are referenced by another. Some of that has already been done, and the result was a second test game (15 civs this time) which reached 1000 AD before the playtest was voluntarily terminated. It's going to be painful, but there's no real alternative. Although each of these games made it very far along, I'm not impressed (to put it mildly) with the AI's performance. So a great deal of changing, testing, and tweaking still lies ahead. Plus I still need to complete the "Special Attacks" project that was underway when this nightmare first reared its head over a month ago. And THAT is proving to be a rat's nest of unparalleled proportions. The SC guys did great work in almost every area.....but THIS? Aye caramba.

[Kull]

SLIC File reviews (alphabetical): All file numbers preceded by an asterisk were "commented out" and are not used in Cradle 3+. That's 14 in total, over a third.

*1) Airunit.slc: Not Required (per Martin Guhman (2004)): Refuels air units (it actually destroys the unit and replaces it with one of the same kind...fully refueled)

2) Buildingunits.slc: Required. Creates the "Great King" unit when the new "Dynastic House" building is completed. One piece of EVENT code.

*3) Capturecity.slc: Not Required. Destroys a percentage of buildings when a city is attacked or captured. The percent chance that various attacks will destroy buildings is included in Const.txt (ASSAULT_DESTROY_BUILDING_CHANCE), and the AE Readme specifically mentions that the "DestroyBuilding" function now works.

4) Colony.slc: Required (but modify, if possible). This is a Cradle file that builds a colony when a settler is disbanded inside city limits and it adds a population point when a Plunder II unit is disbanded in the city. However, it also has code for adding pop points when a settle is disbanded, and that *could* conflict with the new "Settle-in-city" function. Preferable if that part of the code could be removed. Since the "build colony" button doesn't work (Danger Will Robinson!), this is the only way to actually get colonies. Has two EVENT sections.

*5) ComImpSForAIs2.slc: Not Required, per Martin Guhman (2004)

6-8) Culture.slc (which in turn activates culture_funcs.slc and culture_msgs.slc): Required (with caveat). These are the Cradle Religious/Culture Victory files, and thus needed IF you plan to play with that option. If not, it might be best to "comment out" the "#include culture.slc" line in Scenario.slc. There are nine EVENT sections in culture.slc (none in the other two)

*9) Diplomod.slc: Not Required (replaced by diplomacy.slc)

10) Diplomacy.slc: Required. An AE file which replaces diplomod.slc.

11) Elite.slc: Required (but known to be broken!) This file creates the "Cradle Elite Units", and is thus a key part of the mod. Has two EVENT sections. ISSUE: The code which creates Generals from Heroes is broken. After the first Hero is promoted to General, all subsequent promotions kill the Hero unit but do not provide a General unit.

12) Feats.slc: Required. The Cradle-specific version has more entries, but there's no EVENT code, nor any errors related to this file.

*13) FortsForAIs.slc: Not Required. Builds forts for AIs in order to connect separated parts of the empire, primarily so they'll build roads between each area. In 2004 Martin noted that this file was still required, however in 2006 the SC team added the "CanBuildWasteland" code to tileimp.txt, and in 2007 Ekmek commented that "the AI has built roads through wasteland to connect cities".

*14) Frenzy.slc: Not Required, per Martin Guhman (2004)

*15) Goods.slc: Not Required, per multiple sources (now part of the base game)

16) Homeguard.slc: Required. This file creates the "Cradle Militia Units", and is thus a key part of the mod. Has thirteen EVENT sections. Worth noting that SC introduced a feature in userprofile.txt which provides the "cheapest unit" to the AI as a Militia garrison unit (AIMilitiaUnit=No or Yes), but that's a different solution to the problem. I suppose you *could* substitute that feature and do away with this file altogether, but that would be a last resort, and only if it's proven that this file is causing CTDs.

*17) Infras.slc: Not Required (probably). A small file which fixes an AI bug involving Infrastructure or Capitalization. One EVENT section. I couldn't find specific mention of this issue, but there are several threads in which the team fixed different Infrastructure/Capitalization problems, and this was almost certainly dealt with as well.

*18) KillCityOption.slc: Not Required. A file which gave the player a few options after capturing a city (destroy/disband/enslave). Two EVENT sections. "CityCaptureOptions" are now part of the base game, so this file is redundant.

19) Mapwonders.slc: Required. This file identifies the Visible Wonders (a key component of Cradle) and also places them on the map. Four EVENT sections. There were some slic errors related to the Great Wall code (it places two wall TIMPs, one on each side of the city). That feature isn't used in Cradle anyway, so I'll see if that code can be deleted - it almost doubles the size of the file, all to no purpose (in Cradle, anyway).

*20) Natwonders.slc: Not Required (but desired). This file identifies the seven Natural Wonders and places them on the map. Nine EVENT sections. This file was kicking out both a "normal" SLIC error and a cascade of EVENT errors. I was able to fix the first one, but I'm not "coding-smart" enough to figure out what's wrong with the Events. It does seem odd though - most of this code is used to deploy the wonders at the start of T2, after which it should shut down - the exception being all the code designed to prevent pillaging and overbuilding. At least for now I'm going to remove this file from the Active SLIC files list. Eye candy is great, but not at the expense of stability.

21) Plunder.slc: Required. A number of the Cradle Wonder Units have the ability to generate "plunder units" of various sorts, and this file controls the type of plunder unit (based on time period). Two EVENT sections.

*22) Pw_cheat.slc: Not Required. A small file which gives the AI a gold and PW boost to encourage them to build TIMPs. One EVENT section. Not a "bug fix", so not mentioned in the SC threads, but the AI shouldn't require artificial boosts like this, given the many AI improvements in AE. Worth noting that Cradle 3+ originally used the similar "pwcheat.slc" from the MoT mod, but that has been deactivated as well.

23) Scenario.slc: Required. An empty file (presumably the code requires its presence) which is populated and used only by scenarios.

24) Script.slc: Required. Most of the file is dedicated to "messagebox" code but it's also where most of the slic files are activated (bottom of the file). BB added two EVENT sections at the bottom of this file as part of the Cradle Scenario conversion, but I'm removing them since they disabled CityCaptureOptions in favor of those in KillCityOption.slc (now deactivated).

*25) Settling.slc: Not Required. A file from the Mot mod which BB altered for Cradle, intended to improve AI settling location choices. Seventeen EVENT sections. I like the idea, but at least one of the earlier playtest EVENT errors appeared to come from this file, and it has a LOT of EVENT code. Accordingly I'm going to disable it.

*26) Soundfix.slc: Not Required. A file which adds sounds when tile improvements are built. One EVENT section. The SC project added a sound file link to tileimp.txt, making this redundant.

*27) Springfield.slc: Not Required. A file which made the AI build a new Capitol improvement if the old was lost. Five EVENT sections. The AE readme specifically lists this as an SC fix from Revision 907.

28) Tilerefund.slc: Required (not really, but it's a nice feature and there's no indication that it's buggy). A file which refunds part of the PW cost of an improvement when it is pillaged or a new one replaces it. Three EVENT sections.

29-30) Train.slc (which in turn activates trainfunct.slc): Required. These are the Cradle Military Unit Training files, which increase unit strength by spending gold. Personally I don't use this, but it's an interesting feature and has a really nice graphical interface. There are six EVENT sections in train.slc (none in the other).

31) Traits.slc: Required. Holds the Cradle civ-specific feats and golden ages. One EVENT section.

32) Traits2.slc: Required (with caveat). More Cradle civ-specific traits (gold, pw, and culture). Fifteen EVENT sections. The Cradle2 playtest kicked out two EVENT errors related to this file, specifically the two EVENTs which grant extra population to newly founded cities of certain civs. When you read the code, it's designed to keep the exe from opening the build manager for one turn, so it's not surprising that CTP might see this as a problem. Worst case, those two civ features could be removed, but for now I'll keep this with no changes.

33) Updater3.slc: Required. This file allows the player to upgrade Cradle Militia and Elite units, which - because they are unbuildable - cannot be updated using the new AE upgrade system. The file included with Cradle (updater.slc) did not function properly, so it has been replaced with this modified version of APOL_updater2.slc.

34) Wonderbuildings.slc: Required (???) This file prevents the AI from constructing buildings that are already granted by a Wonder. For example, VoK gives the player the effect of an Apothecary in every city, but even if they have this Wonder, the AI builds Apothecaries anyway. Zero EVENT sections. NOTE: There is new code in the Wonder database, "ActualBuildingEverywhere", which means that when the Wonder is built, it places the actual building in all of the player's cities (the existing code - which still works - is "BuildingEverywhere", and that provides the effect of the building). So changing to the new code would mean this file could be removed. HOWEVER: Since there aren't any EVENT sections in the code, this is not a source for those sorts of errors.

35) Wonderunits.slc: Required. This file creates all the units (not all of which are non-buildable "Wonder Units") given to the player when particular Wonders are built. Seventy-four EVENT sections!!! Certainly that's a LOT of EVENTS, but each is a one-time creation of a single unit and each trigger is disabled right after the EVENT fires. Seems unlikely to be a source of problems.

[Kull]

CTDs: It's been quite a while since the last update, and that's because I've been engaged with CTDs. For the most part the Cradle 3+ updates have been graphical, with only three new advances, one new building, and a number of new units (all of which used tried-and-true capabilities). Accordingly, most of the playtesting had been limited in duration, usually 50 turns or less. After the changes to the 11 files in the aidata folder, I launched some longer playtests, and soon discovered that the game would CTD repeatedly after 2500 BC. Reducing the number of civs from 12 to 8 extended things, once as far as 400 BC, but all "fewer civs" games would still CTD (unrecoverable), while those with 9 or more civs would terminate around 2000 BC (or sooner). Most of the CTDs produced Crash Logs, but they are largely unintelligible to me. Something about an EVENT error, but those are part of almost every slic file, and the specific mentions weren't descriptive enough to hone in on a particular file (see attached for one example).

Researching through the Source Code project threads, there were a number of comments suggesting that "no-longer-required" Slic files might contribute to instability (by interfering with functions now built into the exe), so the next step was a rigorous review of all 35 slic files included with Cradle. I'll list that in the next post, if only so folks looking to modify other scenarios can quickly determine which of the pre-Apolyton Edition slic files to delete. However, cutting to the chase, there was no positive effect. Games with 12+ civs still had unrecoverable CTDs around 2300 BC. By this point I'd been working the problem for almost two weeks, appeared to be running out of options, and was looking at the possibility of a complete rebuild of Cradle 3+. Extremely disappointing. As noted above, the slic file review is next, but I'll leave you with this hopeful comment. There is light at the end of the tunnel...

[Kull]

New Goody Huts: One of many new features added by the SC guys is the ability to assign different goody hut images to each terrain type. This latest project takes full advantage of that, assigning no less than 10 new images to most of the various land terraintypes. "Grassland" retains the existing Easter Island heads and the Megaliths, but all the rest have something new. The more common terraintypes (plains/forest/hills) have two, while most of the rest have one. In the attachment, you can see two of the new ones; a Mayan temple in the forest (R), and a Stone Tower atop a hill (L). The others include different temples, castles, obelisks, an actual hut, and even an igloo. I played around with these quite a bit, and am finally satisfied that each choice matches well with the chosen terraintype.

While implementing these changes I discovered something that has apparently always been true, but I'd never noticed until now - Goody Huts do NOT appear in any of the three Mountain terrain types. You can assign images, but they simply will not show up on the map. This was true even for games using the pre-Source Code ctp2.exe, so it's not something that was recently introduced.

I took the opportunity of this screenshot to show a couple of other changes. The "purple murex" (Dye) has been replaced by a more common variety (see red arrow) while the "Trawlers" image used on Beach tiles has shifted from the modern-looking rowboat to a small brown-sailed vessel (fits better with the other two sailing ships).

Edit: Credit where it's due - all the new Goody Hut images came from Ekmek's Civ3 pack, although every image has been edited to add shadows.

[Carolus V.]

Here you go with some other Wonders: Great Pyramids, Chichen Itza, Coliseum, Forbidden City, Hanging Gardens, Great Lighthouse. Use or use them not. As you wish

[Kull]

Hello Kull

I saw, you are looking for a, at least somewhat, better Version of the Hagia Sophia. Probably you´ll find this useful. It´s a Model from AOE II

Thanks, that does look more like the as-built structure. I'd already removed the minarets (those were added much later) from the new version, but I'll take a closer look at yours.

[Carolus V.]

Hello Kull

I saw, you are looking for a, at least somewhat, better Version of the Hagia Sophia. Probably you´ll find this useful. It´s a Model from AOE II

[Kull]

Horses: Just to see how it would play out - and it's not like hints weren't dropped - but Horses are a requirement for horse units. How that plays out over the long term we'll have to see, but this much is certain. As the human player, if you don't have them, you KNOW where they are (or will seek desperately until you do)! And if they aren't nearby? You try to imagine distant colonial schemes that will make them yours. A feeling not unknown to devotees of other civ building games, of course, but it's nice to get that from CtP2. Oh, and building Nukes without uranium?

[Kull]

Status Report - Units without Idle: As reported in various posts, 10 "civilian" units were converted, and now that entire category has the Idle animation (and thus full on-map movement). Only three Naval units did not have Idle, and those have been converted AND given attack animations as well. For Land units, I noted previously (Post #32) that 7 had been converted. And as of today, the remaining 10 non-Idle land units have all been deconstructed and fixed:

8) Horseman
9) Warrior (Pacal)
10) Pharaoh Chariot
11) Great King Chariot
12) Cataphract
13) Crossbowman
14) Man-at-Arms
15) Janissary
16) Arquebusier
17) Howitzer

The only exceptions are the Ballista and Trebuchet, which never had motion images to "unlock". Which leaves Air units. The Nuke has been fixed, leaving only the Fighter, Interceptor, Stealth bomber and Spy Plane, all of which are late game units. Even so, I will probably fix them eventually, if only for the sake of "completeness". But the larger point is that every land and sea unit which can move? Does move.

[Kull]

TIMPs - Getting the AI to build them in the right place: One of the more annoying AI activities is when they build TIMPs in the "wrong" terrain, or in quantities that look awful on the map.
* Example #1 - Mines on Grassland: Just an ugly look. Why would they do that? The reason is "production uber alles". Fortunately the solution is easy - make it impossible to build mines (of any level) on Grassland. Plains can stay, but not for the first level of Mines.
* Example #2 - Ports on every beach hex: This is trickier, because there are no other terrain types these can or should be built on. However, the "food bonus" is the same as "Nets" (+5) so we'll try to mitigate the problem by removing the food bonus and increasing the Gold bonus from 10 to 15. If nothing else, that might restrict the "Port spam" to AIs pursuing a "Gold" objective.
* Example #3 - Mines on Horses: The settings for the new Horse Good were +10 Gold, 0 Food, and +10 Production. Which sounds logical, but the AI builds Mines on top of horses, and that's...just...wrong (albeit understandable from the AI perspective). So I'm shifting the Bonus from +10 Production to +10 Food. Hopefully that results in Pasture/Farm TIMPs being built instead.