By Franηois Delmotte (ultima_spock_3@yahoo.com)

This document has been written by a fan of the Stronghold game and is intended to serve as a reference for other players who will find here all informations to write good scripts. However, as it is written below, a script is only a part of a scenario, which requires also a map and other things. Here you will learn how to make good scripts, but making good scenarios requires much more hard work.

This document has three parts. The first one is based on the description of the general scheme of a scenario It gives examples about very simple events and other general informations. In this part you will learn how to make a simple scenario. The second part is for advanced programmers only. It presents some tricks to create much more complicated scenarios. The third part is a reference of all actions and events that can be used in a scenario.

************************************************************ ************
1 Basic Notions
************************************************************ ************

In this section is described the general scheme of any script. It will also tackle invasion, while these latter are not used in economical scenarios.

1.1 General Scheme of a script
A script uses invasions, messages, and events. It has also a starting date. Everything in the script must have a date from which they can be activated.
Invasions are armies attacking the player's lord. You must choose a starting date, but no condition as with Events. They can be repeated every n months with no end.
Messages appear at a given date and have no other implications.
Events are much more interesting to study and will take the rest of this section.

1.2 The Basic Element of a script : the Event
1.2.1 A single condition
The following notation will be used for any Event.
Event x : (date t ; Cond i) => Action a
It means that at the date t, Condition i is checked and will imply if true the action a. You choose a condition mentionned in the reference section. You choose an action from the reference section.

In this game there are conditions that can be tested at a given threshold. For example you can test if the population is equal to 300. In fact the game engine consider the test not as an equal test, but as an equal or higher test. It means that a condition of a population equal to 300 will become true if the population is 400.

1.2.2 Multiple conditions
You can also test a serie of conditions, this will be noted :
Event x : (date t ; Cond i,...,Cond j) => Action a
With this notation, all conditions must be matched in the same time so that the action is triggered. For example you can script the Event (date t ; Stone = 300, Ale = 200) => Win.
You will win if you have in the same time 300 stones and 200 ale.

In the Editor, when you have several conditions for the same Event, you can choose to use the 'or' operator, which will be noted :
Event x : (date t ; Cond i,...,Cond j ;+) => Action a
It means that action a is triggered as soon as one of the conditions becomes true, not necessarily all. For example (date t ; Stone = 300, Ale = 200 ;+) => Win means that you win if either you have 300 stones or 200 ale. Totally different from the first case.

1.2.3 Until activated, an Event can be triggered
An extremy important point to highlight is that once an event is scripted at date t, it will remain likely to trigger even after date t until it will become triggered.
For example consider (date 1500 ; Stone = 300, Ale = 200) => Win.
Departing from the date 1500, this Event will be tested. You can win in 1500 if you have 300 stones and 200 ale, or later when you will gather enough ressources.

This simple example may be obvious, but must be kept in memory. When scripting complex scripts, with a large set of Events that are linked and interlaced, there could be some big surprises with some forgotten Events that are triggered well long after they were defined.

1.2.4 Final comments
You can attach a single action to a serie of conditions. But you cannot attach a serie of action to a serie of conditions. If for example you want to create (date t ; Stone = 300, Ale = 200) => Fire (10) AND bandits (green) you must cut them in two and write (date t ; Stone = 300, Ale = 200) => Fire (10)
(date t ; Stone = 300, Ale = 200) => bandits (green)

You can indeed scripts several Events at the same date. The only problem is that if messages are attached to actions, some will be delayed.

Now you are ready to tackle the design of simple scenarios by adding several Events. They will be noted :
Name (starting date) {
Event x
Event y
Event z...}

1.3 First basic scripts
In this part is given some examples for simple scripts. From them you can create your own ones, add everything you want and are limited only by your imagination.

1.3.1 Example of an economical script
MonPremier (1000) {
(1010 ; AutoStop) => bandits (red, 10) for 3 times every 9 months
(1020 ; Stone = 300, Ale = 200) => Win }

