Overview
This is a tutorial on making changes to Interstellaria’s dialogue system. During the course of the tutorial you will learn how to alter existing dialogues, and create new dialogues from scratch. This portion will focus on ship dialogue, but much can be applied to planetside NPCs which will be covered in more depth in another tutorial.
Getting Started
The purpose of the guide is to teach people the basics of editing the dialogue in Interstellaria. For this purpose we will limit what we edit. We will be editing the space dialogues, that are in the commdialogue.xml file. Later in an other guide we’ll look at planetside NPCs and their dialogue. NPCs are a more complicated beast, so for now let’s learn the basics of how to make/edit dialogue.
Before we get into the meat of editing the files here is what you’ll need. Fortunately it is a short list.
I use Textpad++ for its search tools, and the fact it can handle multiple files easily at once. You can use regular notepad though if you don’t want anything special.
The only file we’ll touch for this tutorial is commdialogue.xml. It is located here: SteamsteamappscommonInterstellariaAssetsResourcesTextFiles
MAKE BACKUPS OF ANY FILE YOU ALTER
As Interstellaria does not currently have workshop support, you will be editing game files directly. That means that if you verify your game cache, or a game update is pushed that affects files you have altered, your changes will be lost. That means that if you mess something up and verify your files to fix it, all files will be reverted. So it pays to have unaltered backups of any file you edit.
Additionally since your files could be overwritten by an update, that means you should also make copies of your altered files. If the modding scene gains any traction, Coldrice may attempt to add workshop support and some ease of modding features, but for now we will make do.
When editing space comms dialogue, I found it was best to prepare a save file. First encounter a ship of a race you wish to edit the comm of. Exit the dialog and save the game. Do not leave the ship encounter by pressing the “X”. Save while in the encounter but after you exited the communication. This will mean that loading the save will toss you directly into the dialogue you have been editing. If you are unable to approach a ship due to them being hostile, you can edit your reputation level in the save file. Make sure the number is something like 100, that should give you a friendly communication encounter most if not all times. When you make a change to your comm file, save it, start the game, load up your save, and then either the comms will open automatically or you can initiate the conversation with the talk command.
Step 1: Prepping For First Dialogue
Right now we are going to take the Human Ship Comm and replace it with our own. So it would be helpful to set up a save where you encounter a human ship, as I described in the Save File Prep section.
Opening commdialogue.xml you will see plenty of code. If you have experience with this, it should all be pretty clear what is going on. If not here’s a quick run down.
1 <NPCS>
This line indicates what the data is to follow.
2 <talkers>
This pretty much follows from the first line.
3 <dialogue id=”Human”>
When you encounter a ship, the game will look for the data held within that race’s NPCS/talkers infor. So when you encounter a human ship the game loads up the dialogue id’d as Human.
4 <response>
This is the start of the information of the dialogues. The stuff shown in the dialogue boxes, and the choices the player can make.
There is a LOT of information within the Human dialogue, this is because you get different responses to questions as the game progresses. You can see a lot of duplicated <ctext> here. This will be explained later as we work to create a whole new dialogue tree. For now, we are going to remove EVERYTHING between the dialog id and </dialogue>.
When all is said and done your code should look like this.
If you saved commduialogue.xml and tried to force an encounter with a human ship and talk to them, it would possibly crash. So let’s not do that!
Step 2: Simple Dialogue
Starting with the following code, we will need to add our first dialogue screen.
We do this by adding a response like this.
Within the response tags will be any data that appears on a single dialogue screen. Let’s make the human captain greet us. This is treated by the code as Response 0. We’ll remove <NPCS> and <talkers> from the shown code here to reduce space.
If you were to save and then run this code, the captain would greet you, but you would be stuck in the dialogue window with no way to leave. Let’s add a single choice. All choices get wrapped in a <choice> and </choice>. Everything between them will inform how that single choice is presented and acts.
This code will now present the player with a message from the other ship, and give the player an option to select. That option has a text chosen to be shown, and when clicked it will perform the action <goto>999</goto>. This is a hardcoded goto destination. It will end the conversation.
Congrats! This is a single dialogue screen that will let the player respond to a captain’s greeting and close out the dialogue. While not very interesting, this has the bare minimum needed to be a fully functioning dialogue event. Next we’ll make things a bit more complex.
Step 3: Intermediate Dialogue
Let’s add 3 choices to our first dialogue screen.
The player is now presented 3 options in their first dialogue screen. The first choice loads up response 1 (which will be the second response section). The second choice uses the hardcoded <goto> command 991. This ends communications and sets the ship to hostile, entering the player into combat. The third option uses the hardcoded <goto> command 999 which exits out of the communication.
That option that leads to combat should be a little more clear. We can color it using <hex>.
That code within <hex></hex> is a hexidecimal color code, you can place any color code in here, you can find color codes here: [link]. Now when the dialogue options are displayed, the second option, which leads to combat, will be colored red to indicate that you will enter combat when selected.
Options 2 and 3 are all set, but option 1 needs to have a response to be directed toward. Having already made one response, we can make another from scratch. I’ll shorten the first response to save space.
The <goto>0</goto> will send the discussion back to the first dialogue tree. The other 2 gotos will go to Response 2 and Response 3 (numberically the 3rd and 4th in order, due to the first response being 0). You can now create those other responses, or change it so they simply end the conversation.
Next, we’ll learn how to use <req> to make some options appear only when certain conditions are met.
Step 4: Advanced Dialogue
By now, hopefully, you will be able to craft multipathed conversation trees. This lacks certain contextual elements though. No matter how far into the game you are, these conversations will always be the same. In game this is currently most often used to give hints connected to your current game progress. We can direct dialogue based on certain triggers by using <req>.
Let’s start with some familiar dialogue.
Let’s alter the text a little and add some more choices.
This will show 3 instances of “Give me relevant info!”, and each one will lead to a different response/dialog tree. We will now make it so that the option that appears is limited by in game events.
The first <req> we will use is the simplest. It is <req>994=#</req>. This is the biggest overall marker of in game progress. It is tied to how much of the star map is displayed.
“994=0” Trade Co. Available Only
“994=1” Yunqi, Zephyr, Rebirth, and previous.
“994=2” Most of the planets except the below planets.
“994=3” New Terra, Kibou, Cultus, and previous.
“994=4” Station Horizon, and previous.
“994=5” The Zoo, and previous.
So, using <req>994</req> we can vary responses based on overall game progress. Like so:
What happens now, is when a player starts this conversation, if their starmap level equals 0, 2, or 5, they will be given the visually identical option of “Give me relevant info!”, however the response (and thus the given info) they are directed to will change. An important note is that if your starmap level is 1, 3, or 4, then the player will not be given this dialog option. In many instances this is fine, if not you can create additional choices with the needed <req>994=#</req>.
The second simplest <req> is one that checks whether you have access to a planet or not. It is sgnified with <req>997=”planet”</req>. The ties into the star map, but is a little simpler to use. Instead of checking to see what starmap level a planet is tied to, you just check to see if the planet is available or not. We’ll use the base of the previous code to demonstrate its use. As you can imagine it is very similar in use.
In this example you can see that the player will be able to ask about planets if they have access to them in the starmap. You can find a list of all the available planets here. [link]
I’ve made every attempt to make sure that the planet names are identical to what is used in game. If a space is in the name, it must be used here. Like shown with New Terra above.
Step 5: Advanced Dialogue Continued
This is the last and most specific of the requirements, it checks to see if an individual level is unlocked. In addition to starmap level, the starmap.xml file has a <startingZones> setting. With this you can lock off levels on planets. You can learn more about this in the reference guide, in the annotated starmap.xml section. The short of it is that when you can first land on a planet, there can be levels that are shown and levels that are not shown. This <req> is used to check if a particular level on a particular planet has been unlocked. It does this with <req>996=”planet”*#</req>.
In this conversation, (based on the bounty hunter sidequest) the player is searching for a notorious pirate. The planet has 3 levels, but due to the setting in the starmap.xml only the first is unlocked. When you first talk to this character, it sees that level 1 is unlocked and will ONLY show that choice.
Later you discover/unlock the second map on Xiwang. This changes what <req> detects. So when you enter the conversation, it now sees 2 levels unlocked on Xiwang and shows the second choice only. Further on you unlock the third level and the third conversation choice is shown.
This code works with any planet name and any unlocked level number as detailed in the starmap.xml. Refer to that file for the extra information needed.
Conclusion
If you followed this tutorial you should hopefully understand the basics of conversation creation. This tutorial set focused specifically on the dialogues that you work with from the commdialogue.xml file. These are space only dialogs that occur between ship captains. The number of these is hard coded and they are also slightly more limited in their usage.
However, learning the construction of dialogue trees and the use of these settings can be used for working with planet side NPCs. The next tutorial series will focus on the alteration and creation of new planet side NPCs. There are some dialogue settings that are unique to planetside NPCs, and as such we did not go over them here. I will dedicate time to these new settings in the NPC tutorial.
Thanks for reading, if you have any questions or comments feel free to ask. I’ll be happy to help or to refine this tutorial as needed.
I’ll edit in a nice link to the next tutorial guide here once it has been created!