• Content count

  • Joined

  • Last visited

Community Reputation

1878 Excellent

About OhioBob

  • Rank
    Junior Rocket Scientist

Contact Methods

  • Website URL http://www.braeunig.us/space/

Recent Profile Visitors

9229 profile views
  1. Alter the mean anomaly at epoch. That's the variable that tells us where a satellite is in its orbit, it's mean anomaly, at the specified epoch. Mean anomaly is measured in radians, where 360 degrees = 2*pi radians. So let's say you want to space four satellites out 90 degrees apart, place them at mean anomalies of 0, 1.5708, 3.1416 and 4.7124, making sure the epoch is the same for each.
  2. If I were you, I'd just do a complete GPP reinstall.
  3. Mechjeb or Something Else?

    I don't know which mod does the best job because I don't use them all, so I don't have a basis for comparison. However, I sometimes use Gravity Turn. It allows each new launch to learn from the prior one to eventually zero in on a very efficient ascent. I think it does a pretty good job.
  4. Command Moduels...

    You don't need a "command pod" on everything, only on stuff that will carry a crew. The answer as to why you need one should be pretty obvious, the Kerbal needs a habitat with life support and all the controls and instrumentation needed to fly the ship. For vessels not carrying a crew we need a "probe core". The probe core is the brains of the spacecraft. In real life every spacecraft requires on onboard computer (often referred to as the command and data subsystem) that is overall responsible for the management of the spacecraft's activities. It maintains timing, interprets commands from mission control, collects, processes and formats telemetry data, and manages fault-protection and safing routines. I've always presumed that the probe core is the spacecraft computer.
  5. If you're a probe guy, then maybe you should try this... I've seen several threads like this, and the thing I've noticed about tech trees it that that everyone has an opinion and nobody's opinion is the same. Somebody will come along and argue that "it's just common sense" that the tree should be arranged in some particular fashion. The next guy will come along and say the same thing but will propose something completely different. If it were so obvious that the tree should be arranged in some specific way, then everybody would agree, but they don't. It's all depends on a person's particular style of play, and there's nearly are as many different styles as there are players. That's why I proposed you consider rearranging the tree yourself. The chances that there's an existing tech tree out there that does exactly what you want is probably remote. If a particular tree doesn't look the way you think it should, that doesn't make it wrong, it just makes it different.
  6. [1.3.1] Kopernicus (Release 3) - Nov. 30

    Although that may be generally true for most mods, Kopernicus is version locked. It simply will not work if the versions don't match. This is by design.
  7. [1.3.1] Kopernicus (Release 3) - Nov. 30

    Just be sure that the Kopernicus version number matches the KSP version number. For instance, if you're using KSP 1.3.1 then you must use one of the 1.3.1-x Kopernicus versions. It won't work if the version numbers don't match.
  8. [1.3.1] Kopernicus (Release 3) - Nov. 30

  9. I think the intended use of the Dart is probably for a SSTO. The real advantage of an aerospike is that it gives good performance over a wide range of ambient air pressures, i.e. both sea level and vacuum. This advantage isn't all that obvious in stock KSP because the delta-v requirement to get to orbit is so low - we're not really penalized much for using a different type of engine. But in real life, where is takes three times as much delta-v to reach orbit, the advantage is more apparent. An aerospike can burn from liftoff all the way to orbit while providing good ISP the entire way. A bell nozzle can't do that - at some point during the ascent it's going to be performing suboptimally.
  10. The change was actually introduced back in Kopernicus 1.3.0-5, but it had a glitch in it. Version 1.3.1-3 simply fixes the glitch to make it work the way it was originally intended. I learned of the change a month ago and fixed GPP proactively so that verison 1.5.88 would work with the new Kopernicus. GPP 1.5.88 should work with Kopernicus 1.3.1-2, but older versions of GPP will not work with Kopernicus 1.3.1-3. If you are using Kopernicus 1.3.1-3, you must use GPP 1.5.88.
  11. I've never used anything other than the stock tech tree, so I can't recommend any alternatives. But even if there are others, that doesn't mean you'll be happy with them either. It's very unlikely that somebody else is going to share your vision of what the tech tree should be. It's very easy to move items from one technology to another, so why don't you considering customizing it just the way you want it. All you have to do is install ModuleManager and write a .cfg file that changes the required technology for the parts that you want to move. A sample cfg might look something like that below. You just have to look up the names of the parts and technologies by looking through the existing .cfg files in the GameData/Squad/Parts/ folder. After you're finished, just place the cfg anywhere inside the GameData folder. The next time you start a career game, all the parts will be moved to the new techs. @PART[longAntenna] { @TechRequired = engineering101 } @PART[mediumDishAntenna] { @TechRequired = precisionEngineering } @PART[commDish] { @TechRequired = automation }
  12. The following thread provides a little more explanation about sunlight intensity curves. Kopernicus 1.3.1-3 fixed all the bugs, so the curves are now working as they should.
  13. Do what the instructions say. Install, Kopernicus (including ModularFlightIntegrator and ModuleManager) RSS (RealSolarSystem folder only) RSS Textures Sigma Dimensions SSRSS Kronometer Although RSS by itself is not up to date for KSP 1.3.1, SSRSS uses its configuration files. You must install the RealSolarSystem folder from the RSS download.
  14. [1.3.1] Kopernicus (Release 3) - Nov. 30

    Thanks, @Sigma88. You're solution works great. I'm just sorry I had to waste a couple hours chasing down the source of the problem. I don't know if it's the source of your problem or not, but I just noticed another error in your config. timewarpAltitudeLimits requires 8 values, you have only 7.
  15. [1.3.1] Kopernicus (Release 3) - Nov. 30

    I've got a problem that just doesn't make a lot of sense to me. I've got one body in an eleven body planet pack that won't create a cache file. The body loads up in the game just fine and everything looks OK, but I get only 10 out of 11 .bin files in my cache folder. This one body just refuses to produce a cache file. Its cfg is essentially identical to the others. In fact, I tried recreating the cfg from a copy of one of the others that is known to work, but still no cache file. All the logs look good from what I can tell. The only difference that I can see in any of the logs is that the Kopernicus logs for the bodies producing cache files include the following, [LOG 23:21:19]: Brovo is using custom cache file 'C:/Program Files/Kerbal Space Program 131 GPP 1588 GEP/KSP_x64_Data/../GameData\GEP/Cache/Brovo.bin' in 'C:/Program Files/Kerbal Space Program 131 GPP 1588 GEP/KSP_x64_Data/../GameData\GEP/Cache' [LOG 23:21:19]: Body.PostApply(ConfigNode): Loading cached scaled space mesh: Brovo while those lines are missing from the log for the body for which I'm having the problem. Does anybody have any ideas on what could be causing this problem? Help please. (edit) Here's a new test I just tried. I took one of the working cfgs and made a copy of it with a new file name. I then made minimal edits to the file, changing only the body name, the cache file name, and the referenceBody. With those changes only, it produced a cache file. I next made additional edits to the "Properties" node; changing description, radius, geeASL, initialRotation, and timewarpAltitudeLimits. I then deleted the cache file and restarted. With these additional changes, no cache file was generated. When I reverse those changes and go back to the previous properties settings, the cache is again generated. How can those few simple edits to the Properties affect whether or not a cache file is generated? (edit #2) OK, I've isolated the problem to the radius, and I'm pretty sure I know now what's happening. By coincidence my body's radius just happens to be exactly the same as the template. As long as I use a radius that's different from the template, I get a cache file. But when the radii match, no cache file is generated. Is that intended behavior? Should no cache file be generated when the planet radius matches that of the template? I can say from my experience here that my body doesn't look right when no cache file is generated. It looks much better when I force Kopernicus to generate a cache (by changing the radius just a little bit). I suggest that you edit your code to force the generation of a cache file even when the radii match.