TechDragon

Given how they just swapped "Liquid fuel" for "Methane" but didn't think through the implications of using that on the Jet engines... While you can run a jet engine on liquified natural gas (which is basically liquid methane with enough impurities they don't want to call it just "methane" since liquified natural gas is more than 90% methane with the rest varying amounts of other light combustible gasses ethane, propane, butane, and some impurities like heavier alkanes, and nitrogen) and this was demonstrated by the soviets https://en.wikipedia.org/wiki/Tupolev_Tu-155 so it definitely works. There's some issues with the density here, and a large portion of the Tu-155 was a big cryogenic tank because LNG or Liquid Methane would both require significantly more room for a given amount of energy. I don't have enough info yet to work out if they factored this in to the tank sizes and fuel burn rates. Airplane design in KSP1 (and KSP2) usually has way more fuel tank volume than you normally see, since we end up using tanks as big structural parts which in normal planes would just be cabin, cargo or fuselage, (I know some get fancier with plane designs, I'm just speaking in generalities) and so its hard to say from my own experience that they didn't faithfully swap the "fuel economy" of the jet engines over to properly match the Methane fuel. If not then I see no point in relabeling monoprop, since if they didn't adjust any of the numbers for jets then one of the major fuels is still just a generic made up liquid hydrocarbon that works roughly like how the "liquid fuel" (which is basically what kerosene is) did but this time called "Methane". If the names still dont mean anything in real life why bother giving monoprop a real name? To clarify that a bit... (ignoring the more specific Xenon in ion engines) So in KSP1 we had "Liquid fuel" + "Oxidizer" in rockets and "Liquid Fuel" in jets, which given you fill jets and rockets with (admittedly different quality/grades, but still mostly the same stuff) the liquid fuel "Kerosene" this broadly makes sense and seems like a simple abstraction to hide science details out of the way while the game focuses on other things. This didn't make a lot of sense for the nuclear rocket engine in KSP1 but hey, its a game, lets not overthink it. In KSP2, we have the more realistic sounding (because they are real things) "Methalox" which is short for methane and liquid oxygen and is our rocket fuel, we have Hydrogen for nuclear rockets now, and we have Methane (presumably liquid) for our jet engines... which means our rockets make complete sense, and sound more scientific, but now our jet engines are kinda whacky experimental contraptions. While yes you can build a jet to run on liquid methane, and yes its cold as heck up in the atmosphere so some of the cooling issues aren't as bad as you might think, generally speaking, liquid methane is a bad fuel for fancy fighter jets and other general aircraft and while sure you can probably do piston prop planes with compressed natural gas like you can also make cars, between the lower fuel density and the heavier tank mass, I don't know how well it would work. "Methane" as a jet fuel only makes sense on big "wide body" style jets where you have room in the middle for a respectable size cryogenic liquid tank to keep the fuel in... which is how a lot of kerbal airplanes get designed, so its not a complete write off. But the thing is, all we did was fix the glaring issue with nuclear by giving it its own fuel type, otherwise we swapped one kind of "handwavium" fuel for another. Our not very realistic fuel just swapped from being our "Liquid Fuel and Oxidizer" rocket fuel in KSP1 to our "Methane" jet fuel in KSP2. So unless they really went deep and adjusted all the combustion efficiencies and everything else to make the methane fueled jet engines realistic (which I doubt, because what's the benefit the game design to make the jet engines worse?... and from the limited flying I've done the jets seem more powerful than in KSP1?) then there's not a lot of point to just for the sake of appearance, make Monopropellant into something more realistic sounding. Which is far from a simple choice, since we've got different kinds of hydrazine, is it "normal" Hydrazine? is it Dimethyl Hydrazine? Unsymmetrical Dimethyl Hydrazine? Is it Nitrous Oxide? Hydrogen Peroxide? Something new like Hydroxylammonium nitrate? Perhaps we get one of the not entirely "mono" monopropellants like Cavea-B (more technically 1,4-Diaza-1,2,4-trimethyl bicyclo[2.2.2]octane dinitrate dissolved in white fuming nitric acid) which had to use a little bit of UDMH each time to light the engine, but was otherwise a monopropellant as the Cavea-B burned in the engine by itself after ignition. All of these with different densities and performance, and all of them valid choices, except maybe Cavea-B... So, is it even worth it? We still have a level of "don't worry about the details" when it comes to our "Methane" jet engines... I'm all for realism (huge Realism Overhaul fan, cant wait to see how KSP2 goes for mod makers, because I'm already imagining how good Realism Overhaul might be as a KSP2 mod) but its still a game, its meant to be fun, and getting too technical in places probably hurts more than it helps because it leads to people being distracted by details and complaining about things like "you cant get that much thrust from a hydrazine monoprop thruster, it would have to be UDMH".

