Modders Notes 1.11.0

[JPLRepo]

Inventory System

In order to allow a part to be an inventory cargo part that can be placed in inventories or allowing larger parts to be manipulated in EVA construction mode (but not placeable in inventories) the Part cfg file must have a ModuleCargoPart defined to it.

The following important KSPFields are available for configuration of this module:

• packedVolume - The space this part occupies when packed inside an inventory container. If this is set to < 0 then the part can be manipulated in EVA construction mode but cannot be placed inside inventory containers.
• kinematicDelay - This is the time delay used to wait for the part to settle on the ground.
• placementMaxRivotVelocity - This is the velocity the part must be travelling less than before it will be rivoted to the ground.
• inventoryTooltip - The tooltip for inventory cargo parts,shows up when mouse is over a part icon during flight.
• stackableQuantity - The number of parts of the same kind and variant that can be stacked in a single inventory slot. Defaults to 1, so leave it out if you DON’T want the part to be stackable.

The Inventory system is now persisted as a list of protoparts instead of a comma-separated string of names. The old system is still there for compatibility, but the new one is preferred.

Parts that can hold cargo parts are known as Inventory Parts and must have the ModuleInventoryPartPartModule defined to them (as it did before).

The inventory system now has volume and mass limits on ModuleInventoryPart (inventory container) parts. 

The following important KSPFields are available for configuration of this module:
InventorySlots - This is the number of inventory slots this part has.

• packedVolumeLimit - The volume capacity this container has.

• massLimit - The mass capacity this container has.

 

Inventory system now has default inventories the use of a DEFAULTPARTS node defined within a ModuleInventoryPart MODULE node in the part.cfg files.

ModuleInventoryPart.allowedKerbalEvaDistance obsolete in preference to GameSetting.EVA_INVENTORY_RANGE.

Kerbal Inventories now have two slots per kerbal and their inventories have a default inventory which is defined via the kerbal part.cfg files. This default will be taken each time they are added as crew to a ship in the VAB/SPH unless the persist kerbal inventories difficulty/game setting is turned on. In which case the default inventory is given to them the very first time they go on a mission but then persists between missions from the first mission onwards. Kerbal inventories in the editor scene and when they are IVA are managed via a new scenario module: KerbalInventoryScenario.

As part of the inventory system changes, part icons for inventory slots are no longer 3D parts with render textures. That was dropped in favor of part snapshots. For stock parts, these are already pre-baked in the GameData/Squad(Expansions)/<expansionName>/Parts/@thumbs folder. If your mod has cargo parts, the first time you add them to an inventory slot, the snapshots will be created automatically and persisted to GameData/<modName>/Parts/@thumbs. If you’re not using a Parts folder (consider doing it) they will be stored in the thumbs folder in the KSP root. If you’re doing adjustments to your parts to take advantage of the new inventory system, please also consider distributing the pre-baked thumbnails for them.

A number of variables and methods related to ModuleInventoryPart and the previous inventory system have been marked as obsolete refer to the API documentation for more information.

For further details on code classes and variables refer to the API documentation.

EVA Construction Mode

The main classes involved running EVA construction mode are (refer to the API documents for details of each class):

• EVAConstructionModeController

• EVAConstructionModeEditor

• EVAConstructionToolsUI

Parts taken out of an inventory are completely disabled (The Part and all its PartModule instance MonoBehaviors are disabled) and re enabled when it is attached to a vessel in Construction Mode or dropped on the ground/in space around the active kerbal.

The following methods can be overridden/implemented by PartModules that will be called during construction mode.

• OnPartCreatedFromInventory - This is called whenever the part is being created from an inventory (the user has dragged the part out from an inventory slot).

• OnInventoryModeDisable - This is called after the part is created from an inventory whilst just before the Part and all its PartModules are disabled. 

• OnInventoryModeEnable - This is called just before the part is enabled again when it is either attached or dropped in construction mode.

