OhioBob

OK, sounds like I just need to get bettertimewarp. I installed Principia but I don't know if it's working; I don't see anything different. What versions of KSP and Principia are you using?

Mun's orbit is close to that of our real life moon (at 1/4 scale of course), but not exact. Mun is a little smaller than Moon, so its a little closer. Mun's distance was determine by simulating the tidal interaction between it and Kerbin. Kerbin's rotation slows, Mun becomes tidally locked and slowly drifts away, and angular momentum is conserved. I placed Mun at the distance it should be after about 4.5 billions years. Of course that's assuming all the input variables are correct. But generally Mun is about where it should be, and I'm not changing it or else I tamper with the realism of the system. The problem is Minmus. If a realistic and stable orbit cannot be found for Minmus with Mun in its current orbit, then I'll have to find some other solution. One of my problems is that I've never used Principia and have no idea how it works. I don't know how to test the stability of an orbit using Principia.

That's interesting. Making JNSQ work stablly with Principia was a goal of mine. Unfortunately I ran out of time and didn't get a chance to test it prior to release. I had concerns about Minmus, but I feared that placing it too close to Mun would cause its orbit to become unstable. It looks like maybe I overcompensated. Is there anyway you can try decreasing Minmus' orbit until you find something that's stable? If so, I'll change it for the net update. Your help would be appreciated. (edit) Well, it looks like you did what I requested while I was writing that. Unfortunately I don't want to change Mun's orbit. I'd like to find a way to stabilize Minmus without changing Mun.

JNSQ is designed to be a standalone system. We do not recommended its use in combination with any other planet packs.

Mentioned in this thread's opening post is the mod Rational Resources developed by @JadeOfMaar. It is the full evolution of the resource placement engineering project that went into GPP. Rational Resources is part of the core of the JNSQ experience and is easy for other planet mods to employ. Be forewarned, the presence of Ore is reduced even further than in GPP, and creation of certain advanced ISRU chains is encouraged. They are mentioned in the Rational Resources OP. Sunflare of Maar Included in JNSQ is an all-new and exclusive "Sunflare of Maar." Its name is "Esther." It runs in either Scatterer mode or Unity mode (such as Galileo's Flare Replacer mod). To choose which one runs, change the setting in GameData\JNSQ\JNSQ_Configs\SunflareMode.cfg In Unity mode, you have the further option to disable the sunflare ghosts by creating a folder JNSQNoGhosts beside JNSQ. ΔV Map Included in the download, in the JNSQ folder is a ΔV map designed in an all-new "Protractor" style. Concept and numbers by OhioBob, artwork by @JadeOfMaar. Also included is a dark mode version. JNSQ_Rescale Included in the JNSQ download is the optional mod JNSQ_Rescale, enabling JNSQ to be played not only at its native 1/4th real scale, but also 1/10th real scale (≈stock size) and real scale. It also allows the addition of the planet packs GPP and GEP. For a detailed explanation of this mod and the possible play modes that it provides, please refer to the following forum post:

I'll have to take a closer look at it before recommending anything, but it sounds interesting.

@Gordon Fecyk, I don't know anything about Kerbal X, so I made no accommodation for it. MM patches seemed the easiest way to do what I wanted to do.

Which engine gives the most delta-v in a particular application often depends on how much delta-v you need. Delta-v is a function of mass ratio and specific impulse. Using a small engine is going to produce a higher mass ratio than using a large engine. So even if the small engine has a lower ISP, in the right circumstances it can produce more delta-v. But that's often the case only when you don't need a lot of delta-v and you're carrying a small fuel load. When you need a lot of delta-v and are carrying a large fuel load, then ISP is likely more important. A heavy engine in that case will reduce the mass ratio by only a small amount, and the higher efficiency will more than make up for it. So when you're not burning much fuel, mass efficiency is most important. And when you're burning a lot of fuel, fuel efficiency is most important.

Neither of those bodies have an atmosphere. Mun's atmosphere, if it had one, would be so thin that it wouldn't really do much of anything other than produce unwanted effects. For instance, based on Mun's visual configs, I think its daytime sky would likely lose its stars. Furthermore, high speed time warp is disabled in an atmosphere, so a player would be relegated to physics time warp once entering the atmosphere. Having an atmosphere would also create new conditions for science collection, and Mun already generates enough science as is. So I think the cons far outweigh the pros in this case. Eeloo could certainly support a thin atmosphere, and I contemplated giving it one. But I decided not to because of what I consider to be a bug in the way stock parachutes work. If I gave Eeloo an atmosphere, I'd want it to be too thin for parachutes to work. While parachute semi-deployment is a function of atmospheric pressure, full deployment is strictly a function of altitude. So when a vehicle is within X distance from the ground (setting is adjustable, but default is 2500 m AGL for drogues and 1000 m AGL for mains), a parachute will full deploy even if the minimum pressure condition hasn't been met. Since I don't want that, Eeloo doesn't get an atmosphere.

