DStaal

It's also worth noting on CKAN that it's not perfect either: it occasionally causes it's own set of install issues, doesn't have all mods, and (especially for older versions of KSP) doesn't always run on all the same platforms as KSP. (And on some looks fairly out-of-place even when it does run.)

Thanks. It just sounded like it could be part of a reference-counting GC system, which are low-overhead but a bit more manual. I've worked with them in the past - a decent compromise in many cases.

Does that immediately free it, or does it reduce some retention counter? (Honest question - but the latter could be part of a garbage collection system.)

As much as I agree with that sentiment - should MechJeb care? It seems out of scope, and there is a mod for checking for DLL loading errors:

It's looking more like it's going to be in MADLAD - but either way I'm against this. Additional complexity, and if you know what you're doing to be able to move mods around you should know enough to either ignore this warning or to be able to edit/remove the .version files. On the specs: Something in the back of my mind is trying to say something about dependencies you don't control, but I'm not exactly sure what it is. Otherwise looks good.

People installing in wrong location and then asking for help when the mod doesn't work (or just saying 'it doesn't work') becomes the mod author's problem - at least in that other more useful feedback is obscured, even if you discount that mod authors typically try to help people get their mods working. This does sound like a great idea. I'm a bit hesitant on adding yet another set of mini-dlls and like the idea of adding a config line to the .version file - but either way it's a good idea.

Yes: It's how (non-physical) time warp works - you skip ahead a certain period, and calculate the new position. For that matter, even at normal speed there's essentially a timeskip between frames, of the duration of each frame. (I'm of the opinion that you could likely do a 3-body simulation on ships in the Rusk/Rask system, keeping the planets themselves on rails, and have it work well enough for the game - but that's an opinion and I may be wrong.)

I believe in that in theory US copyright law allows you to make copies of anything you own a copy of for your own personal use. (Provided you don't break any other laws of course - one of the issues with the DMCA is/was that it provides companies with a way around that: It made removing copy protection illegal, even if the removal was for legal purposes.) As far as I understand it, if your country is a signatory of the Berne treaty, they've implemented or changed their laws to generally conform to the terms of the treaty. Exact details will very from country to country of course, but the general scope should be quite similar on anything the treaty covered. (There are of course things the treaty didn't cover.)

The best example of ballooning bonus costs is Train Simulator 2020 - $6402.46 with all DLCs. (Of course they are all optional.) Most games I wait for a sale - 50% off is typically not hard to find, and you can often get much better yet. If KSP2 is anything close to KSP1 for me, even at $60 it's fairly cheap on the dollars-per-hour-played.

It would be interesting. Hard to talk about at the moment since they haven't shown any probe parts at all, but I agree a bit of love here would be nice.

Ok, so now they're out of sync with the rest of the world as they've reverted, while the rest of the world has kept playing. How are you planning on catching up? If they fly up to dock to a station, and in the interim someone else has docked to that same port in the future, what happens? Or is 'revert' simply a synonym for 'delete', and you have to do the new launch at the new time?

The only workaround would be to have them have seats while deflated.

Works for a single player - but what if there's a dozen players in the world? Can any one of them revert the entire world at any time?

Not all logic can be parallelized effectively. KSP tends towards some that can't, because of what it's doing. That's not an issue with the programming necissarially - it's limits of design, logic, and computing theory.

Same for me, though I assembled via KIS on the launchpad. Also, the bumpers appear to attach backwards, and I see the issue Raptor22 had with attaching the wheels - dropping them on the ground first avoids it. (They appear to initialize in the deployed state, and then revert to the stowed.)

This isn't about naming a particular station - it's about naming the interface/virtual building that's used to design and build *all* stations in the game.

How can you add the lack of something that's not there in the first place?

I typically use a part from Probes Plus - but it's exactly like a Narrow Band Scanner except for the model. Occasionally I'll use a Magnometer to scan for ore - but that's just because I'm typically carrying it anyway for the experiment, and if all I care about is ore it'll do the job. I do run into the issue where SCANsat can't handle all the resources my game's trying to track, so anything that could help that issue would be welcomed. Arguably the Narrow Band Scanner is to powerful in that it can scan for everything - but with the alternative being either sending up huge scanner sats with lots of nearly-identical scanner parts (or lots of nearly identical small sats) and continuing limitations on the number of distinct resources that can be shown, I'm ok with the over-poweredness.

I'm sure they've solved it to their satisfaction. But I agree it's a dead issue until then - the possible issues with various approaches have been talked to death. Every approach has issues, the question will be what issues Star Theory thought needed to be avoided and what they could live with.

You're talking about mathematically - that the equations do not have a finite solution. That doesn't mean programmatically they can't have something in place. (Even the fact that it doesn't scale isn't really an issue: It's just the two planets and your ship, it doesn't *need* to scale beyond that.) Several options of what that could be have been theorized on this board: They could be doing full N-Body inside that SOI, they could have mini-SOI's for each planet within an SOI for the binary pair, they could have the planets on rails and do 3-body gravity for any ship in that SOI, etc. Lots of ways to approach it depending on what you want, the level of performance, and the design decisions. I don't know the math well enough - there may be some distance/mass ratio between the planets which makes a particular set of equations a reasonable solution (for that small set) and they can tune the system to just those ratios. You do not need a generic case - just a case in this situation. Until they release more details, we can't say what they've done, because there *are* multiple ways to approach the problem.

Honestly, I think that's part of the problem with trying to define a career mode for KSP: You have to define the goals. Basically every time I start a save I define a different set of goals for myself. The career contracts are just stepping stones along the way to that. (Admittedly, I typically play Science mode, because I find the contracts annoying mostly - but I have played full career a few times.) So any career/progression mode in KSP2 needs to balance pushing the player with letting the player define their own goals. If you define the goals to rigidly in the game, then there becomes an optimal route through the game to reach them which hurts the replayability/exploration aspects of the game. I'm not entirely sure you want to define them at all - you may want to just have the player define them and have contracts to push you further out and offer a few more constraints. There's this talk about making sure there's reasons to colonize every planet - do you actually *want* to force every player to colonize every planet every playthrough? Or if someone wants to play a game where they step from Kerbin to Minmus to Jool to Rask, should that be fine? And sure you can timewarp to fill your tanks even at low concentrations - but then you'll miss that transfer window, which means you may need to figure out how to hit your next stop... (And they may be playing with a LS mod - or LS could be in the game - or they may then run out of something else...) To me, KSP is about offering choices, not forcing them. You shouldn't intend to penalize players who don't do something - you should intend to reward players to do do something.

I'd go with option 2 - It'll will consolidate all the output from those 12 mods, as well as any other mods that you have that have .version files that may not ship MiniAVC. Option 1 won't work - it would just disable version checking on those 11 mods. Option 3 is likely fine - there's a very minor hit during loading for each .dll, but it will be very minor. If you install this mod you can remove all 12 of those to eliminate any impact they might have, but you'll probably not notice either way.

They've said they have some custom solution for that system. What it is has currently not been disclosed.

As a more general answer: They've said that the Kerbol system will stay the same (minus some graphical/engine lifts), but that there will be multiple new star systems with planets. We've seen I believe a gas giant, Rask/Rusk (the world pair), and whatever it was they landed on at the end of the trailer.

Probably: When I'm sure it'll be released on my platform. (Which likely means when it *is* released for Mac.)