Shadowmage
-
Posts
4,628 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Everything posted by Shadowmage
-
Yeah, the stock parts that use stock shaders look fine in the parts list. Its only parts using non-KSP PBR-based shaders that have messed up icons (legacy non-KSP shaders should still work fine).
-
I'm not understanding the post? The icons in the parts list -are- using KSP icon-shaders (specifically KSP/ScreenSpaceMask(sp?)) -- that is the entire problem. They should be using some PBR-featured icon shader, and should show reflections/etc. Edit: Even if I were to somehow be able to do this -- the issue is that the KSP/XXX icon shaders don't render PBR textures properly (no reflections, no smoothness, no bump-maps, no AO maps, etc). (The TU replacement icon shaders do still work when their configs are enabled, and both render the textures and show reflections properly; however I was told these icon-related hacks should no longer be needed, which is what I was testing)
-
Hehe, the art of illusion, at its heart. Glad I could convey that bit of understanding regarding model rigging. Now only your imagination will limit your rigging (and obscure technical issues, as always)
-
Icons for parts using KSP/XXXXX shaders work fine. Icons using any non-KSP/XXX shaders (e.g. any TU shader) revert to using the default icon-shader for legacy-diffuse textures. For this test I manually disabled all TU icon-related features (by removing the icon-shader configs that drive the icon-shader replacement), as I was intentionally testing the stock icon-shader handling. Here is how KSP 'handles' non-KSP shaders (e.g. TU/Metallic, etc): More ugly bits... They aren't un-textured -- they are fully textured, but are using the legacy diffuse shader, which renders PBR textures very poorly. Quite the mess. Finding it really hard to care past this point. Regardless, I don't think I'm carrying the part-icon manipulation code forward; I was told this was going to be a solved problem, and I lack the motivation to continue fixing stock issues, especially when they do not provide the API level hooks to solve it properly. I'll reconsider if I find that stock did add proper hooks, but so far I have not seen/heard anything about it. Now, to their credit, the 'blue icons under DX11' issue has been fixed, but as DX11 is the new default for Windows, I would expect nothing less.
-
Unfortunately, my initial testing has revealed that SQUAD has not fixed the part-icons. They are as screwed up as ever if I turn off TU's icon replacement code, at least in the default configuration. During the pre-1.8 discussions, one of the devs mentioned that there might be some configurability regarding this, so I'm inquiring now to see if it was actually implemented. Quite sad that the first thing I look at in the update is broken (even though I was told it would be fixed), doesn't spell good things for the rest of the update.
-
@JPLRepo During the pre-update discussions regarding 1.8, it was brought up that there were issues with the Part Icons for any parts using non-KSP shaders. IIRC you mentioned that a solution was being developed (or was at least going to be investigated?). Did anything come out of this? Is there a way for me to set the icon shader for any specific part/model/mesh? Or, how could one specify the original shader -> icon shader mappings so that KSP will know to use the proper icon shader? Notably, KSP 1.8 does not render the part-icons properly for any part using a non-KSP shader. It looks like the icon defaults to using the KSP/Diffuse equivalent icon shader. Alternatively, is there source available for the icon-shaders anywhere, so that I might develop properly functioning replacements (I haven't d/l the update part tools yet; was it included?)? Thanks;
-
I'll be working through some updates for the mod in the upcoming weeks, and I'll try to remember to take a moment to check on this feature and document how to adjust the tech-limits. If you do get it figured out, feel free to post letting others know how it was done; nothing wrong with sharing the information
-
Good to know. Would have added documentation anyway, but I'm glad someone is making use of the feature, and happy that it could be helpful to someone other than myself That was the whole intent -- could be faster than ripping the model into blender just to look at UV's. Indeed, feels like it got a bit of a bad name/rep from all of the 'make it shiny' patches floating around, and nobody bothered looking into the mod past that, or what its intended purpose was. Glad that some further consideration is being done on the mod, for its intended uses, and I will be happy to add some documentation to support that. I wish I could get that point across to more people. PBR brings so much more to the table than metallics, but it seems not many are interested.
-
These upgrade lines in the individual parts (these are the tanks, but other parts use very similar setups): https://github.com/shadowmage45/SSTULabs/blob/master/GameData/SSTU/Parts/Tanks/SSTU-TANK-MFT-A.cfg#L599-L639 Reference these 'upgrade' parts (again, that is the tanks file; the other files are in the same folder): https://github.com/shadowmage45/SSTULabs/blob/master/GameData/SSTU/Parts/Upgrades/UpgradeParts-MFT.cfg The required tech is set in the upgrade part. Edit/patch those to reference your desired tech. As far as removing the requirements entirely -- been too long since I've played with the system, so couldn't say off the top of my head; but it is an unsupported use-case anyway. It might be doable (should be, even), but couldn't really say one way or the other with any certainty. NOTE: I believe some of the tech-tree related data is loaded into the save-game file, so you may need to start a new game in order to see all of the tech-tree related changes. FURTHER NOTE: Many of the parts reference upgrades for other parts (or did at one point). E.g. the decouplers may use the tank-size upgrade (or they might have their own...). Something to keep in mind.
-
So... the good news is that I was finally able to take a few moments to download the KSP 1.8.1 update, the newer version of the Unity Editor that will be needed, and was able to (with quite a bit of expletive-induced coercion) get the existing code to compile versus the updated KSP binaries. What does that mean in regards to an updated release? Not much, but also, quite a bit. The existing code still functions, from a linking/compiling perspective, so that means there were no large API level changes that would break things (hooray). This was mostly evident by the fact that the old DLLs apparently continued to function under KSP 1.8, but it is always good to confirm it by linking to the new libraries (sometimes function calls may still fail if they used reflection/etc, and weren't fully linked). Notable issues encountered with updating of the project: Unity 2019 has split its dependencies into a mess of .dll's. Each of these must be referenced individually for specific features. .NET framework version has to be bumped up to 4.0 (from 3.5), as the newer Unity libraries are built on that framework. It has been a long time since I've toyed with modding, and it is going to take me a bit to figure out where I was in all of my projects and how I had configured them and their build tools My goals for this week are: Finish cleanup of old Unity versions, conversion of all KSP projects to new Unity version + link to newer libraries. Fix up any Unity Editor scripts that I had in KSP projects that might have been broken, such as the shader packaging script(s) Basic recompile of TU against new KSP binaries Repackage of DX11 + OpenGL shaders Testing KSP icon-shader code, to see if all of the ugly hacks with part-icons can finally be removed (likely not, but hoping...) Potentially publish an update to TU sometime over the weekend. Other mods to come as development progresses. UV-Exporter -- sure. Its just one line in the config file that enables the feature, IIRC, but as it is a potentially useful feature (even if nobody has actually made use of it yet), still would be good to have it documented. Shader Loader -- what aspects are you desiring documentation on? (shader package creation?)
-
Likely as not the shaders themselves need to be recompiled using the new Unity Editor version -- shader packs were historically Unity version dependent, so it is a bit surprising that they even work under DX11 The good(ish) news is that TU will be the first of my major mods to receive an update, as it is a dependency for all the rest. The further good news is that I should have some time this weekend to start on the 1.8+ updates. The project I was in the middle of at work has mostly wrapped up, and while that doesn't mean that I have any more free time than before, it does mean that I can devote a bit of headspace to modding again for a bit (can only hold so many programming projects in my head at a time, and lately it has all been work related stuff).
-
Good news is that it sounds like my work project is wrapping up; I just got the word last night that I would not be having to get on a plane and fly out to the jobsite, as one of the other parties involved finally fixed all of their broken mess. Should be finishing off the project this week, and might actually get some breathing room in the next few weeks, possibly even enough for some modding efforts Still not making any promises, as there are still too many unknowns, but the prospects are looking much better today than they were yesterday; undoubtedly some progress.
-
Yes, excellent suggestion. Don't think I documented that one at all. (Off the top of my head, I think the colors themselves were added to the GROUP definitions, but its been awhile, so I'll take a look to confirm, and add it all to the docs)
-
Sorry guys, still neck-deep in a major work project, so have had precisely zero time to devote to modding recently (and very little time for sleep/etc). Really hoping that it will be wrapped up soon (technically, I believe it is, at least my end of the project), but until all involved parties have finished and the leads signed off, I'm still being kept occupied. Should get the word sometime later this week unless some major new issues are uncovered during extended testing. Sadly, I haven't even been able to try out 1.8 yet. Hoping, truly hoping, that they did a good job on the DX11 update, and that I won't have to spend months fixing problems related to it. I should know more shortly after I'm able to start the update; shouldn't take long to see what is working/broken.
-
I thought I had just merged a PR that updated them to the newer system (a few weeks/months back..). I'll take a look though, but no promises, as it is a ton of work (and at this point I don't even know what needs to be done). In general news, it looks like I missed the release of 1.8 by over a week! Not sure how I missed it, but I'll be starting work on updates for all of my mods in the very near future. Hoping to wrap up a project at work this week which should (barring the next project dropping) give me a bit more headspace to concentrate on modding.
-
Is this using the stock ModulePartVariants? (IIRC, yes, as I think that part uses them) Have a config that you wouldn't mind sharing? (don't necessarily need any textures/etc, just the config text file) Sounds like this might be a bug in the TUPartVariant module, could also be some config oddity though.
-
That is a case of KSPs odd rendering system (scaled space, multiple cameras) not playing nicely with Unity's Reflection Probe system. Is something that SQUAD would have to fix, as it is a problem with their rendering systems. TU does not handle any of the reflection mechanics anymore (it used to in the past); that is now all stock code. All that TU does is provide the Unity-Standard compatible PBR shaders (and provide mechanisms for loading those and applying to parts/models).
-
Yes, they were both removed quite awhile ago. Their functionality can be replicated with the configurable MUS fuel tank (Modular Upper Stage).
-
While technically true, it is a bit of an advanced use, as it requires an understanding of how all of the different components work together (which is generally something only plugin authors would grasp), so I don't advertise it as a standard use scenario. I have enough on my plate helping people figure out the 'standard' uses already (With that said, yes, it is a valid technique, but as it relies upon the ModulePartVariants internal functioning, I cannot guarantee that it will continue to work for any particular use if/when SQUAD updates that module)
-
No, and yes (and creating any missing textures; e.g. the metallic maps). Sounds simple, but it is a ton of effort to add support for mods extrenally. TexturesUnlimited was intended to be a tool for the mod developers themselves to use as part of their workflow, where it is not quite as painful to do the setup if it is done during the model/texture creation and included in the workflow from start to finish. But trying to come in after the fact, without the original art assets (e.g. layered texture files, substance projects, etc), is a major pain, extremely time consuming, and the result is not nearly as good as it could be had it been done properly from the start. Unfortunately, not many mod authors showed any interest in using it, so not many mods have TU support. SSTU is about the only one that I know of that actually makes use of it for all of its parts/textures (see signature).
-
To set the starting state: MODULE { name = KSPWheelBase [....existing stuff....] persistentState = RETRACTED } If the animation is 'backwards' (allowing control when retracted), invert the animation in the deployment module: MODULE { name = KSPWheelDeployment [.... existing stuff ....] invertAnimation = true } A bit later in the week, if you are still having problems, try packing up your configs + model files into a .zip and send them my way. 99% certain I can get it working, but I'll have to dig into what is currently going on / how the model is rigged. (Really wish there was someone else who could wrap their head around the wheel system so I didn't have to do all of these myself.... any volunteers? I really don't have time to keep working through other peoples models' configs, and could use some assistance if anyone is knowledgeable enough) Further note -- KSPWheel actually works closer to the old Unity 4 wheel system (in fact, it was designed around that interface), so trying to utilize tutorials for making wheels in KSP for Unity 5+ might point you in the wrong direction (at the very least it'll make things needlessly complex). (I have no idea how to use the new stock system, so can't give any more precise information...)
-
Yep Exactly Yes.
-
There is a way to invert/reverse the animation within the configs, so it should be able to be made to work regardless of which direction the actual animation is setup for in the model. I'll try and dig up which config settings are needed (just handled this when helping someone else, but don't remember.... seemed 'common sense' when looking at the module defs). Constraints -- I can't really help much there as it is entirely model specific. I'm not seeing any constraints modules listed in the config though? I'm certain we can get it all working for you, might just take a bit to get it all sorted out.
-
Ignoring the mach 0.5 on-the-ground (which is crazy fast, and likely to cause problems with KSP physics regardless), I've had previous reports of 'hitches' and 'stalls' when using KF wheels, but have so far been unable to reproduce it locally (could be just hardware differences where I don't notice it). So you are probably not crazy. Could you please upload a .craft file of a Stock+KF only craft that exhibits the issues, so that I might duplicate the problem locally? You can attach the craft file to this issue ticket (Drag+drop into the comment textbox to upload): https://github.com/shadowmage45/KSPWheel/issues/61 If you could also include a listing of the steps that are needed in order to manifest the problem, it would greatly help. I've tried investigating this problem at least four different times, and each time I end up spending ~2 hours doing debug testing, without the issue showing up. Likely I'm just testing the wrong things, as I'm fairly certain there is a problem in the mod, only I do not have enough information to know where or what.
-
Likely that your stock reflection settings are set to 'disabled' for real-time updates. Go into the game options, find the settings dealing with reflection quality/speed, and enable them. Not at a KSP enabled computer at the moment, to can't give any more specific info =\
