DStaal

Interesting analysis. I'm not sure how the devs will approach this, but I could see the current config file format staying fairly static (or at least being left as something similar) - unless you're heavily modded, it's not going to add huge amounts of time. (Though parallelization would be a good idea.) Module Manager already tries to do the caching to an extent, and it shows the main issue with caching for this: You still need to check for changes to see if the cache is still valid. Personally if I were on the dev team I'd be looking at something like SQLite for the main save file/craft file format. It's not much harder to work with manually than a text file, but it'll be far more robust in use. But that's just a personal thought.

Best to ask this type of question directly in the mod in question's thread (which would in this case be KIS). However: You'll have to pull the parts out directly into the world. You can't directly carry the part in the Kerbal's inventory if it's to large (which is different than to heavy). You'll likely have to place pick it back up, after moving your Kerbal(s). Note that your Kerbals can pass it between them, if they're close enough. (That is: they extend the range you can place things, assuming their ranges overlap.) 4 tonnes is to heavy for one Kerbal to handle, so you're going to need multiple Kerbals. If you final placement location is close enough to the storage unit you might be able to get around it - I've had luck with one Kerbal getting something out of inventory and placing it where it's needed even if it's to heavy - but only if *both* the storage unit and it's final location are within range of the Kerbal at the start. One other note with large parts: Note that a Kerbal's grab range it calculated to the center of the part. For very large parts, it's possible that a Kerbal cannot get within range to pick a part up at all.

A quick question - Is this mod compatible with CommNetManager (and therefore with ELSD Jump Beacons Revived)? (My testing would indicate no - but I run a *lot* of mods, and I'm not sure I didn't break things some other way.)

We have no details on how multiplayer would work. It could be entirely local, it could be small-scale, it could be one global instance, it's currently unknown.

Sounds like something that scaling up - assuming you can handle the material strength issues - helps with. Surface area per unit of volume would go down as the size of the bubble went up - put it in a dome over a 2km diameter mini-city, and and how much heat would you need?

Some people who are saying it are probably thinking of the limitations of the KSP1 engine - in which case a ship out of focus is either landed, prelaunched, in orbit, or destroyed. In either of the first cases it's stationary, in orbit it's calculated separately from the planet it's orbiting around. This avoids having to deal with fuel, aerodynamics, ground collisions, etc. on unloaded vessels. It's definitely possible that they could change this for KSP2 - but it's also quite possible that they don't.

I'm guessing it's more that you have to have an active connection between your ship and the beacon you're using to jump. Could be either or both, however.

Yes, but the miniAVC version was a stand-alone DLL which was in every mod that used it - and broke horribly after 1.8. So not only did it not work, it also crashed KSP. Remove them all, install KSP-AVC (the full version, which is a separate mod and updated) and see if it works.

They're directly linked in this case anyway. From that graph, it'll all be hydrogen down to well below where you want to be, so it's a simple ratio.

That was from the C# code describing the defaults. It's necessary in C#, but not in Module Manager. (TLD: Just ignore it, it's a C# thing.)

Worth noting is that generally mods for 1.8.x work with 1.9.x. There may be some exceptions, but assume that true unless otherwise stated. 1.7.x->1.8.x was a low-level change, which meant most compiled mods needed updates, but that low-level change doesn't occur every update.

Typically either a single core, or if I can't get enough dV on the core (without dropping the TWR to low) I'll add 3-4 SRBs. The SRBs will be in a separate stage, and drop before the core fires up. Occasionally for really heavy payloads where I need both dV and TWR, I'll do the same 3-4, but as LFO and staged to the main stage. I've played with Asparagus staging a few times, but I rarely need to get that exotic.

Honestly, if the intent is to minimize testing and bughunting - I don't really see it. For if/than statements you only need to test both sides of the if statement for full coverage. For a variable constant, to have good coverage you need to test both the maximum and minimum values, a few in the middle, one below the minimum, one above the maximum, and at least one further out on both sides. So you haven't really simplified your testing. You've simplified your code a bit, maybe, but I'm not sure it's an overall help.

The other piece of advice I'd give - and it's somewhat counter-intuitive - is *don't* attach to the ground if you can help it. At least, not for long-term bases and such. Exact placement of things after a scene reload tends to vary by a bit, and anything directly attached to the ground isn't going to handle that well.

Computers are annoying things. Never doing what you want, only what you told them.

Likely because at this point there's no *debate* happening: Debate assumes an exchange of ideas and considering of opposing arguments - And at this point in this thread there's no real exchange or consideration going on, there's just two opposing sides. No one is going to be changing anyone's opinion, so participating further really only increases the likelihood of it becoming a full-out argument, which I don't think anyone wants. Best to let it die as 'I respectfully disagree with your position' at this point - while the 'respectfully' can still be left in.

Nearly all Linux users do understand that not everything is Open Source, and that they have to deal with that. Especially since the business model for Open Source software and the business model for games doesn't really intersect anywhere.

Nice to have someone in charge of this mod again. It's my go-to for whenever something that needs to be done in a ship is behaving a bit 'wonky'.

Honestly, if you wanted to go mobile the right thing would to do would be to have a 'flight computer' app that could tie into your currently running version of KSP on your desktop, and give various readouts and calculations.

I think he's saying thanks. ('ty' being 'thank you'.) Not sure though.

There are probably lots of places for an experienced development team to make incremental improvements between KSP1 and KSP2 - but none of that's really relevant to this thread. At the end of the day, you'll still have one big thread that likely can't be broken up that's the bottleneck for the game, and no multi-thread or multi-core process approach is going to help that. On the other hand they have mentioned a physics 'level-of-detail' system - where parts close to the player's attention will get simulated more accurately and those further away will get less costly simulation. *That* will make a difference.

I'd say it's more because they're trying to design more powerful chips, while they've basically already hit the limit of how fast silicon can cycle. However they can add more transistors to the same area of silicon - so to make a more powerful chip they need to figure out how to make use of that to allow more operations per cycle. Obvious answer is to build more operations pipelines.

I never play either. Do I have to do one or the other?

What engine do you think would do better? Note that I do think they'll have rewritten large portions of the physics engine.

I do get what he's saying here. There are two ways features/choices hurt testing/debugging: First is interactions, which in theory go up by the square of the number of optional features. (But that can be mitigated to a large extent by good encapsulation.) The other large one that encapsulation can't handle is if you try to build features on top of other features. Say you have both light-speed delay and comnet - If you turn comnet off, how does light-speed delay work? If you turn comnet on, does the delay take into account the length of the comnet? The features are interdependent, so you now need to test both combinations. So there is a cost, and sometimes the cost is too high I understand - but pushing 'no options' is pushing that cost to far the other way in my opinion.