OhioBob

Just for Eve. The use of Eve Optimized Engines isn't recommended because of the scale of the system, it is because of the high atmospheric pressure on Eve.

As @Galileo said, there are no plans to make JNSQ compatible with other planet packs. But that just means the JNSQ devs will not be adding such support. It doesn't mean it's not possible. If somebody is motivated enough to give it a go, there's no reason there couldn't be unofficial third-party support at some point in the future. Our resistance to add official support is not because we are unsensitive to your request. It is simply because providing compatibility for other planet packs adds layers of complexity that we want no part of. We went down that rabbit hole with GPP and the configs needed to make sure everything worked together correctly (for instance, scatterer) ended up being a convoluted mess. We decided early on that we are not going to repeat that mistake. We'd rather put our energy into making JNSQ as good as we can make it, and not spend countless hours trying to make it work with some other planet pack. Yep, that's a misprint. I'll fix it. Thanks.

To see clouds you need to download and install EVE from the following: https://github.com/WazWaz/EnvironmentalVisualEnhancements/releases That's just the EVE plugin, it doesn't come with any configs. JNSQ includes all the configs you need. You should just have the following folders in your GameData: EnvironmentalVisualEnhancements JNSQ If that's all you have, then you should be seeing JNSQ's clouds. Some earlier versions of EVE included configs that you could install separately, but you don't want those. Those came in a folder named BoulderCo, so if you have that folder delete it. You also don't want to have installed anything like StockVisualEnhancements.

It looks like all the essential files are there, but I do see a couple potential issues. First, you have two ModuleManager files (4.02 and 4.03). I don't know what problem that may cause, but you should delete one. I also see a GameData folder inside your GameData folder. I have no idea what that is. You probably need to delete it. Other than that, I don't really see anything that looks unusual. If you still have problems, I recommend removing all mods except for those required specifically for JNSQ, and then test it. Minimum requirements are: JNSQ Kopernicus ModularFlightIntegrator Squad ModuleManager

You've must have installed something incorrectly. Can we get a screenshot of your GameData folder?

I'll look up what I have and I'll get back to you. We can continue the conversation in Discord.

What ISP are you using for those? I did a bunch of calculations of NTRs several years ago with different fuels, including ammonia and methane. I can probably look up those numbers if it would help.

Anything is possible if you mod the mod. But SVT doesn't come with an option to do what you ask. You'd have to do it yourself.

Yes, it is principally due to the low gravity. The low gravity causes the atmosphere to expand because it is under less compression. But Tekto is also very cold, so that increases the air density and cause the atmosphere to contract. After considering both gravity and temperature (and molecular weight), we end up with a 95 km atmosphere. Tekto is a Titan analog. In real life Titan's atmosphere extends for hundreds of kilometers, so Tekto's atmosphere is not that unusual. https://en.wikipedia.org/wiki/Atmosphere_of_Titan#/media/File:Titan's_atmosphere.svg

Just look at the planet info in the Tracking Station.

Theoretically, yes. But I don't know how KSP handles "infinity". Perhaps there's a hard limit at some point?

I've never experienced your first issue, so I have no answer for that. Regarding your second question, as far as I know, they are in slow orbits. As I understand it, everything orbits around one central body, typically the Sun. However, not long ago Kopernicus introduced the ability to use custom orbital periods, so perhaps they can be put into a fixed position by setting the orbital period to 0. I don't know of any mods that actually do that, however. (edit) It just occurred to me that setting the orbital period to 0 is going in the wrong direction. To effectively fix a body's position, the orbital period would have to be set to an insanely large value.

The config I gave, assuming I did it right, should turn them off everywhere, including the map view and tracking station. Turning them off, however, means you can't click on and target the planet. As I recall, I think you just need the icon to target a planet. So you could try turning off the orbits lines (mode = OFF) and keeping the icon as is.

@jpinard, install Kopernicus and try this: @Kopernicus:FINAL { @Body,* { @Orbit { mode = OFF icon = NONE } } } mode draws the orbit line and icon is the dot showing the planet position.

@DeclanTheDarkest, if your craft is falling back into the atmosphere before completing the circularization burn, then it is likely your circularization burn is taking too long. One way to decrease the duration is to use a higher thrust-to-weight ratio, as Vanamonde suggests. Though I suspect the better strategy is to try to reduce the size of the burn. You've given us little information to go on, but I'm guessing the problem is likely in the trajectory that you are flying. My suspicion it that you are lofting the rocket into a steep arc with a very large circularization burn. There are two problems with this: (1) the duration of the burn is long, and (2) the time you spend near the top of the arc is brief. My suggestion is that during ascent you pitch the rocket over more aggressively and fly a flatter trajectory. Make the arc of your flight path as long and as flat as possible, without being so flat that your craft is overcome by drag. Doing so will decrease the size and duration of the circularization burn. You will also spend much more time near the apex of the trajectory and outside the atmosphere. This should allow you to complete the circularization burn with ease. This type of trajectory is also more efficient fuel-wise. It will take some practice to perfect the technique, but you'll get there.

With a major rewrite, probably. It's never going to happen though unless you do it yourself.

I've done some more investigating and I think the ideal switchover point between EOE engines and stock sea-level engines occurs somewhere between about 2 and 2.5 atmospheres, or roughly 8 km altitude. That's were the stock engines generally begin to be more efficient that the EOE engines.

That's correct. This mod's engines are intended only for use near sea level and the initial climb through the lower atmosphere. After you've climbed to higher altitude, you should switch to stock engines. You'll have to decide what works best, but you may want to consider staging through three types of engines: Stage 1 - Eve Optimized Engines (for 5 atm) Stage 2 - Standard sea level boosters (for 1 atm) Stage 3+ - Vacuum engines. Eve's atmospheric pressure drops to 1 atm at about 14.6 km, so that's about where you'd want to make the switch from stage 1 to 2.

I've never had that issue, so I don't think it is JNSQ.

I have do idea when the next release will come. People have made changes but I've heard no discussion about releasing an update. Maybe there's something we're waiting on that I'm not privy to. You can try downloading the master from the GitHub repo ( https://github.com/Galileo88/JNSQ ). As far as I know it should work.

Give us a screenshot of your GameData folder.

I've completely loss track of what the current status is. I'm as confused about what is going on as you are. Maybe @Galileo or @JadeOfMaar can give us an update.

Writing a Sigma Dimensions config is easy. You might have missed it, but I just edited my previous post to show you how.

Do you mean you want to make JNSQ 3.2x compared to stock size, or do you want to make JNSQ 3.2x larger than it currently is? In either case, it would probably be easiest to use Sigma Dimensions, though you'll have to write your own config. I don't recommend using Rescale because it is designed to scale up stock sized systems, and JNSQ is not stock sized. If you want JNSQ to be 3.2x compared to stock, you might try this: @SigmaDimensions { @Resize = 1.2 @Rescale = 1.2 }

You can do whatever you want if you write a config for it. Be advised, however, that we don't provide support for user modified versions of JNSQ. Also note that JNSQ Duna is a completely different planet than stock Duna. Those stock textures may not work at all on our version of Duna.