ringerc

@zer0Kerbal has expressed interest in adopting this, since I don't have time for it. I've made them a SpaceDock author. I'll copy the notes I made in a PM here, in case others are interested. ---- The main issue I ran into with this mod btw was that KSP doesn't have a sensible way to achieve a sensible CoM offset. Its physics start getting seriously wacky. Lets just say I couldn't copy the Apollo data I studied verbatim . Balancing it so that the module itself had a reasonable offset for aerodynamic flight wasn't easy without tending to tumble, especially since it also needs to naturally re-orient into a blunt-end-first re-entry position for uncontrolled/ballistic re-entry. But then keeping flight characteristics reasonably consistent with an attached heat shield wasn't simple at all due to KSP's faked up funky physics. With a strong enough CoM and CoL offset to allow the command module itself to retain desired flight characteristics I found that heat shields tended to enter a wild flipping fall where they spun increasingly rapidly in an absurdly unrealistic way. Or they'd slice through the air sideways like some kind of super-aerofoil and fly absurd distances in wild curves. I was never quite satisfied with the outcomes there. I suspect a workaround might involve some combination of changing the shield-to-capsule mass ratio, or using C# to dynamically change parameters based on whether there's an attached heatshield. I also found that the thruster positions are part of the actual model, not the part definition. So while you can try to add built-in RCS to modules, they won't work unless the original model has RCS placed in its metadata. I know enough 3D modelling for basic 3D printing use (openscad) but have no idea how to model parts for KSP let alone edit existing models, so that meant I couldn't add the built-in RCS I wanted for the basic capsules. I wish Squad would add that. I had intended to explore advanced tweakables to see if I could add x/y/z CoM offset controls to some parts, with some kind of nonlinear price and extra mass cost scaling added to discourage abuse. But never had time, though it'd be fun to to. Ideally I'd like to model a new adjustible mass slider part that has an imaginary internal ballast it can slide in 1 or 2 axes, so you can use it instead of RCS for flight control and to adjust mass as fuel is depleted. Or clone and repurpose something like a SAS module or fuel tank model for the job. That would go fantastically with the new robotics controller system too, since you could set it to slowly adjust the offset during ascent, write basic autopilot guidance descent commands, etc. If I had time to learn more of the semi-documented internal APIs exposed to mods in KSP I'd probably be able to achieve more of this, but it's just not going to happen this century.

Thankyou thankyou thankyou. Why the stock game doesn't use SDL joystick support - when the control configuration UI obviously supports it - is beyond me. Finally I can fly.

Hi folks I'm loving these contract enhancements. But of course I probably wouldn't be here if I hadn't encountered a problem. I run KSP on a laptop that is extremely lacking in grunt, so I leave the option to declutter KSC enabled, and limit max debris to 50 (!). Either because of this, or perhaps my own unwitting mistake, the Training Drill appears to have been recovered or destroyed while I had a mission active that required me to crew it. It wants me to put 1 to 4 crew on "Training Drill (TBD)". The mission is not failed, but cannot be completed, and seems to just be stuck. Any thoughts how this could occur?

How practical would it be to take the .mu reading code and teach it to dump the part properties to the command line instead? I'm looking for a way to see the CoG, CoP etc baked into the part, and it's amazingly opaque in KSP. edit: https://github.com/taniwha/io_object_mu, python dump.py /path/to/KSP_linux/GameData/Squad/Parts/Command/Mk1-3Pod/Mk1-3.mu shows me the model metadata, but I don't see the CoG there. Hint? Is it part of M1-3 Pod lp (-1.4010000228881836, 0.0, 0.0) lr (1.0, -0.0, -0.0, -0.0) ls (1.0, 1.0, 1.0) Edit, from the code print("%s lp %s" % (" " * level, str(trans.localPosition))) print("%s lr %s" % (" " * level, str(trans.localRotation))) print("%s ls %s" % (" " * level, str(trans.localScale))) so "localPosition", "localRotation" and "localScale" respectively. I'm assuming that localPosition is the default CoM, but some insight would be a huge help. Also, do your vectors have the same component-order as the ModuleManager vectors? Because lp would make way more sense if it were (0.0, -1.4, 0.0) for the CM... (Fascinatingly, this shows me that the mk1-3 pod does have RCS ports in its model, but they're unnamed. Wonder if that means I can't enable them from ModuleManager - I've wanted to make RCS stock on all pods). Also, Kia-Ora from an Aoterora expat in the big flat red place.

Early experiments in lifting pods: https://imgur.com/gallery/trBLIAq

