OhioBob

@linuxgurugamer, it has been discovered that there's a conflict between this mod and BetterSRBs. I don't know enough about how these mods interact to cite the specific cause, but the issue is described here and here. BetterSRBs adds a module to the modified SRBs. I've found that adding this module to your blacklist removes the conflict and allows BetterSRBs to work alongside KRnD. Would you consider adding the following to your blacklist? BLACKLISTED_MODULE = ModuleTweakMaxResource If you can find a better solution I'm certainly willing to entertain it. But blacklisting the module seems to be the simplest solution.

I've confirmed everything you've been saying. I'm seeing the exact same issue. I don't know enough about KRnD to know what specifically is causing the problem, but I believe I've found a solution. Open the following file: GameData/KRnD/PluginData/blacklist.cfg and add the following to the list of blacklisted modules: BLACKLISTED_MODULE = ModuleTweakMaxResource That should fix the issue by preventing KRnD by doing anything with the SRBs modified by BetterSRBs. There may be a better solution but I don't know what it is.

I know nothing about Kerbal Research and Development. I'll take a look at it to see if I can figure out what's going on.

@jimmymcgoochie, I've never seen that happen before. Even though the slider shows 100%, I've always had the correct fuel mass on the launch pad. I have no idea what could be causing it to revert to full. If you can isolate which combination of mods are at fault, I can look into it further to see if I can find a solution. I typically don't use very many mods myself, so I don't often run into these types of conflicts.

The current version of GPP should work in 1.9.1 as soon as Kopernicus updates to 1.9.1.

I remember seeing and hearing about this issue at least a year ago. It's not new, and it's not unique to GEP. (edit) Here's a report on it happening in GPP from almost two years ago. https://github.com/Galileo88/Galileos-Planet-Pack/issues/47

The slider shows full on the launch pad, but the mass of propellant is what you set it to in the VAB. For instance, let's say a SRB holds 1000 units of solid fuel. You turn the slider down to 50%, decreasing the fuel load to 500 units. When you send the SRB to the launch pad, the fuel slider will show 100%, but you have only 500 units of fuel on board as intended. This is not normal behavior for stock KSP, but it is for BetterSRBs. It is necessary that KSP thinks the SRB is fully loaded with fuel or else the thrust curves won't work properly.

The current version of GPP works fine in 1.8+, only without the new shaders. If and when we update, it will probably be for whatever the most current KSP version is at the time of release. Whether or not it will be backwards compatible with previous versions remains to be seen. It's impossible to say at this point in time.

Are you talking about the oceans turning red during reentry? It's my understand that it's a stock bug. I don't think it has anything to do with GEP.

The last of Poodmund's concerns should be whether or not somebody else can open his textures.

I had nothing to do with Realistic Atmospheres' submission to CKAN. I haven't the foggiest idea how any of that works. But typically I don't like putting a max version on my mods. Most of my mods don't require updating when a new KSP version comes out. So putting a max version on them just means that anybody using the mod is going to get an error saying its incompatible with the new version even though it is actually perfectly fine. So either everybody gets an error message for something that's not really an error, or I have to release an update just to change the version number on something that otherwise doesn't require updating. It's easier just to not put a max version on it. And technically Realistic Atmospheres is compatible with 1.9.1, it's its dependency (Kopernicus) that's not compatible.

No it doesn't. It says it's 1.8.1 compatible. Though it should work fine in 1.9.1 once Kopernicus updates.

Sorry, no work around. To use Realistic Atmospheres in 1.9.1, you'll have to wait until Kopernicus updates for 1.9.1. Please don't pester the Kopernicus devs about it. They're working on it and an update will be released when it's ready.

@GEPEG_Unconscious, yes, it's still in the pipeline. The problem is that I just need a little break from KSP. The motivation to work on it will return eventually. What little I've done so far looks pretty good.

I honestly have no idea what's there and what's not. Aside from Nodens, anomalies is something I just didn't pay any attention to when making GEP. All bodies use removeAllPQSMods = True, which I think removes anomalies, but I'm not sure. If any anomalies exist, they would have been inherited from the template, which in most cases is Moho.

Nodens in GEP_Primary should have most of the same anomalies found on Kerbin. Nothing moved, so they should be located at the same coordinates that they are in the stock game. There were a couple monoliths that I deleted because they ended up underwater, but everything else should be there.

