Roll20 uses cookies to improve your experience on our site. Cookies enable you to enjoy certain features, social sharing functionality, and tailor message and display ads to your interests on our site and others. They also help us understand how our site is being used. By continuing to use our site, you consent to our use of cookies. Update your cookie preferences .
×
Create a free account

Implementing Fallout Terminals Into Roll20

Rookie here. I followed some examples that people made way back 8 years ago. Thing is, I don't even know how to test my code (which this is my first time doing by the way). None of the forums I've seen explain HOW you activate the .JSON so that it shows up in chat. If anyone has had success with this, please let me know and help me out. Maybe I did something wrong or I'm lacking something, but I'm sure exactly what the issue is. 


Here is my code:

{
	"name": "Vault-Tec Security Terminal",
	"locked": false,
	"content": "Welcome to ROBCO Industries (TM) Termlink\nClearance: Vault-Tec Security Personnel",
	"screens": [
		{
			"name": "Vault-Tec Security Door Logs", 
			"screens": [
				{
					"name": "02/21/2075 [File Corrupted]"
				},
				{
					"name": "03/04/2075 [File Corrupted]"
				},
				{
					"name": "09/15/2076 [File Corrupted]"
				},
				{
					"name": "04/27/2077 [File Corrupted]"
				},
				{
					"name": "08/02/2077 [File Corrupted]"
				},
				{
					"name": "10/23/2077 [File Corrupted]"
				},
				{
					"name": "05/17/2085",
					"content": "Pip-boy 2000 ID 137565502 connected"
				},
				{
					"name": "07/29/2267",
					"content": "Pip-boy 2000 ID 137565502 connected"
				}
			]
		},
		{
			"name": "Security Overview", 
			"screens": [
				{
					"name": "Spotlight Controls",
					"content": "OFFLINE"
				},
				{
					"name": "Turret Controls",
					"Content": "OFFLINE"
				}
			]
		},
		{
			"name": "Elevator Controls",
			"screens": [
				{
					"name": Service Mode",
					"content": "Deactivate Service Mode to call elevator.",
					"screens": [
						{
							"name": "Activate",
							"content": "Service Mode activated"
						},
						{
							"name": "Deactivate",
							"content": "Service Mode deactivated."
						}
					]
				},
				{
					"name": "Call Elevator",
					"content": "Calling, please stand by..."
				}
			]
		}
	]
}
May 12 (2 months ago)
Nic B.
Roll20 Team

Hey,

This doesn't appear to be a complete script, in fact it looks like only the data aspect and the implementation is completely missing. It would probably help if you were able to provide links to the forum threads you found so that we can better advise.

Thanks!

This is the post I looked at and attempted to follow. 


May 22 (2 months ago)
timmaugh
Forum Champion
API Scripter

Did you install the FalloutTerminal script? That linked thread points to a git repository that doesn't exist, but it does say that the pull request was pending (the pull request is what tells Roll20 that the script is ready to be added into the Roll20 repository, to be available for users), and there is a FalloutTerminal script in the 1-click.

Your JSON is only the data that that script would display, so you need the script to do the presentation. Install that script in your game, then follow the setup instructions. If you have trouble with any of these steps, post back and we can help.

May 23 (2 months ago)

Edited May 23 (2 months ago)

Hey there, thanks for the response. I did not install the FalloutTerminal Script. I was unaware that such a thing existed. Where exactly can I get this FalloutTerminal Script, and how would I install it onto my game? Additionally, is there any other things I might need in regards to programs, apps, accounts, links or hardware/software? Also, pardon my confusion and lack of knowledge, but I don't exactly know what you mean by 1-click. 

May 23 (2 months ago)
timmaugh
Forum Champion
API Scripter

No worries. Let me see if I can both explain and maintain some brevity:

What Are Mod Scripts

Scripts are things you add on to your game to provide extended functionality. They are bits of code written in JavaScript built around particular facets of the Roll20 experience (like adding a token to the board, or adjusting an attribute on a character, etc.)

Where Can You Get Them

You can get scripts from a number of locations:

  1. you write it yourself
  2. someone writes it for you
  3. you find it in the Roll20 forums or Discord (like I posted a script here)
  4. someone links to their GitHub repository (like the person did in the source link you provided), or...
  5. the 1-click (don't worry, you'll see what/where the 1-click is and how to use it in a minute...)

