KSP_win\GameData\ShadowSplat\Parts\Engine\DoesItAll.mu KSP_win\GameData\ShadowSplat\Parts\Engine\DoesItAll.cfg KSP_win\GameData\ShadowSplat\Parts\Engine\DoesItAll Many of the stock parts contain commenting-out lines to help you decode where things should go, but, here's a general breakdown, using a mythological part (let's call it "DoesItAll"). However, for compatability and error-checking reasons, it's best to follow the general structure that exists within stock parts. As far as I can tell, you can throw just about anything you want in there in any order. KSP_win\GameData\ShadowSplat\Parts\ElectricalĪs of at least 0.24.2, the order of the configuration file matters very little. KSP_win\GameData\ShadowSplat\Parts\Science KSP_win\GameData\ShadowSplat\Parts\FuelTank KSP_win\GameData\ShadowSplat\Parts\Engine My folder structure might look like this:
#Kerbal space program 1.4.5 mods mod#
So, I wrote a mod (let's call it ShadowSplat) that modifies some resources, adds a few agencies, and massively updates the parts pack including new engines, fuel tanks, science containers, and electrics. It would be wise to name this folder the same as you are marketing your mod (ie: GameData\Modular Kolonization System\ is advertised as Modular Kolonization System or GameData\MechJeb is advertised as MechJeb) (and yes, I know that I'm using examples which actively violate this principle!) No matter how deep you nest your mods' folders, your mod itself should be contained within the /GameData folder with a name that uniquely identifies your mod. If you are making a mod that does things other than just provide a stock-capable parts pack, you may want a more subfolders, one for parts, one for agencies, another for contracts, etc, etc. For example: /Engines/ to place all of your engine designs inside. This is certainly an acceptable practice, and one that Squad uses themselves. If you making more than a few parts, you may want to create a folder for each type of part. Even though Squad themselves are horribly inconsistent when building parts, it is best to have the name of the folder, and the names of each of the meshes match the name of the part inside the cfg file (not the name that you see in the parts building! More on that later). When creating a new part, each of these files (including additional models and meshes, if needed) should all be contained in a single folder which describes or names the part. I am not a modeler, so I will leave that guidance to someone more qualified.
#Kerbal space program 1.4.5 mods software#
Under the 0.25 standards, the model and collision mesh must both have a material assigned when creating them in your modeling software and prior to export for use. It is well documented in the forum thread and on sarbian's Gitub.Įvery part consists of multiple files, including the configuration file, a model and a collision mesh. If you see an signs, 's, or it looks like programming, the config is using Module Manager. The mod Module Manager adds powerful filtering and extension capabilities to the Config Node format. The stock config is very simple - nodes and values, which are nothing more than tree nodes and strings. See the C# class documentation in the KSP API Documentation for more details. Config nodes can contain values (serialized versions of all sorts of data types) or other config nodes. The config format used in Kerbal Space Program is NOT a Unity class, but specific to KSP.
0 kommentar(er)