Is that with RealHeat or scaling mods? Or stock? That does seem odd, anyway, especially as I cut the ablator tuning mods out in the last revision, focusing just on making sure the part can fail when depleted. I want to revisit burn rate tuning, but need something to go on in terms of "reasonable" burn rate, weight, mass, etc, and probably need to make the shield's conductive insulation properties a nonlinear function of its remaining thickness to allow for gradual failure. I've been studying Apollo Thermal Protection System documents a little bit. Based on that I'm working on making the pods and heat shields naturally re-orient to produce a gently lifting re-entry, not a purely ballistic one, and I'm looking at what the weight and burn profiles should look like. (It's very fiddly, so I'm looking at adding tweakables for CoM/CoP/CoL on parts during experimentation). I'll probably add upgrades to improve ablator materials in higher tech levels in KSP, but it's actually amazing how good the 1960s ones were. The Apollo capsule could have probably survived re-entry from interplanetary velocities (though the astronauts might not have).

... which is fine unless you want to mute warnings about out-of-comms from a probe or vessel that is currently out-of-comms Yeah, this confused me too. Also that it's unclear what the bounds of needed shielding are in the UI (but hey, space exploration isn't an exact science sometimes right?) It gets a bit weird when you can have one unpressurised capsule with scrubbers, and one pressurised capsule with no scrubbers. But I just figure the kerbals have done some creative cross-wiring. Anyway, @N70 thanks for the fantastic mod or continuation of it

Thanks for that. I'd given that a go already, but all I see is "connection in progress... connection timed out" in the "[spacecraft name] VESSEL CONFIG" menu that appears. Maybe you can't mute it without being able to talk to it o_O?

I didn't find any way to mute warnings about unreachability for a vessel, especially without muting everything. I'm playing with very limited comms, and the autopause for going into / out of comm range is unfortunate. A look in the source and changelog shows that messages may be muted with CTRL-N. But that seems to be global. I'm looking to mute specific warnings on a vessel, like "I know comms are down, but still tell me if my kerbals are suffocating". Am I missing something? Or is it not implemented? If not, I might have a go at a patch, though it'll be my first non-trivial KSP work and C# coding, so we'll see. (I also want to teach MechJeb how to lock the controls when out of comms range, so maybe this'd be a good starting point before I try getting my hands really dirty in MechJeb).

It's great that you're experimenting with that. I don't really want to pursue anything with RealHeat unless it's actually meant to work with stock though. I'll gladly take patches if you find changes are needed to make it work, but don't intend to look into it myself.

OK, Realism Overhaul, RSS etc isn't currently on my radar, I'm trying to keep it a bit more stock. So for now I won't chase RealHeat. As for ablator depletion, I agree it needs some tuning (RealHeat aside). My earlier changes were too heavy handed as they attempted to make the part fail due to simple heating when depleted, without changing the conductivity or maxTemp at depletion. I may want to turn up depletion a bit, but it doesn't need to be drastic - the ablator shouldn't generally be depleted severely, and making it easily depleted makes repeated aerobraking passes a real problem. I'm more likely to make the conductivity protection proportional to the remaining ablator, or (better, if I can make it work) to the rate of pyrolysis in the last physics frame. So you need a heavier shield for a more demanding re-entry. The main goal was fixing those BS 0-ablator shields, though, and that's working.

Gotcha. The SpaceDock page is outdated then, might be worth editing that + removing or editing the gitlab to show the new location.

I wonder if @ShotgunNinja would be willing to chnage the tagline for https://github.com/ShotgunNinja/Kerbalism and the wiki at https://github.com/ShotgunNinja/Kerbalism/wiki to reflect the new line of development? For other readers, you want https://github.com/steamp0rt/Kerbalism or https://spacedock.info/mod/1774/Kerbalism . (https://gitlab.com/N70/Kerbalism outdated too according to follow up post)

Thanks! That's fantastic. I'm really enjoying playing it, especially with my heat shield tweaks on top to make heat shield failure a concern. I know how long this stuff takes (I'm a dev by trade) so thanks _so_ much for the time you and others have given.

Good point. Fixed. Interim release posted at https://github.com/ringerc/KSP-DRE-Lite/releases/tag/0.2 . I haven't updated SpaceDock yet, I want to do some QA, look into interaction with RealHeat (which I didn't know about), etc. It's a real shame so many mods are updated on github and don't have metadata on spacedock etc, so you'd assume they're dead. I'll try to keep mine up to date. Really, SpaceDock should offer support for pulling releases from GitHub automatically... Good point. Fixed. Interim release posted at https://github.com/ringerc/KSP-DRE-Lite/releases/tag/0.2 . I haven't updated SpaceDock yet, I want to do some QA, look into interaction with RealHeat (which I didn't know about), etc. It's a real shame so many mods are updated on github and don't have metadata on spacedock etc, so you'd assume they're dead. I'll try to keep mine up to date. Really, SpaceDock should offer support for pulling releases from GitHub automatically...