Shadowmage
-
Posts
4,628 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Everything posted by Shadowmage
-
Pretty much. The two systems are mutually exclusive -- you either use the Stock PartVariant system (and thus use Variants that link to a single texture-set), or you use the KSPTextureSwitch system (and directly switch between texture-sets). They cannot work alongside eachother without issues, mostly due to the stock system stomping all over materials and settings. They both use the same KSP_TEXTURE_SET config definition/data construct, so at least there is a bit of consistency in the mod in that regard.
-
With the stock wheel modules? Absolutely not. Using KSPWheel -- yep, as has been posted by others, they have already been converted and available for use since.... a long time ago (something like the 1.4 era of KSP?)
-
Your thinking of it incorrectly. You need to make a new variant per texture set that you wish to add. When PartVariants are in use, they control the texture switching, TU just provides the shaders (and some hooks to use those shaders properly). Yep, both serve the same purpose in the end -- to use the TU shaders. Its just that stock made this terribly terrible 'PartVariant' system that didn't play nicely with... well... anything... so I had to come up with a special method to allow for still patching shaders/parameters while the PartVariant system was in use. Isn't that always the way it goes? Set up a presentation for something, start going through it, and then its like 'oops... I guess that needs to be fixed' (at least it never fails for me, no matter how many times I check over everything and test it prior).
-
PartVariants don't use the KSPTextureSwitch -- they use the TUPartVariant module, and are set up slightly differently. See an example here: https://github.com/shadowmage45/STUCK/blob/master/GameData/STUCK/Stock/Aero/aerodynamicNoseCone/aerodynamicNoseCone-TextureSets.cfg
-
In reality -- shouldn't be too much changed with TU. I'll have to recompile my shader bundles for the new Unity Player version, that is a given. Beyond that, I might have to (hopefully) remove the code that 'fixes' the part-icons, depending upon how well that feature was fixed up (or if it was fixed up). As TU basically already 'expected' DX11/OpenGL Core to be used, there isn't much else that should need to be changed or updated. Certainly the change won't deprecate TU, as I doubt they've included Standard shader variants in KSP proper, and even if they did, I guarantee they aren't including the full texture-switch and recoloring systems that TU has implemented. Shouldn't be any breakage on the config end of things either -- as far as I know at this time, nothing should really be broken by the update. I suppose we'll find out more whenever 1.8 drops (ETA: ~ a month from now?).
-
Indeed. Which only serves to complicate the entire process from a (re)texturing perspective; esp in regards to utilizing different shader styles on a single part. Only choice is to use a single shader, and create any custom texture maps that might be needed for that shader.
-
Pretty much that ^^. Even without creating new metallic textures or normal maps, just making the masks alone, can take upwards of ~2 hours per part depending on how messy the original UV maps and textures are. Its slow work, for me at least.
-
Hi, and thanks for the interest. Unfortunately I'm not aware of any fully functional recoloring config sets. The recoloring-depot is likely the closest that is available, but I'm pretty sure it is a bit out-of-date at this point. I do not provide these patches/config sets myself, and cannot provide any specific support for them. I was/am working on developing a stock-recoloring mod myself, but the work is extremely slow and time-consuming, and there is a lot of it (300+ parts, often with multiple textures each), so it likely won't be available anytime soon. If you are truly interested in recolorable parts, I would take a look at SSTU -- https://forum.kerbalspaceprogram.com/index.php?/topic/117090-wip17x-sstulabs-low-part-count-solutions-orbiters-landers-lifters-dev-thread-11-18-18/ -- it is the only mod that I'm aware of that has properly implemented the recoloring system, and a large majority of the parts in it are fully recolorable.
-
Any way to make the stock parts internal cutout only for windows?
Shadowmage replied to ssd21345's topic in KSP1 Discussion
The cutout overlay is built into the model. There is no way to 'fix' the issue without a replacement model, with the proper cutout overlay. So, in reality, needs to be fixed by SQUAD. -
TU tutorials/info: https://github.com/shadowmage45/TexturesUnlimited/wiki/Config-Documentation And some samples I was/am working through to convert stock parts to use recoloring: https://github.com/shadowmage45/STUCK I'm also working on helping another user convert some parts to use TU, so I'll try and re-use the tutorial/info that I'm putting together there, and post it up here/in the TU thread as well for general use.
-
Ahh, indeed I hit the inspiration last night while laying in bed, and didn't read the other posts before replying. Glad you got it figured out The rest of the settings that will need to be changed are mostly model-geometry related, and aside from the 'height' (which needs to be exact) can all be approximated values.
-
Remove the MODEL node from the original config. SSTU adds the models through the SSTUModularEngineCluster PartModule, and if one already exists, the plugin won't touch it (hence why you end up with multiple models; the original model + the ones SSTU adds for the current configuration). Please let me know if that does not resolve the immediate issue (obv. there is more work to be done on the numeric/values config; but the above should solve your duplicate model issue).
-
I would need to know a bit more about the part in question. Which engine are you attempting to SSTU-ify? Stock part, modded part? Does it use ModulePartVariants? In general it should be doable for most engines from most mods. There might be situations where there is plugin/PartModule incompatibility, but I can't think of any specifics at the moment.
-
Things that will make me not want to buy/play a KSP2: Noodle-rockets / Unity Joints -- this is a no-go. Floppy rockets are not realistic; not only unrealistic, but terrible for performance. Part-Count contributing to CPU load. If part-count is the limiting factor for performance, that manifests as a CPU bottleneck, that's a no-buy from me. (this goes hand-in-hand with the first point re: Unity Joints) Arbitrary limitations on wheels/wheelcolliders (this is more of a Unity thing). Must be able to design tank-track like parts; e.g. KerbalFoundries parts. That means no more arbitrary z+ axis orientation limit on WheelColliders, and the ability to re-orient a wheel-collider relative to the rigidbody on which it operates. GC-based stutter still being present. Basically... not much directly gameplay related, and its all engine-level issues that would stop me from buying the sequel. I would buy a KSP2 for the technical advances; if those have not been done, there is no reason for KSP2 to exist in my opinion. I can get over some of the 'gamey' stuff that they've announced (e.g. magic-tech), as mostly you could simply not use it / play by house-rules; but if the game-engine itself isn't capable, not much can be done about that post-release.
-
Notably, its a problem with the way the PartVariants function, and the fact that they -all- use a SharedMaterial per variant (rather than per-part). E.g. multiple parts with the same variant all share a material (that is STOCK code doing it, not TU). What needs to happen, is that this is changed to a per-part shared material instance. TU doesn't cache anything. Yeah, after I've already lost countless hours dealing with fixing their lack of caring. At this point.. it is me who is about to exhibit a lack of caring. Edit: That probably comes across much more negatively than is truly intended. Yes, I'm a bit frustrated by their development route (and the entirety of KSP2); but I'm also happy they are finally making the changes, and am excited to see how much stuff was 'fixed' (but also quite scared to see how much was broken or still not fixed).
-
Pretty much exactly that. The only mention that I saw regarding technical details of modding was a statement about 'modding tools are being written using LUA' (paraphrased from memory...). Trying to find the specific post that mentioned it, but not having much luck at the moment (it was a compilation of notes/transcript from some videos or interviews that was compiled by another forum-user...but don't remember their name offhand either). Which sparked this whole thing off. LUA has its purposes.. but plugin authoring is not one of them. I thought it was an extremely odd decision and course of action for them to take, which is why I opened this thread for further discussion. If we can be reasonably confident that plugins will still be authored using c#, then I would say this thread can be closed, as there is nothing really to cause concern. (I'm perfectly fine with some LUA based tools being included, esp. the sort that you mention regarding external (or internal) automation tools -- that is exactly what the language was meant for, and a perfectly suited case for its use) Thanks for the input and info (and feel free to close/lock this thread to not continue discussing false info and speculation)
-
I can accept that argument for what it is; valid point. LUA scripting certainly is easier to get into than learning a full language + environment + all of the tools. Indeed -- its fine for occasional scripting, something that runs every few frames, or every few seconds, or by occasional event/trigger. But I would never to do physics calculations with it, heavy math, or even anything more than a line or two that had to execute every frame. (apparently, since the last time I've used it, LUA has JIT compilers available...which could put it much closer to on-par with C# from a speed perspective; still not fond of its lack of strong syntax/structure for larger projects) That would make sense, and could actually be a functional improvement over what we have now. Hopefully someone can confirm. The LUA end would be a built-in KOS sort of thing, for basic scripting tasks, which could interact with the KSP API and any exposed mods' APIs; and leave the heavy lifting and complex calculations to c# or c++ native code.
-
Title says it all. I believe it is a terrible idea from my experience with the language. LUA is an interpreted language (read: slow to execute, slower to interact with external data and code), has minimal syntax structure (bad for people who like structured code), and is not suited to large or complex projects due to lack of decent IDEs and standard external libraries. Now, I actually like the LUA language, am decently familiar with it, and have used it quite a bit in the past (for very small projects); but it is that familiarity that leads me to think it is not a good choice for a programming language for mods in a physics-based game -- you want precompiled (or at list JIT'd), as close to the metal as possible. I could see it being used for actual scripting in-game; e.g. scripting your own autopilot functions per-mission profile; but using it for full mods is like building a house from popsickle sticks -- its just the wrong tool/material for the job. As nobody else seems to concerned with it, I thought I should at least voice my opinion and concerns. Interested in hearing others' opinions, thoughts, and/or more information regarding why LUA might be a good choice.
-
Sweet, good to know I wasn't imagining things (I guess I need to finally finish the balance patch and push an official KF update...)
-
On the KSP2 front -- I should also note that they have stated that mods will be scripted using LUA. So mods won't even be first-class-code anymore, but will be relegated to second-class citizens with access to only that which is exposed through the API. Furthermore, as it will be running a script-interpreter to run the LUA mod scripts, these will be slow-as-dirt for any sort of complex computations (e.g. doing lots of simple math). Not sure who was in charge of that decision, but they should be fired for incompetency. Nearly every single thing that I read about the new game makes me want to pretend the entire thing doesn't exist, like it is all some bad dream that will go away when I wake up. Sadly, its still there... At this point I'm kind of over it, and planning on winding down my KSP modding over the next few months. Too little, and far too late. I've already spent thousands of man-hours on fixing their problems, and I'm not going to get that time back just because they finally decide to upgrade. Thanks for the info though -- I'll def. look into it; not calling it quits yet, just very fed up with the state of the game and development. I'll take a good look over the next update when it is available and re-examine my plans at that point.
-
LoL, yeah, I occasionally add a bit of humor to things, and sneak in the periodic easter egg
-
I'm not referring to a hard limit enforced by the game (e.g. an arbitrary limit). I'm referring to that the limiting factor for performance in regards to a craft construction will be the overhead load induced by the physics connections (joints) between parts, and the overhead from processing that many separate physics entities. So, there will still be a limit on part-count where beyond that point the game is simply unplayable due to low frame-rates. This is unacceptable in a sandbox style game where the entire game premise is designing craft from separate parts. Unacceptable. I can understand a few hundred or few thousands of separate craft causing slowdowns. But merely one single high-ish part-count craft? I'm sorry.... what year is it again? The only limiting factor for 'part count' related to performance should be due to the actual rendering of the polygons from those parts. And mostly I'm bashing on it because they have, once again, chosen to go with 'parts joined by Unity Joints', which is the entire root of the problem, and my single biggest gripe with KSPs 'engine'. Hmm.. what? Did I make some part that I've forgotten about?
-
Well, from everything I'm reading and seeing on KSP2 -- its going to be a 'no buy' from me. Part count limits, 'metallic hydrogen' fuel, magic-tech engines, floppy noodle rockets. Its like they took all of the bad things from KSP1 and used those as their 'advertised features'. Exactly the reverse of what I was looking for.
-
Thanks for the confirmation and info. Are there any errors in the log-file? I'm pretty sure that I had fixed the issue, but there is a chance it was only fixed in KSPWheel and the update didn't make it into KerbalFoundries, so I'm going to do some testing to verify. You can also try and update your KSPWheel manually, by installing from the following -- https://github.com/shadowmage45/KSPWheel/releases/tag/15.13.32 Will let you know what I find out
-
What version of the mod are you using? There was an issue with that a few versions back, but it should have been corrected in all recent releases.
