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:
- you write it yourself
- someone writes it for you
- you find it in the Roll20 forums or Discord (like I posted a script here)
- someone links to their GitHub repository (like the person did in the source link you provided), or...
- 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).