Sounds like a nice clean and simple bug report. Mods may want to move this into the bug report forum.

I think were missing a couple of obvious procedural parts. Procedural flat panel Wings are not a substitute, they are curved and look wrong, I like making rover bodies from the neat flat panel parts, but it would be a billion times easier with procedural ones, using procedural wings in KSP1 worked because you could make them flat, you cannot make the KSP2 wings look flat Procedural fuel tanks Given differentiation of the designs, might be best to avoid the sort of all in one procedural tank stuff that we got from KSP1 mods, and to just give us a procedural tank per fuel type, so that the existing look and feel of each fuel's tank style can be maintained.

Yes, which is why I expect that if they do add this, it would need to use a modifier key, so it would be normal scroll for zoom in and out and something like shift + scroll wheel or alt + scroll wheel for up and down. I leave room for a solution that doesn't need a modifier key because I'm not the developers, I don't know what clever solution they might cook up, but I expect the answer will just be a modifier key.

I would if I had any basis to assume it was one, and not just weird quirks of how they built the game... I've seen weirder things in software state serialization output before. This is "weird" sure, and now I know its on my mental list of things to keep an eye on, like the null guids and possible guid conflicts causing issues... But without more, it feels like it just wouldn't be a helpful bug report, know what I mean?

Whenever this comes up, I just point to the n-Body addon developed for KSP1, Principia If a bunch of people can mod this sort of thing into KSP1... It goes to show how this sort of thing is doable, even if we have to do it ourselves. Of course, this does depend on them not somehow hobbling mod support so that such extensive mods are impossible... which given the goal includes multiplayer, I worry may happen... Multiplayer and Mods seems to be a bridge too far for many development teams. The missing n-Body and the current wobbly unity joint physics makes me worried that very little effort has been put into the "rocket physics" in the vacuum of space as opposed to the apparently pretty good airplane physics (haven't made a plane yet, I like rockets more) which would obviously be a good fit for multiplayer dogfighting or just general flying contraptions with friends. This also makes sense when I hear about bugs like phantom sea level drag stuff like this. Its hard to not notice this sort of thing if you put something into a close orbit to take cool screenshots while whipping over the surface of a moon close enough to feel like your flying over it.

This is a pretty simple one. Give me a way to tell KSP2 to "stay in its lane" and keep its save data in the game's install folder, where it (at least in my personal opinion) belongs. I have 1 save game, with just a couple dozen vehicle (attempts, with little success due to bugs) and I have nearly 250MB of data in my %appdata% now. I can easily see this growing since the breakdown so far is about 50% crash data, and 50% game saves a 1 vehicle workspace is about 4MB of JSON data and a save file seems to contain a primary file between a couple KB and 6ish MB and then a set of four autosaves at 4MB each for a total of about 25MB of save data for a game with no active missions and just some junk I cant delete so I expect this to significantly grow in size with active missions, as it appears to be keeping the entire vehicle hierarchy in the main save in addition to any individual workspace files. (I'll update this if I manage to get multiple things into space and save without crashing so I can tell if the file size increases correspondingly) Crash data for this game is at a little over 3MB per crash, and the KSP crash reporting currently has 39 crash report files. Which feels pretty close to the number of times the game has crashed to desktop on me. So I expect this folder is just growing without any limit, which I have no issue with in normal circumstances, but given how many crashes I have in 27hrs, thats less than 1hr per crash, this will likely grow to a significant size and cause issues with my main user "windows" drive. My C drive is not my biggest drive, never has been, its often my smallest. Ive got media files on HDDs, project and asset file asset dirs on larger SSDs I can easily drop into a new machine if anything happens to this one, and a more expensive M2 PCIe NVME drive for the stuff that needs high IO like my development environments so the compiler can pull all the small files together, etc... and spread out across all of these are steam libraries with the location chosen based on how I feel... tiny 30MB game, chuck them all on the spinning rust, they arent big enough i care, large game I rarely play and dont mind the load time, sure HDD again, game I like and want to be able to open quickly, maybe on the SSD, game I want to load as fast as possible or hate any interruption while playing, maybe that gets a place on the expensive high IO NVME... I gave KSP2 a spot on that NVME drive, but it seems to want to put its data on my slower windows drive... and fill it up with crash reports. This is silly. I dont want yet more junk in %appdata% If I delete KSP2, I want to delete KSP2, that means all the data gone, not taking up extra space somewhere else. Having a hard coded one true directory where every version of KSP2 puts save files, feels like it will cause issues with conflicting files between different versions of KSP2 once we have updates and start having to deal with things like Mod compatibility between versions of KSP2 Early access = lots of bugs, lots of bugs means lots of crash reports, lots of crash reports mean filling up my windows drive, don't fill up my windows drive. %appdata% isn't %tmp% (not that windows is particularly good at keeping %tmp% clean) don't fill it up. Just give me a place in the global config or something like that, where I can say "data files live in the game directory"... or better yet, make that the default behavior, because the current one doesn't make sense for a game that expects to have a modding community in the future. The current default will either need workarounds to avoid conflicting save file versions between multiple copies of KSP, or its going to cause problems... or a different save directory can just avoid the issue entirely.

