Jump to content

[WIP][1.8.x] SSTULabs - Low Part Count Solutions (Orbiters, Landers, Lifters) - Dev Thread [11-18-18]

Shadowmage

By Shadowmage
in KSP1 Mod Development

 Share

Recommended Posts

drhay53

drhay53

Posted
Posted (edited)

@Shadowmage @Jimbodiah

I'm trying to put together a set of MM patches that add the SSTUVolumeContainer to KPBS tanks. I worked on it for a couple hours last night and a bit more today. The MM config below is intended to add the configurable tank to the K&K T400 Fuel Container. However, the Configure Containers GUI comes up totally empty and the FuelType slider doesn't do anything (https://imgur.com/a/0yYJgvG). Can you see easily what I'm doing wrong? 

@PART[KKAOSS_Rocket_Fuel_Tank]:NEEDS[PlanetaryBaseInc]:AFTER[PlanetaryBaseInc]
{
    -RESOURCE,* { }
	MODULE
	 {
        name = SSTUVolumeContainer
        volume = 5.4868
        enableContainerEdit = true
        enableFuelTypeChange = true
        subtractMass = false
        subtractCost = false
        baseContainerIndex = 0
        CONTAINER
        {
            name = Main Tank
            //default placeholder volume; set by MFT module below
            tankageVolume = 0
            tankageMass = 0
            defaultModifier = standard
            defaultFuelPreset = LFO,1
            resource = LiquidFuel
            resource = LqdHydrogen
            resource = Oxidizer
            resource = MonoPropellant
            resource = Aerozine50
            resource = NTO
            resource = ElectricCharge
            resource = RocketParts
            resource = XenonGas
            resource = Ore
            modifier = standard
        }
    }
}

 

Edited by drhay53
Link to comment
Share on other sites
Shadowmage

Shadowmage

Posted
  • Author
Posted (edited)
54 minutes ago, drhay53 said:

@Shadowmage @Jimbodiah

I'm trying to put together a set of MM patches that add the SSTUVolumeContainer to KPBS tanks. I worked on it for a couple hours last night and a bit more today. The MM config below is intended to add the configurable tank to the K&K T400 Fuel Container. However, the Configure Containers GUI comes up totally empty and the FuelType slider doesn't do anything (https://imgur.com/a/0yYJgvG). Can you see easily what I'm doing wrong?

 

In the recent versions, the place where volume is specified has moved to the CONTAINER block.  So rather than specifying a 'percent' in the container, you merely specify the volume.  This was done specifically to allow for easier adding of life-support supplies to parts by dynamic patches, and also simplifies a bit of the math when setting up more complex parts with multiple specific-use containers.

Have adjusted your config to the new syntax, so the below config should work for you...

Note -- I also changed the 'defaultFuelPreset' to remove the ',1' --- the fuel preset does not include a ratio, and it will likely crash when attempting to load the preset with the ',1' present. 

@PART[KKAOSS_Rocket_Fuel_Tank]:NEEDS[PlanetaryBaseInc]:AFTER[PlanetaryBaseInc]
{
    -RESOURCE,* { }
	MODULE
	 {
        name = SSTUVolumeContainer
        enableContainerEdit = true
        enableFuelTypeChange = true
        subtractMass = false
        subtractCost = false
        baseContainerIndex = 0
        CONTAINER
        {
            name = Main Tank
			volume = 5.4868
            tankageVolume = 0
            tankageMass = 0
            defaultModifier = standard
            defaultFuelPreset = LFO
            resource = LiquidFuel
            resource = LqdHydrogen
            resource = Oxidizer
            resource = MonoPropellant
            resource = Aerozine50
            resource = NTO
            resource = ElectricCharge
            resource = RocketParts
            resource = XenonGas
            resource = Ore
            modifier = standard
        }
    }
}

 

Edited by Shadowmage
Link to comment
Share on other sites
drhay53

drhay53

Posted
Posted

@Shadowmage I actually first tried the Volume in the Container object, because I started working directly off of the MFT-A config, just trying to plug in the SSTUVolumeContainer stuff into the patch;  in that case the SSTU stuff doesn't show up in the right click menu at all (in fact, moving the Volume to Container and removing the default resources, this part now does nothing at all when I right-click on it).

Only things I see in the log that seem relevant at all, are innocuous: 

[LOG 20:02:10.737] Config(@PART[KKAOSS_Rocket_Fuel_Tank]:NEEDS[PlanetaryBaseInc]:AFTER[PlanetaryBaseInc]) /kpbs_patch/@PART[KKAOSS_Rocket_Fuel_Tank]:NEEDS[PlanetaryBaseInc]:AFTER[PlanetaryBaseInc]
[LOG 20:02:11.802] [ModuleManager] Applying update /kpbs_patch/@PART[KKAOSS_Rocket_Fuel_Tank] to PlanetaryBaseInc/ContainerSystem/tank_rocketFuel/PART

 

Link to comment
Share on other sites
Shadowmage

Shadowmage

Posted
  • Author
Posted
14 hours ago, drhay53 said:

@Shadowmage I actually first tried the Volume in the Container object, because I started working directly off of the MFT-A config, just trying to plug in the SSTUVolumeContainer stuff into the patch;  in that case the SSTU stuff doesn't show up in the right click menu at all (in fact, moving the Volume to Container and removing the default resources, this part now does nothing at all when I right-click on it).

Only things I see in the log that seem relevant at all, are innocuous: 


[LOG 20:02:10.737] Config(@PART[KKAOSS_Rocket_Fuel_Tank]:NEEDS[PlanetaryBaseInc]:AFTER[PlanetaryBaseInc]) /kpbs_patch/@PART[KKAOSS_Rocket_Fuel_Tank]:NEEDS[PlanetaryBaseInc]:AFTER[PlanetaryBaseInc]
[LOG 20:02:11.802] [ModuleManager] Applying update /kpbs_patch/@PART[KKAOSS_Rocket_Fuel_Tank] to PlanetaryBaseInc/ContainerSystem/tank_rocketFuel/PART

 

Try opening up your ModuleManagerCache file (its a giant text file), and finding the section for that part.  It will show what the part config looks like after patching -- so you can check to make sure everything was patched correctly.

Are you seeing any errors in the log when that part is being compiled, or when the part is selected in the editor?

32 minutes ago, RedParadize said:

@Shadowmage You know the ticket that have been openend about part reseting on spawn? Just wanted to say I have it too. It seem to happen very often with the common bulkhead/split tank setting. 

Yeah -- someone finally provided instructions to repro the issue, so I can finally start trying to find it and fix it :)   Should have it fixed for the next release.

Link to comment
Share on other sites
Shadowmage

Shadowmage

Posted
  • Author
Posted

It would appear that the 'losing settings' bug was being caused (at least in part) by the 'variant' UI control.  This control doesn't map to any actual data structures, but was being populated dynamically at runtime based on what the user had selected.  Its value was non-persistent, and was supposed to be restored upon loading by filling it with the value of the currently selected core.

Unfortunately, during (re)loading of a part, the value of this field was being used to determine the 'available' models for each model slot.  Further validation code would 'fix' the problems of the currently selected model not being 'currently valid' for the selected variant, and would thus reset things to the defaults for the default variant.

After marking that field as persistent, I am now able to successfully re-load craft that were previously exhibiting problems, and am no longer able to reproduce the issue.  I am going to continue investigating/testing, as IIRC there was a reason why that field was not persistent... but perhaps it just was forgotten about during module setup.

 

Link to comment
Share on other sites
drhay53

drhay53

Posted
Posted (edited)
8 hours ago, Shadowmage said:

Try opening up your ModuleManagerCache file (its a giant text file), and finding the section for that part.  It will show what the part config looks like after patching -- so you can check to make sure everything was patched correctly.

Are you seeing any errors in the log when that part is being compiled, or when the part is selected in the editor?

There's nothing in the log. A couple of simple info messages from MM saying the patch was applied and a message saying the part was compiled. No Errors. Nothing when the part is pulled out of the editor.

The part in the MM Cache looks fine I think? 

UrlConfig
{
	name = KKAOSS_Rocket_Fuel_Tank
	type = PART
	parentUrl = PlanetaryBaseInc/ContainerSystem/tank_rocketFuel
	PART
	{
		name = KKAOSS_Rocket_Fuel_Tank
		module = Part
		author = Nils277
		scale = 1
		rescaleFactor = 1
		CoMOffset = -0.45, -0.45, 0.0
		node_stack_top = 0, 0, 0, 1, 0, 0, 1
		TechRequired = fuelSystems
		entryCost = 4000
		cost = 550
		category = FuelTank
		subcategory = 0
		title = K&K T400 Fuel Container
		manufacturer = K&K Advanced Orbit and Surface Structures
		description = The big brother of the "K&K T200 Fuel Container". It also is not really accepted by the engineers because of its unusual shape, although they say it has more "BOOM" than it's little brother.
		attachRules = 1,0,1,1,0
		mass = 0.05
		dragModelType = default
		maximum_drag = 0.2
		minimum_drag = 0.2
		angularDrag = 2
		crashTolerance = 15
		maxTemp = 2000
		tags = fueltank ?lfo liquid oxidizer propellant rocket planetary base container
		MODEL
		{
			model = PlanetaryBaseInc/ContainerSystem/tank_rocketFuel
		}
		MODULE
		{
			name = SSTUVolumeContainer
			enableContainerEdit = true
			enableFuelTypeChange = true
			subtractMass = false
			subtractCost = false
			baseContainerIndex = 0
			CONTAINER
			{
				name = Main Tank
				tankageVolume = 0
				tankageMass = 0
				volume = 5.4868
				defaultModifier = standard
				defaultFuelPreset = LFO
				resource = LiquidFuel
				resource = LqdHydrogen
				resource = Oxidizer
				resource = MonoPropellant
				resource = Aerozine50
				resource = NTO
				resource = ElectricCharge
				resource = RocketParts
				resource = XenonGas
				resource = Ore
				modifier = standard
			}
		}
	}
}

I don't know. Maybe I'll have to use another addon to apply switchable configs. My main save will have configurable containers by Allista in the addon list (this test save does not), but the configs look much harder to update IMO. And B9 would require a whole new mod installation which I wanted to avoid. I just thought using the SSTU module looked like the easiest MM patch.

Edited by drhay53
Link to comment
Share on other sites
Shadowmage

Shadowmage

Posted
  • Author
Posted
15 minutes ago, drhay53 said:

There's nothing in the log. A couple of simple info messages from MM saying the patch was applied and a message saying the part was compiled. No Errors. Nothing when the part is pulled out of the editor.

The part in the MM Cache looks fine I think?

I don't know. Maybe I'll have to use another addon to apply switchable configs. My main save will have configurable containers by Allista in the addon list (this test save does not), but the configs look much harder to update IMO. And B9 would require a whole new mod installation which I wanted to avoid. I just thought using the SSTU module looked like the easiest MM patch.

After comparing your config versus the setups that I've used on the SC-A/B/etc parts, it looks like one important line is missing from the CONTAINER definition that I unfortunately did not spot before: 

useStaticVolume = true

That line tells the VolumeContainer that the volume specified will not change for that CONTAINER block -- otherwise it expects volume updates to come from an external module (e.g. ModularPart, ModularHeatShield, etc).

Also note that the volumes specified in VolumeContainer are in liters and not m^3; as such I applied a 1000x multiplier to the volume you had originally specified.

The below patch has been tested to work: 

@PART[KKAOSS_Rocket_Fuel_Tank]:NEEDS[PlanetaryBaseInc]:AFTER[PlanetaryBaseInc]
{
    -RESOURCE,* { }
	MODULE
	{
		name = SSTUVolumeContainer
		enableContainerEdit = true
		enableFuelTypeChange = true
		subtractMass = false
		subtractCost = false
		baseContainerIndex = 0
		CONTAINER
		{
			name = Main Tank
			volume = 5486.8
			useStaticVolume = true
			tankageVolume = 0
			tankageMass = 0
			defaultModifier = standard
			defaultFuelPreset = LFO
			resource = LiquidFuel
			resource = LqdHydrogen
			resource = Oxidizer
			resource = MonoPropellant
			resource = Aerozine50
			resource = NTO
			resource = ElectricCharge
			resource = RocketParts
			resource = XenonGas
			resource = Ore
			modifier = standard
		}
	}
}

Proof:

g6YawY7.png

 

Link to comment
Share on other sites
drhay53

drhay53

Posted
Posted

@Shadowmage Sincere thanks for spending your valuable time helping debug my messed up MM patch. Sorry that it was a simple miss. I confirm it's working now.

There's more LFO in the part than there is without SSTU, so now I've got to figure out conversion rates for all of the parts and whatnot to keep the intended balance. But I'll figure that out now that it works. Thanks again!

Link to comment
Share on other sites
Shadowmage

Shadowmage

Posted
  • Author
Posted
16 minutes ago, drhay53 said:

There's more LFO in the part than there is without SSTU,

1.) Take the original part;
2.) sum the LF + O units. 
3.) Multiply by 5. (stock LF/O is 5 liters per unit)
4.) Put that value as the 'volume'  (as SSTU uses liters)
5.) Profit?!?

