Loskene

I think that's our fault. How many times have any of us built a passenger plane, taken off, and realise we've forgotten to put passengers in it? I'd wonder if it ever crossed a KSP airline simulating player's mind to add some dummy mass to the plane for all their bags. I like life support mods for taking the burden of working that out off my shoulders, makes space travel more realistic, should work for airplanes too where "supplies" are hopefully not the fish dinner. On the plus side technically we do have DLC to give them actual carry-on luggage now.

Since the mohole is a spherical mapping defect (literally square peg round hole problem) and it extends all the way to the centre of the planet, though gets too narrow to slide all the way down, making the "core" of Moho for a certain radius around its origin into a minibiome should work for these purposes. Then increase the ambient temperature as you descend and make an achievement for anyone who reaches it, The Core style

This is what happens when you log too many hours in flight sims

Even realism overhaul with all the modpacks (which has persistent rotation under timewarp and other things you'd need to achieve this) doesn't ask you to physically point your dish at Earth to simulate a connection. It's more hassle than it's worth.

Yeah, why make one video when twenty-six will do? I forgive you but my scroll wheel would like a few words.

Don't know if it's been brought up here yet but small pylons make excellent tyres. Very high crash tolerance and a grippy collider. This thing weighs 40 tons but it can climb mountains at 40m/s without slowing down or using the jets, which are largely aesthetic and cause more problems than they solve, and it has to fall at least its own height before the suspension gives up and you lose a couple parts. I'm amazed by the performance of the first working thing I've built with the DLC.

It's common for otherwise stable planes to drift off course or wobble during physics warp due to calculation inaccuracies. If you didn't know how it worked and it happened while you're passing over mountains you'd be forgiven for thinking it was caused by turbulence, it certainly looks like it sometimes.

Sure, sounds good. We can make trebuchets held down by strut and released by hand then too. It's just like that mod I always think will be handy but I never bother installing. It's a very niche thing that suddenly has a lot of applications with robotics.

Absolutely. If you're going to organise a filing system for convenience sake, you may as well go whole hog and throw in everything you need to organise stuff. Folders, subfolders, sorting by attribute, renaming, hiding, deleting, searchbox integration, whatever people would keep coming back to ask for if you give them one of those things.

I just got the expansion, and after a few failed attempts at making a corkscrew-driven submarine, I gave up on the water physics and went for seeing how much torque those large rotors can give over land. In the process I had to, ahem, reinvent the wheel a little. Did you know the small hardpoints have a crash tolerance of 80m/s? And have a collider quite amenable to serving as an eighth of a tyre? I do now. Some more screenshots, I just went for seeing how much junk I could throw on there, it has all the science stuff and can cruise for ages at 40m/s, or more with the jets if you're feeling risky. In terms of handling you can just let it rip, I must see what its 0-60 time is. Steering is mostly handled by going fast and using the reaction wheels, intermittent friction and airbrakes set for yaw control. Not great at parallel parking but we'll get to that. Suspension is the simplest thing I could think of that'd do the job of maintaining a smooth ride, works really well actually.

I mean it's not my favourite Enterprise by a country mile but that's a level of replica detail I don't think I've ever seen here before, incredible craftsmanship. Can I borrow your supercomputer some time? I have a bunch of computationally expensive 3D renders to cook.

Like the hot air balloons in Rust then. They couldn't afford modelling wind patterns either so they abstracted balloon flight by having the airflow change direction with altitude, making piloting the balloon a matter of maintaining altitude when you find the wind layer that's going where you want. It's a little janky but it's a decent enough abstraction for these purposes if procedural turns out to be too much work, and I imagine the jankiness is less noticeable in a rocket than a balloon.

I'm a supporter of weather effects, and I think the handiest middle ground between complete random and a static pattern would be a seed-based procedural generation system, which hopefully isn't as complex as it sounds. Meaning the weather patterns for an entire save would be based on a seed value supplied at game start, configurable and copyable. This way the weather can be as random as you want, while still being possible to make identical between playthroughs for testing something specific or standardising challenges. ie "Try and launch through the KSC hurricane on day 4 using seed 1337" etc. Plus there's always the fun of procedurally generated weather producing rare, interesting phenomena from certain input values. "Wow seed 74656 makes a storm that takes up a whole hemisphere on Laythe, you gotta check this out" If we get Jool's cloud bands based on the same system we might even see the occasional Great Green Spot

Your approach seems to be almost hummingbird style, generating lift on the forward and back strokes, have you thought of going further on that and mounting the wings vertically? Tilting them as they swing back and forth to maximise lift at all parts of the stroke. May need something else for forward propulsion though brute force pitching with reaction wheels would probably do the job.

This is hilarious because you're both more or less right for the wrong reasons. Single player games do have to take balance of features into account so as not to spoil the default experience, ie playing the game "as intended", but there is absolutely no such thing as "cheating" in a single player game in the sense that we consider "cheating" today. It used to mean funny things like big head mode you'd mess around with when you've already beat the game, now it means ruining someone else's day, which you obviously can't do in single player. So in this case, while balance is not irrelevant neither is it a showstopper where there should only be one "correct" way of playing the game.

What? [snip] At no point did I ask for any changes to how physics work, even stressing to keep things as unchanged as possible by suggesting the path of least disruption for adding a decently minor feature that would've saved some UI/operational headaches. You know what, nevermind, this isn't remotely as important for how much time it's already wasted. Sorry to derail your thread op, didn't think there'd be this much nonsense about it.

See? halfway there already. Look I'm not one of those people trying to say "it's just code, it's basically magic, do whatever", but I do have somewhat higher expectations when a game is this moddable and most of these functions have already been done or approached by mods in the past. Without knowing what the underlying source code that enables all these surface features looks like though, makes it genuinely impossible to say what we can do here. I mean they got docking ports to work with robotic parts, which were always the "Big No No, Here Be Dragons" of infernal robotics. I'd cut squad some slack here.

I mean all I'm hearing there is "it would be really hard to do if you did it the hardest possible way" Like just set up a condition to handle a second type of "docking" that catalogues and preserves the separation of resources and command orderings in a way that can be retrieved when updating UI, performing actions or undocking. You don't actually have to make them two separate vessels held by a new type of joint. I understand the thinking guys, but it's usually people with no experience of development whatsoever that are the first to say "that's probably impossible" Of course it's not impossible, few things are, it's only ever a question of whether the labour time outweighs the end value, and an assessment of that is something only one of the devs can give us. So thank you for trying but you really haven't added anything. Frankly calling something (especially something so trivial) "impossible" should come with a greater burden of proof than calling it possible or even easy, since it's by far the least likely outcome.

This is said for every suggestion but I'm honestly struggling to think how it'd be the first thought this time, not claiming to be a developer but just based on what we know of existing KSP mechanics and using them in minimally-disruptive ways to achieve the desired effect. Add a second button to docking ports (or a new part with 2 modes like an ISS universal adaptor: docking and berthing). "Berthing" mode behaves the same way all docking ports do now. Vessels are merged and all functions and resources are collapsed under a single command point. Advanced ports or universal adaptors can be switched between berth and dock mode, and if both sides of a connection are set to berthing configuration, they will join as modules of a larger construct like normal. "Docking" mode (perhaps the only option on early-tech ports to mark and encourage a distinction between monolithic and modular spacecraft/stations) will be a new addition based on the same functions as existing docking ports, the only difference being while the magnetism stays on, the vessel merging never takes place. Docked vessels will be held in place with the same force as berthed modules for simplicity, but will remain as separate vessels as far as the display is concerned and can only be controlled by shifting to their perspective with the vessel switcher. Crossfeed can be enabled according to user preference and/or type of docking port and connection. You could simulate requiring fuel and power lines having to be run through open hatches, which is generally only done for berthed vessels or propellant-only docking ports, but I'll understand if that's not bothered with for gameplay's sake. For convenience sake an extra field could be added for the vessel mass (or other) display indicating the individual vessel and the total mass of all docked spacecraft, which would be handy even without these functions. Pros: -Eliminates the HUD clutter that's a hallmark of large space stations with many vessels docked, which makes the staging readout and action groups useless, eventually requiring every action to be done via hunting for part menus to click on constructs that can have many hundreds of tiny parts. -Lets us quickly see and switch between every vessel docked to the same station, and be ready to launch using the ship's own action groups immediately. -No more worries about accidentally activating a docked vessel's engines while trying to control your station, or getting into the paranoia-induced habit of disabling all visiting crafts' main engines after docking. -Simplifies station and modular spacecraft construction with an easy way to delineate temporary or host vessels from the permanent construct, and stops resources being drained from payloads due to absent-mindedness. Cons: -Requires time from a programmer to modify the docking code appropriately, and possibly an artist/art technician to design and rig a new part for it. -May cause conflicts with mods performing a similar function, necessitating they update or be replaced. That's basically it far as I know. I'd file it under a QoL grab-bag feature they should get around to whenever it's one of those updates.

Really digging the crow's nest spotlight, nice lol.

It seems to be dependant on something because every video I've seen has a different refresh rate for the kerbal cams. Mine in particular is very slow compared to others I've seen with apparently realtime views.

You do unintentionally raise a point here that for KSP there's no difference between docking (a loose connection for visiting spacecraft etc) and berthing (strongly connecting two docking ports together in a semi-permanent configuration, like ISS modules). Berthing is effectively what we already have in KSP as "docking", the two berthed vessels become one vessel and share everything until they are separated. Why would this be at all important? Well it's not, but I'd still like it as a quality of life thing. One major advantage I see of having both "dock" and "berth" options (maybe configurable on a per-port basis) is not having your action groups and staging all messed up and merged if you dock a ship to a station and each have overlapping functions. If a ship is only docked to a station then it should retain its own control point (switchable with the square brackets as if they were still separate craft) while allowing resource and crew transfer as if they were one craft the way it is now. Only berthed modules would actually become part of the station and respond to commands as the same vessel. This would mean if I'm controlling my space station with a ship docked to it, I no longer have to worry about manually shutting down the ship's engines in case I accidentally hit Z and send my whole station into a spin. It would also eliminate not knowing exactly what side you're controlling from when you click "undock" on a port. Small things, but it's the small things that cause big, if infrequent, headaches. Is this worth its own suggestion thread?

If you don't build an entire enormous car now and drive it over the KSC like a jeep over a sandcastle I'll be disappointed.

When it comes to spaceplanes, you'll want to design around the craft's centres of lift and mass rather than trying to compensate with aerodynamic control surfaces, which just won't work in the thin upper atmosphere or add too much wing mass for an efficient design. When building what I do to save headaches is have it so the centre of mass moves as little as possible as the fuel drains, meaning tank placement is always close to the CoM or balanced evenly around it, with fuel priorities set accordingly so uneven drain doesn't upset the arrangement. I also always empty every tank I place and only fill the craft with fuel before I go to test it, again working around the dry CoM and adjusting the wet CoM to match. This means I only have to worry about fiddling with wing placement to adjust the centre of lift rather than requiring major redesigns of the entire structure if it doesn't work as planned. When the CoL is far behind the CoM you get that "lawn dart" quality where the plane is very stable but only in a nosedive. Since spaceplane re-entry often involves some very wild pitching and rolling out of the airstream to alter trajectory, it's best to aim for manoeuvrability, which means having the CoL much closer to (but still behind) the CoM. Since this is generally the mission phase with little or no fuel left in the plane, you can see where designing around the dry CoM comes in handy here. So if your CoL is far behind your CoM and you don't want to re-do the whole thing from scratch, you can add leading canards to bring the CoL forwards and empty some noseward fuel tanks to move the mass rearward. Just a guess without seeing your plane but works for most use cases. The lawn dart quality of planes with a wide M/L gap is also what makes them hard to take off, not necessarily landing gear placement (though that helps), since the thick atmosphere at ground level is forcing them to nose down harder as they accelerate. I easily spend more time on any of my aircraft tweaking the centre of lift than I do on any other aspect of the design, and when it clicks you'll find them taking off, handling and landing buttery smooth every time. Mastery of this part of craft design definitely pays off, and informational tools like RCS build aid's DCoM indicator are a good way to learn some of these quirks, though not strictly necessary.

Yeah... nah. You've reached so far you've gone all the way around the world to pat yourself on the back. This ain't it, chief.