whitespacekilla

Members
  • Content Count

    102
  • Joined

  • Last visited

Community Reputation

52 Excellent

About whitespacekilla

  • Rank
    Spacecraft Engineer

Recent Profile Visitors

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

  1. While that may be just one of many issues, private methods are not a true barrier to use. Reflection allows you to use whatever methods you want, it's not even that hard once you know they're there (i.e. have the source code). There's no way in a distributed assembly to make a method "impossible" to call, really. Private elements are more guidelines than rules.
  2. If you do a careful examination of mod added models and textures, you'll see that the mod added ones are not only higher quality but also better organized, take better advantage of unity and ksp features, etc. I would not count on a daedalus texture added in stock ksp2 saving modders much if any time and I have doubts as to ksp2 being "better suited" to modding just because one of the public facing team members (who doesn't generally code) said it. I look forward to the refactoring they've supposedly done to the physics system, I hope they stop shipping obfuscated code and/or document the interfaces available for modding, and ship a non-horrible UI modding framework. I'd say colonization systems are as likely to be worse than mods already available for ksp1 as not. Interplanetary systems I give a lower chance still although calculating thrust while unloaded would be a big improvement.
  3. It's not a nozzle. It needs a large amount of MW electricity. It will scale its thrust with the available electricity and there's also a maximum due to technology upgrades. To get the listed thrust, you need the maximum listed power and all upgrades.
  4. Cool. I have a mod in-development which would have been pretty in-depth and have been my first serious project using their (somewhat difficult to use) UI toolkit but I've pretty much given up on it since I don't know how well any of that work will translate to the KSP2 (I've heard in some interviews that it's a total, ground up re-write and in others that specific systems got a big overhaul, seems like the guys giving interviews just don't know what they're talking about).
  5. Can't you just use the normal transfer to work around this? I'm kind of on the fence about any but the smallest KSP1 modding efforts since KSP2 was announced.
  6. This is about when I figured out I was going to engage in an argument about joints in Unity with a bunch of people who have never developed in Unity and decided to just go on living my life.
  7. Are you talking about KJR? It works by adding more connections.
  8. VERY interesting. Will you be able to describe the platform/engine, mod support mechanisms, etc.? I didn't think any of that would be interesting because I assumed pretty much the same codebase.
  9. I think the authors of binary system mods and players who have used them would beg to differ. The SOI model certainly can handle binary systems (insofar as it handles anything else, as an abstraction). I'm confident Rusk and Rask will work the same way (with an invisible point mass body representing the barycenter). Edit: there's merit to what you're saying about just ignoring the maintenance of orbits, this is effectively already in KSP1 thanks to some rails inaccuracies that can cause orbital decay even in the patched conics simulation version. Maybe you could design a game such that when you were in a non-hyperbolic orbit, unloaded, fixed conic section orbits are used but active vessels and vessels on hyperbolic orbits (or coming from hyperbolic orbit since last active) obey n-body physics. That said, I wouldn't bet on the devs adding any of this, mostly because system design is so much harder when you have n-body physics. If I was tasked to design systems that would be stable in an n-body simulation, I would probably just steal the parameters of real world systems, I don't know that this approach is of interest to/compatible with the vision of the teams behind these games.
  10. So far as I understand it, this is a problem endemic to unity games. It's difficult (time consuming and not always doable) to use unity's engine and tools to create "perfect joints". Especially in dynamic contexts (like where joints are created dynamically between editable parts...). Frankly, I don't think much will change game engine wise without a total re-write (which I also don't really want to see because so much that was found in KSP1 would be lost in a re-write). I'll buy KSP2 when the KSP1 community starts to fade.
  11. Even though the ship has sailed on ALL of these suggestions if they're already demoing footage, why not add a few ideas for us looky-loos in the forums to scrap about? Modders enhancements: Don't run the code through a silly obfuscator, doesn't protect any IP (your licensing does that), bloats the DLLs a bit, makes it harder for the community to make use of the public facing APIs, makes it harder for the community to communicate to you about bugs, etc. Switch to a standard configuration file format like json/yaml, not a custom format Document at least the data models in your config files thoroughly Provide examples Provide usable, stable UI toolkits and tooling Technical enhancements: Don't allocate so much garbage memory per second Use something like a voxel based drag model (a la FAR) Build calculation intensive systems with more parallelization in mind (no one has CPUs with less than 4 logical cores these days) Load configuration/textures/definitions/other assets and data in a manner that strikes an intelligent, modern balance between memory usage, load times, performance, and stability Drop the breaking ground science deployment and inventory system entirely and/or adopt the KIS/KAS system Automation: Once I've proven some type of mission is trivial by accomplishing some milestone, give me ways to skip it, i.e. if I can put a giant station in LKO, don't make me individually launch small satellites anymore, perhaps a system based on the mass, capacity, and equipment of the stations/bases determines what kind of premium I have to pay to have the vessel I want to ship automatically delivered to some corridor near my stations (I've always wanted to make a mod that does this and have made some progress but haven't completed it) Auto-navigation of rovers so they're useful Automated re-supply at a cost Movement of resources around a well colonized celestial body at a cost Sharing of resources in short range so I don't have to make giant single vessel bases and stations (even if some time has to elapse or special equipment is necessary) Quality of life: KER's features at a minimum as far as information and readouts Better science tracking/checklist functionality Overhaul the action group interface, maybe even introduce some templating (i.e. dynamic specifications like I want re-runnable experiments mapped to this, I want multi-mode engines and air intakes mapped to this, etc) Alarm clock/scheduling system Built in transfer window / porkchop information systems, ejection angle tools visually integrated "Intuitive mode" maneuver node editing More "smart points" on orbits for starting a maneuver node
  12. I like when people are upfront about wanting n-body physics because it helps me spot people who I won't agree with on game design at all. I'd confidently bet KSP2 won't have n-body physics. It's the kind of thing perfect for Universe Sandbox, which isn't really much of a game. I do not have ANY desire to go to my vessels in flight and keep their station. Nor do I have any desire to calculate stable orbits (within the context of accomplishing other orbit sensitive contracts, especially). Nor do I have any desire to refuel craft that slowly use resources for their own station keeping. It's not fun, I don't care, single body SOI is a fine enough abstraction for a game like this.
  13. In sequels/reboots of older games with strong communities and mods, it's very rare for the community to shift over to the new game fast. KSP1 will be alive and kicking for a long while and I guarantee there are more people complaining their favorite things from KSP1 aren't even being worked on for KSP2 than there are people salty over a shift in focus to KSP2 for a LONG time after launch.
  14. No worries. Get some sleep The online documentation is pretty bad for these APIs. I just happened to know exactly where some examples querying the cheat menu were from some recent reading and documenting. Some silly levels of effort (trivial obfuscation) and rules (forum gag rules) have been erected to make the interfaces harder to use...
  15. Based on historical precedent from other games, this goal might do more to harm the PC version of KSP2 than improve the console version. I think the game is just too complicated for console but those complications are the things I love about the game.