TechDragon

At over two hundred hours, at least 25%, possibly closer to 50% what with all the construction glitches requiring so much rebuilding from scratch as though save didn't exist at all... of which has been spent in the VAB... and I still don't intuitively understand whats going on with Workspaces + Vehicles... The glitches ruin any trust I have in putting more than a single vehicle in a workspace, heck I'm not even completely confident vehicle construction glitches cant permanently break an entire game save file... If I want to be able to ever use a rocket again I have to ignore whatever the intent of the entire save system design was, and very specifically use it a certain way in order to isolate bugs and prevent losing multiple craft designs and the hard work that I put into them... After they fix the construction glitches, because nothing will matter if I still cant trust the game with more than 1 vehicle per workspace... after that... if they want the whole Workspaces and Vehicles thing to make sense, they need to do a lot of work on the UI... I have no idea what has been saved and not saved, what groups of part are named (and saved) vehicles, the autosaves get mixed in and make it hard to find which vehicle I want to open once I have more than a half dozen vehicles... its just such a damn mess.

... wait... are you saying if I click on the old ship thumbnail it doesn't prompt me... because I've put like a hundred frustrating hours into KSP2... with so much of it spent rebuilding and overwriting crafts due to construction glitches with big rockets... and I never worked this out... so if this is indeed what is meant to be done... it is a ludicrously unintuitive user interface for craft save/load. Also this is still an issue in 1.3.1 and 1.3.2 (so it needs more bug tags)

This explains several mystery craft failures I couldn't understand. Trying to simply build a big booster and having the struts become useless was very confusing...

Not to get too far off topic, but I have to say I partially agree, but I want to express the understandable frustration since its relevant. As much as I continue to try and be informed, I find it harder than ever to be sure of things, and I've drastically slashed my game purchasing... I went from dozens of games, a couple large, few medium sized, and heaps of small games a year... to under a half dozen typically larger games, or established indie games, or games from developers who have earned my trust with consistent releases, per year at most... its harder than it used to be to be sure a game will actually be good. The malicious actors in business development and marketing departments got wise to the fact we as gamers are buying a product we expect to make us feel things, so they start trying to manipulate that aspect of our psychology before we even click the buy button. Things like pre-orders that have in game content effects play on our fear of missing out, sometimes the stuff on the pre order just genuinely looks so damn cool, but now you have to buy ahead of time, and what if its a game on a platform not like steam where there's a generous refund policy... there's lots of manipulative behavior that people trying to separate gamers from their money are now using, to make it hard for people like you and me and anyone else trying to make informed purchasing decisions are now subjected to... And it kind of sucks. /end off topic pseudo-rant. Back on topic... This is why I'm concerned about things instead of sitting back and going "well I guess I have to wait and see", they asked for feedback, this is why I'm bothering to try and understand and work out what they might be thinking with respect to procedural tanks (and other things), since its relevant to how I voice support for something, what things I'm complaining about because sometimes stuff is obviously going to get better, like I've never mentioned the "do you want to overwrite this vehicle" popup that happens every time I do a final manual save due to the autosave workspace system, its just a minor irritant and I'm sure it will get a little attention and fixed up and made nicer later. If they have ZERO desire to have procedural tanks, there are some natural consequences, like that wings will never get fuel in them, since the moment you can make procedural wings with fuel in them, people will be incentivized to use them when they want more control over tanks volume, instead of using multiple smaller tanks. There's knock on effects and its understandable they don't want to comment on future plans, but its frustrating to sit at my keyboard, typing up stuff like this comment, about stuff they may have all but 100% decided something will not happen, or its already put into a bucket marked "maybe that would make a good DLC later, if we get that far, definitely not something were going to do in the basic game" This is sort of the reason behind my desire for an issue tracker, there are people getting very deep into this game already, there's a community fixes mod already because people are finding and fixing bugs for them... which is something that shouldn't be that necessary. If a bug is confirmed enough to fix in a mod, it would be good to have a public record that "we know about this specific thing too", and then later on when they fix it or even before if they are super confident the fix will be in the release they can mention it before hand so someone could remove it from a community fix mod.

Wow... I'm constantly on the edge of giving up with my massive launches because I usually start with a vehicle design and then try to work out how to launch it... and I suspect I'm missing out on some of the favorable physics behavior I suspect is going on in your designs. I'm definitely going "too tall". And need to find a "payload" design I'm happy with that lets me design a more flat layout like your castle has there... And inspiration has already struck I think...

