Zacspace

Same vibes as cleaning up the apartment before ending it all. Props to the team for still plugging away on it instead of searching for work on company time while the cheques still clear. I can't say I'd do the same, especially after being done so dirty. I kinda hope they push out a messy final update that just has all the stuff they've worked on in it, regardless of how complete or integrated. Maybe in a beta channel. It was obvious from the beginning that there was a lot of half-done stuff that just didn't make it into the public releases and it'd be a shame for all that work to be lost forever.

I built a new pc in 2019 after the announcement. To be fair, I was well overdue for an upgrade by then and it saved me from paying pandemic prices to do it. It was a little disappointing that a medium-high end system built when the game was announced, and was notably said by Nate to perform well on low-end hardware, was completely inadequate to play the game on release. I put probably less than 10 hours into KSP2 total though so I'm not really that upset. Plus, I can use all the graphics mods I want in OG KSP now, and play all the other games I couldn't before now too especially after scooping up a cheap rx6700 after prices calmed back down. Previously I had been using an old xeon workstation salvaged from a construction site's trash and a discarded GTX 670 with a jimmy-rigged cooler partly made with cardboard and hot-glue. This is actually my first time having an actually nice PC and I kinda have Nate and the various KSP 2 teams to thank for that.

You're right about that. The usual cause is you're on opengl, and the usual cause of that is you're on mac or linux. If that's the case,you can work around this bug, and a lot of other bugs in other graphics mods, by using the windows version of the game through steam proton or wine/dxvk. If you're on windows and this is happening to you, you should check your steam launch options or whatever method you use to launch the game to make sure it's not specifying the opengl backend. It used to be popular to do that to lower ram usage, so if you've been around for a while you might have done it and then forgot.

Woah. I haven't been around here much lately so I missed this. Thanks for going out of your way to find my stuff! I'm surprised anyone on the subreddit knows about me, I've never interacted with that community and barely do this one. I tend to remove craft from my Kerbalx page when they break, become obsolete or just aren't up to my standards anymore. My Ranger in particular I never quite got working as well as I'd have liked. You've probably found out by now, but it's a little unstable on re-entry and it's thrust was annoyingly off-axis. I've decided to update the thread since it's somewhat visible now (and apparently has been for some time).

I moved my install over to the windows client on proton under linux, previously linux native, because I wanted to use parallax and waterfall without the graphical errors you get from those mods under opengl. So to start, I just moved everything from my old linux gamedata folder to my new windows gamedata folder (apart from squad and squadexpansion) and I found that almost everything except waterfall and parallax worked. To be clear, I had those both working on linux before moving them. I double checked and re-did the installation, upgraded the dependencies, downgraded to see if maybe a kopernicus update had broken parallax since parallax's last release. I've tried different builds of proton. I eventually ended up with only parallax and it's dependencies installed and it still doesn't work. I'm getting errors like this for most, if not all assemblies it's trying to load: [ERR 16:25:27.698] AssemblyLoader: Exception loading 'ModuleManager': System.BadImageFormatException: File name: 'Z:\home\zac\.local\share\Steam\steamapps\common\Kerbal Space Program\GameData\ModuleManager.4.2.3.dll' at (wrapper managed-to-native) System.Reflection.Assembly.LoadFrom(string,bool) at System.Reflection.Assembly.LoadFrom (System.String assemblyFile) [0x00000] in <9577ac7a62ef43179789031239ba8798>:0 at AssemblyLoader+LoadedAssembly.Load () [0x00040] in <4b449f2841f84227adfaad3149c8fdba>:0 at AssemblyLoader.LoadAssemblies () [0x00064] in <4b449f2841f84227adfaad3149c8fdba>:0 I've been focusing of parallax for now, but I'm pretty sure my waterfall issues are related to modulemanager not loading. I'll post the full logs if necessary, but there's got to be at least a couple other people who play modded on linux through proton, right? I'm sure I'm just doing something dumb and one of you will go "oh! yeah, that happened to me, here's the fix" I even had this working myself some time last year and I don't think I did anything special then. I'm at a complete loss here.

Wow that little rover is a hero! I think I saw it hit the ground at 70+m/s in one of your posts. I love that something so simple and so silly is so effective. No surprise you finished your run so quickly.

I was honestly hoping that in the sequel they'd move away from modeling every part as its own physicsbody with joints and instead do something like simple rockets 2 where everything is welded together, but with some sort of simple structural analysis so our vehicles can still react and break under stress. That said, I don't think the joints being as springy as they are presently is a deliberate design choice. Just something that hasn't been dialed in yet. Like SAS, or wheels, or aerodynamics or... almost everything. Eventually They'll get around to tightening things up like in KSP 1.

Finished my Mun run. Screens/highlights in the spoiler The route I took. Nothing crazy. One of the main things I wanted to learn from this mission was whether or not I could drive across a whole hemisphere of a CB in darkness with my rover, and these results are promising. I used about %40 of my fuel and made it a little under halfway around the Mun. Suggests I could do a whole circumnavigation in darkness if I wanted to, on the Mun at least. For now I'm going to go ahead and not carry on to Duna. Since KSP2 dropped and then dropped the ball, I'm un-mothballing some other missions and builds.

My favourite things to do in KSP are building planes and rovers. I'm excited to learn how to do it all again in a new game, and to have new purposes to design them around! Hyped for those procedural wings!

Actually incredible. Never expected to see a functional ornithopter in this game, much less to see one looking so good.

