Restricted Vanilla Modules

[size=150]This mod is no longer needed as of GSB version 1.61.[/size]

This mod is intended to restrict the modules included with the game to the original four races. This is to allow new modded races to use their own weapon systems and not be forced to also include the core modules in their lists.

This is a modification to the core data files, so nothing is guaranteed. However, to my knowledge, nothing should blow up or insult your family, and this will not interfere with existing ship designs, challenges, and so on.


  • New races aren’t forced to use the base modules.
  • If it’s your thing, the base modules can be tweaked per race to give different performance envelopes.


  • GSB load time may be increased as it has many more files to read in.


  • All modules will be unlocked. Users were finding it annoying (and expensive) to have to unlock multiple copies of every module.

In the description below, $GSB refers to your GSB install directory.

Until it is confirmed to work, 1.55-rvm3 can be downloaded here:

  1. Download from
  2. Rename your core modules directory ($GSB/data/modules) to modules_backup.
  3. Extract the contents of into $GSB.
  4. Check that you now have:
  • a modules directory in $GSB/data, and,
  • a restricted_vanilla_modules.pkg file in $GSB/data/packages.

How to use with other mods

  • If you rely on the core modules not being available:
    [*] Don’t distribute these modules yourself, instead provide a link to this thread to download the modules. This will reduce the size of your mod, and will prevent impossible-to-solve conflicts if the generated modules are changed in the future. I will add versioning information to the package file soon, but it’s not in there yet.

  • Basically, treat this as another mod that yours relies on.
    ] If your new race needs access to the core modules:

  • I will soon add a script which will generate a set of modules restricted to your race. Include these in your mod’s modules directory.

Note that, to keep some semblence of order, I don’t officially support any modification of the core game files beyond what is done here. Except for the need for a package file to avoid the challenge system choking, the modifications made should be transparent to the game. If you do modify the core files, PLEASE include your own package file.


  • Adjusted internal name scheme to increase interoperability with unmodded installs.


  • Unlock all modules by default.
  • Handle tactical.txt correctly.
  • Add version number to package file.


  • Fixed various problems with initial script.


  • Confirm correct operation with challenges and GC.
  • Create script to easily generate restricted core modules for new races.

Works perfectly, great. Load time of GSB is not really affected :slight_smile:

I’ll knock up a package file later so that using this doesn’t crash other people’s GSB if they play one of your challenges or get one of your fleets in GC.

Just one comment : I think it would be good if the script also unlocked all the modules. Right now each race has to re-unlock each lockable module. Might be cumbersome for people who don’t know how to search and replace inside of text files (the Fleet HQ is so slooooooooooow)

I’ve had some other feedback related to that as well. Particularly that you have four identical copies of each to unlock, so even if you want to unlock a particular one, you have to find it first. Would everyone be happy with an auto-unlock for them all?

Also, I’ve attached the package file to the first post. If you want to create it yourself, it’s simply:

name = restricted_vanilla_modules
uiname = “Restricted Vanilla Modules”

Please please please, if you’ve modified the core modules in any way other than running this script, don’t just add this package file. Create another package file for your modifications. If possible, we need to avoid destroying the challenge system :wink:

I’ve added some instructions on using this (in the first post).

What I may end up doing is releasing this as an actual separate mod in its own directory. It would make mistakes during installation less likely as people just need to rename their modules directory (to modules_backup for example) and add this mod like they would any other.

Have provided a link to the new modules and attached a revised package file to the first post. It turns out my script doesn’t do the right thing with the tactical module, so I’ve corrected that by hand. I think Cliff modified it in one of the patches since I first wrote the script (or I’m going crazy).

Updated the instructions and modified the zip file so that it contains everything needed.

Version 1.55-rvm2 released thanks to knightofni.

This is so great, it looks like it’s working perfectly! Thank you so much, Kemp :slight_smile:

No problem, I’m glad you found it useful :slight_smile:

Problem : Once RVM is installed, challenges created using a non modded race are not playable by other players (unless they have RVM) due to the different internal name

Analysis : As RVM does NOT change any module characteristic, different internal names are not needed - actually RVM is purely an interface modification, simply preventing the core modules to appear in unintended races.

Solution : Keep RVM’s file structure ‘as is’, but revert the internal ‘name’ to the original. This ensures complete online compatibility, without nefarious consequences.

What do you think ?

Ah, that is quite unfortunate. The RVM package includes a group of modules which retain the original internal names to avoid this problem when playing challenges created by players without RVM, but I don’t have a solution for the other way round. The problem here is that each race would need their modules to use the original internal name, and multiple modules with the same internal name is a big no-no. If Cliff adds in the multi-race restriction capability then this is an easy fix, otherwise I’m not sure I can work around it.

Kemp, are you sure it wouldn’t work ? At the beginning of Balance Mod, i didn’t understand the importance of internal names, so i did at some moment have mulitple modules with different internal names. It doesn’t crash or anything, and from memory, it follows the following behaviour :

  • the modules in \data will have priority over modules in *your mod* folders
  • in the same folder, it seems that the game will use alphabetical priority

So as long as the modules that have several files for the same internal name are functionnally indentical, there should be no impact on the actual game. And all the modules that would need this ‘treatment’ are - by definition - functionnally identical.

I hope - but am unsure - that i’m clear.

Note : I realise that it’s a dirty hack. But if it is of no consequence on game & gameplay, then it’d be a useful dirty hack.

I will have a look at that tonight and see what happens.

O_o i always thought the internal names are specific for every module, so u cant have multiple modules with the same internal name. When that happens, it always crashed to me. So u can have a pulse phaser named “cruiser pulse phaser” and then another module pulse phaser mk2 named the same way “cruiser pulse phaser” ??? i dont think so… lol. I cant see a way to change that (only Cliff can…).

My first instinct would be to say you definitely can’t (knowing approximately how Cliff is using he internal name). If he’s using a joint key type approach it might be possible, but that’s a long shot.

Ok this is my two cents on the matter.

I have ran into this sooo many time when i make my modules I copy past into a new file. this is what i have found…

The game DOES NOT crash . . . . . .
The game loads the module of the same name from the Data folder of the main folder.
The game will remove the module that you placed and replace it with the first module that it finds of the name.

So in conclusion, it MIGHT be possible to have many modules with the same name and restricted to certain races. But I have never attempted to try it in this manner.

That was the thing I mainly expected to happen Lonestar. Somewhere in GSB there is a dictionary (hashmap) of internal names to module information, or some equivalent. If another module of the same name is read in then it simply overwrites the old one (or the code checks if it already exists and skips adding it altogether).

Having re-read knightofni’s post, it seems that this is what he already said. I interpreted it completely differently before.