OhioBob

I did originally, but I soon thereafter revised it.

Yes, but @simonh apparently didn't see it. @TheRagingIrishman was just responding to somebody else who apparently skipped over my post.

The Science Relay mod already does it. When you get the result of an experiment, there is the normal transmit button, which transmits to Kerbin, and a second transmit button for transmitting between vessels. Clicking the second button brings up a list of vessels to which you are connect via the CommNet and which are capable of storing science. Select the vessel and the science is transmitted. Normal transmission losses are incurred, but only once. There is no further loss for subsequent retransmission.

Why yes it is, my mistake. I know we had it in there at one time, then it wasn't, and now it's back. I guess I just got a little confused. I remember now why we don't have Hox-Argo set up as binaries - because it's pretty boring and we decided not to bother. If anybody wants to, however, all they have to do is find the file Argo.cfg and paste the following in at the very end. @Kopernicus:NEEDS[SigmaBinary&!RemoteTech]:BEFORE[SigmaBinary] { @Body[Argo] { SigmaBinary {} } } It looks like it was RemoteTech that created the conflict, because the above is configured to work only if RemoteTech is not installed. If you have both RemoteTech and Sigma Binary installed, the Sigma Binary stuff won't work. You'll have to make a choice between those two mods.

To create planets you must install the mod Kopernicus and write a configuration file for the new planet. The following gives some of the basics on how to use it. It's a start. Creating textures is the hard part, at least for me it is. There are probably some tutorials in the forum, but I can't think of a good one at the moment. Kopernicus also allows you to delete bodies. For instance, I think the following will delete all bodies. @Kopernicus:AFTER[Kopernicus] { !Body,* {} }

We had Hox and Argo configured for that at one time. We also had Gauss and Catullus configured as binaries. To enable it all you had to do was install Sigma Binary. But it was removed for some reason because it was suspected of causing a problem. I think there might have been a conflict with the Research Bodies mod, but I don't really remember. I never experienced the problem myself, but I recall others complaining about it. Perhaps one of the other guys can elaborate.

Science Relay, Version 4.1 (on Spacedock)

I suggest you start here:

[x] Science! has two different windows. One is opened by clicking the "X" icon, and the other in opened by clicking the icon with the waypoint symbol. The latter brings up the small window that provides the science alerts.

You're welcome. Sometimes it doesn't matter where you place a file, but at other times it's crucial. The only thing in GPP that I'm aware of that doesn't require a specific location are the resize configs. Those you can put anywhere in the GameData folder, which I believe is stated in the instructions. But something like the textures are referenced in the planet configs by a specific path. If the files are not where they're suppose to be, they won't be found and the install will fail. Anytime you see a "GameData" folder inside a mod download, you should copy exactly the contents of that folder to the GameData folder of your KSP installation. And when you have a problem, checking that everything is in the right place is probably the first thing you should do.

The folder GPP_Textures must be inside the folder GPP. Just move that folder to the correct place and it should work. Also delete ModuleManager.2.8.1.dll. Clearly you didn't EXACTLY follow the instructions. If it works for everybody else but you, then it's a pretty good bet that you're the one who did something wrong. The GPP folders and files must be installed into your KSP installation using the exact same file structure as found in the download (this is typical of all mods). In the GPP_Textures.zip download, the file structure is, GameData\GPP\GPP_Textures You installed GPP_Textures incorrectly by placing it in GameData\ rather than GameData\GPP\. If you decide to install any of the optional mods, please be careful to put the folders and files in the correct location.

@Slasher, 1) Create a fresh install of KSP version 1.2.2. 2) Launch KSP once with no mods installed, then close. Must launch in 64-bit. 3) Download GPP version 1.2.3 from GitHub. 4) Drill into the downloaded file and find the folder GameData. 5) Copy the contents of this GameDate folder to the GameData folder of your KSP installation. 6) Step 5 must include the following folders and files: GPP\ Kopernicus\ ModuleFlightIntegrator\ ModuleManager.2.7.6.dll 7) Do not download the above separately; you must use the versions included in the GPP download. 8) Download the file GPP_Textures.zip from GitHub. 9) Drill into the downloaded file and find the folder GameDate\GPP\GPP_Textures. 10) Copy the folder GPP_Textures to the GameDate\GPP\ folder of your KSP installation. 11) Launch KSP. If you follow the above steps correctly, GPP should work. After you have it working, you can then install any of the optional mods or other mods that you want to use.

