Communication

Communication in the context of this guide refers to different ghosts interacting with each other in some way. This can be used for all sorts of purposes, from two different ghosts having a back and forth conversation, to sharing stats, to reacting to things another ghost is doing, and more. Various methods of communication will be outlined here, as well as considerations for each one.

Note that this guide is not exhaustive, nor is it rules about how you must do things. There are some recommendations for how certain methods are best used, but you may find solutions that fit your ghost's needs better, or invent a new way to facilitate communication between certain ghosts.

One of the most important things to know about ghost communication is that some types of communication use the ghost name of the ghost you want to communicate with, while many others use the sakura name. For a ghost such as Call of the Sea, “Call of the Sea” is the ghost name and “Conch” is the sakura name.

Which name is used where seems arbitrary at times, but it has to be maintained as-is to preserve compatibility for older ghosts. Any time you're working with communication, keep this in mind, and make sure you're looking out for whether you need to be using the ghost name or the sakura name. There are a few events that will provide both, but there are plenty that do not.

Communication is completely SHIORI-agnostic. Because communication is handled by the baseware through SHIORI events and SakuraScript tags, any ghost may communicate with any other ghost, regardless of what programming language is used to make them. YAYA ghosts can communicate with Kawari ghosts, Satori ghosts, etc., and vice versa. The only exception to this is that not all SHIORI may provide a way to send a message to others via the OnCommunicate event, in which case other methods of communication would need to be used.

While not in any official documentation, it could be said that there are two “styles” of communication. In this guide, we will use the terms “passive communication” and “active communication” to distinguish between these styles.

“Passive communication” will be used to describe types of communication where the communication does not require any collaborative effort from the developers. Each developer can implement it on their own, at different times, and it will work.

“Active communication” will be used to describe types of communication where the developers of all of the involved ghosts must work together to implement the function.

Passive communication tends to be easier to set up and may be implemented more broadly, while active communication tends to be much more involved and have hand-crafted responses for each group of characters that are interacting.

Passive communication is generally a much easier form of communication to set up. Usually it involves the developer(s) of one ghost (or plugin, etc.) setting up an event of some kind that other ghosts can react to, and then at any point in the future, any other ghost developer can make their ghost respond just by knowing what event to add or what data to send back.

The major benefit of passive communication is that it can be implemented independently by developers, without the need to actively coordinate with someone else. This can be useful because direct collaboration can be a lot more work, or may not be feasible due to time constraints, etc. It also means that even ghosts which have not been updated for many years can still be interacted with in some form.

The potential downside is that this style of communication can become so broad that interactions may feel generic, depending on how they are implemented. Interactions with a “hand-crafted” feel are usually found in more active communication styles, although passive communication styles can certainly still be very customized and individual. It all depends on the approach, so it's worth keeping this potential effect in mind.

This is communication at its most basic. This method is much the same as the way that ukagaka works in general, so much so that you can often find these kinds of events listed on Ukadoc's External SHIORI Events list.

The way ukagaka works is that the baseware sends events, and if the ghost responds with a script, then that response script is displayed. The same is true of this kind of communication as well: a ghost sends out a SHIORI event using the \![raiseother] or \![notifyother] tags, the baseware passes this event along to your ghost, and if you want your ghost to respond you simply need to add a response for that event.

See the description of the raiseother tag on Ukadoc for details of how this tag is to be implemented.

Events that are called with “raise” will be sent as [GET], while events that are called with “notify” will be sent as [NOTIFY]. Basically, this means that events that are called with raise can have a response displayed, while events that are called with notify can never display a script. For a full description of GET vs NOTIFY, please see the explanation on Ukadoc.

In general, “raise” should be used in cases where the receiving ghost may want to play a script in response. Notify should be used when a script output would not be desirable. Notify events are used for things like updating variables, as can be seen in normal SHIORI events like OnNotifyDressupInfo.

For example, you might use a raise event to tell other open ghosts that your ghost has just told a bad joke, and prompt them to laugh. You might use a notify event if your ghost has a function like a music player, and you want other ghosts to be able to tell what song is currently playing.

