Trigger Making Guide

#####################
Triggers making guide
#####################

Here is an explanation of how triggers work and how to make them.
	Events are what determines when some code will be executed. "Room change" event, for example, will make the code you write below execute every time any card changes their current room.

Triggers are absolutely global. Whatever code you write, it will affect every card. That's why at the start of every trigger you have to narrow down to exactly what you want to affect. Which is why you will often see "If ThisCard == TriggerCard", for example.

We make a distinction between actions and expressions. Actions do something to the game, change it, while expressions return some value. Common expressions that don't take any argument are ThisCard, or TriggerCard. ThisCard refers to the card that the module will be applied to, whereas TriggerCard refers to the card that made the event fire.

When a NPC wants to talk with someone event is fired, that means that some card wanted to talk to another one. The card that decided to do the talking is the TriggerCard in this event. In a NPC answers event, a NPC gave answer to some card. So the TriggerCard in this event is the NPC that gave an answer to some other card, that replied to some interaction with a yes, no or huh.

In some events there are event-specific expressions that take no arguments. In a NPC answers event, there's AnswerTarget. This refers to the card that the NPC gave answer to. So if an NPC  gives an answer yes/no/huh he will be TriggerCard in NPC answers event, and the card that asked him something will be AnswerTarget. PC can be AnswerTarget in a NPC answers event. When you ask NPC something they reply to you, so you're the AnswerTarget of an event where NPC gave an answer. But if an NPC asks you something and you're the one giving the reply, the NPC answers event won't be fired. Because the event is fired only when a NPC answers, and you're the PC. So you have to use PC answers event.

In a PC answers event the TriggerCard is the PC, as PC is the one who started the event by giving an answer. There's no "AnswerTarget" in this event. AnswerTarget exists only in NPC answers event. To determine who the PC gave answer to we use actors present on the screen. (int)::Actor is an expression that returns the seat of the actor present on the screen. We pass it an argument, where the least is 0. The argument we pass to this is the position of the actor on the screen. 0 refers to the leftmost character present. If there's only one character, he will be the leftmost character so you will pass argument 0. "0::Actor" can substitute AnswerTarget in PC Answers event in most cases. Naturally, if two actors are present on the screen (like when you compete), the right character will have index 1.
Trigger code often deals with integers. "TriggerCard", "ThisCard", "AnswerTarget", "[argument]::Actor" they're all things that return the seat number of characters. There is 25 characters in the game. The seat index counts from 0 tho. So the range is 0-24. So TriggerCard, for example, will have an integer value 0-24.

You should be reading the descriptions of actions and expressions. They describe which type of argument to pass it and what they do. Sometimes the description won't tell you which type of value to pass it (integer, bool, float, or string) but you should take note of suggested possible values and expressions that the drop down list that opens includes. General Constant is present for all types of values. You can type "Hello" as a string, "2" as an int, etc. So to figure out which type of value the expression/action wants click on General Constant in the drop down and try passing it a string. If it fails, pass it a float. Eventually you'll learn how the drop down looks for each type of expected value and won't have problems.

There's 3 types of storage in triggers that last for various amount of time, and have different accessibility. There's local variables, global variables and card storage.

Local variables are defined by right clicking on the white space of trigger code and clicking "add variable". Local variables shouldn't be used to store any permanent data. Local variables are destroyed and recreated each time the trigger is ran. They also cannot be accessed by other triggers. They're completely contained to the one trigger that you defined them in.

Global variables are decent for storage of non-permanent data. Global variables can be accessed by all triggers and they last for one game session. To define them, click on the "Globals" button above trigger list. Click on the add button. You will notice 2 empty fields and a button that says "Default Value". In the first field you specify the name of the variable. In the second field you specify the type, whereas clicking the Default Value will prompt you to give initial value to your variable.

Card Storage is most permanent storage and lasts even after the game is turned off. If you need to store some data that will last for the whole save file, then use card storage. There's a group of expressions to retrieve the card storage data and actions that write it.
There's 4 actions: "Set Card Storage Integer", "Set Card Storage Bool", "Set Card Storage Float", "Set Card Storage String". They take 3 arguments: the seat of the card that you are writing the data to, the variable name, and value for that variable. Card  Storage is tied to the seat of some specific card, so you have to specify which card you are writing the variable to.
For expressions, there is "Get Card Storage Int", "Get Card Storage Float", "Get Card Storage String", "Get Card Storage Bool". When you retrieve Card Storage you will be asked to provide 3 arguments. Card storage is some variable with some value written to a specific card. So to retrieve the value from card storage it will ask you for 1) the seat of the card that you wrote the value to 2) the name of the variable whose value you want to retrieve 3) the default value that this variable will be assigned in case no value for this variable was found in card storage.

That is pretty much the entirety of information that you have to know to be able to make triggers. Everything else is just specifics and knowing how certain events/actions and expressions behave alone and together. For that you will need a bit of experience. To get experience, go and read the code of existing modules and ask a lot of questions. If you're not sure what some action does, ask. If you're not sure some expression is an event specific expression, ask. If you're not sure why your code crashes, ask.
A very useful action is "WriteLog" which you can use often while making the triggers to debug and easily see at which step your code crashes.