Starfield TS Modloader

Starfield TS (Typescript) Modloader is a framework used to develop plugins (mods) into Starfield. It provides a ready-to-go API classes and objects that can be imported into a Node project, to start developing.

Features

• Full Typescript support and Full Node support, in one of the most extensive languages in the web. You can mod Starfield supporting all already existing TS node packages
• Full HTML UIs. Design and implement UIs with the most extensive, and with most support UI technologies. You have examples of React UIs on some mods below
• Full access to a variety of commands from the console. More to be added as time passes
• Develop mods on hot reload. No need to exit the game. Making changes and restarting the service is enough.
• Full Unit testing for your mods (Something almost non-existant nowadays)

What does this mean from the user side?

More frameworks and more languages supporting the game means more mods for it! Current means to mod Bethesda games are great, with a lot of flexibility, but the languages that supports them can be challenging for some developers who difficulty is too step, or simply don't have time to afford learning how to do it. This should shorten that gap, and makes it more accessible.

How to know if it is working?

You should see an extra CMD windows as soon as you start Starfield. Logs should starting to appear on that. If you see something like yarn command not found, then you probably are missing Node installation (And restart the computer) The first time you run it, it takes a while (Needs to install node dependencies). Once you see StarfieldTSModloader logs, the service is running!

Cons

This framework has a list of downsides against developing regular Bethesda mods

• Only support for console commands. While I have plans to add support to more SFSE commands as such tool grows, it heavily depends on the flexibility of that. As of now, only console commands are supported in the API. That does not limits the creativity of such mods though. Below there are some examples of that.
• Extra system requirements. Node needs to be installed on the system. Makes sense, since it is TS Modloader, but from the user side, can be bothersome.
• Run of an extra service. Same way as you do with SFSE. Transparent to the user

Future plans

There are a list of things planned to mitigate previous downsides:

• Increase the support on SFSE commands, or even native creation kit features
• Automate the installation of system requisites, so is transparent for the end user

Requirements

Starfield mods requirements

Console API and Web Application Without the creation of this mod, none of this would be possible. This mod creates an endpoint to run basic commands on an API. If this mod grows functionality, so we do

System requirements

• Node
  • x86
  • x64

Example mods

This is a list of example mods being made for Starfield TS Mod loader:

• starfield-ts-radio. A in-game implementation of the already known https://starfieldradio.com/. Is a great way to know how a mod is being made with Modloader framework. It has basic logic, but contains React UI, keys binding in the game, HTTP endpoints implementation...
• starfield-ts-fuel. Implements real fuel into the game, and the possibility of depleting it, being stranded in space. Calculates how much the engines, the jump, or even the reactor consumes, and deduces it in the actual SpaceshipGravJumpFuel actor value from ships.
• starfield-ts-oxygen. Adds a feature to existing backpacks, to add oxygen to it, and be able to depleting it. Once a backpack has been depleted, the backpack is destroyed. Makes expeditions to non breathable planets more resource-planning.

Why name it plugin instead of mod?

Is just naming it something, to be honest. You can name it mod/plugin or whatever:

• In the Modloader context, these are things that extends the functionality of this program, hence, plugins.
• In the Starfield context, these are things that modifies the game current functionality, hence, mods.

Since in the program context, they're in fact, plugins, all the references are set as Plugins, but they're mods nonetheless.

Incompatibilities

• Console output to file. This mod writes the output of console into a file. This makes Console API and Web Application mod, a dependency, unusable.

Contributions

Contributions are accepted, but only small changes, few lines, or hotfixes. I don't have a lot of time to review 500 lines PRs. If you have a big change that changes the main functionality of the service in any way, you're free to fork the project. I also want to maintain a high quality standard in the codebase, so expect nitpicky comments! Other than that, thank you for contributing!