If that does not work, let me know and I can take a look at the existing original part config and see where the differences may come from.

Link to comment
Share on other sites
drhay53

drhay53

Posted
Posted (edited)
59 minutes ago, Shadowmage said:

1.) Take the original part;
2.) sum the LF + O units. 
3.) Multiply by 5. (stock LF/O is 5 liters per unit)
4.) Put that value as the 'volume'  (as SSTU uses liters)
5.) Profit?!?

If that does not work, let me know and I can take a look at the existing original part config and see where the differences may come from.

Yeah, I figured out the ratio by looking at the volume and units in the SSTU GUI.

I went a step further though and used the MM arithmetic; I need to change a fair number of parts and some of them will have different multipliers (edit: guess pretty much everything has a multiplier of 5?) so I didn't want to have to write everything down and calculate it somewhere else!

Here's what it looks like (this version confirmed working): 

MMCONFIG
{
    vol_liter_per_LFO_unit = 5.0
}
@PART[KKAOSS_Rocket_Fuel_Tank]:NEEDS[PlanetaryBaseInc]:AFTER[PlanetaryBaseInc]
{

	MODULE
	{
		name = SSTUVolumeContainer
		enableContainerEdit = true
		enableFuelTypeChange = true
		subtractMass = false
		subtractCost = false
		baseContainerIndex = 0
		CONTAINER
		{
			name = Main Tank
			conversion = #$@MMCONFIG/vol_liter_per_LFO_unit$
			LF = 0
			OX = 0
			@LF += #$../../RESOURCE[LiquidFuel]/amount$
			@OX += #$../../RESOURCE[Oxidizer]/amount$
			@LF *= #$conversion$
			@OX *= #$conversion$
			volume = 0
			@volume += #$LF$
			@volume += #$OX$
			-conversion = DELETE
			-LF = DELETE
			-OX = DELETE
			useStaticVolume = true
			tankageVolume = 0
			tankageMass = 0
			defaultModifier = standard
			defaultFuelPreset = LFO
			resource = LiquidFuel
			resource = LqdHydrogen
			resource = Oxidizer
			resource = MonoPropellant
			resource = Aerozine50
			resource = NTO
			resource = ElectricCharge
			resource = RocketParts
			resource = XenonGas
			resource = Ore
			modifier = standard
		}
	}

	-RESOURCE,* { }
}

 

