Jump to content


  • Posts

  • Joined

  • Last visited

Everything posted by FirroSeranel

  1. Additionally, the yaw key bindings do not seem to control wheel steering, and there doesn't seem to be a bind for wheel steering. Unlike the E-binding issue, there doesn't seem to be a workaround for this, as wheel steering doesn't even have its own binding. To reproduce... 1. Set Pitch to E and D, Yaw to S and F, and roll to W and R in-game. Pitch will fail. 2. Open /AppData/LocalLow/Intercept Games/Kerbal Space Program 2/Global/InputBindings.json in your favorite text editor. 3. Search for "Pitch" and struggle to decipher the awful unformatted input bindings file to set Pitch to E and D. Good luck getting it in the correct orientation the first time! 4. Go into the game and build an airplane that includes steerable landing gear. Launch to a Runway. Pitch up to test elevator and watch your plane steer hard to the right because pitch-up is D, and apparently so is "steer right".
  2. This should definitely be a stock feature. The node gizmo is awful and always has been. It's way too easy to grab the wrong handle, to grab a handle when trying to move the node, etc. I understand that it's meant to be intuitive for people just learning about orbital mechanics, but once you know what you're doing, it's terrible, and something like Precise Maneuver is practically mandatory. The amount of faff it eliminates when planning a mission to anything further away than Minmus (even then, it's helpful), or anything more precise than a planetary body, is incredible. KSP made some... shall we say "errors in judgment" over the years. This is one that even the original dev team eventually recognized was just that, as evidenced by the fact that they "fixed" it. Not very well, really, but at least they tried. I imagine the main point against having this feature in the stock game is that any advanced features like "circularize orbit", "move to Ap/Pe/An/Dn", or even just "rotate orbit CW/CCW" could be considered 'cheaty' for a new player (although frankly if a new player doesn't understand that to circularize you just burn prograde near Ap, they need to just re-read a sentence, not degrade the playability of the game for literally everybody else, and even for themselves for 99% of their play time). If so... make it an unlockable feature via tech, or tech tiers, like maybe make precise editing overall a Tier 2 feature, and the full suite of ease-of-use/QoL improvements including porkchop plots and transfer planning at Tier 3 feature.
  3. Reported Version: v0.2.0 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 10 | CPU: i5-8600k | GPU: RTX 2060 | RAM: 32 GB I use ESDF, and in 0.1.0, rebinding the E key to any double control (pitch for me, E/D) resulted in the rebind being cancelled, making it impossible to bind the controls I need in-game. In 0.1.3, this was fixed. Now, in 0.2.0, it is broken again. Probably just some fixes from around last June weren't baked into 0.2.0's working files. Included Attachments: .ipsImage { width: 900px !important; }
  4. Well... a few things. First, that rocket is barely flyable. I realize you managed to get it to orbit, but I don't imagine it was particularly easy. Typically you want a first-stage TWR of around 1.6 in atmosphere, so with most engines, closer to 2 given the losses to low-atmosphere ISP. Yours is 1.37, so very slow off the pad. Then after just 990 m/s it drops to below 1. What this tells me is that you're probably having to fly with a really big AoA to get it to orbit. This is inefficient and very hard for a simple autopilot like MJ to do. I imagine you're thinking in terms of an initial boost stage, then a sustainer stage, and then a circularization stage, like real-life rockets use, but KSP, stock, just doesn't work very well with that method. This is because Kerbin is just too small. Its atmosphere is too shallow. By the time a real rocket would be on a sustainer stage, it'd already be in space. They are much more powerful and have much more fuel ratio and much higher ISP because Earth is much bigger than Kerbin (10 times bigger, to be exact, with around double the atmosphere depth). Second, you are correct: MechJeb's ascent guidance is trash. All it does is go straight up for a bit, then turn to 40° or whatever you set your initial angle to, then gradually turns more and more on a preset flight plan. This forces an unnatural flight path with high angle of attack (ideally you want zero AoA for almost the entire launch), and creates massive losses to aerodynamic drag while also failing to optimize for gravity losses... the worst of both worlds. It's basically the "rocket launch 101" scheme new players tend to be taught, but it's an absolutely abysmal launch profile. The only worse one is going straight up all the way to vacuum and then doing a transverse burn. The most efficient launch profile (in Stock KSP) for most well-built rockets is to accelerate straight up to around 100 m/s, then pitch to 10°. Once things are stabilized at 10°, turn off SAS and then you shouldn't ever need to touch rotational controls again until space. Everything from then on should be done just with the throttle, allowing the rocket to rotate naturally due to a correct drag profile (Center of Pressure slightly below center of mass). Once your Time to Ap hits about 50 seconds, throttle down to maintain 50 seconds until you get to your desired Ap, at which point you should need <100 m/s of dV to circularize, and can get to orbit with as little as 3200 m/s dV. There is a mod that does all of this for you, correctly, called GravityTurn Continued. It defaults to exactly what I just said, and can also try to guess, based on stats for your rocket, what to set the initial turn velocity and angle to for a more efficient ascent. The default almost always works. Having it guess usually works, but occasionally it'll fail to get to orbit, in which case, revert, and instead of "Initial Guess" it'll have "Improve Guess". Theoretically, for a given launch vehicle, it should find the absolute optimal launch profile in around 3-4 tries, but I usually just cheat its guess up by about 5 m/s and down by about 2° and it's "efficient enough" and extremely reliable. However... you'll still need more TWR than that rocket has in the first few stages. I suppose in theory you could coax MechJeb into flying the same trajectory that you do, as others have suggested, but honestly MJ's ascent guidance just isn't good enough to bother. Add some more TWR and get GravityTurn, and you'll be much happier I think! (In general, MechJeb is a jack of all trades, master of none. It can do basically everything, yes... but for certain situations, especially involving atmosphere, bespoke autopilot mods do significantly better, such as GravityTurn for atmospheric ascents, Atmosphere Autopilot for flying planes, or Throttle Controlled Avionics for VTOL control and balance. MJ can do all of those things... kind of. But it's not that good at them. I recommend mostly using it for orbital maneuvering and planning, and rover stabilization. Actually, I recommend not using it at all until you're 100% confident you can do absolutely everything it does, and understand what it's doing at all times. After all, that's kind of the point of KSP, plus that whole "Yes, you have a calculator, but you need to know the math yourself so you know if the number it spits out makes sense" idea. Even then, honestly, you'll be better at a lot of stuff than it is. Its docking routine, for example, is horrifyingly inefficient. It kind of has to be, in order to be as foolproof as it is, but again with Docking Alignment Indicator you can do oodles better hand-flying.) Edit: It's worth noting that the optimal ascent profile is basically behaving like an idealized version of the boost-sustain model used in the real world. The reason those are done in separate stages in real life is because real-life rockets don't have the ability to throttle down to sustain time-to-apogee like you can in KSP. Most first-stage-capable rockets can only throttle down to around 70%, while some "deep throttle" engines can go as low as 25% (SpaceX claims 17% on their vacuum Merlin, but realistically there are probably significant issues with reliability and durability throttling that low). KSP's 1% throttle is a pipe dream. That said, a lot of the more modern rockets being flown do use the same engine to sustain, by throttling down and/or ejecting boosters to get down to a single core. You could do the staging version of booster-sustainer-circularizer (though it's unnecessary through most of a stock playthrough) in KSP, but you'd have to do a fair amount more math, testing, and development. Keep in mind, you're building a rocket in what, maybe an hour? NASA and SpaceX and any other real life rocket developer spends millions of hours on them, and hundreds or thousands of additional man-hours to fine-tune the parameters for each launch.
  5. I'm having an issue in Career in which the Rover Autopilot button doesn't exist. It does exist in Sandbox. I have most of the tech tree unlocked, including all nodes with any MechJeb module unlocks. However, I'm running a very not-standard tech tree in the form of Un Kerbaled Start, which I suspect is the problem, as it changes a lot of early-game nodes, and I'm not sure it even has "fieldScience" (the node that unlocks the Rover guidance). Is there a way to just enable everything in career mode? There used to be mods for that, but they're waaaaaay deprecated, like 6 KSP versions ago.
  6. Yeah, I still use it too, but because it hasn't been on CKAN as compatible (without old versions checked), new players don't even know it exists. Since all it would seemingly take to get it current again is literally changing the version limits in its config files, it'd be nice if someone adopted it and did that, or forked it and did that... but that's a lot of responsibility to take on if it ever breaks due to some unforeseen future update. Not that that's likely anymore, but... still. If its core functionality was integrated into the core engineering data mod of KSP2, then it'd always be maintained for sure... even if it's only numerical torque readouts rather than the graphical right-hand-rule arrows, although I do love the wet/dry/average CoM markers as well.
  7. Ah, yeah, and the game happily makes lots of mistakes. xD I don't think it's that big of a deal to need CoM and CoT on, honestly. If I'm tweaking thrust vectoring and balance, I almost certainly have those on anyway. Calculating it manually might be quite the pain, too, because of the ability to have multiple crafts in the VAB at once. Depending on how the "active launch vehicle" flag is done and exposed, anyway, if it ends up way, way easier to keep it how it is, I don't see a particular problem. If you want to be more ambitious, I might suggest integrating RCS Build Aid's functionality (basically just torque from RCS systems along each control axis). The only trouble with RCS Build Aid is that it stopped getting maintained, and because it's a fairly small, niche feature set, nobody adopted it. Something like this is so essential that even if you get tired of maintaining it, _someone_ will pick it up, you know? So integrating it would make sure that functionality is always available.
  8. Sometimes on game load, my custom flag is gone, and replaced with a distorted version of the default KSP flag. Any idea what's causing this? The save points to the correct file... though there are spaces in the file name. Could that be causing it? It tends to work fine at first, then once it loads wrong, it's always wrong. :\
  9. One thing I'm wishing this did, but don't know if it can, is to split out asparagus stages separately. It seems to generally add the dV correctly, but combining it all into the engine activation stage is a bit opaque. Heh, that's probably partly because I don't trust KSP2's own dV estimations yet. Especially sometimes when putting multiple engines on a stage, it'll suddenly double the available dV compared to a single engine, even though dV should go down in that case, not up. I assume for now you're pulling dV info from the game? Or do you calculate it using the part hierarchy? It also doesn't seem to correctly calculate fuel-only stages, like drop tanks... though that could also just be because the game doesn't have a fuel flow priority system yet, other than fuel lines (which like to reverse themselves on load, it seems).
  10. Nice! Love the more accurate SLT for atmospheric bodies, heh. Really helps with the Eve challenge. I'm curious how you're doing torque... does the game give the exact coordinates of the CoM and CoT markers, and you take the thrust vector multiplied by the torque arm with some trig? It seems to be behaving correctly to me. This should help a ton with design of VTOL craft especially, until someone manages to recreate RCS Build Aid and/or Throttle Controlled Avionics.
  11. I did quite a bit of fine-tuning, though most of it was on Duna to maximize stability and thus speed, since I had a pretty long drive all the way across the ice cap. I did a fair bit of testing ahead of time, and easily the fastest wheels (no contest at all) is the Ruggedized. They are definitely vastly under-torqued, even worse than KSP1 (they really should be traction-limited; electric motors have max torque at zero RPM so shouldn't ever really get stuck unable to turn; my mobility scooter can go up much steeper slopes in 1G than any rover in KSP2!) However... an inability to climb a slope on Kerbin is not at all a good predictor of behavior in much lower gravity. On Duna, with traction control off, I was indeed traction-limited, and could move up any slope I could also hold still on with brakes, which was about 50° or so. Anything higher than that, and I needed some momentum. I almost got stuck in the bottom of a small crater once. I wound up sort of spiraling up out of it, using my centrifugal force to add more traction to eventually make it out. The same rover could likely go up 80° slopes on Minmus, the only real limitation there being the center of mass staying forward of the rear wheels' contact patch to avoid flipping over backwards. But yeah... whoever initially designed the rover wheels' torque curves in KSP1 was on some pretty good drugs... and have absolutely no idea how electric motors work. They start at almost zero torque at zero RPM, then climb to a very early spike before then very sharply dropping off again at ~1/4 of their rated speed to less than 10%, and then slowly trail off from there. Then, since I'm 99% sure all KSP2's team did was copy-paste part definitions over from KSP1, all the same janky curves are there, except even weaker in the new physics engine! Huzzah! Of course, there are variations in real-world DC electric motor torque/speed curves, depending on their winding layout and whether they use permanent magnets or electromagnets for the field generation, but most start at max torque then have a gradual decay from there. In KSP1, I always, always modded all rover wheels to something much more sane feeling (for all the good it did with Unity's "wheels on crack" physics for colliders), so going to even weaker than KSP1 stock in this mission was... frustrating, often. Hence the eight wheel setup, and ultra-wide, ultra-long track, heh. I wound up using a differential friction control from 1.0 at the rear, down to 0.6 at the front, so when the kraken would punt my rover into a yaw spin about once a minute, the rover would want to straighten out. Much fun as doing many many 360's was, once I came upon that scheme, I was able to use SAS and actually not be in full racing attention mode for the entire multi-hour trip, heh. I also turned traction control off and set motor output to 100%. Turned off auto-suspension (which shouldn't even exist it's so godawful) and tuned it myself once on Duna. And also turned off Auto Steering control, and set it to 20°, but with a lower steering response for small tapping adjustments but also good counter-steer on skids and a decent turning radius (the auto-adjust steering in KSP2 right now is WAAAAAAAAAAAY too aggressive, bringing steering angle down to a fraction of a degree by like, 1 m/s...)
  12. Great job! I briefly considered a plane, but I wasn't sure how far I could fly on Duna without some sort of electric propulsion, so I went rover, but that's very cool looking!
  13. Amazing, thank you! One of my most-used statistics in designing craft in KSP1 with KER is torque in a given stage. Is there any way to add that to this?
  14. Good point... edited mine to have _most_ of the pictures in spoilers, minus a couple of signature pics.
  15. I'm doing Val++ mode! Landing an unmanned return vehicle on Duna's South Ice Cap, then taking Val, in a separate craft, first to Ike, then to Duna's red sands, and then driving her to the lander on the ice cap to come home. All this while defending against the kraken! This is the return vessel. Val's flying rover for a Duna + Ike landing and then a nice lazy several dozen (hundred?) kilometer drive... The return vehicle, seen here on its way to its periapsis a good month after Val landed on Ike. It launched first! By a lot, actually, like, 19 days. But you know Val; she's such a great pilot, she beat it there by double that! Here's Val standing beside her nuclear-powered sports-rover on Ike, with a crescent Duna on the horizon. Entering Duna's atmosphere with the rover. Emulating the "Belly Flop" maneuver to decelerate. Final landing with chutes and dorsal rockets. Val posing for a photo as she repacks the rover's parachutes, mostly for practice for when she reaches the return ship on the opposite side of the South Pole. A mere 39 days late, the ride home finally lands... ...a rather long way away. Something like 200 kilometers, I think! I hope the rover is up to the task! (It's nuclear powered and as close to invincible as I could make it in Patch 1...) Now that she knew where to go, Val began to drive in twilight, heading toward daylight so she can actually see! (Spotlights are rather dim and short range, Devs...) Up and down turned out to be pretty scary! In one particularly nasty tumble down a hill, she lost one headlight and both tail lights! So Val quickly learned to ridge-run, despite the icy landscape. 50 kilometers left! Almost there! "One more ridge, and it should come into sight... okay, maybe two." "I can see it! I can see it and it's still stand—" "—oh. Crap. Seriously? Just as I get to it, it falls over out of nowhere?" Landing legs are a but, er... wet noodly. I mean, everything is pretty noodly right now. Did you guys really think most of the community likes floppy rockets? So much that we want severely limited part count forever, and can thus add even more parts to avoid the wobble? (Seriously, have you considered a dynamic welding system? In normal flight, there's little reason to allow the main body of a craft to bend and flex, so maybe just count them as a single object, and only "disassemble" them back into individual rigid bodies during a predicted impact event or the like?) "Oh well... I'ma still plant the flag, dammit!" A Wild Bob appears out of nowhere! For real... see how there's no bob in the previous image? Jeb also teleported into the empty return capsule half way to Duna. Yes, I'm sure he wasn't there at launch. See how Bob just appeared? Bug report submitted. Bob left behind. Jeb, uh... well, he splatted after I made him eject in space on a Duna collision trajectory. Sorry, Jeb. Shoulda stayed at home like a good boy, huh? Bob, I have good news and bad news, buddy. The good news is, that rover is nuclear powered! Even at full speed ahead, it's got five or six years of fuel in it! The bad news is... uh... that's all the entertainment you'll have for the rest of, well... eternity. Sorry. See above scolding of Jeb's, er... gooey green splat in the sands? Maybe you can go find him! You do not want to know how many attempts it took to get this thing upright, intact, coordinating the rover and rocket... at least tripled by falling through the ground on 2/3 loads as I attempted it again and again... Bug report submitted. Does 2495 m/s of dV seem a bit low for a polar return from Duna? Why yes... yes it does! I uh... may have used more fuel than I planned to during landing, to avoid a nasty slope. You... don't want to know how many launch attempts it took me to find the perfect gravity turn schema to launch from Duna! Okay, this one was only maybe ten, unlike the 50+ to get the rocket upright. Even then, it was awfully close. Actually impossible with simple Hohman transfer. This was two Ike assists, one of which was a pretty close shave! and then eighteen years waiting to get the perfect transfer window, since I had just enough dV in Kerbolar orbit to get to Kerbin's orbital altitude from Ap. Seriously... look! 55 m/s to spare! Not my closest call (that would be getting out and pushing to get a Mun assist to get back to atmo in KSP1), but sheesh! 18 years! But at last, sweet, sweet oxygen! But Val will Val... first thing she did on setting foot in grass was complain about how uninteresting it was and ask to get back out there! Oh Val...
  16. Yeah, I've gotten the impression that they pretty much just copy-pasted the parts from KSP1 and then did some graphical tweaks. I did extensive cockpit drag testing while participating in the last season of Scott Manley's dogfighting competition, and... the results were very odd indeed. There were immense differences in drag, both with the cockpits on their own, and with an ore tank occluded into them to make them all equivalent area density, with differences in a drop from 10,000m to ground level of as much as 40 seconds. Some fell straight down, while others would end up with asymmetric drag, with neither of those making any sense considering the cockpits' shapes. What's more, one cockpit type was indestructible, and literally just bounced off of its nose when it hit the ground... though I think that might've been an Airplanes Plus mod cockpit IIRC.
  17. For pricing, I, for one, am kind of baffled that a AAA video game in 1999 cost about $60, and a AAA video game in 2023 still costs about $60, after well over 100%, probably closing on 200% inflation. I fully expect $80 or even $100 to become the new normal for AAA games in the _very_ near future. Many are already well above that if you count DLC and micro-transactions as part of the price. I think $50 is perfectly reasonable, probably going up to $80 at launch. Yes, they were forced to release too early, but they're making good progress in catching up, and have admitted that having feedback from a large player base is already helping immensely. For performance, how exactly do you think that works, that they can just "come out with it already"? They've addressed several times already that performance optimization is a top priority, but at the same time, it's also necessarily going to be an iterative process as more features, parts, and bodies are added. I'm actually extremely impressed by the performance, other than the already admitted issues with fuel flow modeling to multiple engines. If you keep to one engine per tank, for me, and for many others I've spoken to, KSP2 runs much better than KSP1 (modded to a similar level of graphics). My concern is that I'm not seeing any significant changes in craft physics methodology. I'd hoped for a more selective system of on-the-fly "welding" to reduce computation load in non-critical scenes like ordinary flight, as I don't see how colonies will be possible at all if they calculate the physics for every part in physics range all the time. That said, they did acknowledge that the floppy rockets aren't as popular as they'd assumed, so I'm hoping they'll not just tighten up joints like KSP1 did, but also consider treating core "fuselage" parts to be single solid bodies outside of collisons. I also wonder if you'd updated your graphics driver when you had poor performance. I had pretty abysmal performance at first, and really hideous dithering effects on the edges of clouds that bled into my craft and just generally looked like hot garbage. I even, to my chagrin, wrote some less-than-kind things about it. And... then I updated my GPU driver, and the performance got much better, and the dithering and transparency bleed went away entirely. Overall, while I certainly understand the frustration, and share in a lot of it, I respectfully suggest reconsidering your tone, as I did after my initial anger faded. Imagine yourself as a game developer, already having put years of your life and passion into a project. Do you imagine that the message you wrote would be motivating? I don't know that someone who already refunded their purchase then going on to threaten not re-purchasing at all if you don't capitulate to their demands would be anything but upsetting and discouraging. I don't even work there, and your post makes me more inclined to think "Good riddance, then, you aren't the customer they need," than "Oh, they'd better work hard to win him back." In other words... you can catch more flies with honey than vinegar. Food for thought.
  18. Yeah, always Ap up, Pe down, which is radial-out thrust. It seems like Ap goes up faster than Pe goes down usually, so some prograde component, too I think.
  19. It seems to act like an outward radial force. It's doing it in a 30km munar orbit, but much more slowly, about like it did in LKO at 80km. Then the lower I got with my lander, the more intense it got, until at some point it stopped.
  20. Same. Also same with disabling SAS altogether. Yet in Munar orbit, the oribits do degrade faster if I rotate the craft in various directions with reaction wheels. My guess is something isn't respecting the craft's overall center of mass and there's a phantom force, with the phantom force responsible for the always-on orbit wandering, and the CoM issue (similar to the old wobble kraken drive in KSP1) responsible for the faster decay while rotating. It also seems to be related to the bug in which coming out of rails-warp gives a big impulse kick to the ship. The faster the orbital wander is happening, the harder the kick. Around Kerbin, coming out of time warp maybe nudges the nose aside a bit and SAS brings it right back, barely even a wobble. Around the Mun at low altitude (10-15km orbit), coming out of warp kicks the Pe to -10,000m or more, and sets the ship spinning at ~100 RPM. Then again, if it were a phantom force, why would it go away above a certain altitude? And why would it _not_ be happening near the surface? When I'm going in to land, it feels perfectly normal, no 20 m/s/s accelerations from nowhere. Very odd... My gut feeling is that it's to do with whatever implementation they did of the floating reference point system that lets KSP have both fine spatial resolution for crafts, but also billions of kilometers of "open world" game area... which is also the source of classic KSP tropes like orbit line jitter, and many of the "Kraken" bugs. And maybe near the surface, it engages a higher-precision mode? And at high-orbit a semi-rails mode? For now, I guess I'll use higher parking orbits, and call it an unintentional feature instead of a bug! Like... an accidental implementation of relativistic frame dragging, amplified in gleeful mischievousness by the Kraken.
  21. I also have this problem, but it does happen on Kerbin, just much more subtly. ~0.5 to 1 m/s/s around Kerbin vs. 10-20 m/s/s around the Mun. The below were taken about 15 seconds apart, with no control inputs and no thrust of any kind active.
  22. Hullo there! I've been having an odd bug in this current save. I have MOLE, and created a small rover with a lab and some experiments, along with some deployable EVA science. I drove it a bit away from KSC, to the anomaly on the KSC peninsula, set up a goo experiment with control and power, then started a long-term (36 hour) Power Tool experiment. All was well for a few missions. I finished an airplane mission, and time-warped to the next morning. All of a sudden I went into Mission Control, accepted a couple of new missions, and... the game soft-crashed, stuck in Mission Control. Odd... So I restarted the game, time warped, and tried accepting just one mission, thinking the other mission was the problem. Nope, still froze. Restart again, go into mission control, no time warp. This time no crash. I started to get a sneaking suspicion it had to do with my little rover-base by the anomaly (which is within physics range of KSC). Because Unity, the rover-base's wheels slide and jitter around slightly on the very small 2° slope by the anomaly... toward the deployed surface experiments. I started to suspect that over time, the base was sliding into one of the experiments under warp and shenanigans were ensuing. So I tried driving the rover away from the experiments a little, and... voila! Several more in-game days passed, several more missions, no problems. Now I'm deploying some commsats, which is a multi-day mission, and... three or four days in, I wanted to return to the Space Center to make sure my scientist on the anomaly lab was doing okay (he has 16 days of healthy time left, and I wasn't sure how many days I had left). Suddenly, I couldn't return to the Space Center, couldn't save the game, couldn't switch craft, couldn't pull up Kerbal Health... Aha! So I opened the console, and kept seeing the same error message, which I'd also seen before, "Object reference not set to an instance of an object." My guess is that the game is disabling some stuff, like saving and, as a result, scene changes, to avoid corrupting the save once an error is thrown. So... I hard-close the game again (probably losing much or all of my multi-sat deployment mission, hooray), pull up the logs, and... this is what I get. This sequence started during a time warp (i.e. when the base would possibly be moving around the most and/or causing some kind of problem?), throwing the NRE error once a (real-time) second during the warp. Then when the warp ended (was an auto-warp), it shifted to once every 10 seconds. Every time, the error sequence is the same, with some other stuff happening in between (looks like garbage collection stuff?) The log is pasted below. The actual log goes on at quite some length, but I captured the start of it, the once-per-second period, and the first few iterations of the ten-second timing (which I assume is how often Kerbal Health runs checks on deployed kerbals when not in rails-warp?) I realize this is a very strange, niche case... and it looks like it also has something to do with Connected Living Space, but I don't know enough about Kerbal Health's code to fully grasp what this sequence is trying to do... like, I don't know if "ProtoCrewMember" is a normal call, or if that's a generic placeholder and part of the problem. Any idea what's happening here? If you want the entire log, let me know, but this is the relevant section, and it was a pretty long play session, so it's huge. This is from KSP.log. No other logs were written at the time of this incident. Module Manager only shows three warnings for the load for this session, all related to Decouple With Control whining that I'd uninstalled State Funding, but that was several saves ago and I doubt it's related. Edit: Went back into the game, drove the base farther from the experiments and the anomaly and onto much more level ground, and... same thing happened. Switched to the same comsat, warped to the same maneuver, did the maneuver, set up the next one, and got the error. https://imgur.com/a/YZtZPL7
  23. How does this play with Bureaucracy? I like your mods, how they feel and look, the level of support and information you give... But I'm debating between this and Oh Scrap! + Scrapyard, mostly because they were originally developed by severedsolo and so was Bureaucracy. Then again, I'm playing with almost your entire suite of Mods...
  24. In CKAN, it's listed as compatible with any version of KSP. Usually that's reserved for mods that are extremely certain that no changes Squad might make to the game could ever break them.
  25. Wait... so BARIS isn't updated for 1.12? Why does it say "Any" then for what version it works for? I can't get LDEF experiments to work, either, or storage containers to function correctly... I suppose that means the whole WBI constellation isn't updated?
  • Create New...