Jump to content

OhioBob

Members
 View Profile  See their activity

  • Posts

    3,934

  • Joined

  • Last visited

 Content Type 

Everything posted by OhioBob

  1. OhioBob
    Blockiness can indeed be an issue at times with heightmaps. Other than doing what you can with the heightmaps, as you already are, the only other things I can suggest are, (1) reduce PQS maxLevel, and/or (2) add some low-level PQS height noise. The lower the maxLevel, the more rounded and less blocky the terrain becomes. In some ways it makes the terrrain look worse and less interesting, but it can be very effective at reducing blockiness. (Reducing maxLevel also reduces scatter density, so you may have to compensate.) Adding PQS height noise doesn't do anything to remove blockiness, but it can help obsure it and make it less noticeable.
  2. OhioBob
    Are you sure it's not just loading an outdated mesh from cache? If you haven't already done so, delete the .bin files for the planet pack you are running. These are typically in a cache folder inside the planet pack folder, or if not there, inside the Kopernicus folder.
  3. OhioBob
    If anyone has had an issue with the surfaces of celestial bodies in JNSQ turning bright colors, there is a solution. These colors were used for debugging back when JNSQ was first developed and are meant to be turned off. But a recent change to Kopernicus has switched the colors back on as a means to fix something else. So by fixing one problem, it created another. The remedy is to remove the colors by installing the below patch. Just copy the following into a plain text file, save it with a .cfg extension, and place the file anywhere inside your KSP's GameData folder. @Kopernicus:FINAL { @Body,* { @PQS { @Mods { @LandControl { @landClasses { @Class,* { @color = 0,0,0,0 @noiseColor = 0,0,0,0 } } } } } } }
  4. OhioBob
    Both GPP and GEP have optional rescale mods, and both must be installed. Have you done that?
  5. OhioBob
    Did you install this?
  6. OhioBob
    That's very strange indeed. I see nothing in the KSRSS configs that would make Earth in KSRSS substantially different than Kerbin in JNSQ. I have no explanation.
  7. OhioBob
    No, I did it that way because the real life asteroid designations use a letter to indicate the month of discovery. However, in real life it is by half months, so 24 letters are used (I and Z are excluded). I was born in the second half of May, so that is represented by the letter K. Therefore, if an asteroid were discovered on the day of my birth, the first part of its designation would be 1958 K. The next letter of the designation represents the sequence of discovery during that period. For example, the fourth asteroid discovered during the second half of May 1958 would have the full designation 1958 KD. 25 letters are used to indicate the sequence (I is excluded because it can be confused for the number 1). If more than 25 asteroids are discovered in a period, we cycle back to the beginning and add a number at the end to indicate how many times we've cycled through the letters. So suppose we are the 29th asteroid discovered that period (asteroids weren't being discoverd at that rate back in 1958, but humor me). We cycle back to the letter D, but now the designation becomes 1958 KD1. I use RAB-58E because it looks like a Kerbal designation, but the 58E is also a simplified version of the real life naming system.
  8. OhioBob
    Although it's a mouthfull, I usually pronounce it by simply reading off all the letters and numbers... "R, A, B, fifty-eight, E". Here's some trivia for you... RAB-58E is actually named after me. RAB are my initials, 58 is my birth year (yes, I'm old), and E (the 5th letter) refers to the month of my birth (May, the 5th month).
  9. OhioBob
    That's a Kopernicus issue. Those colors were included in GPP for debugging back during development. They are suppose to be turned off, but for some reason in the more recent versions of Kopernicus they are being activated. The fix is to remove the colors, the below patch should do it. Just copy the following into a plain text file, save it with a .cfg extension, and place the file anywhere inside your GameData folder. @Kopernicus:FINAL { @Body,* { @PQS { @Mods { @LandControl { @landClasses { @Class,* { @color = 0,0,0,0 @noiseColor = 0,0,0,0 } } } } } } }
  10. OhioBob
    Thanks for the information. I have suspected for some time that GPP is not the root cause of this problem. So while your experience is certainly not proof of this, at least I now know that the problem is more widespread than just GPP.
  11. OhioBob
    Also make sure that when starting a new game you delete settings.cfg in your KSP folder. You'll have to reselect your settings the next time you start KSP. The last release of GPP made some changes to terrain detail presets. So by not reselecting your terrain detail in the settings, it could possibly cause a problem. I'm not sure it has anything to do with the crashes, but let's make sure.
  12. OhioBob
    @Leganeski, have you installed Kopernicus' MultiStarSolarPanels.cfg? It's required for multi-star support. Just download it from the Kopernicus GitHub and install it into the Kopernicus/Config folder.
  13. OhioBob
    I can't recall if there was a specific reason why we did it that way or not. It's possible we (meaning me) just didn't think it through enough. I have a similar situtation in GEP were a planet that would normally be tidally locked to its star is instead tidally locked to a large moon. I'll have to investigate this further, and if I agree with your findings, I'll change it. I'm currently working on a GPP update, so adding this change will be easy.
  14. OhioBob
    Has anybody had any luck getting the disabling of the maneuver tool to stop your game freezes/crashes?
  15. OhioBob
    Thalia is sneaky that way. Sorry you had the find out the hard way.
  16. OhioBob
    I didn't realize your apoapsis was increasing. (That's my fault for not watching the video.) I don't know what's happening in that case, clearly something glitchy. You might try asking about it in the RSS thread, maybe it's a known issue that other RSS players can explain.
  17. OhioBob
    That's not to be expected that high up in the atmosphere. Even though you are inside the atmosphere, gravity is still accelerating your vessel toward periapsis. The vessel is subjected to drag forces, but in the thin air of the upper atmosphere, the deceleration produced by drag is much less than the acceleration produced by gravity. Therefore your vessel wil continue to pick up speed (but not as much as it would if there were no atmosphere). It is not until you descend deeper into the atmosphere that drag begins to dominate over gravity and your vessel's speed will actually begin to decrease. It is not an uncommon occrrence. Jupiter's surface gravity is about 2.4 times greater than Saturn's, therefore its atmosphere is much more highly compressed. Saturn's atmosphere, on the other hand, is more extended because of its lower gravity. Although Jupiter's atmopshere is not as tall, it is much more dense and more massive than Saturn's.
  18. OhioBob
    GEP has not been updated for any of the scatterer 0.08+ versions. Whether or not there are any issues when using recent versions of Scatterer, I don't know. I haven't done any testing since the first 0.08+ version was released.
  19. OhioBob
    Certainly, please post away.
  20. OhioBob
    That would probably be a yes. I've never used Ad Astra, but I see no evidence that the creator ever intended it to be used with GPP and GEP.
  21. OhioBob
    For those who may have read my previous post shortly after posting it, please note that additional instructions have been added.
  22. OhioBob
    For those who have reported game freezes and crashes, I may have gotten a lead on a possible cause. I've been informed that there is a bug in the stock maneuver tool that can cause intermittent freezes when changing spheres of influence (and at other times as well). I can't be certain this is what you have been experiencing, but it sounds likely. Regrettably, this is a stock bug and there's nothing we can do to fix it. However, the mod KSP Community Fixes includes the option to disable the stock maneuver tool, which may eliminate the problem. Instructions: Download and install KSP Community Fixes and its dependencies. Launch KSP and load your saved game. Press ESC and select Settings. Scroll down to KSP Community Fixes. Click the button next to "Maneuver Tool" to disable. Click Accept to save changes and exit.
  23. OhioBob
    It starts out with some standard settings, which may or may not work. It then tries to improve on those settings with each successive launch. Eventually it will zero in on settings that will achieve an efficient gravity turn. (Of course you must have a rocket capable of achieving orbit. Gravity Turn can make up for a bad design.)
  24. OhioBob
    There's nothing bugged, we just made the planets too dim. I think what happened is we increased the semi-major axes of the planets without checking to make sure the intesity curves still worked with the new distances. Try replacing the curves in GPP_OPM.cfg with the following: These curves should give results like we originally intended. The planets are still not really brightly illumated, but it should be much better than before. If you want them brighter still, I recommend that you decrease the semi-major axes to move the planets closer to the star. Here is a long-winded explanation of why the planets are placed where they are if you are interested:
  25. OhioBob
    Robau's Star is part of GPP. Its configs can be found in the file GPP/GPP_Configs/GPP_OPM.cfg. If you want to increase the amount of light the star emits, you would need to adjust IntensityCurve, ScaledIntensityCurve, and IVAIntensityCurve. Or, alternatively and likely easier, you can move the planets closer to the star by decreasing their semiMajorAxis. I was not aware the OPM planets were so dimly light by Robau's Star. This is something I will look into and adjust for the next release. Thanks for shedding some light on the issue.
×
×
  • Create New...