tstein

No that is nto how the real world works, becuase manufacturing process are not perfect. We would not had hundreds of plane crashes in history if things worked as you describe.

Well that is a general problem with KSP, not career mode. KPS was bad at communication with the user. A simple always present list of examples that could be done in game would have already helped a lot. With career I kind of likes the concept of funds. Why? Because that gave me a reason to not simply make the largest and mostly absurd rocket just to put a small satellite in orbit.

I was more worried on the concept that we will have multiplayer. And surely we cannot avoid having one process being the master that ensure the physics is synced on both players. The 2 players most of the time will be in independent islands. My time in the industry was when we built new engines for every new game family, there was not many pre made engines outside for FPS games, so my mentality is always of "well, I would implement that"

The island connections are NOT hard to deal in a game where space between islands is so large like in KSP and where entities also tend to move in monotonic forms relative to each other, that means temporal coherence is very large (so you know what islands are likely or not to interact in the next couple of frames), this is completely different from most other games where the movement patterns are almost arbitrary and constrained in a heavily populated and spatially dense "scene". In such scenario a simple sphere intersection is good enough for that and has a near zero cost when you have a non stupid number of islands. (each compare takes 3 multiplications 5 sums, 3 movups and a branch), In fact a predictive space bound by a cone aligned with the vector of velocity between the 2 islands (and with its slope based on the combined maximum acceleration of both islands (that can be easily pre computed) is good enough on KSP to decide if an island should be merged or not The constraint solver is the vast majority of the intensive physics in kerbal, but the independent nature of most cells means you can separate the islands into different cores on the most common scenarios. That is specially useful because you are unlikely to have 2 islands in risk of interaction at the same time when the physics load is at it's highest ( i.e. an island accelerating inside the atmosphere, that is when the engine struggles for most players. That because usually you do not have 2 ships accelerating inside the atmosphere suddenly meet each other ). Such a separation of cores would mean that every common scenario bar the docking connection moment scenario can be optimized into multiple cores.

That is open to interpretation. I find the progression the fun part. Without the progression system any and all game are always boring for me. No exception, No gating.. no evolution? no fun.

I think what would be fun is if we need to use instruments and probes to gather specific data about a planet before we visit. I.e We should now know eve's exact gravity and atmospheric density before we send a probe. I would , I decision was mine to make every playtrough have some 5% variance on the mass and atmospheric qualities of planets. So one needs to study these before they send something risking kerbals. I think that is where we have some split in the community approach on kerbals. Some people treat them like rocks, others like me, proudly never ever left a kerbal lost in space. In fact exclusing my first 2 hours int he game, my space program had zero casualities up today (several years later).

Just an addendum. The connected solids physics is the complex one to do multicore. The movement one is pretty easy to do multi core (although is light enough that is not really worth). Said that you can separate each system of components in a different core with no problems. So for example an optimized system could have a station being processed by one core and the ship you are flying nearby by other, only when they connect they need to offload to the same core.

no no Kerbalox. like kerbals liquified

I see a lost opportunity to rename all engines in the "dog breed" style, following the terrier, poodle etc.. interestingly enough it would make (besides the funny part) even easier for new players to realize the class of engine they are dealing with. "Hey, what do I put in my minimus lande, a Pug Engine or a Mastiff engine.. I think the answer is pretty obvious

More important than that is the capability of select a moment in time (future) and get the distance of that point on that orbit to kerbin at the same moment in time. The ranges usually played less trick on me than the ship arriving at the other planet in the worst possible window (when tyring to do multi planetary missions)

They overlap each other. So no there is no space in between them and they are not really spheres.

That brought me the mental Idea of how kerbals would solve traveling to a start 4 ly away. They would put rockets in kerbin and push its orbit down so it orbited the sun in 50 days... problem solved suddenly 4 Ly is not that far.

Because people (in my case back then my boss) ask for N-Body. A developer does what he is asked to do. I agree there are simpler way to implement some of these concepts. Lagrange points can be simulated with invisible anchors that force local minima energywise and that is far simpler to do than an N-Body simulation on a CPU budget. I really think they do not use it anymore. Maybe they used in past, but they even had an open source simulator that you can download and compile and run. I will see if I can find it when I get home, I remember downloading and compiling it once in the past. edit: GMAT is one of the softwares they use: https://sourceforge.net/projects/gmat/ you can chose several forms of simulation and integrations

About the same as an empty dark rock floating in space....

Sorry to burst your bubble , but I already did implement it (not alone we were a team of 11 back in 2002). We used 10 ticks per second for every ship (we had a max count of 64 ships in that game, but it was 2003, so the CPU power available was much more restricted as well, but doing things in 64 was never a problem because back then we did not use cookie cutter game engines, we always had to write the game engine) The planets energy normalization was not applied with the ships mixed, each ship was computed in a LOCAL frame of reference (you always need to have those because the graphic coordinate system already demands it, so to keep it for the physics was not that much more work, that combined with the fact that we limited the number of celestial bodies affecting a single body to a rather low number was enough to keep things pretty stable) . We did not try to get a final perfect energy state, just a dampening function to keep things stable (and it did work for our time frames). we could not get a transfer from one planet to other that ended with a single meter deviation on the final Pe, but we did not try that, we simply assumed (And displayed)t hat the player could not have such level of precision before reaching the terminal local frame of reference. There were a few other tricks we had to create, but after 20 years I do not remember everything anymore. Unfortunately the game development flopped because of internal administrative issues, but it did work pretty well for the type of scenario we had . Under that system your mun probes would not be gone because they are simulated in a LOCAL frame of reference, but they do receive attraction of any body whose the gravitational pull was large enough comparing the origin of that local frame of reference to the origin of the other celestial body frame of reference. In our game we did not had time warp because it was a persistent real time game and the idea was that the whole system would have just a few orbit in the whole game lifetime (although the moon systems of the large planets would score up quite a good number of revolutions). In nowhere I said that it would be easy to reach the necessary speed for a huge timewarp, I just said that the simulation itself with the precision needed for a game is not that hard to keep stable by cutting some corners of realism..

Unless you fight with snowballs ....

The first part can be dealt with CLEAR messages in a clear interface. Also the roll the dice thing can be made that you only roll the dice when you operate a certain part above a certain specification. The same way some forms of stress cause immediate break in KSP. We can have a middle ground where it does not explode.. but every period X it rolls a rice with y% chance of failure. That would allow people to play safe or to push the risk if they wish .

But that is KSP in a nutshell. KSP is engineering with seasoning of unrealistic optimism . The unrealistic strength of struts, the infinitely magical reaction wheels, the portable hole where kerbals store their food, the infinite stupidity of a kerbal accepting to travel in an external seat between kerbin and Duna, faster than light communication, engines can that be pushed from 0% to 100% and back in 1/10th of a second and nothing bad happens. A bit of wishful thinking on an Orion engine or a Metallic Hydrogen one is just a bit more of salt in the ocean... it changes nothing the taste..

That is not the idea . A system like the one in question does not need to run on same dt for all body categories and neither the N-Body must be truly quadratic. Planetary bodies are the only ones massive enough to really affect each other, so you have an integration loop running with dt of 1 hour (in kerbal smaller scale maybe go down to 15 min) where the velocities and accelerations are derived from the gravitational pull ONLY among the massive bodies . A second loop running in a tigher dt runs for all non super massive bodies and they get their derivatives calculated from the effect of the bodies in the first group upon them. The position of the celestial bodies between each iteration is a simple linear or quadratic interpolator between the previous point and the next one, the ships have much more precise dt. For each of the celestial bodies there is a final step every M iteractions where the whole energy state fo the system is adjusted to help erase numeric instability errors. That is enough for a GAME. You have celestial bodies behaving as an N-Body system with a precision enough that a casual observer cannot say something is not right, and you have ships behaving as if under effect of N-Bodies ( again one can optimize and use only an n clsoer ones where n <N) I think those conditions are more related to having a multi body system that is stable. When I wrote my first orbit integrator I was amazed how many times I had to try to change masses and velocities until I got a system that was stable (nothing being thrown into the void) in the first 30 orbits.

I don't know why but this video made me instantly imagine an engine that uses kerbals as propelled material.

First, sorry if there was some other topic about it, but my fast search with the keywords I came with did not find anything. I was wondering if there is any chance of we having the opportunity of explore under the surface of some planet ( with some nice science prize of course since underwater woudl make any space biologist salivate).

It is possible to create lagrange points without the complete simulation of the NBodies. The lagrance points effectively are local minima energy state wise so there are ways to implement them artificially with zones where certain levels of forces are "neutralized" artificially. That said it woudl not be terribly hard to implement for specifically kerbin - moon- ship sets. Not in fact... NBodies simulation is very little code, but it is a code that is computationally very expensive. One can implement an N-Body simulation with an Rk4 integrator in an afternoon. The problem is you cannot predict the future without stepping into the future and that makes orbit prediction quite expensive (specially considering time acceleration) If you want the whole N Body system to change all the time yes, but if someone just wants the ships to be constantly under effect of gravity of the N-closer bodies and the bodies themselves just have a few cycles or "pre computed pattern and after those they are pushed into the previously exactly known position) it is feasible. Btw For planetary body levels an Rk4 works quite well even with a huge 1 hour step. IT takes tens of years of simulation before you see weird stuff and KSP we are not trying to predict centuries of effect of jupiter in orth cloud.

I really think you must stop for a secodn and check if you see KSP as that because you decided it is and is painting it in your mind to force that result or you really really think KSP is completely disconnected with KSP 1. Notice that the vast majority of people do not see KSP 2 as being disconnected at all with KSP 1, just extending further at the "endgame". Sometimes the majority of people are wrong, but usually if you are seeign something that basically no one sees, it might be good to get glasses (i.e calmly revisit your asserted convictions ) Well I do not think KSP was designed to trebuchet things into orbit. That is akin to epople that create a workign touring machine in minecraft.. ok.. it can work, but it was not MADE to do these stuff.

Yup.. last week my Duna attempt in my newest career (every time I create some different restrictions for myself) I arrived in Duna with 6 ships at same time gathered fuel from the ones that did not need to land (relayy ships that had some tiny spare load to carry fuel there) for the lander) did the mission, made a very long rover travel..... returned experiments made a final pass at Ike. My engineer threw away a lot of pieces it would not need for the return, basically rebuildign on site the most minimalistic rocket that could bring him and valentina back to kerbin... and we came back home. Each one can create its own challenges and that makes the game fun

It is just a very reasonable extrapolation since after you solve procedural wings (that generate forces) procedural structs are so logical and absurdly easy to do that you woudl need a very very dumb manager to create some reason for that never to be added.