Small Editorial: Some people try carve out another source by having something like ChatGPT write them a script. Don't be those people. Not only is it bad for the environment, morally dubious, and cognitively stunting, most pragmatically it isn't suited to the Roll20 scriptosphere, which uses a subset of JS and a localized vernacular of commands. Most often, you're going to end up with something that is going to need troubleshooting, anyway. There's a whole community (and a bank of already-written scripts) to draw on, people willing to help. /Editorial

How to Install Them

All of your sources for a script's source can be divided into 2 categories: direct install vs. copy/paste

Put another way: there is the 1-click, and then there's everything else. Let's deal with everything else, first. You've copied the code to your clipboard, and you need to get it in your game. Go to the launch page for your game, and click the Settings dropdown. Choose Mod (API) Scripts.


That will take you to your "Script Deck," which will show you all of the installed scripts in your game. To install a script via copy/paste, click as depicted in this image:

1) Click "New Script"

2) Give your script a name (it does NOT have to end with ".js", it just needs to be a name you recognize)

3) Paste the code here

Then hit the Save Script button, below the code panel:

Notice the Mod Output Console just below the Save Script button. Sometimes scripts will output a message to you, here, if they are designed to give feedback or you need to do some troubleshooting. Also, if you ever need to reboot your sandbox, you'll see that progress in this window. Saving a will automatically force a sandbox reboot, but only if you or a player are in your game. That is, if a player or GM is in the game, then there would be a running sandbox which would need to be rebooted when you save a script; on the other hand, no player or GM in the game means no sandbox, so you would NOT see an immediate reboot of your sandbox (you WOULD see one the next time you or your players entered the game).

Note, too, that being on this Script Deck page does not count as being in the game (nor does being on the game's launch page count). You are only in the game when the game environment is running in a tab. For that reason (and because sometimes, during a game you may need to reboot the sandbox -- i.e., after an error and/or after a soft crash where it simply stops working but doesn't give you the report of an error), most GMs will keep the Script Deck open in another tab/window so they can monitor the state of their sandbox. You will notice an error from the large pink box that will appear just above the Output Console, explaining where the error occurred. The information, there, can be helpful in diagnosing what went wrong... but after such an error you will ultimately need to reboot your sandbox before you will be able to use it again. To reboot it, you can click the Save Script button for any script or you can navigate to the Mod Library tab of the Script Deck and choose the Restart API Sandbox button.

1-Click

This is the other way to get scripts in your game other than copy/paste. Roll20 maintains a repository of community-written scripts that are available in any game where the owner of the game is a Pro subscriber. To find them, navigate to your Script Deck page, and click on the Mod Library tab if you're not already there (#1)...


...then locate the 1-click drop down (#2).

Click on this dropdown and you will see the list of all scripts in the Roll20 1-click repository. They are grouped roughly by their utility in your game (e.g., do they deal with Chat? Characters? Maps? etc.), then sorted alphabetically... however once you've clicked on the dropdown, you can start typing the name of the script you're looking for:


(If you don't see a script listed in the dropdown that you KNOW is in the 1-click, it's typically because you already have a script in your game going by the same name, so Roll20 is filtering the list to only show you scripts you DO NOT have.)

Click on the script and you will be presented with a "readme" page for the script. Some scripts are more elaborate than others in what they put on the readme (Fallout Terminal has a fair amount of information about usage and terminal JSON composition). Other than instructions for using the script (that maybe you couldn't find elsewhere), you will want to take notice of two buttons at the bottom of the readme:


BOTH BUTTONS WILL GET THE SCRIPT INTO YOUR GAME, BUT THEY ARE DIFFERENT AND THE DIFFERENCES ARE IMPORTANT.

Add Script will "install" the latest version of the script in your game, as well as any supporting scripts designated by the script's author. For instance, some of my scripts use a script named "Messenger" I wrote as a library for handling how I format chat messages (so I don't have to replicate this code structure in every script I release). We call these supporting scripts "dependencies"... and a script's author has the capability to designate (when they upload their script into the Roll20 repo) that the script is dependent on scripts X, Y, and Z to function properly. One of the chief benefits of using the Add Script button is that it will make sure all of these required dependencies get installed into your game, as well.

The other chief benefit of using the Add Script button (or, "installing" a script) is that the script will update should (let's say) the author locate a bug and releases a fix for it... or if the author adds functionality with a new phase of development on the script. Both of these situations would require a new version of the script be uploaded to the Roll20 repo. If you have installed a script, your game will get this new version of the script automatically.

99.9% of the time, if you are getting a script from the 1-click, you will want to use the Add Script method.

Let's compare that to the Import option...

Import will also get the latest version of the script into your game, but that script will NOT stay in sync and update if there is a future release (think of it like a snapshot of the current version of the script). Also, it will NOT install a script's dependencies in your game (you'd have to manually install or import them). Also, you will no longer see the script's readme page (which might have valuable instructions). So why would you ever choose to import a script rather than installing it?

The chief benefit of clicking the Import button is for troubleshooting. When you install a script, you can't see (and don't have access to) the code for the script. You will continue to ONLY see the readme information for it. By contrast, when you import a script, you will see the code behind that version of the script. This can be helpful if you are comfortable with JavaScript and want to dig into an error you're getting, or if you want to change the script in some way (adding a feature or removing a limitation).

