[1.12.x] KSP Part Volumes

[theJesuit]

Just released a Simplex Assembly mod.  Gives all parts construction manipulation but not storage if it hasn't been specified by volume. 

This mod though will give the ability to use something like Sandcastle or OSE for any part.  Except for crewed parts with inventory. 

[linuxgurugamer]

New release, 0.0.3

• Added check for ModuleInventoryPart, if there, packedVolume set to -1
• Added part whitelist
• Added option to allow manipulatable parts to have volumes changed
• Added part    cryoengine-iguanodon-1    to blacklist due to an inability to properly get the correct dimensions from Unity for this engine

[flart]

@linuxgurugamer

(manipulatable parts checkbox enabled)

1. if a part already has volume, it is not showed in the Bypass reasons.

// ----------------------------------------------------------------------
// Squad/Parts/Aero/aerodynamicNoseCone/aerodynamicNoseCone/noseCone
// Dimensions: x: 1.53, y: 0.68, z: 1.53
// Bounding Box Size: 1583.574 liters
// Volume adjustment: 10%
//
//   Bypass reasons:
//
// ----------------------------------------------------------------------

Also it would be nice to have that config volume:

//   Bypass reasons:
//      contains ModuleCargoPart (packedVolume = 1050)

 

2. CargoContainers can't have anything except ModuleCargoPart/packedVolume = -1,
so ModuleInventoryPart is probably another Bypass reasons.

// ----------------------------------------------------------------------
// Squad/Parts/Cargo/CargoContainers/cargoContainer/cargoContainer
// Dimensions: x: 1.25, y: 0.64, z: 1.25
// Bounding Box Size: 998.1078 liters
// Volume adjustment: 10%
//
@PART[cargoContainer]:Final
{
    -MODULE[ModuleCargoPart] {}
    MODULE
    {
        name = ModuleCargoPart
        packedVolume = -1
        KSP_PartVolume = true
    }
}
// ----------------------------------------------------------------------

3. repo's KSP_PartVolume\PluginData\KSP_PartVolume.cfg miss default processManipulableOnly line.

 

 

Edited August 18, 2021 by flart

[linuxgurugamer]

1 hour ago, flart said:

1. if a part already has volume, it is not showed in the Bypass reasons.

I'll see if I can add that.

It alreasy says that it contains a ModuleCargoPart if it's there, as one of the bypass reasons.  No need for anything else.  That's where the volume is specified

1 hour ago, flart said:

2. CargoContainers can't have anything except ModuleCargoPart/packedVolume = -1,
so ModuleInventoryPart is probably another Bypass reasons.

It's not being bypassed, it just has the setting set to -1

1 hour ago, flart said:

repo's KSP_PartVolume\PluginData\KSP_PartVolume.cfg miss default processManipulableOnly line.

Not needed.  It defaults to false, and you shouldn't be editing that file anyway, it's set by the settings page.  I'll add it, but only because of the change for #1 above, in the next release whenever it happens

Edited August 18, 2021 by linuxgurugamer

[flart]

25 minutes ago, linuxgurugamer said:

It's not being bypassed, it just has the setting set to -1

it is worth considering to bypass containers, because:

there is a problem with parts, that have both ModuleInventoryPart and ModuleCargoPart, modules in the part need to be placed in the specific order, one before another, and if the order is reversed, the modules are no working properly, and the mod patching could change that order.

Containers can't be placed in the other containers, and  packedVolume could be only -1, so nothing to do in area of this mod

As now, mod just remove ModuleCargoPart/packedVolume = -1, and replace with its own ModuleCargoPart/packedVolume = -1. Probably it is safer to ignore containers whatsoever.

[linuxgurugamer]

1 hour ago, flart said:

it is worth considering to bypass containers, because:

there is a problem with parts, that have both ModuleInventoryPart and ModuleCargoPart, modules in the part need to be placed in the specific order, one before another, and if the order is reversed, the modules are no working properly, and the mod patching could change that order.

