tstein

The whole game need to change to accept soemthing like that. You need to make a longer run predicitons than prinipia does (but with MUCH wider steps) and you can put some reasonable estimates even on long runs. What you cannot is make a burn in kerbin orbit and expect to pass exactly at the periapsis you planned in jool without correcting a few time sin the middle. You need a system where the path is not updated every tick wher eyou acelerate but only every couple of second or when you stop your engine. Yes the usability drops, that is true. But it is the same tradeoff of playing DCS vs playing war thunder.

I tried again and regreted... after the first launch half the rocket teleported some 50 meters to the left while the rest continued attached and moving ...

Except it is nto obsolete, it is by far superior to KSP 2 as of today.

Lets put this way this game waste computational resources left and right for useless stuff. N-Body would be a drop in the ocean in this scenario (if implemented by a competent developer and in a language proper for this like C++ or Rust). N-Body physics still adds more to the game than kerbal expressions or kerbals rendering inside capsule, or even more than PAINTING the ship (that seems to be the only feature they really worked on). So let people dream.

IT is equally hard to implement N-Body and 3 Body physics. Seriously if you allow only bodies above certain mass to add their pull to the n-Body loop (while all bodies are subject to it) you can have somethign really smooth. THat if you put some good developer doing it, not the way the resources of this game were used. A lot of people already implemented this type of thing for fun. It is not hard. It can be problematic only if you want asteroids to affect each other's paths,but I do not think that is what players expect.

mm It might not be. Consider the following very possible scenario.. the devs say "No no it is nto ready yet to be shown to public, it will be a disaster!" the publisher responds " shut up dude, it all gonna be fine, players are stupid and they will buy even a pile or burning trash". If you do buy the game you are supporting the PUBLISHER and you are mining the developers in this case.

The gravity part is indeed not hard...the issue is how to you represent on screen long orbits that take years? I started writing a 2D space simulator with n-Body physics some time ago, unfortunately I have very little time to make it progress . If you want to try something here lies my tip from what I did and worked well. Pre compute quite head then only store some of the points you can have really calculated n-Body path for each HOUR for example. And in between them you interpolate with a cubic interpolator. it works fast and it is a valid engineer solution (as engineering solutions are to math theorethical ones, not exact but good enough that no human will care )

It would NOT be a challenge people. For god sake. The physics can be implemented in 1 afternoon, I did it in Python then in Rust just to see the performance.. in the SAME afternoon. The only issue is how to REPRESENT in the interface and not confuse the player, and that is where it intersect with the Thread tittle. It is a game direction choice. I also would like more a deeper game with zero chenanigans of kerbal expressions for example, but the game decided to focus on a different direction, it happens.

True but that complexity can be solved at design time and pre stored. All the non tank nodes can be mapped on if they are reachable from each tank without passing for a decoupler and everything that can be reached by tank A can be treated as a single same enter point. It is simple transitivity. If A can reach C trough B then C and B are the same node for this purpose and all vertex leading to C or B can be merged. It is simply the finite automata simplification algorithm. That reduces the number of vertex drastically. That is how we did in the 80's We did not care for EVERY single sewage entrance but for every connection that was reachable by one. Surely it is not easy to test as a human, but you do make a generated set of scenarios and compare your simulation with an FMM (plenty of implementations ready to use) if your results are different.. you have a bug. I really hope it is not a bug in the fuel transfer because that is a very bad prospect for QA of the game. If it is a PhysX issue at least it is more understandable.

Well a few weeks ago I wrote in a thread that the average KSP player is not a gamer with a GPU of 2 years and people called me crazy and out of touch with reality. Well it seems the invisible hand of market has proved me right.

The save/reload of ships in space is very buggy. Very. I had a reload where the kerbal loaded outside the capsule

But did it show the intercept globe? If not the PE was not for the Mun. There are some very counter intuitive data display in this game. you need 855 ms dV from 100 km and pull and push your start position until you see the globe witht he concentric marks. Also when you start to burn... if you try to burn with Time acc and your ship is not aligned the SAS will NOT align your ship! You need to align in 1x time.

Sorry but that is repurposed bovine waste, if your browser is down it matters not if you use your PC for other things. Remember there are LOTS of software engineers here, we know what is real or not on computers. That said come bad computers sometimes run things ok because the game engine FAILS to even initialize some sort of graphic effect, I have seen that happen 2 times in the last few years.

That unfortunately is a modern trend that is BAD for the game. TO not care for performance during the development and let everything to the end get get you stuck in a well too deep to leave without undoing a lot of content. If your performance issue is due to bad data structures you want to fix it in the start of the development . A Healthy process needs constant checkpoints to see if the performance is slipping too fast away from what is desired. You cannot get stuck in savign every cycle at every moment, but You cannot consider a feature released if by adding it you made the software unusable.

Being passionate rarely means you are the best to do a job. Being passionate sometimes can lead you into focusing on things that are NOT priority and that is very bad. For example, why in hell waste a SINGLE SECOND working on the many kerbal face expressions, when there is so many CRITICAL foundation issues in the game? Some of the best developers I worked on hated the software they were working on, maybe exactly because they focused in the important stuff first. TO be fair this might be to blame on someone else, like a manager, marketing or producers, but there seems to be a CLEAR issue of bad focus. They spent so much time in their new gui, launchpad, KSC, kerbal faces, rendering kerbals even inside the ship, while the basics were not ready.. not even remotely ready. It might even be the case of a studio with too many content creators and too few senior developers ?

The I1 and I2 are NOT intercepts ( I know, coutner intuitive) they are the closest aproachs. THe interecpts are shown with a small globe (sphere of influence) near the point.

I thought it was like that for everyone... well will put in the list to report when I get home.

REstless natives are the best thing to put the development priorities in the important stuff (and how many facial expressions a kerbal has is not one of them)

not an appendage of english .. several languages use article of that form for Luna and Terra (while other celestial bodies names after gods do not get an article as god's names do not receive articles.

Well I cannot even remotely try to put into orbit something as big as KSP 1 because of performance, so they kind of slayed the kraken by hunger..

To burn your GPU as fast as possible it seems.

but they do not work correctly still. They only remove fromt he exact fuel tank they are attached not the whole assembly of fuel tanks where they attach.

For me it simply does not work... nothing at all.

Well copy paste of functions (including names) will happen, developers will do it by themselves. That does not mean that is not a different project with a different structure. All is possible at this stage. Interestingly if they did copy code they managed to copy the bad part of KSP and elave the good part out

Imminent in game dev means 2 weeks. Coming weeks usually means within a month.