• OnConstructionModeUpdate - This is called every Update cycle for each Part and PartModule on an inactive Part that is currently attached to the mouse.

• OnConstructionModeFixedUpdate - This is called every FixedUpdate cycle for each Part and PartModule on an inactive Part that is currently attached to the mouse.

 

Contracts - Prebuilt craft, locations.

Contracts can now use pre-generated craft in a contract. These are defined in CONTRACTCRAFT config nodes as follows:

One PREBUILTCRAFT config node for each prebuilt craft (contained within a CONTRACTCRAFT node).

• url = <url for the craft file>

• AllowGround = True/False // Whether craft can spawn on the ground

• AllowOrbit = True/False // Whether craft can spawn in orbit        

• AllowWater = True/False // Whether craft can spawn in the ocean

• UsePreBuiltPos = True/False //Whether to use a random prebuild position, or completely random position.

• ContractType = <a string that the contract can use to identify which craft are for which contract>

There is also a config node structure for defining and storing pre-determined Lat/Lon locations on planets that contracts can now use.

These are defined in CONTRACTCRAFT config nodes as follows:

One PREBUILTPOSITIONS config node for each position (contained within a CONTRACTCRAFT node).

• Body = <CB body name>

• CenterLatitude = x.xxx //The center latitude that a random position will be generated from

• CenterLongitude = x.xxx //The center longitude that a random position will be generated from

• SearchRadius = xxxx //A radius in meters from the Lat/Lon that the position will be generated. So it’s never exactly in the same spot.

Other Items

LightOn/Off events have been replaced with a toggle event on the PAW to reduce PAW redraw. The events still exist and can be triggered, but are hidden from the PAW.

ModuleLight no longer uses animations to control color and brightness of the lights.Instead this is done by the part module itself.

Previously KSP had a hard-coded path to the techtree.cfg file in GameData Folder which was read at startup. Now KSP will look for and concatenate TechTree nodes from the game database which is preloaded on startup of all .cfg files and ConfigNodes.

QuaternionD class now supports LookRotation in double precision.

The FlightVesselOverlays class implements the Center of Mass/Lift/Thrust overlays to be displayed in EVA construction mode.

Parts now have a minimum Rigidbody mass minimumRBMass which affects how small the rigidbodies mass can be. Does not affect part.mass - which is what’s used to calculate force, etc - but does affect rigidbody collisions.

Kerbals are no longer massless, and the weight they carry in their inventories matters in terms of physics. In order to not impact the way existing vessels fly, an amount of mass equal to the size of the crew times the mass of a kerbal with a full jetpack and a parachute (94kg) is subtracted from the vessel mass and added back in function of the crew in the vessel. This is all already done automatically, but if you want to play around with different mass values for a kerbal, the value is kerbalCrewMass in Physics.cfg (defaults to 45 kg).

[Poodmund]

On 12/17/2020 at 5:30 AM, JPLRepo said:

As part of the inventory system changes, part icons for inventory slots are no longer 3D parts with render textures. That was dropped in favor of part snapshots. For stock parts, these are already pre-baked in the GameData/Squad(Expansions)/<expansionName>/Parts/@thumbs folder. If your mod has cargo parts, the first time you add them to an inventory slot, the snapshots will be created automatically and persisted to GameData/<modName>/Parts/@thumbs. If you’re not using a Parts folder (consider doing it) they will be stored in the thumbs folder in the KSP root. If you’re doing adjustments to your parts to take advantage of the new inventory system, please also consider distributing the pre-baked thumbnails for them.

If you have a patch that affect the visuals of a Vanilla part, how can this be handled to display the visual representation of the part post-patch without having to distribute files to overwrite the Vanilla thumbnail assets?

EDIT: Also, why wouldn't all the textures located in Kerbal Space Program\GameData\Squad\Parts\@thumbs\ be in the DXT5 DDS format rather than PNG as Unity will have to compress them all each time you load the game?

Edited December 18, 2020 by Poodmund

[cineboxandrew]

