shadowmage45 / SSTULabs

Dev repository for testing/unfinished KSP parts/plugins/etc.
Other
62 stars 41 forks source link

Custom COS storage part, no fuel GUI #785

Open Jimbodiah opened 5 years ago

Jimbodiah commented 5 years ago

I'm trying to make a new version of my COS storage containers and have the following code:

`+PART[SSTU-ST-COS-HAB-L]:NEEDS[SSTU]:AFTER[SSTU] {

@name = JPL-COS-STORAGE-25 @author = ShadowMage, Jimbodiah

@TechRequired = spaceExploration @entryCost = 32000 @cost = 8000 @category = FuelTank @title = JPL - COS - STORAGE-25 @description = COS Storage 2.5m @manufacturer = JPL

!INTERNAL{}

@mass = 2.9 @crashTolerance = 12 @maxTemp = 2200 @fuelCrossFeed = True @CrewCapacity = 0 @vesselType = Station

!MODULE[SSTUVolumeContainer] {}

MODULE { name = SSTUVolumeContainer baseContainerIndex = 0 subtractMass = false subtractCost = false enableContainerEdit = true enableFuelTypeChange = true CONTAINER { name = Storage volume = 0 tankageVolume = 0.15 tankageMass = 0.15 defaultModifier = standard defaultResources = ElectricCharge,1,1 resource = SSTUEmptyVolume resource = Ore resource = ElectricCharge resource = NTO resource = Aerozine50 resource = LiquidFuel resource = Oxidizer resource = RocketParts resource = MonoPropellant resource = XenonGas modifier = standard modifier = lbo modifier = zbo modifier = zboLight modifier = light modifier = superLight modifier = structural modifier = structuralLight }

UPGRADES
{        
    // tank type upgrades -- unlock the various tank modifier types
    UPGRADE
    {
        name__ = SSTU-VCMod-Lightweight
    }
    UPGRADE
    {
        name__ = SSTU-VCMod-SuperLightweight
    }
    UPGRADE
    {
        name__ = SSTU-VCMod-LowBoiloff
    }
    UPGRADE
    {
        name__ = SSTU-VCMod-ZeroBoiloff
    }
    UPGRADE
    {
        name__ = SSTU-VCMod-LightweightZeroBoiloff
    }
}

}

}

`

There is no fuel GUI available in the VAB for this part, despite listing both these as true:

enableContainerEdit = true
enableFuelTypeChange = true

What am I doing wrong?

Also are the COS length variants no longer valid for COREs? ie XSHORT, SHORT, MEDIUM, LONG...

shadowmage45 commented 5 years ago

That config appears to be correct from a quick review. Any errors in the log when using that part in the editor? Could you post the post-module-manager-patched config for the part (out of the ModuleManager.ConfigCache file)?

The only other reason the GUI would be not displayed that I can think of, is if there are no containers with any volume that can be adjusted.

Thinking on it a bit -- the order of the modules in the part config is extremely important. When you delete the module, and then re-add it, it gets added back in to the end of the file. It needs to be present in the file before the SSTUModularPart module. This may well be causing the problem that you are seeing

Rather than deleting the entire module, you might try to merely delete the CONTAINER nodes from the existing module, and then patch in your new CONTAINER nodes as needed.

Also are the COS length variants no longer valid for COREs? ie XSHORT, SHORT, MEDIUM, LONG...

The way the modular-part plugin works has changed completely compared to prior versions, and requires a bit more setup for some things. Not sure exactly what you are asking there though? There should still be multiple COS parts, with specific lengths; all of the lengths are still available. I don't even think the model-definition names changed for these (still seeing ' name = ST-COS-XSHORT' in the modeldata files).

Jimbodiah commented 5 years ago

OK, the order might be the cause then. I will try that first (removing excess containers and editing existing one).

Re COS lengths: I have a custom storage COS module that in 1.3.1 I could change the length of in the VAB, so select the XSHORT to XLONG and it would automatically add/remove volume of any resources.

BTW: The collider had some issues with placing items on the outside surface when changing the CORE length in the VAB, but as a container it was really cool to have the COS equivalent of an MFT-A. I might just make 3 fixed lengths instead, as that seems to solve the surface attach issue in 1.3.1 (so probably the same in 1.6.1).

I could never get the MFT-A to get the COS textures for some reason (knowing it was only for 2-3 fixed lengths), so made my own part.

I'll let you know if the module order was the cause. Thanks!!!

shadowmage45 commented 5 years ago

Re COS lengths: I have a custom storage COS module that in 1.3.1 I could change the length of in the VAB, so select the XSHORT to XLONG and it would automatically add/remove volume of any resources.

