Jump to content

jd284

Members
  • Posts

    340
  • Joined

  • Last visited

Everything posted by jd284

  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?)
  15. It's a quad-core (8 HT), several years old i7-4790K at 4 GHz, running on Linux with RSS. When paused in map view, about 1.5 cores are in use on average, when unpaused it hits 3.5 - 4 cores. There doesn't seem to be an impact whether the equipotentials are enabled or not in the main window, so as you say those don't seem to be the bottleneck (or do they still get calculated and just not displayed?), in any case it's probably not the graphics card either (Geforce 970), although it's at 100% usage whenever the game is running. Do these have to get recalculated from scratch every frame, or do you use the previous frame as initial condition and only make small adjustments each frame? It sounds like this computation is somehow much slower on my computer than it should be. I've noticed the FPS also scales very strongly now with the prediction steps setting, at 6.4e1 or below it's above 10 fps in the EML frame, and at 1.6e4 it's down to 1-2 fps. In other frames I have 40+ fps all the way up to 1.6e4. It's not really a big deal however, since I would actually use this frame very rarely, but it's just so pretty to look at! I can just dial down the prediction steps when I need it.
  16. I absolutely love this, even though it kills my FPS dead (from 45 to less than 2). Is there some setting to reduce the number of equipotentials? I would really only need two or three; the ones "crossing" at L1/L2 and possibly those around L4/L5. The other ones are nice for sceenshots though.
  17. Unfortunately I'm only good at coding, and less than useless with modeling or textures...
  18. Since the wheel revamp in KSP 1.12 I haven't any luck whatsoever getting any of the USI wheels to work properly. I've stuck to making Frankenrovers with stock wheels only. Ugly but at least they work.
  19. Hmm, I'm using the full-scale RSS so I'm not sure how well that would work then. In that case I think I'll just wait until someone makes a proper RSS config.
  20. Can you post your WIP please? I'm not spending much time to look around KSC anymore anyway. It works fine for me on Linux as far as I can tell.
  21. Right, sorry for being impatient. If you need help with the code I can assist though, although from the description it's not obvious why you would need to change the code at all, just new part files should be able to do that, and probably a 3D model for the goo chamber if you don't want to reuse the existing models for that.
  22. This sounds really interesting, but is there a way to try it out yet? The links still go to the old MOAR Station Science mod.
  23. It's allowed for the fuel experiment parts (they have crossflow enabled), but you have to mind that some other parts such as heat shields and structural parts don't permit fuel flow, and for decouplers you have to enable it in the PAW. That's probably your issue. Well, at least it was my issue a few times, and I had to bolt a new FL-200 next to the original tank, transfer the fuel into it, and then move it next to the experiment using EVA construction. Because usually I put the tank on the wrong side of the heat shield for this...
  24. I mean only one depot on each destination really needs a lot of crew, for the rest you should set up transport routes (using a rover so that they're free, or ISRU to refuel) to transport everything to one location where the crew can process it. With the power provided by the depot you can set up a small unmanned harvesting base in each biome and with multiple such harvesters you should be able to get all resources transported back to your crewed main base, at least until you get to the crazy stuff like producing prototypes and robotics. Sounds like you're trying to do everything at once, and that's intended to be very painful, both in MKS as in WOLF.
×
×
  • Create New...