Shadowmage

Probably goes to show how old I am.... but how can you not know how to use a command-line option? (mostly kidding; I know that these days most people don't even know what a command prompt is, let alone how to use one) These are the unity docs on it: https://docs.unity3d.com/Manual/CommandLineArguments.html And how to use them in Steam (this page is tailored to Valve/Source-Engine games, but the methodology applies equally to any game) https://support.steampowered.com/kb_article.php?ref=1040-JWMT-2947 The important bits from the article above:

Glad you are getting some enjoyment out of the improved shaders What you propose would be the 'correct' way to add support for PBR shaders to the stock parts. To fully support the features of the new shaders, entirely new textures should be authored with proper values for all channels in use (albedo/diff, spec/smooth/rough, metallic, AO, NRM, and GLOW). Nice work on that conversion, looking good It is pretty amazing what the stock models can look like with modern texturing and shading.... Normal map / smoothing groups -- your output NRM might work fine. I've noticed that the blender .mu importer often loses the edge-split/smoothing groups, so they have to be recreated. As long as the recreated ones match the originals, the normal map should work on the stock model just fine. I have noticed that for stock textures, the existing DIFF and SPEC data can mostly be used as-is. It is really the MET data that needs to be created for stock parts (and many could benefit from a good NRM map as well). I actually have a shader written specifically for this setup, that takes the existing stock DIFF(RGB)/SPEC(A) textures and only requires the addition of a MET texture (with MET stored in the R channel of the texture).

Thanks for the log. That one makes a lot more sense (I have a feeling the first one you posted was quite out of date, as it was for KSP 1.3.x). Looks like the problem is that you are trying to use SSTU with KSP 1.4.3. SSTU does not currently support KSP 1.4+, and you will have to wait for a compatible version to be released.

Looks like you are missing the dependencies for SSTU, at least TexturesUnlimited is missing (which would cause all textures to fail to load). Try installing this release of TU (I think it was the last one for KSP 1.3 -- https://github.com/shadowmage45/TexturesUnlimited/releases/tag/1.0.0.8 ) Generally though you should have installed everything that was included in the SSTU release -- I made sure to include all of the dependencies, and they were all intended to be installed as they are required. Edit: That log actually doesn't even show SSTU as being installed. Are you sure you got the right log file? It should be the KSP.log file located in the same directory as the KSP executable (the file is named 'KSP.log').

Sounds like you have installed it incorrectly, likely that the dependencies are either missing incorrect versions. SSTU requires the following dependencies (all of a version appropriate for the KSP version you are using): ModuleManager CommunityResourcePack KSPWheel TexturesUnlimited If you could provide a link to a hosted copy of your KSP.log file (use dropbox or another file hosting site, paste the link here), I could likely tell you exactly what is missing or otherwise going wrong.

@Deltac Thanks for providing the examples, at least I can see specifically what you are looking at. If others are not using 64%, that is most likely the cause of the discrepancies. I believe the range of scales on my parts ranges from ~63% - ~66% depending on the engine, with most being very close to 64% As @Jimbodiah stated, such code already exists; shouldn't be more than a simple patch to change the engine scale (likely a single line; more complex if you also wanted to adjust mass/cost/thrust) (but you are entirely on your own if you choose to do so) Some quick measurements --- F1 - real diameter = 3.75m; SSTU's scaled diameter = 2.45m; scale = 65.33333% RS-25 - real diameter = 2.4m; SSTU's scaled diameter = 1.54m; scale = 64.166666666666666666666666666667% IDK... I would say that they are pretty consistently scaled... FYI - The stock F1 motor is modeled at that scale as they needed 5 engines to fit under a 5m fuel tank. A real 64% Saturn-V would have a 6.4m diameter S-IC, but stock likely did not want to add even larger fuel tanks. In SSTU it is entirely possible to have 6.4m tanks (or 6.25m), and the engines fit just fine when everything is done to the proper scale. Edit: I should also mention that SSTU is really intended to be played with most stock (and other mods') parts removed or disabled. Inconsistent scales can't bug you if they don't exist....

Please provide some images for demonstration -- what mods, what parts? Generally speaking SSTU's engines are 64% of the size of their real-world counterparts; most accurate down to a few cm if compared to the parameters/sources used for design. They are intended to be used in the stock system, which is most often specified that the 'kerbalized' parts are ~64% the size of human-scaled parts (thus the 64% scale applied to the engines). Other mods' engines may be done at a different scale, or based on different sources, or be an entirely different variant of a specific engine.

Thanks for the comments, and excellent question. The MFT part, using the MFT-A-2-0, at 2.5m diameter is a cylinder of diameter 2.5m and height of 5m. Would have a volume of 24.54 m3 (24540 liters) (pi * r^2 * h). So looks like the GUI is correct on the raw volume. Usable volume should be ~85% of that. Stock resources are defined in 5-liter 'units'. LH2 and other CRP resources are defined in 1-liter 'units'. So yes, there will be a 5x discrepancy if comparing by number of units alone; but the volume will be the same. Edit: Also note that LH2 is extremely 'light' when compared to LFO fuel -- it is far less dense, so you will need much more volume in order to get the same mass of propellant. If you compare these two screenshots, you can see that the 'usable volume' doesn't change depending on the resource selected. 20825 liters of usable volume, filled with LH2, = 1.475451t of propellant (1475.451 kg), which would give a density of: 0.070828331332533 kg/l or 70.828331332533 kg/m^3 (minor discrepancies likely due to floating-point rounding errors) Seems like it all checks out to me.... Edit: Looks like the error in your volume calculations are due to using 'diameter' rather than 'radius'. Diameter = 2x radius. Thus: Becomes:

KSP 1.4.4 The current plugin in the dev branch should work fine on KSP 1.4, 1.4.1, 1.4.2, 1.4.3, and the upcoming 1.4.4 (untested, but should work). I'm currently compiling against the KSP 1.4.2 libraries, so if you want the 'best' compatibility, I would say to use 1.4.2 or higher. (I'll update my KSP libraries to the most current version prior to the first public release; for now though, I'm just compiling with what I already have linked)

Yes, you could still do that. I was more referring to the fact that the 'ModuleEngines' can't be removed from the part once added. But yes, you could set the thrust + resources to zero, which would effectively disable it.

^^ This. There were some out of date dependencies in the dev branch. Also, as previously posted, keep all discussion of problems and issues regarding the 1.4 testing versions on Github. No further warnings will be issued, I'll just start ignoring people. I have enabled and use the github issue tracker for a reason, and it is not so that I can sort through pages of forum posts.... On a more positive note: The new plugin code has made it possible to add separation motors to the MFT-D (radial booster fuel tank). The only limitation would be that if it were added to the part, it would always be present on the part -- it could not be disabled in the editor, and would have to be patched/edited out of the part to be removed. What kind of interest is there in having this feature added?

Your normal maps seem to represent two formats, both of which are 'correct' depending upon the texture file format and data encoding. Left = the encoding that should be used for DDS (DXT5_NM), and is known as 'swizzled'; this format should only be used (afaik) on DDS textures, encoding a PNG like that would be wrong. If this is the output you are getting from PartTools...something is obviously wrong (it should only encode them like that for DDS) Right = standard normal map format, and the expected format for .png textures. (likely not much help to solve the problem, but hopefully some useful information).

Thanks. No rush, whenever you have time. Should also mention that I'll be updating the dev branch regularly (likely several times per day), so it would be best to keep an eye on the commit log to be apprised of changes and fixes ( https://github.com/shadowmage45/SSTULabs/commits/dev ). Just use the same link as posted above to grab the updated version (it always points to the most recent .zip of the dev branch).

Much work over the weekend on finishing up the rest of the plugin features and updating configs. I think at this point it is about as ready for initial testing as it will ever be. Undoubtedly there are still a few things that got missed, are unfinished, or are actual bugs. So, for anyone interested in helping to do testing on the 1.4 versions, you may find it all here: https://github.com/shadowmage45/SSTULabs/archive/dev.zip The above link should be a zipped up copy of the entire dev repository. You should install only the contents of the GameData/ folder, minus the Optional Patches and Texture Sets folders. I will not be packing up actual releases until this initial testing period is done and most of the bugs/issues have been resolved. I anticipate that at least a couple of weeks worth of testing and cleanup will be needed. In regards to submitting bug reports -- keep them all on the Github issues tracker, preferably in one of the existing issues. Please take a look at the existing issue tickets before posting about a problem and make sure it hasn't already been reported. For most part-related problems, you will also need to include at least the last few hundred lines of your KSP.log file. Any 'bug reports' for 1.4+ versions posted here on the forums will result in me adding you to my forum ignore list, without further warning or response. This is your warning, single and only...be responsible and respectful, or there will be no further releases (dev or otherwise).

You can likely use MM to patch the 'current' or 'default' variant as specified in the part config. When doing it this way, it should be 'permanent'.