Jack Mcslay

Something that bothers me is that we only have one measurement of speed available, m/s is optimal for orbital speeds, but not as helpful for aerial flight or wheeled vehicles. Air intakes, sensor nose cone and atmospheric variometer could display speed in knots and mach number while inside an atmosphere and rover wheels could have a speedometer that displays current ground speed in km/h or mph (last recorded ground speed if during a jump) when they're in use by right-clicking them.

I put my pilots in classic suits, engineers in retro suits, scientists in the futuristic suits and tourists in ESA suits. I would like to have be an option where you can choose an specific color for the helmet stripe much like color codes for hard hats http://www.civilology.com/helmet-color-code-construction/

Minmus refueling is my bread and butter. So easy to get off you can save a considerable amount of fuel by driving to a considerable speed on the great flats before taking off and deliver several tons of fuel to a space station in it's orbit, plus it has a pretty decent amount of science to suplly labs with. And with it I can maintain a number of asteroid catchers around that I can also use for recovering parts and rescue missions, such that I don't even need to launch new spacecraft to rescue kerbals anymore, I can just grab their pods with one of my asteroid catchers, the smaller ones having about 4000dV each making them suitable even for some interplanetary rescue missions

Worked just fine for the Halo series' forge mode, which is on a similar spirit.

Had KSP started in Unreal Engine, they would probably have had the exact same problems. Universal engines are not well-suited for games heavily relying on physics and constructing elements. Ideally a game such as KSP should have a ground-up custom engine, but I don't fault them for using a pre-built one given their limited budget. It's a shame Godot wasn't a thing when KSP first started development, an open source game engine would have worked really well, anything they had a problem with could be fixed and customized at the source rather than fighting against the engine's limitations, but unfortunately the closest thing there was at the time that I know of was Irrlicht and Blender Game Engine, which really aren't as robust.

Seems to me it would be pretty tough to create an acceptably robust in-game tool to build planets from scratch but it wouldn't be hard to have one to modify existing planets in a game. Like adding/removing features such as rings, sea level and atmosphere, change orbital parameters and/or orbiting parent, scale bodies to a degree, duplicating bodies and such. Like, putting Kerbin in Jool's orbit while making the whole system a binary star system. Something like that would already create a bunch of fun scenarios.

Minmus has got me confused, the ground shots show the steep slopes much like we see in KSP 1, but the far shot shows Minmus much less bumpy than we're used to. Could it be that KSP2 will have much larger scale planets? That's the only way I can conciliate the images of minmus' slopes with the far away shots.

I would love for this to be backported to KSP, it might help the ridiculous performance drop when displaying asteroids

If they were to implement the idea of being able to shrink existing parts down to an extent on wings you would still be able to get pretty precise on wing size as well. Dividing fuselages into compartments seems like a pain to implement, although I think there could be 1-meter long fuselage housings as a better alternative to having cargo bays to put other parts inside.

The idea is that you can have an engine that's efficient or one that's powerful, you can't have both. In KSP all engines are minimally powerful such that you might only need a more powerful, less efficient engine if you need to land - all engines in the first game are powerful enough to transfer and capture orbits save maybe for ion engines in very dV-demanding capture burns. So I suspect most of the new engines aren't going to be particularly powerful.

KSP's hard body physics relies on the craft having multiple parts in order to simulate flex so I don't expect to be able to generate huge parts procedurally. However it would be really useful if we were able to shorten fuel tanks and solid rocket boosters when the extra fuel is unnecessary. Alternatively, I think there should be an interface that procedurally builds large wings and panels out of the currently unlocked parts, so we don't need to put it together one by one.

The way I see it an icosphere would increase performance, first because the heightmaps would necessarily be composed of triangles instead of quads, and triangles deform much smoother than quads do, needing less polygons for the same amount of detail, second by reducing distortion you also reduce the amount of data to be processed at the distorted locations, needing a less robust routine to deal with it or maybe ignore it entirely as the distortion would be small enough it could be ignored.

