Jump to content


  • Posts

  • Joined

  • Last visited

Everything posted by OhioBob

  1. JNSQ does not work with OPM, so that's not an option. First off, JNSQ is built to a different scale (OPM is stock size while JNSQ is 1/4 real scale). And while JNSQ is based on the stock solar system, it also adds several new bodies. In total there are 30 planets and moons in JNSQ, while stock plus OPM gives a total of 31 (with JNSQ actually having more bodies that you can land on). So the large number of bodies really makes it unnecessary to add an OPM-like expansion pack. The usual complaint that I hear is that there are too many similar looking "grey" moons, but that's matter of personal opinion. It doesn't take long to install it, so perhaps you can do so and just take a quick look at the planets to see if you like it or not. If you find it uninspiring, you can easily uninstall it and try something else. I don't recall the shoreline issue necessarily being something unique to JNSQ. I know little about Ad Astra as it is by a thrid party, and I've never used it. I am planning a revamp of GPP (and GEP). I've actually completed most of it, but I hit a wall where I just needed to step away from it and take a break. Once the motivation to continue returns, an updated version will be released. Unfortunately I have no particular timely table for when that will happen. Hopefully before the year is over, but I make no guarantees. I've never played KSRSS, but it looks interesting. Unfortunately right now I don't think you can even download it. The mod dev is in the process of revamping it, and it's my understanding he has removed the download link until the new version is available. Based on what I've read, the revamp includes changes to the scale of the system (with 1/4 and 1/9 real scale versions). No word on when the revamp will be completed. If you still can't decide, something else you can do is install JNSQ and GPP together. JNSQ will be the primary system, while GPP can be installed in its secondary mode as a secondary star system. While JNSQ and GPP are built natively to different scales (JNSQ 1/4 real scale and GPP 1/10 real scale), optional mods are provided to rescale one or the other so they can be played together. You can either make JNSQ smaller or GPP bigger, depending on what you prefer. You can even add in GEP if you'd like. Of course, if the idea making the long journey to a neighboring star system doesn't appeal to you, then this really isn't an attractive option.
  2. Are you looking for something that replaces the stock solar system, or something that adds to it? Because every replacement pack is almost certain to have a habitable home world to replace Kerbin. As far as planet packs that add planets and (possibly) stars, I am only familiar with a few of them. One of the oldest and still active planet packs is OPM, though it doesn't add any habitable planets. Two of the planet packs that I've been a part of - Galileo's Planet Pack (GPP) and Grannus Expansion Pack (GEP) - can both be installed as either a primary system (i.e. replaces the stock solar system) or as a secondary system (i.e. adds a secondary star system). GPP adds two habitable planets (Gael and Tellumo), and GEP adds one (Nodens). All three of those planets are roughly 50% water with oxygen atmospheres. If GPP is installed as the primary system, Gael is the home world, and if GEP is installed as primary, Nodens is the home world. GPP and GEP can also be installed together, with either one being the primary system, and the other being the secondary system. Or they can be installed along side the stock solar system, forming secondary and tertiary star systems.
  3. This had been asked and answered. Read the thread.
  4. Something is definitely not right, but I don't know enough about either KSRSS or Principia to offer any advice. My only experience with Principia was to install it with my own planet packs just long enough to see if there were any unstable orbits. I don't recall if there were any tricks in getting it to work. I do remember that that it's necessary to start a new game, it won't work with an existing save.
  5. To get Principia to work, you just need to install it. No config is necessary. Of course that doesn't mean all the orbits will be stable. For instance, in JNSQ some of the moon orbits became unstable with Principia installed. That is, the moons would be ejected out of their initial orbits into interplanetary space. So when we say JNSQ includes support for Principia, we just mean that some of the orbits had to be modified to assure stability. These changes are included in the body configs rather than in a Principia config. As I recall, the bodies that include changes are Mun, Minmus and Bop. If you look in Minmus.cfg, for example, you'll see two different values for semiMajorAxis, one without Principia installed - NEEEDS[!Principia] - and one with Principia installed - NEEDS[Principia]. Probably all you need to do is install KSRSS with Principia and inspect it to see if everything works and is stable. If so, then you won't need to do anything. If not, you'll need to make whatever modifications are necessary to keep bodies in their orbits. It is my understanding that Principia can also do axial tilt, which I suppose it probably does for RSS. The axial tilt portion of Principia is something I know nothing about, so I can't advise you about that.
  6. I don't know what [x]science is, so I can't comment on that. "removePQSMods = PQSMod_VoronoiCraters" would only remove craters from the template, if there actually were any. But Moho doesn't use that mod, so you'd be removing something doesn't exist to start with. I don't fully understand the problem, but you probably should delete the biome from the config. Try deleting this part from Moho.cfg: Biome { name = VoronoiCraters displayName = #LOC_JNSQ_Biome_VoronoiCraters value = 1 color = #916991 }
  7. Multiply by the square root of 2.5.
  8. I've thought about writing a patch that would do it. But I don't have the time right now. Perhaps something for the future.
  9. Perhaps you should delete ModuleManager.ConfigCache. The cache will rebuild the next time you launch KSP.
  10. Why don't you ask the makers of Wanderer's Planet pack why their mod isn't working?
  11. I still don't know where the 5130 m/s number comes from, but looking at the KSRSS delta-v maps I see that they give 3400 m/s for stock size, and 5375 m/s for 2.5x. I think where the 5375 number comes from is, 3400*SQRT(2.5) = 5375 m/s. While it is true that delta-v goes up by the square root of the rescale factor, this is really only true for transfer trajectories between bodies, such as going from Earth to Mars. For a launch from the surface of a body to low orbit, this method tends to overestimate the delta-v required. This is because, although the planet is 2.5 times larger, we're typically not launching into an orbit 2.5x higher. For instance, say we typically launch into an 80 km orbit at stock scale. At 2.5x we might increase this to 100 km to get above the higher atmosphere, but we don't start launching into a 200 km orbit just because the planet got 2.5x bigger. Also, drag losses do not get appreciably greater just because the planet got bigger. So while multiplying by SQRT(Rescale) is a quick and easy way to convert delta-v, in this case it yields a very conservative result.
  12. Axial tilt is not possible in KSP. But while the axes can't be tilted, the orbits can. So what RSS does to give Earth's axis a ~23.5-degree tilt relative to its orbit is to incline the entire ecliptic. This gives Earth the correct tilt, but it also gives all the other planets approximately the same tilt as Earth. This is just a limitation of KSP and there is nothing that can be done about it. It's possible to give any one planet the correct tilt, but then all the others are wrong. In RSS, Earth is the correct one, which obviously makes the most sense.
  13. In addition to the fix on the Kopernicus GitHub, it is also posted in this thread three posts above yours.
  14. I've been able to manage 4800 m/s in JNSQ as well, though not every one of my rockets can do it. 4900 m/s is a more reasonably attainable number, thus it's what's on the delta-v map. It's been awhile since I last played, but I seem to recall budgeting about 5100-5200 m/s for early career rockets.
  15. We commonly say JNSQ is 2.7x stock, but it was actually made to 1/4 real scale. That is, the JNSQ solar system was designed at real scale and then scaled down to 1/4 size. I place stock at about 1/10.6 to 1/11 real scale depending on what dimension or property we're looking at. If we call it 1/10.8, then that makes JNSQ about 10.8/4 = 2.7 times stock. So that's where the 2.7x comes from, but it's only approximate. In reality, none of the body radii are scaled directly from stock. I scaled the celestial bodies based on mass, not size. I then selected what I thought were realistic densities and computed new radii from mass and density. Where does the 5130 m/s number come from? Is that RSS at 1/4 scale? The 4900 m/s number for JNSQ was determined in game through repeated launches. I find it to be pretty close for rockets made from 2.5-m parts and larger. The 1.25-m parts tend to be less efficient. This is likely because the small parts have a lower ballistic coefficient and, therefore, more drag loss. For these smaller parts, >5000 m/s is pretty common. 5130 m/s sounds reasonable in that case. As far as rotation speed goes, the faster rotating the body, the less delta-v the rocket takes to get to orbit (assuming we are launching in the direction of the rotation, i.e. east for most bodies). So if Kerbin in JNSQ is rotating faster, then that too could account for some or all of the difference.
  16. JNSQ dosen't do anything to parts but for a couple small exceptions. The LV-TX87 and LV-T91 engines have their thrust, mass, and cost increased slightly (25% for the 87 and 20% for the 91). This is because these engines are intended to power a Titan II analog rocket to lift the Mk2 command pod + service module to orbit. At JNSQ scale, we believed these engines where a little unpowered for that task, so we gave them a buff. We also changed the AtmosphereCurve for a couple Karbonite Plus engines from Umbra Space Industries. I'm not sure what that's all about, I'm not the one who did it.
  17. @linuxgurugamer, I might be getting confused with something else, but I kind of remember talk about adding some custom anomalies. Perhaps the stock anomalies were removed with the intent that they'd be replaced. But further development of JNSQ has pretty much come to a halt, so custom anomalies are a dream that will probably never be realized. If I ever release an update, I'll consider bringing the stock anomalies back.
  18. It looks like the Kraken has been removed too. It would normally appear on Bop, and has the name DeadKraken.
  19. I have no list, but it looks like you've already figured out how to find out what's been removed. Just open the configs and look for something like, removePQSMods = PQSCity[UFO]. If you were to edit out that part of the config, I suppose the anomaly would come back, though I'm not sure if it would work in an existing save. Galileo wrote that part of the configs, so I don't know what he had in mind when removing the anomalies. I do know that the planets weren't construction with accomodation of the anomalies in mind. Perhaps he just felt that the terrain at the location of the anomaly was unsatisfactory. I can only guess at the reasons. That part I don't understand. All my prior experience with monoliths is that they snap to the terrain. No idea why this one is doing otherwise.
  20. The UFO has been removed, as have many anomalies. I'm not sure why.
  21. For the 140 km Kerbin atmosphere, the hard-coded one would be better. That atmosphere was designed from the beginning to be 140 km, so its temperature curve, etc. follows a realitstic Earth-like profile all the way to the top. The Sigma Dimensions atmosphere only has information up to 87.5 km, so above that it is just extrapolating from the last known information. For instance, as I recall, it uses the last known temperature throughout the extrapolated region. However, now that we know atmoTopLayer is actually working, you can use it to modify the atmospheres of other planets.
  22. @Strych74, I think this apparent Sigma Dimensions bug is a false alarm. While it's true the MM cache is showing only the changes produced by atmosphere, it appears that atmosTopLayer is actually working in game. For instance, I ran a test using using atmosphere = 1.25 and atmoTopLayer = 1.6, which should give us a Kerbin atmosphere with a height of 140 km. The curves we see in the MM cache only shows them stretched out to 87.5 km, and not extrpolated out to 140 km as they should be. But when I load up the game and place a satellite in orbit within the 87.5-140 km region, it encounters atmospheric drag. The Aero GUI is also indicating air pressure in this region. So while the MM cache leads us to believe that atmoTopLayer is not working, in game testing shows that it actually is.
  23. That works out nicely because when resizing a solar system, orbital periods change by the sqaure root of the rescale factor. It would actually be better if KSRSS were resized to 1/4 real scale rather than 2.5x stock. At 1/4 real scale, all the orbital periods would be SQRT(1/4) = 1/2 what they are in real life. So if the rotation periods are then also factored by 1/2, the years when measured in days would be exactly the same as they are in real life. Earth's year would be 365 12-hour days, and so on. 2.5x stock scale is is a little smaller than 1/4 real scale, so that's why you are getting orbital periods that are a little less than their real life values. This is one of the main reasons the JNSQ mod was made to 1/4 real scale. The math just works out so nicely. In fact, if I were to make a stock-ish like version of RSS, I would probably make it 1/9 real scale rather than stock size. The difference between 1/9 scale and stock isn't all that much, but 1/9 scale is so much better mathematically. The orbital periods at 1/9 scale are exactly 1/3 real life. So if we give Earth an 8-hour day, all the orbital periods again equal their real life values when measured in days.
  • Create New...