Jump to content


  • Posts

  • Joined

  • Last visited

Posts posted by GradientOGames

  1. 4 minutes ago, regex said:

    I think y'all really need to invest in that new terrain engine, especially if this is going to continue being "a thing".

    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.

  2. Reported Version: v0.2.0 (latest) | Mods: none | Can replicate without mods? Yes 
    OS: Windows 10 | CPU: Ryzen 5700X | GPU: RTX 3050 | RAM32GB


    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:

  3. 19 hours ago, Spicat said:

    @GradientOGames and @Abelinoss, do you have an orbit line still showing for your craft when this happened? (to check if it’s not related to the landed state bug (or splashed state in this case))

    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.

  4. Reported Version: v0.2.0 (latest) | Mods: none | Can replicate without mods? Yes 
    OS: Windows 10 | CPU: Ryzen 5700X | GPU: RTX 3050 | RAM32GB


    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:


  5. Reported Version: v0.2.0 (latest) | Mods: none | Can replicate without mods? Yes 
    OS: Windows 10 | CPU: Ryzen 5700X | GPU: RTX 3050 | RAM32GB


    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:


  6. On 10/22/2023 at 5:48 PM, TriggerAu said:

    Various parts of the code do already use these kind of multi-threading and performance tools - Jobs is in a range of the Physics type calculations. Finding the best solution for each challenge invariably includes where can/should we use these types of tools - PhysX Joints don't lend themselves to that "easily", but lots of adjacent to Joints things do.

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

  7. 6 hours ago, TriggerAu said:

    I'd call it a medium term solution, and one that we will be constantly reviewing as creations get bigger and bigger - we cant "joint for ever" . We spent time before going this direction to validate it was the right step with this games architecture and define variations/alternates/options that will be considerations of the future as well 

    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!

  8. 6 hours ago, PicoSpace said:

    Likely because its integrated physics engine framework that is core element of the game, which is going to take a LONG time to make a permanent fix. So a short term is required to make the game playable (cough: Autostrut).

    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.

  9. On 8/31/2023 at 8:15 AM, InterstellarDrifter said:

    With physical interaction being linear, in relation to time, I could see it being very difficult to keep multiple threads running in time with one another.

    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. 

  10. 7 hours ago, ShadowDev said:

    The Potential Solution – Unity's DOTS:
    Unity's Data-Oriented Technology Stack  

    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...

  11. 9 hours ago, Alexoff said:

    Are you saying that an unknown person who had nothing to do with the development of KSP2 came into the room and answered the question instead of Nate? And Nate didn't even react to it? Can we then say that only Nate is authorized to answer questions about the game, and all other AMAs are unofficial and are not any promises or reliable information?

    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?


    10 hours ago, Alexoff said:

    Some say that the game was restarted from scratch. If this is so, then management has made very serious mistakes.

    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.

  12. 8 hours ago, Scarecrow71 said:

    CBT or HDRP, which have no defined timelines.

    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.

  13. 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

  14. 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)

  15. 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.


    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)
  16. 37 minutes ago, Leganeski said:

    Yes, this is critical for saving Δv because it lets you reduce the amount of oxidizer. Every kilogram of oxidizer (and oxidizer storage!) is wasted mass unless you absolutely need it to get into orbit.

    At 2.0 m/s2, a Mun landing is very difficult but not impossible. However, your TWR will increase by 25% or more from LKO to the final landing burn, and even at 2.5 m/s2, landing is much more manageable. It's still not easy to do with a plane, though, and a fifth NERV would make landing much easier at the cost of some Δv.

    Also, if you manage to reduce the amount of oxidizer storage by using NERVs for more of the ascent, that would improve TWR as well.

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

  17. 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...





    But I was thinking, what if I used the nerves to not only get to the mun, but also help me get into orbit,

    On 11/29/2022 at 4:13 PM, Leganeski said:

    To add to what @camacju and @Lt_Duckweed have already explained: from the picture, it looks like you're getting the 1500 m/s remaining Δv figure in low orbit from closed-cycle RAPIERs alone. If you managed to get the same payload fraction with a NERV vacuum stage instead, you would have over 4000 m/s from low orbit. Of course, the increased dry mass means that you wouldn't actually get as much payload fraction, but it would most likely still be a large increase in Δv.

    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?

  18. 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. 


  19. 18 hours ago, Leganeski said:

    Stability issues are caused by improperly positioned centers of lift and drag relative to the center of mass. These centers are not visible in your picture, but make sure that your center of lift is just behind your center of mass, not only when the fuel tanks are full but also when you've used up some liquid fuel to power the jet engines. I've heard good things about TAC Fuel Balancer for that purpose, although I haven't tried it personally.

    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?

  • Create New...