cpast

"Kraken" has no meaning; it is not a subcategory of "bug". It is a term that formerly referred to one bug, which was fixed a long time ago. Any use that isn't that specific bug is worse than useless - you are trying to distinguish between "bugs" and "krakens", and use "kraken" to refer to a class of bug, and that doesn't work. If you start using terms that mean something that everyone can agree upon, you'll get your point across better. It is indeed true that some bugs are tiny errors in the code. That still doesn't help; before you can fix a bug you have to find out what causes it, and that is normally the hard part of debugging. Some bugs are small mistakes. Others are consequences of design decisions, and fixing them requires redesigning substantial parts of the code (the Kraken, i.e. the specific bug that is the only sort of objective meaning to the word, was in this category - the fix was to zero out position and velocity of the current ship when they went past certain thresholds, and move the universe around the ship). Others are consequences of the unexpected interaction between multiple parts of code. There is no way to know without extensive work isolating a bug, which may be in a section of code that seems unrelated to the symptoms. Isolating bugs is extremely hard, fixing them is generally much easier. But you can't fix them without isolating them.

I really don't think "what if Skylon succeeds" means "will Skylon succeed?"

Because physics in orbit *are* substantially simpler. In orbit, with no thrusters of any sort firing and no reaction wheels moving, the only force is gravity. There are no other forces. With parachutes and with ground impact, there are multiple forces at play, and different parts have substantially different forces applying. There is literally no possible equivalent of rails; rails are based on a (reasonably accurate) patched conic Keplerian orbit, which is analytically solvable. With such an orbit, there is no force simulation required. Keplerian orbits do not require any considerations of force, except to initially derive orbital parameters; after that, there is an equation in the orbital parameters (which don't change during the orbit) and time that returns the position of the orbiting object. That means there is no need to go from time A to time B by means of many small steps - you can directly calculate where it will be at time B, without knowing where it will be at any other time. No such thing exists for ground impact. First, the force is initially applied just to the bit that touches the ground; that means rotation angle is key (while it is irrelevant where there aren't collisions, such as in orbit). That has to be simulated. Likewise, you need to look at where precisely the part will land, what slope it has, what torque is applied on initial touchdown, how the part behaves from there... it is far more complicated than setting position equal to Pos(orbit, t).

I've been assuming that, in this thread, "succeeds" means "succeeds at all stated goals" -- turnaround time of days, makes access to space as cheap as they claim. This thread is assuming Skylon succeeds at its goals, not whether it will or can.

"I can't sleep because it's so hot out" is not remotely the same thing as a sleep disorder. Sleep disorders are medical conditions, and you should check with either a physician who gives flight physicals, or the relevant aviation authority, for if it's disqualifying or not. If you want to know whether it disqualifies a particular person, only a doctor can really tell you, and only after examining you.

They did remove the kraken; there is no more kraken. There are bugs, but "kraken" is a worse-than-useless term for them (it implies they're all related, when they're not). One does not simply "remove" bugs (insert obligatory image); you can "fix" bugs, but it's a painstaking (though necessary) process that sometimes introduces more bugs. "Remove" implies that it's something easy to do, and the devs are just lazily deciding not to do it. Debugging is actually the single hardest part of software development, and is never complete.

I can think of such a reason - letting you recover all stages by slapping on parachutes means there is no longer such a need to minimize staging. It's harder to use fewer stages; doing so should be rewarded by any sensible budget system. I've still never seen a very good reason upper stages *should* be recoverable.

Very probably. It really depends on the mod; there's no formal definition that says "it's not 0.24 compatible unless these criteria are met". That said, the OP will probably say if it doesn't work on x86-64, and if it doesn't say anything about it it probably works fine.

Out of curiosity, what are the proper channels for something like this? PM Rowsdowser or something?

Most programs don't, but modern operating systems do schedule processes on different cores, so it can still be an advantage if you like being able to run multiple things at once. Coincidentally, that's the easiest example to explain, IMO: Multiple cores mean the computer can in fact do multiple things at once. With one core, for instance, processes all have to split time on the one core. With four, four programs can all be doing something simultaneously.

