• Content count

  • Joined

  • Last visited

Community Reputation

477 Excellent


About diomedea

  • Rank
    The Right Stuff

Profile Information

  • Location Second to the right, and straight on till morning.
  • Interests astronomy, cosmology, advanced physics and more ...

Recent Profile Visitors

2805 profile views
  1. Nice suggestion. Never checked Contract Configurator up to now, thanks
  2. DV map is pretty easy moving from Kerbin to other places. Is a bit less intuitive for other trips. You'll spend around 3400 m/s to get in orbit (80 Km altitude) (Note, value depends on TWR, drag, trajectory and how accurately it is followed). Then, 860 m/s for the hohmann transfer to Mun, that brings apoapsis up to ~ 11400 Km, while periapsis still is at 80 Km. Then, 310 m/s at Mun periapsis to close the hyperbolic injection orbit to a circular low orbit. Then 580 m/s to land (you'll probably spend more unless you're able to perform a perfect suicide burn). Now, to bring the craft back up in a low circular orbit around Mun, takes another 580 m/s. To eject from low orbit you need to accelerate to a hyperbolic orbit fast enough to bring you back to the same kind of hohmann transfer orbit you used to get to Mun: that requires 310 m/s. Burning just a few m/s more, you'll be able to lower periapsis around kerbin from 80 Km to a value low enough to have an aerocapture (35-40 Km, depends on drag). And generally you don't need to burn during aerocapture. So the total amount is (theoretically) close to 3400+860+310+580, +580+310+a bit. Add some to deal with plane changes, piloting errors, non-instantaneous burns, imperfect timing, mid-course corrections.
  3. You have a public DMP server and don't know who maintains the server list? How did you publish it first time? Anyway, public list is with the DMP opening post, contact the author to update your data in there.
  4. If planetary orbits had no eccentricity, the correct phase angle for a transfer window would present with chronometric precision after one full synodic period from the last. So, for each kind of transfer (e.g., Kerbin -> Duna) we could write down a succession of dates when the transfer is optimal. Doing so with the back transfer too, then comparing arrival date with the first next date for return, would give what you need. However orbits are eccentric, so transfer windows aren't so regular. Therefore I still prefer to check transfer windows both ways when planning each interplanetary mission (same with tours, I check each transfer).
  5. @Nathair: I found the same issue with my heavily modded KSP 1.2.2. Had no time to try and isolate what mod could be doing so, also because just exiting flight and going back to the same vessel that showed the detached shroud, showed the shroud back in place (I can't verify without consistent behaviour, can only proceed by trial and error). Never saw the issue with a unmodded KSP install. Sure enough however, I don't have MFT with that modded install above, so can't think it to be tied to this. Below a list of what mods I have, if any were as well with your install, would be the first I'd check: AmpYear, E.V.E., Asteroid Day, Aviation Lights, BetterBurnTime, Chatterer, ConnectedLivingSpace, CorrectCoL, DPAI, EngineIgnitor, FASALaunchClamps, Final Frontier, G-Effects, Gravity Turn, IR, KAC, KAS, KIS, KER, Kerbalism, Kerbulator, Kostruction, SDHI, KSPARP, MandatoryRCS, MJ, MKS, NDAI, NavUtilities, PartOverhauls, PilotAssistant, PreciseNode, RPM, RCSBuildAid, RealChute, RemoteTech, SCANSat, Ship Manifest, Sounding Rockets, TAC FB, TokamakRefurbishedParts, Trajectories, TransferWindowPlanner, KSPTOTConnect.
  6. Game likes you. On the contrary, I just had to rescue a kerbal in munar orbit from a PPD-10 hitchhiker pod. When arrived within the bubble limit (2.5 km) had the nasty surprise to find the pod had nothin but atmosphere: no EC, no EVA fuel, no oxygen. Which isn't really unexpected as that module shows none such resources in editor (unlike command pods). Had I known in advance, I'd brought a rescue vessel with a grabber; no chance to bring a kerbal aboard the rescue vessel on its own without EVA fuel, I could maybe have maneuvered the vessel to make contact with the entry hatch and switch back to the EVA'd kerbal to make him grab, but not before he passed away without oxygen. Don't think kerbalism to be at fault for the above: pod selection where to find stranded kerbals is a stock game function. But stock game doesn't care about life support resources so is unaware of this "limitation".
  7. Any autopilot able to be given a simple instruction of the kind of "keep relative speed oriented along the relative position vector" would be able to make what you asked. Autopilots programmed in kOS definitely would make it easily. However, your target appears "stationary" only when you are very close (Note, this is a very different issue than with moving targets as I described above). The larger the angular distance along the orbit, the larger the error due to how KSP computes relative speed (vector difference from target absolute speed and vessel absolute speed): the farther away, the more the two vectors point in different directions (you certainly observed that making a close R/V with target, relative speed starts high but gets down the more the target is close, even while neither vessel nor target have changed speed). That vectorial difference therefore includes an angular component, that seems an error to be compensated. Quite often players keep trying to compensate that error without reducing relative speed first, ending running circles around the target. Your missile will need to be very maneuverable to cancel that angular error while it approaches the target at high speed. Very possible it may have to use the main engine to provide a lot of vectored thrust, so your autopilot would require a routine to orient the engine thrust accordingly and then to keep firing the engine until angular error is reduced to 0 (which is when target is along the prograde direction, but beware of the apparent error due to distance). So, I'd not use docking autopilots. They need to keep orientation of the vessel's port parallel to the targeted docking port, and thrust is generally only made out of RCS in translation mode.
  8. Time warp would stop it if you could warp just when forces between any two modules were null. Warp kills all relative velocities between parts, but if two parts are misaligned they will remain so, and exiting timewarp will again create physics forces meant to re-align the two parts. With the Unity physics engine, parts are allowed some "freedom" but each time they move from where they are supposed to be (in relation to the next attached part) a force is created to bring the two parts towards the correct position. Trouble like wobbling shows more when massive parts are attached through something smaller. In particular, through a couple of docking ports, as such ports don't even disperse energy, allowing movements to keep going for very long times. In the worse situations, using time warp at the wrong time with a long vessel already subject to such forces between parts, often the vessel breaks apart when exiting timewarp (as the forces recreated at the moment would even be greater than the maximum allowed). I'm unsure about how to easily explain this mechanical phenomenon. You may consider two attached parts to be able to oscillate like if one is a pendulum in relation to the other. The more massive, and the farther away the center of mass of the two parts, and the less the reaction provided by the attachment (very little with docking ports), the longer the oscillation and more intense the forces can get at the max displacement. Like with all pendulums, there is alternation of potential and kinetic energy, the first when the two parts are the more displaced from the rest position, the second when the wobbling speed is largest. You may be able to think at each form of energy like it was flowing with time, like a wave. And if more modules were tied that way, a wave of energy could be "seen" to move across the whole structure, from one side to the other and then back. That's how such things work in reality, just like with a guitar cord. What to do then to fix the problem? well, building so to avoid large massive parts being attached only by small ones. Struts help greatly to reinforce structures, though they also contribute to make forces, so could even worsen the issue if linked at wrong angles. While docking heavy modules, be extra careful to avoid misalignments (ports would still make the docking, but then the single resultant vessel would start wobbling because the physics engine has to cancel that misalignment.
  9. It's actually very simple (if I recall correctly). 1. Have KSPTOTConnect correctly installed in the GameData subfolder of your KSP install where RSS/RO is. 2. Launch KSP, enter flight scene (with whatever vessel you like). 3. Launch KSPTOT, from the main window menu, find File/Create New Bodies File from KSP 4. KSP will fetch all the needed bodies data in RSS/RO and make a new file like the default bodies.ini with them. 5. With more than one universe configuration in KSP, you can switch KSPTOT to work with different (bodies).ini files from the menu File/Load Bodies from File
  10. Warhead: KSP handles explosions (for graphical effect but also damage to nearby parts), but don't expect a part being destroyed on your missile to produce damage to a nearby vessel. While in reality warhead fragments projected all around and the shockwave bring enough energy, KSP doesn't transmit any from explosions to another vessel. KSP however works fine with physical forces, therefore transmission of kinetic energy: impacting another vessel makes an impulsive force F = dV/dT * m, dV/dT is the change in speed with time, m the mass of the impacter. If said force produces a displacement on the impacted part larger than what the physics engine allows, the impacted part detaches from the target (which is generally reason to start an explosion in KSP). So, you have to maximize kinetic energy with the impacter, meaning using a part with a large mass and moving at high relative speed towards target. And the mass of the impacted part is also relevant, if large that part will be able to absorb the kinetic energy without exploding. Guidance: aiming directly at a target position works best with a stationary or slow target. It still can be successful if chasing a high speed target (weapon fired from the target rear). With moving targets at wide aspect angle, kinematic makes for increasing change in angles the lower the distance gets, and invariably the missile won't be able to maneuver fast enough (change its speed vector to keep following target). Which is still acceptable if said missile can explode its warhead when close enough to damage target, but can't work in KSP. Instead, you need to use a guidance system using proportional navigation. Which means, the missile is directed at the predicted target position, movements ratios (missile/target speed components) in each coordinate are the same (proportional), angles don't change. Actually, when a change in aiming angle is detected, the guidance system uses that to further change its own speed vector, until the change in aiming angle with time becomes zero. Don't know about any add-on for KSP that implements proportional navigation guidance. However, the principle is easy enough so could be programmed in a autopilot using kOS. However please know one thing: the PID based autopilots (used in stock KSP and all add-ons I know about) work fine when goal is to reach and keep a specific orientation, but aren't able to keep pace with a changing value. To make an adaptive guidance system able to compensate movements of a moving target you need a closed-loop feedback system of at least 2nd order (acceleration) (real missiles guidance systems include also 3rd or even 4th order derivatives), on both pitch and yaw axes. Feedback systems require precise calibration to be fast while avoiding overcompensation, their response is tied to timing (or phase) of the error signal used as input.
  11. @Ser: tested with the same settings as before, and now everything seems to be working perfectly. Sure I have no more control locked when it shouldn't. Didn't check FPS before, but now it seems ok to me. Many thanks for your fast response and effective fix .
  12. Unmanned probes are fully controllable (if they have an active connection, as required with RemoteTech). Manned pods would normally not require a connection to be controllable in RT, but when G-effects is also installed, they aren't unless more than 1 crew mans them.
  13. Hi Ser, thanks for keeping this mod alive. Unfortunately, seems I've found an incompatibility. KSP 1.2.2, Win_x64, G-effects (latest 0.4.0 quickfix version) and RemoteTech (latest 1.8.4 version) (plus latest MM 2.7.5 as it's mandatory with RT). With any single-crewed pod, but also with multiple-crewed pods if less than 2 crew members are in, vessels aren't controllable when also RemoteTech is installed (uncontrollable meaning they won't respond to any command). Even having an antenna active (what is normally enough to control uncrewed probes with RemoteTech) doesn't work when G-effects is installed and 1 or less crewmembers are with the pod. Absolutely nothing in the log shows an issue. It's currently unclear to me if the issue should be dealt from this side or RemoteTech's, but hope this report provides enough info to diagnose and fix it. Output_log.txt (doesn't show aything of value to me)
  14. I'll do to complete this test, later as I haven't time just now. Many thanks for all those tests you did, that was some very valuable help to let us know what happens with those settings . EDIT: test done, confirmed AA must not be off or fairings will disappear when accepting mini settings.
  15. There's something incorrect with Edge Highlighting, your output_log shows a number of "HighlightingSystem : Edge Highlighting requires AA to work!" messages. Sure you have the Part Highlighter Enabled in Flight, while your AA shows to be set at 1. On my side, I have the Part Highlighter on too, but AA is set = 2 and no such messages show. Can't be totally sure this is the cause, but the Highlighter has caused a number of issues already, and you may still be having one with specific settings that weren't checked. So, my advice is to test with either Part Highlighter disabled, and/or AA set to something else than 1. Hopefully you'll find no more those messages in the log, and if that was really the cause, you should also have fairings still visible.