It means that you begins in 1000. In 1010 you will be attacked automatically by bandits, and they will come back 2 times (one for the first time, plus two others equal 3).
At 1020 or later, you will win if you gather 300 stones and 200 ale.

This example is perfect for a tutorial in stronghold, but is incorrect for a true scenario. For a tutorial, a beginner would have all the time to learn the game and try various tactics. But you want a true scenario for players. So what is the problem ? The script lacks of a losing condition. Usually in economical scenarios, you have a deadline to do the required job.
To do this you simply change the script as follows :

MonPremier1 (1000) {
(1010 ; AutoStop) => bandits (red, 10) for 3 times every 9 months
(1020 ; Stone = 300, Ale = 200) => Win
(1025 ; AutoStop) => Lose }

In this case if you do not win before 1025, you lose. That is not more complex, but add a high pressure on the player who will see in the left top of the screen the countdown !
Depending on the map, the available resources, wolves and so on, the scenario could be anything between easy to impossible.

You could forget the wining condition and write
MonPremier2 (1000) {
(1010 ; AutoStop) => bandits (red, 10) for 3 times every 9 months
(1025 ; AutoStop) => Lose }

In this case the scenario is in a dead end, it is not possible to win it.

Let us come back to the working scenario and change something :
MonPremier3 (1000) {
(1000 ; Stone = 300, Ale = 200) => Win
(1010 ; AutoStop) => bandits (red, 10) for 3 times every 9 months
(1025 ; AutoStop) ( Lose }

We simply changed the starting date of the winning Event. Now it begins in 1000 so it means that you can win before 1020, even before 1010 and so a player could very well never see the bandits. In this script this does not change anything, because resources you gathered cannot be destroyed, and so if you could win before 1010, you will surely win after 1020. But this can be very different with the script
MonPremier4 (1000) {
(1010 ; AutoStop) => bandits (red, 10) for 3 times every 9 months
(1020 ; bread = 500) => Win
(1025 ; AutoStop) => Lose }
Indeed food can disappear if the granary is destroyed. You might very well win before 1010 and not be able to resist the bandits' attack.

1.3.2 Example of military script
MonSecond1 (1000) {
(1000 ; LordKilled) => Lose
(1010 Invasion : 100 bowmen)
(1020 ; AutoStop) => Win }
In this case you have 10 years to prepare yourself to an invasion. You win in 1020 if you just go to that date. You lose if your lord is killed. You could write the winning Event by two other means :
(1000 ; NoEnemy&InvasionLeft) => Win
and
(1010 ; NoEnemyOnMap) => Win

The first one can be placed in 1000. It checks if there are any enemies on the map, and a left invasion. So between 1000 and 1010 it will wait, and you will win if you kill all the enemies. The second must not be placed before 1010 because at this time there are no enemies and you would win without doing anything.

1.3.3 Breaking the Siege script
You want to improve your previous script and enhances it in some ways. You want to prepare a huge invasion, but if the player is doing well he will receive reinforcements.
Let us study :
MonSecond2 (1000) {
(1000 ; LordKilled) => Lose
(1000 ; NoEnemy&InvasionLeft) => Win
(1010 Invasion : 200 bowmen, 100 pikemen)
(1011, AutoStop) => Bandits (green, 50) 1 time}
The reinforcements could very well appear in the middle of the battle, or at least they could be surrounded by ennemies. This is not very good or realistic.
You may in this case write :
MonSecond3 (1000) {
(1000 ; LordKilled) => Lose
(1000 ; NoEnemy&InvasionLeft) => Win
(1010 Invasion : 100 bowmen, 50 pikemen)
(1010, NoEnemyOnMap) => Bandits (green, 50) 1 time
(1012 Invasion : 100 bowmen, 50 pikemen)}
In this case reinforcements appear only if there are no enemies on the map. The player has two years to kill the first wave, after that he will have to battle the second wave. If he is not enough fast, he will have to battle a huge invasion without any help.

Let us come back to section 1.2.3 concerning Event that can be triggered well after they were defined.
Concerning the script MonSecond2, you tried yourself the scenario, and know that in one year the first wave can be destroyed. It is hard, but possible if the player spends and uses all of its best troops. You do not want any reinforcement, but instead of you want to force the player to kill the first wave in one year and not more, due to the story you invented.
Let us consider the script
MonSecond4 (1000) {
(1000 ; LordKilled) => Lose
(1000 ; NoEnemy&InvasionLeft) => Win
(1010 Invasion : 100 bowmen, 50 pikemen)
(1011, AnyEnemyOnMap) => Lose
(1012 Invasion : 100 bowmen, 50 pikemen)}
This script will surely fail.
Indeed in 1012 there will be new enemies, and you lose.

So now keep in mind that you can trigger an action with the AutoStop Condition at the time t you want. You can trigger an action conditonned by a test from and after a time t. But you cannot decide to test something at a date t and not after.

As a last comment concerning Invasions, if you trigger several ones in the same time, they will all appear in the same place on the map, even if they are several signposts. This allows you to stack for exemple 300 crossbwomen in the same place. Waouuuu !

1.4 Concluding remarks

So in this part you have learnt how to script simple scripts. You can add plenty of Events, attacks from wolves, wheat diseases, theft in the granary, and so on and so on... But this would be not more complex -concerning the script- that what has been presented above. What would be more complex is the whole scenario, the links between timing, the map, the resources...
You do not need lengthy scripts to make interesting scenarios. I remember absolutely amazing games, including some economical ones at the hard level from the original game, that were based on a script of 4-5 Events.

In the next section you will learn some tricks that are quite complex to enhance the possibilites you have when writing Events. Read it only if you already wrote scenarios. All scenarios from the original game, and a crushing majority of scenarios from fans use only the principles presented here.

************************************************************ *****
2 Advanced programming : How to impress FireFly's Studio !
************************************************************ *****
In this section you will learn some more complex principles, that mainly turn around the principle of memory. When we will be able to use memory, we will see how to create the logical operator lower than. All the tools presented here are not elegant and have one or more drawbacks. But they multiply by so much the possibilites of your imagination that they reward well.

2.1 Memory
Events, and thus scripts, are memoryless in Stronghold. If you had 300 ale in 1010, but spend it with inns, you cannot remember in 1020 that you had 300 ale in 1010. You have no variable to store something. Except :

2.1.1 The eights kills'counters.
YourTroopsKilled from one side (Pig, Rat, Wolf and Snake) and EnemyTroopsKilled from the same sides store the amounts of casualties from each side, the one you did, and the one they did on you.
They were used in the original game to send messages. For example if you killed 10 Snakes men, he was angerous. If you killed 100 of his mens, he was asking mercy. A pure waste !
We will use these variables for much more interesting scripts.

They are also the possibility of testing YourTroopsKilled and EnemyTroopsKilled with the side 'any'. We could believe it adds kills from the four sides. This is the contrary ! It is a substracter !!! It removes kills from one of the four sides. Consider for example the following script :
Plusqu'etonnant1 (1000) {
(1000; Invasion Rat : 20)
(1000 ; EnemyTroopsKilled (Rat,19)) => Message X
(1000, EnemyTroopsKilled (Pig,19)) => Message Y
(1000, EnemyTroopsKilled (Any,15)) => Message Z
(1001 ; Invasion Rat : 20)
(1002 ; Invasion Pig : 20)}

