3 | Mod Architecture - MassiveMiniteam/OddModKit GitHub Wiki

Folder structure

For the Content:

  • Content
    • LOC
      • This is the whole game
    • Mods
      • TestModA
      • TestModB

UHT Headers

We use a tool to generate the C++ headers of our code. We don't ship the gameplay code but basically everything around it for you to know how types and functions look like. You can call them but they will only work within the runtime. The tool exposes a bit more properties so it might show cached properties that you dont really want to set in design time.

Log Files

Log files are under %localappdata%/Loc/Saved/Logs/Loc.log.

General

We heavily use components in Oddsparks. If you want to extend the functionality of something its generally the best when you create a new component for it and attach it where you want the functionality.

When you want to find out how something is implemented or if you want to extend it you need to use Dummy Assets. With dummy assets you can lookup what components we use for actors and reference anything that we implemented yourself. For example adding a new workstation, you can inherit from the Dummy Asset BP_S_Workstation_Base just like our Sawbench. It will create and add all the component dummy assets too.

ModBase

ModBase is the entry point of every mod. It needs to be implemented in a blueprint called "ModBase". You can implement OnModEnabled and OnModDisabled to react to the mod beeing loaded and unloaded. Like changing CDOs or something else. OnModEnabled will be called as soon as the mod is loaded so already in the main menu and not on savegame load.

ModSimulationActorClasses is a list you can set for ModSimulationActors that should be spawned. When you load a savegame that was saved without your mod, it will spawn those actors (or on a new game respectively). This is where you should put your mods savegame data for gameplay.

ModSettingsClass class you can override to implement custom settings for your mod. The ModSettingsWidgetClass will will appear in the Settings/Mods screen to change those settings. This is for savegame data across savegames.

You can call the RegisterObjectForOverride function to serialize objects before modifying them. They will automatically be restored when your mod is disabled. Similarly you can use Override Object Paths to override existing assets in the game with your own. This is useful if you want to change StatContainers for rebalancing or generally change DataAssets. This feature is a bit experimental and might not correctly work for more complex assets.

ModSettings

OnSettingsCreated is called when the settings were newly created. Use this for more complex default logic. OnSettingsLoaded is called when the settings loaded on game start, you can use versioning to migrate data. OnSettingsWantToSave is called before saving (usually when the user exists the settings screen). Important all variables need to be marked as "SaveGame" image

ModSettingsWidget

todo

ModSimulationActor

Behaves like other SimulationActors (see Oddsparks Architecture) and will be spawned on savegame load if they dont exist.

ActorHooks

You can inherit from USimulationActorHook and map it to a target class in your ModBase. This hook will be called for each spawned and destroyed actor. It will not get instantiated. This is the easiest way to add a component or modify an existing one. You need to use the Dummy Asset Importer to reference existing classes.

When you want to add a component that supports savegames, you need to rename the component after adding to ensure the same name. It also needs to happen in OnSimulationActorPreDeserialize to be called before the serialization code runs.

image

WidgetHooks

WidgetHooks are similar to ActorHooks but for widgets.