Toggle menu
Toggle preferences menu
Toggle personal menu
Not logged in
Your IP address will be publicly visible if you make any edits.

Scriptref Procs: Difference between revisions

From Lost City Wiki
Branon (talk | contribs)
No edit summary
Branon (talk | contribs)
No edit summary
 
(2 intermediate revisions by the same user not shown)
Line 4: Line 4:


= Procedures, Commands, and Labels =
= Procedures, Commands, and Labels =
There are a few more trigger types to go over. These are slightly more complex but will ultimately make your life easier as they allow a scriptwriter to stay organized and avoid code reuse.
There are a few more trigger types to go over. These are slightly more complex but will ultimately make your life easier as they allow a contributor to stay organized and avoid code reuse.


Procedures, commands, and labels are simply triggers that have been given names and may be called from within other triggers. Often, parameters will be used to dictate the precise function of a given procedure/command/label.
Procedures, commands, and labels are simply triggers that have been given names and may be called from within other triggers. Often, parameters will be used to dictate the precise function of a given procedure/command/label.


The intent is for a scriptwriter to utilize procedures/commands/labels _inside_ the scripts and triggers that they are writing.
The intent is for a contributor to utilize procedures/commands/labels ''inside'' the scripts and triggers that they are writing.


== Procedures ==
== Procedures ==
Procedures are prefixed with `~` when calling. For example:
Procedures are prefixed with <code>~</code> when calling. For example:


```ts
<pre>[opnpc1,border_guard_lumby]
~chatnpc("<p,angry>I'm in a bad mood, get out of here!");</pre>


[opnpc1,border_guard_lumby]
The <code>~chatnpc</code> procedure causes an NPC dialog to appear in the player's chatbox. We have called this procedure as part of an <code>opnpc1</code> trigger, so <code>~chatnpc</code> will run when operation 1 (<code>Talk-to</code>) is triggered on the <code>border_guard_lumby</code> NPC.
 
~chatnpc("<p,angry>I'm in a bad mood, get out of here!");
 
```
 
The `~chatnpc` procedure causes an NPC dialog to appear in the player's chatbox. We have called this procedure as part of an `opnpc1` trigger, so `~chatnpc` will run when operation 1 (`Talk-to`) is triggered on the `border_guard_lumby` NPC.


The result looks like:
The result looks like:


<nowiki>![image](https://github.com/user-attachments/assets/c288db66-8ae9-4c7d-a660-47183dfecc91</nowiki>)
[[File:Proc1.png|frameless|511x511px]]


The important thing to know about procedures is that they **continue execution** of your script after they finish running.
The important thing to know about procedures is that they '''continue execution''' of your script after they finish running.


`~chatplayer` in particular will block execution until "Click here to continue" is clicked. Execution of your script will then continue from where it left off. This allows a scriptwriter to trigger additional actions during/after NPC dialogue, for example.
<code>~chatplayer</code> in particular will block execution until "Click here to continue" is clicked. Execution of your script will then continue from where it left off. This allows a script to trigger additional code during/after NPC dialogue.


== Commands ==
== Commands ==
Line 35: Line 30:


No special prefix is required when calling commands. For example:
No special prefix is required when calling commands. For example:
[opnpc1,border_guard_lumby]
mes("The guard, evidently in a bad mood, shouts at you to leave.");
The <code>mes</code> command prints a message to the player's chatbox.


```ts
[[File:Proc2.png|frameless|339x339px]]
 
[opnpc1,border_guard_lumby]
 
mes("The guard, evidently in a bad mood, shouts at you to leave.");
 
```
 
The `mes` command prints a message to the player's chatbox.
 
<nowiki>![image](https://github.com/user-attachments/assets/bae32d71-189f-4e96-b0be-e276d5dd05f4</nowiki>)


== Labels ==
== Labels ==

Latest revision as of 17:21, 22 August 2025

Previous Page || Browse all Scriptref pages

Procedures, Commands, and Labels

There are a few more trigger types to go over. These are slightly more complex but will ultimately make your life easier as they allow a contributor to stay organized and avoid code reuse.

Procedures, commands, and labels are simply triggers that have been given names and may be called from within other triggers. Often, parameters will be used to dictate the precise function of a given procedure/command/label.

The intent is for a contributor to utilize procedures/commands/labels inside the scripts and triggers that they are writing.

Procedures

Procedures are prefixed with ~ when calling. For example:

[opnpc1,border_guard_lumby]
~chatnpc("<p,angry>I'm in a bad mood, get out of here!");

The ~chatnpc procedure causes an NPC dialog to appear in the player's chatbox. We have called this procedure as part of an opnpc1 trigger, so ~chatnpc will run when operation 1 (Talk-to) is triggered on the border_guard_lumby NPC.

The result looks like:

The important thing to know about procedures is that they continue execution of your script after they finish running.

~chatplayer in particular will block execution until "Click here to continue" is clicked. Execution of your script will then continue from where it left off. This allows a script to trigger additional code during/after NPC dialogue.

Commands

Commands are provided directly by the game engine and tend to be simpler than procedures.

No special prefix is required when calling commands. For example:

[opnpc1,border_guard_lumby]
mes("The guard, evidently in a bad mood, shouts at you to leave.");

The mes command prints a message to the player's chatbox.

Labels

Labels are similar to procedures with one important difference: they halt execution of the calling trigger after they finish running.

By calling a label, your trigger relinquishes control of the player. Execution of your script will not continue where it left off. Instead, execution begins at the label, and ends when the label ends, without returning to your trigger.

Labels are mostly useful for chaining well-organized blocks of code together, using a trigger only as the initial entry point.

You will often see a trigger call a label, which calls a second label, ... and so on.