Jump to content

VMQ

Members
  • Posts

    21
  • Joined

  • Last visited

Everything posted by VMQ

  1. I didn't read this before hitting "no" when CKAN asked me. Now it is not asking again and all installed packages show "N/A" in the install column. Is there a way to trigger the reinstall again?
  2. Question regarding maximum value for Parachute Altitude slider. I created a custom parachute increasing the deployment altitude of the parachute with a little module manager config: +PART[parachuteRadial]:FINAL { @name = parachuteRadial-High @title = Mk2-R Radial-Mount Parachute (8000m deploy variant) @MODULE[ModuleParachute] { @deployAltitude = 8000 } } This works, but when I click on the slider for altitude in the UI the maximum value reverts back to 5000. Is there a setting that controls the maximum value for the UI? Like @clampMinAirPressure for the minimum of the pressure slider? Thanks!
  3. I'm trying to use the Rover Autopilot to drive to a game waypoint (From a contract or waypoint manager). Is there a way to select the active waypoint as a rover waypoint? Currently I am creating a rover waypoint by clicking on the map and then editing it in the "Rover Waypoint" window to match the lattitude / longitude coordinates. Am I missing something here?
  4. I just ran into an issue where the red impact marker is updated very delayed. This only happens on Minmus, the red marker moves fine on the Mun. See the following video to show what I mean. I'm using kOS and the IMPACTPOS value from Trajectories follows what the red mark is doing. The impact marker from KER gets it right and even the "fixed body" trajectory from Trajectories points to the right spot. FYI and Thanks!
  5. Update: With Kerbalism 3.15 the DataRateDampingExponent value changed, affecting the science rate. See section at the bottom of the post. The following section is based on Kerbalism 3.14, but the math is still correct. I tried to make sense of the data rates shown and used by Kerbalism, see science rate 300kB/s in first picture below. Now, if you are not interested in the formulas, just go to [1.8.x-1.11.x] Kerbalism Companion Calculator (KCC) - An antenna planner for Kerbalism [v1.3.0] [29th November 2020] and use the mod. If you are interested in the underlying math, keep on reading. As a bonus you get my measurements and theory about how relays affect the total data rate. First thing, all credit goes to Valentin Bischof who wrote the mod. I just looked at his code and compared it with what Kerbalism shows. The data rate depends on the signal strength as shown in the upper left corner in map or vessel view. See Mike Aben’s excellent tutorial about signal strength Ranges and Signal Strength | KSP Let's Do The Math. There are two settings that change the data rate. The Antenna Bandwidth factor (Antenna Speed) in the Kerbalism(1) Science settings. Mine is set to 150%, but yours may vary. Secondly there is a DataRateDampingExponent in Kerbalism’s settings.cfg. It seems to be set to 6 by default. Combining Antennas Combining antennas changes the signal strength, see Mike Aben's tutorial, but it also changes the data rate. The combined data rate of the antennas on the vessel is calculated through: With ABf the Antenna Bandwidth factor and AntRate the data rates of the active antennas this is the geometric mean of the data rates of the antennas. Careful, do not combine strong and weak antennas. A Communitron 16 with 2.2kB/s and a Communotron DTS-M1 with 25kB/s combine to 7.42kB/s, or 11.12kB/s with ABf = 1.5. Data Rate The total distance dependent rate can now be calculated by using the following formula: With signal the signal strength and D the DataRateDampingExponent (= 6). This formula lets the data rate quickly deteriorate for signal strengths less than 100%. See plot for the factor that is multiplied with the combined antenna rate. For example, to have more than 0.5 of the maximum transmission rate, one should have at least 90% signal strength. Relays The following is only loosely tested, so please let me know if you get the same results. When going through a relay, the minimum of the total distance dependent rate of the vessel and the total distance dependent rate*ABf of the relay satellites involved is used (ABf = 1.5). I tested this with a relay in Mun orbit with a HG-5 relay antenna at 100% signal strength with 14.49kB/s (including the ABf) data rate and a direct antenna HG-55 with 200kB/s on a vessel. With direct sight, the vessel achieves a data rate of 300kB/s (including the ABf), but in the Mun’s shadow the data rate drops to 21.74kB/s when the relay is used. This looks like a small bug as the ABf factor is applied twice to the relay (9.66*1.5*1.5=21.74). In a second test I had a Communotron 16-S at 96.63% signal strength on the vessel and the same faster HG-5 antenna on the relay, see picture below. The data rate to the relay was 2.69kB/s (agreeing with the formula above). Changes in Kerbalism 3.15 and newer In the newer version the DataRateDampingExponent setting was removed from Kerbalism’s settings.cfg. Now settings.cfg says: Kerbalism will calculate a damping exponent to achieve good data communication rates (see KSP.log, search for DataRateDampingExponent) According to my KSP.log the new damping coefficient is 14.034, but yours might vary. Calculated DataRateDampingExponent: 14.0340 (max. DSN range: 250000000000, strength at 2 AU: 0.967) A damping coefficient of 14 instead of 6 leads to significantly reduced science data range, see pictures below for comparison (left: D = 14.034; right: D = 6). For further comparison here is a data rate vs. signal strength plot for D = 14: For example, to have more than 0.5 of the maximum transmission rate, one should have at least 95% signal strength. Restore behavior from Kerbalism 3.14 To restore the previous science data rate behavior, uncomment and change the following line in Kerbalism’s settings.cfg: DampingExponentOverride = 6 Hope this helps someone to calculate science data transmission rates in Kerbalism.
  6. I am trying to find out a problem with a contract from Contract Configurator with Kerbalism where the check for CrewCapacity fails when crossing a certain altitude, somewhere around 2344m. On the launchpad, and during the early phase of the launch the "Support 4 Kerbals" condition is satisfied, but then it fails. I filed two issues, Contract Configurator issue 717 and Kerbalism issue 817 with further details. Does anyone have an idea where/why the CrewCapacity seems to be removed at around the altitude when the pressure or oxygen go away on the outside? See the video below, Kerbalism says all is good to support the crew. Here is a video of one of those launches:
  7. @OHaraThank you for this nice explanation! It seems over the last years two pictures went missing. Could you bring them back? Or is there a follow up article somewhere?
  8. After my own kOS scripts and even MechJeb failed to get me into the exact target inclination, I did some searching and math and came up with the following formalism that gets me right on target. This is mostly based on this website, but adds some derivations and corrects the part that takes the rotating body into consideration. The azimuth, or degrees from north dynamically changes during the course of an orbit around a body and depends on the latitude of the object at that time. With some spherical geometry, and especially Napier's rules for right spherical triangles (R8) one finds that: cos(inclination) = sin(azimuth) cos(latitude) From this formula one finds that for a given orbit inclination the azimuth is given by (note there are two possible solutions): azimuth = arcsin(cos(inclination)/cos(latitude)) or azimuth = 180 - arcsin(cos(inclination)/cos(latitude)) This is sometimes also referred to as the inertial azimuth. Please see that for latitude 0, on the equator, this becomes the familiar azimuth = 90 + inclination or azimuth = 90 - inclination Effect of the earth rotation If the body wouldn't rotate one would be done by now. But the rotating body gives the ship an additional velocity toward the east, so that launching into the calculated azimuth above will still miss the target inclination by a fair amount because an orbit with with orbital velocity v_ob will have the following two components: v_ox = sin(azimuth) v_ob // component along the equator v_oy = cos(azimuth) v_ob // component perpendicular to the equator This means, that launching into an inclined orbit will be off slightly because of the additional equatorial velocity that is added at launch. The velocity changes with the latitude of the launch. v_e = cos(launch latitude) * equatorial surface velocity Putting this all together means that we need to launch and maintain the azimuth of the rocket during flight so that the surface rotation is taken into account and that the rocket is applying the thrust in a corrected azimuth direction. The velocity components need to obey: v_ox = sin(azimuth) v_ob - v_e (1) // component along the equator v_oy = cos(azimuth) v_ob (2) // component perpendicular to the equator The picture at the bottom shows the possible cases (with iAzi = azimuth and cAzi = corrected azimuth) for the velocity vector for v_o that includes the surface velocity that is gained for free and the components v_ox and v_oy that the rocket is getting through the burn. With this in mind the corrected azimuth (cAzi) can be calculated by: cAzi = arctan2(v_ox, v_oy) (3) The upper left and upper right diagrams are fairly obvious and cover the situation for launching into the ascending node. Equation (3) follows directly from the diagrams. The case is slightly more complicated for azimuths from 90 to 270 (launches into descending node), but symmetry shows that the absolute values for vox and voy are also correct, but that voy needs to come out negative. This is correct, because cos(180-x) = -cos(x), so that eqn. (2) also holds in those cases and eqn. (3) stays valid. Effect of the earth rotation (final comment) In the website referenced at the top the velocity v_ob is assumed to be the velocity of the stable orbit. This is incorrect of the burn is interrupted before the final orbit is reached. Instead the corrected azimuth needs to be maintained until the engine shuts off after the initial burn, hence the horizontal velocity at engine shutoff, usually with an apoapsis higher than the atmosphere, but not a stable orbit yet, determines the v_ob and therefore the corrected azimuth. For people using kOS it works well to select v_ob that is reached during the initial burn - 1500 m/s usually works well for Kerbin launches - and switch the heading of the rocket from "corrected azimuth" to "azimuth" once the target inclination has been reached. Let me know if this was helpful, or if someone is interested in my kOS scrip that uses this formalism. Picture to show dependency between corrected and inertial azimuth:
  9. After seeing this question asked before and not seeing a satisfactory answer I tried to come up with my own answer. First, we need to establish the reference direction that the longitude of ascending node (LAN) is measured against. See for example this post for a definition, the reference direction points from Kerbin to Kerbol on day 1 (lets ignore the tiny difference of 0.00159rad because the mean anomaly of Kerbin is 3.14 and not Pi in this assumption.). The next needed part is that a solar (Kerbol) day is a little longer than the sidereal rotation of Kerbin. Looking at the picture below one can piece together the global longitudinal angle in the Kerbol (different from the coordinates on Kerbin). At 0 degrees longitude on day 1 year 1 the global longitude is 90 degrees. At KSC the lat/long coordinates are about 0,-75, so that on day 1 year 1 the global longitude is 90-75 = 15 degrees Due to the rotation of Kerbin the global longitude increases by 360 degrees over 1 day, i.e. 1 degree per minute, plus ... The difference between sidereal day and solar day is adding 360 degrees per complete sidereal orbit, or 21600/9203545*360 degrees per full day. Now putting this all together the time x (in minutes) after 0:00h in UT to have the KSC at global longitude LAN on day d can be calculated with this formula (not showing the algebra): x = LAN - (90 + <launch longitude>) - (d-1)*21600/9203545*360 As an example, to launch at global longitude 90 degree, on day 60 the calculation yields x = 25.15m. So, if the Kerbals launch at 0:25h at KSC on day 60 with an inclination their resulting orbit will have a LAN of about 90 degrees. Hope this helps. I tried it, but please let me know if you find errors.
  10. Missing contract details? Please compare the details provided for the "Explore Minmus" contract in the pictures below. The part of the contract that says: "At least one scientist assures us that we won't bring back any harmful contaminants" is missing in the VAB or on the launchpad but is shown in the Space Center window. Am I missing a setting or option somewhere?
  11. Indeed, I didn't notice that, but on Kerbin the sliders have an effect, as expected they change the values in the sentence: "Turn start when Altitude is x.x km or Velocity reach y m/s" But on Minmus there is no efect: Note the sliders and the values. It works on Kerbin:
  12. Can someone point me to an explanation what the Altitude and Velocity sliders exactly do in the Ascent Path Editor? See picture below, I have a the "Automatic Altitude Turn" setting on.
  13. You would have a point if the numbers would change. But they don't. They are the same numbers for the average as reported by the M700 and in map view as in my pictures above.
  14. I just got a scan from Minmus with a M700 survey scanner. Can someone explain why the percentage is different? 5.74% is shown by the scanner and map view shows 5.1%. That's not even close to a rounding error.
  15. I thought I'm trying something simple, I tried to change an alarm time/day and make also it repeatable. I cannot find an option for that. Am I missing something? See picture below:
  16. I was reading the wiki pages about CommNet https://wiki.kerbalspaceprogram.com/wiki/CommNet to figure out what science transmission to expect for various signal strengths, but it only give a nebulous answer: "This bonus decreases non-linearly with signal strength." Googling this also didn't turn out anything, so I thought it is probably straight forward to "beam" a vessel to various distances to Kerbin and take some data about this relationship. The CommNet page describes the signal strength vs distance, so I started sending a vessel with a Communotron 16 out into space. With a Tracking Station with 250G the maximum range is 353.55Mm. With this the signal strength is calculated. (See wiki for formula). Procedure: Use <Ctrl><Alt>-F12 and set craft in Sun orbit. Select Kerbin as target. Place test craft at the same angle as Kerbin: In "set orbit" set eccentricity to 0.00001 and adjust "Arg PE" (Argument of periapsis) until the target phase angle is 0 deg. This allows to calculate the distance between Kerbin's and the craft by (Kerbin altitude) - (Craft altitude+Kerbol radius). For the various distances I took data for signal strength, Science bonus and science transmit value for Temperature, Pressure, Mystery Goo Materials Study and Magnetometer. I also calculated the signal strength according to the wiki. The calculated signal strength agrees pretty well with the signal strength provided by the game when hovering the mouse over the signal strength icon, but can anyone explain the science bonus dependency? See https://docs.google.com/spreadsheets/d/1G5QT6JhA4P_90pcRfA7tyPhpS1TztGEwG_LaJo9dygk/edit?usp=sharing for the complete "measurements". Signal strength Science bonus 0 0 1 0 7 0 21 0 41 1 45 1 46 19 47 19 48 19 48 20 49 20 53 21 58 22 62 23 63 24 64 24 64 24 65 24 66 25 70 26 74 27 78 28 79 29 81 29 81 29 81 29 81 29 81 29 82 40 82 40 82 40 85 40 That really is "non-linear"! Make sure to always have at least 82% signal strength!
  17. Hi, this seems to be a display bug for the OX-Stat-PD and not an actual power production bug. Below you see the setup with Control Station, OX-Stat-PD and Go-ob ED, with the OX-Stat-PD placed from the engineer (out of his personal inventory). The control station shows "Total Power Available: 2" and the Go-ob ED shows that science is produced (see below) If I have the scientist pick up the OX-Stat-PD and then place it again, the "Total Power Available" in the control station changes to 1 and the Go-ob ED stops producing science. Still a bug, but at least it works.
  18. Ascent Guidance - Time to Orbit Being Long I was just looking at this entry in the manual https://github.com/MuMech/MechJeb2/wiki/Ascent-Guidance#time-to-orbit-being-long and wondered where I actually set the "intermediate altitude" as recommended. I don't see that option in the ascent guidance module.
  19. Hi, I just installed AFBW with CKAN and I was wondering if it is expected to not have a minimum default preset configuration for the connected controller available? If so, that's fine. I was able to create a preset configuration for the PS4 dualshock 4 controller connected with USB cable and could teach AFBW the controller inputs with the preset editor.
×
×
  • Create New...