kfsone

Maybe if they're using their own UI system that would be true, but if they're using one of the popular unity-favored UIs (and it looks a lot like imgui to me, but I'm biased) then testing the sort of low-level brokeness isn't hard so long as it's not an afterthought, which isn't unusual in a post-indie team; sooooo many post mortems that go "well, testing... turns out you need it from the start". As I said, this isn't so much about the buttons themselves: it demonstrates that QA doesn't get the information it needs to perform quality control and testing, or a controlling interest over what gets into the code base. I've never related to some of my peers' disdain for needing QA approval for changes to make it into main/master/trunk.

Yeah. But also sort of no: I consciously stepped outside my player headspace when I read it, rather than as a player or a forumite or a reddit post by a rando.

None of those latter aspects are important. The fact is, KSP2 was developed in a way that wasn't viable for anything but a very small indie team. Of course "there will be bugs" but KSP2 hadn't even achieved KSP1-alpha quality at this point, and a lot of the bug-fixes in the last couple releases were workarounds. BugA in SystemB causes BugC which makes X happen where you explode if you try to leave an atmosphere. - Fixed bug where you explode trying to leave an atmosphere and a couple days later the known issues adds "we're aware of a bug where you may explode after leaving an atmosphere" The exploding and X weren't actual bugs they were just tells, and 6 months later it turns out that the workaround that was added causes .... And this itself is not the problem but a reveal of the mechanics of the team and their processes that is the software development equivalent of holding your breath until the monsters go away...

I counter with: Un-indieing and a lack of leading. Un-indieing: when previous talent moves upwards and chokes as a result. Lack of leading: no goal and no coherency. There are countless examples but the easiest is this: the HUD, and I'll give you two concrete examples from that, but I'm also going to be very terse because the true cause is systemic and not on individual UI dev's shoulders: 1- Lack of consistency between elements, lack of functional theme shows the lack of a style and theme guide, things that are antithetical to indie dev but do-or-die to a larger team; 2- Consistent broken state across widgets/screens/etc speaks to a lack of architecture, tooling, infrastructure, testing, and fundamental qa integration that distinguish an indie developer from ... a developer. objections: "ui: the game was in alpha they were experimenting" Nope: A UI like this serves one purpose, to look good in screenshots by being busy. First there's no anchor for the experiment, and second it wouldn't be possible if the code, tool and workflow infrastructure were in place. Without them, any such experiment is invalidated. "there are going to be bugs" This is true of a dead body, but if you want to know why the body died you have to accept that if there are flies coming out of the mouth 30s after death, chances are it wasn't a blow to the head that killed them: flies don't hatch that quickly. It's not actually, specifically, about the UI button-state, but that a bug of that kind, scope, and nature was released and remained. It's a kind of bug that causes other bugs, at every level of its code; and its fundamentally the most visible and testable kind of bug: it's a textbook case for the kind of code that even game developers like to have unit tests for, it's often the textbook case for integration testing, and it's commonly the de-facto onboarding example case for qa engineers. Was it not observed during all the time it was present? Was it not ticketed? Was it not marked a blocker? Was it not reproducible? Was it not tested? Was it not considered important? Was it not assigned? Was it not investigated? "its too early in development for you to ..." Nope: there's an expression "don't put the cart before the horse" (before meaning in-front of) but indie games are self-driving carts. If they have a horse then it is cargo, and they can put it in-front, to the side, on, in, under, or behind. The day I knew KSP2 was dead was May 4th 2023. Darrin's post laid out for me that the development process was stillborn; I know that Darrin knows - but perhaps being new didn't want to admit to himself - having to ask the users for help like that is a final/post-mortem request. It is grasping at rock you *hope* might be attached to the cliff you're falling down. I'm not faulting his post or Darrin. For someone with my background, it was equivalent to your boss at the nuclear plant coming in sweating, shivering, and retching while saying "nothing to worry about, just a bit of radiation sickness".

"Well, lads, smoke 'em if you got 'em. We're going to be crashing into Jool in a few days - we're out of fuel" "No we're not, we've got 350t of fuel in the tank at the front of the ship. Let's just flip the tank around, redock it and fuel up?" "Oh, we could totally do that... but without fuel, we can't plan for that" "Things are going to get mighty bumpy for a while and then we might crash and explode" "But I don't wanna explode; can't you just tap the RCS thruster in 2d 41m 50s?" "I could, but we're out of methalox" "RCS don't use methalox" "Look, you know that, I know that, but _do they know that_?" "Boy, sure would be nice if we had some grenades" Giving me feedback that I'm not looking like I can make a burn/turn/alteration is nice. But telling me I can't *plan* anything because I have no fuel could easily be a Windows Vista feature. I know they're called Maneuver Nodes, but they are also defacto timeline markers, especially when you're flying multiple vessels concurrently.

Had to give up on trying to get it to build on my system - not sure VS 2022 Preview likes JsonPeek and NewtonSoft.json - but I submitted a pull request that fixes some of the garbage-collection thrashing/performance issues.

Not quite sure where these choices are coming from, but you can simplify it a lot if you are running Windows 11 by using winget or on earlier windows I recommend you install Chocolatey Software | Chocolatey - The package manager for Windows With WinGet open a powershell or cmd window and at the prompt enter: winget install Git.Git with chocolatey, you need to open an administrator version of the same (hit the Win key + X and select the Admin option or press A) and type choco install git open a new terminal window and type 'git', and you should be set. Recommend you also do this in a regular cmd/terminal window: git config --global user.name "YourName Here" git config --global user.email "[email protected]" If you end up being known as "YourName Here" then you probably shouldn't be trying to mod KSP2

Hey, Kadestronaut, I'm finding KS absolutely slams my system after a while due to some memory management issues; I created a couple github issues, one before I had chance to look at the code and a second after I'd done a bit more digging which is kind of a sub-ticket I guess. The only non-work machine I have atm where I can install Unity is a Mac and since KSP2 doesn't seem to run on Mac yet, not sure if I'll be able to try and contribute fixes. TL;DR is the mod drives C#/Unity's memory management into craziness to the point that time runs at half speed inside KSP2 (e.g maneuver node countdown is 3 .. .. .. 2 .. .. .. 1 .. .. .. .. 0 instead of 3 .. 2 .. 1 .. 0). The problem is you're doing 'new' allocations like crazy, including for static lists: private List<KuriosityExperimentTracker> GetBestExperiments() { List<KuriosityExperimentPrecedence> precedences = new List<KuriosityExperimentPrecedence> { KuriosityExperimentPrecedence.Priority, KuriosityExperimentPrecedence.NonPriority }; List<KuriosityExperimentState> states = new List<KuriosityExperimentState> { KuriosityExperimentState.Running, KuriosityExperimentState.Paused, KuriosityExperimentState.Initialized }; every time this method runs, it has to allocate two new lists, and then grow them to contain the priority/state lists, which it gets from the static lists you already have above. You could immediately reduce this runtime cost with a simple change: // Make the underlying static lists as members of the class so they are created at compile time not runtime private static readonly KuriosityExperimentPrecedence[] precedences = new[] { KuriosityExperimentPrecedence.Priority, KuriosityExperimentPrecedence.NonPriority }; private static readonly KuriosityExperimentState[] states = new[] { KuriosityExperimentState.Running, KuriosityExperimentState.Paused, KuriosityExperimentState.Initialized }; But it would probably make sense to also try and avoid the other dynamic allocations you're doing in GetBestExperiments

Has anyone else figured out what gets you into the state where the VAB keeps telling you it's changing key control modes? Every now and again I have to switch from VAB to one of the other KSC tabs in order to unbreak symmetry or because it will no-longer place struts, fuel pumps, or even tanks. Other times an actual restart of the game is needed and I've noticed that seems to coincide with the "controls now in docking mode" etc toasts. I also get the sense that there's a pattern to when that happens. I mean, duh, I assumed it was 'adding a docking port' during the session - but attempts to make it happen by fooling with ports didn't seem to make it work. And I've seen it happen 3x now (separate game runs) where I'm pretty sure I never selected a docking port. It's possible I'd selected one or loaded a vehicle with one in a previous VAB session during the same game session and (internal, low level) state seems to be a big problem for the ksp2 engine atm. Ive also found that any vehicle I've saved after seeing these messages will have .. issues - haven't narrowed it down more specifically yet, but they seem more likely to suffer from weird loading state like all fuel lines not registering or all the lights being in a nice little grid 10 ft away from the vehicle.

Seeing this with the Medium Fairing and HECS.

MUAHAHAHA: I hadn't noticed (I haven't scrolled that far in a while). But I think it's because it's a ReadMe.htm (I was publishing it direct from MSVS). The Island runway would be a great place to start you off gently - i.e a little existing infrastructure - before getting you to throw everything into building somewhere else from scratch?

