shdwlrd

What about the console players? Console players can't run nor share non-native scripts on both the XB or PS. Why add a mandatory requirement that a percentage of players can't do? Why add a mandatory requirement that most PC players won't use? It's one thing if you want to program every little control for your craft. I'm sure that a majority of players wouldn't want to either.

Don't know, I'm not an expert with Unity. The only reason I know how KOS works is because the basic operation and impacts are spelled out in the thread and git. What I do know is if you need to run code through multiple translation layers, you can get some serious performance hits. So the least number of steps the better.

Thanks for taking the time to write this up Nertea. 600+ parts planned and more added as needed, that's a lot of work. Part creation doesn't seem as straightforward as one would expect. Mods you only really have to answer to yourself. For the vanilla game, there are bunch of extra steps that needs to be done. I'm sure the process isn't as quick as some people may expect. I'm looking forward to see more of your handiwork when KSP2 is released.

I thought this FX was already shown off in the exhaust dev diary?

@Bej Kermanthe point is, there should have been a collision. All three craft were in physics range of each other. The distance between my target and the satellite was less than 5m. The satellite should have hit that docking arm and destroyed it along with the satellite itself. (My target was at 550m prograde to my craft, the satellite passed at 555m in front of me when I noticed it a few degrees above it.)

These pointless collision checks will teach and force the player to keep distance between crafts. An example that actually happened to me. I put a mapping satellite into a 250-251km polar orbit. Several weeks later, (real time) I assembled a station into a 249-251km equatorial orbit. A couple weeks later I was approaching the station and saw a flash of a targeting reticle in the middle of my station. After a couple minutes of confusion, I checked the map screen. It was my mapping satellite that phased through my station. I learned my lesson from that and moved my stations orbit. Luckily objects that are approaching each other at high velocities won't collide in KSP1, so no damage done. But in KSP2, it becomes a worry and something you will have to account for.

I definitely agree on this. Maybe a couple more show and tells, hopefully. Maybe some wheel designs or some of the tank or structural parts.

An collision alarm is a very sensible idea. Dropping time warp and highlighting the craft(s) with enough time to maneuver to avoid a collision (even just narrowly) would be a good thing.

You can thrust while in time warp, focused or not. There will still be rotation while in time warp, focused or not. So would it be much of a stretch to have active collision scans while in time warp? If you can thrust and rotate your craft while in time warp, focused or not, it just makes sense that the collision scans would continue. You don't want your craft phasing through a planet on your way to your destination now, do you?

A rock is a rock. Most people don't care about the chemical breakdown of a rock. The difference is the perception between a rock and metal. When you say metal, everyone thinks of a pure element or an alloy with certain properties. Usually shiny, malleable, melts with high heat, and visibly corrodes in the presence of oxygen. When someone thinks of a rock, they think of chunks of material found throughout the surface of the planet. Usually hard and brittle, without a natural shine. (Onxy does shine, but it's the only one without polishing.) It doesn't visibly corrode in the presence of oxygen. So concrete and metal need to be separate. Not because of any elemental makeup, because of the different perception of what each material is.

Don't forget about concrete. Part construction and colony construction will share some of the same materials, metals in particular.

I doubt that a true scale star system will be in the game. We don't know much about the other star systems that will be in the game. So it's truly unknown what the devs have planned.

They did a dev blog about that. You will have to worry about crossing orbits with time warp. If there's going to be a collision, it's going to happen, time warp or not.

These two reasons are perfect case examples for tethers. Just like in real life, if there's really no reasons why you shouldn't be tethered to your craft when in orbit.

This has been asked and answered before. The Kerbol system is not changing outside of an art pass. The Kerbol system is intended as the "easy" starting system. Any planetary systems you discover are being designed to provide challenges beyond what the Kerbol system will provide.

Easier said than done. Too many times I've forgotten to pack the necessary science equipment for my science missions, enough Mine Shafts for my Pathfinder bases, antennas for my crafts. I've had to patch in a MP tag to the titles for the MP engines to remember which engines are MP and which engines are LFO. (I don't get along with the right click info menu.) When planning missions and designing crafts, I quickly reach my mental saturation point and start forgetting things. So the shorter the list of stuff I have to remember, the better. Lol, there's a few people that share the blame, me included. (There really needs a guilty smile emoij.)

Yep, but someone always have to run over the line and take things to the farthest depths the topic can go. Personally I wouldn't want to selectable nozzles. It's one more step that I can miss and screw up my mission. I'd rather have a tag that says the engine is tuned for one or the other or acceptable for either.

Yes and no. The basic narrow nozzle for atmosphere and wide nozzle for vacuum is fine for KSP. But start throwing in the combustion chamber size, combustion rate, throat diameter, bell length, bell diameters, bell shape, fuel mass, fuel mixture, exhaust velocities, exhaust temperature. See how quickly designing a rocket engine can get very complicated for someone who has never seen or even thought about how a rocket engine even works.

Procedural nozzles and separate engine components shouldn't be a stock option. It's really complicated for someone who has little to no exposure rocket engine design, or the thrust equation. This is a good idea for a mod. Someone who is familiar with rocket engine design and the thrust equation could make some really useful and niche designs beyond what is stock.

There's always going to be physics bugs in games. It's how the game deals with it that matters. KSP1 is notorious for flat out breaking when the physics got out of wack. (Danny2462 showcases them very well.) If KSP2 can deal with that level of breaking of the physics without crashing or deleting the Kerbal universe, I would take that as a good sign. Physics exploits themselves, if they are truly game breaking, (kraken drives) they should be corrected. If they are more of a nausance than anything else, they still need to be corrected, but a much lower priority. (Super buoyant parts, small part vibration that doesn't cascade into a bigger problem.) Some exploitation would be expected with part clipping. It would be really hard to police that one. Some use cases are obviously exploitative, but some are necessary to gain reasonable performance without completely changing your design. (Power production and storage comes to mind.) Under normal circumstances, crafts with floating parts shouldn't be allowed to launch. But with all the Kerbal contraptions I've seen, floating parts are necessary to setup "stock" bearings and to free them. So there's another case where something that shouldn't be allowed is actually necessary in some cases.

[snip] I wouldn't [be a beta tester]. I don't want to ruin the fun of the game for me. I found out when writing patches for KSO that testing and debugging really isn't for me. When I was done, I never really used the KSO shuttles because I was bored of them, and stepped away from KSP for a bit because it burned me out. So no official beta testing for me. I'll report bugs when I can easily reproduce them, but that's about it.

We can assume that KSP2 will have better controller support, but nothing has been confirmed. Yes, different joysticks/ gamepads /hotas does work for KSP1. You have to set everything up manually.

Aerodynamics -- since I'm a plane lover, how the game approaches lift, drag would be interesting to me. How/if different atmosphere compositions would affect craft design beyond relative pressures. The editor UIs -- obviously once it's near release state, a thorough overview of the functions, rules, and types that you would see in the game. General overview of the parts -- it doesn't need to be super specific, but the sizes, types, and anything notable that they care to share. Wheels -- how the colliders work, how forgiving they are, how tunable they are. Basically show us that the weirdness and inconsistencies we come to expect with KSP1 wheels won't be a problem in KSP2. Base to Colony progression -- explain the differences between them. The requirements for them to progress from base to a colony. Resource distribution -- how the background distribution works. How complex you can make it.

As far as we know, nothing has been confirmed. So maybe yes or maybe no.