Even if you're not familiar with JavaScript, however, this route can sometimes be helpful. For instance, if someone brings a breaking error to the attention of a script's author, the author may say something like, "Solving that problem the right way will take a little time to get right; in the meantime, to get around that error, you can modify the script by changing line #xyz. Where it says 'taco' change it to read 'hoocha'. I'll release a fix as soon as I can..." In this case, you would need access to the source code in order to apply that suggested patch while the author continues to work on a more permanent solution, so you would want to import the script rather than installing it.

This gets to the primary usage of the Import button, then. Most times when you want a script from the 1-click, you will choose Add Script. Even if you want to troubleshoot or modify the source code, you'd start with the Add Script option, just to make sure you also got any dependencies identified by the script's author. Then, once all the scripts are installed, you can remove the script you want to modify/troubleshoot and then choose to import it, instead.

In our scenario just above, where the author is letting you know how to get around a bug while they work on a more permanent fix, this is exactly how you would go about getting access to the source code to make the change they suggested. Then, when the author releases a new version of the script that properly addresses the bug, you can return to using the installed version of the script so that you get future updates, again.

Video Explaining How Scripts Work

If you have never used scripts before, I'd suggest watching the first 15 minutes of this video. It explains the timing of certain events, what happens to messages, etc. Once you're comfortable with scripts in general, you can return to watch the remainder of that video, which gets into the difference between scripts and metascripts -- something beyond what you need to do, now, but which might be helpful later (or to others finding this thread in the future).


timmaugh said:

No worries. Let me see if I can both explain and maintain some brevity:

What Are Mod Scripts

Scripts are things you add on to your game to provide extended functionality. They are bits of code written in JavaScript built around particular facets of the Roll20 experience (like adding a token to the board, or adjusting an attribute on a character, etc.)

Where Can You Get Them

You can get scripts from a number of locations:

  1. you write it yourself
  2. someone writes it for you
  3. you find it in the Roll20 forums or Discord (like I posted a script here)
  4. someone links to their GitHub repository (like the person did in the source link you provided), or...
  5. the 1-click (don't worry, you'll see what/where the 1-click is and how to use it in a minute...)

Small Editorial: Some people try carve out another source by having something like ChatGPT write them a script. Don't be those people. Not only is it bad for the environment, morally dubious, and cognitively stunting, most pragmatically it isn't suited to the Roll20 scriptosphere, which uses a subset of JS and a localized vernacular of commands. Most often, you're going to end up with something that is going to need troubleshooting, anyway. There's a whole community (and a bank of already-written scripts) to draw on, people willing to help. /Editorial

How to Install Them

All of your sources for a script's source can be divided into 2 categories: direct install vs. copy/paste

Put another way: there is the 1-click, and then there's everything else. Let's deal with everything else, first. You've copied the code to your clipboard, and you need to get it in your game. Go to the launch page for your game, and click the Settings dropdown. Choose Mod (API) Scripts.


That will take you to your "Script Deck," which will show you all of the installed scripts in your game. To install a script via copy/paste, click as depicted in this image:

1) Click "New Script"

2) Give your script a name (it does NOT have to end with ".js", it just needs to be a name you recognize)

3) Paste the code here

Then hit the Save Script button, below the code panel:

