-
Notifications
You must be signed in to change notification settings - Fork 5
Creating mods
Creating mods using the framework is fairly easy and straightforward. To start off, extend the "ModBase" class and implement the abstract properties. Any class extending ModBase and placed in the Planetbase\Mods folder will be autoloaded on launch.
There are two ways to have code called. Override the Init method, or the Update method. The init method is ran one time, extremely early in it game's life. The update method is called repeatedly throughout the game. It is independent of the game state, meaning that code placed in the Update loop will be ran even when the actual "game" isn't playing (i.e. in menus) Be aware that blocking code here will block the entire game, potentially freezing it.
Any files in [Modname]\assets\png, [Modname]\assets\obj, [Modname]\assets\strings will be loaded into the ModTextures, ModObjects, and the global string dictionary. They can be accessed with [list].find(x => x.name.Equals("<filename.extention>")). Strings files use the same format as the native game. See the workshop for an example, or https://github.com/solidDoWant/Planetbase-Framework/blob/master/assets/strings/framework_en.xml. Click here for an example.
BasePath, ModPath, and ModName provide information on the path of the Planetbase folder, Planetbase\Mod folder, and the name of the mod.
To add a new button to the title menu, extend the TitleButton class. Override the HandleAction method to handle button clicks. Instantiating an instance of the TitleMenu class will auto-register it to be displayed. The name of the button is automatically translated. Click here for an example.
To add a new gamestate (such as a new screen, similar to Mod List), extend the GameState class. To activate the state, call GameManager.getInstance().setNewState(new ()). onGui can be overridden to draw on the screen. Click here for an example
The debug log, located in the Planetbase folder, contains extensive information on issues that arise while the game is running.
All found mods are loaded into Modloader.ModList at the launch of the game. A list of mods matching a given type can be found with Modloader.GetModByType(Type).
Putting a ModLoaderIgnoreAttribute attribute on a class extending ModBase will cause it not to be loaded, even if it is public and not abstract. This is useful if your mod dynamically generates other mods at runtime (like the XML Modloader mod)
OBJ and MTL files can be dynamically loaded into gameobjects at runtime. To load an obj (that isn't already in ModBase.ModObjects), call ObjLoader.LoadOBJFile(filename, texturelist). This will autoload the OBJ, generate a mesh, and load any related materials.
To create a new building, extend the BaseModuleType class (or the ModuleType class, not typically recommended). Provide a texture for the menu icon, and a list of gameobject in an array from small to large. OVerride the calculateCost method to set the required resources (metal, starch, etc.). To add the new building into the game, call TypeList<ModuleType, ModuleTypeList>.getInstance().add(new ()).
The utils class is a static class for miscellaneous functions that (I think) will be useful to modders. It contains features ranging from exceptioni logging to texture loading. See the class for more details. Two methods of note are the GetObjectPropertyValues and the LogException methods, as they are extremely useful for debugging.
New technologies are fairly easy to implement. Simply extend the Planetbase.Technology class, and then register it with TypeList<Tech, TechList>.getInstance().add(newTech). New technologies must be registered any moduletypes tied to them are registered.
To request new features, please create a new issue on GitHub (this project).