Shadowmage

Now there is a concept that I could see myself picking up (not saying I'm going to though). Develop the framework for others to add the models (the science hooks, some pluggable AI system to interact with animations, settings regarding spawning, etc). I'm big on frameworks (and not so big on modeling/texturing/animating)

After retrying mine yesterday/last night, I found that it is extremely sensitive to... just about any sort of modification. Added ~0.05t to it, and now it barely can hover under full power. Sad times. Even more strange, it seems to get an increase in lift if I decrease prop RPM from 460 to ~400. Really wanted some sort of micro-aerocraft for Duna, but it looks like I'm going to have to go bigger if I want it to work. Trying to use props for lift (trying to stay small) is apparently not going to be sufficient, and might have to switch over to using a dedicated set of helicopter blades for lift. Yeah, been awhile since I've done anything aero on Duna (since before 1.x aero update), and I'm learning that quickly. Always knew to pack extra chutes, but the changes to thrust/drag in flying machines is... odd... to get used to.

Best explained through images I think. When you place a part as you suggest, faking cloning of radial parts, you have one real part (in red), and some clones (in blue), around a cylinder (wireframe). KSP sees these as one part (the white disc) for drag purposes, and has one joint (on the red node). So far, so good. Now, lets add some aero force and see what happens. Add a few kN of drag to each of the parachutes at their attach position, and the parts will end up looking like this: Okay, so the 'fake' parachutes all get pushed out of position due to KSP's joint mechanics. Perhaps not the end of the world for most parts to be offset a little bit? Except for KSPs 'drag cubes'. Now the drag-cube system sees an inclined plate intersecting the part, which it dutifully calculates drag for in its inclined angle, and you might as well have put a wing or control surface there for all it cares. The result is that now you have some odd drag going on throwing your rocket all over the place. This happens even during ascent with the parachutes stowed, simply by the nature of the 'one attach joint, on the side of the part' and the 'disc' created by the drag cube system. Drag pushes on disc, disc rotates around its attach joint (red node), and inclines the other direction; the result is you again have an inclined plane intersecting your rocket, throwing good aero design out the window. I know. I've done this for parts in the past. There is a reason I'm not doing it now In order for it to work you would need to somehow offset the part-joint into the center of the parent part. Which is not directly supported by KSP, and would require someone with knowledge of KSPs internals and their use of joints in order to fix.

I can't agree with the general use-case of that. 90% of the time I want a heat-shield, I already have a probe core. You could easily patch it in yourself though, if desired, or patch yourself a second version with probe core. Edit: It could include decouplers for both ends, with optional staging, and optional jettison-able shroud/fairing surrounding the stowed petals. Can't think of too many other features I would want in a heat-shield of this design. Pretty much all of that, yes. Funny you mention that, as the module was written with a good deal of that functionality in mind. All of the parachutes are already positioned and scaled by the plugin code, so it really just needs some minor adaptation to include scaling of a base model, and all the fiddly UI bits for scaling and parameter setup, and their backend code. What has stopped me is that it is really only useful in a stack-mount setup for part-count reduction, and I rarely use stack-mounted parachutes. There is no way to reduce part count for radially attached parachutes =\ (I guess you could provide larger ones through scaling, reducing duplicate-part-spam a bit for larger designs). Perhaps something to think on and further develop.

Ahh, yep, that makes sense, and would be usable with a part like this. I'll toy around with the concept a bit more in-depth now that I've confirmed we're thinking of the same thing. The bashup earlier for the examples was very crude and not intended for further development, just showing the concept. Unless you wanted to take a crack at the modeling? Fair warning -- even if I start work on this now, it will likely be a few weeks before it will be available and usable. Few other WIP projects consuming large portions of my time that I want to wrap up or get to the next phase (fixes for TU, finishing KF texture conversions + balance, custom TU patch set for stock), and then would need to take the time to actually develop this new part (or part(s) most likely). Likely only take ~1 week for this part once it gets to the top of the queue, perhaps a bit more depending on the complexity of the models and if any variants are created. Texturing should be simple enough / fast enough, and of course we can add recoloring if desired. Might require some minor additions to the plugin code to facilitate interaction of the heat-shield module with an animation module (e.g. heat shield code only active while deployed), but that should only be a few minor edits.

LoL, apparently yeah, quite similar in regards to deployment mechanism. Apparently I'm not the first to think up that kind of setup Yeah... not doable in a 'generic stowable heat-shield' type part. That would require per-engine heat-shield models... that also somehow adjusted to the users selected cluster layout and all of the procedural settings available there. Although, if I were to actually engineer such a design, that is likely how I would do it. There would be a standard heat-shield with holes in it for each engines exhaust, and engines would have small'ish cover-plates that moved into position during heat-shield deployment that filled in the holes in the heat shield.

Your rotor is the same basic setup as mine above; smallest props on the smallest rotor. Try increasing it to four blades per rotor. And then try using a deployed pitch in the range of ~15-20 for hovering (maybe less depending on mass). When I switched from two to four blades-per rotor on the craft, it went from 'unable to hover' to 'capable of controlled and sustained flight'.

@vossiewulf Here is the concept that I quickly mocked up for a stowable heat shield. Three 'layers' of 'leaves' which fold down. The outermost layer is a simple hinge, while the inner layers would require a hinge+strut. stowed: deploying: deployed: I guess I'm curious if this is the same kind of part you had envisioned? (mostly I'm wondering how something like this would help with your situation; how would you mount a heat-shield below the engines without it interfering with their normal operation?)

