kfsone

"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.

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.

I've spent literally the last week working to attach a large Mun base to a ground anchor so it I don't have to turn cheats on to spawn it without it flipping over / crashing itself into the ground. Now, the GARNET reactor in the base overheats and shuts down every time I leave physics range of the base and come back. The thing is, the reactor isn't hot - it hasn't been used in a while, it should actually be healthy, and I don't see anything in the part's SFS data that should cause this. Is there some way I can fix this? The base has a massive amount of heat rejection and the reactor itself has a heck-ton It occurred to me that perhaps the problem is that I *haven't* used the base in a while, but that's because I've had to spend an entire week fighting the game's extreme desire to launch this base into orbit or waggle all the parts until they explode (see the huge number of manually added struts). Side note: Building a base with a large footprint near a grand-slam experiment is a fantastic way to quickly get massive amounts of science; regular 1e9-1e11 impacts make for lots of seismology data, as long as you remember to turn off collision damage before you click Fly. If I edit the SFS file and change the CoreIntegrity to 100 and state to 0, then it comes back to a working state but immediately shuts down and damages itself on loading. PART { name = reactor-125 cid = 4281215308 uid = 1606797284 mid = 3112283054 persistentId = 998920866 launchID = 104 parent = 149 position = -14.636277198791504,3.2554168701171875,42.443935394287109 rotation = 0.00949838944,0.124046631,-0.00670795003,0.992208302 mirror = 1,1,1 symMethod = Mirror istg = 0 resPri = 0 dstg = 0 sqor = -1 sepI = 1 sidx = -1 attm = 0 sameVesselCollision = False srfN = , -1 attN = top, 156 attN = bottom, 149 mass = 1.06700003 shielded = False temp = 257.04494791662256 tempExt = 255.83656592192247 tempExtUnexp = 200 staticPressureAtm = 0 expt = 0.5 state = 0 PreFailState = 0 attached = True autostrutMode = Grandparent rigidAttachment = True flag = rTrf = reactor-125 modCost = 0 modMass = 0 moduleVariantName = moduleCargoStackableQuantity = 1 EVENTS { } ACTIONS { ToggleSameVesselInteraction { actionGroup = None wasActiveBeforePartWasAdjusted = False } SetSameVesselInteraction { actionGroup = None wasActiveBeforePartWasAdjusted = False } RemoveSameVesselInteraction { actionGroup = None wasActiveBeforePartWasAdjusted = False } AutostrutOff { actionGroup = None wasActiveBeforePartWasAdjusted = False } AutostrutRoot { actionGroup = None wasActiveBeforePartWasAdjusted = False } AutostrutHeaviest { actionGroup = None wasActiveBeforePartWasAdjusted = False } AutostrutGrandparent { actionGroup = None wasActiveBeforePartWasAdjusted = False } ResourcesEnableFlow { actionGroup = None wasActiveBeforePartWasAdjusted = False } ResourcesDisableFlow { actionGroup = None wasActiveBeforePartWasAdjusted = False } } PARTDATA { } MODULE { name = ModuleUpdateOverride isEnabled = True stagingEnabled = True EVENTS { } ACTIONS { } UPGRADESAPPLIED { } } MODULE { name = FissionReactor isEnabled = True UIIcon = 1 UIName = MX-1 'GARNET' Fission Reactor CurrentSafetyOverride = 1300 CurrentPowerPercent = 25 AvailablePower = 0 TimewarpShutdown = False TimewarpShutdownFactor = 5 CoreIntegrity = 0 FirstLoad = False EfficiencyBonus = 1 IsActivated = False stagingEnabled = True lastUpdateTime = 139357268.04754806 EVENTS { } ACTIONS { TogglePanelAction { actionGroup = None wasActiveBeforePartWasAdjusted = False } StopResourceConverterAction { actionGroup = None wasActiveBeforePartWasAdjusted = False } StartResourceConverterAction { actionGroup = None wasActiveBeforePartWasAdjusted = False } ToggleResourceConverterAction { actionGroup = None wasActiveBeforePartWasAdjusted = False } } UPGRADESAPPLIED { } } MODULE { name = ModuleCoreHeatNoCatchup isEnabled = True CoreTempGoalAdjustment = 0 CoreThermalEnergy = 257014.13069399877 stagingEnabled = True lastUpdateTime = 139357268.04754806 EVENTS { } ACTIONS { } UPGRADESAPPLIED { } } MODULE { name = FissionGenerator isEnabled = True CurrentGeneration = 0 CurrentHeatUsed = 0 Setting = 0 stagingEnabled = True EVENTS { } ACTIONS { } UPGRADESAPPLIED { } } MODULE { name = RadioactiveStorageContainer isEnabled = True stagingEnabled = True EVENTS { } ACTIONS { } UPGRADESAPPLIED { } } MODULE { name = ModuleB9PartSwitch isEnabled = True stagingEnabled = True moduleID = meshSwitch currentSubtype = Inline EVENTS { } ACTIONS { } UPGRADESAPPLIED { } } MODULE { name = TweakScale isEnabled = True active = True available = True currentScale = 3.75 defaultScale = 3.75 defaultTransformScale = (0, 0, 0) DryCost = 44376 OriginalCrewCapacity = 0 stagingEnabled = True EVENTS { } ACTIONS { } UPGRADESAPPLIED { } } MODULE { name = ModuleKaboom isEnabled = True delay = 0 isGlued = False stagingEnabled = True EVENTS { } ACTIONS { KaboomAction { actionGroup = None wasActiveBeforePartWasAdjusted = False } } UPGRADESAPPLIED { } } MODULE { name = ModuleB9PartInfo isEnabled = False stagingEnabled = True EVENTS { } ACTIONS { } UPGRADESAPPLIED { } } MODULE { name = AttachedOnEditor isEnabled = True active = True originalPos = (0, 27.520853, -4.25419617) originalRotation = (0.707106829, 0, 0, -0.707106829) moduleVersion = 6 stagingEnabled = True originalAttachNodePos = (0.0, 1.3, 0.0) originalAttachNodeSize = 1 originalAttachNodeOrientation = (0.0, 1.0, 0.0) originalAttachNodeOffset = (0.0, 0.0, 0.0) originalAttachNodePos = (0.0, -1.0, 0.0) originalAttachNodeSize = 1 originalAttachNodeOrientation = (0.0, -1.0, 0.0) originalAttachNodeOffset = (0.0, 0.0, 0.0) EVENTS { } ACTIONS { } UPGRADESAPPLIED { } } MODULE { name = ModuleCargoPart isEnabled = True beingAttached = False beingSettled = False reinitResourcesOnStoreInVessel = False stagingEnabled = True EVENTS { } ACTIONS { } UPGRADESAPPLIED { } } MODULE { name = KSPPartVolumeModule isEnabled = True stagingEnabled = True EVENTS { } ACTIONS { } UPGRADESAPPLIED { } } RESOURCE { name = ElectricCharge amount = 200 maxAmount = 200 flowState = True isTweakable = True hideFlow = False isVisible = True flowMode = Both } RESOURCE { name = DepletedFuel amount = 0 maxAmount = 65 flowState = True isTweakable = True hideFlow = False isVisible = True flowMode = Both } RESOURCE { name = EnrichedUranium amount = 64.093507812807914 maxAmount = 65 flowState = True isTweakable = True hideFlow = False isVisible = True flowMode = Both } } Entire SFS file is here If I don't turn the cheats on, the base self-destroys on unpack incrementally. By "incrementally", I mean it gets worse with every reload until I restart the game. 11th gen i7, 32GB of ram, nvme drive, rtx 2080, mods: [x] Science! Continued (xScienceContinued 6.0.0.10) Astrogator (Astrogator v0.10.3) AT Utils (AT-Utils v1.10.1) B9 Part Switch (B9PartSwitch v2.20.0) Breaking Ground (BreakingGround-DLC 1.7.1) ClickThrough Blocker (ClickThroughBlocker 1:0.1.10.17) Community Category Kit (CommunityCategoryKit v112.0.1) Community Resource Pack (CommunityResourcePack v112.0.1) Community Tech Tree (CommunityTechTree 1:3.4.4) Configurable Containers (ConfigurableContainers 2.6.2.1) Contract Configurator (ContractConfigurator 2.1.3) Contract Pack: Field Research (ContractConfigurator-FieldResearch 1.2.2) Contract Pack: Research Advancement Division (ResearchAdvancementDivision 1.2.1) Deployable Engines Plugin (DeployableEngines 1.3.1) Distant Object Enhancement /L (DistantObject v2.1.1.8) Distant Object Enhancement /L default config (DistantObject-default v2.1.1.8) Dynamic Battery Storage (DynamicBatteryStorage 2:2.2.5.0) Editor Extensions Redux (EditorExtensionsRedux 3.4.3.5) Engine Lighting Relit (EngineLightRelit 1.6.3.4) EVA Enhancements Continued (EVAEnhancementsContinued 0.1.15.3) EVA Refueling (EVARefueling 0.1) Extraplanetary Launchpads (ExtraPlanetaryLaunchpads 6.99.3.0) ForScience! (ForScienceUpdated 1.6.0) Fuel Tank Expansion Rebuilt (MunarIndustriesFTX 0.9.7.1) Global Construction (GroundConstruction 2.7.1) Global Construction Core (GroundConstruction-Core 2.7.1) Harmony 2 (Harmony2 2.2.1.0) Hide Empty Tech Tree Nodes (HideEmptyTechNodes 1.3.2) HyperEdit (HyperEdit 1.5.8.0) Interstellar Fuel Switch Core (InterstellarFuelSwitch-Core 3.29.4) Kaboom! (Kaboom 1.4.0.1) Kerbal Attachment System (KAS 1.11) Kerbal Dust Experiment (KDEX v2.0.2) Kerbal Engineer Redux (KerbalEngineerRedux 1.1.9.0) Kerbal Improved Save System (KerbalImprovedSaveSystem v2.4.2) Kerbal Inventory System (KIS 1.29) Kerbal Joint Reinforcement Continued (KerbalJointReinforcementContinued v3.6.1) Kerbal Planetary Base Systems (KerbalPlanetaryBaseSystems v1.6.16) KSP Community Fixes (KSPCommunityFixes 1.19.1) KSP Recall (KSP-Recall v0.3.0.1) KSP_PartVolume (KSP-PartVolume 0.0.3.3) Making History (MakingHistory-DLC 1.12.1) MechJeb 2 (MechJeb2 2.14.1.0) MechJeb and Engineer for all! (MechJebForAll 1.3.0.7) Mission Controller 2 (MissionController2 2:3.2.0.0) Module Manager (ModuleManager 4.2.2) Near Future Construction (NearFutureConstruction 1.3.1) Near Future Electrical (NearFutureElectrical 1.2.3) Near Future Electrical Core (NearFutureElectrical-Core 1.2.3) Near Future Exploration (NearFutureExploration 1.1.2) Near Future IVA Props (NearFutureProps 1:0.7.1) Near Future Launch Vehicles (NearFutureLaunchVehicles 2.2.0) Near Future Propulsion (NearFuturePropulsion 1.3.5) Near Future Solar (NearFutureSolar 1.3.2) Near Future Solar Core (NearFutureSolar-Core 1.3.2) Near Future Spacecraft (NearFutureSpacecraft 1.4.3) Part Wizard Continued (PartWizardContinued 1.3.9) Patch Manager (PatchManager 0.0.17.4) Physics Range Extender (PhysicsRangeExtender 1.21.0) PlanetShine (PlanetShine 0.2.6.6) PlanetShine - Default configuration (PlanetShine-Config-Default 0.2.6.6) Procedural Fairings (ProceduralFairings 1:v6.2.1) Procedural Parts (ProceduralParts v2.4.1) RCS Build Aid (RCSBuildAid v1.0.6) ReStock (ReStock 1.4.3) ReStock+ (ReStockPlus 1.4.3) Rover Science Continued (RoverScienceCont 2.3.5.6) Sandcastle (Sandcastle v1.0.9) SCANsat (SCANsat v20.4) ScienceAlert ReAlerted (ScienceAlert 1.9.10) SimpleFuelSwitch (SimpleFuelSwitch 1.4.2) Smart Parts (SmartParts 1.9.16.2) SpaceTux Library (SpaceTuxLibrary 0.0.8.4) StageRecovery (StageRecovery 1.9.5.4) Stockalike Station Parts Expansion Redux (StationPartsExpansionRedux 2.0.10) Stockalike Station Parts Expansion Redux - Internal Spaces (StationPartsExpansionRedux-IVAs 2.0.10) Toolbar (Toolbar 1:1.8.0.8) Toolbar Controller (ToolbarController 1:0.1.9.8) Transfer Window Planner (TransferWindowPlanner v1.8.0.0) TweakScale - Rescale Everything! (TweakScale v2.4.6.16) TweakScale Redistributable (TweakScale-Redist v2.4.6.16) Utility Weight (UtilityWeight 2.0.0) Zero MiniAVC (ZeroMiniAVC 1:1.1.2.4) I'd *just* installed physics range extender and have it disabled, disabling/uninstalling planet shine didn't have any appreciable impact on performance.