Edited by drhay53
Link to comment
Share on other sites
Shadowmage

Shadowmage

Posted
  • Author
Posted
10 hours ago, Insanity_BK said:

Can anyone help me? I get very long loading times when i have the mod installed... why? 

I get stuck on this part for a very long time:

Image, https://www.dropbox.com/s/9zrphg9wjg4pi4t/20180928234202_1.jpg?dl=0

Can anyone help me?

 

2 hours ago, Insanity_BK said:

https://www.dropbox.com/s/d2vak5zo3sxn2ia/KSP.log?dl=0 here u go!

Thank you for providing the log file and screenshot.  The more info I have the better the chance I can track down whatever is going on...

 

For some reason TexturesUnlimited is not loading for you -- which is what is used to load that particular model.  From your log: 


[EXC 23:38:58.524] TypeLoadException: Could not load type 'KSPShaderTools.TexturesUnlimitedLoader' from assembly 'SSTUTools'.

[EXC 23:38:58.525] TypeLoadException: Could not load type 'KSPShaderTools.TexturesUnlimitedLoader' from assembly 'SSTUTools'.

[WRN 23:38:58.544] File 'D:/Steam/steamapps/common/Kerbal Space Program/KSP_x64_Data/../GameData/001_ToolbarControl/PluginData/Debug.cfg' does not exist

 

