GradientOGames

How come KSP2 is using a 3rd party plugin for wheel physics? At this point it'd make more sense to just make a brand new wheel system that works properly with the KSP2 systems.

It's likely to do with floating point imprecision with the wheel physics 3rd-party addon the devs are using. A good long term solution would simply be creating their own wheel system that is compatible with their terrain system's floating point origin shifts within local space.

Reported Version: v0.2.0 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 10 | CPU: Ryzen 5700X | GPU: RTX 3050 | RAM: 32GB Grandparent mode is objectively superior over root mode in very large vehicles. For some reason the game resets that settings to root mode, either on purpose, or the setting is just not getting saved/loaded from PlayerPrefs. I keep forgetting to change it back, so I load into a game where all of my new launches keep combusting until I remember that I need to go to main menu and change the setting again. Included Attachments:

Bug? devs should just call it a feature, it has saved my ass from accidentally staging so many times...

No, I believe the trajectory bug and the this bug are both related to the same issue where the game sometimes doesn't recognise that a vessel has left the surface.

Reported Version: v0.2.0 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 10 | CPU: Ryzen 5700X | GPU: RTX 3050 | RAM: 32GB Parts in question are batteries and solar panels inside a fairing. The batteries are fully inside and are 100% occluded by the fairing. However, while launching through the Kerbin atmosphere, the parts are getting heated up close to the point of destruction. Included Attachments: .ipsImage { width: 900px !important; }

Reported Version: v0.2.0 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 10 | CPU: Ryzen 5700X | GPU: RTX 3050 | RAM: 32GB Put in 'other' category cause there isn't a science category yet Trying out the new science update and I love it, though every now and again I get a notification that I can EVA the collect samples... in space... When I go EVA the notification goes away. Hovering over the science button, it shows that the games thinks I am currently landed on whatever biome I'm currently above, this has happened with the ocean and the KSC. Included Attachments:

What is a "Dres"?

I've seen so many sunset screenshots because of the new atmosphere stuff, but the Kerbol lense flare looks the same on every single one of them. Just a bit of random rotation on parts of flare would make them more interesting. Someone might have made this post before it seems quite obvious to me...

That's nice! Also to be more specific, are the any plans to switch part of the game to ECS?

Would a long term solution possibly be the use of DOTS for more than just colonies. By DOTS I mean more than just Burst and the Job system, I'm talking like, ECS. A partial transformation of the game to ECS would significantly increase performance. Is the Job system and Burst compiler already in use yet? If not, just a few heavy math operations done in a burstified job would make it 50x faster!

I wouldn't say it would take THAT long though I can't say much as my games using ECS and DOTS haven't been as ambitious. Unity engine's DOTS seems like a simple fix but then the ksp2 devs have to figure out how to mix that with everything else. It'd be more worthwhile to get the first few roadmap items done, and then start working on converting the ENTIRE project into dots rather than a mix. This would fit into colonies development as there are talks about using Dots for the colonies stuff, but we'll see.

It is an incredibly complex technical challenge, but devs at Unity and have been working on making such a system for years, all the ksp2 devs need to do is to utilize it.

I've been advocating for the use of DOTS for years, however it is nice to see someone more recognisable in the community wanting the implementation of this technology as well. I'm sure there's a small handful of unity users in this forum who despises those who blame the engine, when they provide solutions to these problems. Admittely I've been datamining KSP2 (I know, I'm a horrible person) and I've found no DOTS packages, no C# job system package, and no entities package. This is very dissapointing as, speaking from experience, converting an existing project to DOTS is an absolute nightmare! I hope the KSP2 devs have an easier time converting KSP2 to DOTS... assuming they don't give up doing so...

perhaps Nate can only say things about design and some other person related can describe the technical side where Nate doesn't have much control on? What is your whole point here? This would be incredibly unlikely, data miners across reddit have brought up the very large amount of content the ksp2 keeps disabled likely as the features aren't complete yet (colonies, interstellar, perhaps experimental optimisations). Whatever you heard is not only a plain lie, but I doubt others have even thought of the idea and you are bluffing. give us some sources.

I believe it was CBT which would succeed the PQS+ system currently implemented. I believe there was some mention of a timeline for this new system but I might be hallucinating here... worst case scenario would be a few years. HDRP is a render pipeline which would not have an effect on the custom generated meshes of the terrain systems. Although KSP2 graphics is fantastic, the game might still be using the deferred default render pipeline (which would be horrible) but at least it means an easy transition to hdrp would significantly increase framerate. The reason I believe the game is not currently using URP instead of the deferred render pipeline is because of the large amount of lights that can be rendered on terrain (URP as of the blog post could not support more than 8+ point lights in one area). The deferred renderer is the likely other option as it isn't very difficult to create custom shaders to create good graphics, e.g lens flares, however it is more realistic to believe that ksp2 already uses hdrp as ksp2 can use 100% of gpu while games with deferred renderer cant normally.

I have a really good feeling that optimisations are going to skyrocket once some internal transitions are complete. As a Unity dev myself, I understand what it takes to implement highly performant systems such as ECS, DOTS, and JOBS, (NEO included once multiplayer arrives). If you delve into the patch notes, the dev team have already made significant improvements by implementing these systems. In patch 3, the devs implemented the job system for calculations with parts in liquids (making it multithreaded) which spread out water calculations from the main threads to other threads improving times for 10ms to 1.5 which is a whopping 6.6x increase in speeds (realistically it would be 3-4x as some other threads would be used for other tasks as the jobs system is implemented into other systems.)! The devs new terrain system which will be implemented within the next few months (I forgor the name) is documented to significantly improve terrain quality and framerates. Another special unity system that can easily massively reduce frame times is converting the ECS system (see ** for explanation). I am going to remain optimistic and assume that it hasn't been implemented already. Fully implementing ecs is a monumental task, however Unity offers a way to quickly increase performance without changing any scripts which is the hybrid entities and renderer for unity. You just set it on within all objects and bam, converted to entities (not really, again, see **). I'm assuming the devs haven't already done this as it makes it harder to debug. (the following may not be 100% accurate; I don't have deep technical knowledge of ecs) **: ECS (entity component system) is different from Unity's ordinary Game Object system in one core way, gameobjects have lots a jargon and unneeded values while entities only have required values. So Fully converting to entities significantly reduces cpu overhead as it has much less random variables to deal with. If you only convert partway by using hybrid renderer, you get all the rendering benefits (better gpu performance) while still using game objects. That's why I believe anything that can be converted to hybrid renderer, should; there's not much effort required and it works so much better. one of the reasons rendering is better with ecs and hybrid renderer is because entities give rendering calls and calls to access video memory using the unity JOB system and burst compiler (Burst compiler compiles all JOBs code to C++ to get run much faster) to significantly reduce both cpu and gpu loads. My verdict is that performance will significantly increase with each major update/patch and running over 1000 objects in a performant manor. Thanks for reading P.S. This probably won't age well lmao

