ringerc

Members
  • Content Count

    59
  • Joined

  • Last visited

Community Reputation

23 Excellent

About ringerc

  • Rank
    Baby modder

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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.
  2. Huge thanks for this. After wrestling jstest and /dev/input/js0, SDL environment variables and more and simply being unable to make KSP see my joystick ... magic. Imagine, if the core game ... used SDL. Which makes joysticks easy. Unless you break it completely... somehow. Even better the breakage is silent. KSP doesn't appear to attempt to find the joystick at all. Search hints: KSP joystick environment variable SDL SDL2 SDL_HINT_GAMECONTROLLERCONFIG ksp joystick not detected ksp joystick not working afbw advanced by by wire oh my god just fix the bug
  3. 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?
  4. 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.
  5. Early experiments in lifting pods: https://imgur.com/gallery/trBLIAq
  6. 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).
  7. ... 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
  8. 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?
  9. 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).
  10. 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.
  11. 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.
  12. Gotcha. The SpaceDock page is outdated then, might be worth editing that + removing or editing the gitlab to show the new location.
  13. 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)
  14. 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.
  15. 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...