Tutorial 6: PS entry browser

To put it all together, let's take a look at how one might see all the pieces of $ substitution used in one set of triggers. We'll make a PS entry browser to look at what's in the database as our example.

---

Here are some triggers that rely on using $ to substitute dynamic text:

(0:32) When someone says something with {@BrowsePS } in it,

(5:250) set message ~BrowsePS to {[PARAM3]}.

(0:32) When someone says something with {@BrowsePS } in it,

(1:176) and the length of message ~BrowsePS is less than 1,

(5:200) emit message {The value of the '[PARAM2]' entry in the '[PARAM1]' table is: $[PARAM1].[PARAM2]} to the triggering furre.

(0:32) When someone says something with {@BrowsePS } in it,

(1:76) and the length of message ~BrowsePS is greater than 0,

(5:200) emit message {The value of the '[PARAM3]' entry within the '[PARAM2]' row in the '[PARAM1]' table is: $[PARAM1].[PARAM2].[PARAM3]} to the triggering furre.

The very first trigger stores the value of [PARAM3] into a string called ~BrowsePS to provide the command with the ability to distinguish between an entry that is inside of a table ($table.entry), or one that is inside of a row in a table ($table.row.entry).

The second trigger displays the value of an entry, if an entry is inside of a table ($table.entry), but it is important to take a better look at the structure of the emit line:

(5:200) emit message {The value of the '[PARAM2]' entry in the '[PARAM1]' table is: $[PARAM1].[PARAM2]} to the triggering furre.

You may notice that even though we replaced both the tablename and entryname elements with [PARAM1] and [PARAM2] respectively, the $ as well as the . separating tablename from entryname are still written in plain text.

This is important because the $ as well as the . must always be written in manually. Any attempts to substitute them with a string (for example, a string that contains a full $ address such as $dream.Example) or a special text replacement string will cause the PhoenixSpeak entry called through $ to not display. This limitation is why we used three different triggers instead of one.

The third trigger is the same as the second one, except that it only triggers if an entry is inside of a row that is in a table ($table.row.entry).

So, for example, if we had a PhoenixSpeak entry called Cookies with a value of 40 in the Dream table, and we used the @BrowsePS command like this:

@BrowsePS dream Cookies

The trigger would emit the following text:

The value of the ‘Cookies’ entry in the ‘dream’ table is: 40

Meanwhile, if, for example, we made a PS entry called VisitorNumber with a value of 3 to the player named Joey, and we used the @BrowsePS command like the following:

@Browse character Joey VisitorNumber

The trigger would emit the following text:

The value of the ‘VisitorNumber’ entry in the ‘Joey’ row of the ‘character’ table is: 3