There's a number of potential good uses for poles: There's science to be obtained there in most bodies In bodies with sufficient inclination you could position a lander there and get months of perpetual daylight, and move to the other pole for the other half of the year In bodies with very long solar days, a rover could travel relatively short distances at a time and remain under daylight driving near one of the poles We're now going to be able to build launch sites, as such having some of them in polar locations can be useful Bodies covered in liquid often have frozen poles, making them massive flats handy for landing Or they might be the opposite and create interesting landing challenges, such as Vall's 7000m peaks at the poles (which are broken due to KSP's glitchy poles) Atmospheric bodies have lower temperatures at the poles, making them useful if you need to dissipate a lot of heat

KSP has a certain degree of procedural generation; while the primary features (biome locations, major craters, canyons, mountains) are predefined, minor geographic features are procedurally generated in some of the bodies such as small craters hills and such. I suspect that procedural generation is the culprit behind the pattern in bodies such as Duna and Mun having streaked patterns at the poles converging at the 90° latitudes creating such erratic terrain that reaching them by rover is difficult to impossible. Therefore, assuming KSP2 will implement it too, editing it out is not an option

This is more of a technical issue, but one I'm concerned about. KSP1 uses rectangular projection which is pretty bad and causes terrain glitches in a number of bodies at 90°N and 90°S latitudes, and the terrain getting increasingly distorted as you approach those points. To illustrate: You can see that near the equator each face is close to a square and it gets increasingly distorted is it reaches the poles. That makes is so that the west-east mapping becomes much more squeezed such there is much greater resolution in one direction than it does at the other, and at the end it switches from quads to triangles, resulting in even more distortion as it's difficult to map to a image. But if instead they used a cubic projection: https://imgur.com/s4o5onU They could now just map as if they were making skyboxes, it takes some more effort to implement but the end result is much less distorted

Something I thought of that should be neat: What if the game starts out with only a limited amount of planets at the tracking station, and then you need to progress in the game in order to be able to track more, such as launching telescope satellites? It could be that the game starts out only with KSP 1 planets and other planets must be discovered in-game, or even that you only have an even more limited amount of planets at the start of the game such that only Eve and Duna are initially tracked. This could also add an interesting challenge, I have no doubts there would be players attempting to rendezvous with untracked planets by attempting to calculate the precise location of a given planet and maneuvers to reach it.

First, bug fixes specially on EVA construction, I get constant issues with parts refusing to stay where I put them, poor alignment features, changing/installing wheels is a pain and at times I put a part and an unrelated parts moves. And there seems to be a glitch where often times right after I finish a burn the orbit continues to change, messing up my maneuvers. And they seriously need to revamp the map view code, my framerate drops to single digits when I have a few hundred asteroids being tracked. I also checked 'new features' because KSP needs serious UI improvements, for instance: Ability to search for an object to mark as target, so I don't have to search for a single asteroid among several dozens; List all experiments inside a module in a scrollable list instead of having a window having you read every experiment one by one; A message saying "Transferred X experiments" instead of having 50 messages one for each transferred experiment; Filter vessels by what body they're orbiting on the tracking station; More information about vessels from the tracking station, such as mass, size and resources; Sorting options for objects in the tracking station; Ability to show only A/B/C/D/E class asteroids; Show asteroid class for known asteroids (seriously, the game tells you what class a new asteroid is before it's tracked, but not when it's being tracked?)

Considering how slow ISS maneuvers it would be fair to expect a turnaround maneuver to last way more than two minutes

It's not really OCD when they do not fulfill the entire point of planting them in first place, specially when they're being used as markers for ground operations and having them fallen over makes them harder to see

Anyone else hoping to be able to create things like fuel ducts, power lines, as well as flattening spots for landing rockets and spaceplanes safely? Having remove bases have a quasi-city management feel would be very cool

My theory is they're tardigrates, and can survive basically anything when in hibernation Except then they don't get the high ground

Glitches aside, that's entire the player's fault for not planning orbits correctly. Even some form of weather forecast isn't going to do much help if you're encountering Duna straight into an aerobraking trajectory

For quite some time I kept going to the 'payload' category until I got used to go to 'cargo', specially on my portuguese translated copy where they get translated to the very unhelpful 'Cargas' and 'Carga' It makes much more sense to put storage units in the 'Payload' section, specially considering you can now put regular parts inside them, and rename the 'Cargo' section to 'Items' or 'Inventory' Edit: According to webster https://www.merriam-webster.com/dictionary/payload 'Payload' also refers passengers, it could be useful to move passenger modules there as well.

The original post doesn't say anything about surviving, so it's a bigass rocket with mammoth engines and collision course into jool

Most likely a bug, you can load a FT-T200 tank but not a stratus tank?I would suggest filing a bug report, stating the mission details in which it asks to install the tank But here's a fix: open the file GameData/Squad/Parts/FuelTank/RCStankRadialLong/RCSTankRadialLong.cfg inside the game's directory and add the following section, right before the last '}': MODULE { name = ModuleCargoPart packedVolume = 600 } Now you can load it up inside a storage unit to be installed on your satellite