Ahh, yes, you should still be able to configure your part for that kind of setup. Those would be modifications to the SSTUModularPart config, basically just adding the additional models to the CORE{} node. Should be fairly simple to do as all of the volume data/etc is defined in the model config.

So.. how the MFT-A has multiple lengths defined under a single CORE node -- https://github.com/shadowmage45/SSTULabs/blob/master/GameData/SSTU/Parts/Tanks/SSTU-TANK-MFT-A.cfg#L192-L211

Do the same for your COS models, something like:

CORE
{
    //variant name is unimportant, not used unless multiple CORE nodes are present, which should not be needed in your setup
    variant = Default 
    model = SSTU-ST-COS-XSHORT
    model = SSTU-ST-COS-SHORT
    model = SSTU-ST-COS-MEDIUM
    model = SSTU-ST-COS-LONG
}

And the patch that would need to be added to your existing patch would be:

@MODULE[SSTUModularPart]
{
    @CORE[Standard]
    {
        model = SSTU-ST-COS-XSHORT
        model = SSTU-ST-COS-SHORT
        model = SSTU-ST-COS-MEDIUM
    }
}

^^^ This will keep the existing 'LONG' model definition, and add the three other lengths. Now that there are multiple CORE options, the Core/Body slider should be visible in the PAW in the editors.

Jimbodiah commented 5 years ago

Got the CORE change to work, still working on the SSTU volume container.

Screenshot_3

I made a new part file instead of an MM patch just to be sure. The VolumeContainer module is from the MFT-A and the ModularPart is from the COS-HAB.

MM patch shows both modules. Even the ModIntegrations seems to be working judging by all the added resources in the MM log for this part.