Its less 'figuring out how to do it' and more 'do I have 6+ months to dedicate to modding in such a feature to an acceptable degree?' Nothing really to difficult, just a few big time-consuming bits, and a bit of scripting: Create a ton of models, textures, animations. The time consuming portion. Seriously. Time. Consuming. Randomly spawn models dependent upon planet/biome, in the area immediately surrounding the player. Entirely doable. Use some 'simple' scripts to add some rudimentary AI. Relatively simple, but can take time depending upon how complex the desired AI should be. Hook into the KSP science system to add science defs and interaction. Not sure on this one; likely tricky, but probably doable. ? Profit!?! Pretty much this I think. (I had a hand in the resurrection of the critter-crawler; it is far less related to npc-animals than you might think; being essentially a collection of wheels synced to an animation)

Hmm... I have an idea Will try and mock it up when next I have some modeling time. Should be relatively simple, if I grasp what you are getting at regarding overall concept (probably not, but gotta start somewhere).

The updated fifth revision seems to fly acceptably on Duna. Main change was to increase the # of blades per rotor, from two to four. Blade pitch acts very strange compared to Kerbin; some difference was expected, but this is just odd. Don't mind the odd planet colors. Just landing in an Ike-eclipse of the sun...

Few pics of the first attempt, that worked so well on Kerbin, but failed to produce sufficient lift/thrust on Duna. All are mostly the same craft at various iterations: ~1.2t, ~48 parts. Infinite flight time in sunlight. Streamlined probe version at max speed: Jeb practicing VTOL Max speed of the crewed version: Which also folds up: And.... props are some kind of magic in regards to drag/max speed. This is a full-speed dive on the craft in helo mode with powered props at hover pitch; it caps out at ~70m/s, gravity be darned. Drops like a rock if I turn off the props though I'll be playing around with making a Duna capable version, and post any successful results.

Lets figure it out then Certainly I can SSTU-ify a part, if we can come up with a functional model. Try radially/surface attaching it to the side of a round tank, where it is not sitting flush. The variant is a 'backplate' or tube structure -- so you don't need extra parts just for a flush mounting. The 'scale' applies only to the backplate.