On 12/16/2020 at 9:30 PM, JPLRepo said:

As part of the inventory system changes, part icons for inventory slots are no longer 3D parts with render textures. That was dropped in favor of part snapshots. For stock parts, these are already pre-baked in the GameData/Squad(Expansions)/<expansionName>/Parts/@thumbs folder. If your mod has cargo parts, the first time you add them to an inventory slot, the snapshots will be created automatically and persisted to GameData/<modName>/Parts/@thumbs. If you’re not using a Parts folder (consider doing it) they will be stored in the thumbs folder in the KSP root. If you’re doing adjustments to your parts to take advantage of the new inventory system, please also consider distributing the pre-baked thumbnails for them.

Please tell me these are loaded on the fly

Edit: Honestly, is there a real reason to save the thumbnails and not re-render them each time? loading a png and compressing it is pretty slow compared to just a handful of draw calls and a ReadPixels, as I've learned working on Conformal Decals

Edited December 19, 2020 by cineboxandrew

[ev0]

On 12/16/2020 at 10:30 PM, JPLRepo said:

Previously KSP had a hard-coded path to the techtree.cfg file in GameData Folder which was read at startup. Now KSP will look for and concatenate TechTree nodes from the game database which is preloaded on startup of all .cfg files and ConfigNodes.

Is there a new way load a single TechTree node from a single file after startup now?  My mod created a file with a single TechTree node on the fly, derived from the ModuleManager tech tree. The file contents change based on the user's game settings, which they could change mid game if they wanted. Assigning my file's URL to "HighLogic.CurrentGame.Parameters.Career.TechTreeUrl" was all I needed to do to load my modded tech tree, but that doesn't seem to work anymore.

[Beale]

On 12/17/2020 at 5:30 AM, JPLRepo said:

As part of the inventory system changes, part icons for inventory slots are no longer 3D parts with render textures. That was dropped in favor of part snapshots. For stock parts, these are already pre-baked in the GameData/Squad(Expansions)/<expansionName>/Parts/@thumbs folder. If your mod has cargo parts, the first time you add them to an inventory slot, the snapshots will be created automatically and persisted to GameData/<modName>/Parts/@thumbs. If you’re not using a Parts folder (consider doing it) they will be stored in the thumbs folder in the KSP root. If you’re doing adjustments to your parts to take advantage of the new inventory system, please also consider distributing the pre-baked thumbnails for them.