Containers can't be placed in the other containers, and  packedVolume could be only -1, so nothing to do in area of this mod

As now, mod just remove ModuleCargoPart/packedVolume = -1, and replace with its own ModuleCargoPart/packedVolume = -1. Probably it is safer to ignore containers whatsoever.

You miss the point.  The mod properly sets the values if both are set.  They are not being bypassed for that reason, just having the correct values.

[flart]

On 8/18/2021 at 5:14 PM, linuxgurugamer said:

It alreasy says that it contains a ModuleCargoPart if it's there, as one of the bypass reasons.

Where?
Set processManipulableOnly to true, generate the config, find the Squad/Parts/Aero/aerodynamicNoseCone/aerodynamicNoseCone/noseCone
the part is bypassed, but nothing in the comment is saying that ModuleCargoPart is there

Spoiler

// ----------------------------------------------------------------------
// Squad/Parts/Aero/aerodynamicNoseCone/aerodynamicNoseCone/noseCone
// Dimensions: x: 1.53, y: 0.68, z: 1.53
// Bounding Box Size: 1583.574 liters
// Volume adjustment: 10%
//
//   Bypass reasons:
//
// ----------------------------------------------------------------------

 

 

 

Also put PotatoRoid and PotatoComet into the blacklist, please.

Spoiler

// ----------------------------------------------------------------------
// Squad/Parts/Misc/PotatoRoid/part/PotatoRoid
// Bounding Box Size: 1000 liters
// Volume adjustment: 10%
//
@PART[PotatoRoid]:HAS[!MODULE[ModuleCargoPart]]:Final
{
    MODULE
    {
        name = ModuleCargoPart
        packedVolume = 1101
    }
}
// ----------------------------------------------------------------------

 

Edited August 22, 2021 by flart

[theJesuit]

I came to ask whether it would be possible to get the bounding box dimensions...

Apparently I can - Thank you in hindsight!

I'm working on SIMPLEX Assembly Sandcastle integration, and considering making the larger Inventory spaces only able to build parts that will actually fit inside them.  There will need to be some awesome MM-Fu with this, and likely that I'll need to provide a 'per part' yay or nay for the various size containers/ inventory parts.

 

[theJesuit]

Howdy @linuxgurugamer!

So, I've been playing with volumes and extracted the dimensions from all Squad parts, and I have noticed something...

When calculating the Part Volumes for Squad with NO packaging...

The mk3 fuselage, and cargo bays are the 2.5m, 5m, and 10m respectively in terms of height, which means save three small cargo bays stack should by 7.5 meters.

The Rockomax 64 (2.5m large orange tank :) old skool measurements!) is 7.55 meters

Yet when you compare the Rockomax 64 against three of the 2.5m fuselages stacked, it looks smaller, meaning you can fit the Rockomax 7.55m height comfortably within 3 stanck Mk3 cargo bays totaling 7.5ms.

I'm just pointing this out, and I'm not suggesting you change or fix this, unless it really bugs you

In fact all the Rockomax tanks seem to be different sizes from Part Volume comparatively, from flattest to jumbo:

8x8 is 7.92m
4x16 is 7.68m
2x32 is 7.6m
1x64 is 7.55m

Given that you use the bounding box as the part has been created to calculate volumes, it is what it is.  Just an interesting observation.

Peace.

[linuxgurugamer]

18 hours ago, theJesuit said:

Howdy @linuxgurugamer!

So, I've been playing with volumes and extracted the dimensions from all Squad parts, and I have noticed something...

When calculating the Part Volumes for Squad with NO packaging...

The mk3 fuselage, and cargo bays are the 2.5m, 5m, and 10m respectively in terms of height, which means save three small cargo bays stack should by 7.5 meters.

The Rockomax 64 (2.5m large orange tank :) old skool measurements!) is 7.55 meters

Yet when you compare the Rockomax 64 against three of the 2.5m fuselages stacked, it looks smaller, meaning you can fit the Rockomax 7.55m height comfortably within 3 stanck Mk3 cargo bays totaling 7.5ms.

