Zacspace

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.

When paralax 2.0 came out I started thinking about how I'd go about building a vehicle that can handle rough terrain. KSP's wheel colliders seem to only collide the bottom, so any time they encounter a bump they just dig in. I came up with a novel way of doing tank tracks that abuses a recently (ish) discovered glitch with the breaking ground pistons that lets them stretch infinitely. Basically the treads are driven directly by spokes that can stretch and squeeze to keep grabbed on. Each set of 2 spokes gets its own rotor so that I don't have to worry about the changing angle between them. This keeps the whole vehicle as one craft, makes the treads less likely to wander off, and greatly increases the torque they can deliver. Unfortunately I started a new job before I could really starve to death start working on it, but now I have! tank treads are a pain in the butt to build, and janky as heck even with this new system, It's coming along though. It works as long as it's not in contact with the ground and the treads are tightened. I think it needs more spokes since right now it just kind of stretches and tangles itself up when I try to drive with it. WIP, but I thought I'd share since I feel the concept is sufficiently proven now. You can't tell because it's a still image, but the track is tracking! the other one had some symmetry issues and unfortunately couldn't join the celebration

Not a chance they'd shut the forums. No business sense in alienating the existing community. It may not be as large as it was, but there's quite a few of us on here still for such an old game. Many of us who remain are pretty valuable to intercept, too. Maybe not me, but folks like blackrack and linuxgurugamer for sure, among others. Just those two alone are probably worth the cost of hosting and moderating the forum and they're far from the only ones. Having a discord channel is like page one of the "how to sell an indie game in 2023" playbook. Not a chance in hell they wouldn't do it. Besides, there's probably a lot of players out there who use discord but are averse to signing up for another web service. Obviously you're not signing your life away for KSPforums like you are for, say, facebook, but the modern web landscape has given people a certain tendency toward caution and familiarity, and the people are familiar with discord. You can see this sort of thing happening already on steam. There are people who post in the community tab there and get craft files from the workshop and never interact with the forums, kerbalx, or spacedock.

Rovers in KSP are much faster than they seem. Try converting the speed you're trying to drive at from m/s into something more usual for automobiles like km/h or m/h. Then, if you're a driver, think about what would happen if you suddenly cranked the wheel in one direction or another at that speed. Now consider that in most places in the game it's going to be even easier to flip over due to lower gravity. It would be hard to build a more stable rover than that in KSP without abusing the game in silly ways. You'll just have to tweak the wheels and slow down a bit. Generally, you'd want to set more of your mass forward to improve stability, same reason as for aircraft except you're dealing with friction instead of drag. It's the reason most consumer vehicles have their engine mounted up front. The part about friction in the rear is spot on though. Super cars and formula one have their engines mounted more center for the same reason that fighter jets tend to be aerodynamically unstable, for tighter turns. Now that I think of it though, I'm starting to wonder why drag racing cars are so back heavy.

Streetwind's answer is the best one you're going to get. I'll add some tips for landing gear placement since that tends to be the next big hurdle to players after they figure out basic airplane design use angle snap to make sure all your wheels are perpendicular to the ground and perfectly straight. I know it feels like it should be fine to angle the wheels in certain directions, but because of how KSP's wheel colliders and springs work it's with rare exceptions best to have them pointed straight and upright. attach them as close to the fuselage as you reasonably can. I mean close in terms of number of connections, but also to a lesser degree actual closeness. directly attaching your gear to the fuselage minimizes the amount of flexing and bending they can do, every additional joint between increases it. Having the landing gear far from the fuselage increases the yaw moment wheel friction can apply to your aircraft, keeping a narrow footprint minimizes that. Of course you don't want to be doing a balancing act either, so just keep it in mind. I see a lot of inexperienced players attach their gear to the wingtips to avoid tipping over only to find themselves veering off the runway (and usually still tipping over after). Similarly to the above point, keeping the majority of your wheels rearward will help you stay pointed true while rolling. In the same way that in flight you want your center of mass ahead of your center of drag for stability, on the ground you want your center of mass ahead of your center of friction. Keep all that in mind and your aircraft should reliably at least have a chance of flying and maybe even landing

Your navball shows your vectors relative to your current sphere of influence, so once you leave Bop's orbit and enter Jool's it'll suddenly switch to showing you Jool-relative vectors. if you ejected from Bop in the opposite direction that it orbits Jool then your navball would probably flip the the whole way around then you change SOI, the reason being that you're moving the opposite direction relative to Jool from what you are to Bop. To put it another way, you're moving away from Bop while still orbiting Jool in the same direction as it. The same motion is just being shown to you from different perspectives throughout your flight based on which planet/moon's gravity is effecting your craft.

