Jump to content

OhioBob

Members
 View Profile  See their activity

  • Posts

    3,934

  • Joined

  • Last visited

 Content Type 

Everything posted by OhioBob

  1. OhioBob
    Yes, it shrunk. I redid the atmospheres in one of the more recent updates. General properties are unchanged, however.
  2. OhioBob
    That's what I use as well. There was a time when it wasn't compatible with Kronometer, but that was years ago. Of late I've had no issues.
  3. OhioBob
    From what I can tell, we can't mix stuff that's configured for v0.0772 with stuff that's configured for v0.0830. It would have been nice had Scatterer included backwards compatibility so that stuff configured for the old version still worked with the new version, but that doesn't seem to be the case. A planet pack that's updated can no longer be used with one that's not updated, and vice versa. It's an unfortunate situation.
  4. OhioBob
    In Sigma Dimensions, the "Resize" parameter changes the size of the celestial bodies, and the "Rescale" parameter changes the size of the orbits. In the config you provide, both Resize and Rescale are set to 2.5, so both planets and orbits should be changed by that factor. SOIs are calculated by KSP based on the new masses and orbits of the celestial bodies. But if everything is resized/rescaled by 2.5, then the SOIs should be changed by the same amount.
  5. OhioBob
    If it works for me, it ought to work for you. You're likely doing something wrong, but I can't guess at what it might be.
  6. OhioBob
    It works fine for me.
  7. OhioBob
    Not at this time.
  8. OhioBob
    I thought it was, but I see now it isn't. I'll have to update that.
  9. OhioBob
    @Graploos, @flart, @eberkain, @caipi: I'm not sure what all the problem is here, but just to clarify something... JNSQ uses a 12-hour day (and a 365-day year) only if Kronometer is installed. Kronometer is the mod that allows changes to the clock/calendar. I would have thought that most other mods would have been updated by now to be compatible with Kronometer, but perhaps not. If anyone is having a problem with mods displaying times that don't match, the best thing to do might be to uninstall Kronometer. Without Kronometer the game should revert to stock 6-hour day, 426-day year. This means that the clock/calendar won't match the movements of the JNSQ home world (i.e. the planet will still rotate once every 12 hours), but at least all mods will probably display the same time and be consistent. I know nothing about Graploos, so I can't help you there. However, in stock KSP you have only the 6- and 24-hour options. Only with the mod Kronometer can this be changed. JNSQ is configured to give a 12-hour day when Kronometer is installed.
  10. OhioBob
    I'm not ready to say we've found the solution yet, but let's keep our fingers crossed. Let me know if it continues to work or if the bug reoccurs. To others who have reported this problem, you might want to give this possible solution a try and see what happens.
  11. OhioBob
    There's one thing you might try. Delete the file settings.cfg from your KSP folder and restart the game. This will force you to reselect all your game settings. Then see if the problem still exists and report back. This may not do anything, but the last GPP version made some changes to the terrain detail settings. Perhaps not deleting the old file is creating an issue. It's worth checking to either rule it in or out as a cause.
  12. OhioBob
    Nothing official at the moment, though @Coldrifting has release his version of updated JNSQ scatterer configs, which you might try. I haven't used them, however, so I can't vouch for them. JNSQ is designed to work with scatterer v0.0772. I don't recommend any other version.
  13. OhioBob
    @CessnaSkyhawk, as I understand it, you're proposing distributing configs that alters JNSQ after the fact without actually changing JNSQ directly and redistributing it. In other words, players would download and install JNSQ intact as it currently exists from the Team Galileo JNSQ GitHub. They would then download and install your configs, which would make changes to JNSQ but without redistributing any of JNSQ's original components. If that is correct, then I see no problem with that.
  14. OhioBob
    Form the RAD thread... For all the planet packs that I have been involved in, it hasn't been dealt with at all. I've never had the need or desire to use contract packs, so I've never paid any attention to them. I've just assumed that the programming necessary to distinguish land from water was included on the contract side of things. If it becomes necessary to add a config to the planet packs to remedy this situation, that shouldn't be a problem. I don't want to be the one to figure it out, however.
  15. OhioBob
    I can provide insight regarding JNSQ if necessary, but otherwise I don't know much. What's CC?
  16. OhioBob
    Rational Resources includes a GPP config, so it might already support GPP. @JadeOfMaar is the person who can confirm this.
  17. OhioBob
    I just wanted to clarify that when I said OPM won't work with JNSQ, I didn't mean that OPM won't load. OPM will probably load OK if installed with JNSQ, but the OPM planets will be to the wrong scale and their orbits will be intermixed with the JNSQ orbits. For instance, Sanus will orbit between Dres and Jool, and Urlum will orbit between Jool and Lindor, etc. It would be a totally screwed up system. So I suppose it's more accurate to say that OPM won't fit JNSQ. To get a proper fit, OPM would need to be modified.
  18. OhioBob
    It must orbit Sun, not Kerbol. Kerbol is an unofficial name coined by fans of the game, it does not exist in KSP or JNSQ. The main central body around which everything orbits is named Sun, though it could have a different display name.
  19. OhioBob
    No, the code is built into Kopernicus. Yes, find the following file and change the extension from .txt to .cfg. DART/Plugins/RespawnDimorphos.txt // How to reset and respawn Dimorphos: // Simply rename this file from .txt to .cfg // Then restart KSP and either load your test save or create a new one. // Every time that you go to the Space Center, Dimorphos will be recreated. // To stop that from happening, exit KSP and rename this file from .cfg to .txt
  20. OhioBob
    No, OPM does not work with JNSQ. The only planet packs, to my knowledge, that have been modified to work with JNSQ are GPP and GEP (all by the same developers). However, these planet packs are added to the JNSQ universe as secondary star systems. There is nothing that adds planets to the JNSQ solar system. That being said, there's no reason configs couldn't be written that would make OPM compatible with JNSQ. However, JNSQ and OPM really aren't a very good fit stylistically.
  21. OhioBob
    What is not compatible with Kerbalism - RemoteTech or JNSQ? If you are referring to JNSQ, that's not true. JNSQ is compatible with Kerbalism. You may well be right about RemoteTech's compatibility, however. I wouldn't know about that.
  22. OhioBob
    I'm not sure how to whitelist or blacklist stuff, but the following ought to work. The following example is assuming you're using 2.5x Rescale, though the method would be the same for all sizes. Inside the GameData/Rescale 2.5x folder you will find a file named 2,5xScale.cfg. Edit this file to read as follows: What the first part does is adds a DoNotRescale tag to all the planets that you want to exclude from rescaling, where PlanetPackName is the name of the planet pack and PlanetName# are the names of all the planets included in that planet pack. Add as many @Body nodes as necessary include all the planets. The second part changes Rescale from applying its rescale parameters globally to making them planet specific, and those planet specific changes are applied only to those planets that exclude the DoNotRescale tag.
  23. OhioBob
    Although Gordon has apparently based his explodium burning engines on ethane as the fuel, it's unlikely that "explodium" is actually ethane. The environmental conditions on Eve wouldn't allow liquid ethane to exist on its surface. However, heavier hydrocarbons such as dodecane (C12H26) could exist as liquids. Heavier hydrocarbons of this type are found in kerosene, i.e. rocket fuel. Where enough of these hydrocarbons would come from to fill seas, however, I don't know. Another issue with Eve's oceans is that the liquid has a specific gravity of 1.5, which is much heavier than any common hydrocarbons. Dodecane, for instance, has a specific gravity of 0.75. So, given the known properties, there's really no logical way to explain what explodium is or how it got there. We just have to suspend disbelief and take on faith that it exists.
  24. OhioBob
    The Voronoi Craters biome doesn't exist on Moho. The biome name appears in the config, but it doesn't actually exist in the biome map.
  25. OhioBob
    @Thomot512, Kerbin's atmospheric model is based on the U.S. Standard Atmosphere. The only adjustments the KSP developers made were to convert geopotential height to geometric height, and then multiply all the heights by 0.8 to lower the top of the atmosphere. Here you can find the atmosphere curves used by Kerbin: kittopia-dumps/Kerbin.cfg at master · Kopernicus/kittopia-dumps (github.com) And here you can find an explanation of what all the curves do: For an alternative model, you can use this mod: Realistic Atmospheres bases Kerbin's atmosphere on this model of Earth's atmosphere developed by the U.S. Air Force: Standard & Reference Atmospheres.pdf (braeunig.us) It is very similar to the U.S. Standard Atmosphere (as you would expect since they both model Earth) but is more complete in that it has multiple models for different latitudes (the U.S. Standard Atmosphere is centered on 45o N as I recall). The atmosphere curves used by Realistic Atmospheres can all be found within the mod's config files. Realistic Atmospheres also remodels all other atmospheres in KSP to be more lifelike.
×
×
  • Create New...