This page outlines "SHIORI Events".

The following article is not a complete specification of SHIORI/3.0, but merely a rough guide to understanding it in concept.

For a description of each SHIORI Event, please refer to the list on the "SHIORI Event" page.

To begin with, what does it mean for a ghost to move (speak, change facial expressions, etc.)?

Roughly speaking, it is the functionality achieved by linking baseware(MATERIA, CROW, SSP, etc.) and SHIORI(the core component of the ghost)

SHIORI Event is an important keyword to understand what role baseware and SHIORI each play.

In ghost operation, the first thing to work is the baseware.

The first major task that the baseware fulfills is to create the timing for the ghost to speak and move.

The baseware monitors various conditions, such as time and mouse input, and issues notices to the ghost (to the SHIORI, the core of the ghost) triggered by specific changes (e.g., a minute or second passing, or when the mouse cursor touches the ghost).

We call these notices SHIORI Events.

When the SHIORI receives a SHIORI Event, it uses the contents of a file called the dictionary to create instructions for the ghost (these instructions are called Sakura Scripts)

When the SHIORI sends the motion instructions back to the baseware, the baseware reads the motion instructions and expresses the ghost's movements.

In this way, the ghost actually moves on the user's monitor whenever a SHIORI Event occurs.

Conversely, the SHIORI cannot move a ghost until it receives a SHIORI Event. In principle, all ghost actions are performed in a SHIORI Event and are passive.

Even if it doesn't seem like it at first glance, it is important to note that many ghosts have functions called "Random Talk" or "AI Talk" that are implemented by many SHIORI in OnSecondChange processing, which occurs every second. (This is a SHIORI-specific implementation, so you should refer to the documentation of each SHIORI for details.)

In most SHIORI Events, related information is notified in the form of a Reference, alongside the ID (name and type) of the event.

As an example, let's look at the case of the ID OnMouseClick, which occurs when a ghost is clicked. Information such as which scope (main character, side character, additional character...) was clicked, which hitbox of that scope was clicked, which mouse button was clicked (right, left, wheel...), and so on, is notified as a Reference.

For example, the SHIORI can change the movement of the ghost based on References.

In the OnMouseClick example, many ghosts change which function they perform or what they say based on which part of the scope is clicked.

All References are given serial numbers starting from 0 and References with the same ID SHIORI Event almost always have the same content corresponding to the same number .

This may be easier to understand by looking at the list of References notified with IDs in each section of the SHIORI Event list page

However, depending on the ID, the number of references may be indeterminate.

For example, on the SHIORI Event list page, if you look at the References for the SHIORI Event installedghostname, there are no numbers specified, but rather "Reference*".

The installedghostname is a SHIORI Event that occurs immediately after startup and lists the names of all the ghosts installed in the baseware. The number of ghosts installed varies from user to user, so the Reference is also indefinite.

Even if the total number of References is indefinite, the principle that all References are numbered consecutively starting from 0 remains.

Not only do all SHIORI Events have various IDs, but the issuance itself has two different forms and purposes.

One is the issuance of the SHIORI Event as the timing of the ghost's movement, as mentioned above.

This is called a GET command, and as the name implies, it issues a SHIORI Event for the baseware to receive (GET) operation instructions (Sakura Scripts) and other contents from the SHIORI.

The other NOTIFY command is a little more specific: Ghosts cannot move in a SHIORI Event issued with the NOTIFY command.

This is because even if the SHIORI sends back some action instructions in response to a SHIORI Event with the NOTIFY command, the baseware is supposed to ignore this.

The purpose of the NOTIFY command is to inform (notify) the SHIORI of information (Reference).

Rather than using the received information for that SHIORI Event, the SHIORI can use it for future ghost operations.

The installedghostname mentioned above is typical of the IDs issued by the NOTIFY command; from its Reference, the SHIORI can determine what ghosts are installed in the user's environment. The ghost could use this information to create a feature, for example, "If a particular ghost is installed, the menu will display an item to call that ghost".

It is important to note that the existence of two commands does not mean that SHIORI Event IDs can be divided into two "groups".

In principle, all SHIORI Events for all IDs may be issued as either NOTIFY or GET. The type of command and type of ID are independent of each other and are essentially not dependent on each other (although certain trends and rules can be observed when looking at actual implementations. See the respective sections of the SHIORI Event list page for details.)