Just a little teething issue, for years now my mods (and many other people's mods) have been using a "parts" folder, but in lower case (not "Parts").

Unfortunately lower case does not work with this new system, would a small tweak to the code to cast the folder name to upper / lower be possible to remedy this? Unfortunately right now icon generation is a bit broken for all my mods.

Great update in total and nice work fellas, but there is a little bit of pain! 

Many thanks.

Edit: Nertea's suggestion is way better

Edited December 19, 2020 by Beale

[Nertea]

Further to @Beale's note, this is somewhat worse for any mod that creates a storeable part that doesn't sit in a Parts folder. It's also pretty awkward for mods that replace/mess with stock part visuals as then we have to de shennanigans inside users' GameData/Squad folders, which is less than ideal. 

I would suggest a solution to this might be to preserve the current capability, if you must, but allow ModuleCargoPart to specify the thumbnail path. 

Edited December 19, 2020 by Nertea

[Poodmund]

On 12/19/2020 at 4:21 PM, Beale said:

Just a little teething issue, for years now my mods (and many other people's mods) have been using a "parts" folder, but in lower case (not "Parts").

Unfortunately lower case does not work with this new system, would a small tweak to the code to cast the folder name to upper / lower be possible to remedy this? Unfortunately right now icon generation is a bit broken for all my mods.

It would be much more foolproof if you could specify a path to a texture inside the cargo part module, i.e.

	MODULE
	{
		name = ModuleCargoPart
		packedVolume = 100
		thumbPath = Squad/Parts/DummyPart/part.png
	}	

This would also double up for Module Manager being able to interact with this feature.

EDIT: Oh, Nertea just ninja'd me saying exactly the same thing.

EDITEDIT: Just seen thumbPath suggested elsewhere which is probably more suitable that iconPath that I originally posted.

EDITEDITEDIT: It also doesn't seem variants are handled with the current system.

Edited December 20, 2020 by Poodmund

[JPLRepo]

On 12/19/2020 at 4:49 PM, ev0 said:

Is there a new way load a single TechTree node from a single file after startup now?  My mod created a file with a single TechTree node on the fly, derived from the ModuleManager tech tree. The file contents change based on the user's game settings, which they could change mid game if they wanted. Assigning my file's URL to "HighLogic.CurrentGame.Parameters.Career.TechTreeUrl" was all I needed to do to load my modded tech tree, but that doesn't seem to work anymore.

If you want to add one after startup. redefine/write out all the rd nodes to a file.
Call RDController.Instance.techTree.LoadTechTree(string filePath, List<RDNode> rdNodes)
The filePath would be your new rd nodes file/tech nodes setup. and rdNodes you would pass in the existing nodes: RDController.Instance.nodes.

 

On 12/20/2020 at 2:32 AM, Poodmund said:

It would be much more foolproof if you could specify a path to a texture inside the cargo part module, i.e.

	MODULE
	{
		name = ModuleCargoPart
		packedVolume = 100
		thumbPath = Squad/Parts/DummyPart/part.png
	}	

This would also double up for Module Manager being able to interact with this feature.

EDIT: Oh, Nertea just ninja'd me saying exactly the same thing.

EDITEDIT: Just seen thumbPath suggested elsewhere which is probably more suitable that iconPath that I originally posted.

EDITEDITEDIT: It also doesn't seem variants are handled with the current system.

@Poodmund@Nertea@Beale

If the Part is not in a GameData \Parts\ folder it will automatically default to GameData\@thumbs\Parts\ folder.
Will look at what we can do after the holiday break about allowing the PartModule to specify a path. No commitments though.
Variants are handled by the thumbnails. - need some more details on what you aren't seeing there.

[micha]

On 12/17/2020 at 5:30 AM, JPLRepo said:

• stackableQuantity - The number of parts of the same kind and variant that can be stacked in a single inventory slot. Defaults to 1, so leave it out if you DON’T want the part to be stackable.

Is there a reason that parts have a stack limit?  Seems that volume/mass restrictions of the container would have covered it along with a "canStack" flag if a part should not be stackable for some reason.

Alternatively could we add a "0" or "-1" value to indicate that a part can be stacked infinitely (assuming volume/mass limits are maintained)?

Also it would have been great if the game could calculate a parts' volume (if not explicitly provided) based on its dragcube thus automatically making all parts up to a certain size storable in inventories. It's a lot of work for modders to explicitly add inventory support to all of their parts.. (yes, I'm lazy! )

Thanks for the awesome update and keep up the great work!

[ev0]

9 hours ago, JPLRepo said:

If you want to add one after startup. redefine/write out all the rd nodes to a file.
Call RDController.Instance.techTree.LoadTechTree(string filePath, List<RDNode> rdNodes)
The filePath would be your new rd nodes file/tech nodes setup. and rdNodes you would pass in the existing nodes: RDController.Instance.nodes.

I think something like that only works from the R&D screen.  Otherwise the game is telling me the RDController.Instance is null from the KSC screen or in flight.  I think you also need to make sure to call other members in RDController.Instance.techTree to get the mod's RDNodes to load properly (like WipeTechTree , ReLoad, and/or SpawnTechTreeNodes, etc.).

But the game needs to know the loaded TechTree node while in flight in order to get the correct bonus that you get when you find one of the Space Odyssey monoliths.  Is something like the code example below more appropriate?  It seems to work for my mod, but if there's a more correct way let me know.  I'm not sure of a way to change the Instance so there's no random empty TechTree nodes left by the first for loop, which would happen if there's another TechTree node besides the stock one.

// Get instanced TechTree nodes.
ConfigNode[] instanceTechTreeNodes = GameDatabase.Instance.GetConfigNodes("TechTree");

// Clear all instanced TechTree nodes.
for (int i = 0; i < instanceTechTreeNodes.Length; ++i)
{
    instanceTechTreeNodes[i].ClearNodes();
}

// Repopulate the *first* TechTree node with MY_MODS's RDNodes.
for (int i = 0; i < myRDNodes.Length; ++i)
{
    instanceTechTreeNodes[0].AddNode(myRDNodes[i]);
}

 

[JPLRepo]

On 12/27/2020 at 10:12 PM, ev0 said:

I think something like that only works from the R&D screen.  Otherwise the game is telling me the RDController.Instance is null from the KSC screen or in flight.  I think you also need to make sure to call other members in RDController.Instance.techTree to get the mod's RDNodes to load properly (like WipeTechTree , ReLoad, and/or SpawnTechTreeNodes, etc.).

But the game needs to know the loaded TechTree node while in flight in order to get the correct bonus that you get when you find one of the Space Odyssey monoliths.  Is something like the code example below more appropriate?  It seems to work for my mod, but if there's a more correct way let me know.  I'm not sure of a way to change the Instance so there's no random empty TechTree nodes left by the first for loop, which would happen if there's another TechTree node besides the stock one.

// Get instanced TechTree nodes.
ConfigNode[] instanceTechTreeNodes = GameDatabase.Instance.GetConfigNodes("TechTree");

// Clear all instanced TechTree nodes.
for (int i = 0; i < instanceTechTreeNodes.Length; ++i)
{
    instanceTechTreeNodes[i].ClearNodes();
}

// Repopulate the *first* TechTree node with MY_MODS's RDNodes.
for (int i = 0; i < myRDNodes.Length; ++i)
{
    instanceTechTreeNodes[0].AddNode(myRDNodes[i]);
}

 

That "should" work in theory.

My bad with the information given earlier, indeed those are instanced only in RnD. Will look to add a static method for this - given we've removed the old way of doing it. This was an oversight.

On 12/27/2020 at 5:33 PM, micha said:

Is there a reason that parts have a stack limit?  Seems that volume/mass restrictions of the container would have covered it along with a "canStack" flag if a part should not be stackable for some reason.

Alternatively could we add a "0" or "-1" value to indicate that a part can be stacked infinitely (assuming volume/mass limits are maintained)?

Also it would have been great if the game could calculate a parts' volume (if not explicitly provided) based on its dragcube thus automatically making all parts up to a certain size storable in inventories. It's a lot of work for modders to explicitly add inventory support to all of their parts.. (yes, I'm lazy! )

Thanks for the awesome update and keep up the great work!

1) Would have to go and follow that up after the holidays.

2) Infinite stacking comes with it's own issues. There's also a limitation that you cannot stack parts that contain resources which is enforced regardless of the values in the cfg file.

3) This has already been raised as a request on the bug tracker. Can't promise anything there. It's a case of cost/benefit.

4) Thanks. Will pass on to the team.