What is happening is :
You get message Z first in 1000. Message X does not appear at the end of the first invasion. Message X appears in 1001 when 15 more Rat's men are killed. Message Y appears in 1002. Weird isn't it ? Implications of such behaviours have to be drawn so far.

Anyway we will be able to do lots of things with these eights counters. The two weird ones are left there and need more studies.

A very important remark is that kills from bandits do not raise the four counters EnemyTroopsKilled(). We will use this later.

2.1.2 Use the wolves
Wolves are very interesting objects you can handle. You can create at any times wolves. But more interestingly, you can awake wolves on a map, that will next attack the player and finaly they will be killed. So there were wolves, and then you do not have wolves any longer. So you have a binary memory.
The script for the binary memory based on wolves is as follows :
WolvesKeepMemory (t) {
(t; AutoStop) => WolfSleeps
(t+x ; Condition i, ..., Condition j) => WolfAwakes()(A)
(t+x+y, Condition i', ..., Condition j', NoWolvesOnMap) => Action a}(B)

The event A triggers the memory. The event B uses the memory.

Let us consider the following simple example. You have a very limited space to put your farms. The king asks you to have 2000 bread in 1010 and 2000 ale before 1015. You know that when 1010 arrives, there will be wheat diseases and you will not be able to gather food.

LimitedPlace1 (1000) {
(1000; AutoStop) => WolfSleeps
(1000 ; ale = 2000, NoWolvesOnMap) => Win
(1010 ; Bread = 2000) => WolfAwakes()
(1010 ; AutoStop) => WheatDisease (9*7 months)
(1015 ;AutoStop) => Lose}