Some seriously interesting points by @BechMeister, @Scarecrow71, @Flush Foot, @Presto200. Scale up system and give Kerbin a hazy atmosphere, and you have a basis for them to be unaware of much beyond the Mun. I've just been flying around Kerbin in a jet and enjoying the scenery, but I had two annoying thoughts itching to ask themselves: how come all the kerbals live at ksc?; why would someone else come here? Well, hopefully you can practice your base building on Kerbal for the scenic sunrises and views and etc. But if the game added aircraft missions at the moment that would quickly irritate me because the flight controls are still wip (I hope). KSP2 has a very strong competitor to face off against: Kerbal Space Program. Seeing the game in it's current state, if I were working at Intercept my ass would clench every time they called an All Hands. There has to be some main-stream appeal to offset against KSP1 to keep investors gree erh happy. Base building is, uhm, cool, but cool and fun are not the same thing. Cool is watching someone win a tense Starcraft match during lockdown, cool is watching your guild first an epic boss after getting online too late to be part of the raid. I think a lot of people will find building bases "cool" if they don't have a potential to provide a reasonable amount of return on construction-investment. I think this is important to raise because fundamentally KSP1 was about visiting, while bases are about staying. I don't see Scott Manley or Matt Lowne switching their streams to KSP decorating tips. So who is base building targeting? I'm certainly not suggesting that they intentionally eliminate launch from KSP for anyone; but we already get options to turn off heating, unbreakable joints, science-me-out-the-wazoo mode. I think a difficulty setting that enables "assisted flight" is gonna be a critical must for the folks who want to build more than they want to fly. I realize they could use K2-D2 or whatever mods emerge in the future, and in my mind that's the kind of audience that probably isn't nearly as unwilling to use 3rd party tools etc (*cough*), but the developers typically have to give them some kind of tieback into the rest of the game: plenty of MMOs tanked themselves by going all in on a big push to add player housing to the game as opposed to building player housing into the game.

