OhioBob

We're going to stipulate that it be used with new games only. We're not going to take any responsibity for, or provide support for, existing saves.

I haven't tested GPP with OPM since the early days, but I assume nothing has changed. As far as I know, everything should still work as detailed in this post: The latest release of GPP may not work in 1.7.2 however. We list the minimum version as 1.12.1, so no support will be provided for older KSP versions.

The game clock is set to Universal Time, not local time. It may be sunrise at KSC but it's noon on the zero meridian, hence 6:00 UT. It's equivalent to KSC being located in New Orleans but having the clock set to Greenwich Mean Time.

May I presume you plan to play JNSQ at 10x scale (real scale)? I know what SMURFF is and what it supposedly does, but I have never used it. Therefore, I can make no recommendation about its use. PartRebalancer10x is just one simple config that you install. It primarily does two things: (1) increases the density of some propellants, and (2) decreases the mass of most parts. The changes bring mass fractions in line with what we find in the real world so that parts are well balanced for 10x scale. PartRebalancer10x works well with all stock parts and it should work with most part mods. However, some of the part changes refer to parts by their "EngineType" and/or "category". So if a mod changes or creates a new EngineType or category, then the part changes may not be correctly applied. For instance, a mod alters the categories under which parts are found in the VAB or SPH may break PartRebalancer10x. Also a mod that puts parts in unexpected places, like putting "Aero" parts under "Structural", may produce unplanned results. PartRebalancer10x presumes that everything is stockalike. On the other hand, if you plan to play JNSQ at its native scale (1/4 real scale, or about 2.7x stock), then you don't need to do anything. Both stock parts and mod parts should work perfectly fine at this scale, though it will obviously be more difficult than stock scale (which is, of course, the whole point). If I'm not mistaken, I believe the creator of BDB tests his parts in JNSQ and balances around it (at least that's what I've heard).

Physics-wise nothing will change (orbit, size, gravity, etc.), but there will definitely be changes to the planets' terrain and appearance. I haven't forgotten about the Toutatis discussion, but I'm not sure yet if that will be something I'll try to implement or not. I haven't really thought much about the added bodies, I've mainly been thinking about the original bodies and how much I can improve them. The added ones are probably not going to change much.

I'm planning a big cosmetic update to GEP. GEP was done years ago, and they were the first planets I had ever done. So it's time to give them a makeover.

No, but delta-v is proportional to the square root of the rescale factor. So 10x scale is 4x bigger than normal JNSQ. Therefore, you can use the delta-v map that comes with JNSQ and multiply the values by SQRT(4) = 2.

I just tried to reproduce the problem in sandbox testing, so I have no idea what I had installed. I haven't actually played a game in probably a year. That's possibly the reason I haven't been able to reproduce the problem. If it has something to do with contracts or milestone, etc., I haven't experienced any of that. That's what makes this so hard to track down. I'm not going to sit here and play the game for hours in the hope that the bug might occur, and then hope that I can figure what's causing it. What I really need is a bug report that can tell me how to produce the bug without fail by following a specific set of steps. But one somebody says it happened when they completed some contract, that is so specific to their particular game and setup that there is really nothing I can do to reproduce those specific circumstances. What also has me baffled is that there wasn't anything changed in the last release that would make me think it might be the source of the problem. It was all pretty standard stuff. I just don't know what to do about it.

Thanks for the report. Other than myself, I've only heard from a few people that say they haven't had problems. But that's not surprising considering most who come here do so because they've had issues. Those who haven't probably don't bother to read my posts. The fact that some people have had this problem and other haven't makes it even more perplexing as to what the source of the problem is. (FYI, GPP has not been updated since the problem was first reported.)

The stock asteroid generator should work just fine with Stock + OPM. Stock asteroids spawn near Kerbin and Dres, so as long as those bodies exist in their stock locations, stock asteroids will appear as intended without any problems. Where you run into problems using the stock generator is when the stock solar system is reconfigured or replaced. When planet modders start moving planets around, or deleting and adding planets, they likely want asteroids to spawn in new locations. That's when they need to use the Kopernicus asteroid generator.

Although the settings you reference are from the current version of JNSQ, they produce bad results. At someone else's request, I've changed the settings to the following, which should be much better. JNSQ hasn't been updated with the change, however. I have no idea why you are getting class F, unless that's an addition to the stock game that I'm unaware of. MyRocksAreBiggerThanYours is a plugin that allows the placement of Breaking Ground surface features (like the Baobab trees on Kerbin). Doesn't have anything to do with asteroids.

