0111narwhalz

For the time being, you can lock staging by pressing Alt+L. This will prevent the spacebar from doing anything so you don't accidentally advance the staging stack at all. It's not an exact solution, but it can prevent headaches all the same.

The issue is less that Jim would turn it down, and more that TTI would turn it down.

An advanced settings menu by any other name still smells just as sweet…

I'm seeing the merit in the "change constants" school. Commnet can be circumvented by setting the minimum control level to full, with intermediate setpoints for each of the control levels we see in KSP today. If you don't want commnet, you don't need to use commnet or any hacks like starting a save with a relay network. Thermodynamics can be circumvented by setting all heat generation/rejection coefficients to zero. Heat can come from multiple places, like engines, ambient atmosphere, ram heating, or machinery, so you should be able to dial each of those sources in individually. If you don't want to deal with heat, you don't need heat or "disabling" the thermodynamics system. It's assumed that, when a player starts tweaking settings like this, they are taking the balance of their game into their own hands. This means that it is no longer the devs' responsibility to balance the game: as soon as the player enters this "advanced settings" menu, all bets are off.

I can see the point of modifying constants rather than eviscerating mechanics… but I wonder if the better solution would be to modify costs rather than giving you some arbitrary budget? As in, set the part cost multiplier to zero and you can launch literally infinite vessels without changing your nominal budget. Zero-cost science nodes (perhaps they would be used for organization or something) could be unlocked automatically (why wouldn't you want them unlocked? maybe have an option to enable that behavior…), which would make setting science cost to zero unlock everything all at once. However, I still don't see a huge cost to dev time for allowing Commnet to be disabled. Even if it destroys progression… so does disabling the tech tree, and we don't have a problem with that.

Speaking for myself… Clicking a few times to do something that should be a simple radio button to begin with? This sounds like a hack to me. Just include an option to start off in this fully-upgraded, fully-unlocked state. Maybe even label it "sandbox."

The engine died, sputtering. Jeb swore under his breath, reaching for the translation controls. He glared at the altimeter as it counted down alarmingly quickly, the rate needle wavering as it crept towards zero. "Smooth landing, Jeb," Gene's voice came through the speaker, an echo lightlagged to absurdity. Jeb cackled, one hand still on the translation stick as he keyed the transmit button. "Smooth as silk. See you soon." Jeb's voice was overlaid with alarms and the mad enthusiasm unique to kerbal pilots. Gene sighed and pushed himself back from the desk in his chair. "You're sure there's no chance he survived?" Wernher shook his head. "Our models show a full breakup at that impact velocity, and the crater ejecta analysis from DRESat agrees. No debris larger than thirty centimeters. No disturbance since the impact, either." Gene turned to Wernher. "At least it was quick. Best get the service prepared, then." No matter how many times it had happened, in the space program and before, it never seemed to get easier. The mood in the astronaut complex' cafeteria was somber. Close to a hundred kerbs in their dress whites stood, shoulder to shoulder. At the end of the room, on a table draped with a blue cloth, lay a helmet. Its faceplate was painted with a likeness of Jeb's face, the near-opaque visor raised. "…May the kraken spare his soul." Walt reached forward and flicked the visor down, the crinkle of his hazmat suit the only sound after the snap of the visor. Silence reigned in the cafeteria for almost fifteen seconds before the door at the back flew open, bashed by a cart heavily-laden with snacks. A kerbal hung from the handle at its back as it coasted to a halt in the center of the room. Plastered across the kerb's face was an unmistakable grin. "I brought the snacks, what'd I miss?"

At what point did we slew to failure handling? Unexpected exceptions arising from a disabled feature are, I believe, a symptom of a kraken visitation. Turning something off should make it maximally predictable. Encapsulation can and should make definitions of all interactions between systems accessible. I'm curious as to which features you cannot stub out. You can replace Commnet connectivity checks with "yes it's connected." You can replace the thermodynamics with "yes everything is at 350K all the time." You can even replace aerodynamics with "no there's no aerodynamic force being applied." At what point does disabling these features cause unexpected results?

If it's done right, shouldn't it remove dimensions? By my intuition it should transform testing from O(k^n) to O(n), because rather than testing every combination of conditions between all of your modules, you test one condition for each module. (Integration testing is still important, of course, but that shouldn't buck O(n) into O(k^n), right?) Basically I feel like turning modules off should happen in regular testing anyway, so that should not be disruptive in production.

I admit, while I read this thread I was confused by your position. At one point I considered deploying the "doing something for 30 years does not preclude doing something wrong for 30 years" line. I'm glad I didn't. I believe I understand now. You work in a very conservative field—and it's right to be conservative! Failure is expensive. Lives are at stake. Of course stability is at a premium. Miscellaneous Boeing snafus aside, aerospace is the same way. But—and I think this is a critical distinction—KSP (and KSP 2) are video games about aerospace. And video games demand a different design philosophy. Every resource I've looked at in my three years or so (ha) since learning to program has described a concept known as "encapsulation." Encapsulation is used to ensure that you always know the ways in which the different parts of your project interact. In your words, it is a way to "silo away" parts of your project. And everywhere I've seen it, it has been described as a way to improve the ability of your program to be developed and maintained. Encapsulation does this by allowing you to replace, say, Commnet checks to determine whether your vessel can be controlled with a function that just returns "true." This now lets you test other systems that may interact with Commnet without considering what Commnet would have to say about it. Your testing can now be more scientific because you can limit your independent variables to the absolute minimum and test each feature in relative isolation. This also applies for development: You needn't wait for the implementation of plasma sheathing to develop relay functionality, because although these are both Commnet and should interact during real gameplay, each of them still means something in isolation. This also has ripples for modding. If you wanted to write a mod to supplant Commnet, it could be very difficult to dig through a tightly-integrated system, commandeering every individual function—and what if you miss one? However, a properly-encapsulated Commnet would be but a step removed from a drop-in module. All functionality is located in one place, and can be replaced easily. It even makes API documentation more sensible. So, in light of encapsulation being apparently accepted as best practice, and the benefits it brings, it's plausible that it is in use in the development of KSP 2. And, if replacement with stubs is present in the kind of testing suite encapsulation permits, it's plausible that it is in the testing suite applied to KSP 2. Given these, I conclude that it is plausible that adding an option to disable Commnet, or a feature like Commnet, is as easy as exposing the "stub out" functionality of the testing suite to an options menu—and doing so will not impact stability.

Eh, fair enough. If it's too early it's too early. Well, if a resource pack or a category pack are needed, the Ailevérse team will be ready to go.

Oh, for sure—I'm not suggesting that we immediately start creating these mods. There's a large chance that we won't need all of these features, or maybe even any of them—but it'd be best to not trip over one another while implementing the ones it turns out we will need.

The definition the Ailevérse team has been working on is basically "functionality which a lot of mods need, and which would otherwise be developed and redeveloped." This project is primarily about setting standards early on to avoid problems I observed over the course of my KSP experience. Clickthrough blocking is a huge quality of life feature, and I would say that it does indeed belong on this list. Toolbar Controller is, as I understand it, a utility to use either the stock or Blizzy's toolbar, and so its necessity is contingent upon the existence of both a stock and modded toolbar. This early on I expect one or the other. Blizzy's toolbar would belong here as well, since mods with GUIs will want to make themselves accessible to the screen without the old hardcoded keyboard shortcuts, and it'd be best if they agreed upon one way of doing this. I'm a bit behind and sideways on the news. If that is indeed true, and its features are robust and extensive, then so be it—less work for the one who would have signed up. It should be clarified that all of these suggestions assume that stock KSP2 won't have the relevant features we've enjoyed in the mature KSP1 modding community. It should also be clarified that signing up in no way binds an author to a commitment. It is more like calling the ball before half your team rushes for it. If you sign up, and then discover that you do not want to or cannot contribute, there should be no shame in pulling out and allowing another author to take the lead.

With KSP2 on the horizon, it's time to start thinking about how to make modding excellent from the beginning. Star Theory won't be able to get everything right from day one—that's just programming—so it falls on us, the community. Duplication of effort is silly and causes problems later down the line. For this reason I propose we coordinate the development of core dependency mods (coredeps). Below are some of my suggestions for coredeps which can establish long-term standards from the get-go: • A general resource library similar to the Community Resource Pack. Never again should we face the anarchy which preceded the CRP. LiquidHydrogen competing with LH2, FSCoolant versus B9CompressedAir versus IntakeAtmosphere versus IntakeAtm… It's a mess so easily avoided, but we need to take the initiative. The earlier the burn the less the ΔV, yes? • A part category base similar to the Community Category Kit. Standardized ideas of where parts belong improve the user experience massively. • ModuleManager. MM forms the foundation of essentially every part-affecting plugin. The health of the future KSP2 modding community is contingent upon the ability of mods to, well, modify—both the game and one another. Masterpieces like Tweakscale could not practically exist without MM. • A part switcher. Today we have the Firespitter one, the B9 one, Configurable Containers from Allista, and the stock one. There's a high probability that KSP2 will implement this feature, given that KSP1 already has, but we still need to account for the possibility. A standardized part switcher will streamline a lot of model, config, and compatibility work. Furthermore, a consortium of coredep maintainers and potential KSP2 modders would be useful in coordinating the development path taken by such dependencies, especially concerning the CRP- and CCK-like coredeps. If sufficient interest is demonstrated, a Discord server could be set up to facilitate such coordination. The Ailevérse team—led by myself, @TotallyNotHuman, and @Benjamin Kerman—has agreed to spearhead the development of the resource and category libraries, since our planned suite of science-fiction mods would make heavy use of such libraries. If you would like to propose any coredeps for inclusion into the above category, or would like to commit to the effort itself (which would be greatly appreciated!), feel free to reply below. The potluck so far: • Resource pack — the Ailevérse Team • Categories — the Ailevérse Team

Having forgotten it, Microsoft begins developing it again. The power to make arbitrary objects superconductive at will.