Jump to content

ringerc

Members
  • Posts

    60
  • Joined

  • Last visited

Everything posted by ringerc

  1. @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.
  2. 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.
  3. 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
  4. 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?
  5. 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.
  6. Early experiments in lifting pods: https://imgur.com/gallery/trBLIAq
  7. 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).
  8. ... 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
  9. 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?
  10. 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).
  11. 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.
  12. 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.
  13. Gotcha. The SpaceDock page is outdated then, might be worth editing that + removing or editing the gitlab to show the new location.
  14. 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)
  15. 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.
  16. 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...
  17. Comments as a newbie: Humidity control is darn confusing. Pods don't have humidity control by default, and it's not really very discoverable that humidity is even a thing or that pods can be configured to change which life support modules they have. Most importantly, the mission planner doesn't seem to know anything about it, so your mission can seem to be good to go but your kerbal will probably die in a hurry. Jeb's pod is still orbiting with his electrocuted corpse inside. With an early mission being to keep a kerbal in orbit for 30 days, that's a bit tough. I suggest lowering that to 10 or 15 days, so you can put them in an unpressurised pod, then add a long term mission once they can survive. Or defer the mission spawn until you have either additional life support modules or docking ports. The only way I see to do it at low tech is to launch with two pods, which is just hacky and kind of nonsensical. So if you hear that Jeb has "clamy hands" (should be "clammy") - that's what's going on. Get down. Fast. Extending "Engineers report" to show * Fuel cell consumes hydrogen, but none is available; and * No humdity control warnings would help. BTW, I did get it done ... he just went completely mad and screamed, pushed random buttons, and broke stuff. Nothing vital. Well, too vital.
  18. I've been playing it myself with Kerbalism, and that shows I need to make the ablator behaviour closer to stock, because the Kerbalism-tweaked parts cannot survive the temps of the tweaked ablators. The fairly extreme parameter tweaking was done in an attempt to create a shield that would overheat and fail when depleted, but work fine until depleted. Now that I have a behavioural hook to change the conductivity and maxTemp when depleted, that tuning is much less necessary, and I'm inclined to remove it entirely. I'll ship a disabled-by-default MM config for it. Try deleting everything in `ImprovedAblator.cfg` except @PART[*]:HAS[@MODULE[ModuleAblator]]:FINAL { @MODULE[ModuleAblator] { // Override the stock ablator implementation wherever it is used @name = ModuleAblatorImproved } } and try again. I'll fix that in the next revision. It didn't match the name pattern. I deliberately patched only the stock heat shields first time around. But I think I'll change the criteria to patch any part with @RESOURCE[Ablator], @MODULE[ModuleAblator],#maxTemp=3300 . That way it'll catch anyone else's cloned and rescaled parts, etc, too.
  19. Ditto. Google Drive gets upset when a file is downloaded by too many different people, so it's probably that.
  20. Download Get it from SpaceDock, or build it from GitHub What? This is a behaviour-only mod. No new parts, it just fixes KSP's stock heat shields so they fail when depleted and in extreme re-entry profiles. Don't slam into the atmosphere hard and fast, and don't expect to survive with those 0-ablator "for novelty use only" heat shields anymore. (Credit goes to the Deadly Reentry crew for the class I adapted for depletion. Without this mod wouldn't work.) Also makes the inflatable heat shield a bit more delicate. It remains amazing for what it should be amazing for - slow, grazing aerocaptures and aerobraking manoeuvres. But now if you try to use it for ballistic re-entry at high speed or of a heavy vehicle, you'll probably die. (This is optional, you can omit the ModuleManager config for it). Also lowers max temp of service bays so they don't function as similarly magic heat shields. They're still very tough, just not "drop one into Eve at 4000m/s" tough. Think of this as Deadly Reentry Lite. No Kerbal injury, no part damage, etc. Just heat shields that can fail, and saner temp tolerances on service bays. Why? KSP's heat shields are magic. Really. Try re-entering from Minmus on a steep trajectory ... with your heat shield tweaked to have zero ablator. You'll be fine. You can even use a service bay instead of a heat shield for interplanetary transfers, it's almost as good a heat shield. I want heat shields where I have to care about the re-entry profile, at least a bit. Don't bring enough ablative material and your shield will be exhausted, with fatal consequences. Slam too hard into the atmosphere and the shield will overheat and fail - pyrolysis only gets you so far in terms of heat protection. These shields aren't realistic. They're just slightly less absurdly unrealistic. KSP's ablator model is silly. Instead of lowering conductivity by providing a gas blast shield to buffer the surface from the hot gases of reentry, pyrolysis in KSP works more like some kind of super-compressed refrigerant that absorbs heat, or some kind of mega-endothermic chemical reaction. The thermal energy accumulates normally in the part until it reaches a threshold, then some ablator burns away and poof, bye bye heat. The heat shield its self is a magic insulator, whether or not it has ablative material left. Instead what should happen is that the pyrolysis of the ablator should greatly lower the thermal conductivity of the part ... until the ablator runs out. To simulate that I borrowed Deadly Reentry's approach (and some DLL code, CC-BY-SA) for resetting the heat shield's conductivity and lowering its max temp when it is exhausted. We presume it's weakened by being burned up. The max temp is also lowered overall, allowing the shield to fail when used in extreme re-entry profiles. They're really still magic fridges in physics terms, but the behaviour works out well enough. None of the rest of DRE is used here. No part damage. No kerbal injury. No separate heat shield parts. Changes Made When a heat shield has 0 ablator material, its max temp is reset to 1200K (tweakable in MM) and its conductivity set to 20. A depleted heat shield will promptly explode, exposing the part underneath. (ImprovedAblator.cfgand Plugins/ImprovedAblator.dll) Heat shields' max temp is lowered from 3300K (effectively indestructible) to 2800K (merely very tough). This means extreme re-entry profiles can cause the shield to fail, especially with a heavy craft. The burn profile of ablators is also tweaked so they only start to burn up at 2000K and tend to burn quite aggressively once that threshold is hit. (HeatShieldMaxTemp.cfg) Service bay max temp lowered to 2600K from 3000K (ServiceBays.cfg). Inflatable heat shield max temp lowered to 3000K from 3500K, allowing it to fail on steep re-entries. (InflatableHeatShieldForAero.cfg)
  21. I've written a very cut down sort of "DRE-Lite" for 1.4. It doesn't attempt to support part damage or kerbal injury, and it focuses on changes only to some of the more outrageous parts like heat shields and service bays. I've adopted DRE's approach to heat shield failures but won't attempt to fix the underlying silly physics. Keep an eye on https://github.com/ringerc/KSP-DRE-Lite and https://spacedock.info/mod/1889/ . BTW, I also filed a bug on the underlying defect in ModuleAblator which should be fixed in core; see https://bugs.kerbalspaceprogram.com/issues/19234
  22. No kidding! I'm used to mailing lists, threaded forum-like environments like Reddit, etc, and this is ... stone age. Thanks for doing as much as you did.
  23. Wow, I wish I'd known of this before writing https://github.com/ringerc/ksp-minimods/blob/master/HeatShields/HeatShieldsArentMagic.cfg . Though my goals were a bit different - I want to make heat shield failure an issue too, and stop depleted-ablator shields from being magical heat guards.
  24. Hi I really appreciate the scale offered by the SpaceY parts. It's been rock solid on 1.2.2 (Linux) and adds both convenience and scope to the game. The main thing I'm noticing is that in general, things are absurdly cheap. Particularly the large SRBs. Want to get payloads into orbit practically for free? SRB time. The SpaceY parts feel like "cheat codes" sometimes. Having trouble getting a large payload to its destination under budget (obviously with non-default contract payout and part cost scaling). Whack a SpaceY booster or four on it. For example: The S109 delivers 1700-2000 kN of thrust over 28s, wet weight 32T, TWR unloaded 6.3, dV 3200-3600 with no payload. Cost: 3650. The LFB KR-1x2 "Twin Boar" fueled to 70%ish delivers 1866-2000 kN of thrust over 33s, wet weight 32T, TWR unloaded 6.2, dV 3136-3360 with no payload. Cost: 16000 Not totally unreasonable - the SRB is much less flexible, for one thing. But it's less than 1/4 the price. Going big(er) looks similar. The S217 delivers 3.3-3.8Mn of thrust over 50s with initial TWR 3.6 unloaded, dry weight 107T, dV 3260-3678 with no payload. Cost: 12200. A S3 KR-25x4 with 2x S3-7200 and 1x S3-3600 tanks delivers 3.7-4.0Mn of thrust over 70s with initial TWR 3.6 unloaded, dry weight 116, dV 4300-4600 with no payload. Cost: 56000. Again, the LF stack performs moderately better, is more flexible, can be crossfed from extra fuel stacked on side-mounted boosters, etc, but at a massively greater cost. They don't even offer significantly better control and thrust vectoring than the SpaceY SRBs. I reckon the prices should be about double or 3x what they are at the moment. It can't be cheap to cast a monster SRB, right? That said: In stock KSP, as soon as I get the "Kickback" SRB in a career game I pretty much stop using LF stacks for small payloads. Why bother when you have an enormously powerful, dirt cheap SRB you can use as a first stage? It's even more absurdly superior to the LF alternatives than the SpaceY ones. 2700 gets you a 2.85 initial TwR booster with 600-670 thrust over 62s, why would you use anything else? About the only reason is vectoring. A "skipper" + tanks will deliver superior performance and control for 10000, true, but 4x the price. So I guess your SRBs are consistent with stock SRB and scale, albeit with great vectoring, and SRBs in KSP are just ridiculously good. So nevermind, ignore me.
×
×
  • Create New...