Making Cradle 3+ fully compatible with the Apolyton Edition

[Kull]

"Hear Gossip" is now Functional: A few weeks ago I reviewed the Diplomatic "special attacks", and sadly reported that "Hear Gossip" didn't work. Even so, yesterday evening - on a hunch - I added the HearGossip attribute to the Diplomat entry in "units.txt". To be clear, that is not a listed attribute and no units have it, but it did appear in a text file search of the executable. So I ran a quick playtest and parked a Greek Diplomat next to several foreign capital cities, and - voila - Gossip messages appeared! Unfortunately the code for the civ names didn't work, but eventually the problem was solved by moving the message text from "cut_str.txt" over to "info_str.txt" AND using a different format for the civ identifier code. The messageicon originally defaulted to the "red exclamation point", but it was possible to create a new one using an "ear" icon borrowed from CtP1. The messages themselves were rather boring and generic, so those were spiced up as well, and you see the result in the attachment.

Per the earlier review, there should be a chance to HearGossip when a Diplomat uses the ThrowParty attack, or passively when a Diplomat is positioned outside a capital city. So far it does NOT work as an adjunct to ThrowParty (possibly something to do with stringing two attributes together) and it's worth noting that Diplomats parked outside a non-Capital city will never hear gossip. But in this one specific instance it DEFINITELY works, and that includes the sound (whispering) and the sprite (blue puff of smoke).

As a result, this attribute will be added to the other "diplomat-type" units (Ambassador and Empathic Diplomat), and I'll drop the percent chance in "const.txt" from .9 (used for testing) down to .05 since it should not be a common occurrence (the AE default was .02). In addition, I'll add some references to the Great Library so players are aware of the mechanism.

[Kull]

Thanks for the info. I am running Apolyton version of CTP2 under Win7 and will now look to ad the Cradle v3 mod & give that a go.

Super, you are well ahead of the curve! Since you are already running the Apolyton edition, the good news is the Cradle3 scenario is already installed. It should work OK, but please look at the first post in this thread for the two "workarounds" needed in order to select Cradle Civs and to re-activate the Great Library every time you load a save game. Selecting a civ is particularly annoying, since the menu forces you to choose from the AE list, and there's no obvious correlation to Cradle. To help you out, look at this attachment. As an example, if you wanted to play as Assyria, choose the Turks.

[Cyberguy]

Thanks for the info. I am running Apolyton version of CTP2 under Win7 and will now look to ad the Cradle v3 mod & give that a go.

[Kull]

This is a "mod of a mod", and is still under active development, so unfortunately no - not available for download yet. However, you might want to try your hand at the Cradle Scenario which is included with the Source Code update. If you don't have CtP2 loaded (and working) on your PC (and maybe even if you do), I highly recommend that you follow the installation process laid out in this thread. CtP2 is a very old game, but I've had ZERO problems running it in Windows 10 using that method. Once you have the game up and running (to include the Source Code Team's patch), then you'll be able to run Cradle as a scenario. There are a few tricks to get it running properly, so if you have any problems just open a new thread in the main CTP2 forum and I'll help you work through them.

To be clear, that is the original "Cradle v3", and not the version I'm working on here. But even so, it's a fun mod and playing around with it will be good preparation for this new version, once it's finally released (still quite a few months away, unfortunately, as I'm still deeply embedded in the special attacks sub-project).

Edit: The main link for the Source Code download is broken, but the first link in Post #3 is still active.

[Cyberguy]

The mod looks great. Is this available for use now, where is the download link and how is it installed?

[Kull]

Military Special Attacks (4): I completed this group a while ago, but let's take a look at them in more detail. I won't share the full autopsy results, just the more interesting findings. Also, there's far more than four orders that apply primarily to military units, but most of them are simple and obvious, like "Fortify" or "Sleep" or even "Attack". They work as expected and aren't worth digging into.

