In Stronghold 2, every War Custom and Peace Custom map can have missions. Missions are individual chapters on the same map. As such, the content of the map is kept exactly the same between each mission which takes place on a map. This means that any buildings you create, trees which are cut down, armies which are created or estates which are captured in mission 1 will be the same at the start of mission 2. Each mission contains a whole number of events, and these tell the game what needs to happen in that mission. You may for example need a lord to be rescued, or for a user to take a certain number of estates before they will win- this is all done by events. Once in the mission editor, you will see this screen:
Each mission you create should contain at least one win event and one lose event. Without both of these, you could be stuck forever in that same mission. However, you may wish to add more- you can have as many win and lose conditions setup as you like. As you can see with each new mission there is a default lose condition setup, which is that if your lord dies, you lose the game. We have an excellent guide on individual triggers and events in more detail, so this article will explain more on how to setup working events.
All events consist of a trigger and an action. The trigger is responsible for making sure that the action happens. An event can have a whole number of triggers but it can only do one thing. If an event has multiple triggers, then all conditions must be true before the action happens. For example, a Peace scenario may look something like this:
In this example, you can only win the scenario when all the gong is gone from your estates, and all rats as well. If only one of the conditions is true, for example, there is no gong but there are still rats, you won't win. If you wanted the user to be able to win the mission by either eliminating all gong or rats, then you must create a similar setup like this:
Because in this version, they are two totally independent events, then you only need one event to trigger in order to win. So that means to win the game you can either clear all the gong, or eliminate all the rats.
You should also note that events can only be triggered once. If for example, you had an event which would give you 50 honour when you recruited 20 Archers, this would only happen once. The next time you recruited 20 Archers, it would not happen again unless you had an entirely new event setup for recruiting 40 Archers. This is because if you had two events setup for recruiting 20 Archers, they would both trigger at the same time. Similarly, the terminology of the trigger Always does not mean the event will always happen, it is the chance of the event happening. So if you set the event to always happen, regardless of whatever other events are triggered, that event will always happen in the game.
One of the other things which is important to note is that all events are ran from the top of the list down to the bottom in the scenario editor. Let us take a look at the following example map:
You can see here that there are is a win condition and a lose condition, as well as two other events. There is a Witchcraft event which will always happen, and an event which will send a bear attack when no bears are left on the map. However, this mission will not work as intended. There are two factors which play into this: the first is because the editor runs relevant events top-down. That is, from the top of the events list to the bottom. Because of this, the Win condition runs before the event to add more bears on the map. The second reason, is because the events are also ordered ascending in terms of the delay before the event happens (the number on the left hand side of it). As you can see in my example above, there is a +1 delay to adding bears on the map.
There are two ways to rearrange this. The first is to clear the win event and re-create it, and it should be created underneath the event to add bears. If this doesn't work on its own, check the event delay, and make sure the event is delayed less than the event above it. You can also delay the event above more than the event below, so that the editor automatically moves it down:
Quests are a way of structuring events and keeping them together. The main benefit to using quests is that you can avoid keeping your events duplicated and messy. There are a total of three quests called A, B and C. Quests can either be complete, not complete or failed. You can setup specific triggers on the status of quests as well. When dealing with these triggers however, it is important to note that Not Complete is dealt with in the same way as Failed. Take a look at an example quest from one of my scenarios:
You can see all of the quests setup here. Quest A is to rebuild the ruined bridge. Quest B is to produce a large number of resources, and Quest C is to attain a specific population. Once all three quests are complete, a message is displayed from The King.
What you can also do with quests is dynamically setup events to change their status. For example, if you completed a quest, you can set up an event to change its status again back to Not Completed. You could also have events to trigger on the completion of single quests as well. Suppose I wanted to give some honour when the ruined bridge was rebuilt. I'd be able to use the Single Quest Complete trigger to check if Quest A is complete. When the ruined bridge is completed, that would complete Quest A. Because Quest A has been completed, that would then trigger whatever event has been setup as a result of completing Quest A (in that case giving some honour to the user). This makes it possible to set off chain reaction events.
The other interesting thing when creating events is the ability to delay them. At first glance these may seem to do exactly the same thing but they actually do completely different things and it's important to note the difference between them. Let's take another look at my old example here:
I set this event up using a Month delay. A month delay will prevent the event from being active in the game until that time has expired. So if for example, you kill off all the bears in January, and have a delay of this kind for 2 months on adding more bears, the event doesn't become active until the end of February. That means that even though you've killed off all the bears in January, because the event wasn't active it won't trigger until the following month when the game checks for untriggered events again. This is a very complicated concept to fully understand, but in more simpler terms it means the event exists, it's just disabled and can't be triggered until the delay is over.
In contrast with a month delay, the other kind of delay does nothing to disable the event, and will just delay the event by a set number of months from whenever it was triggered. Back to my previous example, you kill all the Bears in January. The month changes to February, the game checks for untriggered events, and it finds this one. It delays the event by one month until March, then adds new bears in the map. It's important to note that only month delays are shown on the scenario editor mission editor screen, that is, the delays until events become active.