If all you're trying to do is take drag into account, then you should only need density. If there's a way to get density without temperature and pressure, then I don't see any reason to get temperature and pressure.

I just remembered that I included the updated temperature equation in this thread. The equation is, Temperature = currentMainBody.atmosphereTemperatureCurve.Evaluate(altitude) + atmosphereTemperatureOffset * currentMainBody.atmosphereTemperatureSunMultCurve.Evaluate(altitude) where, atmosphereTemperatureOffset = currentMainBody.latitudeTemperatureBiasCurve.Evaluate(latitude) + currentMainBody.latitudeTemperatureSunMultCurve.Evaluate(latitude) * sunDotNormalized + currentMainBody.axialTemperatureSunBiasCurve.Evaluate((float)currentMainBody.orbit.trueAnomaly * Mathf.Rad2Deg) * currentMainBody.axialTemperatureSunMultCurve.Evaluate(latitude)) + currentMainBody.eccentricityTemperatureBiasCurve.Evaluate((float)((currentMainBody.orbit.radius - currentMainBody.orbit.PeR) / (currentMainBody.orbit.ApR - currentMainBody.orbit.PeR))) I believe the pressure equation should be, Pressure = currentMainBody.atmospherePressureCurve.Evaluate(altitude) And finally, Density = pressure * 1000.0 * atmosphereMolarMass / (PhysicsGlobals.IdealGasConstant * temperature)

@MusicalHQ, it looks like you're computing Kerbin's atmospheric temperature, pressure, and density using an equation from the KSP Wiki and this web page. I'm actually the guy who wrote that part of the Wiki and the reference web page. It looks to me like the code you've written will work, but the downside is that is only works for Kerbin's stock atmosphere, nor does it account for location. You probably want a more universal way of doing it that will work with any planet or atmosphere. KSP computes temperature and pressure using animation curves. A couple years ago @NathanKell told me how the curves are evaluated. I'm not a computer programmer so I don't necessarily understand it all, but perhaps you will. This is what he told me: The temperature equation above is outdated because there were additional curves added about a year ago. I can probably go through my notes and construct an updated equation, but I don't want to bother unless it is something you need. If the above is something you can use, please let me know and I'll figure what changes are necessary.

I think we all understand it was a joke (at least I did). But I've never found that a reason not to have a engineering discussion.

As I recall, the problem was that jet engine thrust and specific impulse were incorrectly based on the total mass flow of both fuel and air, while it should have been based on just the mass of liquid fuel. The fact that only the fuel is counted is why real life jet engines have Isp so much greater than rocket engines (which must carry their own oxidizer). I think the engines had a air-fuel mixture ratio of something like 16:1. Let's say that based on the thrust and Isp it is calculated that the fuel flow rate of a jet engine is 1.7. If done correctly, that would mean that 1.7 units of liquid fuel is consumed, and 1.7*16 = 27.2 units of air. But the way Squad did it, they said that 0.1 units of fuel and 1.6 units of air were consumed. So jet engines burned only 1/17th as much fuel as they should have.

I'm not familiar with SolverEngines. I played around briefly with Real Fuels over a year ago but uninstalled it. Real Fuels is pretty cool for realism junkies, but it complicated things too much for my taste.

I had this same issue once before, where I wanted a thin atmosphere but a black starry nighttime sky. I tried several things but was never able to figure it out. No matter what I did, when daylight came the stars disappears and I got a lighted sky. I eventually gave up and deleted the atmosphere. Of course that was several versions of Kopernicus ago, so maybe things have changed. What happens if you try this...