I don't think they even nerfed the reaction wheels. We're just seeing KSP2's weirdly bad SAS overshooting its mark and then not being strong enough to un-overcorrect itself. I distinctly remember having about as hard a time keeping my craft pointed straight in 0.20 as the youtubers seemed to in their videos. The way SAS was working for their aircraft reminded me of old-old KSP1 SAS too. In Matt Lowne's SSTO video you can see the plane flipping back and forth in high atmosphere. It obviously has enough torque to point itself at the target, even a much smaller than usual amount could manage that, it was just using that torque to point itself everywhere else instead. That said. I'd love it if there was a bigger focus on reaction thrusters in the sequel, it just doesn't look to me like it's going to be the case.

I get what this person's saying. Almost like opposite autostruts. Like you're right clicking on the part in VAB and telling it you'd like to have to option of treating it like a decoupler later on if need be. Many people have pointed out that decouplers, and other parts that are decouplers in all but name like the structural pylon/hardpoint already exist, but those are parts. They add to the part count and they add another wiggly-wobbly KSP physics connection. They're also pretty bulky just design-wise. Kinda hard to integrate into a build unless you're going strictly function over form. For my part, I've done a lot of radially attaching things to stack separators so that I can offset the separator out of sight and then the stuff attached to it just falls off when the separator is staged, but that's just a workaround for the fact we don't have a better solution. The ability to just click on a part and say "this one comes off later, maybe" would be pretty cool. It could be pretty unbalanced since there would be no gameplay reason to use a dead-weight decoupler if you could use a fuel tank instead, but like I haven't been playing KSP1 for this long because it's balanced. Regardless there's no point getting salty about our friend's suggestion. It's not going to make it in the game, and if something like it is in the game at this point it'll be because Intercept independently came up with the idea ages ago.

Honestly impressive that you even attempted it. When I tried Parallax, basically none of my rovers could reliably handle even the little rocks that are all over the place. I have to imagine that KF wheels have less trouble with Parallax terrain than stock ones, but even so, that would only make it possible, not easy. You went and turned Duna into a planet sized off road trail and then drove almost the whole thing. Madman. But I didn't just come here to talk about how impressed I am with OJT's insanity, I've also been doing some circumnavigating: On Moho, quite some time ago, I landed the latest, battle-tested version of my largest rover on Moho with the intention of doing the thing. Moho sucks. At first I persevered because I was pretty sure half of the planet sucked less, But I eventually stopped making progress. I recently confirmed that at least some of that half of that planet has reasonably navigable terrain. Look how flat that terrain is! I don't know how long it's going to remain so easy for. I've been playing with the idea of abandoning this big thing and completing the mission in the little rover it keeps on board. Thing is, that rover also isn't really designed for Elcano-ing, and while this big one isn't ideal I at least know it can make it. That's why I planned another mission: I packed two rovers because while both are supposed to be suitable for a long-range mission, neither has had the opportunity to prove itself. The little one, Rover Mini S, will be circling the Mun. It's the same as the backup rover my big rover on Moho is carrying . Deployable Support Vehicle, the other one, will refuel my SSTO and then the plan is to drive it around Duna after this is done. The spaceplane is designed for interplanetary flights. It was actually kind of a pain to get it to the Mun due to its low TWR. I spent probably an extra 1000m/s all in getting here over what I would in a regular vehicle. I could probably have been more efficient If I thought it through a little more, but I had the margins to unga-bunga so that's what I did. What I'm interested to find out from this mission is what it's like to drive this rover in the dark. It's powered by fuel cell, so it's night-time range is limited. Its headlights also kind of suck. The proposed mission for it on Moho involves driving across half the planet in pitch darkness, so how it holds up against Munar night decides whether or not I abandon ship there. I have a custom module manager patch that adds the capability to all stock wheels to use differential steering. This allows me to make use of the same bug as I did in my last Elcano run on Eeloo, and this little rover's relatively strong reaction wheels let me drive it the same way too. With that in mind I initially set off expecting something like a repeat of my Eeloo mission: just rip across the whole thing at top speed. That... didn't work out. Rover Mini S just isn't designed for it. after a couple of false starts I decided to plot a course around the craters instead of through them and limit myself to highway speeds. I've made it about a quarter of the way around so far. Kinda forgot to take pictures because it's just a Mun mission. Next time I'll take enough to at least verify the run. Here's the patch in case anyone's interested:

You gotta show us some pics of this thing in action if it's doing all that!

Your flyby trajectory is pretty extreme. The burn from low Kerbin orbit to make your Jool transfer should only cost you 1900-2100m/s. Ideally you want to come in ahead of Jool travelling almost the same direction and then get scooped up by it's gravity. As it is you're kind of almost smacking straight into the side of its SOI as it flies by. As is, your options are to try and get a beneficial gravity assist off of Tylo, or try and line up an aerobrake in Laythe's upper atmosphere. I think it might take some combination of both. As for what you should send, or anything else related to vessel construction, we'd need to see your ship. That said fuel is a good bet, or heat shields if you're going to go the aerobraking route. You might want to consider dropping your science equipment and using the landers as drop tanks. Better to send a rescue mission to Jool than to high solar orbit, even if you don't end up getting to do your planned mission. Edit: You're trying to brake into Laythe orbit all in one go while descending straight into it. For starters, you'll want to make a course correction burn in solar orbit. If you play with the prograde/retrograde and normal/antinormal nodes you should be able to adjust the timing of your arrival so that your Laythe entry trajectory isn't so suicidal. This is also how you'd go about lining up a gravity assist off of Tylo. For best results at Laythe, meet it on the right side of Jool and enter the atmosphere on the right side of Laythe. That way you'll have the lowest relative velocity to Laythe, Aerobraking should be more survivable and your burn should be more reasonable.