I couldn't agree more - the node UX is like kicking a dog when it's down, and you are also the dog, with a big factor of that being the way the entire UX is bad at tracking state - e.g you can "lock" the ap/pe tooltip windows but if something causes them to close such as adding too much dv, they remember their state despite not being visible, so when they do appear you have to click three times to lock them until you restart the game; if you go into gameplay settings, many of the options will show as OFF and ON being both selected because it restores the default state and then applies the current state and in the process remembers both things... I'm posting here mostly because this thread brought me here trying to find "cannot create maneuver node: no fuel" for a ship with fuel. It turns out that from a late change to my staging/early activation of an engine, KSP2 was convinced I had no delta-v left. I guess they don't expect refuelling or RCS-based adjustments? FIX: "+" an extra staging node for yourself, drag your engines into it, then make it the next/lowest stage, and voila, the game finally lets you create maneuver nodes again (assuming you have fuel).

A lot of folks will react to the 'a' word with instant cringe/fear - precisely because if you take away launch, there's not much left to do in KSP1, you've eliminated what the game originally really was (a rocket-flight simulator). That's the fear but sometimes you have to assess the rationale behind any given fear, and the sensible-fear-of-auto in KSP1 is because it takes purpose out of the product. Or does it? One of the responses so far was "you can just use the debug menu to put your vehicle into orbit". That's not the objection of someone with a valid argument against some kind of tech-tree based launch-assist capability. That sounds like my own inner objections to hearing others discuss auto features, which came from the way mechjeb seemed to be at fault for ruining my original ksp1 experience way back. I gradually became dependent on mechjeb for more and more of the steps I felt I had mastered and then I finished building my first duna base only to watch it thrown off the surface and eventually crash into the sun when the game unpacked it as I was landing my first kerbals. The tedium that then resulted wasn't mechjeb's fault as much as it felt like it at the time. Mechjeb had allowed me to find entertainment/fun in the parts of the game - parts I hadn't otherwise played during the earlier parts of my first play thru (base building, resupply, etc) - without having to invest all of the end-to-end time it would otherwise have taken. Instead I'd gotten my fill of flying launches, of trying to min/max rendezvous' and docking, so I had no interest in taking those roles back out of mj's hands. From reading posts and blogs and watching yt vids, I suspect that's the actual truth for many other post-mj kspers. Again, I'm not asking for a KSP2 built-in mechjeb. I'm advocating against approaching the matter in KSP2 as it if were KSP1, but advised by KSP1 without the literal fear it introduces in some. Frankly, I'm afraid that KSP2's base building is going to suck and die horribly, because there's no hook(*) for it, and all signs so far are that the engine won't be any better at keeping a billion ton mass stationary on the surface of a planet than KSP1 was. (*evidence) (*hook initially the hook for base building will be going further; but if bases are unreliable and unfun they'll be the sim-equivalent of that one gas station under the overpass with the rank sewage stink and the creepy pedo clerk that sometimes has the cheapest gas prices in town but bumps the price by $2/gallon the moment word gets out, so you do everything you can to avoid going there) (*evidence: jettison liquid fuel tank+engine during launch so that they impact and explode just as you cross the 2km range from pad, and you'll see the particles/sprites of the explosion cloud appear above you - if you get the timing perfect the icon for the debris will end up stuck above you until you restart the game; this existed in ksp1 you'd most commonly see it as little explosion sprites/puffs appearing ahead of the vehicle during launch. It's caused by an engine feature designed to deal with limitations of the way floating point math in cpus works that a lot of engineers mistakenly think is linear and only a problem at scale, but is a scale-of-intervals problem so, 3.1 - 0.7 + 0.1 != 3.1: https://gcc.godbolt.org/z/KqTjoEdxv and yeah that difference is small, and programmers account for this through a special number called 'epsilon' which is the smallest possible number a computer's float values can represent, but the 'extra' amount we gained here is actually 2x epsilon https://gcc.godbolt.org/z/PdP8h4hKf; and the ratio being a mere off-by-1 isn't because we're using small numbers, which programmers tend to be blissfully ignorant of that because the extra digits usually get trimmed away when the numbers are displayed. You can break all kinds of mathematically correct algorithms with inputs like 0.1 + 0.2: https://gcc.godbolt.org/z/YjPE8nsn7 . how is that evidence? it's the same factor that suddenly injects massive impulses of force into vehicles/bases that should be perfectly stationary and then nukes them with scale at an origin-centering boundary)

I wonder what inspired you to make such an epiderp? Amen - but you can't make concessions by starting from a position of refusal to change. And there are people in this community who will burn their KSP2 license if/when they add a built-in autopilot of any kind. Again, launch is going to be just the start of the journey, and I think it's entirely reasonable that there be the ability for some folks to enjoy the exploration and base building aspects without having to always demonstrate how unskilled they are at takeoffs. Anyone who argues that some kind of storylined-earnable partial-auto-pilot is going to make them less wanting to play or injures them more somehow than say sandbox mode, is basically *just* being a turnip.