Darael

Members
  • Content Count

    38
  • Joined

  • Last visited

Community Reputation

19 Good

About Darael

  • Rank
    Rocketeer

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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.
  2. 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.
  3. 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"
  4. 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).
  5. 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.
  6. 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.
  7. 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.
  8. ...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)
  9. 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.)
  10. 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?
  11. 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.
  12. 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.)
  13. 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.
  14. 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.
  15. 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.