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

Shadowmage

Shadowmage

Posted
  • Author
Posted
Just now, Pointblank66 said:

Recently I have installed SSTU, though only the solar panels, and the other mods that came with the .ZIP file. What I noticed is that TU is conflicting with ProbesPlus. Is SSTU dependent on TU or can I remove that?

SSTU 100% depends on TU being installed.  Without TU installed the SSTU plugin won't even load.

AFAIK there should be no incompatibility between the two.... I thought Probes Plus was even using TU at some point? (more rhetorical than an actual question)

What exactly is the problem you are encountering? (description, log files, etc...)

Link to comment
Share on other sites
Pointblank66

Pointblank66

Posted
Posted (edited)

I also forwarded the problem to Akron, who manages ProbesPlus. This is what he said:

2 minutes ago, akron said:

Ok, TU takes over texture switching from Firespitter if installed. That's the cause, since the config syntax changed in TU at some point ago. I can only write configs for one version or the other, so I preferred to support the latest. I can provide you a test patch I have, or you can simply delete the TU configs which lets Firespitter take over again; but you'll lose the PBR shading on my parts.

So from what I understand is that he is using Firespitter instead of TU

And the problem I am getting is that it adds a slider?(same slideryou can change the amount of fuel in a tank) to select the texture for his parts instead of just only buttons. But since TU uses another syntax, and probably overrides Firespitter bc of that, it gives an error that says *Textures not found* and when I press one of the buttons it resets to default

Edited by Pointblank66
Link to comment
Share on other sites
Shadowmage

Shadowmage

Posted
  • Author
Posted
Just now, Pointblank66 said:

I also forwarded the problem to Akron, who manages ProbesPlus. This is what he said:

So from what I understand is that he is using Firespitter instead of TU

It sounds like the actual problem is that you are trying to use mods compiled for KSP 1.4+ in an older KSP 1.3 install?   What version of KSP are you using, and what versions of the impacted mods (TU, SSTU)?

As far as I know, if it is all setup properly (game version, mod versions), there should be no compatibility problems.  Install KSP 1.4.x; install the latest SSTU, which comes with the latest TU bundled; install the latest ProbesPlus; it should all 'just work' from there.

 

Link to comment
Share on other sites
Shadowmage

Shadowmage

Posted
  • Author
Posted
13 minutes ago, Pointblank66 said:

I have used the latest version ProbesPlus in the past with 1.3.1 and it worked fine. I just needed to use the dependencies that were patched for 1.3.1.

I'm gonna check on 1.4.x if that gives the same problem. I'll let you know what the results will be 

So, if I'm inferring things correctly -- you are running KSP 1.3.x, using SSTU the older SSTU + TU versions, but are using the latest versions of ProbesPlus?