I'm just pointing this out, and I'm not suggesting you change or fix this, unless it really bugs you

In fact all the Rockomax tanks seem to be different sizes from Part Volume comparatively, from flattest to jumbo:

8x8 is 7.92m
4x16 is 7.68m
2x32 is 7.6m
1x64 is 7.55m

Given that you use the bounding box as the part has been created to calculate volumes, it is what it is.  Just an interesting observation.

Peace.

Keep in mind that the part volumes are used for packaging, so it really doesn't matter that much if they are a bit larger.  In fact, the mod adds extra space for packing

It's a quick n dirty calculation, the bounding box isn't great, but was the easiest and safest to use

[theJesuit]

3 hours ago, linuxgurugamer said:

Keep in mind that the part volumes are used for packaging, so it really doesn't matter that much if they are a bit larger.  In fact, the mod adds extra space for packing

It's a quick n dirty calculation, the bounding box isn't great, but was the easiest and safest to use

It was more that the dimensions were not relatable when compared to part volumes when i used the option to remove all packaging.

All good though.

[flart]

it's funny, I was asking to add process "-1" feature, and now it is conflicting with one of my mods.

CommNet Antennas Consumptor adds moduleAntennaToggler,
and ModuleDataTransmitter/DeployFxModules need to have an index of that module (I patch it there).
Removing ModuleCargoPart what is there originally and appending it on the end of PART, change the index.

Could you instead of removing and adding for "-1" case:
-MODULE[ModuleCargoPart] {}
MODULE 
{
        name = ModuleCargoPart
        packedVolume = 100
        KSP_PartVolume = true
}

to make it a patch like
@MODULE[ModuleCargoPart]
{
        %packedVolume = 100
        %KSP_PartVolume = true
}

so an order of moduleAntennaToggler doesn't change?

Edited August 28, 2021 by flart

[Krzeszny]

On 6/19/2021 at 11:21 PM, linuxgurugamer said:

Should be there now, sorry

Make sure you have the latest version installed.

 

Do the following both with and without KIS:

1. Start the game, exit after getting to the main menu.
2. Start the game again, and do the video

Provide the log with each.

I think 2 months is enough on my part.

I did what you suggested and the bug isn't there anymore for whatever reason.

[linuxgurugamer]

On 8/28/2021 at 9:29 AM, flart said:

Could you instead of removing and adding for "-1" case:
-MODULE[ModuleCargoPart] {}
MODULE 
{
        name = ModuleCargoPart
        packedVolume = 100
        KSP_PartVolume = true
}

to make it a patch like
@MODULE[ModuleCargoPart]
{
        %packedVolume = 100
        %KSP_PartVolume = true
}

so an order of moduleAntennaToggler doesn't change?

I'll see if I can add something about that

[flart]

@linuxgurugamer if you missed it — https://github.com/linuxgurugamer/KSP_PartVolume/pull/4
otherwise in the case "time has not come" yet - it's ok

[linuxgurugamer]

8 hours ago, flart said:

@linuxgurugamer if you missed it — https://github.com/linuxgurugamer/KSP_PartVolume/pull/4
otherwise in the case "time has not come" yet - it's ok

I am aware of that, but it's not a priority right now.  Still working through real bugs and updates to 1.12.

Also decided to wait in case he has any other commits

[DPOHbl4]

Mod keeps saying that i have to restart the game

LOG

[linuxgurugamer]

1 hour ago, DPOHbl4 said:

Mod keeps saying that i have to restart the game

LOG

it will say that if you change any parts/mods between game runs

[DPOHbl4]

5 minutes ago, linuxgurugamer said:

it will say that if you change any parts/mods between game runs

I am sorry for not being clear enough - it keeps saying that mod detected a new part without me adding any new mods, it wants me to keep restarting the game infinitely. 

I managed to find the culprit - "allow manipulatable parts to have volumes changed" option. If i disable it all works as intended.