Oh absolutely, its why I'm so frustrated by this game. It looks better than it plays and I'm fighting the part of my brain that equates "looks good" with "probably is good". As a developer, I've rushed a polished demo, most of us have, we see how easy people are to convince that something is "just about done" because it can do most of the stuff, like a demo mobile app with everything in memory, without any persistence, or api framework, and completely without a backend service, and like 80% of the work might still remain ahead... but the client looks at the thing they can touch, that you built to evaluate that you understand what they want in terms of interaction, and now your backend guys and gals are in a mad scramble to make anything function because management heard that the UI looked great and ... people were even able to use it to do the things the app is designed to do... and so a deadline gets set. In any case, I'm going to try to limit my interaction with this till its more polished, but its going to be a struggle because of how much I want a shinier KSP1, and as a dev I know feedback is valuable, I also know how much feedback they will get so its also hard to think of anything, no matter how much effort I put in, as anything but a waste of my time. For instance I'm genuinely baffled by some of the serialization weirdness I see in the save files. "ActionType": "None", "oabOrientation": "VAB", "Assemblies": [ { "assembly": "", "Assembly": { "Version": "0.1", "Guid": { "Guid": "00000000-0000-0000-0000-000000000000", "DebugName": null }, The existence of "assembly": "" and "Assembly": { looks very odd, and almost looks like a default initializer is hardcoded somewhere and populates a lowercase value before the struct is assembled with actual data about a vehicle, and then there is a null guid, which is weird, like guids are built in to C#, its not hard to make one, even a magic one to tag something per build, its so weird to see how many null guid attributes are in the KSP2 save files... it just gives me a bad vibe, the programmer equivalent of hearing an unsettling creaking sound that makes you wonder if a building or vehicle is safe to be inside.

