-
Posts
4,628 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Everything posted by Shadowmage
-
Interesting -- I haven't yet played around with the new DLC inventory, but it seems like a good addition for the crewed parts. At least a couple of inventory slots on the standard pods, and a slightly higher number on the dedicated lander pods.
-
Ahh, indeed I do seem to remember having to play around with that a bit at some point, but never saw any documentation about what exactly it was supposed to do. Your explanation makes sense, thanks . @Joker58th I've opened an issue ticket to track this problem and make sure it doesn't get forgotten about -- https://github.com/shadowmage45/SSTULabs/issues/796 I'll update that ticket with more information as things progress.
-
Either works fine for me, I don't really notice much of a difference between the two. As long as its not DX9... I think DX11 might have slightly higher framerates, but it is hard to tell with KSP being CPU bound most of the time. Now, I should also mention that stock KSP has issues regardless of OpenGL or DX11 -- the stock shaders have issues with part-icons; issues that SQUAD refuses to fix (they simply respond with 'we don't support those APIs, so not fixing it, sorry').
-
Specifically because I always hated the stock solar panels with their colliders, always getting broken by... random kerbals? sneezes? looking at them sideways? IDK, they always broke for me from the slightest brush of collision with anything, or sometimes nothing at all (break on being deployed, or on vessel reload). So the SSTU solar panels simply don't have colliders on the panels. The only way to destroy one is to destroy that little knob. (note that they still have code that will destroy them from excessive aero forces; they are not deployable wings after all) Is this the best way to fix the perceived problem? Possibly not, but it was the fastest and easiest one I could implement (and also, at the time that module was written, in my early days of KSP modding, I did not have enough knowledge of Unity to properly handle destroying of just the panel meshes and persist that state across reloads). I've since learned how to handle such an issue (and collisions could be enabled in the current plugin easily enough) -- but now the problem is that the original models lack colliders. Some of those solar panels have ~100 meshes that would need to have colliders generated, added to the model hierarchy, positioned, and then imported into unity and individually configured there as well; a massively time consuming project, at best. This also brings up the issue of '100 colliders on a part' is simply bad for performance; terrible even when using primitives (cubes/spheres). To effectively add colliders to these parts I would have to get... creative. Enable/disable the colliders as part of the animation to minimize the number needed, or have a single/few collider(s) that 'scales up' during deployment that covers the entire mesh (but is not animated accurately relative to the visible panels). Pretty much exactly that. KSP was started by one guy (HarvesteR), working for what was at the time a marketing firm. From what I understand he had little knowledge of coding when he started, so the years of 'best practice' knowledge I take for granted, would have been completely unknown to him at the time. Not trying to be critical of his efforts or accomplishments, everyone is new at some time. Fast forward a few years and the KSP codebase has grown substantially, but was never taken through the rewrite that it should have been once the original code deficiencies were realized. Possibly they never were or have been realized -- the issues we encounter in the modding scene simply wouldn't exist in the base code interacting with itself -- they only manifest when trying to interface arbitrary mods with each other without using reflection or compile-time dependencies. Not a problem specific to KSP either (or even game modding). When I was doing Minecraft modding there were much of the same issues encountered regarding cross-modding interactions and layers-of-cruft style code. I also see much of the same with some of the software that I maintain for my employer, layers of bad code covering up more layers of bad code; but as long as it 'functions', there is little motivation to spend the time to rework things.
-
You and me both I thought I understood what it was for / how it was supposed to function; but attempts to use it like that (e.g. how you are using it) simply don't work as you would expect. So, unfortunately, I'm not really able to provide any tips or pointers on this -- it is a stock PartModule, and not my code, so I can't really tell what is going on under the hood. Is anyone else out there familiar with the stock docking port module's 'angle snap' functionality? Mind shedding some light on how it is supposed to work? Edit: You might try setting them to some value > 0. I believe it means 'they should only attach on increments of X degrees', where 'zero degrees' is not a valid value (X / 0 = NAN). So, something like 90 degrees on both ports, should allow them to only dock/attach at 90 degree increments. Also, note, that with the welding docking port, you have to have both ports in the 'retract and arm' state before they will actually dock. If either port is 'extended' there are colliders that keep them from docking (intentionally; to allow you to fine-tune orientation before permanently attaching things).
-
Yeah, don't get me started... ^^^ is the entire reason that SSTU exists. If I didn't need part-modules that would work on welded parts, I never would have started coding plugins for KSP. Was actually my first bit of plugin code for KSP, IIRC -- a multi-transform capable fixed solar panel module. What irks me even more is that many of these modules could support multiple transforms/animations/etc with just some very minor edits, generally one-line type of changes, where they could still be 100% backwards compatible with existing uses. Trying to convince SQUAD of that though has been a futile effort the few times I've tried. Alternatively they could implement an actual API for these stock systems; e.g. an ISolarGenerator interface one could implement on their part-module. External mods would then no longer look for the stock solar panel class, but could then interact with ANY module that implemented that interface, regardless of which mod it came from. Of course, that would mean that someone at SQUAD actually understood and used one of the primary tenants of OO programming, which are most often lost on anyone targeting Unity ('what...? Class hierarchy.... that's what we did in high-school, right?'). ...Perhaps I'm just a bit bitter after dealing with exactly these issues for years now, with little movement towards improvement
-
Pretty sure it does include indicators of orientation, baked into the texture. Should be indicators for 'front' and 'top' on the respective sides, which should be enough to determine orientation during construction. https://github.com/shadowmage45/SSTULabs/blob/master/GameData/SSTU/Assets/SC-GEN-DC-DIFF.dds Note that these text indicators are on the 'top' and 'bottom' of the probe core / decoupler parts; once it is in a stack there should be no visible orientation markers on the external cylinder portions of the model. The issue with allowing any kind of indicators on the side-panels is due to the procedural nature of the texture and UV mapping; any potential indicators would end up squashed, stretched, warped, and distorted dependent upon the currently selected 'height'. You can try it out for yourself if you would like, and see if you can come up with anything acceptable. Edit/replace the texture linked above with your alterations. The top half of the texture are the cylinder caps, and the bottom half of the texture is the side panel. Might only need to create new mask textures ( https://github.com/shadowmage45/SSTULabs/blob/master/GameData/SSTU/Assets/SC-GEN-DC-MASK-A.dds ) rather than the base diffuse, as the part is fully recolorable. Simply create some masks that include your desired indicators
-
See below Yep pretty much that. Stock modules absolutely will not support the complex solar panel suncatcher/pivot layouts used in SSTU -- stock is 'one named pivot only per part' However, the Kerbalism devs are already working on SSTU support/integration last I heard (~3 weeks ago). I believe there is one PR that I need to review and merge, and then I think the rest of the integration will be on Kerbalism's side of things.
-
You can also install the latest TU from here: ( ) Notably, it no longer 'requires' DX11 or OpenGL. Still looks just as bad under DX9 as it ever did (those are problems with DX9, and not TU), but it will let you use the old API without popping up the warning during startup. Now, if you actually want to _use_ TU and get the most out of it as far as the graphics it can offer, then yes, you have to use either DX11 or OpenGL-Core.
-
TU doesn't directly allow for manipulation of non-part textures. The system is based around PartModules, and as such, really only works with Parts. The shaders themselves work fine when used for other purposes, but there is no built-in functionality in TU to use them for those purposes. Certainly you could use TU to provide and load the shaders, but you would then need some additional code to apply the new shaders (and materials/textures) to the terrain and scenery/buildings. The shaders -do- work for terrain. Did quite a bit of experimentation when working through HDR and post-process effects, and one of the things I needed to 'fix' was that the stock terrain/scenery shaders had some odd rendering issues when HDR was enabled, so I put together some quick-and dirty prototype code that replaced all of the stock scenery shaders with the TU. Notably I didn't continue down this route as the stock terrain shaders were authored with the diffuse workflow, and lack specular maps entirely, which would have required that I create and/or otherwise supply these textures for every material I was replacing; and as these were the stock terrain textures, there is no direct access to the source material for those (they are embedded in the KSP asset packs), so trying to make matching spec-maps was a futile endeavor. Now, if you were intending to completely replace the stock terrain textures with PBR versions (with proper gloss/spec/metal maps) you really wouldn't encounter that specific issue.
-
Thanks for the info. I'll definitely have to take a look at them to see where the configs go wrong. The first bit is a known issue regarding stock parts -- if there are any resources in the prefab, stock code makes a mess of fuel-switching and re-adds those resources to 'live' parts. So there will always be some discrepancy based solely on the resources in the prefab vs. the actual part. However what you are stating is shown for the costs of the live parts sans resources is incorrect, or at least not intended. I'll have to dig into that a bit. You have TextureReplace installed, which is throwing tons of errors. That is its own problem which should be resolved by that mods' author. [EXC 23:12:25.414] InvalidOperationException: Operation is not valid due to the current state of the object System.Linq.Enumerable.First[SkinnedMeshRenderer] (IEnumerable`1 source, System.Func`2 predicate, Fallback fallback) System.Linq.Enumerable.First[SkinnedMeshRenderer] (IEnumerable`1 source, System.Func`2 predicate) TextureReplacer.Reflections.setReflectionType (Type type) TextureReplacer.Reflections.load () TextureReplacer.TextureReplacer.LateUpdate () I think the real issue you are encountering with SSTU though is that it appears you did not install CommunityResourcePack, as the Aerozine50 resource is missing: [ERR 23:09:41.163] Aerozine50 not found in resource database. Propellant Setup has failed. [ERR 23:09:41.164] Module ModuleRCSFX threw during OnLoad: System.NullReferenceException: Object reference not set to an instance of an object at ModuleRCS.SetupPropellant (.ConfigNode node) [0x00000] in <filename unknown>:0 at ModuleRCS.OnLoad (.ConfigNode node) [0x00000] in <filename unknown>:0 at PartModule.Load (.ConfigNode node) [0x00000] in <filename unknown>:0 That error essentially 'breaks' any parts using those resources. Which is quite a few. Your log confirms that CRP is not being loaded. It was included in the SSTU releases, and needed to be installed alongside all the rest of the dependencies.
-
Included in the release. Or can be found here : https://github.com/shadowmage45/SSTULabs/tree/master/GameData/SSTU/ModIntegration/RealPlume
-
While I hate megacorps and the slow erosion of common sense that seems prevalent in the larger companies.... I have to agree with you. Since the T2 buyout, I've only seen large improvements to KSP. Sure, they added some 'paid' expansions (DLC)... but more than likely, it was exactly that which allowed them to make the other changes.
-
Yeah, those were the textures assigned to the models when they were exported through PartTools, back in the day. The textures have since changed names, and are now loaded/assigned by TU.... but PartTools still embeds the original texture name into the model, KSP looks for that texture when loading, and then complains when it can't find it. TU then dutifully comes in behind the stock code and fixes it all up as it should be based on the values defined in configs.
-
Updated release is available: https://github.com/shadowmage45/SSTULabs/releases/tag/0.11.48.160 Few minor bugfixes, merged many PRs, some integration features for use by other mods, and an updated TU that removes the API warning and uses stock reflection probes. See the link above for changelog and downloads.
-
Updated release is available: https://github.com/shadowmage45/TexturesUnlimited/releases/tag/1.4.8.22 See link for changelog and downloads. Mostly notably, switched over to using stock Reflection Probes, and dropped the API check and warning on DX9.
-
Probably asking in the wrong place. This isn't a ULA-replica thread. I have no idea what that rocket is even supposed to be, so certainly, I'm the entirely wrong person to ask.
-
Were you able to track down any further information about this? What is adding the light, why it is positioned where it is, etc? (its not being added by SSTU) Fairly certain it is being added by the mod in question; specifically The Light field https://github.com/linuxgurugamer/EngineLightRelit/blob/master/EngineLightRelit/EngineLightEffect.cs#L294 The code creating the light https://github.com/linuxgurugamer/EngineLightRelit/blob/master/EngineLightRelit/EngineLightEffect.cs#L294 And I think the positional problem is likely to be found here: https://github.com/linuxgurugamer/EngineLightRelit/blob/master/EngineLightRelit/EngineLightEffect.cs#L380-L382 Notably the thrust transform position for the MSRBS is not updated until Start(), which is fired long after OnStart() (and not until just before the first Update()). So at the point where the mod is positioning the lights, the thrust transforms have not yet been positioned for the current part layout. TLDR: - Move your light initialization code to Start() to ensure that any external modules you interact with are fully initialized, and/or reposition them in the Start() call. I would wager this simple change would fix the interaction issues with the SSTU SRB parts (and engine clusters, and other parts... as they all use the Start() based ModuleEngines interaction).
-
Thanks for the craft file. Can confirm the described issues with the craft as provided. Can fix(?) the issues with three simple(?) changes. Enable Autostrut-Grandparent on each of the SRBs. The first test flight the SRBs sagged into the core on decoupling and lots of things exploded Set the bottom thrust limiter on the RBDCs to ~70%. This forces a 'nose out' decoupling (same as offsetting the COM would). When decoupling, ensure that you are flying mostly prograde, or aero forces will push the 'lower' SRBs back into the stack. This is probably the most important bit from my test flights. If I let autopilot run 'dumb', it would be a few degrees off prograde at that point in flight, and cause issues quite often. If I briefly toggled 'hold prograde' before and during decoupling, it was smooth every time. Kind of not surprising considering the decoupling is happening right around max-q for this craft and flight profile. Normally this type of event would be programmed into the autopilot to compensate for such issues (throttling down and/or maintaining prograde (which isn't really a thing on a real gravity turn; you always point prograde)). Note I switched off autopilot and turned on stock SAS 'hold prograde' a few seconds before decoupling. No collisions with central core. A couple SRBs collided after jettison... which is perfectly Kerbal. It does appear that the RBDC lacks some decoupling power at that particular scale and dynamic pressure; the engines aren't giving things quite the push that they need to in order to fight aero forces fully. In my test craft the decoupling was happening much higher up, at much lower dynamic pressure (pretty much vacuum), so the puny engines were plenty. As a bit of a more drastic 'test' you might try patching/editing the RBDCs to increase their thrust and fuel a bit, or adjusting the thrust/fuel scaling factors. I feel the part works fine for my uses and craft designs, but perhaps it needs adjustment for other specific cases or play styles. You know, I never even thought of that issue (the RBDC thrust and its single joint on the SRB)... but that would explain quite a bit of the off-axis thrust that I see on jettison with those parts. The long lever arm + Unity joint slop = inconsistent thrust vectors, just enough to induce some spin.
-
Could I get a copy of your .craft file (assuming it is stock+SSTU only)? My attempt to create a similar craft layout had no problems at all during decoupling of the SRBs. The only changes that I made were to set the RBDC lower motors thrust limiter to 90%, so the upper motor had just a bit more push to it, and to enable 'autostrut - grandparent' on each of the SRBs (so they were strutted to the central tank). The SRBs were left centered on the decouplers, with no offset used. I made those changes before the first flight (standard stuff for my designs), so no idea if they were actually needed; likely would have worked fine without the thrust adjustment, though auto-strut is a bit more of a necessity.
-
They are certainly close together, but it -looks- like there should be sufficient room to prevent basic collisions. Putting together a test craft now and will let you know how it goes.
-
Are you sure all of the SRBs are attached to the RBDC, and not attached to the core? At 2:52 in your video, it looks like two of them decouple fine, but two don't decouple at all? It also looks like the SRBs may be a bit too close to eachother, and are colliding upon initially decoupling (9:53 in the video). Additionally, it doesn't look like there is any gap between the SRBs and the core... whereas there should be if they are placed on the RBDCs properly. It may also be that I'm not entirely understanding the issue? (Thought the issue was that the SRBs were colliding into the central fuel tank, which is why I suggested offseting the parts). SRBs colliding -after- they have been jettisoned though is quite normal for KSP in my experiences. I'll try and make up a quick replica of your craft this evening to see if I can duplicate the issue at least. Fairly certain I've used launchers similar to that in the past without too many problems. Indeed, if all you are wanting to do is to remove the solar panel grid/lattice, editing of the textures (ALL of them) should do the trick. Notably you will need to edit both the DIFF and MET textures, editing out the solar panel bits in each of them as needed. Note that the MET texture contains metallic information in the 'R' channel, and specular/gloss information in the 'Alpha' channel (and possibly AO information in the 'G' channel) -- all channels need to be maintained aside from the edited portions.
-
Please contact SQUAD and tell them that modders need access to ALL of their shader source files then. Basically, SQUAD created some terrible 'icon shader' that is used when rendering icons. They use some very hacky functions in there to boost light levels. But they do not provide the source of these files so that acceptable alternate implementations can be developed. I've opened multiple issue tickets on the subject, and had zero reply. I do not have access to those shader files, and thus cannot duplicate whatever hacks they are using to boost light levels on the icons. Until I am provided with that source -- there is no fix. I'm not going to spend days and days trying random stuff in the hope that something works... it is neither productive, nor satisfying. Indeed, they were 'done' when I uploaded them; I actually used those configs for the development of KSPWheel and all of the initial setup and testing. Worked as far as I knew, and should still work (minus perhaps a few changes to features). The problem is -- I don't use stock parts, nor do I feel like taking time to 'balance' the configs for stock parts that I do not use. Moreover, I have no clue what the intended 'balance' of the stock parts is, as the information that can be extracted from the stock configs is... nonsensical at best (e.g. what is the maximum load (in N / kN) for a stock wheel before it breaks? Where do you find that value in the stock config? What is the maximum wheel speed? Motor Torque?). The values listed in the stock part configs often don't lineup with what is seen in-game, so trying to base any balance around those numerical values is difficult. Basically -- they should work, but I don't personally want to support or distribute them, and nobody else has stepped forward offering to pick them up. (I don't want to distribute them, because I've seen far too many issues and complaints regarding mods 'messing with stock or other mods' parts; so as a rule, I do not touch any parts or values outside of the mod that is being distributed; Case in point.. I -did- distribute these patches for a brief while, and received numerous complaints regarding the changes to modules in the stock wheels.. not that they were broken, but merely that they were changed).