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?

Gee, what a new and unique insight that has in no way been considered. ...I'm sorry, I appear to have left my sarcasm neurons engaged. Let me try again. Apart from other things Commnet provides neither signal delay nor the flight computer, both of which are major draws for RT players.

Correct (ish) - but it's the "& co" that's crucial here: Part of the point of the GNU GPL is that every contributor would have to agree to do this, or all code touched by those contributors who did not explicitly so agree would have to be stripped out of the BSD licence. And it'd probably have to be replaced by still other contributors who were given only a description of what the missing code did and had never seen the original, to ensure that the replacement wasn't derived from the GPL-only code. As the number of historical contributors rises and their contributions gain dependencies in other parts of the code, the difficulty of a) contacting them and b) replacing code written by people who refuse or cannot be contacted both increase. In short: Ferram alone can't change the licence. Ferram et al can change the licence in theory, but it'd be a lot of work in practice. (also there's no need to consider the differently-licensed versions distinct until and unless there are differences between them besides licensing, such as newly-contributed patches that are GPL-only (BSD-only ones can be relicensed as GPL by the terms of the BSD licence, so that way round is a non-issue). So there'd still be one FAR, and it'd be dual-licensed, until and unless there was a subsequent single-licence release.)

Forgive my bluntness, please, but since this is not an officially-announced FAR release or beta, if thou dostn't know what th'art doing thou probably shouldstn't be using it. It's not ready - which is to say, it was known not to be release-ready more recently than the last commit on that branch. If Ferram wants more testers, we'll hear about it. That being said, copying the contents of the repository's GameData folder (specifically, the FerramAerospaceResearch folder therein) to the game's GameData folder is the usual procedure. Probably best, if working with this dev-branch, to delete any such folder that already exists. Do watch out for the possibility of accidentally ending up with a "GameData/GameData/FerramAerospaceResearch" folder.

It's not that, either. It's about being able to mount a control surface in the middle of the wing rather than on the edge. Such a surface (assuming it's atop the wing, rather than beneath) should be able to deflect up, either for use symmetrically as a spoiler or differentially as an aileron, but it should not be able to deflect down because that would involve clipping through the wing. FAR does not provide a way to do this "properly"; I've checked the code and there's no way to set maximum deflection distinctly from minimum deflection, which I'm pretty sure is what would be needed to achieve this even with a ModuleManager patch. At least using ModuleControlSurface and FARControllableSurface - there might be something doable by working off the airbrake part instead of a control-surface one? Failing that, the only options I can see are abusing the features FAR does provide, as discussed, or finding or creating a secondary mod.

Right, which is why I interpreted the first suggestion to mean what would essentially be abusing the flap settings. The idea is that while the parts to be used as spoilerons would have their flap settings enabled and their flap-level set such that they stay at maximum negative deflection, they'd be excluded from any flap-control action groups so that they stay there, and don't change with the flap-settings. They're not used as flaps, they just exploit that group of settings. The problem is that, under FAR, a single control surface can be set as a flap or as a spoiler, but not both - so to avoid choosing between using them as positive-only ailerons and as spoilers (or doubling up, clipping dupes into each other and using one set as each? That might work but feels wrong) it'll be necessary to add mod-parts. Or work with spoilers that aren't automatically in the brake action-group, &c &c &c.

It really depends how far in the future these archaeologists are. In a hundred years, sure, they'll recognise we were probably messing with them. How about a couple of millennia? At that point, they may very well assume we didn't think of that, just as most archaeologists today tend to assume their finds are either genuine or very recent fabrications, rather than faked up to mess with them on the low end of the archaeological timescale but more than a couple of decades before.

I think the idea is to place the part at an angle, then abuse the flap feature using a negative flap-deflection so that when the specific control surface is in the correct flap-state its rest position is level with the wing. The maximum total deflection won't let it go below there, but it should still respond to control inputs that would move it upward.

That... might actually work, yeah.

That works so long as one always wants the no-control-input position to be at the midpoint of the surface's travel. I can't immediately see a way to produce a surface that's level without any control inputs, and only moves one way - it would probably be necessary to clone-and-patch the part and use the result.

Burial suggestion: Cremated remains in a lead-lined box, along with as many anachronisms as you can manage. Pump out the air, or fill it with an inert gas, and encase the whole thing in a durable ceramic with carefully-consistent gibberish inlaid in a ceramic of a different colour. Maybe also some warnings in actual languages. Drop onto oceanic ridge - I'd suggest a trench but those tend to be subduction zones and the box probably wouldn't survive the mantle even if we add some phenomenal thermal insulating layer under the ceramic - and it'll be extremely unlikely to wash up until you and your civilisation are long-forgotten, which is of course ideal for messing with archaeologists.