If this is the case, it might be just a simple MM patch (or possibly manual edits) in order to fix the ProbesPlus-TU configs to load with the older version of TU (unless he is using newer features that weren't present in the older TU releases).  Something that could be investigated if you wanted to go that route.

Link to comment
Share on other sites
akron

akron

Posted
Posted

As I recall, Textures Unlimited changed syntax a while. I think the TEXTURE tag got renamed to MATERIAL or something relatively simple like that. Unfortunately once I changed the tags in my config to match the new usage, it broke any installs that use the previous one. I believe this is the issue he's having. A mismatch of TU version to my configs. One of the two is either too new. or too old. 

The way my texture/material switching works is that it is handled by Firespitter as long as you don't have TU installed. Once TU is detected, it handles it instead and all references of Firespitter are removed from the parts using: 

@PART[*]:HAS[#author[Akron]:HAS[@MODULE[FStextureSwitch2]]]:FOR[CoatlAerospace]:NEEDS[TexturesUnlimited]
{
	!MODULE[FStextureSwitch2] {}
}

This is a basic sample of a material configs used by v0.16 of my mod: 

KSP_TEXTURE_SET
{
	name = Silver
	title = Silver
	recolorable = false
	TEXTURE
	{
	shader = SSTU/PBR/Metallic
	texture = _MainTex, Coatl Aerospace/ProbesPlus/Assets/mat_fsilver
	texture = _BumpMap, Coatl Aerospace/ProbesPlus/Assets/mat_foil_N
	PROPERTY
	{
		name = _Metallic
		float = 250
	}
	PROPERTY
	{
		name = _Smoothness
		float = 0.7
	}
	}
	COLORS
	{
		mainColor = white
		secondColor = orange
		detailColor = white
	}
}

And this is one using the new syntax in v0.16.1: 

KSP_TEXTURE_SET
{
	name = Silver
	title = Silver
	recolorable = false
	MATERIAL
	{
	shader = SSTU/PBR/StockMetallicBumped
	texture = _MainTex, Coatl Aerospace/ProbesPlus/Assets/mat_fsilver
	texture = _MetallicGlossMap, Coatl Aerospace/ProbesPlus/Assets/mat_fsilver
	texture = _BumpMap, Coatl Aerospace/ProbesPlus/Assets/mat_foil_N

	PROPERTY
	{
		name = _Metal
		float = 1
	}
	PROPERTY
	{
		name = _Smoothness
		float = 0.9
	}
	}
}

@Pointblank66 Hopefully this helps you figure out exactly which version of TexturesUnlimited you need. If there is no version of TU using the new syntax available for KSP 1.3.1, you may have to use version 0.16 of my mod instead, or we can follow the other troubleshooting step I suggested back in my thread

Link to comment
Share on other sites
Shadowmage

Shadowmage

Posted
  • Author
Posted

@akron  Well said, and pretty much what I figured was going on.  As far as I can tell your patches and system for optional use of TU is set up properly.  Your input is appreciated :)

So not really a problem so much with anyones' mods or configs, but just another case of someone trying to stick with out-of-date KSP versions, but wanting to use newer mod versions.  Nothing you can do to fix that....

Link to comment
Share on other sites
RedParadize

RedParadize

Posted
Posted

Hi @Shadowmage

I finaly rebuild my SSTU MM patch for 6.4x. I am still a bit rusty but went pretty well. Sadly I do not use your latest SSTU as there is no version of kopernicus for 1.4.4. Stuck with 1.4.3 for now. Anyways, I have few questions regarding the inflatable parts: 

First off, their available volume do not seem to expand when inflated. I looked a bit into your code and from my poor understanding of it it does not seem to change/update the available volume. Is it a game limitation?

If I assume that its a game limitation or that it will be patched in 1.4.5. I would be ok with increase the HAB and CFG in both state. Is it possible to MM patch SSTU_MODEL? I tried this without great success:

@SSTU_MODEL[ST-HAB*,ST-CFG*]:AFTER[SSTU]
{
    @volume *= 2.0
}

Also, it might already have been fixed in the latest version but I noted that if there is no end cap to the hab and you try to edit the container it will trow infinite null error and container editor window will be a empty window that can't be closed.

Link to comment
Share on other sites
Shadowmage

Shadowmage

Posted
  • Author
Posted

@RedParadize Use the latest SSTU releases -- they will still work for any KSP 1.4.x version (might pop up a warning in AVC, but should work fine).  You are likely encountering a bug that was fixed in one of the more recent releases.

If you can confirm the issue still exists in the latest SSTU release, please let me know and I'll open a proper issue ticket for it.

Link to comment
Share on other sites
Shadowmage

Shadowmage

Posted
  • Author
Posted
7 minutes ago, RedParadize said:

@Shadowmage Null bug is still there, and inflation do not increase available volume, at least in editor.

Edit: give me a sec, I will test this without patch first...

Yes, please.  All appears to work fine in my tests --

Pre-inflate (note only 80EC)

L26Kzxk.png

Post-inflate (note 800 EC, no null-refs or errors in log)

mppWEcJ.png

Link to comment
Share on other sites
RedParadize

RedParadize

Posted
Posted

@Shadowmage Interesting, but usable volume of the container remained the same. So you can't store more resource in the configurable container when inflated.
 

I can confirm that the null spam is still there in the last version, even without my mm patch. To reproduce: Pick a Hab that have no cap, and click configure containers. 

Link to comment
Share on other sites
Shadowmage

Shadowmage

Posted
  • Author
Posted
Just now, RedParadize said:

I can confirm that the null spam is still there in the last version, even without my mm patch. To reproduce: Pick a Hab that have no cap, and click configure containers. 

Which hab has no caps?  (that is likely the error that needs to be solved first -- they MUST have caps, or things will go bad)

Would you mind posting/linking to a log file that contains the errors you are seeing?

Link to comment
Share on other sites
Shadowmage

Shadowmage

Posted
  • Author
Posted
6 minutes ago, RedParadize said:

@Shadowmage I mean Flat cap, like what ST-HAB-A1 have has default.

Give me two min for the log, forgot where they are...

Interesting -- can confirm the issue on parts with zero volume (doesn't actually have to do with the models/caps, rather that they have a volume = 0 defined in the model definition).  Changing even one of the caps to something with volume works-around the NREs.... but it shouldn't be doing that to begin with.

Have opened an issue ticket and will see about getting this one cleaned up for the next release ( https://github.com/shadowmage45/SSTULabs/issues/738 ).

Link to comment
Share on other sites
Shadowmage

Shadowmage

Posted
  • Author
Posted
1 minute ago, RedParadize said:

Now that we got this out of the way, what about the available volume for inflatable? 

What about it?

The 'volume' for the inflatable portion is defined in its model-definition (GameData/SSTU/Data/ModelData/ModelData-ST-HAB.cfg for example): 

SSTU_MODEL
{
	name = ST-HAB-A1
	modelName = ST-HAB-A1
	orientation = TOP
	height = 2.5
	diameter = 1.25
	mass = 1.05
	volume = 10
	cost = 2400
	upperProfile = cylinder
	upperProfile = uncapped
	compatibleUpperProfile = cylinder
	compatibleUpperProfile = uncapped
	compatibleUpperProfile = capped
	compatibleUpperProfile = inset
	lowerProfile = cylinder
	lowerProfile = uncapped
	compatibleLowerProfile = cylinder
	compatibleLowerProfile = uncapped
	compatibleLowerProfile = capped
	compatibleLowerProfile = inset
	SUBMODEL
	{
		modelName = SSTU/Assets/ST-HAB-INF-S
		position = 0, 0, 0
		rotation = 0, 0, 0
		scale = 0.5, 0.5, 0.5
	}
}

 

The volume/containers are then referenced in the part-config in both the VolumeContainer modules and ModularPart modules (note that on this part the 'main' container is set to only allow for EC, empty volume, and Ore in stock configuration, and it can ONLY be adjusted through the 'Configure Containers' GUI as the fuel-type slider is disabled).  THIS is the container that manipulation of the Model-Definition volume will adjust.

Note containers at index 1,2, etc all have 'useStaticVolue = true' and 'volume = XXXX' defined in them.  In order to manipulate the available volume for these containers, you must adjust that 'volume = XXXX' line through a patch. 


MODULE
{
	name = SSTUVolumeContainer
	//set the built in 'fuel type' slider to adjust container 0
	baseContainerIndex = 0
	//disable zeroing of mass and cost from this module; it is zeroed by ModularPart
	subtractMass = false
	subtractCost = false
	//enable the 'edit container' GUI option
	enableContainerEdit = true
	//disable the 'fuel type' slider
	enableFuelTypeChange = false
	//container index 0, general storage, manipulated by ModularPart for the volume of adapters
	//defaults to 'empty storage' resource
	CONTAINER
	{
		name = Storage
		tankageVolume = 0.15
		tankageMass = 0.15
		defaultModifier = standard
		modifier = standard
		defaultResources = SSTUEmptyVolume,1,1
		resource = SSTUEmptyVolume
		resource = Ore
		resource = ElectricCharge
		resourceSet = fuels
	}
	//container index 1, EC storage/battery compartment
	CONTAINER
	{
		name = Battery
		volume = 0075
		useStaticVolume = true
		tankageVolume = 0
		tankageMass = 0
		ecHasCost = false
		ecHasMass = false
		guiAvailable = false
		defaultModifier = standard
		modifier = standard
		defaultResources = ElectricCharge,100,1
		resource = ElectricCharge
	}
	//container index 2, RCS propellant
	CONTAINER
	{
		name = RCSPropellant
		volume = 0
		useStaticVolume = true
		tankageVolume = 0
		tankageMass = 0
		defaultModifier = standard
		modifier = standard
		defaultResources = NTO,1,1;Aerozine50,1,1
		resource = Aerozine50
		resource = NTO
		resource = MonoPropellant
	}
	//container index 3, engine propellant
	CONTAINER
	{
		name = Propellant
		volume = 0
		useStaticVolume = true
		tankageVolume = 0
		tankageMass = 0
		ecHasCost = false
		defaultModifier = standard
		modifier = standard
		defaultResources = NTO,1,1;Aerozine50,1,1
		resource = Aerozine50
		resource = NTO
	}	
	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
		}
	}
}

MODULE
{
	name = SSTUModularPart
    
    //standard module configuration values
	diameterIncrement = 0.625
	minDiameter = 1.25
	maxDiameter = 1.25
    userAdapterVolume = true
    useAdapterMass = true
    useAdapterCost = true
    
    //layers for use in the built-in animation handling -- ensures no conflicts between models
    solarAnimationLayer = 1
    noseAnimationLayer = 3
    upperAnimationLayer = 5
    coreAnimationLayer = 7
    lowerAnimationLayer = 9
    mountAnimationLayer = 11
    
    //upper-rcs-module will rename its thrust transforms to this name (should be the name specified in the ModuleRCS)
    upperRCSThrustTransform = rcsThrustTransform
    //lower-rcs-module will rename its thrust transforms to this name (should be the name specified in the ModuleRCS)
    lowerRCSThrustTransform = rcsThrustTransform
    //model-slot responsible for engine updating will rename its thrust transforms to this name (should be the name specified in the ModuleEngines)
    engineThrustTransform = engineThrustTransform
    
    //attach nodes that are manipulated by the various models
	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
    
    //which model slots may the solar panels be parented to?
    solarParentOptions = CORE
    //which model slots may the upper-rcs be parented to?
    upperRCSParentOptions = CORE
    //which model slots may the lower-rcs be parented to?
    lowerRCSParentOptions = CORE
	
	noseContainerIndex = 0
	upperContainerIndex = 0
	coreContainerIndex = -1
	lowerContainerIndex = 0
	mountContainerIndex = 0
    
    //--------------------------------------------------------------------------------------------------//
    //below here specifies starting/default values
    //these values -should- be populated in the config file if
    //you want to control what the default part looks like
    //if defaults are not specified, the first available/valid model + layout for each slot will be used.
    
    
    //initial starting diameter
    currentDiameter = 1.25
	
	//variants are listed in the CORE blocks below
	currentVariant = Standard
	
    //initial starting model selections 
	//(validation not enforced for config-specified values; it is possible to set an invalid configuration as defaults, which -may- cause problems later)
    currentNose = Model-None
    currentUpper = Model-TankCap-Flat
    currentCore = ST-HAB-A1
    currentLower = Model-TankCap-Flat
    currentMount = Model-None
	
	//RCS and solar module initial selections
	currentSolar = Solar-None
	currentUpperRCS = RCS-None
	currentLowerRCS = RCS-None
	
    //multi-model layout options for solar, RCS
    currentSolarLayout = Double-Sides
    currentUpperRCSLayout = HAB-Upper
    currentLowerRCSLayout = HAB-Lower
	
    //initial starting texture-set selections for the models listed above
	//'default' is an invalid set that triggers the actual default from the model to be loaded
    currentNoseTexture = default
    currentUpperTexture = default
    currentCoreTexture = default
    currentLowerTexture = default
    currentMountTexture = default
    currentSolarTexture = default
    currentUpperRCSTexture = default
    currentLowerRCSTexture = default
    
	//DOS have no nose model selections
    NOSE
    {
		model = Model-None
    }
	
    //DOS have multiple upper adapter selections
    UPPER
    {
		model = Model-TankCap-Flat
		model = Adapter-1-1-Hub
		model = Adapter-1-1-Hub-Ext
		model = Adapter-1-1-VA
		model = Adapter-2-1-Hub
		model = Adapter-2-1-Dome
		model = Adapter-2-1-Short
		model = Adapter-2-1-Long
		model = Adapter-2-3-Short
		model = Adapter-2-3-Long
		model = Adapter-1-2-Short
		model = Adapter-1-2-Long
		model = Adapter-1-3-Short
		model = Adapter-1-3-Long
    }
	
	//DOS have a single 'CORE' selection
	CORE
	{
        variant = Standard
        model = ST-HAB-A1
	}
    
    //all lower model selections; current valid selections determined by current core model
    LOWER
    {
		model = Model-TankCap-Flat
		model = Adapter-1-1-Hub
		model = Adapter-1-1-Hub-Ext
		model = Adapter-1-1-VA
		model = Adapter-2-1-Hub
		model = Adapter-2-1-Dome
		model = Adapter-2-1-Short
		model = Adapter-2-1-Long
		model = Adapter-2-3-Short
		model = Adapter-2-3-Long
		model = Adapter-1-2-Short
		model = Adapter-1-2-Long
		model = Adapter-1-3-Short
		model = Adapter-1-3-Long
    }
    
    MOUNT
    {
        model = Model-None
    }
	
	SOLAR
	{
		model = Solar-None
        layout = Double-Sides
	}
	
	UPPERRCS
	{
		model = RCS-None
        layout = HAB-Upper
	}
	
	LOWERRCS
	{
		model = RCS-None
        layout = HAB-Lower
	}
}
MODULE
{
	name = SSTUInflatable
	deflationMult = 0.1
	inflatedCrew = 2
	deflatedCrew = 0
	inflationMass = 0.621
	inflationCost = 372
	resourceName = RocketParts
	inflated = false
	ANIMATIONDATA
	{
		ANIMATION
		{
			name = ST-HAB-INF-S-Deploy
		}
	}
}

 

So, to adjust the 'user configurable' volume in the inflatable module -- patch the model definition.  To adjust the built-in battery/propellant containers, patch the CONTAINER blocks in the part-config.

Link to comment
Share on other sites
RedParadize

RedParadize

Posted
Posted

@Shadowmage

I am a bit confused by your answer. If you look at the two image you posted, while the battery change from 80 to 800. The usable volume did not. So if I get it right, to make the "Storage" container volume change according to inflation state, it need to have a specified volume in it? Like the battery?

Link to comment
Share on other sites
Shadowmage

Shadowmage

Posted
  • Author
Posted
1 minute ago, RedParadize said:

@Shadowmage

I am a bit confused by your answer. If you look at the two image you posted, while the battery change from 80 to 800. The usable volume did not. So if I get it right, to make the "Storage" container volume change according to inflation state, it need to have a specified volume in it? Like the battery?

The 'usable volume' displays the -deployed- stats.  Basically the volume container is setup as-per-normal, and when it goes to apply the resources to the part, it checks if it is inflated or not, and applies the multiplier only at that time.

 

These parts changed a bit in how they are (logically) set up.  The battery and propellant containers do NOT expand/shrink with deployment --  They are small enough that they can be seen as a permanent function of the part.  This was (at least in part) to allow for un-inflated modules to still be usable (battery/rcs/propellant).

The only portion of their volume that shrinks/expands is the 'user configurable' portion, and this container functions much like it did in the past -- the full volume is only available when the part is inflated.

 

With the GUI open, so you can see the values in the GUI do not change based on inflation status:

Pre-inflate:

mjFa4KL.png

Post-inflate -- notice no change in the 'usable volume', but there IS a change in the actual amount of EC in the part.

TEx8Pkq.png

 

As I stated in my post -- if you want to adjust the 'user configurable' volume of the part -- patch the 'volume = XXX' line in the model definition.  E.G.: 

@SSTU_MODEL[ST-HAB-A1]
{
	%volume = 100
}

 

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...