• Content Count

  • Joined

  • Last visited

Community Reputation

47 Excellent

About MrSystems

  • Rank
    Rocketry Enthusiast

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. I was also having an issue with my solar panels not charging. Even the stock OX-STAT, when manually pointed directly at Kerbol in the stock solar system, did not charge. Installing Kopernicus 1.7.3, released yesterday, did not fix the issue. In the file Kopernicus\Config\SolarPanels.cfg is the following note: // This will replace all instances of ModuleDeployableSolarPanel with the Kopernicus version // that has proper support for multiple lightsources // // If you want to keep your ModuleDeployableSolarPanel, add "useKopernicusSolarPanels = false" to the MODULE node // That will stop Kopernicus from replacing it I don't want that behavior while Kopernicus isn't caught up to the version I'm running. So, rather than write a config to add the useKopernicusSolarPanels=F flag to all of my solar panels, I just deleted the Kopernicus\Config\SolarPanels.cfg file and reloaded the game. Problem solved.
  2. The Training mission Asteroid Redirect Part 1 provides assistance with some of these concepts.
  3. Zhetaan gave a really great answer and all his advice is fantastic. I propose here a simpler solution: If you're on the wrong side of the space station, you can just rotate your space station 180° so that the correct side is facing your incoming craft.
  4. Thank you. I'll take a look. Thank you again. I was curious what the most- and least-draggy parts were for the back end of a rocket, particularly as regards engines. Sorting first by diameter and then by Cd_YN×A_YN, I found the following: (note this is for parts in the ordinary prograde orientation, and sticking for instance a nose cone pointing backwards on the butt end of the rocket isn't considered an option in this analysis)
  5. The OP inspired me to do a bit of testing on 1.25m nose cones. My methodology was: start with a flea set to 23.5% thrust (pad TWR ~ 2.11), top with a RC-001S pod, an FL-T100 fuel tank, and various nose cones. I adjusted the fuel in the T100 so the launch mass would be the same each time (2,172 ± 10 kg). I launched straight surface-relative Radial Out from KSC and measured the apoapsis achieved. The maximum speed achieved was about Mach 1.3, so the results should extrapolate to actual rocket launches. The results were: 8,580 m, no nose cone (bare FL-T100). (Interestingly, the amount of drag from the Flea was the same as the drag from the T100) 9,551 m, MK16-XL parachute 12,067 m, Advanced Nose Cone Type A 12,475 m, Small Nose Cone resized to 1.25m using TweakScale 12,844 m, Aerodynamic Nose Cone (the blunt one) 13,702 m, Small Nose Cone on top of an FL-A10 fuel tank 14,063 m, Tail Connector A 14,611 m, Small Nose Cone on top of a "C7 Brand Adapter - 2.5m to 1.25m" fuel tank resized using TweakScale Of the four best options, SNC with empty scaled-down C7 has a mass of 81 kg, SNC with FL-A10 has a mass of 60 kg, Tail Connector A has a mass of 200 kg, and the Aerodynamic Nose Cone has a mass of 30 kg. So I might conclude: If you have TweakScale, use an empty C7 with the Small Nose Cone; otherwise use the Aerodynamic Nose Cone (the blunt one). Also, a mod-maker could improve the stock parts selection by creating a nose cone with the same profile as the C7/SNC.
  6. Fantastic info! Thank you for sharing. I have a question specifically as concerns structural tubes and custom drag cubes. If I wanted to write a custom ModuleManager cfg to fix the tubes, what ought the custom cubes to look like? My PartDatabase.cfg shows the following for the shortest length of the 1.25m tube (annotated as in your example above): Is the problem that the area in the YP and YN dimensions is only PI × (outer_radius² – inner_radius²) when (if the rocket is in a stack) it ought to be PI × outer_radius² (thus 1.227 for the 1.25m size, despite the fact it's 1.217 in all the PartDatabase listings for the other 1.25m parts)? And am I correct in thinking a mod with this "fix" would break (odd, rare) cases where a series of hollow structural tubes with no nose and no tail is used? A second question: how is drag at the trailing edge calculated? On a related note, (thanks to you I now know how to read the drag cubes and where to find them) I dumped all the cubes from my install into a spreadsheet and sorted them by Cd_YP. Drag coefficients for leading-edge parts, and some oddball parts that outperform leading-edge parts, include: Noteable takeaways from the data above include: Never use a Type-B nose cone The Mk1 Cockpit makes a better nose cone than any of the 1.25m nose cones Always use radially-attachable parachutes
  7. I just ran a Duna flyby-and-return mission early in my new career. There might be lower delta-V was to do this, and there are certainly faster ways than what I did, but my method is very simple to plan and did not require much delta-V. Here are the mission parameters: Starting from circular Kerbin orbit at 73km altitude, ... Ejection burn of 1050 m/s on Year 1 Day 227 Minor burn adjustments in Kerbol orbit (~20 m/s) to get Duna periapsis of 80km Arrive at Duna Year 2 Day 47 At Duna periapsis, burn prograde to lower Kerbol periapsis to 13.3 Gm, 483 m/s dV In Kerbol orbit at ascending/descending node relative to Kerbin, burn 32 m/s dV to yield 0 relative inclination In Kerbol orbit at periapsis, burn -190 m/s to get encounter with Kerbin one orbit later Aerocapture at Kerbin at approximately the same (slightly less) relative velocity as an ordinary transfer back from Duna. Total delta-V budget, including the initial transfer burn to Duna, was 1,800 m/s. Mission elapsed time was 3 Years 36 Days.
  8. When you're controlling the debris capsule, EVA the Kerbals inside, one at a time. Have the first one move to the controllable ship and get in. Then right-click on the pod, select Transfer Crew, and move that Kerbal to the other crew cabin on the controllable ship to make room in the pod for the second Kerbal. Then EVA the second Kerbal and have him get in the pod.
  9. Making History has been great. Engine plates certainly make things easier. Also, the Bobcat and the Mastodon end up in a lot of my builds--I just launched a craft where I calculated the most cost-effective solution for a main stage was 5 Bobcats under a 3.75m plate. PSA: All Making History players should get the mod Missing History. What good is a 1.875m stack without a 1.875m reaction wheel, 1.875m probe core, and 1.875m nose cone? (And why were 1.25m plates not included in the DLC?)
  10. I really like this mod! I just installed it yesterday but I wish I had been using it all along. I wanted to know in advance if I had added enough parachutes, rather than hoping for a pleasant surprise when I got out of physics range. So I looked through the source code, did some math, and did some in-game experimentation. The code uses the standard terminal velocity formula, v = ROOT[(2 m g)/(rho A Cd)]. The g used in the code is 9.81m/s² precisely, and rho at sea level in stock KSP is about 1.225 kg/m3, but the area and coefficient of drag for the stock parachutes were not readily available (not surprisingly, the values shown in the VAB and the parts cfg files did not align with expectations). The StageRecovery source code calculates it from the drag cubes, which is not something I am equipped to handle, so I conducted a series of launches varying numbers of parachutes and mass, and wrote down the results. Long story short, these are the calculated Area × coefficient of drag values (in m²) for the five stock parachutes. (The only chute tested more than once was the Mk2-R (n=9, stdev=0.3%).) 102 Mk16 Parachute 411.6 Mk2-R Radial-Mount Parachute 612 Mk16-XL Parachute 14 Mk12-R Radial-Mount Drogue 9.4 Mk25 Parachute (node-mounted drogue) It is also worth noting that TweakScale behaves as expected; a parachute scaled to 200% gives 4× the area of the base model. With that data and the formula, you can calculate the amount of mass you can land under your recovery velocity threshold with a given number of parachutes. Holding velocity constant, mass and area are proportionately-related in the formula, and it can be calculated that: 1 Mk2-R is needed per 1.5447 Mg of mass (not counting parachute mass) to be recovered at 8.0m/s
  11. Two KSP facts: 1) The camera always follows the center of mass of the active ship. The part you place first in the VAB is the "root" of the ship, and as you decouple various stages the active ship stays with the designated root. You can use the Re-Root tool in the VAB to change the root part; in most cases you'll want the root to be the Pod part on the upper-most stage. 2) KSP will mark a craft as "Debris" if it does not have a Pod on it. Therefore, if you decouple and the camera stays with the section marked "Debris", it is because a) the designated root part was on that half of the craft, and b) that half of the craft has no Pod.
  12. I agree with @Zhetaan; I usually make the determination based on the following two factors: Which setup costs less? Which setup is less likely to topple over in flight? Suppose your payload + upper stage has a mass of 50 tons, and you need 2,200 m/s dV from your main stage + booster. If you try to get it all from a liquid-fueled engine with min total TWR of 1.8, you're looking at a Mammoth + 97 tons of fuel, which costs $58,400. If instead you split it to 1,400 dV from the main stage + 800 dV from the boosters, you're looking at a Mastodon* with 43 tons of fuel and cost of $16,600, plus three Kickbacks at a cost not including separators and struts of $8,100, which is about $30,000 less expensive than the other option. (*If you don't have Making History, it would be a Mainsail with 45 tons of fuel, for $5,500 more than the Mastodon but still $25,000 less than doing it without SRBs.) In real life big rockets use boosters for a reason--they're a less-expensive way to add thrust and delta-V at launch. Two more tips: The Small Hardpoint and Structural Pylon, which are in the 'Structural' category in the VAB and unlocked with Advanced Aerodynamics and High Altitude Flight, can be used as decouplers for SRBs and cost much less than ordinary radial decouplers. And the mod SpaceY-Lifters has a great assortment of SRBs that provides a lot more flexibility than the handful of stock options. I made a calculator for use in Excel that will help with planning.
  13. I have noticed that my heliocentric orbit on a transfer burn from LKO never looks quite like the planned maneuver node, and I have to do a correction (sometimes a massive one) after leaving Kerbin's SOI. I think it's a problem with KSP 1.6.1 and not with any of the mods I have installed. I think, further, it is a problem that can be confused for "warping too fast through the SOI change" and is most noticeable when changing SOIs but has nothing at all to do with changing SOIs. Steps to Reproduce: Put a ship in low kerbin orbit. Burn to escape velocity. Go to the map screen and make note of where the ship is supposed to end up in Kerbol orbit Hit F5 to quicksave Open the saved file, and make note of the orbital parameters for the ship Wait a few in-game minutes (no need to warp) Hit F5 to quicksave Open the saved file, and notice the orbital parameters for the ship have changed Go to the map screen and make note of new, different orbital parameters in heliocentric orbit Wait or warp to but not past Kerbin's SOI, and repeat the above three steps Problem Detail I followed the above steps with my last launch, which was to achieve an apoapsis relative to Kerbol of ~831Gm. Immediately after the burn was completed I noted the orbital parameters in the save file, and I did so periodically later. No warping happened between the first three columns, and all data is from within Kerbin's SOI. This is what I found: Immediately after 2 minutes after 5 more minutes warping +5 hours warping +40 min MET 4,357 4,499 4,777 22,881 25,478 SMA -232,942.2 -232,942.2 -233,004.5 -233,004.6 -233,004.6 ECC 4.6721 4.6721 4.6715 4.6715 4.6715 INC 11.37787102 11.37787089 11.37787088 11.37787104 11.37787104 LPE 180.4062 180.4062 180.4072 180.4072 180.4072 LAN 78.186933 78.186931 78.186930 78.186926 78.186926 MNA 5.20 9.85 312.32 355.70 355.70 EPH 426,124,386 426,124,664 426,142,769 426,145,365 426,145,365 v at SOI 3,904.455 3,904.455 3,903.936 3,903.935 3,903.935 The first 7 rows came directly out of the save file. MET= mission elapsed tIme (in seconds), SMA = semi-major axis, ECC = eccentricity, INC = inclination, LPE = argument of periapsis, LAN = longitude of ascending node, MNA = mean anomaly at epoch, EPH = epoch. 'v at SOI' is my calculation, using ROOT(mu*(2/SOI - 1/SMA)), of the residual Kerbin-relative velocity at the edge of the SOI, which directly relates to where the craft actually ends up after it leaves the SOI. The discrepancy of 0.52 m/s resulted in a 6 gigameter shift relative to my target (Plock). What can be seen is: At the full 17-specific digit level used in the save file (not reproduced here) the final two columns are precisely identical in all respects, but none of the others match in any respect. Changes in MNA and EPH between the first four columns mean KSP was updating the ship's orbit each time (ship not "on rails"). No changes in any variable between the last two columns mean that the ship went "on rails" at some point Most but not all of the change happened in the first 7 minutes after the burn was completed, while the craft was under ~500km altitude From this data I conclude 1) that the KSP engine doesn't actually put orbiting ships on rails until some time after their thrust is cut off or until some altitude above Kerbin, and 2) the game is not correctly calculating orbital motion when the craft is not on rails. An additional supporting data point is that, during launches, Kerbal Engineer Redux indicates slight changes in my apoapsis (on the order of a few meters) after I've left the atmosphere on ascent. I've even had problems getting to the Mun and Minmus from LKO, where the moon-relative periapsis at altitude ~2,000,000m is much different from what the conic sections indicated at the end of the burn from LKO. One could perhaps blame one of my mods, such as PreciseNode, for mucking around with the conic sections, but what this data seems to show is that imprecise transfers are not due to imprecise conic sections or to "warping too fast through the edge of the SOI," but rather to imprecise tracking of ships near Kerbin. Some distinguished professors interpret unexpected nongravitational acceleration as proof of alien intervention in the solar system. Because the "How To Get Support" thread asked nicely, here's my log, but there's nothing of interest there.
  14. I don't know how to answer the specific question you asked, but I do know how to use KOS to get a ship into orbit. First, why are you using multiple kOS processors when just one (on the upper stage) would work fine? Second, I think KSP treats a vessel as a single vessel when it's joined together, so forcesetactivevessel might not work. Third, it's easier if you can put all your "steps" in one file, and make use of the WAIT UNTIL control before the next step happens. As in: DECLARE FUNCTION launch { // some code goes here } DECLARE FUNCTION orbit { // some code goes here } launch. WAIT UNTIL ALTITUDE > 70000. orbit. Or you could make them run sequentially like: set launching_is_done to FALSE. DECLARE FUNCTION launch { // some code goes here return(TRUE). } DECLARE FUNCTION orbit { // some code goes here } WAIT UNTIL launch. // won't proceed until the last line of launch is executed, which returns TRUE orbit. My kOS launching code is set up like: DECLARE some_constants. DECLARE some_logging_functions. WHEN ALTITUDE > 70000 then { stage fairings, etc. } // this won't trigger until much later SET some_steering_parameters. LOCK steering to some_steering_parameters. stage. // launches ship WHEN stage:liquidfuel < 0.1 THEN { stage. and do some other things. PRESERVE. // allows the WHEN to repeat next time youre out of fuel } WHEN ALTITUDE > 25000 THEN { lock steering to different_steering_parameters. } WAIT UNTIL APOAPSIS > target_apoapsis. set throttle to 0. unlock steering. run circularize_high // a different file that creates a maneuver node for circularization burn run burnnode // a different file that executes the next maneuver node // end of file; the real version is about 450 lines long, not counting circularize_high and burnnode
  15. Thank you for the explanation, @DMagic. I did look through the C++ code--not a language I'm fluent in--to see how the altitude was handled. It did not look to me like the body was referenced anywhere, and therefore any MM patches (like the one I wrote) would have to affect altitude equally across all bodies. Mine, for instance, just duplicated the part, called it "SCAN Multispectral Sensor Sarnus edition", and added a bit of cost and mass, but there would be nothing to keep me from using it at the new altitude over any other body. I would think any solution other than the cheat I came up with would have to involve reworking SCANsat.OnLoad in SCANcontroller.cs; it appears all the data in the foreach node_sensor in node_vessel loop would come directly from the part configs and there would be no way to use MM by itself to make a part function differently over different bodies unless the code were changed. // starting at line 552 public override void OnLoad(ConfigNode node) { ConfigNode node_vessels = node.GetNode("Scanners"); if (node_vessels != null) { SCANUtil.SCANlog("SCANsat Controller: Loading {0} known vessels", node_vessels.CountNodes); foreach (ConfigNode node_vessel in node_vessels.GetNodes("Vessel")) { Guid id = node_vessel.parse("guid", new Guid()); if (id == new Guid()) { SCANUtil.SCANlog("Something Went Wrong Loading This SCAN Vessel; Moving On To The Next"); continue; } foreach (ConfigNode node_sensor in node_vessel.GetNodes("Sensor")) { int sensor = node_sensor.parse("type", (int)0); double fov = node_sensor.parse("fov", 3d); double min_alt = node_sensor.parse("min_alt", (double)minScanAlt); double max_alt = node_sensor.parse("max_alt", (double)maxScanAlt); double best_alt = node_sensor.parse("best_alt", (double)bestScanAlt); registerSensorTemp(id, (SCANtype)sensor, fov, min_alt, max_alt, best_alt); tempIDs.Add(id); } } } I might suggest (like I said, I've not used C++ or delved into the KSP API, so bear with me) double min_alt = Math.max(node_sensor.parse("min_alt", (double)minScanAlt), SHIP:ORBIT:BODY:ATMOSPHEREHEIGHT); double max_alt = Math.max(node_sensor.parse("max_alt", (double)maxScanAlt), SHIP:ORBIT:BODY:ATMOSPHEREHEIGHT * 2) double fov = node_sensor.parse("fov", 3d) * Math.min(1, node_sensor.parse("min_alt", (double)minScanAlt) / min_alt) Something like that would narrow the FOV in the rare instance where the scanning altitude is raised but leave it unchanged otherwise.