I don't know all that much about Vanguard, but I feel pretty confident that nothing had parachutes or heat shields. And the link you provided says about the second stage "This stage contained the complete guidance and control system." This is also shown in the illustration, labeled "Inertial Reference System". One thing you'll probably not be able to exactly replicate in your recreation is that the first stage includes hydrogen peroxide in addition to the kerosene fuel. I'm sure the hydrogen peroxide was used as a monopropellant to drive the engine's turbopumps. The kerosene is the fuel burned in the combustion chamber and ejected out the nozzle to produce thrust. You'll just have to assume that your mass of liquid fuel includes both kerosene and hydrogen peroxide. I believe the X-405 first stage engine was gimbaled to provide steering. I don't believe the AJ10-118 second stage engine was gimbaled, but I don't know for sure.

I don't think @Rocket Farmer is talking about performing a straight up launch (correct be if I'm wrong). I think he's suggesting using a normal, mostly horizontal ascent, but timing the launch so that launch and ejection can be performed all in one continuous burn; as opposed to burn-pause-circularize-pause-eject. In theory, he's correct, one could save a small amount of delta-v by using that technique. However, I think the potential savings is so small that's it's not worth it. A flawless Mun transfer is a lot easier to execute from a parking orbit, but far be it from me to tell people how to have fun.

I assume you mean apoapsis burn, i.e. the burn performed at apoapsis to circularize the orbit on a typically launch and orbit insertion? You don't actually save that delta-v. All the apoapsis burn does is raise the periapsis on the other side of the planet, which you are still doing. It's just that you're doing it all in one burn rather than pausing and then completing the burn when you reach apoapsis. The only advantage to performing the Mun transfer in one shot is that you're performing the ejection burn while at a lower altitude. The exact savings depend on the circumstances, but a quick back of the envelope calculation tells me you might save in the neighborhood of 30 m/s. But then again, much of the Mun transfer will be performed in the upper atmosphere, so that added speed will produce greater drag loses. Your actual savings might be less. Mun it not in the perfect position you think it is. The old rule of thumb it that you preform the transfer burn just as you see Mun rising over the horizon, but that's from orbit. You have to realize that having Mun on the horizon when observed from the surface of the planet is not the same as having Mun on the horizon when in an 80 kilometer orbit. When in orbit you're seeing far beyond the horizon that can be seen from the surface below. When an observer at sea level sees Mun on the horizon, an observer 80 km overhead will see Mun 28 degrees above the horizon. So if you launch when Mun is on the horizon at the launch pad, you've waited too long.

@Z-Key Aerospace, I have a question/problem that I want to run by you. In Galileo's Plant Pack we have a couple of planets that have oceans, but not really. The oceans are subsurface and are only there so that we can use HazardousOcean to produce excess heat. It is not our intent that the planets actually have oceans; i.e. no one is suppose to see or even be aware that they're there. However, when in the Tracking Station the Selected Object information window is showing that the planets have oceans. Is there anyway to block or hide that? [x] Science is doing its job and detecting the oceans, but in this case we don't want it to.

Adding to my previous post... The difference in true anomaly, Δν, between the current location and where the orbit intersects the ground is the angular distance the vehicle will travel along its current heading until touchdown. If you know the coordinates of the sub-vehicle point and the heading, you should be able to compute the landing site. Just move Δν degrees from the sub-vehicle point in the direction the vehicle is moving and you're there. If you want to know the linear distance rather than angular, it's πRΔν/180, where R = radius of planet. So if you know semimajor axis, eccentricity, current altitude, heading, and sub-vehicle point, it should be solvable. I think all of those are given by KER and MechJeb, so hopefully you have access to them. If you don't know one or more of those, then you're going to have to figure something else out. I also agree with @Spricigo. Ask those who have already figured it out.

Even without drag, it's still not easy. Do you know the semimajor axis and eccentricity of the lander's orbit (even though it's suborbital, it's still an orbit)? If so, what I would probably try doing is compute the lander's true anomaly at its current position, and its true anomaly intersecting the planet's surface. True anomaly can be computed using equation 4.43. From that there is probably a way to compute the location of the landing site in relation to the lander's current position. Unfortunately I have no idea what the solution is off the top of my head.