Jump to content

OhioBob

Members
 View Profile  See their activity

  • Posts

    3,934

  • Joined

  • Last visited

 Content Type 

Everything posted by OhioBob

  1. OhioBob
    16 km is Hale's computed SOI at 2.5x scale. Likewise, 58 km (as seen in the screenshot) is Ovok's computed SOI at 2.5x scale. So what is apprently happening is SigmaDimensions is resizing the planets, then the SOIs are being computed using KSP's internal formula. The sphereOfInfluence parameter is not being used at all. I have no idea what would cause such a thing to happen. @tmccreight651, obviously you are using SigmaDimension to do the rescaling, but what configs are you using? Are you using Rescale, Rescale Continued, your own custom configs, or something else? (edit) I just ran a test in a minimum install with OPM and SigmaDimensions. The only settings I changed where the Resize and Rescale multipliers to 2.5. SigmaDimensions correctly rescaled the SOIs of Hale and Ovok. So that tells me SigmaDimensions is doing what it is suppose to do. The bug is most likely due to some unusual mod interaction.
  2. OhioBob
    I doubt you'll get a response. Sigma88 (maker of all the Sigma mods) hasn't been around for a long time. As far as I know, he has stopped maintaining all of his mods.
  3. OhioBob
    The renamer and replacements mods have been a source of occasional complaints and bugs since the beginning. I've therefore decided to strip GPP of all the unnecessary frills and extras and just get down to the basics of providing a planet pack. I just don't want to have to deal the the maintenance of all those extras.
  4. OhioBob
    You're going to have to do what Poodmund said and take up the issue with the maker of whatever rescale mod you're using. The SOIs shown in your screenshots are actually smaller than what they are in the OPM configs -- Ovok's SOI at normal scale should be 94 km and Hale's 41 km, yet the screenshot shows them as 58 and 16 km. So clearly something is screwing up the SOIs, making them smaller rather than larger. This is not an OPM problem. (edit) I've figured out what's happening, but I don't know why. For some reason the sphereOfInfluence parameter is being ignored and you're getting the KSP computed SOI values for Hale and Ovok. I suspect this is some sort of a problem with the rescale mod or Sigma Dimensions. Certainly not an OPM issue.
  5. OhioBob
    Are you sure you applied the patch correctly? You should take the text that Leganeski gave you, save it as a plain text file but with a .cfg extension, and then place the file inside your GameData folder. I see no reason why it shouldn't work.
  6. OhioBob
    I've never used any of the replacement stuff, so I don't know how it is supposed to work, or even if it does work. All the replacement stuff is scheduled to be removed from the next GPP version.
  7. OhioBob
    I have no idea. Sorry.
  8. OhioBob
    I also recommend KSPCommunityFixes. It repairs a bug that interfers with the correct placement of ground scatters.
  9. OhioBob
    @SpudNutimus, adding to what Jade said, if you need to reselect your terrain detail settings, be sure to first delete the settings.cfg file in your KSP folder. The next time you start KSP after deleting the file, KSP will rebuild it. You'll have to go into settings and reselect everything.
  10. OhioBob
    Aside from being incompatitble with 0.08+ versions of scatterer, I think SVE still works fine.
  11. OhioBob
    We made Jool green just because stock Jool is green. We didn't try to rationalize it.
  12. OhioBob
    It looks like you're downloading and installing the Kopernicus master. You don't want to do that. You need to use the current release from here: Releases · Kopernicus/Kopernicus (github.com) I wanted to see your GameData with those mods installed so I could confirm that it looked right.
  13. OhioBob
    GEP adds a second star with a big red orbit line circling the stock system. If it is there, you can't miss it. This shows what it looks like: KSP Mods - Grannus Expansion Pack, by Kottabos Games As modus suggested, a screenshot of your GameData folder would be helpful.
  14. OhioBob
    You've done something wrong or else it would be working. But since I don't know what you did, I can't tell you what you did wrong. The installation is pretty straightforward - you just need to make sure the GEP folder is copied into the GameData folder of your KSP install. And, or course, you need to install Kopernicus and its dependencies. At a minimum, your GameData folder should include the following: 000_Harmony GEP Kopernicus ModularFlightIntegrator Squad ModuleManager.4.2.2.dll
  15. OhioBob
    I don't know what that's all about. I have no suggestions for you.
  16. OhioBob
    Try this... 1) Locate and open the file RealSolarSystem/RSS_TerrainDetailPresets.cfg 2) Add the following to the list of presets: PLANET { name = KerbinOcean minDistance = 8 minSubdivision = 1 maxSubdivision = 7 } 3) Save the file 4) Find and delete the file [KSP Folder]/settings.cfg 5) Relaunch KSP 6) Enter Settings and reselect your settings - set textures to RSS_High
  17. OhioBob
    That can be a common problem around very small bodies. But Jupiter's moons are large enough that I wouldn't have expected it. Does the lag go away when in low orbit of the moons? The problem that I'm familiar with is the lag kicks in as soon as a vessel crosses the PQS deactivation altitude (when traveling inward). This can be set to different altitudes for different bodies, but it could be about 100-200 km or so. Initially the lag can be severe, but lessen as you get closer to the body. By the time low orbit altitude is reached, the lag disappears and eventhing is back to normal. Does this sound like what's happening?
  18. OhioBob
    No, it's stock only. But RSS already has realistic atmospheres. I did the atmospheres for RSS years ago.
  19. OhioBob
    I assume you have GPP installed as secondary? It appears that GPP's RemoteTech config fails to disable when GPP is secondary. This is an oversight in GPP. To fix it, I suggest opening the file GPP/GPP_Configs/GPP_RemoteTech.cfg and changing the first line to read the following: @RemoteTechSettings:NEEDS[GPP,!GPP_Secondary] Nodens should be using the stock ground stations.
  20. OhioBob
    Sorry, but I have never seen anything like that before. I have no idea what the cause is.
  21. OhioBob
    I did post some calculations, but that was just free advice to help confirm some of Gordon's numbers. There was no real collaboration between us, and I certainly don't deserve any credit for the mod.
  22. OhioBob
    Explodium Breathing Engines is all @Gordon Fecyk's. I deserve no credit for it.
  23. OhioBob
    Haha. I didn't even know that was there. I think JadeOfMaar wrote that; he uses a lot of food references in his descriptions. Although the planet name has nothing to do with Lindor chocolate, that probably is his inspiration for that.
  24. OhioBob
    Fun fact: While most people seem to associate the Lindor name with the chocolate, the planet is actually named after baseball shortstop Francisco Lindor. Lindor played for the Cleveland Indians at the time JNSQ was made. I briefly considered changing the planet's name after Lindor was traded to the New York Mets.
  25. OhioBob
    With Research Bodies, some bodies are hidden until you discover them. It looks like OPM is configured so that Sarnus is known from the start, Eeloo is known at the easy and normal settings, and everything else in OPM is unknown. I suspect this to be your problem.
×
×
  • Create New...