Another update: I've found a few fundamental flaws, speed with nervs is INCREADIBLE slow, at this point, it'd be easier to land on minmus, also the low landing gear, I will lower the landing gear to a proper height and I'll see if I can manage my own delta V better. What are you experiences with using nervs, and any new tips with them? Edit: new update; SSTOs are USELESS, I see that they are a lot cheaper for career, but there is absolutely no other benefit, Spaceplanes and rockets are good enough for me! I did manage to go to the mun and back with my ssto but after aerobraking, I was unable to regain control of my craft, how to be able to regain control after aerobraking on kerbin? At least I now know the ins and outs of heavy sstos. Consider this forum answered (after the next two questions of course) What are you experiences with using nervs? and any new tips with them? How would I be able to regain control of my ssto after aerobraking (altitude 8k with 200-300mps) Final Craft Image Give me one reason for me to use sstos (excluding cost)? If not, then WOOHOO! Thank you all for sticking around <3 (no homo)

Update and problem: I was going well and I was experimenting with using nervs to get to orbit as well. I added my 20t payload and replaced a rapier with a nerv because it weighs more than 200t in total. But now the craft won't go past subsonic speeds. I'll try adding 4 more rapiers (two on each side) and see if it makes much of a difference. How do I overcome this problem? Although my original plan was to use the ssto for recovering something from the mun, but I'm also going to use this to add more segments to the KISS (kerbin international space station) and maybe even the MISS (MInmus space station) if I have enough delta V. An unrelated question: at what distance should u stop using sstos and start using rockets to build space station and outposts? I assuming out of the Kerbin system would be inefficient or are sstos only usefull for kerbin orbit and maybe mun (ssto does stand for single stage to orbit after all). Thanks to the people who are sticking by to help me with sstos, I really appreciate it. Thanks. Edit: I added the 4 extra rapier boosters and did a few flights to see how much oxidizer I would have left after doing that nerv to orbit technique and it left me SIX THOUSAND oxidizer left. After rooming approx 4000-5000 of that, I added effectively 1000 delta V to my craft (thats including 20t payload which wont be used on mun rescue). I try to go to mun and back with it and see how it goes. Edit x2: what... less gooo, after getting into orbit with my new iteration, I'm left with 3600 Delta V left! I think I should add radial decouplers onto the rapier boosters to increase my speed and get rid of excess mass but I haven't seen any designs do such a thing, should I? TLDR: My two (potentially final) questions are: at what point should I stop using sstos to build space stations (I'm assuming out side of the kerbin system is useless) Should I decouple my rapier boosters after using them (after transferring their spare liquid fuel to the main tanks, of course)

so use nerves during launch, or at like, 27k altitude?

So getting into orbit, I have both rapiers and nervs on at the same time? or nerves alone

Another update: Sorry I took so long, I've just attached 4 nerves on sides (might put 1 more in centre replacing rapier) and I can get to orbit with rapiers. Once I'm in orbit, I switch to my nervs only via an action group and that leaves me with 2000 approx delta V remaining. After checking my delta V map, I can confidently say... Not enough delta V. But I was thinking, what if I used the nerves to not only get to the mun, but also help me get into orbit, I'm going to try it, but if it doesn't work out, I need more delta V somehow. Any pro tips? Edit: forgot to mention, my 4 nervs is only getting about 2mps, is that good for landing or should I get more nervs?

UPDATEE WOOOOO: I managed to get the ssto into orbit with 1500 delta v remaining! However that's not enough to go to the moon and back, let alone the amount of delta V spent on going to the location to recover Jeb and Val. My new question for ya all: How to get more delta V without getting rid of stability. Newest iteration

update: I've tried switching the engines all to rapiers, haven't added more wings yet, but the plane is incredible stable now for some reason. however the stability doesn't last for long, as soon as I reach 400-500 metres per second, the plane flips. This shouldn't be happening, my col is well behind the com. I've read about the col going closer forward while reaching super sonic speed, but I thought this amount would be enough. image

I've done my research a while ago about COL and COM, for rockets its easy, have the col below the com. For smaller planes, I always have it just a bit behind the com. But for a super heavy plane, how far behind do I put the col. I also heard about having the sol slightly below the com, should I do that?