kfsone

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.

Again, not talking about "magic me to orbit" - but I am choosing to be a little evocative in the hopes some will think about their own carte-blanche aversion to any kind of orbit assist. I used to work for an MMO called WWII Online, half-scale map of Europe with realistic guns/tanks/planes/yadda. When it launched, you could spawn at any friendly forward base alone the front line, and drive, ride, or walk, towards the nearest "enemy" town. The dream come true. Do you know how fun it is to talk 15km in a video game with birds tweeting in the distance, only to find an empty, poorly modelled village? Or to crawl thru ditches towards one for 2 hours only to have your screen go black inexplicably, because the bullet reaches you before the sound of the shot. Well, that's one of the reasons not many people have heard of the game (even tho it is *still* running, lol). One of the biggest cluster-fs in the game was finally realizing the melding of the naval aspect of the game and the land aspect: cargo ships. But, not wanting to break the spirit of the simulation, every troop and vehicle that the ship was going to carry had to be loaded onto the ship. That is: 1. Spawn the ship, 2. Convince people they want to ride a freighter to the battle happening _right now_ in Kaalmthout or Antwerp or somewhere, 3. Sail the ship into harbor and line it up against the dock, 4. Raise the crane and turn it out over the side of the ship, 5. Get a tank/atg/truck to drive in under the crane, 6. Lower the crane, find the hitching point, get the vehicle hitched, 7. Raise the crane, carefully, swing it over the hatch, 8. Gently lower the vehicle without damaging it and place it onto the cargo bay, 9. Unhitch the vehicle without dropping it, 10. Have the vehicle find the parking spot and "mount" the ship, 11. Repeat, 12. Sail a WWII freighter vessel across a half-scale English channel, while the players stay connected to their in-game troopers/vehicles, 13. Hope the fight remains at a coastal town you can reach during the *2 hours sailing time*, 14. Try not to get bombed/strafed/sunk by enemy air patrols who have a reasonably good sense of where freighters would be launching from, 15. Try to reach a piece of coastline sufficiently far away from the fight that you won't get shelled/bombed before you can unload, 16. The freighter didn't have a cargo ramp, so ... find a spot where you can use the crane to unload vehicles without dropping them into the water. Use the life boats to lower troopers down and hope you're not too far out... 17. Despawn, because f**k sailing back. 18. Never do this again after all the complaints you get from people who disco'd, sank, drowned, or who didn't get to the target until after it had been captured and the frontline moved away. It absolutely made sense that there be a player-investment in the loading of the vehicle, so that it wasn't just a magic firehose-for-one whereby if one player can get a boat into position X they could spawn an entire army on the enemy; but the vice-like grip of the auto-fear meant that there was no willingness by certain team members to even consider ideas where any part of that process wasn't entirely manual/humanized. My concept was for to add supply trucks/engineers who could execute sorties to the docked ship, the ship would operate its crane to take loads onboard, and then when it reached the opposite end it would be able to provide/deploy an amount of resources corresponding to the amount of effort that went into loading. Because on the rare occasion when people were insane enough to mount actual coastal assaults, almost invariably the outcome was that the reduction in number of combatants *at* the fight ended up killing the fight. You might be willing to spend 2.5 hours boarding a ship and sailing to 50km away from your planned destination, but will the enemy wait there or despawn and go someplace else? What I'm aspiring to here for KSP2 is that it be possible in some game modes to earn additional launch assistance so that you can *feel* you are moving your focus onto the next stage of gameplay. And yes, some people will hit launch and then timewarp. But what of it? How does that affect you? I dunno about you but when I watch Matt Lowne videos I'm always glad he doesn't show the whole thing in real time? I mean: tell me how much of *this* video you actually watch, and how much you think anyone else would watch?

"plan everything in advance" - is exactly my point. Perhaps, for you, KSP is a game of jenga, where you just keep repeating the same basic gameplay over and over but aiming for a taller tower. For the majority of players, that's called "grind". I'm not proposing a "skip to launch" feature, modders can provide that. Rather, I'm proposing some eventual lenience to allow players to earn their way to focusing less on the reach-kerbin-orbit steps of the game. As for the flip-side of your argument, if all KSP2 is supposed to be is a shinier version of KSP1, it'll never make it to release. Everything I've read suggests that KSP2 is supposed to be extending game play (adding bases, interstellar, etc) and very, very, very few of the potential audience that could fuel a long healthy life for this product will get that far if there is no sense of "progress", and all because some don't want an assisted-launch option.