We may have different values for "optimal" and "viable". KSP1 has a pretty hefty cognitive burden on maintaining a non-trivial base or station that has nothing to do with astrophysics and everything to do with how ksp implements its physics and the recursive sunk-cost fallacies that are built into vehicle packing/unpacking (tl;dr: because unpacking a vehicle is slow, they're sloppy about restoring its physics and you end up with impulses instead of moments which jump into the sack with some very silly rounding errors to rip vehicles/stations/bases apart. The KSP1 sfs loader seems to be about 450x slower than it needs to be and well over 2000 times slower than a naive binary approach using something like protocol buffers to handle the format) Maybe it's a mods thing, but I've also never had access to a sufficiently staffed science lab operating before reaching a point where I'm down to the completionist stage So not only the optimal way but - for me - also the only

I guess my thinking is that KSP1 proved - to a degree - that you can make significant segments of that structure optional to cater to multiple "play" goals. Here for the physics and making SpaceX-mockup youtube videos? -> Sandbox. Here for interstellar base-building and couldn't give a rats about re-playing the KSP1-portion of the game? Select-a-Science(*) mode; and ... (* Select-a-Science: Show you the science tree and literally let you uncheck what nodes are available/not, with an "all" toggle to one side; I'm not sure if this is just spit-ball padding for the larger point or an actual idea)