1) Pillage: The pillage attack is pretty straightforward. Military units with the CanPillage attribute in "units.txt" use this to destroy Tile Improvements - usually those belonging to an enemy, but it's also one of the rare attacks you can direct at your own assets. The main finding is that a successful attack features a sprite (trumpets) and sound (trumpet fanfare), and BOTH are hardcoded. More specifically they use the "General Success" sprite and sound, so if you altered that for this attack it would also apply in all other cases where "General Success" is used. Not a big deal, but it limits the ability to customize this attack.

2) Intercept Trade: This is the "Piracy" attack (hijacks profits of the Trade Route for 1-turn) performed by all units which have the CanPirate attribute (primarily military). Has a Button icon (pirate flag), Cursor (pirate flag), Sprite (pirate flag) and Sound (slaver whooshing net). There are no messages for pirating trade routes, either as attack or victim. There are two messages in "script.slc", but neither is listed in the exe, so they can't be made to work. Accordingly, there's no Messageicon either. The interesting finding here is that Piracy is not listed in "specattacks.txt" and thus the sprite and the sound are hardcoded by file name. That's not a problem for the sprite (pirate flag is perfectly appropriate) but the sound is a different story. It uses the file linked to SOUND_ID_SLAVE_RAIDS (in sounds.txt) and there's no way to change it.

That's a problem because it's also the sound used in a successful city slaver attack. On the surface that might not seem like a big deal, but one of the really neat features of CtP2 is that even though much of the map is obscured by Fog-of-War (FOW), you can still hear the sounds of AI-on-AI special attacks during the "end-turn" gameplay. But in this case you wouldn't know WHICH attack is happening sight unseen. Are slavers at work, or is the AI busy pirating trade routes? For me it's quite important since - among many other things - I'm trying to determine which special attacks the AI is using, and when.

Fortunately there was a solution. The city slaving attack is listed in "specattacks.txt", and that allowed me to change the sound file link from SOUND_ID_SLAVE_RAIDS to a piece of unused code called SOUND_ID_RAILLAUNCH. That new code was then linked to the "slavernet" sound file (GXXX14.WAV) while the old code - now used only by the Piracy attack - was linked to the "evil laugh" file from CtP1 (guax09.wav). Sounds complicated but it's not, and the end result is that each special attack now has a different and unique sound. And sure enough, during the next playtest there were a lot of whooshing sounds in the early game, but later on - once Trade Routes had been established - you began to hear the evil laugh. Very nice.

3) Expel: Units with the CanExpel attribute are able to "boot" certain foreign units back to their nearest city (used against units which have the CanBeExpelled attribute - mostly civilians). As with "Pillage", the main finding is that once again the successful attack utilizes a hardcoded sprite (trumpets) and sound (foghorn). Not really a problem, but once again it limits the ability to customize this attack. An interesting discovery is that you can expel units from neutral territory as well as your own land.

4) Bombard: This is an interesting feature, as it allows units to attack those in an adjacent hex, and it's used by land, sea, and air units to represent such diverse weapons as rock throwers, anti-air missiles, torpedoes, and modern artillery. The attack can only be launched by units which have one of four CanBombard attributes (Land, Mountain, Water & Air). But that alone is not enough. Units also need settings for BombRounds (usually 5) and BombardRange (typically 1), while those with the CanCounterBombard attribute are able to respond in kind. This is one of the few instances in which combat between units does not take place on the "battleboard"

I bring this up because 4 of the Ancient-era naval units (Trireme, Heptireme, Longship, and Dromon) have the CanBombard attribute, but they do NOT have BombRounds or BombardRange. So if you click the Bombard button on these units and place the target icon over an adjacent unit, they move into that hex and conduct a standard battleboard-type attack (see attached). Historically three of these units did not have ranged attacks, so the solution for them is very simple - remove the CanBombard attribute. By contrast, the Dromon used an attack which spewed Greek Fire from a tube and immolated target vessels, so - even though the range of that attack was limited - it's reasonable to retain it here. In this case the solution involves adding the necessary BombRounds and BombardRange values.

[Kull]