Caused by using an apparently incompatible version that is for KSP 1.3.1 (also from the log): 

[LOG 23:39:00.980] KSP-AVC -> D:\Steam\steamapps\common\Kerbal Space Program\GameData\000_TexturesUnlimited\TexturesUnlimited.version
	NAME: TexturesUnlimited
	URL: http://ksp-avc.cybutek.net/version.php?id=532
	DOWNLOAD: https://github.com/shadowmage45/TexturesUnlimited/releases/tag/1.0.0.8
	GITHUB: NULL
	VERSION: 1.0.0.8
	KSP_VERSION: 1.3.1
	KSP_VERSION_MIN: 1.3
	KSP_VERSION_MAX: 1.3.1
	CompatibleKspVersion: False
	CompatibleKspVersionMin: True
	CompatibleKspVersionMax: False
	CompatibleGitHubVersion: True

 

 

TLDR:  Update your TU version to the latest.  And KSPWHeel.  And CRP.  And SSTU.  They are all the 1.3.1 versions which absolutlely will not work with KSP 1.4.5.  You can get them all from the SSTU Github --  https://github.com/shadowmage45/SSTULabs/releases  Although I might recommend until waiting until I post today/tomorrows release, as it fixes a fairly major bug in the current versions.

In fact -- you have a ton of outdated mods in your install, many that I know have updated versions.  Might want to do a full mod audit and remove or update any that are still old versions.

