Infinite Aerospace

I hope that in the coming months, I can change that recommendation.

My experience with virtual joints is very limited, near zero infact so I'd have to defer to real world examples in my work for example. So that's useful insight regarding increasing joints not yielding increases in 'stiffness' in the virtual world.

Another area I think requires attention is joints between the base of a second stage, and the top of a first stage, the interstage. Right now I'd argue this is the biggest source of deformation in any rocket I build. The issue stems from the fact the game doesn't seem to treat the interstage fairing pieces as solid entities. You can often see slight clipping in those sorts of locations, and this is due mostly (I think) down to the singular attachment node that connects the two. Any mechanical system like that where there's two things connected at a single point is potentially prone to flexing.

There needs to be a bit of common sense applied to that though, people need to ask themselves what should be rigid, and what should have the potential to deform, that's it. A solid rocket booster, which is made from several mated sections (which are not intended to move relative to one another) should 'not' deform unless in the most extreme circumstances. Now, a connection point where something is mounted (not mated) to something else 'should' be one of those variable locations. The issue is, Kerbal has always done an extremely poor job of simulating these things. What I fully believe is needed, is a 'weld joint' tool. Where the attachment node/joint is for all intents and purposes removed and two parts become a single homogenous part, fir physics calculations and such forth. I don't really see a viable alternative to that. There does however need to be several 'hard rules' embedded within that, an example being one cannot weld a 1.25 metre tank to a 2.5 metre tank, as the contact point of the two tanks is the barrel section not the dome. So for that example you'd be forced, by design to use an adaptor of some form, which is what you'd want to do. It's what real rocket manufacturers do. The whole purpose of that is to psuedo-simulate the idea of having an actual physical connection, whether that's a weld, or bolts between two parts. Where I think deformation is required is mounting solid rocket boosters for example, there should be a structure (strutting) that removes the torque created with having a booster attached to a single point like that. What I don't want to see is an 'auto-strut' setup again as it doesn't address the root cause, and we remove that second example (the solids mounted to the decoupler) from the equation. I honestly believe we in the community need to accept that a solution is going to fundamentally alter 'something' about how the game plays and embrace it as something of a progression to Kerbal Space Program being a bit more realistic, from a physics standpoint. Don't get me wrong I don't think everyone will agree with the above, but I'd like to think I've weighed up the pros and cons of the whole concept.

Space Shuttle solid rocket boosters, which is what Ares I-X was built on 'are' multiple individual segments, liquid fuel tanks are not in the truest sense of the word.

At this stage, I *couldn't* in good conscience recommend the game to someone, I do own it and I have since release but it's too spartan on features right now to be a worthwhile purchase for someone. That said, the game does work, and performance isn't dreadful provided you've got a decent enough system. I'd hold off until at least the first milestone (Science/Progression) has been ticked off, and see where it stands at that point.

I don't recall ever hearing a sound from electric engines. So it's probably by design.

The problem with all of that is the wobble isn't a 'challenge' of the game, it's something that shouldn't realistically be there. The issue is the game treating each part as well, a part. So a stack of fuel tanks will ALWAYS be treated as such, instead of a single homogenous stack and that I feel personally is where the game misses the mark. It's meant to be a rocket 'simulation' game but it fails at some of the primary aspects of actual rocketry, that being that a core stage isn't loads of various pieces, it's one piece. I would be all in favour of a 'welding' system where individual tanks could be welded together so the game treats them as a single structure. Then there's the problem with the jelly connections when stage decouplers are involved, there's no real strength to them so struts are just a band-aid to a much more insidious problem.

Oh really? Gonna have to have a look for that. Edit: after a rapid search on SpaceDock I would gather that's 'Galaxy Tweaker'?

Whilst that sounds neat, I don't think anyone has figured out how to add planetary bodies to the game yet, or alter things like orbital parameters. Could be wrong though!

He states in the above post that he aims for it to be the spiritual successor to Nertea's Near Future Electrical mod.

As the topic, is anyone currently working on implementing life support to the game?

To be fair I play the game fairly frequently so this would be useful for me, that said I'm only just hearing about this bug in here and Discord.

Wonderful work, these will definitely fill a few gaps.

These are sweet. Good work!

