Shadowmage
-
Posts
4,628 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Everything posted by Shadowmage
-
Judging by the model hierarchy in the screenshot (thanks for posting that!), there is nothing you can do. SQUAD did not make the windows as separate meshes, so they cannot be excluded from a patch in that fashion. So this is not an error in your patch, nor is it a problem with TU; the problem is that the model was not built in an optimal fashion for this sort of operation. About the only thing you could do would be to create custom textures for it.
-
Using 'DebugStuff' -- https://forum.kerbalspaceprogram.com/index.php?/topic/135726-1x-debugstuff-2018-03-13-see-the-hidden-secrets-of-the-game-objects/ It will allow you to 'dump to log' the model hierarchy of any part model. This will list the mesh names for every object within the model. IIRC you need to press 'CTRL+P' to activate it in the VAB/SPH, and then press/hold left-shift while the mouse is over a model to bring up the window showing the hierarchy for that model. The window should have a button to 'dump to log'; from there you can copy/paste the model hierarchy out of the log file. There may be other tools available that do the same similar from in-game (I remember something from LGG awhile back). You can also use the Blender .mu import tool to import the models to Blender and get the hierarchy from there. As it is a stock model you are having problems with, if you can't otherwise find the information, let me know and I'll see what I can do.
-
Your second block is TEXTURE. Try changing it to MATERIAL like the first block. The 'excludeMesh' feature -does- work. Can you show a printout of the model-hierarchy for the models you are having problems with? (what are the mesh names in those models?)
-
Thanks, will try to take a look at this problem sometime this week/end. IIRC, there was a difference between my shaders and the stock shaders, in that the TU shader expected the emissive textures' alpha channel to be > 0, and the stock shader ignores it. Thusly, the stock textures have emissive.alpha = 0, and the glow doesn't work when used with TU shaders. Can't say for certain that is the problem that is being encountered... but it would explain exactly what you are seeing, and why it still works in other parts (or even on only some meshes in some parts).
-
Would you mind posting up the relevant information in either the TU thread or in an issue ticket on the TU repository? (at the very least, a copy of the patches/configs for the problematic parts) It _should_ be possible to maintain emissive window meshes... but I'll have to take a look at the specific part models to see how they are setup (singular mesh for whole model, or windows as separate meshes), as well as poke at the stock light-emissive animation module as well (it might expect stock shaders, which would obviously not work if the shaders have been changed).
-
This is a bug I reported back in... 1.2.x Was never acknowledged, certainly never fixed. From what I can tell of the KSP API, it is actually an intentional choice -- only a single 'collider' object will trigger part explosions on any given part. As service bays have separate collider objects for the top/bottom, and each door (x4), only one of those colliders will trigger explosions (hint: its not one of the door colliders). All stock parts that have > 1 collider in the model also suffer from this same bug (cupola, mk3 cockpit, cargo bays, others), but it is most easily observed in the service bays and cargo bays (both have invincible doors).
-
Recovering crashed HDD = ugghghhhghh (at least it was just a games-ISO archive and nothing critical)
-
-
True dat.... nothing I can do to recover those.
HDDs just get a trip to the freezer, and then into the diagnostics cradle we have at work.... they usually spin up long enough to extract data. Usually.
This one did, thankfully, so no data lost. Just a pointed reminder that some of my drives are getting old (that one was 10 years!), and are due for replacement (and better backups...).
-
-
Updated release is available: https://github.com/shadowmage45/SSTULabs/releases/tag/0.8.43.153 Fixes for a few outstanding issues, mostly related to SRB and MUS parts. Hopefully the next update will only be a week or two out, and should fix up most of the remaining outstanding issues.
-
No -- it warns you when you are using an API that is known to no work with the mod. Disabling the warning would serve no purpose; the mod still wouldn't work properly, you would just have one less pop up. Why not just uninstall the mod completely if you are not interested in using it (and gain some speed in your game startup while you are at it)?
-
The 'SSTU Reflection Probe' is added by TexturesUnlimited ( https://forum.kerbalspaceprogram.com/index.php?/topic/167450-143-textures-unlimited-pbr-shader-texture-and-model-api/ ) -- please report your problem in that thread, or on its github issues page ( https://github.com/shadowmage45/TexturesUnlimited/issues ), along with a link to an upload of your KSP.log file (instructions on how to find the log should be here -- https://forum.kerbalspaceprogram.com/index.php?/topic/83212-how-to-get-support-read-first/ ).
-
Thanks for the report, and confirmation. I've opened an issue ticket regarding the problem here: https://github.com/shadowmage45/SSTULabs/issues/730 Please feel free to add any other relevant information to that ticket -- log files, steps to reproduce, etc. Will try to confirm if it exists in an otherwise clean setup, and if so, should be able to have it fixed for the next release (hopefully 'soon'). In general development news: Nearing completion on a major project at work and, barring some crazy management decisions, hopefully my schedule will be easing up in the next few weeks. If it all works out I should be able to devote more time and brainpower to finishing up the outstanding 'rework' conversions, and maybe get back to actual development work on the list of planned parts. I intend on releasing a bug-fix release that fixes most of the recently reported issues sometime this weekend; many of the fixes are already in place, needs some quick testing and packaging/uploading. It won't address all of the outstanding issues, but will tackle many of the more mod-breaking problems (such as the one reported above).
-
Apologies for dragging you into this, and for apparently posting what amounted to rumor; I did not intend to attribute statements to you that you did not make. I fully agree with your two posted points, and would expect those to be followed at the minimum if someone was working on a mod-of-a-mod. To do any less is simply rude and inconsiderate. I would also agree that in order to get the best effect out of any potential conversion for PBR shaders, one really does need to author new textures for at least the metallic maps (specular can often be converted into smooth/roughness decently enough). I applaud the work that has done into the patch-only TU conversion sets, but they do leave a lot of room for improvement regarding the use of metallic maps. Doesn't require any 'coding' knowledge; simply knowledge of basic KSP config-file modding using ModuleManager. I don't really have time to go into more detail than that -- if you need tutorials on how to use ModuleManager, those are readily available from multiple sources (google for 'KSP ModuleManager Guide'). Once you are to that point, the examples posted by others should give you enough information to create the patch you are looking for.
-
Yes; of a sort... It is a special PartModule for the fairings, and they cannot be applied in the same 'model-shader' method as the other parts due to the nature of the fairings. https://github.com/shadowmage45/TexturesUnlimited/blob/master/Plugin/SSTUTools/KSPShaderTools/Module/KSPFairingShader.cs Add the KSPFairingShader part-module to the parts. Specify the global KSP_TEXTURE_SET in the module-configs' 'textureSet = XXX' parameter. It does not support texture switching or anything aside from simple texture replacement.
-
In theory, it shouldn't matter where the science data comes from -- as long as the lab reports that it has science data to process, it should generate science points from it. (of course, those are the stock mechanics, using stock modules, your mods might alter any/all of that...). I just tested in a stock install, and the lab on the DOS-LAB works fine as far as stock mechanics and modules goes. I can run an experiment, add the data to the lab for processing, click the 'Start Research' button, and it generates science points. In the screenshot above, you can see where it lists 'Data 1/750', and 'Rate 0.0243/day' -- those are the important stats that state that the part is working properly. Could you please provide a screenshot of the LAB's right-click menu (such as the one above), showing its data/science values/other stats?
-
Did you load the lab with science reports first? (sorry, gotta check the obvious...) I'll do some quick testing this evening to see if the stock-science lab portion of those parts works in my dev setup; that will at least let us know if it is a part config problem, or a mod conflict/config problem.
-
What is a 'research-kit'? Certainly it is not stock.... ? (which is why I think this is all related to the mods you are using)
-
@vossiewulf Sounds like your problems are with whatever 'science moving' mod you are using. Or rather, if the DOS-LAB part functions poperly by itself (e.g. generates science, stores science, can transmit), then whatever the problem is must be with your 'science moving mod'. I don't do anything special with science modules -- the part uses the stock science lab and storage container modules. Thus, there is nothing in SSTU code that could be causing those types of problems. Now, if the LAB part doesn't work properly for the stock science-lab functions -- then that might be something I can fix up, as it is likely a configuration error (because, again, I don't do anything with plugin code regarding science modules or functions). In order for me to diagnose what is going on with that other mod I'll need to know what it is called. There is a very high probability that they have 'hard coded' support for special parts and/or mods, and SSTU simply isn't on their special handling list. What is the name of the mod, and do you have forum and/or github links for it?
-
All parts in the mods' default configuration are for Stock solar system (scales, thrusts, TWR). RO used to include a set of patches to adjust the engines for their real-world performance stats, but as I am not involved in RO/etc, I have no idea how up to date or maintained it is. To answer your question -- yes you will want to find/make some patches to adjust the engines for decent performance in an RSS setup.
-
Yep; the core tank should be 1.4375m -- with the Soyuz style nose adapter present, that should bring the upper diameter of the core to 1.875m. The nose option should be available for the MFT-A tank, but it might be listed in the UPPER options rather than NOSE.... (if it is not available.... then something went sideways with the recent releases, as I explicitly added it for the last update) Not removed to my knowledge.... it was a stock feature though.... so who knows what may be going on with it. Were there any config changes to the parts that you are having issues with in any of the recent SSTU releases?
-
That 'problem' has existed since before I even took over development on KF. A bit of history: Stock models (.mu files) store their texture references in the model file. The particular models in question have references to some textures that no longer exist (if they ever existed). The meshes in question receive their texture through plugin code, which is why there are no 'untextured' parts. The 'solution' would be to recompile the model with empty materials for those meshes. Now, I don't have the original modeling files for many of these parts, so I cannot recompile the models (without jumping through hours of work to import them into Blender, fix up the import errors, re-export to .fbx, and finally re-import into Unity). (Alternatively, one could 'edit' the .mu file to remove the reference.... but the .mu's are binary encoded and it is non-trivial to decode the files and rewrite them) As the 'problem' has zero actual effect on gameplay, or really anything aside from those few lines in the log file, I have opted to not spend those many hours of time. One of those 'effort vs productivity' trade-offs....
-
None; that is the new stock MK-whatever pod (3-kerbal, 2.5m) that was released with the Making History expansion. I believe it is part of the base game though, so everyone should have it.
-
Thanks for the confirmation and info. I've opened an issue ticket on it, and will investigate a fix for the next release (hopefully this weekend, or next, depending on if some of the craziness at work clears up). https://github.com/shadowmage45/SSTULabs/issues/729
-
@vossiewulf You may need to enable the 'angle snap' on the ports. IIRC there may be an issue where they refuse to dock unless it is enabled. (if that is the case, please let me know and/or open an issue ticket so that I can remember to get it cleaned up)
-
Taken down due to a polite request from Nertea asking as much. ^^^ is the reason I will not release any configs myself. As I don't use stock parts, they would all be for mods; most of those mods being the NF suite. So its kind of non-starter, as I respect Nertea's wishes regarding his works (and those of other mod authors who have expressed similar).
-
By default, this mod does nothing. It is an API that -others- can make use of. So, no; I will not be updating CKAN with any configs (because there are none there currently).... Any configs that you currently have/use are provided by a third party. I can do nothing about how complete/incomplete they are. Your best bet would be find the author of your configs, and ask -them- to finish them.
True dat.... nothing I can do to recover those.