Jump to content

ExtremeSquared

Members
  • Posts

    311
  • Joined

  • Last visited

Posts posted by ExtremeSquared

  1. To be fair, I don't think any of us expect KSP to get anything right beyond orbital physics, but the game describing every body in the system as life-containing is a bit bold. All biomes contain life and the R/D center lists biomes on Moho and Eeloo. It's relatively unlikely that bacteria would survive in those places.

  2. 14 hours ago, linuxgurugamer said:

    So how does an average player take that signal and convert it to an image.

    And,going the other way, how could someone take an image and convert it into a signal like that for use in the game?

    Debian has a bunch of metapackages for Ham radio stuff. Qsstv is where I'd start for sstv.

  3. There are plenty of bugs to be found on Voyager-type missions. I'm guessing there are limited protections from overflow errors in either Unity or KSP or both.
    I get persistent graphical corruption from switching to an extreme-distance ion probe that did a solar slingshot maneuver 200 game years back. Requires restart.

  4. 12 hours ago, Sppion1 said:

    That just display the manoeuver node, node the point where the alarm will fire. For example for an alarm for target distance, (to body, kerbin, at 100km), it place an alarm a bit before, but I want to see it on the path.

    Right, the date arithmetic must be done manually. The orbital path shows timestamps when you click on it, which guide you to where you want the maneuver node. Then set a maneuver alarm.

  5. Makes sense regardless.
    1.8.0 was a bit of a train wreck and 1.8.1 is still slightly rough around the edges. Releases usually go like this when developing with a lightened QA effort. Makes sense for mod coders to always wait for 1.X.2 in order to avoid wasting effort.

  6. On 8/24/2019 at 3:02 PM, Poodmund said:

    I think its tied into the Science 'Recovery' Multiplier value for each body as SetDeadlineYears depends on GetContractDestinationWeight which depends on body.scienceValues.RecoveryValue so by changing something like: https://github.com/Poodmund/Outer-Planets-Mod/blob/master/GameData/OPM/KopernicusConfigs/OuterPlanets/Plock.cfg#L35 to a higher number may in fact increase the duration of the contracts upon their generation (will not affect existing contracts).

    If you're willing to test this out, then please let me know.

    I am testing this now. Just got a one-way Karen/Plock contract with a duration of 17 years which is probably unworkable below a 15km/s dV budget. Nissee 29 years. Urlum 26 years -- doable.

    After cfg change:

     

  7. Career started in 1.6.1 is at 266 years. ~150 tracked crafts. Mining colonies and orbital fuel depots in every planetary system + OPM planets. Winding it down now with a grand tour of every body including OPM bodies. That alone takes over 150 years with simple hohmann transfers. Planning to bring all manned missions back when 1.8.2 is released and mods catch up, and start again from clean install. I am a little surprised this save has lasted so long without bugging out seriously.

  8. I wonder if this isn't bad timing. Maybe should have saved this until 1.8.1 for the sake of giving good first impressions to new players, considering the state of 1.8.0. Then again, KSP 1.0 was in even worse shape and a lot of us still got hooked in the EA days.

  9. 34 minutes ago, Streetwind said:

    Seen nothing like this even during testing. My first instinct in such a case is always to blame Steam. The way it updates games has caused issues with KSP in the past, so it may have done so again? Go uninstall your game (your savegames will be preserved), make sure to delete settings.cfg for good measure (in case it has some wierd mouse settings saved), and reinstall cleanly.

    It's a from-scratch install in a clean VM. Odd indeed. There are some other documented texture bugs also, so I will revisit this in 1.8.1.
    No complaints though -- this is pretty well polished for an engine upgrade.

×
×
  • Create New...