Structure of a card script

Simulators based on OCGCore, such as EdoPRO and KoishiPRO, make use of LUA files in order to code the behaviour of the cards during a Duel: with the exception of Normal Monsters, which do not possess any effect, material requirements, or Summoning procedures, every card in the game needs its own "script" in order to function properly: if a card does not have any script associated with it, you will be met with the following error message once you start a Duel using a Deck containing said card.  "CallCardFunction" (cXXX.initial_effect): attempt to call an error function Where XXX is a number that represents the original ID of the card whose script is missing.

Below, you can find a set of guidelines that are meant to show you the usual structure each card script needs to follow.

Name conventions
The name assigned to the file containing the script automatically links it to the corresponding card. When naming a card script, you need to follow a set of rules, as showed by the example provided below. c12345678.lua The name always starts with the lower-case letter c, followed by the original ID of the card you want to link the script to (in this case, the script will be linked to the card with 12345678 as ID), and by the extension of the file (.lua).

Contents of the file
The chunk of code provided below is designed for a generic card with multiple effects. The ellipsis (…) serve as a substitute for the text that would have been included in an actual script. Since we are only concerned with the script's structure, we will ignore these omitted portions for now. Every line that starts with a pair of hyphens (--) is a comment. Comments are portions of the scripts that are ignored by the program and are only meant to help the scripter noting any kind of useful information they might need. In this case, we use comments to write the name of the card and the author of the script, or to help identify an effect of the card for example.

The GetID function
In the third line we define two variables with the GetID function: To better grasp what these variables represent, suppose you're creating the script for a card to which you assigned 12345678 as the original ID: in this example, id represents the number 12345678; as for s, without using too technical terms, it is basically a table that we use to hold the functions we will define in the card's script. Every time we define a function, we will always place s. before its name, in order to link it to the table s. On some older scripts, especially the ones used by KoishiPRO, you might find something like cXXX (where XXX is the id of the card), instead of s, but they are basically equivalent as far as we're concerned.
 * s is a table associated with the card's original ID
 * id is the original ID of the card

The initial_effect function
This is the name of the function that is called when a card is initialized at the start of a Duel, and must be present in every single card script. When this function is called, it will create and build the various effects of our card, and register them to it. In case you do not know how to define a function, you can follow these steps in sequence: According to these instructions, the name we will use for this function is s.initial_effect. Since this function only requires one parameter, which represents the card itself, we only write c (which stands for "card") inside the brackets.
 * 1) Start by writing the keyword function
 * 2) Assign a name to your function (for our purposes, remember to always place s. at the start)
 * 3) Enclose a list of the parameters required by the function within a pair of round brackets
 * 4) Write the instructions that the function will execute when it's called
 * 5) After you're done, close the block by using the keyword end

Creating an effect
Now, in order to create an effect we invoke the  function: it has only one parameter, the card that will own the effect, and returns an effect object. As you can see, in the reference script I wrote: I initialized two local variables, e1 and e2, which represent two different effects. The nomenclature I adopted ( **e*** followed by a number) follows the usual convention, but you are free to choose any name you want. Since we passed c as argument, our card becomes the owner of these effects.

Building an effect
At the time of their creation these effects are "empty", they need other components in order to be fully complete. In order to build an effect, we can rely on a vast assortment of Effect functions: Each one of these methods deals with a certain characteristic of the effect: for example, SetType defines the type of our effect (Ignition, Trigger, Quick, etc.). You can come back and check what these function exactly do at a later time, but for now I will only introduce 4 of them. If you have played the game for enough time, you are probably familiar with the concept of Problem-Solving Card Text (often abbreviated to PSCT) and the meaning that some symbols, like colons and semicolons, assume within the card text. The following functions are made specifically for implementing the activation requirements (or activation conditions) of an effect, the procedures that are executed at the time of activation (such as paying costs, or targeting a card), and the procedures that are executed at the time of resolution (the actual effect).
 *  Effect.SetCondition : It sets the activation condition or the requirements that need to be fulfilled in order for an effect to be activated or applied. In the card text, for activated effects, the activation condition is the part of the text that comes before a colon (eg: When your opponent draws 1 card:... ; If all monsters you control are Fairy monsters:...). An effect cannot be activated if the condition is not fulfilled, also the condition does not have any relevance on the resolution of the effect.
 *  Effect.SetCost and  Effect.SetTarget : In the case of activated effects, these two functions implement the procedures that are executed at the time of the effect's activation. In other words, they deal with the portion of text that comes after a colon, but before a semicolon . The first function sets the cost that needs to be paid in order to activate the effect (for example, discarding a card or paying LP). As for the second function, contrary to what the name seems to imply, it doesn't only implement the targeting procedures, but it also concerned with verifying the activation legality of the effect, and stores informations on the actions that will be performed at the time of the effect's resolution.
 *  Effect.SetOperation : Implements the actual effect, and the procedures that are executed at the time of resolution. In the case of activated effects, it deals with the part of text that comes after a semicolon, or after a colon if the effect does not have a cost, and does not target.

