Jump to content

jd284

Members
  • Posts

    340
  • Joined

  • Last visited

Reputation

254 Excellent

Profile Information

  • About me
    Rocketry Enthusiast

Recent Profile Visitors

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

  1. Actually it's still not completely fixed, after docking I still have to quicksave-quickload to be able to transfer crew across docking ports. Seems even without hatch modules present, the default state gets set to the wrong value. Anyway, F5-F9 is still faster than clicking on both ports, so I'll take it for now...
  2. It will probably be fine, though of course you should make a backup of your save. When I installed Principia I had a couple of ships in low orbit around Earth, and they were fine too [1]. This is just with RSS, no RO/RP-1 though, but I doubt they would make a difference here. Principia recalculates the planetary positions every time a game is loaded, so those should be fine too. The main issue is really only transfer orbits which will no longer find their target and most likely crash at periapse without a course correction. [1] However they were no longer aligned with the Moon's orbit, and of course as I found out it's no longer even possible to keep a station orbiting in the same plane as the Moon's orbit...
  3. Should this still be working? I tried it and it did remove the option to open/close hatches, but it also made it impossible to transfer crew through the ports altogether. Or is there some better way of removing the hatches or automatically opening them after docking? It seems all they really do is adding four more mouse clicks after each docking... [edit]Alright, somehow I never thought of just saving and restarting KSP, I was always reloading my save prior to docking which probably still had the old hatch closed state everywhere. It's fine now, no more hatch opening ceremonies after each docking.
  4. I had an issue with my Earth orbital station suddenly vibrating rapidly after I switched to it from the tracking station, in order to do a rendezvous of a probe that had its nearest approach at that time. So both ships were in physics range, about 250m from each other. The station seemed to vibrate at about half my framerate, seemingly switching between two states, "relaxed" and "agitated", finally ending up in the "agitated" state. At that point, multiple parts which still had their autostrut settings enabled, picked up the vibration and, being too far from equilibrium, it kept escalating to tear the station apart. Editing the savegame to disable autostruts didn't fix the vibration, but after shaking for a bit the ship eventually calmed down, with nearly all parts remaining out of alignment from each other even in subsequent time-warp. However, turning on "hack gravity" in the tracking station before switching to the station, I was able to avoid the vibration: 1. Hack gravity, 2. switch to the ship, 3. while still loading press "Escape" to immediately pause when loaded, 4. once it's fully loaded unhack gravity and press "Escape" to resume. Maybe the pausing was unnecessary. Since "hack gravity" hides the ship from Principia, I believe this might indicate a bug in Principia (version 2023061805-伊藤-0-g277). It may perhaps be processing both the probe and the station in consecutive frames and something is getting confused? I think in all prior rendezvous, which had no such problem, only one vessel was initially in physics range and the other came into range while the scene was already loaded. While I lost the trajectory history of the station, it wasn't particularly interesting (just a ~250km LEO), so I'll keep playing for now and hope it doesn't happen again. But if it's of interest, I can provide the samegame (using several dozen mods, including some custom ones of my own), or try to record a journal. I noticed a few things in the logs too:
  5. Absolutely agreed! Though I wish their mission documents explained the trajectories better, I haven't yet managed to do an even semi-efficient launch to get there. Basically always end up making the equivalent of a handbrake turn... really brings home the point why for 50 years, space travel has been almost entirely Hohmann transfers with maybe the occasional gravity assist.
  6. How do I start a Wolf crew route? I have a ship with the 2.5m crew container, but the transport computer says the "ship is too small" to start a route. What am I missing? [edit] Nevermind, KSPCF had hidden the "crew" connect-to-depot button and I was clicking the wrong one... That used to be a bug years ago but it got fixed by excluding the "KerbalEVA" module. So either you have an ancient version or some other mod messes with that module. Look for ScrapParts.cfg, the first line should have "!MODULE[KerbalEVA]]".
  7. Oh, good to know, that explains why sometimes it was wrong again after docking.
  8. Note that if you drive too far, this means your rover arrives in the original orientation but now the ground is in a different direction due to the curvature of the planet. So disabling rotation can work over short distances only, less than 30 or so degrees of latitude or longitude at a time. You can also just set the correct orientation it should use on the Bon Voyage controller PAW, and then re-enable the option. Though it's good to save before, because there's five wrong settings and only one right one, depending on how you've placed the part. Or maybe it depends on the control direction, I forget... In any case, go somewhere close, save when you get there but before switching to the rover, and enable rotations. Then switch to it and see if it was the right setting; if not then reload and turn off rotations and try again with a different setting.
  9. Huh, did not expect it to be quite that much of a reduction... in any case then the popup should really state that speed and not explicitly a speed at night of 40.6 m/s! Though I don't really get why it's that much slower, there's no pilot or driver bonus so clearly it uses the same navigation tools as an unmanned rover. I could understand the driver bonus being dropped at night, but not going at only a quarter of the normal speed. This is going to make exploration pretty tedious during those long lunar nights.
  10. Does that know about Principia burns and trajectories? Because what I've tried so far just uses the faux maneuver node and assumes an instant impulse, whereas the real landing burn takes several minutes. So anything that doesn't correctly take the Principia burn into account will be off by hundreds of kilometers in my experience. I guess I could try getting better at this... so far most attempts to land like this have ended in disaster, either lithobraking during the burn, or wasting fuel and running out, or just landing too far away. Might be the lunar masscons interfering or just KER not having the correct trajectory. Or maybe I just suck at suicide burns... However I've gotten really good at rendezvous in orbit with planned Principia burns, ending up within no more than a few meters and under 10 m/s, so the option for applying that to landings as well would be really cool.
  11. What could be the reason that my rover after a system check shows a speed of 40.6 m/s in the rover's control panel, but when I switch scenes, in the Bon Voyage panel it is moving at only 15 m/s? It has no pilot (only engineer and scientist), and is well powered by a USI reactor. They're going to run out of oxygen at that speed...
  12. For landing near my moon base, would a "Target-centered Moon-fixed" frame be feasible to add? The MCMF frame is somewhat helpful, but it is really difficult to judge the surface altitude, whether my landing burn will leave me 2 km above the surface or 2km below... and I can't tell easily how far from the target I will land either. Alternatively, something like the standard Tgt-MO but with the target velocity set to the surface rotation velocity rather than its equivalent orbital velocity?
  13. Thank you! This makes it much faster for me, barely affects the framerate anymore instead of turning KSP into a slideshow. Greatly appreciated.
  14. Is there a way to get the target's planned trajectory in the Tgt*O frames, rather than just its current trajectory? (Or to set that as default, even?)
×
×
  • Create New...