[Poodmund]

21 hours ago, JPLRepo said:

On 12/27/2020 at 7:33 AM, micha said:

Also it would have been great if the game could calculate a parts' volume (if not explicitly provided) based on its dragcube thus automatically making all parts up to a certain size storable in inventories. It's a lot of work for modders to explicitly add inventory support to all of their parts.. (yes, I'm lazy! )

3) This has already been raised as a request on the bug tracker. Can't promise anything there. It's a case of cost/benefit.

Could you not consider all parts to be stored in 'cardboard boxes' and just calculate the storage volume of parts based on their mesh bounds? https://docs.unity3d.com/ScriptReference/Mesh-bounds.html

[Poodmund]

@JPLRepo with relation to the conversation above about part volume, was there any further decisions, chat or direction that can be shared in this regard? I appreciate 1.11.1 just dropped so you're probably very busy right now but I know a lot of modders were holding off defining their part volumes manually in configs in waiting to see if 1.11.1 was going to implement an intelligent method to handle this automatically.

[JPLRepo]

On 1/29/2021 at 6:55 AM, Poodmund said:

@JPLRepo with relation to the conversation above about part volume, was there any further decisions, chat or direction that can be shared in this regard? I appreciate 1.11.1 just dropped so you're probably very busy right now but I know a lot of modders were holding off defining their part volumes manually in configs in waiting to see if 1.11.1 was going to implement an intelligent method to handle this automatically.