That's something I may try to remedy in a future release. I didn't know much about anomalies when I first made GEP, so I left them out. I'm not extremely motivated to make changes at the moment, but I'll probably get around to it eventually.

As I understand it, yes. Any game intended to be played using Principia has to be started after installing Principia. Principia makes changes to the game that are incompatible with non-Principia saves. However, if you're referring to my config to make JNSQ think Principia is installed, then I think you should be OK installing it mid-game. Any vessels orbiting Minmus should stay with Minmus after it moves.

No problems that I can think of. Note that Mun's orbit changes slightly too for Principia users. As well as Bop's orbit, which becomes retrograde. There's also a trick you can use to force the Prinicipia changes to take effect in JNSQ without actually installing Principia. Create a folder in GameData named Principia, and place the following config into it: @Kopernicus:FOR[Principia] { } That will make JNSQ think there's a mod named Principia installed, so it will make all the Principia related changes without you having to edit any configs.

There is no currently existing map that has all the biomes identified in an easy to read format. But all the data is available in the game if you want to create one for yourself. The biome map can be found here, JNSQ/JNSQ_Textures/PluginData/Kerbin_biome_8K.png (beware that it is flipped horizontally). And the biome names and colors can be found in JNSQ/JNSQ_Bodies/Kerbin.cfg (the colors are hexadecimal). It's very unlikely that's going to happen.

Orbit should definitely be possible with 5000 m/s, but it's going to depend on the design of the rocket. I've had some early game rockets that have taken more than 5200 m/s, and some later bigger rockets that have taken less than 4800 m/s. Also the trajectory flown can make a big difference. A poorly flown rocket can probably add a couple hundred m/s. All I can tell you is to keep practicing at it and try to get better with your designs and piloting. You'll eventually be able to do it for less than 5000 m/s, but in the meantime you may just have to add extra.

I don't know anything about the NFX, but the JX2 shouldn't be able to reach Nara without a boost of some type. The JX2 with no boost has a maximum range of 500 Gm. With either the 4x DSN boost or the 4x Range boost, but not both, the JX2's maximum range is extended to 1000 Gm. And with the 4x boost to both DSN and Range, the JX2 can reach 2000 Gm. Nara's closet distance to Kerbin is 1075 Gm, its mean distance is 1838 Gm, and its maximum distance is 2772 Gm. (Those min-max distances are calculated through the first 500 years of the game.)

If you want to edit the curve so that the shape is the same but it has a maximum value of 1, then just divide the last three numbers of each key by the maximum value found in the second column. In the example provided, the maximum value in the second column is 1.2418, so dividing through by that we get, thrustCurve { key = 0 0.08053 0 28.185 key = 0.03 0.64503 0.6120 0.6120 key = 0.61 1 0.6120 -0.4993 key = 1 0.8053 -0.4993 0 } To compensate for the lower thrustCurve multiplier, you would need to multiple maxThurst by 1.2418.

@GEPEG_Unconscious, I have to admit that I really don't know that much about RationalResources. I've never actually played a game using it. But as far as resources go, GEP has it's own custom resource configs. I've distributed resources around in a quasi-realistic way. That is, you'll find more rocky and metallic resources on the inner planets, while these are far more scarce on the outer planets. On the other hand, the cold outer planets will have more stuff like water, methane, and ammonia frozen into their icy crusts. I'm not sure how this works with RationalResoruces. It's my understanding that RR has no GEP specific configs. So I believe GEP's resource configs will govern resource distribution even with RR install, but I'm not sure about that. If so, then I think you'll be in good shape without having to do any special configuration of RR. Perhaps @JadeOfMaar can enlighten us on how it works. GEP has been tested with and works in Principia. The only instability in the normal settings is the orbit of Belisama (it's too close to Nodens' SOI and gets pulled from it's orbit). There's a config that moves Belisama to a smaller orbit when Principia is installed. Nodens rotation period is also reduced.

In the case of Toutatis, yes. At least it would be if Toutatis were in a perfectly circular and non-inclined orbit. Because of libration the coordinates of the subsolar point changes a little bit, but the mean is 0, 0. However, 0,0 does not automatically become the coordinates of the subsolar point for a tidally locked body. It's the case for Toutatis because I made it so. All the tidally locked bodies in GEP have their prime meridians facing the primary. That's because I carefully selected the initialRotation of each body to place it in the correct orientation. I derived a formula for it, initialRotation = longitudeOfAscendingNode + argumentOfPeriapsis + meanAnomalyAtEpochD - 180