From the look of it, even with two objects side joined end to end like conical sections joined upside down under the 2XL round Hydrogen tank... the struts align their symmetry to the part being attached to. So if you flip the parts around, the "order" (not sure what else to call it) of each struts location, is located on the target part automatically in a specific order that is reversed when you flip a part around, and I suspect similar behavior is happening with the weird targeting for struts to side boosters. I've got screenshots if the "order" symmetry stuff isn't entirely obvious and some visual help is needed.

I've definitely decided to take some inspiration from this. It would be good to try and quantify the different join strengths... but with the launch clamps not having infinite power it makes it much harder to isolate single joints and test... some of the mods that are beginning to appear might make it a bit easier. But its definitely something that people trying to build large ships would benefit from. Radially connecting tanks is... ridiculously fragile compared to most other methods which is really weird compared to KSP1

I don't think the volume calculation is very difficult for procedural tanks that are cylinders of the standard diameters, but where you can vary the length. It could be that the game's architecture doesn't currently support parts with dynamically calculated resource capacity. We have procedural wings that can be adjusted in thickness (which affects mass but not lift or drag), but they can't hold fuel, whereas KSP1 had some larger wings that could hold fuel, but KSP1 wings were not procedural. But I'm more inclined to think this is a deliberate choice to stick with predefined tanks and tank sizes that you click together like lego bricks. As a developer who's looked at the code for at least 2 KSP1 procedural fuel tank mods... yeah its not that hard to do the "how much stuff fits in here" math. Not even that hard to write some extra code to round nicely to more neat numbers like 9.5ton instead of 9.4598ton and have that affect the visual design components of the tank, like how rounded the tank end caps are since that affects the volume and can tidy the numbers up inside an otherwise cylindrical volume of choice... Not having the "procedural parts" system ready to interact with the "resource" system would make sense. Based on the milestone approach they are outlining, "procedural parts without resources" would naturally be an earlier milestone than "procedural parts with resources"... but this is simultaneously at odds with obvious gameplay roadmap planning, if you recognize the propellant tanks are something that should also be procedural, then it makes "procedural parts with resources" would have a high priority and be something that was likely to be done before EA release so as not to confuse people later on when suddenly all the tanks can get done away with and you can switch to procedural tanks instead... Some of this crystal ball gazing is so puzzling... like wobbly rockets... did they not look at the best solutions from KSP1? the code is up on GitHub for multiple mods that have licenses that wont preclude them just taking the fix without anything more than some text in a readme file somewhere. If they are planning procedural fuel tanks then wobbly rocket issues may soon be reduced, so why bother focusing on them yet, so silence makes sense if the future roadmap has fixes... but at the same time, its still really confusing to release to EA with some massive stuff like "procedural propellant tanks" not bedded down at least to an EA level, as this will probably have significant positive performance impacts... or perhaps they wanted the worst case performance of non-procedural tanks in the first few EA releases to help find other bugs in the physics engine? I'm not sure what else I can put it down to other than "deliberate choice" with a caveat of "at least for now" to have the tank segments and corresponding wobbly rocket instead of procedural ones... We really need some sort of "public issue tracker" even of the most high level vague kind... in order to end the constant speculation and little arguments about what they may or may not care about... Like for instance, I've noticed while trying to launch a big nuclear tug in one piece, that the game has a bad habit of making rockets more unstable at slower FPS... easy test is to make a big tree of XL tanks with 9+ Vector engines on the end of each tanks, and get to 100+ engines... and once you get the FPS down real low, you'll start to notice rockets with very little "logical" reason to not be physically stable... all tanks have the same physical force aimed in the same direction, in a parallel direction... yet slow FPS makes the physics simulation... deeply unhappy... it turns out you can summon the Kraken by slowing the game down long enough you give it a chance to escape and attack your vehicle between video frames... do they care about physics instability? do i bother making a save game, just to show "the game breaks when you put lots into the scene" or is this just pointless work on my end because they aren't interested in fixing the physics engine at low FPS... which is not completely irrelevant since if you have a momentary lag spike for whatever reason, you don't want spontaneous disassembly due to a couple of seconds of lag... and I get that they have priorities, but its really easy to feel like they don't care when we throw reports over the wall and only find out if they were listening when we get a cute little rocket next to the bullet point in a future release explanation post.