The first few times it occurred it was quite a specific altitude, but since then it has occurred not long after initial launch, but it's the same general issue it seems. Runs nice and smooth then, slideshow then smooth again. Pausing it, and Alt - Tabbing out of the game for a short while seems to alleviate it too. So it's not specific just to those altitudes.

It doesn't happen that often for me like, I get it just on the initial ascent to orbit, it'll be fine then the frame-rate will tank, and then it'll be alright again.

Kenny, do you get sudden and incredibly profound drops in frame rate? I'm experiencing similar problem going from low 40 FPS to 1 - 4 FPS.

To be fair I'd be inclined to agree it's the same issue. It has more or less the same description but the hit to frame-rate for me is much, much worse than 5 -12 FPS.

Ah! I've been wanting to edit this (but couldn't find it) as the problem occurs across a much broader range of altitudes, it's a lot more random than I initially thought. There's also something else I'd like to add, which is pausing the game for a minute or two seems to fix the issue. There doesn't appear to be any commonality between rockets either.

Reported Version: v0.1.4 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 11 | CPU: RYZEN7 5800H | GPU: RTX 3060 (M) | RAM: 32GB What happens? Enormous frame-rate drop, frame-rate is fairly consistent and smooth during the initial launch and first 3/4 of the ascent to orbit. Frame-rate between 32 - 42 FPS in this phase depending on where the camera is looking. Enormous drop to between 1 - 4 FPS at a specific altitude range before returning to a stable and smooth frame-rate above that altitude. The problem didn't occur in 0.1.3 and it doesn't seem to be a case of 'high part count' as it's just one of the stock builds. (The one with four strap-on boosters). Between 60,000 metres and 75,000 metres the game is a literal slide show and the rocket responds to almost no user input (I suspect due to the frame-rate). It is very specifically this altitude range, almost like at the bottom end akin to a switch, it's that immediate. The same applies at the upper end of the range, the moment I go above 75,000 the game immediately returns to its previous state. Edit to the above, the altitude range this issue occurs is a lot less specific than I initially thought. The game is a fresh install (0.1.4) with the latest NVIDIA drivers, laptop connected to charger so operating at max power state. Game is installed on M.2 Solid State Drive. Appreciate any support anyone can offer. I haven't tested whether the performance drop-off is specific to Kerbin or whether it affects other planetary bodies. Resolution is 1920*1080 and graphics settings are whatever the game default is for this GPU. Anth12 Edit: Could Be Related to:

Oh god yes! Engine plates have been broken since the game was released, you have rockets almost fold in half using them as interstages, it's like there's zero joint rigidity there.

Yup, take the Vector as a prime example being the in-game analogue of the RS-25 engine, looks 'similar' but more than 100 seconds of ISP short and about a third of the overall thrust whilst somehow being heavier than the real world version. I personally think 2.5 - 3.5 scale (vs. Stock KSP) is the sweet spot and I would love to see that as an actual option rather than having to have that modded in.

To be fair I feel my laptop must have been blessed by the Pope himself before it was shipped as I've encountered an alarmingly low amount of bugs and I'm not quite sure as to why.

That's an important point to raise and you're quite right, there's a multitude of things that can impact the development speed of a project. On the outside it's easy for people to 'determine' what those delays are but it's often a lot more complex than just *insert group* failed to do 'insert task'. It's impossible to tell from the outside what is the root cause of the ongoing delays with KSP2 development but there's a number of things worth considering. Perhaps there's a relatively small group working on bug fixes and optimisations, with the bulk of the team working on the roadmap. Perhaps in that sort of setup there'd be a pretty reasonable cadence of feature updates once the first 'domino' falls so to speak. Truthfully we don't know and it's never useful for a collective to assume to know which one is fact and which is just 'assumption'. We can't assume it's been X amount of time between this patch, and that patch so it's going to be Y amount of time before whatever update is going to be released. For all we know colonies could be at a very advanced state in development and could drop a few months after science, or that might not be the case. This is where the one area of critique I do support is that of communication, but everything else is entirely subjective. Communications are critical for a good relationship between two groups, in this case it's developers and end-users. It's a give and take arrangement in my opinion but both parties need to be willing to participate.