The missions and storyline in KSP2 definitely give it a little something to latch on to as you work thru the early game, but once you've done Minmus that source of motivation dries up. Pre-release: got it, but I can't highlight the strengths of the missions/story up to that point if I don't observe the as-is is stony cold dead at that point. What I specifically want to point out are three major weaknesses I see recreated from KSP1 in KSP2 as it exists now: 1- Auto-fear: Resistance to adding rails for fear of "spoiling the sim", (e.g 'auto' things, docking pilots, etc), 2- Too flimsy of a tech tree, 3- Inherent reward for risk only, Auto-fear: Once you've returned from Minmus and are eyeing the next planet, there are two reasons you might fire up KSP and and launch a rocket. 1/ To start a journey; Duna, Eve maybe, Jool? 2/ For the sake of launching a rocket and experimenting. Rewind a second. "To start a journey"? Yep - you were with me, too. But that's not what the game is going to let you do. The game is going to make you go through all the same rookie slog involved in getting your vehicle to orbit. While that's not the worst thing, if KSP2 wants to be more than just a launch sim, it needs to break the vice-like grip of the fear of automation. Why do we allow you to start with a fully loaded vehicle, why don't we make you wait for tanking? Why doesn't the game ship with bad weather so you might have to wait until tuesday next week (real time) to launch your rocket? I'm not proposing that launch needs to be skippable, but by the time you're ready to start heading to Duna/Eve, you ought to be able to play passenger on your kerbin launches. In MMO terms, KSP2 forces you to start every level by walking back to Stormwind/Orgrimmar, doing kill-10-rat quests for all the vendors/random npcs, before finally working your way up to a single quest you will now be able to get 1-2 quests for the zone you now have to walk back to. If I'm in the mood for flying each and every one of my launches to assemble my manned trip to Jool, I can do that. Having an autopilot doesn't prevent me doing it, but it does reward me for my work so far by allowing me to spend more time on the next part of the gameplay. Hell, sometimes I want an auto-feature so I can just *watch* kerbal space program. Flimsy-Tree: One of the purposes of tech-trees is player-teaching. "Try this engine", "you've tried a solid engine, now try a liquid engine", "and here's a parachute". KSPs tech tree is one of the worst in the industry. Near random gluts of stuff, sometimes with no obvious relation. And the way they're mixed makes it real hard to forge your own path, and the jumps in sc-cost tends to lead people to completion-spend. Which means they never experiment with those science-spends. There need to be way more nodes, more layers and more options. Infact, maybe we, as players, don't need to see the tree at all. You could visualize various different vehicles and highlight the parts that scientists are currently "experimenting" with as a way of showing what's currently available to research. IMHO almost every single upgrade - except variants - should be individually selectable. But won't that require a lot more science? Yes, and that leads into the 3rd item What's the pay off? Excerpt from a 90s TV interview: Q. "But what do we get from going to space?" A. "Surviving in space challenges scientists and engineers in ways that our safe environment down here doesn.t It was NASA scientists that invented the microwave ovens and cellular telephones!" KSP struggles with a lack of things to do - other than fly rockets, which is going to be a game killer when you want people to build bases. But doing things *can* be inherent - KSP already relies on that fact heavily, it just doesn't leverage it. Watching stuff explode or crash is fun, but it's also punitive: you get nothing for it. KSP ought to reward failure to properly integrate it as part of gameplay. As long as parts of crashed vehicles are recoverable - and you could build around that - they could produce science, for instance. You should be able to get 1 science point from every single component in the game by launching a launch-clamp holding one and dropping it from > 100ft. "crash tolerance". Another point for burning one up in every atmosphere? How about some science for overheating and destroying engines? Blowing up a tank with a badly placed separatron? Look at this way: Player has two vehicles in orbit for their first attempt at docking. The game autosaves, and they begin docking, but they're not watching their mp and when they finally get an accidental roll under control they realize they're out of fuel and the two vehicles are going to crash at unsurvivable speed. Does the player: a) let the vessels crash, return to VAB and launch 2 more ships? b) hit esc and avoid the annoying mistake? Why would anyone select a? Buuuuut... If science "experiences" paid off, well, now that might be some justification to roll with the occasional punch.

I went with a bug report because it's not on the known issue list, and there are plenty of ways to handle it in Unity from the trivial aspect ratio list to c&p camera scripts from stack overflow. If it is that they only added 16:9, that's its own set of problems: assumptions get made and backing out of the hole becomes as more work than digging the hole was. Ignoring that I've seen UWs in their dev diaries and interviews etc, nobody ran the game on a laptop/tablet? -Oliver

No options for the native resolution on an Ultrawide monitor, and the default fullscreen results in stretching 1920 -> 2560 which looks awful. Also, the default corner rounding in imgui doesn't do this any favors, the defaults have been unfortunate for a long time: Rendering optimization: store rounded corners in texture to use 1 quad per corner · Issue #1962 · ocornut/imgui (github.com) and ultimately the solution is to roll your own or put your own texture in the atlas.