and I'm not suggesting this doesn't need more than a split second of thought - and let me also carefully reiterate that I'm not trying to suggest a one-size-fits-all force mode of gameplay. I can understand why KSP1 was a free-for-all, but most gamers don't actually like it when they get unfettered freedom or when grind is reduced to a single easy to move progress bar My point wasn't to design a constrictive system, tho, simply one with reasonable feedback. Trying different engines defaults to driving engine research. A lot of folks ended up running out of money when they played KSP1 the way you'd think it's supposed to be played, and if they stuck with the game they became risk-averse, and that turns part selection into a crude min-max with extreme penalties, so they'd end with a very limited vocabulary of parts they would use for specific functions (cf various youtubers saying "I made this video because people commented I only ever use the ..."). Unlock nodes would be a first step in making it possible to move the currency around, but there should multi-science should probably both be an option and some solid ways to move your points or incoming to other branches. Very interesting. Especially if they're wanting us to put time into building bases, I think a healthy long-tail of science needs to be there. I think players who are playing ksp2 will get gratification from seeing continued value from being able to keep earlier bases relevant. But in the spirit of sandbox, these nuances need to be opt-in: "Let them eat cake"

Yes, yes, yes: that kind of feed-back loop is what I'd expected as "science", rather like in games like EverQuest 1 where using a skill is how you get experience in it ("You have become better at Sense Heading! (2)") My playthrus tend to consist of: Orbit, Mun, Minmus, otw to Eve and done. I've added a few base-building / construction mods in the hopes that this time I might set up a station on Gilly and land/launch from Eve, and then maybe reach Duna, but I suspect I'll probably mothball the game again before then because I'm starting to get that sense of fighting the game's aspirations over its capabilities. The fact I'm even considering editing the .sfs file to recover the crane I worked so hard to put on the Mun is a bad sign