This example is clearly totally misleading, since you do not need a memory for that.
Simply write
LimitedPlace2 (1000) {
(1000 ; ale = 2000, bread = 2000) => Win
(1015 ;AutoStop) => Lose}

Indeed since you cannot harvest wheat as soon as 1010 is here, you are forced to have 2000 bread in 1010 to win anyway. So a memory is useless in this case.

However it is very usefull in the next scripts :
LimitedPlace3 (1000) {
(1000; AutoStop) => WolfSleeps
(1000 ; ale = 2000, NoWolvesOnMap) => Win
(1010 ; Bread = 2000) => WolfAwakes()
(1010 ; AutoStop) => TheftFromTheGranary (9*7 months)
(1015 ;AutoStop) => Lose}

We had to change a little bit the scenario : instead of wheat disease, some bandits steal food. So in this case a memory is required, because you cannot have before 1010 both 2000 bread and 2000 ale, and bread can only be produced before 1010 and disappear after that.

The approach of using wolves as a memory has two constraints :

The first is the main one. There must be wolves on the map, and they must be protected. Indeed bandits, bear, invaders, anything else, must not kill the wolves, otherwise your script will be defective. And you have to tell the player to not kill the wolves, who must not be in any interesting area of the map. You can protect the wolves by an enemy's castle, or the passage leading to them...Or you can decide on the contrary to test if the player has been in this area. Possibilites are numerous, depending on the scenario.
The second constraint is not that much of a problem : you have to fit the power of WolfAwakes to the number of wolves present on the map. Of course, again, you can decide to use weak WolfAwakes in order to take into account several different conditions at different times, so that when there are no longer any wolves you can trigger something big...It's up your imagination.

The next paragraph proposes a much more complex example than the one of the bread.

2.1.3 Countdown to take the castle
Let us consider the example of a scenario in which there is a strong enemy's castle (let set the Pig) as well as a small village for the player. The player will have some time to prepare its invasion of the Pig's castle. However will arrive more and more invasions. But to raise the stress of the player, you can decide that he will have only a limited amount of time to take the castle, from when he will begins to fight the Pig. You can imagine that as soon as the Pig is attacked, he will ask for some big reinforcements, and the player will lose.
So you decide that the player can freely decide of the moment at which he attacks the castle, but when he decides to do so, he only has, let us say, 1 year.

This is a complex example that requires the use of a memory, EnemyTroopsKilled, and also a WinTimer !!!! Marvelous, isn't it ?

Countdown1 (t) {
(t; AutoStop) => WolfSleeps
(t ; EnemyTroopsKilled (Pig,1),YourTroopsKilled(Pig,1) ;() => WolfAwakes()
(t, NoWolvesOnMap,population 10,WinTimer(6)) => Lose
(t ; EnemyLordKilled,population 100)) => Win}