Notice the Mod Output Console just below the Save Script button. Sometimes scripts will output a message to you, here, if they are designed to give feedback or you need to do some troubleshooting. Also, if you ever need to reboot your sandbox, you'll see that progress in this window. Saving a will automatically force a sandbox reboot, but only if you or a player are in your game. That is, if a player or GM is in the game, then there would be a running sandbox which would need to be rebooted when you save a script; on the other hand, no player or GM in the game means no sandbox, so you would NOT see an immediate reboot of your sandbox (you WOULD see one the next time you or your players entered the game).

Note, too, that being on this Script Deck page does not count as being in the game (nor does being on the game's launch page count). You are only in the game when the game environment is running in a tab. For that reason (and because sometimes, during a game you may need to reboot the sandbox -- i.e., after an error and/or after a soft crash where it simply stops working but doesn't give you the report of an error), most GMs will keep the Script Deck open in another tab/window so they can monitor the state of their sandbox. You will notice an error from the large pink box that will appear just above the Output Console, explaining where the error occurred. The information, there, can be helpful in diagnosing what went wrong... but after such an error you will ultimately need to reboot your sandbox before you will be able to use it again. To reboot it, you can click the Save Script button for any script or you can navigate to the Mod Library tab of the Script Deck and choose the Restart API Sandbox button.

1-Click

This is the other way to get scripts in your game other than copy/paste. Roll20 maintains a repository of community-written scripts that are available in any game where the owner of the game is a Pro subscriber. To find them, navigate to your Script Deck page, and click on the Mod Library tab if you're not already there (#1)...


...then locate the 1-click drop down (#2).

Click on this dropdown and you will see the list of all scripts in the Roll20 1-click repository. They are grouped roughly by their utility in your game (e.g., do they deal with Chat? Characters? Maps? etc.), then sorted alphabetically... however once you've clicked on the dropdown, you can start typing the name of the script you're looking for:


(If you don't see a script listed in the dropdown that you KNOW is in the 1-click, it's typically because you already have a script in your game going by the same name, so Roll20 is filtering the list to only show you scripts you DO NOT have.)

Click on the script and you will be presented with a "readme" page for the script. Some scripts are more elaborate than others in what they put on the readme (Fallout Terminal has a fair amount of information about usage and terminal JSON composition). Other than instructions for using the script (that maybe you couldn't find elsewhere), you will want to take notice of two buttons at the bottom of the readme:


BOTH BUTTONS WILL GET THE SCRIPT INTO YOUR GAME, BUT THEY ARE DIFFERENT AND THE DIFFERENCES ARE IMPORTANT.

Add Script will "install" the latest version of the script in your game, as well as any supporting scripts designated by the script's author. For instance, some of my scripts use a script named "Messenger" I wrote as a library for handling how I format chat messages (so I don't have to replicate this code structure in every script I release). We call these supporting scripts "dependencies"... and a script's author has the capability to designate (when they upload their script into the Roll20 repo) that the script is dependent on scripts X, Y, and Z to function properly. One of the chief benefits of using the Add Script button is that it will make sure all of these required dependencies get installed into your game, as well.

The other chief benefit of using the Add Script button (or, "installing" a script) is that the script will update should (let's say) the author locate a bug and releases a fix for it... or if the author adds functionality with a new phase of development on the script. Both of these situations would require a new version of the script be uploaded to the Roll20 repo. If you have installed a script, your game will get this new version of the script automatically.

99.9% of the time, if you are getting a script from the 1-click, you will want to use the Add Script method.

Let's compare that to the Import option...

Import will also get the latest version of the script into your game, but that script will NOT stay in sync and update if there is a future release (think of it like a snapshot of the current version of the script). Also, it will NOT install a script's dependencies in your game (you'd have to manually install or import them). Also, you will no longer see the script's readme page (which might have valuable instructions). So why would you ever choose to import a script rather than installing it?

The chief benefit of clicking the Import button is for troubleshooting. When you install a script, you can't see (and don't have access to) the code for the script. You will continue to ONLY see the readme information for it. By contrast, when you import a script, you will see the code behind that version of the script. This can be helpful if you are comfortable with JavaScript and want to dig into an error you're getting, or if you want to change the script in some way (adding a feature or removing a limitation).

