Jump to content


  • Posts

  • Joined

  • Last visited

Everything posted by OhioBob

  1. 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.
  2. 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.
  3. 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.
  4. @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.
  5. 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.
  6. I can provide insight regarding JNSQ if necessary, but otherwise I don't know much. What's CC?
  7. Rational Resources includes a GPP config, so it might already support GPP. @JadeOfMaar is the person who can confirm this.
  8. 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.
  9. 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.
  10. 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
  11. 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.
  12. 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.
  13. 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.
  14. 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.
  15. 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.
  16. @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.
  17. Supposedly, yes. There's a config for it. I'm not familiar with RemoteTech, so I don't know. Hopefully somebody with some RemoteTech experience can answer.
  18. @OrbitalManeuvers, I just ran a test and everything worked as expected for me. No problems. What version of JNSQ/TweakChutes are you using? JNSQ v0.10.1 came bundled with TweakChutes v0.3.0. JNSQ v0.10.2 upgrades to TweakChutes v0.3.1. If you're using the older version, perhaps that's the problem. If so, try replacing the TweakChutes in the JNSQ_Plugins folder with this one: Release Sigma TweakChutes v0.3.1 · Sigma88/Sigma-TweakChutes (github.com)
  19. That's normal in the stock game. Parachutes will full-deploy when reaching the height setting regardless of whether the minimum pressure condition has been satisfied or not. This is one of the things that TweakChutes was specifically designed to correct. I'm going to run some tests now to see what happens on my end.
  20. @OrbitalManeuvers, your problem doesn't really sound like it's JNSQ or TweakChutes related, but I won't rule it out just yet. It might be interesting to remove TweakChutes to see what happens. To do so, just temporarily remove the folder JNSQ_Plugins. I haven't had a chance to do any testing on my end yet. That does make sense if you had the altimeter set to height above terrain. Drogues should semi-deploy at an altitude of about 7000m above sea level. But if you were flying over terrain with an elevation of about 2500m, then they would semi-deploy at 4500m above the ground. And since you are already inside the 5000m height for full deployment, they would immediately inflate.
  21. I've never seen that before. If the pressure is high enough for the parachutes to deploy, they should inflate when they reach the height setting. I know of nothing in JNSQ that would stop that from happening. JNSQ does use a plugin called Sigma TweakChutes that changes parachute behavior, but it shouldn't affect parachutes in the way you describe. In stock KSP, parachutes will immediately deploy and inflate when reaching the height above terrain that you have set in the parachute slider even if the minimum deployment pressure has not yet been reached. TweakChutes stops this from happening. With TweakChutes a parachute will never deploy until the minimum pressure has been reach, and it will not inflate until both the minimum pressure and the altitude has been reached. This is why main parachutes won't deploy on Duna because the minimum pressure is never reached. Drogue parachutes, however, should deploy once descending below an altitude of 7068 meters where the air pressure is equal to 0.02 atm (assuming you have them set to deploy at that pressure). Once deployed, there should be nothing stopping them from inflating when you've reached the set altitude above terrain. I suppose it's possible that the latest version of KSP has produced a bug in TweakChutes that could be causing this. I doubt it, however, because in the past TweakChutes has been pretty immune to KSP updates. I should check it to be certain.
  22. The minimum pressure for the parachutes is in units of atmospheres, while the pressure displayed by the PressMat Barometer is in units of kilopascals. 1 atmosphere equals 101.325 kPa, so to convert kPa to atmospheres, divide kPa by 101.325. So in the particular screenshot provided, the pressure displayed in the PressMat is, 3.3237 / 101.325 = 0.0328 atm. The minimum pressure to deploy drogue parachutes is 0.02 atm, so since 0.0328 atm is greater than this, the drogues have deployed. But the minimum pressure to deploy main parachutes of 0.04 atm has not been reached, therefore the main chutes have not deployed. In JNSQ the maximum surface pressure on Duna is 0.04 atm, therefore main parachutes should never deploy. (In practice they might deploy a second or so before impact, but too late to really do anything.) This is by design. We don't want main parachutes to work on Duna to make landing on Duna more Mars-like. That is, one can use drogues to slow and stabilized the vehicle, but propulsion will likely be needed to slow the vehicle enough for a soft touchdown.
  23. UPDATE Version 1.2.6 Changelog: Added DeployedScience config. EVE fixes to improve compatibility with GPP. This mod is not compatible with Scatterer v0.0825b, please use v0.0772. DOWNLOAD
  24. UPDATE Version Changelog: Added DeployedScience config. EVE fixes to improve compatibility with JNSQ. This mod is not compatible with Scatterer v0.0825b, please use v0.0772. DOWNLOAD
  25. UPDATE Version 0.10.2 Changelog: Added DeployedScience config. Updated TweakChutes to v0.3.1. This mod is not compatible with Scatterer v0.0825b, please use v0.0772. DOWNLOAD
  • Create New...