The first event is required by WolfAwakes. The second awakes the wolves if there is a single casualty from one side or the other. This will trigger the memory.
The third event is the loose event. The WinTimer requires to test an economical variable - it does not work with EnemyTroopsKilled-. The simplest is the population. The WinTimer must take into account the time required by the wolves to be killed. Here are 6 months for the timer, and you guess wolves need 6 months to be killed. The sum makes one year.
The last event is the winning event. You win if the lord is killed. Of course devious players who studied the script could say, Oh ! lets us have a big population before the fight, so that I can be ready. And then act so that my population goes below 10, so that the timer is no longer activated, and so that i have all the time needed. So you add the population 100 condition. A population requires more time to go from 9 to 100 than the 6 months of the timer. Of course when disbanding soldiers, population can skyrocket in a second. So the designer of the scenario should check that the remnant of the player's army should be well below 100 mens.

Ahahaha ! We begin some Real scripting !

As a side note, remark that the WolfSleeps does not require an AutoStop condition, but could be conditionned by something else too. In this case the WolfAwakes is not activated. Let us improve the script. Let say that if your small village remains a small village, the Pig will not pay a real attention to you, and will not have big reinforcements close to his castle. However if your population overshoot, let say 200, the Pig will have a big army close to him.
This gives :
Countdown2 (t) {
(t; population = 200) => WolfSleeps
(t ; EnemyTroopsKilled (Pig,1),YourTroopsKilled(Pig,1) ;() => WolfAwakes()
(t, NoWolvesOnMap,population 10,WinTimer(6)) => Lose
(t ; EnemyLordKilled,population 100)) => Win
(t + 20; AutoStop) => Lose}

In this case, the scenario becomes to be really really interesting. The player has the choice to work with a small village, but perhaps he will not have lots of weapons or gold, or anyhing else, and he will have to resist invasions as well, BUT he will have 20 years to take the castle to take the castle. Or he can decide to go right away for a huge town and try to crush the Pig's castle in one swift attack.

The Countdown1 example has been used in the Mad King map2.

2.2 Logical operator Lower than
If you read all previous pages, you should have noticed that we can test variables with the logical operator: equal or higher than.
For example you can test if a population is equal or higher than 200. But the logical operator less than does not exist. Perhaps the game engine can handle it, but at least the editor does not allow you to do that.
This has a very important consequence: games are one-way games. You set an objective, and the whole game is aimed at achieving it. You can only improve variables to reach your goals. You cannot say for example that, if the population is lower than 200 in 1050, you lose.
This is what is presented now. They are two ways to do that. Both have advantages and drawbacks.

2.2.2 Multiple Signposts on the map
This trick can be used only one time.
You trigger a repeated invasion of size n just before testing the variable. If the variable is higher than the threshold you want to use, you turn off repeated invasion. A few months after that you test the number of kills.
If the number of kills is higher than n, then it means than the turn off repeated invasions was not triggered.
So it finally means than the variable you tested was LOWER than the desired threshold!
Of course, number of kills can mix up with others invasions, past and future.
So you have to use a peculiar chief for that invasion. It must not be used elsewhere in the whole game.
That's it! Let use consider the following example, with the Pig's army as a reference (not used elsewhere). You have 10 years to gather 2000 food that the King will take. The scenario, of course, continues after these first 10 years, otherwise a script like MonPremier1 should work.