Even if you're not familiar with JavaScript, however, this route can sometimes be helpful. For instance, if someone brings a breaking error to the attention of a script's author, the author may say something like, "Solving that problem the right way will take a little time to get right; in the meantime, to get around that error, you can modify the script by changing line #xyz. Where it says 'taco' change it to read 'hoocha'. I'll release a fix as soon as I can..." In this case, you would need access to the source code in order to apply that suggested patch while the author continues to work on a more permanent solution, so you would want to import the script rather than installing it.

This gets to the primary usage of the Import button, then. Most times when you want a script from the 1-click, you will choose Add Script. Even if you want to troubleshoot or modify the source code, you'd start with the Add Script option, just to make sure you also got any dependencies identified by the script's author. Then, once all the scripts are installed, you can remove the script you want to modify/troubleshoot and then choose to import it, instead.

In our scenario just above, where the author is letting you know how to get around a bug while they work on a more permanent fix, this is exactly how you would go about getting access to the source code to make the change they suggested. Then, when the author releases a new version of the script that properly addresses the bug, you can return to using the installed version of the script so that you get future updates, again.

Video Explaining How Scripts Work

If you have never used scripts before, I'd suggest watching the first 15 minutes of this video. It explains the timing of certain events, what happens to messages, etc. Once you're comfortable with scripts in general, you can return to watch the remainder of that video, which gets into the difference between scripts and metascripts -- something beyond what you need to do, now, but which might be helpful later (or to others finding this thread in the future).


Thank you! This has been SO helpful. I greatly appreciate you taking me through it. 

I was able to get the script, but getting it to actually WORK still has me at a roadblock. I used the 1-click and then clicked Add Script. Then, I booted up the game, followed the demo instructions from that older post I linked earlier, and tried it out. I had the script tab open on a separate tab in my browser window. But when I clicked "displayterminal" like the demo insisted, I got an error code back. I'll be contacting the creator likely within the next 24 hours, but I worry that, even if they do have a solution, I won't be able to execute said solution. I watched the video you suggested, and it helped me understand, but maybe the creator can guide me through fixing the issue. As far as I'm aware, I've done everything correct, so it must be an issue in the Fallout Terminal script, unless there's something I've either missed or overlooked. 

May 26 (2 months ago)
timmaugh
Forum Champion
API Scripter

Can you post the error? (Screenshot that pink box or copy/paste the text in it.) We might be able to tell what happened...


timmaugh said:

Can you post the error? (Screenshot that pink box or copy/paste the text in it.) We might be able to tell what happened...


Certainly. I'll attempt to paste the screenshot here. Additionally, I'll provide a Copy/Paste the best I can of the Mod Script Console. 

1    
2    "##########> Sandbox [DEFAULT 2025-04-18] : Ready fired after 2.63s, 118 objects."
3    Restarting sandbox by user request...
4    detected currently running sandbox... restarting
5    "Loading character sheet data..."
6    "Starting webworker script..."
7    "Loading 457 translation strings to worker..."
8    "=== Initialized Fallout Terminal v1.1 ==="
9    "##########> Sandbox [DEFAULT 2025-04-18] : Ready fired after 1.60s, 118 objects."
10   "FALLOT TERMINAL ERROR: Unexpected token S in JSON at position 992"
May 28 (2 months ago)

Edited May 28 (2 months ago)
timmaugh
Forum Champion
API Scripter

OK, that's not an error with the Fallout Terminals script... that's an error in your JSON.

You can use a tool like JSONLint to validate your JSON is properly formatted... and when I use that, it demonstrates that line 54 has a problem. Looking at that line:

"name": Service Mode",

you can see it is missing a quotation mark. Change it to:

"name": "Service Mode",

...and it passes validation. Give that a try and see if it works for you.


timmaugh said:

OK, that's not an error with the Fallout Terminals script... that's an error in your JSON.

You can use a tool like JSONLint to validate your JSON is properly formatted... and when I use that, it demonstrates that line 54 has a problem. Looking at that line:

"name": Service Mode",

you can see it is missing a quotation mark. Change it to:

"name": "Service Mode",

...and it passes validation. Give that a try and see if it works for you.


It worked! Thank you so much for helping me understand how to use the JSON script for the terminals. I feel a bit bad that I couldn't get to work because of a lousy typo. All that work you had to go through just for that. Again, thank you so so much.