4. Signposts and Person events

In the events tab

The green p is a person event
The red s is a signpost event

To add a new event increment the number of the type of event you want to add
Pasted image 20240406193015.png

This will open a byte search window, this window shows the free space available to store your new event, you can pick any location listed
Pasted image 20240406193151.png

Script offset

The script offset is the location of memory where the script is located, when creating a signpost, you need two memory locations
- Script offset
- Location of the message inside the script
You can search for new memory locations by clicking in this icon

Signpost Script example

' this symbol indicates a commented line, everything after the ' will be a comment
0x6B46BC this is the script offset, it must be the same as the script offset value from the Menu
0x6B4704 is also a space in memory, in this case it is where the

'---------------
#org 0x6B46BC
msgbox 0x86B4704 MSG_SIGN '"This is a signpost"
end


'---------
' Strings
'---------
#org 0x6B4704
= This is a signpost

The first text, "LITTLEROOT TOWN\n["]A town that ca...", appearing within the msgbox command, serves as a placeholder or comment within the script
#org 0x6B46BC: This directive sets the current "organization" or location in the ROM to address 0x6B46BC. In ROM hacking, #org is used to tell the compiler where to insert the following data or code in the game's memory.
msgbox 0x86B4704 MSG_SIGN '"LITTLEROOT TOWN\n["]A town that ca...": This line instructs the game to display a message box with text when triggered. The msgbox command is followed by a pointer (0x86B4704), which indicates where in the ROM the text string to be displayed is located. The MSG_SIGN parameter specifies the type of message box to display, in this case, a signpost message, "LITTLEROOT TOWN\n["]A town that ca... is just a comment
The IDE is designed to keep the comments synchronized with the actual content of the script for convenience and clarity. This behavior isn't a standard feature of scripting or programming languages themselves but rather a functionality of the specific IDE
end: This signifies the end of the script for this section, telling the compiler that this block of code or sequence of instructions is complete.

Below this main script block, there's a section labeled as 'Strings', which contains the actual text data referenced by the script:

#org 0x6B4704: Again, this sets the location in the ROM where the following data is to be placed. The address 0x6B4704 matches the pointer in the msgbox command above, indicating this is where the text for the message box begins

= LITTLEROOT TOWN\n["]A town that can't be shaded any hue.": This is the text that will be displayed in the message box. The = symbol is used to define a string.

Receive Item Event

To create an item event, we need to use the giveitem option in the script, we can also use the keywords setflag and checkflag, for checking which text will be displayed when we

#dynamic 0x800000

#org @inicio
lock
faceplayer
checkflag 0x1201
if 0x1 goto @received
msgbox @before 0x6
giveitem <ITEMID> <QTY> <TYPE>
setflag 0x1201
release
end

#org @received
msgbox @after 0x6
release
end

#org @before
Ctrl + T <FIRST TIEM MESSAGE>

#org @after
Ctrl + T <MESSAGE AFTER RECEIVING ITEM>

#dynamic 0x800000 specifies the starting address in the game's memory where this script should be dynamically allocated. This is a common practice in ROM hacking to ensure custom scripts don't overwrite existing game data.

0x800000 is often used as a starting point for inserting custom scripts because it's typically in a region of the ROM that is either unused ("free space") or is allocated for expansion purposes. ROM hackers need to find areas in the game's memory that won't interfere with existing game data, and 0x800000 is a commonly used address that falls into this category in many Pokémon ROMs.

lock: Prevents the player from moving while the script is running.
faceplayer: Makes the NPC face the player during the interaction.
checkflag 0x1201: Checks if a specific flag (0x1201 in this case) is set in the game. Flags are used to track game progress and events.
if 0x1 goto @received: If the flag is set, the script jumps to the @received label, skipping the item-giving part. This prevents the player from receiving the item more than once.
msgbox @before 0x6: Displays a message box with text defined at the @before label, usually indicating the NPC is about to give the player an item. The 0x6 is the MSG_NORMAL value (Message Types)
giveitem <ITEMID> <QTY> <TYPE>: The NPC gives the player an item, where <ITEMID> is the item's unique identifier, <QTY> is the quantity, and <TYPE> likely refers to how the item is received (e.g., visually).
setflag 0x1201: Sets the flag 0x1201, indicating that the item has been received. This prevents the script from giving the item more than once.
release: Allows the player to move again.
end: Marks the end of the script section.

Flag values and behavior

In the above example we use flag 0x1201 fir checking if you already received an item from someone. this value can only be used by that event

Using the same flag (0x1201) for different scripts or events in a Pokémon game ROM hack will indeed affect the first script and any other script that checks or sets this same flag, also the flag that you are using has to be different and cannot have the value of existing flags