Sorry. No this hasn't made it.

On 12/19/2020 at 4:49 PM, ev0 said:

Is there a new way load a single TechTree node from a single file after startup now?  My mod created a file with a single TechTree node on the fly, derived from the ModuleManager tech tree. The file contents change based on the user's game settings, which they could change mid game if they wanted. Assigning my file's URL to "HighLogic.CurrentGame.Parameters.Career.TechTreeUrl" was all I needed to do to load my modded tech tree, but that doesn't seem to work anymore.

This was fixed in 1.11.1 by way of adding new static public method to do this.
 

[linuxgurugamer]

On 12/27/2020 at 2:33 AM, micha said:

Also it would have been great if the game could calculate a parts' volume (if not explicitly provided) based on its dragcube thus automatically making all parts up to a certain size storable in inventories. It's a lot of work for modders to explicitly add inventory support to all of their parts.. (yes, I'm lazy! )

And for those modders who have lots of parts, it's a lot of work.

Is there a way to take a dragcube and calculate a volume?

Just now, linuxgurugamer said:

And for those modders who have lots of parts, it's a lot of work.

 

On 12/17/2020 at 12:30 AM, JPLRepo said:

packedVolume - The space this part occupies when packed inside an inventory container. If this is set to < 0 then the part can be manipulated in EVA construction mode but cannot be placed inside inventory containers.

What units are these?

Edited March 11, 2021 by linuxgurugamer

[Poodmund]

@linuxgurugamer, see this idea:

On 12/29/2020 at 7:49 PM, Poodmund said:

Could you not consider all parts to be stored in 'cardboard boxes' and just calculate the storage volume of parts based on their mesh bounds? https://docs.unity3d.com/ScriptReference/Mesh-bounds.html

 

[JPLRepo]

On 3/11/2021 at 11:32 PM, linuxgurugamer said:

And for those modders who have lots of parts, it's a lot of work.

Is there a way to take a dragcube and calculate a volume?

 

What units are these?

a) Sorry.

b) Not currently.

c) Litres.

[Poodmund]

@linuxgurugamer, I am aware that forum member @ValiZockt has created a very lightweight plugin that applies the Unity mesh bounds technique as discussed above to parse all loaded parts in the current game database and write their volumetric capacity out to a text file so that you can easily append these values to your part configs. A really handy way to brute force an unintelligent situation but I am sure if you contacted them they would be happy to send you their plugin to use.

[Goufalite]

Hello,

I need a little help please, I'm currently writing a mod which adds parts to the inventory system. It works for the moment but I have problems with stackable parts:

• The CheckPartStorage(craftPart) returns false even if a stack is not complete, the API says "Checks if the part can be stored Without actually storing it.", this is confusing...
• StoreCargoPartAtSlot(craftPart, -1) adds the part the next empty slot. But once the inventory has no empty slots but still stackable space it fails, but leaves an error "Unable to store part - there are no free slots. Unable find part with name=evaRepairKit"
• Apparently using StoreCargoPartAtSlot with Part/AvailablePart instead of string is advised but I'm missing the string to Part conversion. Is there an example somewhere?

Thanks in advance!

[Goufalite]

On 6/6/2021 at 3:31 PM, Goufalite said:

I need a little help please, I'm currently writing a mod which adds parts to the inventory system. It works for the moment but I have problems with stackable parts:

After a few research, answers here :