Darael

Hi. I'm sure you're extremely busy, but I was wondering if you had a timescale on the "why we ditched CKAN" rant? It's been listed as "coming soon" for a while now, and while I can see from the B9 PWings situation that you are upset with how that was handled, the "on CKAN" section pointed to by TweakScale's alert popup says "the reasons can be found here" and pointing at… a placeholder page. Not exactly the most user-friendly experience, if you catch my drift.

I was using NVidia binary drivers, but some update broke something to the point where several games, KSP included, would lock my system up entirely shortly after launch, requiring a magic-sysrq reboot to recover. I got sick of trying to fix it and switched to Nouveau instead. Not quite as performant, but better than "locks not just X but the entire computer". Frequently, especially early in career when I'm using SoundingRockets to do FieldResearch "science around KSC" contracts for reputation (and, if I wasn't using Bureaucracy, funds). This can easily lead to multiple launches in a day despite my use of KCT since I'm recovering a very small rocket from within KSC, editing it slightly to change the heading it'll launch on, refuelling, and rolling it right back out again — not to mention jumping into Mission Control every so often to grab the next contract.

Possible bug: When repairing an aerodynamic control surface (or at least, any of the Firespitter biplane ones), all control axes are enabled for that surface, not just the ones that were enabled before failure. This can cause a plane to become even more unbalanced when repaired, as control inputs (whether from trim, SAS, or an autopilot mod) start affecting surfaces they shouldn't. It requires players to remember the correct configuration for every control surface, just in case they fail and have to be repaired. Instead, those tweakables (which are used to implement the failure, by disabling them all when failure occurs) should be saved somewhere so they can be restored automatically upon repair.

I'm experiencing something similar to what Pippin describes, and (while I am also pretty heavily modded) I am not using EVARepairs. However, it's less consistent: on some game starts, science seems to be instant immediately, and on other application runs it can take dozens of launches before it happens. My latest log is here. ..

Except generally we aren't talking about electric charge, but about stored energy. regardless of which terminology people use day-to-day. Yes, a lot of batteries are rated in Ah, and that's misleading because two different 200mAH batteries can have wildly different energy capacities depending on their operating voltages. I suppose we could use charge and operate on the assumption that all systems on all craft operate at a standard voltage. If we did that, we'd rate power consumers in amps — well and good, but we'd also rate generators in amps, and I don't know about you but to me that feels deeply wrong. As such, for the unit-combinations that are technically correct (and ignoring any kilo- or milli- prefixes for now), I'd advocate for joules/watts or watt-hours/watts over amp-hours/amps or coulombs/amps.