Disclaimer: I do think KSP2 has to give people a dashboard for their gameplay experience. The KSP1 science tree was a compromise between sandbox and hardcore simulation that was satisfying the way a lethal overdose must be. Typically, skill/research/science trees in games have two very important roles that were entirely absent in KSP1: 1- Theme parking: Do your thing to earn more of your thing. D&D lets you choose where you spend your skill points because if you want to play a rogue, you don't want the game foisting str and wis on you; New World turned off a big chunk of players by downgrading the drop chances of player-appropriate gear to encourage trade; if a player wants to build orbital bases, how did their last science spend force them to take 7 new wing-surfaces? 2- Guide rails: Part of the beauty of KSP1 was abusing parts in constructive ways. Those 7 new wing-surfaces might actually have a decorative purpose for building your orbital, but it's pretty unlikely, and KSP1 exasperated that issue by eventually throwing so much stuff into each science gain that you would never bother to engage with a lot of it (I *still* occasionally discover new stock parts or their roles, after all this time). Making me pay 1500 science for 7 wings I don't want so I can pay 3000 for a landing gear I do want and a bunch of "crap" I don't care about ... feels like dealing with my bank. Total finger-in-the-air: I'd instead have "advancement" nodes with multiple unlock conditions and possibly no science, and which start with a minimal number of parts the way the root of the tree does, to encourage you to try. I mean, there's not much point in getting landing-gears until you have the ability to go somewhere to land: so surely you need to either have tried to land back home or done a fly-by behind another body before you start on landing stuff? (In this particular play configuration)

