Jump to content


  • Posts

  • Joined

  • Last visited


230 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. You get half the part mass in MaterialKits. So per ton of mass you get 500 MK. The other half is lost. I usually just add one ISM for this purpose, to contain the scraps until I build up until orbital production becomes available. It never fills up for me, mostly because you only get to scrap the upper stages anyway, which should generally have very low dry mass to get decent deltaV.
  2. Catch-up happens in 6-hour increments, so as long as you have at least 6 hours worth of storage (i.e. 100 ore), you will have full fuel. So, you'll be fine.
  3. I still get the error for LVD, but I can now enter numbers such as the orbit size in the Halo Orbit Constructor. Unfortunately at this point I have no real clue what could be wrong, I can't find any errors about anything missing or being wrong. In KSP and other games as well as the desktop compositor, Opengl works fine anyway.
  4. OK, I tried the LVD after all because I saw the "Halo Orbit Constructor" option and wanted to try planning a mission to the lunar gateway NRHO (playing RSS with Principia). However when I open it, after a few seconds I get an error message and it asks it I really want to close the window. Switching to hardware OpenGL rendering at runtime on unix is not supported. If I click "no" to not close the window, it stays open and I can still click on things but I cannot enter any numbers/text. Trying to set the view options to "Painters" instead of opengl and saving results in a different error: Functionality not supported with figures created with the uifigure function. Error in Generic3DTrajectoryViewType/plotStateLog (line 25) Error in LaunchVehicleViewProfile/plotTrajectory (line 142) Error in LaunchVehicleViewSettings/plotTrajectoryWithActiveViewProfile (line 25) Error in lvd_processData (line 29) Error in ma_LvdMainGUI_App/editViewSettingsMenu_Callback (line 1770) Error in appdesigner.internal.service.AppManagementService/tryCallback (line 369) Error in matlab.apps.AppBase>@(source,event)tryCallback(appdesigner.internal.service.AppManagementService.instance(),app,callback,requiresEventData,event) (line 37) Error using matlab.ui.internal.controller.WebMenuController/fireActionEvent (line 67) Error while evaluating Menu Callback. So... should I try to get opengl rendering working? (Maybe I'm missing some library, although there are no other errors in the log file.) Or should I try to get it working without opengl somehow?
  5. Yeah, it's pretty overwhelming at first sight! But now that I can actually read things I think I'll be able to figure out what I want to do.
  6. Thanks, the plugin fixed most of the windows now. Except for Mission Architect. But I wanted to use mostly the flyby tool, so I'm happy with this. 1. Linux (Kubuntu 21.04) 2. 3840x2160 / 184 dpi 3. Without your fix above, it affected all windows. With the fix, only Mission Architect is still at the wrong scale. 4. ======================================== _ __ _____ _____ _______ ____ _______ | |/ // ____| __ \__ __/ __ \__ __| | ' /| (___ | |__) | | | | | | | | | | < \___ \| ___/ | | | | | | | | | . \ ____) | | | | | |__| | | | |_|\_\_____/|_| |_| \____/ |_| ======================================== KSPTOT v1.6.8 MATLAB (R2021a) Update 4 DATE: 2021/10/01 15:38:59 ======================================== Switching to hardware OpenGL rendering at runtime on unix is not supported.
  7. Would it be possible to include an option to set the display scale factor? Currently on a high-res display the tool is pretty unusable, half the info boxes appear to be missing. The text scales correctly but does not fit into the UI boxes. As far as I understand the following should set this in Matlab, but I don't know how that could be changed in a runtime tool like KSPTOT: >> s = settings;s.matlab.desktop.DisplayScaleFactor >> s.matlab.desktop.DisplayScaleFactor.PersonalValue = 1.5 Or is there a way I can enter this somewhere myself?
  8. KSP 1.12 seems to have broken the Karibou wheels, does anyone have a quick patch to fix them? My Moon rover is pretty much unsteerable at the moment.
  9. Thanks for the explanation, and it seems I can still learn something new about orbital mechanics each day. However, at least for my flight plan that doesn't seem to be true. But it wasn't a pure plane change, I had to burn slightly +tangent because of the lunar masscons dragging my highly eccentric orbit well into the surface otherwise, which probably changes things. So when I reloaded the game at that point and tried to plan the same burn (ending at the same 13 km perilune and 102.1° inclination) in inertial mode it cost slightly less delta-V: Standard: 13.519 tangent, -149.981 binormal, 150.589 m/s total Inertial: -55.444 tangent, -134.587 binormal, 145.560 m/s total, about 5 m/s less despite the large anti-tangent component. I got nearly the same Earth perigee 3 days later (only 150 m lower) so it really was an equivalent burn. And in addition to the 5 m/s saved by the inertial burn itself, I saved another 19 m/s on corrections that I had to do with the difficult-to-execute-properly rotating burn, ending up with 105 m/s left over instead of 81 m/s once on the final Earth return trajectory. So I think it may still be worth considering to make inertial burns the default, or at least a global setting that defaults to this, to avoid Principia beginners such as myself falling into the trap of expecting inertial burns after being trained to do it that way during years of KSP maneuvers. Either way I'll try to update the wiki docs on this toggle to make it clearer what it means.
  10. Well, I think I now figured it out, I was intuitively expecting the plane change burn to be "inertially fixed" like all burns in stock KSP, but Principia expected me to follow the maneuver node marker that moves across the navball as the tangent vector rotates. The explanation of that setting could perhaps use some clarification, it seems to imply that it only matters for spin-stabilized spacecraft, not that if you don't set it you actively have to rotate the craft while burning to achieve the planned flight path. So if I instead "manually" pointed in the direction that would've been indicated for an inertially fixed burn (before realizing that's what I was doing), I got the right flight path. However, I still don't understand why it's not set by default, it seems like rotating the spacecraft during a burn by 30 to 60 degrees (as happens with major plane changes) uses substantially more delta-V than just burning in an inertially fixed way. Also, following the moving node around the navball makes the burn quite imprecise to execute. You have to start the rotation before the burn and make it pass through the marker just as the burn is supposed to start, or start rotating hard when you start the burn and try to control the rotation rate throughout. Is there any advantage to non-inertially-fixed burns? I can see that it might help with extremely long-duration burns close to the atmosphere/surface, where initially the periapse might otherwise drop dangerously low, but in general it seems to offer far more disadvantages?
  11. How does the flight planner "time base" work? From the term "End of maneuver #1" one would expect that the time of maneuver #2 moves accordingly when I move maneuver #1 in time. However it stays at the same time as planned originally. This makes it very hard to plan flights with multiple burns, for instance a return from the moon with #1 tangent burn into an elliptical lunar orbit, then #2 plane change at apolune, and #3 Earth transfer tangent burn at the following perilune. Ideally I'd like to play with the initial time to get a good perigee, however if I move it the other maneuvers will no longer be at apolune/perilune, but offset by the amount of time I moved maneuver #1 and so I continuously have to adjust all three at the same time. Am I doing it wrong or do I understand it wrong? Is there a way to change the time base of maneuvers to work like what I want?
  12. RSS comes with a RemoteTech patch (RemoteTech_Settings.cfg), you can probably just delete that, or remove everything but the Cape Canaveral station from it.
  13. Alright, that kind of makes sense, although I'd still expect the maneuver node to be in the right place, and not off by about 10 degrees, since the required direction of thrust should be the same regardless of the plotting frame and its tangent/normal/binormal directions. I don't understand why a different planning frame should affect that. Anyway, in my screenshots it seems that the blue marker is actually in the same place for both frames. But it's the wrong place for the planned maneuver. So what's the proper way of planning an intercept then if it can't be done in the target frame, which is after all the only way I can see how close the intercept will be? Is it enough to roughly create the new maneuver in the inertial frame, and then switch to the target frame for fine tuning? And obviously I need to fine-tune the maneuver execution in the target frame as well. Though I'm actually pretty sure that I've done this, because planning the maneuver time required seeing the apolune in the MCI frame. So I created the maneuver in the MCI frame, changed the binormal value for a plane change to roughly the target plane, and then switched to target frame to fine-tune the intercept.
  14. OK, I don't know which perspective and frame would show it most clearly so I uploaded several others to https://imgur.com/a/kbXiQdI. And I've learned pretty quickly to always rebase after a maneuver, so that wasn't the problem here.
  15. It seems that when planning a maneuver with with significant off-tangent components, the maneuver node on the navball is not always placed correctly. I had to aim several degrees off from it (see screenshot), about half-way between the maneuver node and the target -binormal vector instead (where the maneuver node ended up after moving around during the first wrong burn). I was trying to do a plane change intercept for a rescue operation on the Moon, at apolune of a highly elliptical orbit, with mostly -binormal delta-v. The planned separation was 200 m, but when I aimed for the maneuver node on the navball, I ended up on a way different orbit with 75 km separation with a 50 m/s tangent/normal correction needed. Same when I reloaded and aimed at the binormal node instead. I had to aim half-way in between and got it down to 3 km separation and "only" 6 m/s correction needed afterwards. Or did I do something wrong here? I can provide a savegame a few seconds before the burn but I use a bunch of mods (USI, SpaceY) and several custom ModManager patches so it will probably be difficult to use...
  • Create New...