TaxIncome1 (1000) {
(1000, EnemyTroopsKilled(101,Pig)) => Lose
(1010; Invasion 100 Pig every 9 months)
(1010; bread = 2000) => TurnOffRepeatingInvasion()
(1010, AutoStop) => TheftInTheGranary(100)
.....}
The Pig could have attacked you before, in this case you must take into account it in the losing condition :
TaxIncome2 (1000) {
(1000, EnemyTroopsKilled(151,Pig)) => Lose
(1005; Invasion 50 Pig 1 time)
(1010; Invasion 100 Pig every 9 months)
(1010; bread = 2000) => TurnOffRepeatingInvasion()
(1010, AutoStop) => TheftInTheGranary(100)
.....}
This trick can only be used one time because a TurnOffRepeatingInvasion() action stops every repeated invasions. It has been used in the Kiev 1240 : The Mongol Invasion map.

2.2.3 One SignPost on the map
However this trick can be used several times. It is a variation of the first one. It uses the fact that bandits'kills do not count towards your own number of kills. It can be used several times, since it does not require a turn off repeated invasion.

The principle is as follows : you trigger an invasion of a particular army the month you want to test the variable. In the same time if your variable is higher than the desired treshold, you trigger some bandits. If the bandits outnumber the invasion, they will kill all the invasion, and you will not have to kill enemies, and you can again test the number of kills of that particular army. Of course bandits must appear in the same place than the invasion, that's why there can be only one signpost.
TaxIncome3 (1000) {
(1000, EnemyTroopsKilled(1,Pig)) => Lose
(Jan. of 1010; Invasion 15 Pig 1 time)
(Jan. of 1010; bread = 2000) => bandits (red, 25) one time
(1010, AutoStop) => TheftInTheGranary(100)}

Numbers given in this example are not random : you must have enough bandits to kill the whole invasion. Moreover in this example we give the month of the event. Indeed you have to carefully that bandits and invaders will fight each other. In this example we consider that the signpost is very close to the border of the map, so bandits and invadrrs appears in the same place.

If the signpost is a little bit more inside the map, you have to take into account the time for invaders to go to the signpost. Bandits always appear right on the signpost. Depending on the map you could write
TaxIncome4 (1000) {
(1000, EnemyTroopsKilled(1,Pig)) => Lose
(Jan. of 1010; Invasion 15 Pig 1 time)
(Feb. of 1010; bread = 2000) => bandits (red, 25) one time
(1010, AutoStop) => TheftInTheGranary(100)}

This trick has been used several times in the Mad King map. For example the Ling asks you one year to be very pleasant (factor 5), and very cruel another one (factor 5). Impossible to do without using advanced tools.

So far all examples of this section used EnemyTroopsKilled for a binary purpose : a failure or not. You could imagine a scenario in which the player has several tasks to do, the more he fails, the more the counter rises. And a loss occurs only if the counter reaches high values. For medium values, the game could be harder, with lots of plague, bandits, anything bad...

2.3 Concluding words
This section presented to you complex tools. They are not required to design very good scenarios, since scenarios are maps plus scripts plus story, plus plus...The whole original game was provided with very simple scritps. However the principles presented here greatly enhance your possibilites. If you use them, please add a reference to me, since I had to deeply deeply deeeeeeply think.

************************************************************ **
3 Reference
In this section are described every actions and conditions that can be used in a scenario.
************************************************************ **

3.1 Actions :
Actions are grouped in several classes : terminal actions, economical actions, troops actions, and special.
If an action can be repeated, it will be noted by *. If you set the counter to i (with i from 0 to 9 and -) the action will be repeated i times every n months. You choose the period n of the repeating action. 'n' can range from 0 to 60 months. If you set the counter i to - with a non zero period n, the action will be repeated with no end every n months.

3.1.1 Terminal Actions
They are clear : when they are triggered, you lose, or you win. They must always appear in any scenario, or it will not be playable (because either you cannot lose or you cannot win).
Win
Lose

3.1.2 Economical actions, Repeating ones :
In this group You can choose the power of some actions if they have an x in parenthesis. For example a plague of power 1 will create one cloud of poison, a plague of power 10 will create 10 clouds.

