Shadowmage
-
Posts
4,628 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Everything posted by Shadowmage
-
Nope, TU doesn't care about texture resolutions at all. It will simply take the texture you specify and put it into the shader slot for the material; it won't even check formats/etc.
-
Indeed. Sadly, any 'easy way out' would have to come from the PP end of things, in the fashion of something in the configs that would turn off their texture-assignments entirely. ^^ Pretty much this exactly. As a bonus, such a solution coming from PP itself would allow for turning off/disabling of any PP texture-switch UI widgets, and result in less part-action-window clutter. The other alternative would be a custom PartModule that interfaced with the existing TU part-module, but re-applied the textures at a later point in the loading sequence. Could probably end up being quite simple, something like 5-10 lines of functional code. Hmm... thinking on it a bit (but not being familiar with the PP code), this might be solvable with an order-of-patching thing. What does the final config for the PP parts look like, post-MM patches? If the TU texture-switch part-module is the last module on the part, it should run its updates after all of the others (assuming that the updates are being done in the same lifecycle calls between the two mods; e.g. both are using OnStart).
-
Do you have a Smoothness / Gloss texture? Seems to be the only one missing. (or is it already in the alpha channel of the MET?) Should have five(six?) source textures, which are then compressed into four binary assets to be referenced in the configuration file DIFF (its own RGB) SMOOTH (A channel in MET) MET (R channel in MET) AO (G channel in MET) NRM (RGB) MASK (RGB) The textures that I've looked at appear to be correct for the grayscale based setup. As soon as the smoothness/channel stuff is figured out, you should be able to simply write a config to reference them all and apply them to parts. No. If you need to interact with other plugins, you will have to write your own custom plugin in order to do so (or have that plugins authors make the required changes). E.G. TU -> PP -> Your Custom Stuff In short -- TU is not intended to be able to change procedural parts, nor is it intended to work alongside any other texture-switches. If you need such functionality, you will have to write your own custom plugin code to do it.
-
Noted -- I'll see if I can come up with some more pointed instructions and/or perhaps a walkthrough video or something. Its certainly not the easiest or most obvious concept to grasp from an external perspective. Essentially though it is as how Electrocutor stated it -- you want the average luminance value of the area covered by each of the mask channels. If you wanted some 'precise' help, feel free to PM me your diffuse/specular/metallic/mask textures and I can run them through my calculation tool (eventually I want to release this tool publicly, but it is not quite ready for general consumption yet). It is also possible to do it manually by using GIMP or PS and a bit of interpolation.
-
Unknown -- feel free to give it a try, watching your log for exceptions/errors. If no exceptions pop up, then likely it will work fine. As far as I remember there weren't any breaking changes between the 1.4.5 and 1.5.x stock API, so you may be in luck.
-
Finally got a chance to investigate KSP 1.6 and its 'in-flight environment reflection updates'. It appears that they have chosen to utilize the Unity Reflection Probe for updates, which is logical as there really isn't any other way to do it. The good news is that the stock system is inherently compatible with TU shaders, and that it can be disabled entirely through the in-game stock Settings menu. The bad news is that the stock system is not entirely compatible with Scatterer (untested, but likely EVE as well). Or rather, Scatterer is incompatible with Unity Reflection Probes. At this point there is potentially a choice to make: Disable/remove TU's reflection system in favor of the stock system (problems included) Keep TU's reflection system in-place, allow player to choose stock or TU reflection systems Hack around with the stock reflection system to utilize its reflection probe, but with the TU 'fixes' in place ??? (open to suggestions) For the time being I'll likely be leaving the TU system in place, but add some quick checks to disable it if the stock reflection updates are enabled (no reason to have both going). I'll give some time to see how Scatterer and EVE respond to the stock reflection system. Would really rather love to not have to do the hacky (and bad for performance) fixes that are in place, all of which exist because Scatterer and EVE have issues when the Unity Reflection Probes are used.
-
Cold and snowy here as well. ~12 inches of fresh snow over the weekend (in the valley, likely was likely many ft in the mountains), with daily high temps of <10f. Only getting started here though, still have another 2-3 months of cold and snow yet to go. Yep, right in the middle of the Rockies, a stones-throw away from Yellowstone.
-
As @0111narwhalz points out, the best way to make the wheels support larger loads is to make the wheels larger. Kerbal Foundries includes built-in part scaling, so feel free to make the wheels as big as needed. Also as pointed out, there are other options in the mod specifically intended to support large loads -- Large wheels and large tracks. Sounds like you might already be using the larger wheels, but you might try the large MOLE tracks, or simply scale the existing wheels up a notch or two. Finally -- if breaking from 'overloading' is your only issue, you can disable the wheel-break-from-overload functionality in the KSPWheel settings in the in-game mod settings. To provide more pointed information, I would need more information to work from -- screenshots of the craft, and more specifics on the mass.
-
What parts of the documentation do you feel could use more elaboration/detail/reworking? (more than happy to help explain things, esp. if it can be used to improve the documentation and reduce future confusion of others)
-
Hmm.... which SSTU version? The setup for the parts in the newer versions is quite complex and requires a bit more than it did previously. Could also post samples of your configs/patches so that I can take a peek at them (links or spoilers, whichever you think is appropriate to their length). No kidding Working on getting all of SSTU's dependencies cleaned up and recompiled for 1.6. Two down, one to go. So, perhaps next weekend I'll have an update available.
-
Updated release is available: https://github.com/shadowmage45/KSPWheel/releases/tag/0.13.10.29 Recompiled for KSP 1.6 + .version file updated; no other substantial changes. See link for downloads. I'll be doing a pass over the code in the next few weeks to see if I can track down and remedy the issue of excessive memory use/garbage generation. Thinking it is in the dust/audio code somewhere, as the sim side of things looks clean from a mem-allocation perspective.
-
Updated release is available: https://github.com/shadowmage45/KSPRescuePodFix/releases/tag/1.5.3.13 Recompiled for KSP1.6, adds in new stock command pods, as well as a patch to target the stock expansion pods when the expansion is present. See link for change-log and downloads.
-
My issue is with their lack of following the schedule that they posted. Posting the intention to have a 'three month update cycle', and then immediately not following that schedule for the first release that should have followed it. I would be much less irritated had it been delayed out to >3 months; that I can understand. The timing of it was also exceptionally poor. Seriously, two days before the holidays? Do they not think mod authors have lives/families/other obligations that need taken care of once in awhile, or simply did they not take any of that into consideration at all? Updates = great. Lack of follow-through on posted schedule = bad. Posting an update right before X-mas, that mod-authors need to respond to, outside of their stated schedule = very, very bad. I have lost much respect for SQUAD with this move. Honestly have no idea. I haven't even had time to download the new version, let alone any time to test stuff. Probably won't for another week at least. When I see someone (SQUAD) post about a very specific update schedule, I expect it will be followed. Thus I have/had already scheduled other things to work on for the past few weeks, and through the first part of Jan. According to the schedule that I was following, I wouldn't have to worry about even starting 1.6 stuff until sometime after the middle of January. And unfortunately it is looking like there isn't much I'll be able to do to change that; existing obligations are just that.
-
1.6 Update News: Should be available shortly after TU is updated, but that might take a few weeks (holidays, actual time to implement). Beyond that it might take a bit longer as there are some outstanding bugs that need to get cleaned up before the next update. If the current releases 'work', go ahead and use them. At this point there aren't any game-breaking changes planned, so there shouldn't be any issues when the official update is released.
-
1.6 Update News: I will be investigating the changes to stock code and its in-flight reflection handling that were done in 1.6, use their system if possible, but otherwise update/fix/override whatever is necessary to make the two work together well. As such, it is going to take a bit of time for this to be done. I would anticipate one to three weeks, depending on how quirky the stock implementation is. I have not yet personally tested, but reports tell me that TU appears to work fine in 1.6 (in OpenGL on a Mac at least), so if the current versions work for you, go ahead and use them. At this time there are no scheduled changes to the plugin aside from potential bugfixes and the stock reflection-updating, so there should not be any concern of game-breakage when the update is released. (I did have some very substantial stuff planned, but was anticipating another few weeks to work on it).
-
1.6 Update News: I will hopefully be releasing an updated/recompiled version over the weekend. The current releases may or may not work properly under 1.6 (untested yet). Chances are that if the plugin loads up that everything else will work fine. If the current versions do work, you may continue to use them without fear of breakage when the official update is available; there are no scheduled changes to the plugin aside from potential bugfixes.
-
1.6 Update News: I will hopefully be releasing an official 1.6 version over the weekend (no promises); it will have some minor changes to the list of command pods that are valid, including the newer versions of parts from the latest KSP releases. Until then the current versions should continue to function, and there should be no concern over breakage when the update is available.
-
LoL, looks like there might be an issue with the water-effects in KSPWheel (from the Adjustable Landing Gear). If this is a repeatable problem, would you mind filing a bug report with logs / list of mods used / steps to recreate?
-
Thanks for the offer It something I'm going to have to do myself though, as it will involve some debug-edits and recompiles of the TU plugins to allow it to make use of the stock reflection stuff. Good to know that the stock system didn't break TU entirely; hopefully there won't be too much that I need to change. I'm really hoping that the stock reflection system is done properly, and I'll be able to leverage it directly.... but their previous work is not invoking much confidence.
-
Good to know -- thanks for the info. I figured there likely wasn't going to be much breakage with the new update with SSTU -- I'm more concerned with the stock 'in flight reflection updates' and how much pain that is going to cause for TU. Every time stock touches their shaders/rendering, I end up spending two months cleaning up their mess. Judging by your screenshots it looks like it didn't break anything in TU, which is great news. At least I (hopefully) won't have to spend a ton of time cleaning up the stock issues, though I'll certainly have to play around with the stock reflection update stuff to see if/how it works (and how broken it is with mods in play, and if it even does convolution correctly).
-
Huh, well apparently SQUAD did another un-announced / un-scheduled game update. In short -- I have no idea if/when I'll be able to get SSTU updated for 1.6. It will be awhile. I have things planned and in the works from now up until midway through January, which is when this updated was supposed to be released. Will be at least until then before I will be able to do even a basic recompile of SSTU or any of my other mods. So sick of the inconsistent update schedules, and lack of any actual schedule. Why announce a 3-month update timing pattern... and then not stick to it for even the first update? Like what? How am I supposed to schedule my work if I can't rely on their announced schedules being followed?
-
Pretty much yes - they are grouped by the 'engine'. So if an engine has 3 transforms, and you have 4 engines in the cluster, the transform mult. list should look like. But in order to process it correctly you will need to know the layout of the original engine (how many tr's there are, which one is the 'main' transform). tr[0] = engine[0]:tr[0] tr[1] = engine[0]:tr[1] tr[2] = engine[0]:tr[2] tr[3] = engine[1]:tr[0] tr[4] = engine[1]:tr[1] tr[5] = engine[1]:tr[2] tr[6] = engine[2]:tr[0] tr[7] = engine[2]:tr[1] tr[8] = engine[2]:tr[2] tr[9] = engine[3]:tr[0] tr[10] = engine[3]:tr[1] tr[11] = engine[3]:tr[2]
-
Pretty much this ^^ SSTU doesn't touch the thrust-transform multipliers after it has set up the model and engine-module initially (when vessel/parts are first loaded). It should be safe to manually adjust these values to simulate engine failure modes. As noted though -- some of SSTU's engines have multiple thrust transforms in a single engine (notably the multi-nozzle engines and those with pump-exhaust roll control), so some special handling would be needed for those.
-
As others have pointed out, it is a known issue; I missed a couple of patches for those engines in the last update. Thanks for including the log file though; wish more people took the time to do that when posting about issues As @Starwaster mentioned, it has been brought up before. Its not so much that 'I declined' adding such a feature... but that such a feature would be extremely difficult to add, likely taking weeks of development time, and is not a feature that I would ever use. Weighing that against the features that I will use, and the outstanding bugs that need fixing, and it wasn't hard to see where best I should spend my time. If someone would like to submit a PR for such a feature/addition, I would more than likely include it. But it is not something that I will be spending my (extremely limited) modding time on in the foreseeable future. The difficulty isn't necessarily with SSTU's engine-clustering code -- the difficulty is with the stock engine module (and the fact that you can only effectively have one engine module per part). In theory you shouldn't need to touch SSTUs code to do what you are requesting; hook into the engine module and manipulate its internals.
-
Interesting find, and might explain why I've never noticed it before. Certainly there is the possibility for some less-than-optimal code generating extra garbage from temporary variables; tons of 'processing' goes on with the wheels physics simulation. The good news is that it is more than likely fixable. If you would like to file an issue on the KSPWheel bug-tracker, including the above information on your findings, it will make sure this issues doesn't get forgotten about, and I'll do my best to investigate + clean it up for the next release.
