Kyarao

I love the idea of a partially procedural universe. A local cluster of consistent star systems, then everything beyond that being procedural. For the concerns about required storage: how much storage would be required for a star system? The star itself needs: Name Mass Sphere of influence radius Location Atmosphere Luminosity Planets need: Parent star Name Mass Sphere of influence radius Orbit ellipse Atmosphere Texture Heightmap Moons need: Parent planet Name Mass Atmosphere Sphere of influence radius Orbital ellipse Texture Heightmap There's an obvious general form that could be used so that all celestial bodies are treated the same (code duplication is a big no-no) The biggest memory hogs I see are the texture and heightmap data. I don’t think storing that data would be too difficult (even if LoD variants are stored) There are easy (for the cpu) methods to generate planet heightmaps and textures too. The only issues there might be is MORE ridiculous Unity limitations or Squad not wanting to put the effort into a procedural generator.

I think there should be a key or key combination that has the same effect as pressing any of the green arrows in the top left. My mouse hand is slow and inaccurate and I don't always hit the arrow I want. Having a key combination would eliminate that small annoyance.

Make it all science-y! Have her record things like mass, fuel levels, engine thrust, atmosphere density and so on. It's only recording numbers. You can do all the difficult science that comes with parsing data. It'll be a good introduction to the Scientific Method!

Alpha stage of game development is for pumping lots of features into the game very quickly, as well as improving features that are already in the game. Beta should pretty much be the full game+tons of bugs and not very optimized. Beta testers do everything under the sun to break the game. At this point, a good beta tester records EVERYTHING from cpu load to current activities in game. They suggest potential optimizations and report all bugs no matter how small. After release comes the patching phase. I hate patches that add features. All that does is indicate that alpha development was inadequate. Patches are for fixing bugs and making further optimizations. Typically a small team should be devoted to the patches and updates. The bulk of a development team should start working on the next big thing. Either KSP 2 or an entirely new and different game.

Thanks for letting me know about the limitations of the Unity Physics engine. Shame there's no plan for Squad writing their own physics engine.

Acceleration is the result of the vector sum of forces acting on a mass. It is not a force. The forces acting on a craft in atmosphere are: Gravity. Thrust. Drag. Lift. All of these values change constantly while flying in atmosphere resulting in a constant change in acceleration. In space, there is merely gravity and thrust. Gravity is constantly changing in any non-circular orbit. This results in a constantly changing acceleration

Due to inconstant drag, changing isp and changing gravity, acceleration will not be constant in atmosphere. Acceleration is not constant in nearly all cases, which is why I propose the flex or break tolerance. So long as the change in accelerarion is small enough, craft should be treated as rigid. Once the change in acceleration of the craft as a whole is high enough, the tolerances would be passed and parts will begin to flex and break. This is a much better alternative to having full physics simulation on all parts all the time.

I'm not sure how the game handles location data, but I suspect that is the reason for the 2.5km limit at the moment. Computers are innacturate with precise numbers on large scales (hence the old kraken when you go too fast or fly too far) also, I think cutting down on lag rather than giving it more opportunity to arise is the direction beta development should go. Alpha is more for pumping features into the game engine until it resembles the full version with less assets, more bugs and no optimization

if (ship.angularVelocity > tolerance) { foreach Component i in ship.partsList { if (i.getType == fuelTank && i.fuelLevel > spinningFuelLevelTolerance) { if (i.numConnections == 0) { PhysicsEngine.destroyPart (i) } else { PhysicsEngine.breakConnections (i) } } } } Psuedocode thrown together. No optimizations. Doesn't look hard to implement at all. I see a problem with it though. If a fuel tank is distant from the axis of rotation, it may have a small angular velocity around its own axis, but a large velocity around the ship's axis. Should this still cause it to explode?