Link to comment
Share on other sites
Insanity_BK

Insanity_BK

Posted
Posted
24 minutes ago, Shadowmage said:

 

Thank you for providing the log file and screenshot.  The more info I have the better the chance I can track down whatever is going on...

 

For some reason TexturesUnlimited is not loading for you -- which is what is used to load that particular model.  From your log: 



[EXC 23:38:58.524] TypeLoadException: Could not load type 'KSPShaderTools.TexturesUnlimitedLoader' from assembly 'SSTUTools'.

[EXC 23:38:58.525] TypeLoadException: Could not load type 'KSPShaderTools.TexturesUnlimitedLoader' from assembly 'SSTUTools'.

[WRN 23:38:58.544] File 'D:/Steam/steamapps/common/Kerbal Space Program/KSP_x64_Data/../GameData/001_ToolbarControl/PluginData/Debug.cfg' does not exist

 

Caused by using an apparently incompatible version that is for KSP 1.3.1 (also from the log): 


[LOG 23:39:00.980] KSP-AVC -> D:\Steam\steamapps\common\Kerbal Space Program\GameData\000_TexturesUnlimited\TexturesUnlimited.version
	NAME: TexturesUnlimited
	URL: http://ksp-avc.cybutek.net/version.php?id=532
	DOWNLOAD: https://github.com/shadowmage45/TexturesUnlimited/releases/tag/1.0.0.8
	GITHUB: NULL
	VERSION: 1.0.0.8
	KSP_VERSION: 1.3.1
	KSP_VERSION_MIN: 1.3
	KSP_VERSION_MAX: 1.3.1
	CompatibleKspVersion: False
	CompatibleKspVersionMin: True
	CompatibleKspVersionMax: False
	CompatibleGitHubVersion: True

 

 

