Help:Modding

For more in-depth modding information see the community modding wiki

Modding guidelines and information overview can be put here. Maybe subpages for specific topics like parts, planets, BRUTAL, etc.

Part modding guidelines

Daishi posted the following "semi-official" part modding guidelines for Kitten Space Agency:

KSA is being built to be as user friendly for content creators and modders as possible - a great game outlives its studio and is supported by the community for years (pls support us tho) and we want KSA to thrive as much as KSP did.

To make part mods, all you need is Blender, an image editor, and a little bit of knowledge of xml (how parts are defined). How we define parts and their relationships with each other isn't set in stone yet - so what I would do is just start modelling and getting things ready.

Some guidelines for modelling...

• Cylindrical parts are 48 sides around their circumference, vs KSP's standard of 24.
• We step in 1m (tiny) 2m (small) 3m (medium) 4m (large) profiles, plus some large ones I haven't really blocked out yet (think the Saturn 5). Small capsule is 2m, the medium capsule sits at 2.5m (kinda the outlier, as to get a proportionate Gemini-esque craft I had to bridge the gap); large will be 4m. Things are 99% as close as 'real' scale as I could make it
• Parts are made out of subparts, so for example you'd model one endcap for a tank and reference it twice in XML to appear on both sides. Same deal with the RCS system, for all 16 parts variants there are only three nozzles. Because our rendering system is super efficient, this means complicated ships end up being easier and easier to render because you only have one RCS thruster, one fuel tank end, etc.
• Part models are centered at 0,0 to make sure XML subpart coordinates are consistent.
• Assets are imported into the game in the GLB format. This can be exported from Blender by going to File->Export->glTF 2.0 (.glb/.gltf) and in the menu that appears, select "Format glTF Binary (.glb)"
• Try be efficient with polys as you can be - more density on part silhouettes and less where you can't see it. Rim of an engine bell, for eg.

Guidelines for texturing...

• I work with atlases, so one texture serves multiple parts. In xml you define what part uses what texture, so it's easy to make things efficient.
• A part has one diffuse, one normal map, and one PBR map (so far). PBR maps are three maps in one (Red channel Roughness, Green Metalness, and Blue Ambient Occlusion)
• Diffuse maps thus have no AO, make sure you save them without AO baked in, and put it in the PBR map.
• Most parts are 350ppm (pixels per meter), but as things get bigger you want to step down so things don't use too much texture space. Not by much, it was kind of what the Restock team did with KSP, the largest tanks were about half the density. So my 3m\4m tanks are about 200ppm. Rule of thumb, give more texture density to parts that you're going to interact with (IVA's, Kitten-interactable parts, science equipment, etc); people don't necessarily zoom in on tanks.
• Compress textures in .dds format, more details on compression standards coming soon™
• Roughness maps are greyscale, Metalness maps are binary black and white. You can approximate a roughness map with an inverted Ambient occulsion map overlaid over a diffuse map (in sRGB) that has had its contrast tweaked, but it's all about iteration until it looks right. Metalness maps are strictly "is it metal? Yes\no", as a black and white binary map. I haven't been happy with how glass looks so i'm still working out how to define that.
• So texture these individually, then flatten them, paste them into a PNG file's RGB channels, and then save that PNG as a .dds through Nvidia's texture tool program (standalone and free). You can also use the same tool to convert heightmaps into Normal maps, but those compress differently again. More info soon!