Yes, and also yes. Last I checked mostly works for most structural parts. Anything without any MODULE's in the config file should not explode the world. Even some stuff with simple modules should be fine, like lights. Anything with a module that messes with physics like engines, rcs, parachutes, wheels/gear/legs, etc. is likely to do strange things (or just NRE endlessly). Even when it works though, with the current implementation, it can mess with KSPs approximated physics -- mostly drag and thermal. Also don't have them as a root part, I don't think they can have children parts, they add their mass to the COM of their parent part, and likely a few other gotchas that I've forgotten. To play around with it, simply patch that line in existing parts to the same value as is used in the stock small science experiments (don't remember exactly the name, or correct value, at the moment).

@Manwith Noname I've tracked this down as to what is causing it. Details can be found here: https://github.com/shadowmage45/TexturesUnlimited/issues/72 You can try adding to the MATERIAL blocks a new line that states 'mode = create' to verify if that is the cause (and solution). I'll be doing some verification of this myself as well. I'll be updating TU to change the default mode to 'create' in the near future, as that is the intended default use of the mod and how I desire to write configs. The other option is 'mode = update', which does the current behavior and updates the in-place texture set; useful for MODEL_SHADER, but plays havok with runtime texture switching as you and I have seen; it might also have some use with the part-variant system to adjust existing variants (but the preferred method would be to redefine them entirely through TU).

Different shaders. The specular-in-alpha channel is a legacy shader, using basic Lambert lighting (or some derivative/relative). The (mapped) shader uses a (hacked/partially implemented) form of PBR lighting, and uses global-illumination and environment lighting in its calculations. (Kind of guessing here that you are referring to the two different shaders 'KSP/Bumped Specular' and 'KSP/Bumped Specular (mapped)') Background: I know a thing or three (or ten) about Unity and KSP shaders.

Likely yes. I had to use this exact function for something recently, but can't for the life of me remember what it was for (or even what project it was in). Projection of something onto something... IIRC I was doing orbital mechanics work at the time, so I was likely trying to find something relative to the ecliptic. https://answers.unity.com/questions/25110/what-is-vector3exclude-for.html https://docs.unity3d.com/ScriptReference/Vector3.ProjectOnPlane.html

Thanks for the links. Certainly more information than I had before Looks to be the trick is providing separate lift and thrust mechanisms. I'll post up some pics of my little beastie, and try and document whatever I find for a working solution. From the examples you've linked -- I might have been trying to go 'too small'

Yeah, I think it was part of an unfortunate batch of changes I made when I was last actively working on the mod. Lets just say I have since learned to not make changes just to appease others, unless those changes are also personally desired. Yeah, as long as you are fully defining your texture sets there really shouldn't be an issue (anything not defined should use the default value from the shader; not carry across some random, arbitrary, and unknown previous value). The fact that it is currently not working with that setup (or at least, has some issues) would lead me to believe that I need to fix the mod itself Pretty sure I'll have this cleaned up / fixed up for the next release (which will hopefully be this weekend, time permitting).

With current KSP code -- yep, that's the only way. With some (relatively simple) edits to KSP code -- you could easily have parts still as separate entities, but all sharing a single RigidBody for the entire craft. The only time there would be an explicit need of multiple rigidbodies would be robotics type parts. The idea behind this is for Parts to still be individual entities (e.g. can explode independently of eachother), but all share a single RigidBody. No need for joints at all except specific exceptional cases. Only minor changes in KSP would need to happen for this to work -- most of the groundwork is already in place for the 'PhysicsSignificant' flag on parts (those parts share their parent rigidbody as far as I'm aware, and are not actually connected by joints). Now... this would also remove 'noodle-rocket' induced RUD entirely; there would be no joints, so there would be no noodling. Whether that is good or bad, I'll leave up to personal opinion (I personally think it would be great). (the limitation is that you can't monitor the forces on the joints between sections, without actually having those joints; no joints = no bending rockets). Not entirely realistic, so perhaps some analytical method should be developed to still allow for actual, real, physical, stress-induced RUD (as opposed to sloppy-Unity-Joint induced shake-itself-to-death RUD). Absolutely. SQUAD, there's a hint for your next DLC. I would gladly pay for a DLC that introduced dynamic part-welding and reduced/removed the physics bottleneck regarding part-count. It seems to be much better than it was in the early days, but part-count is still the single most limiting factor of my craft designs. Anyway... I came here to say 'My comp runs KSP at 60fps, even with tons of mods, and it is ~8 years old'. Stayed for the discussion