TLDR:  Update your TU version to the latest.  And KSPWHeel.  And CRP.  And SSTU.  They are all the 1.3.1 versions which absolutlely will not work with KSP 1.4.5.  You can get them all from the SSTU Github --  https://github.com/shadowmage45/SSTULabs/releases  Although I might recommend until waiting until I post today/tomorrows release, as it fixes a fairly major bug in the current versions.

In fact -- you have a ton of outdated mods in your install, many that I know have updated versions.  Might want to do a full mod audit and remove or update any that are still old versions.

Its working now thanks!!!

Link to comment
Share on other sites
Shadowmage

Shadowmage

Posted
  • Author
Posted (edited)

Updated release is available:

https://github.com/shadowmage45/SSTULabs/releases/tag/0.8.43.155

Fixes up the major 'tanks losing settings bug', as well as a few other minor fixes and updates.  See link for change-log and download links.

 

With this release I feel the mod is about where it should be for a 'KSP 1.4.x Stable' release; just took a few extra months to get there....   I'm sure there are still bugs and balance issues that will need to be addressed, but all of the major game-breaking bugs that have been reported have been fixed and it should be generally 'usable'.

My plans over the next few months will be to continue the clean up effort across all of my mods, and continue with general maintenance and upkeep.  While I don't have any plans to start into new part development in the near future, I would certainly like to take advantage of the new modular part features that I spent so long working on.  Probe bus systems, modular service modules, more cargo bays and structural parts -- tons of unexplored concepts.

On the list for cleanup is (in no particular order):

  • Kerbal Foundries Models -- find/fix the Unity Project files so that I can actually re-export these models with updated names/settings/scales/etc.  For some I do have Unity files from older versions, others will require importing the .mu models into Blender and re-rigging.
  • Clean up of Textures Unlimited shader setup -- consolidation of shaders into fewer variants that use keyword driven feature setup.
  • Kerbal Foundries PBR Pass -- once I get the model files sorted out, I'll be able to rip these through SP for some tasty new textures.  Chrome hubcaps ftw..  (optional add-on download to activate PBR)
  • KSPWheel Conversion Patches -- set of patches for stock and other mods' wheels to convert them to use KSPWheel.
  • SSTU PBR Conversion -- Drop legacy shader support.  Create default PBR textures for all non-recolorable parts.  Aim for a more unified texture scale and color scheme across parts.
  • SSTU Tanks/textures update -- I had done some initial work on a texturing scheme for tanks that allowed for better patterning and texture re-use, but still had a lot of 'work' to do on it.

 

Edited by Shadowmage
Link to comment
Share on other sites
Shadowmage

Shadowmage

Posted
  • Author
Posted
13 hours ago, Electrocutor said:

Does that mean you think the 1.4.5 version will be going full release or still waiting on that?

At this point I think the distinction is in name and forum location only.  Calling it a 'full release' won't change any of the gaps in the mod, but giving it another ~6mo+ for further development isn't going to change much either.  I have a pretty good handle on what will or will not be breaking changes, and have been practicing the 'breaking changes only during major KSP version updates' for awhile now.

So.... perhaps?  Really wouldn't change too much.  With KSP 1.5 coming out later this month, seems like that might be a good time to make the move -- would give some time for additional balance updates and cleanup, and possibly to start getting some craft files/etc created.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
 Share
Go to topic listing
×
×
  • Create New...