Still using KSP 1.3.0, so Hangar 3.3.2 - I find that if I load the automatically-created quicksaves (with names of the form "<vessel-launched>-before_launch") from immediately before launching a vessel, the vessel that was to be launched just... disappears. It's gone from the hangar, but it's not spawned in the world. This does not happen with manual quicksaves, and any other hangared vessels, whether in the same hangar or another one on the same craft, are unaffected. That's something of a mitigating factor. Nevertheless, it makes those automatic saves worse than useless. I have thus far observed this phenomenon with a fairing hangar and with an inline hangar, the latter while testing in a sandbox game on the launchpad. My guess (and come to think of it I should really read the code rather than just conjecturing like this) would be that the hangar plugin is triggering the quicksave and immediately proceeding with the remove-from-hangar-spawn-into-world dance, so that by the time the quicksave actually occurs the first of those steps has already finished. Is there a way to wait until the quicksave is finished before continuing? Some blocking variant of whatever call it is you use to save the game, perhaps? Hopefully-final edit: I was partially wrong. The bug exists, but it's not a race condition; the code as it stands just removes the vessel before firing off the save. My best guess for a fix (bearing in mind that I don't know your code and this may be horribly wrong) would be to move the save from Source/HangarMachinery.cs line 753 up a few lines, to the top of the function (or at least to immediately after "if(!can_restore(stored_vessel)) return;"). You're removing the vessel in an if-test on line 742, before the save is fired off.

While you're right in principle, the game stores orbits by way of their semimajor axis; orbital period is a calculated value. To the best of my knowledge, no calculation that doesn't start containing an infinity and doesn't involve dividing by zero is going to produce one, at least in the sorts of languages involved. I don't think calculations that result in values greater than the maximum return +Infty, though I confess I haven't checked. You should be able to set an infinite orbital radius, though, assuming the save-file reader can cope with it. On the hyperbolic question: yes, it's infinite, nominally, but KSP uses some means to ascribe a nominal orbital period for use with the MNA value stored in the save file - although I have no idea what that is.

This isn't about a limit on what you can practically reach (which HyperEdit would bypass), it's about the fact that there is an edge to the Kerbal universe, somewhere around a number of distance-units from the centre equal to the maximum number representable with an IEEE float. That's before we even start considering the case where the orbital radius is large enough that the limits of floating-point precision make the physics break down, as @FungusForge notes - krakensbane helps to reduce those effects (by putting the craft at or near the centre of the universe), but they still kick in long before you reach the actual edge (because everything else is then way out towards the "new" edge, so even though those things are on rails, your acceleration due to gravity gets all messed up). Just to clarify, my original "no, you can't" wasn't in response to "With HyperEdit, you can put your craft into an insane circular Kerbol orbit that is several million exameters with an orbital velocity of 0.1 m/s", because that part is true. No, it was a response to the last sentence: "[...]technically, you can be at infinite distance with an infinite orbital period"

I know the reason and have just submitted a pull request to NetKAN to fix it. Essentially, the metadata file they had was forcing a minimum and maximum version, causing CKAN to think OPT was available only for KSP 1.2.2, rather than pulling compatibility information from Curse. I've removed that, so now it'll do the automatic thing. (incidentally, if Spacedock is the preferred source for automatic CKAN data-scraping, I can set that up too).

No, you can't, because there exist maximum values dictated by the nature of the game engine. The SoI is infinite but the maximum distance at which a craft can be located is not.

Except there wasn't. Those comments were about the version for 1.2.2. Some people are still playing older versions and they still talk about them. What you "knew" - implicitly, that there was already a compile for 1.3 - wasn't true until after you posted.

Point of interest (but low-to-zero importance), prompted by a screenshot posted on the 7th: While the SI is a metric system, so it's pretty legit to put the latter parenthesised after the former, the US Customary and Imperial unit systems are different, though they (unhelpfully) use almost all the same unit names. While this is mostly significant for volume, which rarely comes up in KSP and certainly not for Astrogator's purposes, there are two other units with different values between the systems: the hundredweight and (as a consequence) the ton. Now, while I don't imagine weights (/masses; neither Imperial nor USC distinguishes entirely between the two, using weight-units with an implied under-Earth-standard-gravity for mass) will come up in Astrogator specifically, the difference between the US-Customary (or "short") ton of 20cwt of 100lbs (noticeably less than the metric tonne used by default in KSP) and Imperial (or "long") ton of 20cwt each of 112lbs (total: fractionally more than a tonne) would be significant to someone playing entirely in such units. This has been a needlessly-pedantic post on measurement systems. Now, a return to normal Astrogator programming.

...ignore me; I appear to have missed things on my readthrough of the last couple of pages. Just registering, then, that I'm also getting the black scene and NRE spam, on Debian Testing further edit: I found the GitHub bug-report; since you had to pull 2.0.3, which I see there contained the fixes, is there any chance of an a micro-release that keeps those path-changes even if it doesn't contain the attempt at making DDS work on opengl? Failing that, my fellows on those platforms may be interested in pasting the following into their terminals, after tweaking the path to KSP, which should do it in place, and do so entirely by editing the config files rather than renaming Eve2_00.png as suggested by DylanFrese, which should avoid any possibility of upgrades ending up with two copies of a file: sed -i -e 's_SVT/Terrain_SVT/terrain_' -e 's_SVT/sun_SVT/Sun_' -e "s/eve2_00.png/Eve2_00.png/" /path/to/ksp/GameData/SVT/{Kerbin/Kerbin.cfg,Eve/*.cfg,Sun/Sun.cfg} (it may be a touch more "careful" about selecting the right lines to replace than it needs to be, but I figure that can't do any harm)

Sounds entirely reasonable. I guess I'll have to make do with the plenty of other systems GN can provide. What a tragedy. (with somewhat less self-directed sarcasm, thanks for GN. It is a wonderful thing as it is.)

I realise I'm perhaps being a little hasty, not to mention proposing still more work, but would it be possible to integrate the revived version of Interstellar Adventure, at some point?