You can, but there's no need to. I use the results as is (a unit vector) and it works just fine. The vector just points a direction, so its scalar value is irrelevant. The elevation of whatever you place at that position is relative to the datum or surface. For example, in the following "position" gives the direction to the object, but "flattenTo" gives the elevation relative to the datum. The datum is defined, of course, by the planet radius. FlattenArea { name = Pyramids DEBUG_showColors = False flattenTo = 1770 innerRadius = 400 outerRadius = 1000 position = -0.7795680037, -0.1133018723, -0.6159841015 smoothEnd = 0 smoothStart = 0 order = 150 enabled = True }

X = COS(latitude) * COS(longitude) Y = SIN(latitude) Z = COS(latitude) * SIN(longitude)

If we call the three numbers X, Y and Z, then Latitude = ASIN( Y / SQRT(X^2 + Y^2 + Z^2) ) Longitude, if X>0 = ATAN( Z / X) Longitude, if X<0 and Z>0 = ATAN( Z / X) + 180 Longitude, if X<0 and Z<0 = ATAN(Z / X) -180 So for the given example, Latitude = ASIN( -3000 / SQRT(157000^2 + (-3000)^2 + (-570000)^2 ) = -0.2907275094 Longitude = ATAN(-570000 / 157000) = -74.60038846 When I work with these numbers I prefer to use unit vectors, i.e. vectors that have a magnitude of one. The magnitude doesn't matter because it just points a direction. In unit vectors we have, 0, 1, 0 --- points to the north pole 0, -1, 0 --- points to the south pole 1, 0, 0 --- points to 0 longitude on the equator -1, 0, 0 --- points to 180 longitude on the equator 0, 0, 1 --- points to +90 longitude on the equator 0, 0, -1 --- points to -90 longitude on the equator

@Tyko, you probably don't need the @ in front of reorientFinalAngle. And you may not need it in front of SpaceCenter either. When editing stock bodies, @ is typically only needed at nodes. And sometimes sub-nodes don't require it. I'm not entirely clear on when it's needed and when it's not. I know for sure @Body is needed. Try the following variations and see if either works: @SpaceCenter { reorientFinalAngle = -15.399612 } SpaceCenter { reorientFinalAngle = -15.399612 }

Yeah, KSC is not exactly on the equator. According to the Kittopia dumps, reorientFinalAngle = -15. You can probably just tweak that.

@Tyko, based on its vector position (position = 157000,-3000,-570000), KSC's coordinates are -0.290728 latitude, -74.600388 longitude. That's KSC "center", which is actually a point on the crawler way just a little east of the VAB.

I don't know what you mean exactly. The formula is for launches from Kerbal Space Center, no place else. If you want an orbit with zero inclination, then you launch due east*. If you want to launch into an orbit that has an inclination i, then you have to launch along a heading that is north or south of due east by an amount equal to i + c, where c is a correction to account for Kerbin's rotation. The formula computes the value of i + c. It doesn't make much sense to do it any other way. * This is exactly correct because KSC isn't exactly on the equator. But it's close enough not to split hairs over.

There is no in-game UI for Kopernicus. For KittopiaTech it's Ctrl + P. Regarding KittopiaTech not working... do you have scatterer installed? KittopiaTech won't open for me when scatterer is installed.

@utopein, I explain it a couple posts earlier. The heading that my formula gives is the angle relative to due east. So you would launch in a direction due east +/- the heading angle.

I never even comtemplated BetterSRBs working with RealFuels. I'm not very familiar with RealFuels other than generally what it is. Without looking at it, I have no idea how to make it work.

I'm afraid I know nothing about ksc++. That was all done by the other guys on the team. I also don't use it. Hopefully one of the other guys can shed some light on the problem.

I think so, but I haven't tried it. There's no reason the two mods can't work together, it's just a matter of sequence. We want Sigma Dimensions to do its thing after Realistic Atmospheres, so that the ReScale changes are applied to the new atmospheres. I think that's the case, but I can't swear by it. No harm is done in trying. Just install both mods and check the heights of some of the atmospheres to make sure the changes have been appropriately applied. With both Realistic Atmospheres and 3.2x ReScale installed, Eve's atmosphere should be 84 km, and Duna's should be 105 km. If that's what you're getting, then all is good.

My suggestion, make a backup of your save, then try it and see what happens. Orbit { mode = icon = } mode is the orbit line and icon is the planet marker. For mode the options are OFF, REDRAW_ONLY, REDRAW_AND_FOLLOW, REDRAW_AND_RECALCULATE. For icon the options are NONE, OBJ, OBJ_PE_AP, ALL. I think you can also use numbers; for instance, mode =0 and icon = 0 means OFF and NONE. I'm not certain what all those options do, but REDRAW_AND_RECALCULATE and ALL appear to be the defaults for the stock bodies. I believe you must have an icon to be able to target a body.

@iGGnitE's problem is more than just a camera issue. In his top image the scatterer effects aren't even rendering.

I don't think it's a camera issue. I had the problem because I failed to add flatScaledSpaceModel = True to the celestial bodies in planetsList. Fixing that oversight solved the problem. Here's an example of what it should look like:

I think that should work, but I can't guarantee it. Just copying the GPP_Scatterer and GEP_Scatterer folders from the new version to the old will probably work. If it doesn't work, you should be able to revert back to the old configs without any harm being done to your save. If you're using either GPP_Secondary or GEP_Primary, then there may be additional scatterer files in those folders that will also have to be copied over.