Shadowmage

Indeed -- a good one at that (really surprised that one hadn't been seen or reported before... is much more 'game breaking' than many of the others on the issues list). Really want to try and push out an update this weekend... just need people to stop dropping by with 'surprise' projects (both at work, and at home...). Ohh.. what I could do with a couple of free hours...

@RedParadize Here is a patch to adjust ST-HAB-B1 'user configurable' volume and enable deploy/retract based compression of resources: @SSTU_MODEL[ST-HAB-B1] { %volume = (specify desired user-configurable volume in cubic meters) } @PART[SSTU-ST-HAB-B1] { @MODULE[SSTUModularPart] { %coreContainerIndex = 0 } } Other HAB parts should be patchable in a similar fashion. The CFG parts are simpler, and only need the SSTU_MODEL patched to adjust the volume. Other specific outcomes should be just as easy to patch -- merely need to know exactly what you are trying to accomplish...

1.) It accepts input from either keyboard without issue (Windows 7/10 at least that I've tested). Fun times: Plug in a wireless keyboard receiver to your room-mates computer, wait til he starts typing a document or something on his normal keyboard, and then press some random keys on your (hidden away) wireless keyboard. Watch complete confusion ensue. 2.) Would likely work 'just fine' in KSP. I don't think Unity addresses keyboards individually -- it just grabs the key input state from the OS' IO layer. So if you had 1 keyboard plugged in, or 10, it wouldn't matter which one you pushed 'a' on, Unity/KSP would just see that 'a' was pressed. 3.) Still probably a complete PITA to do because of how most keyboards are designed (as others have stated). Perhaps a better starting point might be a slightly more expensive mechanical keyboard? I haven't looked into the guts of these, but I would think that they use a more standard wiring scheme instead of the crazy wire-matrix that the rubber-dome boards use (especially the ones with N-Key roll-over... would think that those keys are wired individually, but could be wrong).

From the HAB-B1 Config: MODULE { name = SSTUInflatable animationID = deploy deflationMult = 1 inflatedCrew = 10 deflatedCrew = 0 inflationMass = 1.9905 inflationCost = 1194 resourceName = RocketParts inflated = false ANIMATIONDATA { ANIMATION { name = ST-HAB-B1-Deploy } } } Note the line that says 'deflationMult = 1' -- this states that it has zero reduction in volume when deflated. So it appears to be working as the configs specify. (I may have changed the regular HABs around so as to not shrink volume; all of their 'inflation' volume is for living space, and their resource containers' physical volumes can fit into the non-deployed model with lots of room to spare) Edit: Also note in the part-config for that part, that the 'coreContainerIndex = -1' -- meaning volume updates from the 'core' model are disabled (it effectively has volume = 0). All 'user configurable volume' in that part comes from the volume in the adapters. Sorry, my previously posted example patch was likely in error -- it would work as intended on the CFG parts, but the HAB parts require a different setup. I guess I should ask -- what exactly are you trying to do? (e.g. what part names, what specific volume changes (from what, to what, on which resources), etc)

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: Post-inflate -- notice no change in the 'usable volume', but there IS a change in the actual amount of EC in the part. 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 }

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.

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

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?

Yes, please. All appears to work fine in my tests -- Pre-inflate (note only 80EC) Post-inflate (note 800 EC, no null-refs or errors in log)

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

Ahh, yep, that too

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

Thanks, have d/l the cfg, and will take a look at it in the next few days (likely over the weekend, is when I have most of my 'free' time). Most often these end up being small syntax errors, but there always exists the possibility of a bug in the mod. Will let you know what I find out.

Not entirely -- you make one texture, and use one shader for the entire model. The shaders are entirely capable of being used for the entire model as a single mesh -- as long as the textures are set up properly. All this nonsense about needing to have windows as separate meshes is only because nobody wanted to take the time to create the proper texturing. Finally, as this model doesn't have the windows already separated, your only way to get it to work properly for the PBR shaders will be to create and use new textures.

Would you mind posting your config / a link to it / PM'ing the information to me? Hard to diagnose config-level problems, without seeing the .cfg file

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.

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.

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

You can't (without potentially violating copyright and/or eula), as I already stated. But... also... you don't need to. Create the textures and apply them as I've outlined above, and you don't need to split the meshes off -- the textures take care of the per-mesh differences.