Also parts that have storage capacity are not flagged as manipulatable in EVA, for example crew parts from Missing history and Station Parts Expansion Redux.

[Gordon Dry]

On 10/29/2021 at 3:03 PM, DPOHbl4 said:

I managed to find the culprit - "allow manipulatable parts to have volumes changed" option. If i disable it all works as intended.

Where is this option? I neither see it in KSP_PartVolume nor in game settings.

Edit:

Is it "Process manipulable-only parts"? This is already disabled by default, this confuses me.

Edited November 4, 2021 by Gordon Dry

[DPOHbl4]

32 minutes ago, Gordon Dry said:

Edit:

Is it "Process manipulable-only parts"? This is already disabled by default, this confuses me.

Yes, that's it. I wanted to use that option so after i turned it on mod always said that i have to restart the game.

[Saul Retav]

I had the same issue as KPOHbl4 and yes, disabling the "process manipulable-only parts" fixed it.

[Gordon Dry]

The easiest way is to let the mod create the

GameData\partVolumes.cfg

then  quit, move the folder

GameData\KSP_PartVolume

out of GameData
and if existing, also remove

GameData\KerbalInventoryForAll\AllowModPartsInStock.cfg

As long as no part mods are added, the

GameData\partVolumes.cfg

alone is good enough.
Removing part mods is no issue, because the patches for those parts are ignored then.

Edited December 11, 2021 by Gordon Dry

[boCash]

I'm having trouble getting this mod to apply ModuleCargoPart to certain parts. This mod finds them and they aren't being bypassed/commented out in partVolumes.cfg. I think all of the offending parts already have ModuleInventoryPart and I see that they're all yielding 'packedVolume = -1' in the .cfg. I even tried hand-editing the .cfg on one part to 'packedVolume = 1000' in a hail mary to make something work but I cannot for the life of me get the gosh-darn ModuleCargoPart to apply. I'm not very familiar with how MM does its magic so please bear with my uninformed self and let me know if there's any additional data that would help or if I'm being really dumb and failed to read something in this thread.

Log

partVolumes.cfg

An offending part: \PlanetaryBaseInc\BaseSystem\Parts\Utility\Garages\garage_adapter_g.cfg

 

(12/22) Update after another couple hours of tinkering and learning:

True to my avatar, I failed to read something in this thread. Or rather, to process it in any meaningful way. Any time I had it set to 'Process Manipulable-only Parts', I encountered the same restart loop that DPOHbl4 mentioned. I tried the fix Gordon suggested but I still can't get ModuleCargoPart to stick. Is it something to do with the order of that and ModuleInventoryPart that was mentioned upthread? Hand-editing the part.cfg itself to add ModuleCargoPart works.

 

(12/23) Update after more tinkering and learning:

Yes, the issue is caused by the order of ModuleInventoryPart and ModuleCargoPart. Deleting ModuleInventoryPart before adding ModuleCargoPart solved the problem. I also readded ModuleInventoryPart, albeit with a static volume for all parts. I then removed KSP_PartVolume from the GameData folder so my precious hand edited file wouldn't be harassed.

Using NP++ and the ToolBucket plugin for multiline find+replace, I ran the following on PartVolumes.cfg:

Find:

    MODULE
    {
        name = ModuleCargoPart
        packedVolume = -1
        KSP_PartVolume = true
    }

Replace:

    !MODULE[ModuleInventoryPart] {}
    MODULE
    {
        name = ModuleCargoPart
        packedVolume = -1
        KSP_PartVolume = true
    }
    MODULE
    {
        name = ModuleInventoryPart
        InventorySlots = 4
        packedVolumeLimit = 400
    }

Edited December 23, 2021 by boCash
learning how to unbreak stuff

[eberkain]

On 6/5/2021 at 3:44 PM, Krzeszny said:

Is this intended?

 

I installed KIFA 1.2.2 and Part Volumes 0.0.3 and got this message, took some digging back in the thread to see what it was all about.  Apparently this should not show up anymore, but I just pulled them both of CKAN today and got it.