raiseother and notifyother tags can either send their events to specific targets, or they may use SYSTEM_ALL_GHOST to target every open ghost at once. Which is ideal for your event depends on what you are making.

For example, if your ghost has a music player function and you want other ghosts to be able to tell what song is playing, it's probably best to send that information to every open ghost at once with SYSTEM_ALL_GHOST. That way any ghost can simply receive the info and handle it as they see fit with no additional steps.

On the other hand, for a function like Needle's ghost poking, where Needle sends the event OnNeedlePoke after overlapping with a ghost, it makes sense to only send the event to the ghost that was specifically poked.

It is possible for your ghost to listen to the dialogues of another ghost, and react to things within it. This is how machine translation ghosts such as Ukatranslator are possible.

In order to do this, your ghost must run the tag \![set,otherghosttalk], and set it to a value other than false. See its listing on Ukadoc for more details. Once this has been done, the event OnOtherGhostTalk will run each time another ghost talks.

Take caution with this event: if there are many ghosts open at once, this event may be called rapidly.

OnOtherGhostTalk provides various information as references. This includes the name of the ghost (and the ghost's sakura) so that you can tell which ghost talked, the script that it played, and the reference information the ghost had when it played that script. Using all of this, you can react to pretty much anything you want, as long as you can distinguish it.

This can be used for many things because of all the information sent as references. Usually, though, it will be used in one of two ways: responding to a particular event that occurred in a ghost, or responding to a specific dialogue in a ghost.

As an example of responding to a particular event in a ghost, the ghost Noodle will respond any time that the ghost Needle is double clicked or “pokes” another ghost. In these cases, Needle will output a dialogue like “needle needle”, but the exact words change. By detecting one of these events, Noodle is able to parse Needle's dialogue, and echo the words that were said (if Needle says “poke poke”, Noodle will respond with “poke poke~~”, etc.).

Noodle is also an example of responding to a particular dialogue in a ghost. If both Needle and Noodle are open, Noodle will react to specific dialogues from Needle and add commentary or additional context.

Some ghosts, particularly if they are related to each other in some way, may have special comments or behavior if they detect that a particular other ghost is installed, or is running at the same time as them.

This is done through a couple of SHIORI events. Note that these event names do not begin with “On”, but in AYA and YAYA they must be written with the prefix On_.

installedghostname gives a list of all the currently installed ghosts, and otherghostname gives a list of all the currently running ghosts.

To make use of these events, you may wish to save the lists they generate to a variable, or you may wish to process the list within the event and set some variables there. Either way, once you have the information, it becomes trivial to add a check in your aitalk or other events to add special behavior based on the presence or absence of another ghost.

It's important to note that installedghostname lists ghosts by their ghost name, while otherghostname uses the name of the sakura character in that ghost.

A basic implementation in YAYA might look something like this (note that in YAYA, installedghostlist is a variable created within the YAYA as SHIORI base dictionary):

On_otherghostname
{
	MrExampleOpen = 0
	foreach reference.raw; _ref
	{
		if _ref[0,C_BYTE1] == "Example T. Guide"; MrExampleOpen = 1
	}
}
 
//Elsewhere in RandomTalk...
if MrExampleOpen
{
	"Hey, it's Mr. Example!"
}
elseif ASEARCH("Mr. Example",installedghostlist) != -1 //Installed but not open
{
	"You've met Mr. Example, right? He's a friend of mine, maybe we can all hang out sometime."
}

On the topic of noticing when other ghosts are open or installed, etc., there are also some basic SHIORI events that could be considered a form of passive communication. There are a whole range of them listed on Ukadoc, including OnGhostChanged, OnGhostChanging, OnGhostCalled, OnGhostCalling, OnGhostCallComplete, OnOtherGhostBooted, OnOtherGhostChanged, and OnOtherGhostClosed.

You can use these to react to the user changing to other ghosts, calling other ghosts, closing other ghosts, and more.

You might also consider events such as OnVanished and OnOtherGhostVanished, which can allow your ghost to react if another ghost gets uninstalled.

How you use these events is up to you, but they are a quick and easy way of interacting with other ghosts. On their face they may seem like they're mostly useful for ghosts which acknowledge that they're on the user's desktop and literally see the other open ghosts, but they can be used creatively to suit a variety of styles.

For example, a ghost with a café setting could use the OnOtherGhostBooted event to have a diagetic dialogue implying that the booted ghost entered through the café's door and caused a bell to ring, or was greeted by the café staff. The uses for these events are limited only by your imagination.

Active communication tends to be more intricate and involve hand-crafted interactions between different ghosts. “Hand-crafted” meaning things like a conversation between two characters who know each other and banter back and forth. This is achieved by two or more ghosts coordinating and updating (or releasing) to have custom communication content shared between them. This may be between different developers collaborating, or it could be multiple ghosts by the same developer.

The upside of this kind of communication is that it can be a very immersive experience, and can involve new content shared between the ghosts that the user can't see anywhere else. Contrast this with generic responses to events like OnOtherGhostBooted, where a ghost may simply greet every other ghost that boots by name. Both types of communication are good, but a general greeting used for every ghost has a very different feeling to two different ghosts engaging in a full conversation.

The major downside of this is that it involves coordinating multiple ghosts, and often collaboration between multiple developers. This means it is vastly more work than passive communication styles, and it also cannot be used with older ghosts whose developers no longer maintain them. Another potential issue is that if the user updates one ghost but not the other(s), they will not be able to use the communication features and may encounter buggy behavior. All in all, this is a much more difficult form of communication to implement.

Back and forth communication can be achieved in a number of ways. The event made expressly for this purpose is OnCommunicate, but it can also be achieved with the raiseother SakuraScript tag, or by using OnOtherGhostTalk as described in a previous section.

Regardless of the method used, one of the potential problems with this kind of direct interaction is that if there are multiple responses back and forth, and the user is not closely watching their ghosts, they might miss earlier responses since the balloon is reset each time. There have been some attempts to solve this, such as the “reflect system” included in X. Template. Examples of this can be seen in interactions between the ghosts S the Skeleton and Dusty and Obsidian. It can be tricky to set up, but it is possible to make back and forth conversation between two ghosts look as natural as conversation between a sakura and kero in a single ghost.

The following is an example of what a back and forth conversation looks like with no extra processing:

The following is with the “reflect system” in ghosts such as X. Template:

(The ghosts in the above gifs are Dusty and Obsidian and S the Skeleton.)

Another thing to consider with back and forth conversations is that this is best used between ghosts for whom it will not introduce new information which changes their behavior.

This has been an issue speculated about for certain styles of ghost, where if they learn certain information about the user, they might become withdrawn/less friendly towards the user. Particularly, this may be a problem for ghosts that have a “negative route” which allows the user to be unkind, and in which that sort of behavior is intended to have ramifications.

The issue this causes is that in order for such an interaction to be meaningful, it might make the most sense for the ghost in question to use a completely different pool of dialogue than what they used before, or otherwise change their behavior permanently. This is potentially a vast amount of work, and may be a poor user experience.

This concept could be executed well, especially if it is planned from the outset and is a core feature of the ghost, but it isn't usually what developers have in mind when they want to add conversations with other ghosts.

Typically, back and forth conversations will only take place between two ghosts. However, there is nothing stopping you from writing conversations that take place between more than 2 ghosts, other than the increasing difficulty of coordinating multiple ghosts together, and getting the user to run that many ghosts at once in order to see the content.

It is entirely possible to create an interaction that involves conversation between many ghosts, but it is likely that such an approach would be best for ghosts which were made with this feature in mind from the start, and have a large emphasis placed on it.

OnCommunicate is the ideal event for ghosts having a back and forth conversation. It also has an associated input box (the communicate box) which can be used for responding to user input, but this guide will not cover that functionality.

With OnCommunicate, the reference information sent with the event will contain the name of the ghost that sent the communication, as well as the contents of the script that was displayed.

In order to determine what part of a conversation the ghost is in and how to respond, it may be useful to include some additional data in scripts that can be checked for. It is common in some ghosts to include some text after a \e tag indicating what conversation it is. Additional data may also be included, such as the output of a particular word group that was used in the script, or some other data relating to the ghost's current stats, etc. It is arbitrary, and therefore only limited by your imagination.

How OnCommunicate is initiated depends on the SHIORI.

• In AYA and YAYA, communication can sent by specifying the sakura name of the target ghost in the variable res_reference0. Example: res_reference0 = “Someone”
• In Satori, communication can be sent by specifying the sakura name of the target ghost with Value0. Example: ＄Value0【タブ】Someone
• More information about how to initiate communication in Kawari can be found here. Someone please change this listing once we learn more!
• In Aosora, it is not currently possible to send scripts to other ghosts via OnCommunicate.
• In Misaka, communication can be sent by specifying the sakura name of the target ghost in the variable to. Example: {$to=Someone}

A back and forth conversation between two ghosts using the OnCommunicate method could look like this. This example assumes both ghosts are written in YAYA:

//In Ghost A's files:
//Somewhere else in the code, maybe in a menu choice or in RandomTalk (using a separately raised event so that res_reference0 only triggers for this dialogue), conversation is started with this script: "Hey Ghost B, good to see you!\w8"
OnConversation.GhostB
{
	res_reference0 = "B's sakura"
 
	_dialogue_tag = SPLIT(reference1,"\e:")[1] //This gets the part after the \e:
	if _dialogue_tag == "response 2"
	{
		"How have things been with you?\w8\e:response 3"
	}
	elseif _dialogue_tag == "response 4"
	{
		"Fine! I've got to go now, though, so I'll see you around!\w8\e:end"
	}
}

//In Ghost B's files:
OnConversation.GhostA
{
	res_reference0 = "A's sakura"
 
	_dialogue_tag = SPLIT(reference1,"\e:")[1] //This gets the part after the \e:
	if _dialogue_tag == "response 1"
	{
		"Hey Ghost A! Fancy meeting you here.\w8\e:response2"
	}
	elseif _dialogue_tag == "response 3"
	{
		"Oh, not bad, you?\w8\e:response 4"
	}
	elseif _dialogue_tag == "end"
	{
		res_reference0 = "" //Clear the variable set above, since this is the end of the conversation and we don't want to ping the other ghost again
		"Alright then, see you!"
	}
}

The raiseother tag can be used to directly raise an event in another ghost. This can be done without the approval of that ghost's developer (in which case it would probably classify as passive communication) but may be considered rude, especially if it interferes with the operation of the ghost in some way.

In the case of active communication though, this can be used to coordinate an interaction between different ghosts. This can be used for a simple back and forth conversation by raising events that output dialogue, or it could be used to raise special events that make some other kind of interaction happen. Perhaps something like unlocking secret functions, etc.

Note that when an event is raised with the raiseother tag, there will be SSTP text in the balloon of the receiving ghost showing that this is the case and declaring where the event came from.

A back and forth conversation between two ghosts using the raiseother method could look like this. This example assumes both ghosts are written in YAYA:

//In Ghost A's files:
//Somewhere else in the code, maybe in RandomTalk, conversation is started with the script "Hey Ghost B, good to see you!\w8\![raiseother,Ghost B,OnConversation.GhostA,response 1]"
OnConversation.GhostB
{
	if reference0 == "response 2"
	{
		"How have things been with you?\w8\![raiseother,Ghost B,OnConversation.GhostA,response 3]"
	}
	elseif reference0 == "response 4"
	{
		"Fine! I've got to go now, though, so I'll see you around!\w8\![raiseother,Ghost B,OnConversation.GhostA,end]"
	}
}

//In Ghost B's files:
OnConversation.GhostA
{
	if reference0 == "response 1"
	{
		"Hey Ghost A! Fancy meeting you here.\w8\![raiseother,Ghost A,OnConversation.GhostB,response 2]"
	}
	elseif reference0 == "response 3"
	{
		"Oh, not bad, you?\w8\![raiseother,Ghost A,OnConversation.GhostB,response 4]"
	}
	elseif reference0 == "end"
	{
		"Alright then, see you!"
	}
}

Since I mentioned it in a previous section, I won't go into too much detail here. However, it is entirely possible to build up a conversation between ghosts by having both of them use OnOtherGhostTalk.

A potential upside of this method is that a conversation could be built up over time, without needing ghost developers to directly coordinate and synchronize updates. Theoretically, that's possible with the other forms of communication as well, but since OnOtherGhostTalk is used to react to other ghosts rather than directly contact them, it's a slightly different approach.

With OnCommunicate or raiseother, the first ghost to speak initiates it by specifically “broadcasting” communications to another ghost. The ghost that speaks first “pushes” the communication to the ghost that speaks second.

With OnOtherGhostTalk, communication is received by “overhearing” and responding to information from another ghost. The ghost that speaks second “pulls” the communication from the ghost that speaks first.

These different methods can achieve the same thing, but the reactionary approach could lend itself to different styles of interaction. For example, a conversation could be built up between two ghosts over time by simply adding more reactions to an existing conversation. This may help with issues such as one ghost not being updated, etc. (Although this is not a guarantee and depends on the way this is implemented in the ghost.)

Back and forth conversation is not the only thing active communication can be used for, although it is likely the most common since other types of communication could be achieved passively. Even so, the only limit here is your imagination.

It is possible to set up ghosts that coordinate with each other in any number of ways, whether it's trading information back and forth, affecting each other's functionality, etc.

Direct communication between ghosts isn't the only way to communicate, and several plugins have been devised that handle communication in different ways. Some of these could be considered passive communication styles, while others require coordination and could be considered active communication styles. It depends on how you approach it.

The plugin “共有変数プラグイン” (“Shared value plugin”) comes bundled with SSP, and can be used to share values between ghosts even if both ghosts are not open at the same time. Because the plugin runs all the time unless the user disables it, it is possible for one ghost to store a value in the plugin which another ghost can check later and initiate some sort of special behavior based on it.

The plugin Inventory is a plugin that can be used as a sort of “inventory” for the user, which ghosts can add items to or withdraw items from. This means that one ghost can deposit items, and a different ghost can take and use those items.

This could be done passively, by one ghost storing some sort of item and leaving it up to other developers if they want to make use of that item, or it could be done actively by different ghosts coordinating to share specific items between them. Either way, the inventory is maintained plugin-side, which means that the ghosts sharing the items don't need to be open at the same time for it to work.

Another intended use of the plugin is that certain ghosts may give the user a special item after a special event such as completing their story, etc. When the user clicks on the item in the plugin's menu, OnCommunicate is sent to all open ghosts, with information to be able to determine which item was clicked. This way, ghosts can have special commentary for rare items the user receives, etc.

The plugin Wallet of UNYU is a plugin-side “wallet” for the user that holds a fake “cryptocurrency” called UNYU. Any ghost may deposit UNYU into the wallet, and any ghost may withdraw UNYU.

While this isn't direct communication, it still operates in a sort of “shared ghost space”, and can facilitate interesting interactions where some ghosts are useful for gaining UNYU to spend in other ghosts.

The following is not an exhaustive list, but may be useful as a jumping off point for studying ghosts which make use of communication features. Please feel free to add more ghosts to this list.

Ghosts that send external events:

• FLUX
• Hydrate
• LOBO
• Needle
• Presentable Can
• zzzzzzzzz

Ghosts with back and forth conversations:

• Hunter and Smoker and Jockey
• Dusty and Obsidian and Elsen
• Dusty and Obsidian and MiniDev
• Dr. W.D. Gaster and Ghost Jam Temmie
• S the Skeleton and Dusty and Obsidian
• S the Skeleton and Lulo

Ghosts that react to the dialogue of other ghosts:

• Azura (reacts to Dr. W.D. Gaster)
• Noodle (reacts to Needle)
• S the Skeleton (reacts to Dr. W.D. Gaster)

Ghosts that comment on the presence or installation status of other ghosts:

• Dusty and Obsidian
• Frisk
• Lulo
• Multiverse Sans
• S the Skeleton