Plague (x)*
-6 to popularity, and kills peasants around the stockpile and the campfire.
HopsWeevil*
The Production from farms of Hops is reinitialized.
MadCows*
The Production from farms of cows is reinitialized.
WheatDisease*
The Production from farms of wheat is reinitialized.
AppleBlight*
The Production from farms of apple is reinitialized.
TreeFungus*
Kills many tree on the map
RabbitExplosion*
Create rabbit on the map which threatens wheat farms
TheftFromGranary (x)*
Some food disappear from the granary
TravelingFair*
+16 to pop for 3 months
Fire (x)*
Create fires on the map, where there are buildings

3.1.3 Troops Actions
These actions can create bandits of one side or the other, and wolves. An invasion CANNOT be put in this section, invasions can never triggered by conditions but only by time. Some actions have an x, you can choose their power.

WolfAttacks (x) XXX *
Create right away wolves on the map that will attack you. They appear on the map in the place where you put wolves for the first time.
WolfsSleeps
Weird action only to be used with WolfAwakes.
WolfAwakes (x)*
If a WolfSleep has been used, awakes already existing wolves on the map. They will next attack you. Does not create any wolves.
Bandits (x, red)*
Create a group of attacking bandits (macemen). They appear on a random signpost.
Bandits(x, green)*
Create a group of allied bandits (bowmen). They appear on a random signpost.
TurnOffRepeatingInvasion
Once used this action kills any present or future invasion appearing in the scenario. Only non repeating invasion can then appear on the map.

3.1.4 Others and Special
Message
Send a message to the player. You choose the message from all messages of the campaign
Jester
+2 to popularity for 6 months
Marriage
+8 to popularity for 3 months

3.2 Conditions
3.2.1 Economical Conditions
GoldAcquired
Test the gold of the treasury. From 0 to 25000
Goods
Test all the possible goods of the game. From 0 to 10000. This condition appears 4 times, so you can test 4 different goods.
%Blessed
Test the percent of blessed people from priests.
MaximumCruelity
Test the bad things factor. Opposite to good things.
Population
Test you population from 10 to 500
%DrinkingAle
Test the drinking percent of your population
MaximumPleasantness
Test the good things factor. Opposite to bad things.
NoPeopleLeft
Test if you have any peasant.

3.2.2 Military Conditions
In the following the side y means armies controlled by the pig, the rat, the snake or the wolf.
LordKilled (y)
Test if your lord has been killed by the side y.
EnemyTroopsKilled (x,y)
You have killed x men of the y side
EnemyLordKilled
You have killed a lord killed. It seems not possible to test one side or the other.
YourTroopKilled (x,y)
The y side has killed x of your men.
NoEnemy&InvasionLeft
They are no enemy on the map (including bandits) and no invasion are planned in the future.
NoEnemyOnMap
Test if they are no enemies on the map (including bandits)
AnyEnemyOnMap
Test if they are bandits or enemies on the map.
NoWolvesOnMap
They are no longer any wolves on the map.

3.2.3 Other and Special
KeepEnclosed
Test if your keep is surrounded by a continuous line of walls and gatehouses.
AutoStop
Set automatically by the editor if there are no other conditions. Means always true, so an event planned at time t conditionned by autostop will always be triggered at time t.
WinTimer (x)
More complex condition. A timer is triggered when all others conditions of the same event are true. The WinTimer becomes true at the end of the timer, which can be set from 0 to 60 months. If one of the conditions appearing in the same event becomes false during the timer, the timer restarts. For example consider an event such as (At T= t ; %DrinkingAle = 60%, %Blessed = 75%,WinTimer = 12) ( Win. You can only win if for a full duration of 12 months you have in the same time a percent of blessed people equal or higher than 75 % and a drinking percent equal or higher than 60 %.
A countdown will appear in the top left corner of the screen when the WinTimer is triggered. The WinTimer is defective with the conditions EnemyLordKilled, YourTroopsKilled and EnemyTroopsKilled.

1 Months will be mostly omitted in this article, since we do not need to be so accute in simple examples
2 available at the site www.stronghold.heavengames.com