I've been working on a Mun base for a while now, and it's been a brutal learning experience, that I think I can boil down at this point to: I can't seem to stick things to the ground. I'd built a little mobile crane that could carry new extensions, line them up and dock them, but during landing my 3rd component, the instant the base & crane unpacked, the crane either exploded so hard that pieces of it left the kerbol system within a few minutes, or the crane simply landed on the sun. The base also occasionally had a tendency to fly up and meet me during landing, but not in a good way like you'd want. I removed all the auto-struts and that seemed to help. But now, every time I fly into range of the base or every time I exit timewarp, the base leaps up off the surface or begins making a hard turn. Until I turned on "Pause on unpack vehicle" and "unbreakable joints" this would destroy the base 1 time out of 3. So I did a small experiment and used some of the "anchor to ground" elements from KAS etc, and they seem to have the ability to stay put, but I've put a bunch of effort into this base at this point, and I'd like to know if there is some way that I can affix an existing base to the ground? I tried putting a stamp-o-tron or a K&K ground anchor with a docking port, but my base is big enough now that it can't get close enough to dock. Is there some way to affix an existing base to the surface it is sitting on? A part? A mod? An edit of the SFS file?

I disagree slightly - not stripping away time-sinks, but providing flexibility. Plenty of people just aren't going to give a dingo's kidney about bases, even in KSP2, and plenty of people are going to come to KSP2 just for the base building and are going to be going absolutely stir crazy that they can't just request part delivery and spend all their time putting their base together. (My wife is an MMO-housing addict and she keeps asking me questions about building bases in KSP2; 'Is it multiplayer? Can you fly the parts I need so I can focus on building my colony?') I don't think you can make a 1-size-fits-all general play mode for KSP2, not with rocket building, colony building and interstellar travel - it's too diverse. But if I've found one thing about KSP is that's every time I've come back to it after a few months/year hiatus, I totally get into some one particular thing. This time - for reasons in the OP - I've ended up spending weeks focused entirely on building this one mun base. I imagine - I hope - KSP2 won't just add breadth, but will invest KSP1-learnings to also give some depth to the different focus-channels/time-sinks so that the game is more than just a choice between "rockeet" and "get to the mun->build a base->fly to Alpha Kerbturai->victory" If the entire slog of building your first mun colony has the sole purpose of launching your first interstellar, if building the colony can't also be fun and rewarding in/of itself, then a lot of players might not bother engaging with the work needed to work on the second. Conversely: a lot of players aren't going to bother spending months or weeks building a mun base just to punch a ticket that lets them fly to another star?

This is really where I'm speaking to with the science stuff: we're aligned in thinking about the clicky science being a distraction from "rocketeering", but I think from a purely design perspective that when players are building bases they're going to need an investment stake: rocketeering means you're building bases for resupply, etc, so they've already got their stake and forcing them to prance about placing seismometers or triangulating theodolite measurements is going to kill their enjoyment. Building space-stations/bases, tho, if you're not playing rocketeer, and if you're not - oh god I hope not - wandering around in the base playing some kind of minecraft/space-engineers housing game, then you probably came to KSP2 base building because you wanted to play the SpaceX starship debarkee and there needs to be stuff that encourages you to waddle around with kerbals and feeds back into the other gameplay systems without crippling them for rocketeers.