So far as I know, the physics engine handles destruction by breaking and flexing connections. Whole parts are only destroyed when they are not connected to anything. This is a coding optimization Squad seems to have done to reduce the physics load. When your spaceship smacks into the ground, parts break apart first then (maybe as short as 1 game step later, not even a whole frame) the part itself may explode when sufficient force is applied to it. This causes problems when parts hit water, since they break when they bounce back up, instead of breaking when they hit the water. Small difference, so it doesn't really matter.

Currently, the physics engine runs on a part by part basis constantly. I propose changing this to a whole craft approach unless specific conditions are met. This will ease the current load on the physics engine and still provide a high level of realism. Also, I haven't seen the code behind the physics engine so I'm not sure if it checks every part every game step or switches through parts each step. I also propose a dynamic step through of parts checking to reduce physics load at low fps. Overall, this should result in a higher part count before the terrible kraken raises it's ugly head. The physics engine should treat all craft as rigid structures unless the rate of change of acceleration ( This is called "Jerk" ) is greater than the integrity of the weakest part. How I propose the engine does this: Firstly, the acceleration on the craft as a whole is measured against the acceleration of the previous game step. The engine then steps through part connections in the order of weakest to strongest. If the jerk applied to a connection is enough to cause that connection to break, it will give that connection a flag indicating that it is to be treated by the full physics engine. As soon as a connection is found that will not break, all remaining connections in the entire craft are treated as rigid. For example. When a spaceship is generated on the launchpad, its initial acceleration is 9.81m/s^2. The next game step, this acceleration has not changed. Since there is no change in acceleration, the entire craft is treated as rigid. This has the problem of allowing players to put heavy weights on long arms, since the whole craft is treated as rigid until sufficient jerk is applied to break a connection. To counteract this, the physics engine should check if the ship has been newly generated. New ships should be effected by the full physics engine. Since the physics engine may only come into effect during a change in acceleration, eliptical orbits, mad SAS units and user input will all cause the engine to start checking connections; bases and rovers will be able to have many more parts. Unfortunately, this means that full physics still takes effect during most normal gameplay. (it's pretty much impossible to get a perfectly circular orbit). This is why I proposed the tolerance above. Treating ships as rigid until a significant jerk will allow space stations and ships in space to have many more parts than they currently do. If the tolerance I suggested seems too easy, it could be changed to checking if a jerk will cause a flex of 20 degrees (for example). How does the engine know if a component will break/flex under a certain jerk? When the craft is first generated on the landing strip or launchpad, the engine should stress test each component in all 3 directions, recording the jerk required to break each connection (or cause a flex). Why use jerk? Why not acceleration? Constant acceleration induces a constant strain on all connections. If the connections have survived one instant, then they will survive the next. Jerk is the EXTREME CONDITIONS version of acceleration, like when you slap into your docking port at 10 m/s instead of 0.1 m/s, or when you nosedive into the ground 'cos you let SAS wobble your spaceship to oblivion. What's your problem with SAS? SAS can't drive. it overshoots constantly and can't control its own oscillations, leading to wobble and dead kerbals. It keeps applying force until it's beyond its target point then reverses the direction of force applied, instead of reversing direction of force before reaching the target. ------------------------------- There are still some situations where the physics engine will come under high load in the engine change I proposed. During these extreme situations, framerates will drop and the physics engine will come under extreme load. I suggest changing the physics engine to reflect the current FPS. As the framerate drops, the engine should go from checking all connections per game step to checking a few, to checking only one connection per game step and in EXTREME fps loss, there should be an increasing number of game steps between each connection being checked. This could result in some parts being destroyed when they were not supposed to be, due to the physics engine's part checking lagging behind current events. If the physics engine has to reduce its part checks per game step, it should necessitate each part NOT breaking (or flexing) for 2 continuous checks before reverting to treating the craft as a whole, rigid structure. Hope this post wasn't too hard to follow! Also hope it leads to an improved physics engine that allows spaceships, bases and rovers with thousands of parts each