3) "Hear Gossip": To begin with, this is technically NOT a special attack, but rather two different mechanisms by which the Diplomat can gain information on the target civ. There isn't a listing in orders.txt and there is not a button to activate it, but there are plenty of indications that it was coded to be in game:
- There are two settings in "const.txt", the first is the "percent chance" that a Diplomat will "Hear Gossip" when throwing a party. The second mechanism is a different percentage which is applied to Diplomats on every turn they are located adjacent to the capital city of another civ.
- The "specattack.txt" file controls the sprites and sounds applied to all active Special Attacks, and "HearGossip" is one of only 25 listed attacks.
- The existence of Special Attack messageboxes is hard coded in the executable and MUST be listed in script.slc. That file has messageboxes for SIX different types of Gossip, and the text of these is contained in cut_str.txt

To test this in-game, I changed each "chance" to 90% (setting them to "0.9" in const.txt) which should guarantee that gossip happens with almost every party and on almost every turn for a Diplomat parked next to the capital city. Next I ran a 20-civ game down to 500 BC before taking control. 5 Diplomats were stationed next to the Capital cities of 5 distant civs, established embassies, and then held a party. No gossip was heard. The diplomats stayed in position for the next 11 years, yet not a single Gossip message appeared. And finally, each Diplomat held one last reception, and again, no Gossip. Unfortunately, it appears that Gossip is broken.

So that was very disappointing, ESPECIALLY since the new unit settings make it possible for Diplomats to sit undisturbed next to foreign capitals for long periods of time, which is exactly the requirement for the second Gossip mechanism. And of course, the AI is actually throwing parties and parking Diplomats next to foreign capitals, so it would not be a "human-only" benefit. Oh well...win some, lose some.

Anyway that should give you a small taste of what I've been dealing with for the past few weeks. The good news is that every attack in every category except "Espionage Attacks" and "Terror Attacks" has been analyzed and tested and altered where necessary. And yes, there were a few real eye openers along the way. Calling this code a "rat's nest" is an insult to rat's nests.

[Kull]

2) "Hold Reception/"Throw Party": This is an interesting capability, but one which I had never seen used by the AI. The party improves relations with the target civ, but has an odd mix of graphics. The Button icon and Cursor both used the "Handshake with $$" while the Messageicon featured a Martini Glass (w/ olive). The Sprite had the same "blue cloud " you get from Selling Indulgences (a religious attack) while the sound is that of people cheering. The martini glass is a holdover from CTP1, but it's a better way to convey the idea of a party. Admittedly that's a modern drinking vessel, but the archaeological record offers conclusive proof that fancy drinking cups have been a feature of elite ceremonial gatherings from the most ancient of times. Conversely, the handshake icons seem more appropriate for bribery, but that's not what's being represented.

Making new "martini-based" cursors and buttons was easy enough (and another for the Great Library), but there's a limit on "cursor count", so I had to find a set that was not being used and substitute the new ones (see top image in the attachment). As for the sprite, I changed that to the CTP1 "space explosion" (see bottom image) as you could loosely associate that with a celebratory bonfire or fireworks (as opposed to the "blue cloud" which represents...what?)

Cost was a bit confusing since "const.txt" places a "Max Cost" of 500 on each party and the associated text implies that one can spend less. But you can't. The cost per party is set in "orders.txt" and cannot be changed (well, other than by altering values in the file itself). Also, you can hold only one party per civ (diplomats stationed at other cities of this civ cannot throw a party after the first one is held), and it turns out there's a time limit before the next is allowed. Which is 10 turns. That value is listed NOWHERE, but repeated testing confirmed that it's a hard limit.

Lastly there was the question of AI usage. As noted earlier, I've never seen the AI use this capability and while lowering the costs might make it more attractive, I decided to keep them as-is and see if the new "stealthy diplomats" might hang around foreign cities long enough to try this. And in fact, that's what happened! Still pretty rare, but during the playtest there were two instances where I heard the "party cheer" sound - a wav file that is activated by this order and none other. So...it worked!

[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.