You do realize the most "samey" part is literally the 50 differently sized fuel tanks? Wings are a leap in the right direction, radiators and solar panels make a lot of sense, but not doing it for tanks (when they're the main source of "le wobble XD") is contradictory. This... a million times this right here. The moment I read the question and reply, my mind without a single second delay, went "what about all the tanks"... So this needs to be the double down question in the next AMA... like a coordinated campaign to have multiple people ask it to raise the odds or however we can try to get an answer... because its so bizzare they are making decisions with a criteria of "there's a lot of parts that are kinda samey" and somehow haven't noticed how basically all the Methalox tanks are boring "kinda samey" stuff... i mean do they not ever use more an one tank per stage or something? how are they not seeing the boring stacks of tanks and thinking "kinda samey"... I'm baffled.

We really shouldn't need to have extensive juggling tools for stuff like this... I genuinely cant understand why they have put the game save data in the current location while continuing to state they intend to support modding. Mods + "Only one save game folder for all copies of the game no matter what mods may or may not be in each of these copies" = An obvious bad time waiting to happen Now its entirely possible the developers thinking is something like this... they can track the mods that use whatever official API is released, and they intend to annotate the save game information to track which mods are involved in a game and to have some kind of a mod manager UI that wont let you open saves that have/need mods that you have turned off... and I've seen some games use this sort of setup so its a "known solution" to the issue... but it also tends to be a solution used for games with, much less flexible modding options, or much less creative and inventive modding communities. This works for simpler mod scenarios, part addons, UI changes, high level and cosmetic stuff that doesn't affect the game particularly deeply... We're dealing with a modding community that developed a mod to replace the SOI based orbital dynamics with an n-Body integrator to get more realistic orbits! Regardless of the likely hood of a KSP2 Principia mod, its an excellent example of the kind of "deep modding" that the KSP community seems to have a penchant for... and these will not play nice with a restrained tidy modding API that fits neatly in a box you can track per save file... its going to be an issue and its an issue with an easy fix that they should just be doing now rather than later before more mods get made.

First time it was literally loading a new game, Second time after deleting all the existing game files it was during the introductory trailer, Third time it was right as the trailer was nearly done after deleting all the existing user data and trying with absolutely stock everything including flag and colours... fourth time it was about 40km up with a stock Kerbal X rocket... I had my issues with the first version but at least I could play it... like swimming in molasses but at least I was swimming this updated version is just... broken.,. The backtrace breadcrumbs from the last crash is [snip] and the player log is [snip] Hope all of this helps... I don't see a good way to upload the crash dumps here on a forum post. But I have all 4 of them too.

Yeah, while were still suffering from wobbly rockets and performance issues, ascent guidance is sorely needed. I've had a few failures that based on KSP1 experiences, I suspect would have worked if I I had been able to ride the throttle correctly... which is very had to do by hand when the game is basically in ultra slow motion, but MechJeb was always a champ at controlling that sort of "this rocket is so big KSP will lag when you launch it"

I agree its better in a lot of ways, but I too find it far too sensitive with the keyboard throttle. I think we still need the time for throttle up from 0 to 100% to be longer, I want to be able to just tap up my throttle a bit, for fine control while landing, not have to carefully adjust it with the mouse, when I simultaneously need to use the mouse to adjust the camera to check my ground clearance and other things.

The one thing I do hope we get, at the very least is the R-7 Vostok/Voskhod/Soyuz stage one "side" tanks., It was an absolute joy watching my extra heavy boosters throw off side tanks and produce Korolev crosses, snowflakes, and double crosses (4,6, and 8 way symmetry respectively) they just look so much more satisfying than the solid boosters with seperatrons.

Yeah, I did skip the account creation. What I meant by continuing to click the anonymous option, was that if it comes back after an update, I'll click it again and continue to click it whenever it appears.

If there's anything KSP players have, its patience... so so many thinks in KSP have been lessons in patience over the years Nothing like being too low for time warp and having to wait for your polar orbit to circle round to where you need it to be for that high inclination Mun rescue because you don't have enough spare fuel to raise perigee and use time warp... its just time for a tea or coffee while you and the rescue Kerbals wait for the right moment. Or running out of fuel on the way back to Kerbin, having just barely dipped into the atmosphere, and now its just patiently waiting orbit after orbit, each time time warping as fast as you can, but still having to wait for each dip into the atmosphere to happen at normal speed, until you finally aerobreak enough to re-enter and succeed at getting the mission home.

Your right about the potential communication risks, which is why I don't think they could release this sort of build without a bit of effort putting up some danger tape and guard rails to make sure no one can confuse a nightly build bug from a release build bug, assuming there's a screenshot or video at least, and its a lot easier for the community managers to calmly reassure people that nightly builds are ephemeral work snapshots, some may have major issues if they are working on massive things, and I suspect it would take several days of getting worse before this sort of messaging lost its effectiveness. And as for the second bit, yeah this is where it really comes down to insider knowledge neither of us have... for all we know the entire release process is fully automated and they just merge to the release branch or tag a version number on the main branch and their build pipeline swings into gear and generates a build... nothing about automated build of a runnable binary ensures the quality of those builds, I had a little mini rant about game testing in another thread that I wont repeat in full, suffice to say that without knowledge of the current Build, Testing, and Release pipeline, all the manual and automatic steps in the chain, all were both doing is armchair quarterbacking from a safe distance based on personal experience. I only brought up the idea of more frequent releases because I've seen it done well for other games and programs that have communities desperate to see updates and progress, as well as the possibilities for them to have a beta program that multiplies their "calm" portion of the community. If I had access to a beta build and wasnt gagged with some kind of NDA, but asked nicely to not comment in detail (as opposed to not at all) about the changes bugs outside of a private beta bug sub forum, then my tone might go from "I hope the dev's are making progress on the important things" to "I know they are guys, those of us that have seen the beta know it, just hang on till the next public build", it might also make their lives easier in terms of bug reports. I think I reported like 20 posts in the bug forum to the mods for merging into other larger threads about the same bugs, often earlier ones with clear video examples, where someone still posted a duplicate bug report... which is a situation that likely wont get better as new players filter in for the next couple of weeks based on paychecks, curiosity, job schedules, etc.

While that's the ideal way to deliver it, the other way is making it someone's primary job to ensure your build pipeline is functional, and even with a team making constant changes, there's typically a series of punctuated spots along the way where the build is "good enough" to ship, and its these builds they would be putting into a "nightly" beta. As for "catastrophically failing build"... I don't want this to imply what they shipped was somehow a literal turd, because it looks pretty, and does play well enough for some people, particularly for aircraft, but based on my personal development experience (which I'll admit is limited for Unity games the size of KSP, but I am familiar with Unity builds and C# in general) I'm not really sure if nightly builds would be "worse" than the current release build... since its acknowledged that there are a significant amount of high priority game breaking bugs, many of which completely prevent people from playing.... For these people, any build with those bugs fixed is better than the current release build. I don't think that even with "manual" releases being built buy a release manager every day, they would be worse off than they currently are. Its a bit of a catch 22, they are damned if they stay silent and work, and damned if they speak up about work is underway... nightly builds with lots of big in game "DAILY DEBUG BUILD" type test to make it clear to players they are playing a potentially unreliable build that may have new bugs or may have fixed old ones, or not, this is the current bleeding edge to show people that work is clearly happening even if its not being communicated daily because they are busy fixing stuff... and we can all see the daily build for proof.

What's interesting is that we don't see "test builds"... given the raw state of things, I would have expected one tactic to be putting a dev familiar with the release process in charge of trying to ensure a build is in a shippable each day and releasing "nightly" builds to steam that require users to opt in via the beta mechanism, as both a show of good faith that work is indeed happening, and to get faster feedback on if the changes are having the desired effect on the huge variety of systems. The could even ration the betas as I believe this is a supported option in the Steam platform. What I'm wondering is if the decision to build and use their own Private Division launcher Note 1 has complicated this sort of tactic, by way of intermeshing the game itself with another system that may not be capable of such a high release cadence. Note 1:

I had this happen to me as well. But wasn't patient enough to try and find the offending part. If anyone else is, it would be very good to have before and after save files so that the save data for the part can (hopefully) be found in the JSON, since there could be some data corrupted in the save file that would help the dev team.

The game makes a lot of weird little beeps and boops in the VAB, which sound extremely similar to various Steam/Discord/Phone notification sounds... Its genuinely been causing me to alt tab to other programs to check nothing is happening. I don't know if they are actually the exact sound, but whatever these background noises are, they are way too similar to the sounds a lot of other programs are making.

Definitely think you guys have more important work to do at the moment than trawl the individual threads looking for duplicates given the polarized opinions over the quality of the release and the concerns with price... and all the existing KSP1 players still chatting... Thanks @Gargamel for the quick reply, this is exactly why I asked for some advice about how the mods want to collectively handle things, decades of internet forums have trained my brain to think "report is for spam/threats/amazing person" but it is also usually the only thing all the mods have a shared view on... so if report and explain the situation is how the moderators want to do things... then I'm happy to do things that way. Also, ouch, sorry to hear about the PM flood. The stuff about only the current mods who are online will see the shout outs and how the merged stuff will look afterwards is also super handy context since I didn't know how this particular forum handles the move/merge.

Having made a plane in the last half a day since my original post, yeah planes feel fantastic, I just chucked something together with big old wings and the afterburning fast jets, did a liftoff strait into a zoom climb and had an apogee around 37km, and it was a bit chaotic as i dropped back into the atmosphere, I definitely did some maneuvering where I feel KSP1 would have ripped my wings off, but I think (it was a black plane at night, so I'm not completely confident of this) the wings didn't even flex, it was like I was flying a solid object. The wobbliest bit of my plane was the wheels on the landing gear! I'm really tempted to make a space plane to see if launching from the runway makes rockets less wobbly, the physics just felt that different. Which puts me back to my concerns about what the focus of development efforts has been. I am while not convinced, pretty confident much more time has been spent polishing planes and flying, because flying is more conducive to a "dynamic" and "interactive" multiplayer experience in "real time together" as opposed to orbiting rockets, where orbital phasing takes a while, frequently requires a time-warp or two if you don't have all day, and then docking is slow and steady to the point quite a lot of people find it boring... Its a fun challenge to do by hand on a new craft which you've never flown before, but it does get tedious to repeatedly dock refueling flights or crew transfer flights. As a developer it feels very understandable to have prioritized things this way, but it does make me worried that were in for a long slog of space related bugs... I hope I'm wrong.

Since theres been a lot of technical talk, bringing up WASM and other scripting potentialities, I'd like to point out that there might be a built in scripting language. I haven't dumped things into any tools to check this, but two DLLs stood out to me when looking around for a half remembered late night fix for frustratingly wobbly rockets (I was looking for and eventually found the PhysicsSettings.json) but I came across these two: "Kerbal Space Program 2\KSP2_x64_Data\Plugins\x86_64\LuaPipePlugin.dll" and "Kerbal Space Program 2\KSP2_x64_Data\Plugins\x86_64\LuaPipePlugin64.dll"... not a guarantee because who knows what it is or what its doing (I sure don't, because as i mentioned, I haven't bothered to decompile anything or look that deep) but "Lua" is a scripting language often used for adding modding and scripting into a game. A couple minutes google searching didn't bring up much beyond some roblox stuff, and a lot of generic Lua and C# type info, and some Moon# stuff, but the point still stands... if that's is a Lua scripting plugin then that might be how mod support will work, and if the mods support is via Lua, then theres at least the possibility of some "logic" being able to be scripted using Lua. Subject to whatever limitations are added as Lua can be quite heavily constrained and they might put a lot of constraints on it to keep the mods "safe" for multiplayer or something like that... Just some thoughts, my 2c, etc. Thought I should point it out before anyone's enthusiasm leads them to invested time in WASM or anything else beyond the obviously applicable C# (cause its Unity) when we don't know enough yet.

There's quite a bit of stuff I'm seeing that could be merged, is there a good way for us to politely nudge for merging in the bug sub-forum if as just a forum reader/participant and not the original authors or a forum mod, come across stuff that has described the same problem in different ways? And on that point... theres quite a lot of "evidence of bugs" in the feedback forum threads, which for quiet threads might be easy to merge or move, but busier active conversations may only warrant posting quotes/links, is there any preferred way to handle this? Calling for the mods to move vs just posting the link or quote in the most appropriate bug thread already in the bug sub-forum?