Laythe is Jool's first moon, so it technically isn't what OP's asking for, but I think what they really meant is some place that's not a moon of Kerbin. I don't necessarily think it's a better destination than Duna, I just though I'd point it out as being deceptively noob friendly. it takes about 2000m/s to get a Jool encounter from Kerbin orbit. If you tweak that encounter to meet up with Laythe's upper atmosphere (at the right place and from the right direction) you'll be able to aerobrake into Laythe orbit in a single pass without needing to take any particular measures against heat, just like at Kerbin. Parachutes will also work about as well on Laythe as they do on Kerbin. Basically, anything you throw at Laythe will land there, the hardest part is getting the encounter set up. The downsides being that landing on Land is going to be a little trickier since Laythe is mostly ocean, and also that Laythe's similarity to Kerbin makes it similarly difficult to escape. If you decide to take it on, maybe send something unmanned, I suggest a little jet plane.

The players have been saying race cars since rover wheels were first introduced. They're just being realistic. That said, rover racing would be a pretty cool multiplayer feature. Probably one that would emerge organically anyway. Hopefully They formalize regions to act as racetracks/offroad courses on different bodies, so we're all on the same page when it comes to designing and racing rovers.

The vessel you land on has to itself be landed in order for it to count like that. In HoDeok's video that Camacju mentioned earlier, HoDeok used a specially designed platform to glance off of Vall's surface during a flyby, exploiting a glitch to pick up the landed state despite not actually having landed, and then flying to Jool in real time in order to keep it technically landed until low in Jool's atmosphere. He's then able to land on it while it just floats there due to another exploit.

I've had this happen to me with the stock klaw. I was testing the grabbing ability of a craft on the runway so had it load in with a fuel tank that staged away, when I tried to grab it the connection would immediately break and the tank would float away. I actually had to come up with a different test method because this bug presented itself every time I tried to do this. On a couple of occasions I chased down the part and attempted to reconnect, but I was only able to knock the part away faster. At the time I was annoyed because I had to come up with a more complicated test procedure, but now I wonder if this behavior is exploitable.

I'm a known advocate of huge rovers, but I have an alternative strategy: It has 12 drills and two large converters, it's able to run 2 processes on each converter for a total of 4 and it's able to operate indefinitely with a max level engineer. I don't remember how many fuel cells, but it's something like 20. For cooling it has 4 medium thermal control systems and 2 of the curved radiator panels. I'm telling you all this because this dropship has pretty close to the ideal ratios for these parts given a max level engineer aboard. The dropship was designed to make just sort trips, the idea being that whatever it's refueling will land nearby and the dropship will just get itself into position. (In practice it has a lot more range than it needs. no complaints though.) Doing it this way means that every piece of your system can focus on doing what it's best at. The dropship makes fuel and fast as it can, and the big lander behind it lifts fuel as efficiently as it can. Ore storage beyond just the one smallest tank is useless in an ISRU setup whenever the mining and processing are being done by the same vehicle. And they should always be (if you care about playing optimally), because mining and refining share so many systems in common that aren't typically required on any other kinds of vessel. This sort of system overlap also means that rover wheels are a natural companion of ISRU equipment, since all these things require robust EC generation, which brings us back to rovers. They don't have to be huge though. The small converter really isn't that bad if it's properly fed and cooled. I usually use it with 4 of the large drills, which I've found to be most consistent with a max level engineer. This rover takes a few days to re-fuel the plane that brought it to Duna Of course I also have a colossal refueling rover, here's how I land it: Basically two rockets on either side. There' s vector engines in the service bays to soften the landing after I tip it over with RCS or robotics. After that the rockets are staged away. The launcher that carried all this to Moho was just your standard KSP-class gigabooster which was refueled on Minmus using actually the dropship from my first screenshot. EDIT: One final Tip: use docking ports to secure robotics parts that don't need to be in motion. If your part never needs to move again after it's deployed, consider designing it so that the robotic parts are staged away and it;s just docking ports holding it all together. Autostruts can cross docking port connections, but not robotics.

You can also just have a balloon filled with vacuum. It might seem counterintuitive, but vacuum is lighter than helium/hydrogen since it's literally/ideally nothing. It's theoretically more efficient than a gas filled balloon for lifting. I'm pretty sure such a thing has seen real-world development despite the obvious challenges. Maybe in some sci-fi world, a vacuum airship could be made that uses magnetic or static fields in place of pressurized gas to rigid-ize the hull without needing to rely on a heavy internal structure.

The problem with that is that you need to be in control of your plane as it lands or KSP will just delete it and say it crashed, meanwhile you also need to be in control of your spacecraft as it burns to orbit, or else it'll just fall back into the atmosphere and suffer the same fate as your plane. There are ways to do it, of course, but it's more trouble than it's worth if you're just looking to improve efficiency.