This is generally not the case. The vast majority of people generally do not care one way or the other, and just want the dialog to go away. They won't change anything from default settings, because they couldn't care less. Someone accepting a default option never means for sure that they affirmatively prefer that option; it just means they don't care enough to bother reading or changing it. Most people neither opt-out or opt-in, they just opt-default. For those people, the question is "is it ethical to collect their statistics", and the answer is by no means certain, but there is a strong case to be made that if someone doesn't object to statistics collection (i.e. when presented with the choice, they see no reason to choose "no" -- ModStatistics now doesn't present that choice well enough, but opt-out systems can certainly do just that), there's no issue collecting those statistics.

No functional aspect of recovery depends in any way on whether something is debris or not. The only thing debris doesn't do is show the window when you recover; you can still recover it, and get funds back based on distance to KSC (you do have to do this before producing so much debris the game starts removing the old debris, but if you do it right after your mission this isn't an issue). The recovery percentage does not change between controllable craft and debris. Nor does it affect the physics sphere limitation -- all ships on rails below 22km on Kerbin are removed without mods, whether or not they have any given part on them. Even manned craft will be deleted if over 2.5km from the controlled craft and under 22km high on Kerbin.

They already have to do so, per the license (and likely per the forum rules, which say you have to notify people if your addon collects data).

On the topic of Squad's official position, stupid_chris said in the ModStatistics thread:

Because some people would really, really not like to use Curse, and want the features a modding-specific download site would provide (as opposed to Dropbox and co., which just host a file, and are useless for *finding* mods).

I'm picturing HarvesteR looking through the codebase and saying "Oh, there's RandomlyFreakOutAndCauseBugs(). Guess I'll just take it out and be done with my day." If bug-checking were as easy as that, programming would be trivial; however, given that HarvesteR didn't explicitly and intentionally write bugged code, he can't easily just remove it.

Right, because the plugin component in question was released in January 2014 (missing the 0.22-0.23 shift), and the ARM release didn't change major or minor version number (the .5 is the revision number, and many plugins didn't check it, just checking major/minor instead). CompatibilityChecker is designed by modders, and implemented in some mods, but is not part of the stock game.

Or you follow the instructions on page 1 - make a ModStatistics folder in GameData, make a settings.cfg with "disabled = false", never worry about it again. Literally every post saying "Oh, I have to go through each plugin to see if it uses this" is wrong on two counts - one, there is a config way to disable it permanently, and two, all mods using it must announce that fact on their forum thread per the distribution rules. Moreover, unless you have the config already there, adding a new mod with ModStatistics will generate a popup window on the main menu, to ask if you want autoupdates. That's not to say it shouldn't also let you disable stats collection -- it should. But it's not like this is some nefarious thing that is near-impossible to notice or disable.

What if I happen to want the original crew on one particular mission? Is there a way to get that (maybe by launching from crew tab?)

Majir: Until you can get the button working the way you want it to, is there any reason it wouldn't work to just add, after line 106 (and basically copying the update option code): new Callback(() => { disabled = GUILayout.Toggle(disabled, "Disable anonymous data collection"); }), or maybe (not sure if Unity works like this, but if it does) new Callback(() => { disabled = !(GUILayout.Toggle(!disabled, "Enable anonymous data collection")); }), to make the first-run window prompt for data collection as well as updates? It's not as good as a button always visible, for sure, but it might be an OK hotfix if it works.

Is that part of KSP? I think that's code in the mods themselves that pops that check.

Why should you get some back at all?

You can always make the file yourself, but maybe, until Majir updates the UI, he could put up a download consisting of a ModStatistics folder with a settings.cfg with disabled=true?

I think you're looking at the trajectory the wrong way around. The really bright part (and the sudden edge) is at the top of the picture; that's probably the Orbiter, which has gone from the bottom of this picture to the top. The shape of the trajectory on the picture is then more a function of perspective than anything else.

I got one like that as well. It's nowhere near "impossible"; it's actually rather easy.