GPP doesn't do anything that I know of to make asteroids bigger. Could you be thinking of JNSQ? JNSQ increases the size and mass of asteroids, but not GPP. GPP deletes the stock asteroids and creates its own asteroid belts, but that's all. You should continue to see regular stock-sized asteroids.

I don't know how the SENTINEL telescope works; I've never used it. But as far as asteroids in JNSQ are concerned, they appear in several places but only the main belt between Duna and Jool is visible without first reaching the area where they spawn. I'm not exactly sure what qualifies as "reached", but that's how it's set up. When I tested the asteroids, I just needed to put a vessel in orbit near where they spawn, and eventually they started to appear. I didn't need a telescope, so I don't know what's up with that. Be aware, however, that Kopernicus asteroids are a bit bugged. They work, sort of, but not really the way they should. As new areas are discovered, asteroids begin to spread out in all the discovered areas, so the density goes down. At least that's the way it was the last time I tested. I don't think anything has been done to fix it, though the Kopernicus dev knows about the problems. It's apparently not an easy fix. (edit) Here's some additional information that might be helpful. Once the maximum number of asteroids has been reached, they'll stop spawning. New ones won't spawn until an old one despawns. Therefore, when reaching a new area, you may have a long wait before asteroids begin spawning there. Asteroids in JNSQ's main asteroid belt are set to live between 475 and 950 hours. That's "untracked" lifetime. Tracked asteroids live forever.

UPDATE Version 1.2.8 Changelog Fixed Rescale mods to resize Nodens' SOI. DOWNLOAD

Well, crap! You're right, I missed that. I guess another quick update is needed. Thanks for bringing this to my attention.

I've never actually traveled to Grannus when installed as a secondary system. I just never got that far when playing GPP+GEP. The only times I've explored the Grannus system was with it installed as primary. I think it's a pretty fun system to play that way - different than most other things I've played.

@bigyihsuan, @Rodger, the current version of GPP will likely not receive any further updates or patches. I'm working on a much bigger revamp of GPP that will replace the current version.

Yes, the stock surface features have been reused and scattered about on the GPP planets and moons. No special accommodation has been made for it, but since I don't know anything about GU, I don't know. We're planning to remove the renamer in the next update.

UPDATE Version 1.2.7 Changelog Increased Nodens' SOI to 26,000 km (now completely contains Belisama's SOI). Fixed Grannus' sunflare for GEP_Primary. This update includes a couple of fixed that I've been sitting on and forgot to release. Sorry for the delay. DOWNLOAD

Are you using Realism Overhaul or some other part rebalancer. Because if not, stock parts are way too heavy for RSS. You need to do something to rebalance the parts for real scale. If you are not currently using anything, below is a very simple rebalancer that I made. It's nothing like Realism Overhaul, but it is a way to get started and should let you get to orbit. https://www.dropbox.com/s/ro5zb12tszg905r/PartRebalancer10x.zip?dl=0

At this point in time, there are no plans to make any further updates to JNSQ.

If you need help with something, we're going to need more information than that.

Are you being serious?

If you're using JNSQRealDate.cfg for something other than JNSQ, it's not going to work. This mod is made specifically for JNSQ. KSRSS would require its own customizations. And you're right, we should be talking about it in this thread.

That's correct, offsetTime just changes the start time. In JNSQ we offset the time because of where KSC is located (-91.8 longitude). Without the offset, the game begins at 0:00 UT when it's sunset at KSC. But by offsetting 6 hours (the day is 12 hours long), the game starts at 6:00 UT when it's sunrise at KSC. (Kronometer just changes the clock. To change from sunset to sunrise, we also had to rotate the planet 180 degrees.) To change the length of the day you need to do one of two things. First, you can use %useHomeDay = true. This makes the length of the day equal to length of the home world's day. The other thing you can do is the following, where you can custom set the length of the day to whatever value you want it to be (in seconds). @Kronometer:AFTER[modName] { @CustomTime { @Day { value = 27000 } } } For a complete list of all the possible customizations and syntax, see here: Kopernicus/Kronometer: A mod to manipulate the clock for Kerbal Space Program (github.com)