Jump to content

Incarnation of Chaos

Members
  • Content Count

    1,094
  • Joined

  • Last visited

Community Reputation

648 Excellent

2 Followers

About Incarnation of Chaos

  • Rank
    Senior Rocket Scientist

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Oh yeah, I'm just commenting on the level of effort on display here. Nothing more. Also it's KSP, the moment the madness ends is the moment something has truly gone wrong lel
  2. So you have to write custom exception handling for all of these rogue patches that were abandoned just so they don't nuke MM patching, specifiing the author responsible and then determine if the specific patch even needs to be rejected? At that point I would have almost found it easier to reimplement the patches. Mad respect for you and your work.
  3. ...in SQL land that would overwrite all rows with the values given, so are you saying that MM wildcards can potentially patch every single part with potentially erroneous values?( unlike SQL MM doesn't have any type checking...)
  4. Multimonitor breaks everything, windows doesn't clean up the virtual displays gracefully, GPU drivers break or send output to phantom displays and suck performance. I only ever use it on machines I essentially use strictly for word processing.
  5. Switch would choke so badly on KSP with 4gb of RAM....
  6. I'm just going to be real here, if you make the demo too limited people are just going to Torrent the full game. Now they might come around and buy it legit, but relying on the generosity of pirates is a bit of a risky business decision. Personally i think the demo (If it exists) should be as fully-featured as possible, but still leave the player at a point eventually where they need to make a decision. Start them on Kerbin, give them access to the game's systems and let them get to the Mun. Then it should basically stop progression beyond that point, that's well over 30 hours of gam
  7. Yikes, and that's on top of the normal fun stuff when working with >1 thread.
  8. I concur, while i wasn't too cynical about KSP2's potential from a performance standpoint even a year ago. Just knowing the developers are tackling issues like this head-on and squeezing every last bit of performance possible from their implementations makes me very, very happy. @Johannes Thank you so much for your time btw. I really do appreciate you (and other KSP2 developers) taking the time to answer my questions. I've been hearing about DOTS for almost 2 years at this point, but as far as how far along it is from a production/usability standpoint you'd have to ask someon
  9. SSTO design is honestly a lot of trial and error. The first issue is getting something that you can take off, go supersonic, decelerate, and land successfully. The second issue is then getting that same craft to make orbit, and then have enough DV left over to perform your desired transfer burn OR go to the mun/minmus and mine to refuel. If the result of solving the second issue is changing the design, then the first issue comes back up.... The third issue is getting this unicorn of a craft to complete reentry gracefully, and maintaining control while doing so. if the
  10. Because developer time costs money, and once the initial milestones are completed for a task there's likely very little time between that and them moving to the next job down the tracker/list/flowchart. If they just sat around cranking out systems, KSP2 would never be complete. Giving the community the tools to do so allows the best of both worlds, without endless procrastination sinking the project. Plus just from what KSP2 has shown so far, i honestly can't see what more you'd want? KSP1 had one stock system, with a few bodies that even had atmospheres. KSP2 has binary systems, oce
  11. Yep, and honestly most issues in KSP are from the lack of a custom implementation instead of the stock one. No engine or API would change that, and thus is why we have KSP2.
  12. Awesome, that's what I was hoping for. One more question about this though, since you already have multiple points and are using vectors is there anything spun off to additional cores/threads? That would be a potential game changer for higher conic settings and just increase performance in general. (I feel like it would be a pain to program that though) Or is it just good enough on a single thread? Especially since you could probably use some instruction sets like SSE or AVX to accelerate.
  13. Honestly I think the best solution would probably be something close to having the core functions (physics, planets, parts) in their own DLL and the source code on GitHub and open source. But I'm assuming that the goal from the beginning is high maintainability and the ability to make essentially endless modification to core game systems. Setup like that, the game is essentially just a mod itself to the base engine and calls it's own code for most things. This is incredibly labor intensive, requires people who have experience with writing custom plugins and takes much longer th
  14. I'm aware, but it's still something I'd like to know. With multiple systems, and the conics tessellated in multiple places it would potentially add up fairly quickly.
×
×
  • Create New...