Jump to content

OhioBob

Members
  • Posts

    3,934
  • Joined

  • Last visited

Everything posted by OhioBob

  1. What I like to do in that case is perform two burns exact one day apart. The first burn is performed at the location and time of day that you want to perform the ejection burn, but one day earlier. You give the vessel enough delta-v to put it in an orbit with a period of 6-hours. This means that one day later it returns to the correct spot at the correct time to finish off the ejection burn. From a parking orbit of 100 km, the first burn should require a delta-v of about 763 m/s. BTW, a 4 minute burn isn't really all that bad. You could probably do that in a single burn without too much loss of efficiency.
  2. That's correct, but the first two items are a single maneuver, not two separate ones. Maybe you understand this, but that's not the way it sounds from reading your description. That is, you don't (1) perform a burn with just enough velocity to escape, and then (2) perform a second burn after escaping to lower the Pe. What you do is perform a single burn near Mun that provides the velocity to both escape and lower the Pe at the same time. You provide more velocity during this burn than what is needed just to escape. The energy that this extra velocity provides is leftover after escaping in the form of hyperbolic excess velocity. The hyperbolic excess velocity is what lowers the Pe. This method is far more efficient than performing two separate burns because we take advantage of the Oberth effect by performing the burn near Mun.
  3. After existing Mun's SOI you want to be in an orbit with an Ap near Mun (~12,000 km) and a Pe near Kerbin (~625 km). So the semimajor axis is, a = (12000000 + 625000) / 2 = 6312500 m Using the vis-viva equation, the velocity at Ap is, v = SQRT(3.5316E+12 * (2/12000000 - 1/6312500) = 170.7 m/s Mun's orbital velocity is, v = SQRT(3.5316E+12 / 12000000) = 542.5 m/s Therefore the spacecraft's velocity relative to Mun must be, v_rel = 542.5 - 170.7 = 371.8 m/s For the next part we use the following equation, v_ꚙ^2 = v_bo^2 - v_esc^2 where v_ꚙ is hyperbolic excess velocity, v_bo is burnout velocity, and v_esc is escape velocity. What this says is if we take the square of the velocity we're traveling after completing the ejection burn, and subtract the square of the escape velocity, what we get is the square of the velocity we'll be traveling after escaping Mun's gravity. Hyperbolic excess velocity is the result of the extra energy we give the vessel at ejection over and above that needed just to escape. v_ꚙ is the velocity we'll be traveling relative to Mun after escaping, so we set v_ꚙ = v_rel. So we first calculate v_esc and then v_bo. Let's say our orbit around Mun is at an altitude of 20 km. v_esc = SQRT(2 * 6.51384E+10 / 220000) = 769.5 m/s v_bo = SQRT(371.8^2 + 769.5^2) = 854.6 m/s So the Δv that we require for the ejection burn is simply v_bo less the original orbital velocity. Δv = 854.6 - SQRT(6.51384E+10 / 220000) = 310.5 m/s I find that in practice I generally need about 270 m/s. The reason this is less than 310.5 m/s is because of the way KSP uses patched conics. We don't need to accelerate all the way to escape velocity in order to leave Mun's SOI. Therefore it takes less Δv to acquire the same v_ꚙ as it would in real life. As far as ejection angle goes, it's easier to show than explain. Take a look at this, http://www.braeunig.us/space/orbmech.htm#hyperbolic You want one of the asymptotes of the hyperbola to be pointed in the retrograde direction. This means that the ejection angle from retrograde would be the angle η shown in figures 4.14 and 4.15.
  4. I can't think of any reason why adding or updating GEP mid-game would cause any problems. I think you'll be OK.
  5. The problem with your proposal is that you can't time warp while in an atmosphere. Anytime you are focused on one particular vessel, you'll be limited to no more than 4x physics time warp all the way out to the edge of the atmosphere. And when you are not focused on a vessel, it will be orbiting on rails and impervious to drag. Thus the orbit won't decay.
  6. This article from the KSP Wiki pretty much explains it all... https://wiki.kerbalspaceprogram.com/wiki/CommNet
  7. @Gordon Dry, in KSP the atmospheric composition is undefined. All that's given is the mean molecular weight. For Kerbin, the molecular weight is equal to that of dry air on Earth, i.e. 28.9644 g/mol. The intent is that Kerbin air is the same as Earth air.
  8. Your config makes the atmosphere warmer (303 K sea level average vs. 288 K), which accounts for the greater height. Increasing temperature decreases density and causes the atmosphere to expand.
  9. Not forgotten, just not included. Why should the ones you list be included but not a couple hundred other moons, asteroids, and TNOs. It has to stop somewhere.
  10. Using a relay network and/or clustering multiple antennas is the only way to stretch communications all the way to the OPM planets.
  11. @Snark, I've got my GEP CommNet all worked out. I believe I've come up with a solution that works in all possible installation scenarios, and gives us both what we're after. I've created a new mod named GEP_CommNet, which is an optional install that comes with GEP. When installed, the player will get both of the following: A Level 4 Tracking Station with a rating of 2T. An additional antenna with a rating of 1T. which will allow direct communications with the home world from as far away as the star Grannus. Of course this will make communications within the home system overpowered, but that's the choice the player makes by installing the addon. The additional antenna will be the JX2 if your mod is installed. And if your mod is not installed, the player gets the "Communotron 7-1000", which is just a clone of the 88-88 that is rescaled and upgraded. This ensures that the player has something that provides direct communication with Grannus. However, the 7-1000 doesn't have relay capability, so that means the player has greater functionality with the JX2 than without it. I've chosen to undo GPP's antenna upgrades when GEP_CommNet is installed (I borrowed the code from your GPP patch). Adding the extra antenna in lieu of the upgrades is necessary because the upgrades don't apply themselves in sandbox mode, and I can't have a situation where the player doesn't have a 1T antenna available to him/her. The only thing I need from you to make it all work is to have you edit one line in your jx2_OPM.cfg. I believe the following is the best solution: @CUSTOMBARNKIT:AFTER[OPM]:NEEDS[!GEP_CommNet] This will free GEP_CommNet up to add the Level 4 Tracking Station without JX2Antenna trying to undo it. If the player chooses not to install GEP_CommNet, then everything remains exactly as it is now. Can you make that change? There's no rush on it. I would just need the revision to be in place by the time GEP is ready for its next release. I'm not sure when that will be because it's contingent on GPP.
  12. When that Kopernicus error come up, that's a sign that there's something wrong with the planet pack.
  13. @Snark, I'm still not 100% certain how I'll end up handling these CommNet upgrades in GEP. Right now I'm leaning toward making it an optional install that will come packaged in the GEP download. It will likely end up being a separate folder inside GameData, something like this: [KSP]/Gamedata/GEP_CommNet/ Therefore your OPM patch would need to include NEEDS[!GEP_CommNet] rather than just NEEDS[!GEP]. That way if the user decides he/she doesn't want to install the upgrades, your patch will still work. If we just did NEEDS[!GEP], then your patch wouldn't work regardless of whether GEP includes the upgrades or not. I'll let you know what I finally decide before I release, but I think the above works best. Thoughts?
  14. @wile1411, something else of which you made need to be aware is that Grannus' orbit changes when installed in combination with GPP and OPM. Under all other scenarios, Grannus's orbit is, Periapsis = 1200 Gm Apoapsis = 2800 Gm But when GPP + GEP + OPM are all installed together, Grannus' orbit becomes, Periapsis = 1200 Gm Apoapsis = 1800 Gm
  15. @wile1411, the following is how I understand it based on current and planned updates. OPM 2.2.1 (for KSP 1.4.2) - Makes no changes to stock antennas or level 1-3 tracking station. Adds a level 4 tracking station with a 2T power rating, but only if GPP is not installed. GPP 1.6.2.2 (for KSP 1.3.1) - Adds part upgrades to the Communotron 88-88 and RA-100 antenna, boosting their power rating from 100G to 1T. No change is currently planned for the next release. GEP 0.9.2.0 (for KSP 1.3.1) - Does nothing to alter communications in current version. JX2Antenna 2.0.4 (for KSP 1.4.2) - Reverts both the OPM and GPP upgrades, adds the JX2 antenna with a 1T power rating. Therefore, below is what we get when these mods are used in various combinations. Stock + OPM ---> level 4 tracking station Stock + OPM + JX2 ---> JX2 antenna GPP ---> stock antenna upgrades GPP + JX2 ---> JX2 antenna GPP + OPM ---> stock antenna upgrades GPP + OPM + JX2 ---> JX2 antenna GPP + GEP ---> stock antenna upgrades GPP + GEP + JX2 ---> JX2 antenna GPP + GEP + OPM ---> stock antenna upgrades GPP + GEP + OPM + JX2 ---> JX2 antenna The next planned release of GEP will be v1.0.0.0 for KSP 1.4.x. It will include upgrades to boost the commnet so that is reaches Grannus. However, I haven't made a final decision on exactly how I'll package the upgrades. It may be baked in to GEP, or it may be offered as an optional addon. To reach Grannus I require both OPM's level 4 tracking station, and either GPP's antenna upgrades or the JX2 antenna. This is what I have planned: GEP 1.0.0.0 (for KSP 1.4.x) - Adds a level 4 tracking station with a 2T power rating. Adds upgrades to the Communotron 88-88 and RA-100 antenna, boosting their power rating to 1T, but only if JX2Antenna is not installed. If the end user chooses not to use GEP's upgrades, the result will be the same as listed previously. However, if the upgrades are implemented, below is what we'll get with different mod combinations: Stock + GEP ---> level 4 tracking station + stock antenna upgrades Stock + GEP + JX2 ---> level 4 tracking station + JX2 antenna Stock + OPM + GEP ---> level 4 tracking station + stock antenna upgrades Stock + OPM + GEP + JX2 ---> level 4 tracking station + JX2 antenna GPP + GEP ---> level 4 tracking station + stock antenna upgrades GPP + GEP + JX2 ---> level 4 tracking station + JX2 antenna GPP + GEP + OPM ---> level 4 tracking station + stock antenna upgrades GPP + GEP + OPM + JX2 ---> level 4 tracking station + JX2 antenna To get the scenarios that include OPM working as indicated, an update to the JX2Antenna mod is required. @Snark has indicated that he'll make the necessary revision.
  16. That sounds like a good solution, I see no problems with it. As long as you don't do anything that prevents GEP from creating the Level 4 Tracking Station, I'm happy. Somebody else also mentioned PatchManager to me. I don't know much about it. I do like the idea of giving the end user options.
  17. There's nothing I can spot as an obvious cause. Maybe you should try a fresh installation with just the essential stuff to see if that works. CTTP Kopernicus ModularFlightIntegrator OPM Squad ModuleManager
  18. Probably the best first step is to post a screenshot of your GameData folder. That might enable us to spot installation errors.
  19. I've tried to do that but I can't make it work. I been unable to figure out a conditional string that overrides Snark's revert (doesn't mean there isn't one, I just haven't found it). I also don't like the idea of having mods at war with each other trying to undo what the other is doing. Isn't it better if we can all just get along? The only solution I've found that works is to delete jx2_OPM.cfg from Snark's mod. That will be the solution I'll have to recommend to GEP users if I can't find something better. But that's an awkward solution I don't like. Far better to tweak the config so users don't have to go around deleting files.
  20. @Snark, I've got a problem with your mod getting in the way of something I'm trying to do, so I'm hoping you will consider implementing a tiny fix to correct it. First let me give you some background on what I'm doing. I'm the author of Grannus Expansion Pack, which adds planets around the star Grannus in GPP. I'm also working on an update that allows Grannus and its planets to be installed as an expansion to the stock solar system. As part of the update I want to give players the option to extend the commnet all the way to Grannus, providing they've researched all the requisite tech and completed all the upgrades. To achieve this I need a combination of a 2T Level 4 Tracking Station and a 1T advanced antenna. This produces a comm link to Grannus of about 6% when at periapsis. Of course this means that comm links to planets in the local system are overpowered, but that's unavoidable if we're seeking a signal powerful enough to reach Grannus. It should be up to the player to decide which combinations of tech and upgrades he wants to use. Therefore I'm adding to GEP a Level 4 Tracking Station (the same upgrade used in OPM) and upgrades to some of the stock antennas to boost their strength (the same upgrades used in GPP). However, I plan to make the antenna upgrades conditional on NEEDS[!JX2Antenna]. That way the upgrades appear only if your JX2Antenna is not present. And if JX2Antenna is installed, then those become the antenna options from which the player must choose. Of course if the player fully upgrades the Tracking Station, the JX2 becomes less vital as a tool to exploring the outer planets of the main system, but it still remains an essential part of the commnet to Grannus. The Level 4 Tracking Station and the JX2 antenna need each other to accomplish the goal. The problem I'm having is that anytime GEP is installed in combination with OPM, I can't get the Tracking Station upgrade to work. JX2Antenna keeps reverting the upgrade because of your OPM patch, making it impossible to establish a comm link with Grannus. The mods should be made to work together to achieve everyone's objectives, not fight each other. The solution to this problem is very simple: I just require that the NEEDS part of your jx2_OPM patch be revised to NEEDS[OPM,!GEP]. That way all my revisions work, and, I think, everybody wins. Can you make that revision? I don't think it will be necessary for you to make any other GEP patches because I'm handling the antenna upgrade thing on my end.
  21. UPDATE Version 0.9.2.0 Changelog Taranis: Fixed lava and color map bugs, despeckled height map, added PQS height noise, new normal map. Nodens: Fixed height map bug, added PQS height noise, new normal map, recolored shoreline, added trees. Belisama: Revised color map, tweaked height noise settings, new normal map. Airmed: Added PQS height noise, new normal map. Brovo: Added PQS height noise, new normal map. Damona: Added PQS height noise, new normal map. Epona: Added PQS height noise, new normal map. Miscellaneous housekeeping updates to planet configs. Updated cache files. This is intended to be the final release for KSP 1.3.1. It is designed to work with GPP 1.6.2.2.
  22. I see one problem, OPM_FinalFrontier is installed incorrectly. Drill down further into the folder and you'll see another folder titled Nereid. It is the Nereid folder that should go in GameData.
  23. One thing that the level 4 Tracking Station + JX2Antenna can do that no other single option can provide, it can reach Grannus (the red dwarf star in GEP). Although it's not possible with the current version of GEP, a planned update will allow GEP to be added to the stock solar system. So if a player uses Stock + OPM + GEP, they'll have a means to maintain communication with vessels traveling all the way to Grannus (when near perigee). That certainly gives the level 4 TS and JX2 a purpose to coexist together. I'm all in favor of that.
×
×
  • Create New...