I believe that was by design/by request. Someone had requested that I retain existing materials and their parameters, so that they could write shorter patches/configs (e.g. so they wouldn't have to re-specify the current settings or re-specify the same texture across multiple texture sets / so they only had to specify the details that were being changed); which brings us to the current state-of-affairs. I also believe there is a way to tell it to 'don't re-use the existing material, create an entirely new one', but don't remember the method off the top of my head. I'm beginning to believe implement such a change was in error, and that I should have stuck with the default implementation of 'use a new material unless explicitly stated to re-use existing'. Seems that would solve these little oddities quite nicely, and fits more with the intended method of writing configs and patching things. Either way, thanks for the added information -- kind of confirms a suspicion I was having about what is going on. I'll let you know what the outcome of the investigation is (likely outcome is that I change some of the default behavior in the mod back to what it was/should have been the entire time)

Stock heat is balanced around stock atmosphere and stock scales (otherwise there would be close to zero heat during re-entry). If playing an an recaled solar system, you need to adjust the atmosphere thermal parameters accordingly (though, this should have been done by the author of the rescale pack); otherwise you get insane heat levels during re-entry. Not saying that is definitely what you are seeing, merely offering a potential explanation for what seems like an abnormal situation (e.g. boosters should not need heat-shields for basic sub-orbital reentry). Just thinking of the Space-X flyback boosters. Certainly no heat-shields needed there. Or the Space-shuttle SRBs... just some parachutes there.

Yep. That was my thought as well; pentagon/hexagon shaped petals that folded down around a center piece, or even truncated wedge-shapes that folded down. As you say though, it is hard to get them to all stack and fit while collapsed/stowed without clipping into eachother. The issue with an iris shape is much the same for an iris that expands out from the center -- you can't stack all of the petals in the center without clipping (or literal stacking). The standard iris design (closing from the outside) is obviously of no use for this kind of setup. True, to a point. But mach 15 at 0.0001 atm is basically just a gentle breeze at 1atm, which is what these inflatable units are supposed to support. Lots of heat, but not much actual air pressure, so minimal structure is needed. Now, hitting mach 15 much lower in the atmo -- yeah, that'd crumple and crush an inflatable shield. No doubt. I don't think that is what they were intended for though (and KSPs indestructible inflatable heatshield is just poor gameplay). IMO you should be able to recover launchers and most boosters without heat-shields. The engine itself should provide sufficient heat resistance for sub-orbital re-entry, which should work for most first and second stages. I'm not even sure where or how a heat-shield would be placed on a lifter/booster that would aid in recovery. Unless I'm not fully understanding what you are trying to accomplish? (entirely possible... almost certain).

Good to know. I'll be adding proper attribution for all of the mask files that I'm re-using, so good to know where they came from and whom to give credit Understood, and no worries. I think the process that I'm going through now is exactly what will be needed to get things to a 'stable' state (as far as use for patching existing parts is concerned). Was hard for me to know what needed to be fixed/changed/adjusted without going through the process to actually use it myself (obv. it worked for what was needed in SSTU; but that is a bit of a special case, being authored for recoloring from the start, and integrated closely at the plugin level). Up until now I've only toyed with the concept in limited fashion, only targeting a few specific parts with very basic configs. Now that I've spent a fair bit of time writing recoloring patches, I have a much better grasp regarding what is functional, what is broken, what is a pain to deal with, and the other concerns specific to patching of existing parts. Overall the process went about like I would expect for writing up the configs though. A bit time consuming and very repetitive; some definite head-scratching moments trying to figure out some of the more odd edge-cases and seldom used features, but the core of the process seems to work exactly as it should when used as intended. If you still have those new masks around, and don't mind sharing them, I'd certainly be willing to write up configs for those as well. The more coverage the better Thanks for the info; I'll add those to the list of things to investigate (if you have specific examples/steps for reproduction it might help). I've definitely noticed some issues with texture sets affecting multiple parts in the editor(children parts), and a few instances of shader parameters sticking between changing of sets. Haven't noticed anything with layer swapping (example?), nor have I run into any new issues with the TUPartVariant module, but I haven't toyed with it much (again, specific examples to reproduce could be helpful). In the end I'm not meaning to usurp or replace the work you've done with Textures Unlimited Recoloring Depot, only looking to provide a known set of functional patches to use for examples for others to derive their own work from, and in the process sort through some of the usability issues and finish development of my external toolset (the one that calculates normalization parameters for you). Still undecided if I want to actually release it, or just leave it as an online/hosted example set/personal project. If you wanted to use any of the configs that I've written, feel free to grab them. They have been written entirely from scratch, in a 'one-config-file-per-part' setup, so should be easy to pick apart specific bits if needed. Or if there was any other level of collaboration desired please let me know -- I'm open to options. Apologies on that, as I probably should have contacted you first regarding collaboration before posting anything on the project. Certainly not too late to set something up though if desired

Thanks for the confirmation. Yeah, that looks like the same icon-shader issues that I thought I had cleaned up. What happens is that screen coordinates are inverted in OpenGL, and the icon-shader relies on screen coordinates to set up some screen-space based clipping. At various times KSP has passed in regular coordinates, or pre-inverted coordinates, so I've played a bit of whack-a-mole with trying to keep up with their 'fixes'. To make things more complicated, KSP manipulates things in plugin code, but I have to somehow handle it all entirely on the internals of the shader-side of things. Fun stuff (wanted to open an issue on Github to track it, but apparently Github doesn't want to load the TU repo at the moment; I'll try and remember to open the ticket later). In general development news... I finally decided to sit down and create some real examples/configs of how the recoloring system is intended to be used. This set of configs and textures will provide: Examples of adding recoloring to existing stock/mod parts. Examples of use of TU with the stock part-variant system. Examples of use of the 'normalization' system for recoloring, which allows use of existing textures and faithful color reproduction between different models and base textures Show how to add texture sets and texture-switching to parts without messing up existing shader parameters, without using MODEL_SHADER, and allowing drop-in compatibility with existing save-games. Near-complete set of configs and textures to add recoloring to Stock (non-DLC) parts. The initial set of masks are based on those from TURD, which I believe have evolved from KerbPaint originally, used under the terms of the licenses. I'll likely be redoing and replacing several of these masks, and will be creating quite a few new masks for parts that were lacking them (mostly the reworked stock parts). Would not have been possible without those mask textures (or at least would not have been a project I would consider undertaking), so if you enjoy these patches/configs, please send some 'thanks' towards those authors. The first pass of the project is done -- configs have been written for every part for which a mask texture existed (204 out of 305 total parts; took about ~25 hours). Next pass is calculating normalization data for all of these, which should be quite a bit faster than the initial config write-up. Finally I'll work on creating masks for the parts that currently lack them, and redoing/updating masks for a few parts that I think could be done differently; this will be a very time-consuming step, with each new mask taking ~1 hour to make (more or less, depending upon complexity and messiness of the original texture and UV maps). For the longest time I was resistant to making/publishing any config sets myself, but after the ongoing repeated requests for recoloring configs, and knowing the struggles others have endured trying to write them up and get them working, I decided it was time to just put something together. That, and I was so sick of using stock parts alongside SSTU and having them look terribly out of place due to difference in coloring or shaders. If/when it is released it will be as an optional/secondary download. On the subject of releases -- I'll likely make the first releases available after I complete the normalization data pass on the configs. At that point the existing configs should be usable and functional, and can work on adding the rest of the missing parts (new masks) in future releases. Until then the repository is public if anyone is inclined to check it out ( https://github.com/shadowmage45/STUCK ), just note that I will likely not respond to any bug reports/issue tickets until after the first release. Only have a couple of images at the moment as this project is still very much WIP: Preview of the AERO parts, showing mask colors on all parts. Recolored stock fins to match one of my SSTU rocket paint schemes: And in further general development news: I have noted a few bugs that have crept into TU in the past few releases that I'll be fixing up shortly. Also may be adding some additional controls to the recoloring functions in the shader to allow for specifying the detail extraction and application method (add/mult, raw/proportional). Might also be adding an additional control the recoloring-UI as a user-controlled 'detail multiplier'. We'll see.