The bug is "Lack of method to move camera vertically in the VAB without performing a click and hold mouse movement with the middle button" As the owner of many mice and input devices (not a collector, just a frequent shifter to prevent RSI, my current desktop uses 3, Logitech MX "mice", the wireless trackball, the Master and the vertical mouse, and my mac laptop also has a touchpad, and for a while I also used the magic trackpad) ... While "Middle Click" is simple enough, and "scroll wheel" is basically ubiquitous, unlike the "Left/Right Click + Move Mouse Cursor" interactions, the "Middle Click and Hold" or worse the "Middle Click and Hold + Move Mouse Cursor" are often secondary considerations in the design of a mouse/input device. Take for instance my Logitech MX Vertical, the mouse is light as its sold to avoid RSI, the movement shouldn't require much force, the left and right click buttons are lightly weighted and take little force, as you expect on a lightweight mouse, however while the scroll wheel functions fine as a scroll wheel, the click button under the scroll wheel takes at least 3x the force to click as the left and right buttons, its enough force that it puts a noticeable torque on the mouse which is fine for a single click but not a click and hold, the force to get a stable click and hold for large mouse movements like that required to move the camera, requires a tighter palm grip and an adjusted click posture in order to retain "firm control" of the mouse and make the multiple large motions to click and drag the camera , making a large movement like repeatedly clicking and dragging the mouse more awkward and frustrating than any other kind of mouse interaction. Suffice to say... I don't use that mouse while playing KSP2... But its a great illustration of the sorts of ergonomic affordances games intended to be potentially educational (its hard to argue KSP2 doesn't have the same educational potential as KSP1) should be mindful of... and this middle click in the VAB is one of the most annoying little papercuts, up there with not having key bindings for all the UI buttons in the VAB,

I was so close to requesting a refund for the game... the first Steam refund I'd ever have requested... because of how frustrating it is to have the game crashing constantly... This is the sort of buggy where you can go get a coffee and find the game somehow crashed while idle in the VAB ... and I know it comes down to how these games get tested... There's a reason as a fellow developer... even one that's not big on writing tests... I'm appalled at the low standards of testing in the video game industry. Tests that usually consist of humans doing a list of things by hand with all the variability of a human... making reproduction of bugs harder, and making it nearly impossible to catch bugs that slip back in due to merging code or logic pathways that come into or out of use depending on size weight or shape of game objects... Effectively its a loop of "Enough players complain about X happening" -> "Things goes onto the checklist" -> "Tester takes item off the checklist and has <units of time> to try and reproduce the bug, document it, and log it to a real bug tracker" -> "Devs look at real bug tracker and try to fix things logged by testers". This is in stark contrast to more heavily tested environments... where you might run hundreds or thousands of small unit tests on modular functions of code, and for user interfaces (or interactive environments like games) you run scripting harnesses that pretend to push buttons and click icons, and sequence through instances of known user behavior. Sophisticated scripted interaction tools even exist for this in the "complicated" world of video games... but the thing is... it gets used by an appallingly low amount, because having a big build farm constantly running tests costs money, and "tester" is seen as a traditional niche in games industry, from which people can be recruited from the outside allowing it to be a filter for people before risking development or other positions. All of this is also not accounting for the fact that this is the second version of KSP 2 ... after the questionable stuff that happened between the original dev team Star Theory, and the publishers Take Two, the historical context is available (Original: https://www.bloomberg.com/news/articles/2020-06-03/kerbal-space-program-2-release-disrupted-by-corporate-strife Archived for easier reading: https://archive.is/vZQDm ) All this to say that KSP2 has a lot of problems... and what stopped me requesting the refund was when I remembered how many KSP1 had and how much of those were fixed by the modding community. While I know I've played stock KSP1, I genuinely think I've had some mods going for about 99% of the time I've ever played KSP1... From Joint Reinforcement to help wobbly physics, to Engineer giving me a better deltaV calculator, mods made KSP1 "playable" for me... made it more "fun"... and KSP2 is just so new the mods don't exist yet. (though I believe someone may have already done one to avoid a bug, I'm not sure I only saw it in passing because I'm busy writing replies and trying to fix a bug with my entire set of vehicle saves)

As someone with multiple hard drives... This infuriates me because I put KSP2 on a separate hard drive. I was asked where I wanted KSP2 to live, I selected the place I wanted KSP2 to live... and KSP2 decided "nah, were just going to throw our crap where ever we like" and puts stuff on my busy, space constrained, C drive... I don't like it when Adobe does this, and I like it when games do it even less. Secondarily to the "I hate programs taking up space on a hard drive I didn't install them to" issue... This has repercussions for mods and beta install testing and the sort of thing most of us have gotten used to doing when we keep a rich collection of mods. I cant have 6 installs of KSP2 nicely sitting side by side if they all try to load save files from the same folder with potential corruption issues if the games try to automatically load files in the directory, I've seen some games that just auto delete save files they cant load... who knows. Its just not how I as someone that loves mods want KSP2 to work... I want it to keep the save files for a copy of KSP2... with that copy of KSP2.

Thank you guys so much for this.

Really? Because After thousands of hours from KSP1 to train my brain this never occurred to me... I've literally been making one craft one workspace saves for the entire couple dozen hours I've played KSP2 so far... Between the potato smear thumbnails, the autosave mechanism I've not worked out, the complete lack of any indication which "workspace" I was using... I had no idea it actually worked this way... I genuinely assumed "workspace" was just a weird name for "save file name" and got to business saving everything in separate files to not lose any of my precious horribly buggy ships. This isn't sarcasm I'm just surprised to find out this is what's going on. ... And I'm going to keep doing it because of all the bugs with recovered ships, the VAB, docking undocking, etc... This is a game I've never "exited" its always crashed and I decided to not open it again for a while... I currently have no faith in the save/load not screwing up my stuff yet, so I think it will be a while before I consider having more than one thing per workspace.

Awkwardly dragging the camera up and down by holding middle click down and moving my mouse around is not "solving" the fact it should be possible to just scroll up and down easily with/without some modifier key.

I'm getting pretty frustrated by hidden controls... For all the UI improvements in KSP2... this kind of mystery meat navigation hidden behind clicking buttons I just clicked a second time sucks... who does this without prior knowledge?.. that's right no one, no one does this deliberately. A lifetime of computer use has trained me to click a button once, see the expected feedback and then know my modality of use has changed and mentally move on... to the level its something I don't think about... click button, next thing happens... this is how a computer works. ( I write software so I know what goes on, I too have read the everything that happens between your finger pressing a key and the letter appearing on screen blog posts. ) This sort of design gets a flat ZERO score for how easily users can find out features without prior instructions when critically analyzing the UI and UX of professionally developed business software, the sort usually written to automate or assist with business processes in a million little ways around the world.

I found some stuff on GitHub but nothing I could point the package manager at like the official instructions say... I've got no idea how to go about dumping random stuff ripped out of other projects into this specific version of Unity. I don't know whats in the original download, so I don't know what would be missing so trying to reconstruct the zip based on random DLL files left in random git repos seems like... a less than ideal way to get things setup. Hoping someone just has the original file and can either post an upload, or list all the files so I could try to reconstruct the content of the download in such a way that the package manager knows what to do with it and the original instructions still work, just with my reconstructed zip file instead of the original download.

If its not needed, then why does everyone always say its a requirement for the part tools package? I didn't see anyone describing it as "optional" or "only needed if your going to do <something>"... I even found someone saying that the exact version was needed because things wouldn't recognize another supposedly compatible version . So to keep this on the topic of IVAs, is this step needed to setup things for editing IVAs in 2023? or can we skip the step? and does anyone know what will be broken (if anything) in the official PartTools, by not having the correct version of TextMesh Pro?

link is still broken 3 months on, its kind of a showstopper, anyone got a lead on how we can still download TextMesh Pro Release 1.0.56 - Unity 2017.3 now the link is broken? I've been searching and basically all I'm finding is other people noticing the link is broken, and people talking about how you have to download that exact version for KSP modding.

I'm looking for this file too, I suspect a lot of people have the files from before the link broke. But I have no idea how long ago it broke, since it looks like people started asking about the broken link only a couple of months ago. Does anyone have a copy of the file? Or where I can get one? If this file is a prerequisite to any serious KSP modding, then it disappearing basically means if you didn't already get yourself setup for modding, you cant now and the KSP modding scene is going to slowly die. Surely there's a way to get the file still?