UrlConfig { parentUrl = Jimbodiah/JPL/Tanks/JPL-COS-Storage PART { module = Part name = JPL-COS-STORAGE-25 author = Shadowmage, Jimbodiah TechRequired = spaceExploration entryCost = 32000 cost = 8000 category = FuelTank subcategory = 0 title = JPL - COS - STORAGE-25 description = COS Storage 2.5m manufacturer = JPL rescaleFactor = 1 node_stack_top = 0, 0, 0, 0, 1, 0, 1 node_stack_top1 = 0, 0, 0, 0, 1, 0, 1 node_stack_top2 = 0, 0, 0, 0, 1, 0, 1 node_stack_top3 = 0, 0, 0, 0, 1, 0, 1 node_stack_top4 = 0, 0, 0, 0, 1, 0, 1 node_stack_bottom = 0,0, 0, 0, -1, 0, 1 node_stack_bottom1 = 0,0, 0, 0, -1, 0, 1 node_stack_bottom2 = 0,0, 0, 0, -1, 0, 1 node_stack_bottom3 = 0,0, 0, 0, -1, 0, 1 node_stack_bottom4 = 0,0, 0, 0, -1, 0, 1 node_attach = 0, 0, -2.5, 0, 0, -1, 2 attachRules = 1,0,1,1,1 mass = 2.9 crashTolerance = 14 maxTemp = 2000 fuelCrossFeed = True breakingForce = 2000 breakingTorque = 2000 MODEL { model = SSTU/Assets/EmptyProxyModel } MODULE { name = SSTUVolumeContainer enableContainerEdit = true enableFuelTypeChange = true subtractMass = false subtractCost = false baseContainerIndex = 0 CONTAINER { name = Storage volume = 0 tankageVolume = 0.15 tankageMass = 0.15 defaultModifier = standard defaultFuelPreset = LFO resource = ElectricCharge resource = NTO resource = Aerozine50 resource = LiquidFuel resource = LqdHydrogen resource = Oxidizer resource = RocketParts resource = MonoPropellant resource = XenonGas resource = Ore modifier = standard modifier = lbo modifier = zbo modifier = zboLight modifier = light modifier = superLight resource = LqdDeuterium resource = LqdHe3 resource = FissionPellets resource = FusionPellets resource = NuclearSaltWater resource = MtlHydrogen resource = EnrichedUranium resource = DepletedFuel resource = ArgonGas resource = Lithium resource = Supplies resource = Mulch resource = Fertilizer } UPGRADES { UPGRADE { name = SSTU-VCMod-Lightweight } UPGRADE { name = SSTU-VCMod-SuperLightweight } UPGRADE { name = SSTU-VCMod-LowBoiloff } UPGRADE { name = SSTU-VCMod-ZeroBoiloff } UPGRADE { name__ = SSTU-VCMod-LightweightZeroBoiloff } } } MODULE { name = SSTUModularPart diameterIncrement = 0.625 minDiameter = 2.5 maxDiameter = 2.5 userAdapterVolume = true useAdapterMass = true useAdapterCost = true solarAnimationLayer = 1 noseAnimationLayer = 3 upperAnimationLayer = 5 coreAnimationLayer = 7 lowerAnimationLayer = 9 mountAnimationLayer = 11 upperRCSThrustTransform = rcsThrustTransform lowerRCSThrustTransform = rcsThrustTransform engineThrustTransform = engineThrustTransform topNodeName = top bottomNodeName = bottom noseManagedNodes = none upperManagedNodes = top1, top2, top3, top4 coreManagedNodes = none lowerManagedNodes = bottom1, bottom2, bottom3, bottom4 mountManagedNodes = none topInterstageNodeName = noseInterstage bottomInterstageNodeName = mountInterstage topFairingIndex = -1 bottomFairingIndex = -1 centralFairingIndex = -1 solarParentOptions = CORE upperRCSParentOptions = CORE lowerRCSParentOptions = CORE noseContainerIndex = 0 upperContainerIndex = 0 coreContainerIndex = -1 lowerContainerIndex = 0 mountContainerIndex = 0 currentDiameter = 2.5 currentVariant = Standard currentNose = Model-None currentUpper = Adapter-2-1-Dome currentCore = ST-COS-LONG currentLower = Adapter-2-1-Dome currentMount = Model-None currentSolar = Solar-None currentUpperRCS = RCS-None currentLowerRCS = RCS-None currentSolarLayout = Double-Sides currentUpperRCSLayout = DOS-Upper currentLowerRCSLayout = DOS-Lower currentNoseTexture = default currentUpperTexture = SSTU-Adapter-Silver currentCoreTexture = default currentLowerTexture = SSTU-Adapter-Silver currentMountTexture = default currentSolarTexture = default currentUpperRCSTexture = default currentLowerRCSTexture = default NOSE { model = Model-None } UPPER { model = Model-TankCap-Flat model = Adapter-1-1-VA model = Adapter-Airlock-2 model = Adapter-1-1-Hub model = Adapter-1-1-Hub-Ext model = Adapter-4-3-Flat model = Adapter-4-3-Short model = Adapter-4-3-Long model = Adapter-2-1-Flat model = Adapter-2-1-Dome model = Adapter-2-1-Short model = Adapter-2-1-Long model = Adapter-2-1-Hub model = Adapter-4-1-Flat model = Adapter-4-1-Short model = Adapter-4-1-Hub model = Adapter-1-2-Flat model = Adapter-1-2-Short model = Adapter-1-2-Long model = Adapter-2-3-Flat model = Adapter-2-3-Short model = Adapter-2-3-Long } CORE { variant = Standard model = ST-COS-XSHORT model = ST-COS-SHORT model = ST-COS-MEDIUM model = ST-COS-LONG } LOWER { model = Model-TankCap-Flat model = Adapter-1-1-VA model = Adapter-Airlock-2 model = Adapter-1-1-Hub model = Adapter-1-1-Hub-Ext model = Adapter-4-3-Flat model = Adapter-4-3-Short model = Adapter-4-3-Long model = Adapter-2-1-Flat model = Adapter-2-1-Dome model = Adapter-2-1-Short model = Adapter-2-1-Long model = Adapter-2-1-Hub model = Adapter-4-1-Flat model = Adapter-4-1-Short model = Adapter-4-1-Hub model = Adapter-1-2-Flat model = Adapter-1-2-Short model = Adapter-1-2-Long model = Adapter-2-3-Flat model = Adapter-2-3-Short model = Adapter-2-3-Long } MOUNT { model = Model-None } SOLAR { model = Solar-None layout = Double-Sides } UPPERRCS { model = RCS-None layout = DOS-Upper } LOWERRCS { model = RCS-None layout = DOS-Lower } } MODULE { name = SSTURecolorGUI } MODULE { name = ModuleB9PropagateCopyEvents } } } <

The part name does not show up in thr KSP.log file.

Here is the part file itself. JPL-COS-Storage.txt

shadowmage45 commented 5 years ago

Interesting -- I'll def. have to dig into this a bit and find out what is going on; likely something simple that we are missing. Been awhile since I've toyed with these configs, so likely have forgotten something small but important...

Jimbodiah commented 5 years ago

Same here, I think I am overlooking something. I'll tinker with the COS-HAB some more.

Jimbodiah commented 5 years ago

I just looked at unedited SSTU COS-HAB parts and although they show the UI for the VolumeContainer, all the units stay at zero no matter what you enter for the ratios.

The DOS parts seem to respond normally to ratios.