May 22nd 2025: A large number of spam user accounts have been removed from the wiki. If your account was accidentally deleted during this process, please get in contact to have it restored!

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
guide:communication [2023/11/27 04:55] – Moved during guide overhaul, originally written by Cherry and Levidre ulde3guide:communication [2025/11/05 16:45] (current) – [Sending and receiving external SHIORI Events] Fix broken syntax ulde3
Line 1: Line 1:
 ====== Communication ====== ====== Communication ======
-{{page>wiki:banners#Old Wiki Page}} 
 <WRAP right> <WRAP right>
 ^  Communication  ^^ ^  Communication  ^^
 ^ Type | Guide | ^ Type | Guide |
-^ Category | AYA/YAYA |+^ Category | Other |
 </WRAP> </WRAP>
  
-===== The back and forth method ===== +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.
-I figured out code on how to get two ghosts to have an actual conversation back and forth!+
  
-For debugging purposes at least, I have a menu option to Start conversation with the target ghost. +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.
-<code>// Optional: This is part of a menu to start the conversation +
-“\n\n[half]\![*]\q[Start Ghost Convo,InitiateGhostConvo]”</code>+
  
-Then this function starts the conversation. Replace SPEAKERGHOST with the name of the ghost currently speaking. Replace TARGETGHOSTNAME with your intended conversation target. The important part is the \![raiseother,...] command. + 
-<code> +{{SIDETOC width18}} 
-Select.InitiateGhostConvo+ 
 +===== Important considerations ===== 
 +==== Ghost name vs. sakura name ==== 
 +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 [[ghost: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. 
 + 
 +==== SHIORI-agnostic ==== 
 +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. 
 + 
 + 
 +===== Styles  of communication ===== 
 +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 ===== 
 +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. 
 + 
 + 
 +==== Sending and receiving external SHIORI Events ===== 
 +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 [[https://ukagakadreamteam.github.io/ukadoc/manual/list_shiori_event_ex.html|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 [[https://ukagakadreamteam.github.io/ukadoc/manual/list_sakura_script.html#_!_raiseother,ghost_name,event_name,r0,r1,r2..._|description of the raiseother tag on Ukadoc]] for details of how this tag is to be implemented. 
 + 
 + 
 +=== Raise vs Notify === 
 +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 [[https://ukagakadreamteam.github.io/ukadoc/manual/memo_shiorievent.html#chapter3|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 [[https://ukagakadreamteam.github.io/ukadoc/manual/list_shiori_event.html#OnNotifyDressupInfo|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. 
 + 
 + 
 +=== Target === 
 +raiseother and notifyother tags can either send their events to specific targets, or they may use ''<nowiki>__SYSTEM_ALL_GHOST__</nowiki>'' 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 ''<nowiki>__SYSTEM_ALL_GHOST__</nowiki>''. 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 [[ghost: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. 
 + 
 + 
 +==== Listening to another ghost's dialogue ==== 
 +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 [[ghost: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 [[https://ukagakadreamteam.github.io/ukadoc/manual/list_sakura_script.html#_!_set,otherghosttalk,true_false_before_after_|its listing on Ukadoc]] for more details. Once this has been done, the event [[https://ukagakadreamteam.github.io/ukadoc/manual/list_shiori_event.html#OnOtherGhostTalk|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 [[ghost:Noodle]] will respond any time that the ghost [[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. 
 + 
 + 
 +==== Commenting on the presence or installation status of another ghost ==== 
 +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_''. 
 + 
 +[[https://ukagakadreamteam.github.io/ukadoc/manual/list_shiori_event.html#installedghostname|installedghostname]] gives a list of all the currently installed ghosts, and [[https://ukagakadreamteam.github.io/ukadoc/manual/list_shiori_event.html#otherghostname|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): 
 + 
 +<code c> 
 +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
 { {
-     "\0\s[0]* yo TARGETGHOSTNAME that you?\![raiseother,TARGETGHOSTNAME,OnCommunicate,SPEAKERGHOST,greeting]\w8\w8\e"+ "You've met Mr. Example, right? He's a friend of mine, maybe we can all hang out sometime."
 } }
 </code> </code>
  
-==== Now, add this in commu.dic for each ghost: ==== + 
-The **OnCommunicate** function needs this bolded text added somewhere: +==== Reacting to another ghost being opened, closed, uninstalled, etc. ==== 
-<code> +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 [[https://ukagakadreamteam.github.io/ukadoc/manual/list_shiori_event.html#OnGhostChanged|listed on Ukadoc]], including OnGhostChanged, OnGhostChanging, OnGhostCalled, OnGhostCalling, OnGhostCallComplete, OnOtherGhostBooted, OnOtherGhostChanged, and OnOtherGhostClosed. 
-OnCommunicate+ 
 +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 [[https://ukagakadreamteam.github.io/ukadoc/manual/list_shiori_event.html#OnVanished|OnVanished]] and [[https://ukagakadreamteam.github.io/ukadoc/manual/list_shiori_event.html#OnOtherGhostVanished|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 ===== 
 +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. 
 + 
 + 
 +==== Some notes on back and forth conversation ==== 
 +Back and forth communication can be achieved in a number of ways. The event made expressly for this purpose is [[https://ukagakadreamteam.github.io/ukadoc/manual/list_shiori_event.html#OnCommunicate|OnCommunicate]], but it can also be achieved with the [[https://ukagakadreamteam.github.io/ukadoc/manual/list_sakura_script.html#_!_raiseother,ghost_name,event_name,r0,r1,r2..._|raiseother SakuraScript tag]], or by using [[https://ukagakadreamteam.github.io/ukadoc/manual/list_shiori_event.html#OnOtherGhostTalk|OnOtherGhostTalk]] as described in a [[#Listening to another ghost's dialogue|previous section]]. 
 + 
 + 
 +=== Difficulty if the first part of a conversation is missed === 
 +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 [[ghost:X. Template]]. Examples of this can be seen in interactions between the ghosts [[ghost:S the Skeleton]] and [[ghost: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: 
 + 
 +{{guide:communication:back_and_forth_plain.gif}} 
 + 
 +The following is with the "reflect system" in ghosts such as X. Template: 
 + 
 +{{guide:communication:back_and_forth_with_reflect_system.gif}} 
 + 
 +(The ghosts in the above gifs are [[ghost:Dusty and Obsidian]] and [[ghost:S the Skeleton]].) 
 + 
 + 
 +=== New information changing a ghost's perspective === 
 +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. 
 + 
 + 
 +=== Number of ghosts involved === 
 +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 ==== 
 +[[https://ukagakadreamteam.github.io/ukadoc/manual/list_shiori_event.html#OnCommunicate|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. 
 + 
 +=== AYA / YAYA === 
 +In AYA and YAYA, communication can sent by specifying the sakura name of the target ghost in the variable ''res_reference0''. 
 + 
 +  res_reference0 = "Someone" 
 + 
 +=== Satori ===   
 +In Satori, communication can be sent by specifying the sakura name of the target ghost with Value0. 
 + 
 +  ＄Value0【タブ】Someone 
 + 
 +=== Kawari === 
 +More information about how to initiate communication in Kawari can be found [[https://okuajub-netspace.neocities.org/Kawari/tips#communicate|here]]. <wrap important>Someone please change this listing once we learn more!</wrap> 
 + 
 +=== Aosora === 
 +In Aosora, communication can be sent by specifying the sakura name of the target ghost in Shiori.ResponseReference. 
 + 
 +  Shiori.ResponseReference.Add("Someone"); 
 + 
 +=== Misaka === 
 +In Misaka, communication can be sent by specifying the sakura name of the target ghost in the variable ''to''. 
 + 
 +  {$to=Someone} 
 + 
 +Note that Misaka has special setup for ghost communication. Communication from other ghosts is received with the event ''$_OnGhostCommunicateReceive''. The system variable ''{$sender}'' contains the name of the ghost that sent the communication, and the system function ''{$inlastsentence}'' contains the script that the other ghost played. 
 + 
 +=== Usage example === 
 +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: 
 + 
 +<code c> 
 +//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
 { {
-     if reference0 == “SPECIFIC/TARGET GHOST NAME" + res_reference0 = "B's sakura" 
-     { +  
-          TalkToSpecificGhost + _dialogue_tag = SPLIT(reference1,"\e:")[1] //This gets the part after the \e: 
-     } + if _dialogue_tag == "response 2" 
-     -- + { 
-     if reference0 == "user" || reference0 == "User" + "How have things been with you?\w8\e:response 3" 
-     { + } 
-          //---- 사용자로부터의 이야기에 대답 + elseif _dialogue_tag == "response 4" 
-          ReplyToUser + { 
-     } + "Fine! I've got to go now, though, so I'll see you around!\w8\e:end" 
-     else + }
-     { +
-          //---- 유령로부터의 이야기에 대답 +
-          ReplyToGhost +
-     }+
 } }
 </code> </code>
-(tbh that's probably not the best spot to drop it in OnCommunicate, but it works there) 
  
-Put this anywhere in Commu.dic: +<code c> 
-<code> +//In Ghost B's files: 
-// This function handles incoming and outgoing dialogue for the specified ghost. +OnConversation.GhostA
-TalkToSpecificGhost+
 { {
-     case reference1 // reference1 is the name of the conversation piece + res_reference0 = "A's sakura" 
-     { +  
-          when "greeting" + _dialogue_tag = SPLIT(reference1,"\e:")[1] //This gets the part after the \e: 
-          { + if _dialogue_tag == "response 1" 
-               "\0\s[0]* hey there TARGETGHOST. this is greeting leading to part1. \0\![raiseother,TARGETGHOST,OnCommunicate,SPEAKERGHOST,part1]\e" + { 
-          } + "Hey Ghost A! Fancy meeting you here.\w8\e:response2" 
-          when "part1" + } 
-          { + elseif _dialogue_tag == "response 3" 
-               "\0\s[0]* that's cool man. this is part1 leading to part2\0\![raiseother,TARGETGHOST,OnCommunicate,SPEAKERGHOST,part2]\e" + { 
-          } + "Oh, not bad, you?\w8\e:response 4" 
-          when "part2" + } 
-          { + elseif _dialogue_tag == "end" 
-               "\0\s[0]* i ran out of things to say, but this is part2 leading to part3\0\![raiseother,TARGETGHOST,OnCommunicate,SPEAKERGHOST,part3]\e" + { 
-          } + 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 
-          when "part3" + "Alright then, see you!" 
-          { + }
-               "\0\s[0]* i ran out of things to say, but this is part3 leading to part4 \0\![raiseother,TARGETGHOST,OnCommunicate,SPEAKERGHOST,part4]\e" +
-          } +
-          when "part4" +
-          { +
-               "\0\s[0]* i ran out of things to say, but this is part4 leading to ending\0\![raiseother,TARGETGHOST,OnCommunicate,SPEAKERGHOST,ending]\e" +
-          } +
-          when "ending" +
-          { +
-               "\0\s[0]* this is the end of our conversation. bye bye!" +
-               //\0\![raiseother,TARGETGHOST,OnCommunicate,SPEAKERGHOST]\e" +
-          } +
-     }+
 } }
 </code> </code>
-Remember, the above text needs to be added for BOTH ghosts, and replace the SPEAKER/TARGETGHOST name with the correct name. The names will be swapped in the 2nd character's commu.dic file so don't forget. 
  
-This is surely not the best way to implement it, but it’s what I got to work so far, and is mainly just to share with [[dev:zarla|zarla-s]] because it's too much for regular msgs haha. 
  
-===== The communicate method ==== +==== raiseother ==== 
-The advantage of the back and forth method is that the ghost can call any function that starts by On and not only OnCommunicate. It calls the function specified in the raiseother command. Though it's always better to know which ghost called you and it would allow the other ghosts to use both methods if it calls OnCommunicate.+The [[https://ukagakadreamteam.github.io/ukadoc/manual/list_sakura_script.html#_!_raiseother,ghost_name,event_name,r0,r1,r2..._|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.
  
-The "communicate method" uses the communication between two ghosts when the back and forth method was forcing the other ghost to run a function. The inconvenient of it is unlike the back and forth method it would always call OnCommunicate.+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.
  
-==== How to implement the communicate method ==== +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.
-Starting a communication with an other ghost is simple. You just need to put **res_reference0="GHOSTNAME"** before the line of dialogue, where you replace GHOSTNAME by the name of the ghost with who you want to communicate. The line of dialogue would be sent to the other ghost. The other ghost OnCommunicate would run with in reference0 the name of the ghost who communicated and reference1 the dialogue said.+
  
-The advantages of this method, in plus that a shorter command, are being able to have more information. The information given by the back and forth method are only the references sent through the command when the communicate method already gives all the information in the references by default : the name of the ghost who communicated in reference0 and the dialogue sent in reference1. So with the communicate method, putting all the information in the references or creating new functions isn't needed.+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:
  
-A little example (keep in mind that ReplyToGhost is called in OnCommunicate, so the references' value don't change) : +<code c> 
-<code> +//In Ghost A's files: 
-ReplyToGhost+//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
 { {
-     res_reference0 = reference0 + if reference0 == "response 2" 
-     dialogue_sayed = TOLOWER(reference1) + { 
-     if reference0=="a_ghost" + "How have things been with you?\w8\![raiseother,Ghost B,OnConversation.GhostA,response 3]" 
-     { + } 
-          "\0\s[0]* Hello a_ghost. How are you today ?\e" + elseif reference0 == "response 4" 
-     } + { 
-     elseif "hello" _in_ dialogue_sayed + "Fine! I've got to go now, though, so I'll see you around!\w8\![raiseother,Ghost B,OnConversation.GhostA,end]" 
-     { + }
-          "\0\s[0]* Hello, how are you ?\e" +
-     } +
-     elseif "how are you" _in_ dialogue_sayed +
-     { +
-          "\0\s[0]* I'm fine, and you ?"\e +
-     } +
-     else +
-     { +
-          "\0\s[0]* Hello %(reference0), I didn't recognized you nor understood what you said.\e" +
-     }+
 } }
 </code> </code>
-With this method, modifying the two ghosts isn't needed. You can just check for particular dialogues and put responses to them. You can do both general and precise stuffs. 
  
-{{tag>AYA Guide YAYA wiki.needs style revision}}+<code c> 
 +//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!" 
 + } 
 +} 
 +</code> 
 + 
 + 
 + 
 + 
 +==== OnOtherGhostTalk ==== 
 +Since I mentioned it in a [[#Listening to another ghost's dialogue|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.) 
 + 
 + 
 +==== Other types of active communication ==== 
 +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. 
 + 
 + 
 +===== Communicating through external means (plugins, 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. 
 + 
 + 
 +==== 共有変数プラグイン (Shared value plugin) ==== 
 +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. 
 + 
 + 
 +==== Inventory ==== 
 +The plugin [[https://github.com/ambergon/ukagakaPlugin_Inventory|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. 
 + 
 + 
 +==== Wallet of UNYU ==== 
 +The plugin [[https://github.com/nikolat/wallet_of_unyu|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. 
 + 
 + 
 +===== Ghosts with communication features ===== 
 +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: 
 +  * [[ghost:FLUX]] 
 +  * [[ghost:Hydrate]] 
 +  * [[ghost:LOBO]] 
 +  * [[ghost:Needle]] 
 +  * [[ghost:Presentable Can]] 
 +  * [[ghost:zzzzzzzzz]] 
 + 
 +Ghosts with back and forth conversations: 
 +  * [[ghost:Hunter and Smoker]] and [[ghost:Jockey]] 
 +  * [[ghost:Dusty and Obsidian]] and [[ghost:Elsen]] 
 +  * [[ghost:Dusty and Obsidian]] and [[ghost:MiniDev]] 
 +  * [[ghost:Dr. W.D. Gaster]] and [[ghost:Ghost Jam Temmie]] 
 +  * [[ghost:S the Skeleton]] and [[ghost:Dusty and Obsidian]] 
 +  * [[ghost:S the Skeleton]] and [[ghost:Lulo]] 
 + 
 +Ghosts that react to the dialogue of other ghosts: 
 +  * [[ghost:Azura]] (reacts to [[ghost:Dr. W.D. Gaster]]) 
 +  * [[ghost:Noodle]] (reacts to [[ghost:Needle]]) 
 +  * [[ghost:S the Skeleton]] (reacts to [[ghost:Dr. W.D. Gaster]]) 
 + 
 +Ghosts that comment on the presence or installation status of other ghosts: 
 +  * [[ghost:Dusty and Obsidian]] 
 +  * [[ghost:Frisk]] 
 +  * [[ghost:Lulo]] 
 +  * [[ghost:Multiverse Sans]] 
 +  * [[ghost:S the Skeleton]] 
 + 
 + 
 +{{tag>Guide}}

Trace:

Explore Content

Ghosts

Balloons

Freeshells

Calendar Skins

Plugins

SAORI

Tools

Guides

Templates

Events