Here you can find a sample card text with color-coded sections: each of the above functions is responsible for the section that shares its same color. If you control a face-up non-Effect Monster  :  You can banish this card from your hand or GY, then target 1 card your opponent controls  ;  return it to the hand.

Registering an effect
Lastly, when we deem the effect to be complete, we just need to register it to the card. To do so, we invoke the  function, which has 2 parameters: the card we want to register the effect to, and the effect itself. So, when I write, I am just giving the effect e1 to our card c. The card that receives the effect is also referred to as the effect's handler.

Condition, Cost, Target, and Operation functions
When we invoke,  ,  , or  , we also need to pass a function as argument. For instance, in the sample script I passed  when I invoked Effect.SetCondition while building the first effect: this means that the function s.condition1 becomes the condition of e1. Of course we need to define each one of these functions too, and we do that just below the initial_effect function, by following the same steps we mentioned before. It is worth noting that you should pay attention not to assign the same name to different functions, in order to avoid accidental overwriting of previous functions.

As for the sequence of parameters that you need to insert, you can follow this scheme depending on the type of effect you are scripting:
 * Your effect starts a Chain (activated effect):
 * Condition function
 * Cost function
 * Target function
 * Your effect targets
 * Your effect does NOT target
 * Operation function
 * Your effect does NOT start a Chain (continuous effect):
 * Condition function
 * The effect is an inherent Special Summon procedure (e.g. Cyber Dragon)
 * In any other case
 * Target function
 * The effect is an inherent Special Summon procedure (e.g. Cyber Dragon)
 * In any other case
 * Operation and Value functions
 * The effect is an inherent Special Summon procedure (e.g. Cyber Dragon)
 * In any other case
 * Target function
 * The effect is an inherent Special Summon procedure (e.g. Cyber Dragon)
 * In any other case
 * Operation and Value functions
 * The effect is an inherent Special Summon procedure (e.g. Cyber Dragon)
 * In any other case
 * Operation and Value functions
 * The effect is an inherent Special Summon procedure (e.g. Cyber Dragon)
 * In any other case
 * In any other case

Each of these parameters has a specific meaning:
 * e (Effect) - The effect that is being activated/applied, or whose activation conditions are being checked
 * tp (Triggering Player) - The player who activated/applied this effect
 * eg (Event Group) - If an event occurs, it represents the group of cards involved in said event
 * ep (Event Player) - If an event occurs, it represents the player(s) involved in said event
 * ev (Event Value) - If an event occurs, it represents the value associated with said event
 * re (Reason Effect) - If an event occurs, it represents the effect that caused said event
 * r (Reason) - If an event occurs, it represents the reason why said event happened
 * rp (Reason Player) - If an event occurs, it represents the player(s) that caused said event
 * chk (Check) - Used in Target and Cost functions. It is 0 while the effect is not being activated/applied yet (this property is used to verify the activation legality of the effect); while the effect is being activated/applied, it becomes 1.
 * chkc (Check Card) - Used in Target functions. It represents a card that could become a valid target for the effect that was activated (used to script the interaction between effects that can change the target of an effect, e.g. Cairngorgon, Antiluminescent Knight)
 * c (Card) - If the effect is a Summoning procedure, it represents the effect's handler. Otherwise, it represents a generic card that is being currently checked by the Target or Value function.