Ghost Functioning
| Ghost Functioning | |
|---|---|
| Type | Guide |
| Category | Other |
General functioning
A ghost is run by an ukagaka platform such as SSP, Materia or CROW. It's basically a program run by another program.
However, it is more complex than this. A ghost and its platform (or 'baseware') run with a server-client relation, in which the ghost is the server and the platform is the client. The two use the SSTP protocol to communicate (Sakura Script Transfer Protocol). The relationship is different between a ghost and its plugins or modules. The baseware sends a request to the ghost, then the ghost responds.
Requests and communication between the programs
The Sakura Script Transfer Protocol
Sakura scripts are what we usually call dialogues. So it's the protocol to transfer dialogues between the two programs.
This protocol is used between the baseware and the ghost and is similar to an internet protocol, as FTP or HTTP. It has been made for ghosts.
A request sent has the name and the version of the SHIORI (the part of the ghost that handles requests), the charset, a security level depending on where the two programs are, the sender of the request, the ID of the function called, the status of the ghost (if it has a status), the value of the sakura script (the chain of characters of the dialogue) and information put in the references. Here is an example of exchanges:
// request GET SHIORI/3.0 Charset: UTF-8 Sender: SSP SecurityLevel: local Status: choosing,balloon(0=2) ID: OnChoiceSelect Reference0: CANCEL // response (Execution time : 0[ms]) SHIORI/3.0 200 OK Sender: AYA Charset: UTF-8 Value: \0* Ok.\e // request GET SHIORI/3.0 ID: OnTranslate Charset: UTF-8 Sender: SSP SecurityLevel: local Reference0: \0* Ok.\e Reference1: Reference2: OnChoiceSelect Reference3: CANCEL // response (Execution time : 16[ms]) SHIORI/3.0 200 OK Sender: AYA Charset: UTF-8 Value: \0* Ok.\e
Let's understand what happened here. The requests are from SSP and the responses are from a ghost. The user here clicked on the cancel option in the ghost's menu. There are two types of requests: get and notify. Notify won't display the sakura script (the dialogue) whereas get would. Here the requests are get so that the sakura script would be displayed.
Let's begin with the first request. The first line is the type of the request and the version of the SHIORI, 3.0. Then we have the charset, the sender (SSP), the security level (local because both programs are on the same computer), the status of the ghost (the balloon of the main character is opened and its id is 2 and there are options visible, so the status is choosing), the ID of the function called, OnChoiceSelect, for the first request, and reference0 is the name of the option the user selected.
Then the ghost responds. The first line is again the SHIORI and its version, but there is the response code and its translation, 200 meaning ok, 204 no content, 400 bad request. It's the same codes as HTTP. The sender is AYA because the ghost is coded in AYA so that's the name used for the sender, then there is the charset again. But here we have the transfer of a sakura script, “\0* Ok.\e”, sent by the ghost.
For the second request, ghosts have a function called OnTranslate that can be used to filter or to make changes to the dialogues before the platform displays them. So SSP sent the sakura script back to the ghost, calling OnTranslate this time with in the references the name of the function at the origin of the dialogue and its references. Then, the SHIORI sent the dialogue back to SSP again, OnTranslate didn't make any change to it and returned it as it was. Now, SSP would display it in the balloon.
If the response is 204 No Content, the sender would be empty.
The communication between a ghost and its plugins or modules (SAORI)
Plugins or modules for ghosts are called SAORI (Supplemental Archive Onto Restricted Intelligence). They add new features to a ghost such as being able to search a page on wikipedia or having a music player able to read any kind of songs.
The communication between ghosts and SAORI is similar to as with the baseware. But the requests aren't internet requests, only information sent to the other program, given to it through the computer memory.
// request to library // name : C:\Users\Documents\ssp\ghost\Azura\ghost\master\saori\mciaudior.dll EXECUTE SAORI/1.0 Sender: AYA SecurityLevel: Local Argument0: play // response from library (Execution time : 0[ms]) SAORI/1.0 204 No Content Charset: Shift_JIS
There is a new type of requests specific to SAORI, execute. Arguments replace references and Result replace Value. Though a SAORI can return many chain of characters, it would be written Value[n].
Internal ghost operating
The baseware can only call three functions in a ghost: request, load and unload. Load to boot up, unload to close — but the ghost has a third main function, request, to handle the requests sent.
The main file in a ghost is the SHIORI, the load, unload and request functions are in it. Another file can exist if the SHIORI isn't itself a .dll: a .dll module. That's the case for ghosts coded in AYA or in YAYA. The SHIORI would be a shiori.dic and an aya5.dll (for the fifth AYA version) or yaya.dll would exist. But for other languages such as kawari, this module and the SHIORI are the same .dll module, a shiori.dll.
It would be the .dll module that would receive the request from the baseware. The request function would analyse the request, call the function which ID is in the request and create the response before the module sends it to the sender of the request.
For the load and request functions, the baseware would store its message in a place in the computer memory and would give where it is to the SHIORI. It's the SHIORI that free the memory.