The texture you need to make is a _new_ texture -- cupola_Metallic.png (or .dds, whichever way you want to encode it). It needs to be a metallic mask, white in areas of metal, black in areas of non-metals (glass should be non-metal). Note that many of the stock models do not have proper specular/roughness/smoothness values for PBR use, so it may require additional work beyond just adding a metallic map. You then apply it to your part using a standard shader-replacement setup (patch provided below, fill in your texture name and it should 'just work') KSP_MODEL_SHADER { name = CupolaCustomMetallicMap model = Squad/Parts/Command/cupola/model MATERIAL { // this shader uses the ALPHA channel of the diffuse texture // for 'roughness'/'smoothness' input (which should already exist in the stock texture) // and the RED channel of the metallic-gloss-map for the metallic input value shader = SSTU/PBR/StockMetallicBumped // this points to your texture file, relative to the GameData folder; // e.g. if your texture is in GameData/MyMod/MyTexture.png // this line would be 'texture = _MetallicGlossMap, MyMod/MyTexture // note that the extension is NOT included in the path specification texture = _MetallicGlossMap, pathToYourTexture //any other PROPERTY blocks go here //... but if your texture is created properly you shouldn't need them.... } }

Thanks for the confirm. I guess I'll have to do some extended testing sessions to see if I can trigger the problem. Hopefully I'll get a few hours later this week to bash at it --- likely won't take long to fix the problem once I find where it is.

Your patch looks good, but you are overriding the texture.... with the same texture. Replace the line of : texture = _MainTex, Squad/Parts/Command/probeStackSphere/model000 with something that points to your custom (not black) texture. Alternatively, you could try sometihing like (delete that line and use this instead): 'textureColor = _MainTex,255,255,255,255' Which _should_ replace the MainTex slot with a full white default texture. (edit: not sure if this works in the 1.3.1 versions or not.... it was one of the newer features, don't remember when it was added) Yes it works, but you have mis-spelled it in your patch. You have ' SSTU/PBR/MetallicTransparen ' --- missing the 't' at the end ( ' SSTU/PBR/MetallicTransparent ') Have some patience, please. I work full time +, and have extremely limited time that I can devote to modding duties (that includes forum posts and helping others figure things out). I will try and write up an example patch for you later that will show you how to replace the metallic texture with one you have created (really though; you should be able to figure that out from the examples in SSTU).

Thanks for the confirmation; are there precise steps that reproduce the problem, or is it a bit more random? (So far I've been unable to reproduce the issue during testing, so have not been able to proceed any further with investigations; has been reported multiple times, so I have no doubt that there is a problem... I just haven't been able to see it yet)

You don't. You create custom textures in such a way that the mesh doesn't need to be separated. Rather than using unchanging specular and metallic values in the patch, you use the texture(s) to specify the value for each specific bit of the model. This allows for...well..... nearly infinite possibilities in how the model is textured/rendered, and is precisely how these shaders are intended to be used (the fact that nobody wants to create actual PBR textures... frustrates me to no end). Here is a sample of what one of those mask textures might look like (this is the MET texture for the Apollo Service module): https://github.com/shadowmage45/SSTULabs/blob/master/GameData/SSTU-PBR/Assets/SC-B-SM-MET.png Honestly, I would suggest -not- going this route if you don't already have texturing/modeling experience. Unless you are already familiar with texture work, and PBR shader use of those textures, you'll have at least a couple of weeks worth of hard learning to do before you would be able to do much productive work. Likely months/years more practice before that work might be called 'good'. However, if you -do- want to make your own textures -- let me know when you have a texture created, and I can help you figure out how to apply it to the model in KSP. I don't have the time, skills, or patience, to be teaching how to do texturing though. Sadly though, those are your only options in this case due to how the model was created. You can take the time to create custom textures to treat the windows separately, or you can use your existing patch as-is and use the model/textures as SQUAD provided.

Creating textures is done with programs like Photoshop, GIMP, Paint.net, windows paint, etc (or even Substance Painter). Find the UV map for the model you are working on, and create a metallic/specular mask texture for it. https://academy.allegorithmic.com/courses/b6377358ad36c444f45e2deaa0626e65 After you have your custom texture created, the mesh name to which it needs to be applied would seem to be 'obj_base'. (the meshrenderer/etc you are seeing are components that belong to the mesh objects in the model)