cpast

Not even close. 30 fuel tanks weigh as much as 30 fuel tanks. Infinite fuel weighs as much as 1 fuel tank.

...and Romfarer, according to devnotes, is picking this week for a vacation.

Alternatively, he might be starting something for 0.25 now, because he's not at Squad for long so it's useless for him to be sitting around doing nothing until release.

What we're thinking on what? Squad knows we'd generically not like to lose saves ("Please wipe out all of the hard work I've done!" is not a common feature request), and our speculation, while fun, doesn't affect anything. I don't see anything *wrong* with the topic (it's not like harmless speculation ever hurt anyone), but let's not pretend its somehow useful. IMO, the poll is a bit too formalized for random speculation - polls don't encourage speculation and discussion, they restrict things to your answer to the poll question. They're useful in some cases (like if you care about the average opinion of the people who voted in it), but this is a case where the opinion of most KSP players is frankly useless, so we may as well just speculate in posts where there's actually discussion to be had.

Yes, B9 is huge. It contains 210 distinct parts (source: the B9 thread). KSP contains 181 parts (source: the wiki). By any sane definition of the word, B9 is huge. I can see you have no decent argument against the notion that adding tons of parts creates a usability issue, because you went straight to name-calling and empty mockery. "REALLY?!?!" is not a counterargument to anything.

Why? Why should Squad take over maintenance of an absurdly massive parts pack featuring a very non-stock art style, focused on a less-emphasized part of the game? B9 is a *huge* pack, and Squad's time is better spent working on things in stock than maintaining mods whose sole function is to add loads and loads of extra parts. The Kerbin Cup mod is different because it is very small and simple, and ties in with other things Squad was doing (i.e. Kerbin Cup). B9 doesn't add anything like that; all it would do would be to expand parts available for players, which is something that comes later in the dev cycle (and should be more closely integrated into stock).

You'll have to update a number of mods, but staying on an old version locks you out from many current mods, so it's generally better to upgrade.

Unless one of the voters in the poll is an experimentals or QA tester, that is.

According to Maxmaps, they're basically using that hack, with a few tweaks they've done over the years to improve stability of it (they knew about the unstable experimental 64-bit Unity player on Windows since before Maxmaps was hired, and had improving stability on a back burner, so it got some dev time when a dev wasn't doing anything more pressing). The thread you mentioned convinced them there was enough demand to release a somewhat buggy version; the 64-bit version of 0.24 will not be as stable as the 32-bit one. That said - 64-bit is not a panacea; all it does is let KSP address more memory. That doesn't magically give a computer more physical RAM, nor does it mean that memory usage is no longer an issue -- excessive memory usage almost never means "this program tries to allocate more memory than it can address", it means "this program is a memory hog, meaning I need to make sure my computer has lots of physical RAM, and that it sucks up a lot of system resources that could otherwise go to other programs". It's a band-aid solution; the actual solution would be to revise how resources are loaded.

On the SteamDB page, why's the QA build ID lower than the Experimentals build ID?

Not quite the same - pre-0.22 saves simply didn't have the tech tree and science stuff in the save, and neither do 0.22-on sandbox saves. It wasn't an issue because the new stuff in saves only applied to career saves, which didn't exist before 0.22. Here, on the other hand, people already have career saves -- there's not likely to be a "science but no money" mode, like 0.22 had a "no science" mode.

OK, so how do I use that with RPM 0.17? The version in KSO is older than RPM 0.17.

Steam normally autoupdates KSP, although you can turn this off. The store version does not.

After installing RPM 0.17, the KSO's monitors no longer work. Any idea why?

Getting permission from the owner of the item in question seems to rule out "piracy" as a proper word for this.

Some engines are too powerful even for a single set of blades, and have two or more sets of blades on the same axis.

His point is that everything in career mode thus far has happened in the past year; I don't read it as saying that career mode is done. He's replying to someone saying *nothing* changed, not someone saying the game's too far from completion.

That was a while ago. He has since left. He made the current KSC models, but I don't think he ever did anything much with spaceplane stuff.

Going through the list, and cross-referencing with the (admittedly outdated, still lists C7 as active) "meet the team", here's my guess on what people's roles have been: HarvesteR: Developer. Alex: seems to be in charge of running Squad's servers, keeping all their services up. Mu: Developer; "bug fixing" implies he's doing development tasks. Daniel: Working on making videos (his job is not active game development) Jim: UI dev (again, "bug fixing" = he's not just testing; also, he mentions systems he implemented) Maxmaps: Not a dev, he's PR Calisker: ditto, he's PR Ted: QA lead; he's not so much directly testing as running the testing, collecting feedback, etc. - still falls under "working on the game itself" Rowsdowser: Not a dev; he's in charge of community issues Eduardo: Project manager, in charge of coordinating everything, making sure everyone knows what they need to be doing and checking in on their progress Rogelio: Appears to be a similar job to danRosas, making videos Hugo: Also doing development work Devnotes are generally what team members have personally been doing; if someone says "this week has been all about bug fixing", they mean "I personally have been squashing bugs this week". Count: 5 actively working on the game itself, 1 project manager (not directly working on the game, but still a critical position to try to get things done in reasonable time), 1 server admin, 5 PR-y tasks (working on video + the actual PR guys + Rowsdowser). We get a mention of a Marco as well (in Ted's devnote), who the main site says is another programmer, so 6 directly working on game, 1 server admin, 5 community/PR, 1 project manager. I don't think Squad permanently employs any people who just test for bugs - actual testing is done mainly by volunteers, and Squad employees who are testing are generally doing that plus actual development, or are doing that plus media team stuff. You can tell from the devnote which it is.

They can't reduce the force of drag, but they can reduce the acceleration caused by drag. On a rocket of mass 10 made up entirely of parts with drag coefficient 0.2, the drag is (constant)*2*v^2 [constant depends on the atmospheric density, but not on the ship itself or on the velocity]; this gives an acceleration due to drag of (constant)*.2*v^2. Adding a part with mass 1 and drag coefficient 0.1 will increase the force of drag by only (constant)*0.1*v^2, for a net drag of (constant)*2.1*v^2; the acceleration is then (constant)*.19*v^2, less than before. Equivalently (and this is how the wiki defines the drag formula), ship drag is proportional to v^2, to ship mass, and to the net drag coefficient. To get acceleration, you wipe out the mass term, so the acceleration due to drag is proportional to v^2 and the net drag coefficient. The net drag coefficient is the weighted average of the drag coefficients of each part, with the weights being the masses of the parts. Adding a part with lower-than-average drag coefficient reduces the net drag coefficient, thus reducing acceleration due to drag in atmosphere. The trouble is that the drag of a part is factored in the same way no matter what the situation is; that means fairings do *not* reduce drag of the parts behind them, and only have a tiny impact on the drag of the ship. Also, under power, you care more about the actual force due to drag, which does go up whenever a part is added (when not under power, you only care about acceleration).

I currently seem to be on a break from the game - I've tried launching, but always stop before clicking "play" because I'm just not horribly motivated to click it. I suspect it'll pass, though. Even if I don't return for some reason, I bought the game for 2 hours of pay, and have gotten well over 500 hours of gameplay out of it - I could literally play 24/7 for a week per hour of labor it cost me. I count that as a win.

I'm generally in favor of things that make your space program your space program, keeping track of the history and the like. So, good idea!

There is in fact a treaty to that effect.

Why? Because you said so? By this logic, KSP can literally never be finished, as no part ever directly affects those who don't use it, and thus belongs in the game by this logic. What they do do is take up a large amount of development time, to design them, decide on their functionality, and balance everything. It also expands the part list that is seen by non-modders, making it just that tiny bit more confusing. It also can compromise the core idea of the game (you know, that part where the game has a central, guiding vision that should be generally preserved, because if you wanted a fully generic thing, download an assembler). Literally anything being added should first be checked to make sure it fits with the core idea of the game (this eliminates weapons, for instance), then be run through a cost-benefit analysis to ensure that it's really the best thing the devs could be doing with their time. If the devs implement a stock autopilot, there are other things they will not be able to implement (given that they likely want to finish KSP development in a reasonable amount of time, before they all get bored with it and want to move on). If something is optional, and doesn't have to be used by all players, how many actually will use it? How will it affect their experience? If most people wouldn't use a complicated feature, it's not worth the time to implement. If it changes their experience and moves the stock experience away from the one Squad wants to create, it shouldn't be implemented, period.

Very few people use that. There are actually no forums I'm aware of where that sort of thing is actually in common use.