jd284

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.

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.

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.

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?

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.

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 9.10.0.1710957 (R2021a) Update 4 DATE: 2021/10/01 15:38:59 ======================================== Switching to hardware OpenGL rendering at runtime on unix is not supported.

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?

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.

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.

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?

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?

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.

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.

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.

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...

Is there a way to disable the stock clock app? I keep clicking the wrong clock icon... Also can I change the font size of the KAC window without also changing all other app UIs? I'd prefer a smaller font to see more alarms at once. I thought it would be the "UIScaleOverride" in settings.cfg, but it keeps getting set to "false" as soon as I load the game.

Adding version 112 of WOLF to GameData/UmbraSpaceIndustries causes a hang/crash at "Loading Part Upgrades" on KSP 1.12.2 on Linux, I guess it's still missing the "File Version" in the DLL assembly. All the other MKS mods are fine though.

Alright, in regards to my question above, I think I found a neat way of doing this. After calculating various orbital periods, I realized that to achieve a 120° phase angle, i.e. 1/3 orbit, I could make a transfer with an orbital period of 4/3 the original, or in general (3N+1)/3N and the phase angle would be right after N orbits. So I picked 28/27, and boosted prograde for a bit until there were enough visible "rosettes", I counted off the 27th encounter (I'd be doing 27 orbits plus the one orbit indicated by the rosettes, so 28 while the target does 27), and boosted prograde until that encounter matched my current position. At that point everything lined up very neatly again, which I took for a good sign. I guess I'll know if it worked in a few days... but the orbital period seems correct, my 4:26:01.5 is 28/27 of the primary 4:16:31.5. [edit] I just realized that, counting off the 9 encounters after which the phasing should be right, I realized that it was about 120° away from my current position, so I guess that's another good sign. But making the rosettes align was definitely more precise than eyeballing the angle would've been. I've gotta say, I'm extremely impressed with Principia and how it displays the various references frames, thanks everyone for the great work! I don't know if it's worth a ticket, but for the above it definitely would've helped to have a counter for the encounters so I wouldn't have to count the markers manually.

What is a good way of planning constellation maneuvers? For instance, my first relay satellite network would have 3 satellites at 120° phase angle in a 7000 km orbit around Earth. My launcher will place them all there at once, and then two of the satellites would then do a phase change maneuver to place themselves at the right separation along the orbit. In vanilla KSP I would just place dummy maneuver markers and then execute burns until the apsis time matched the time of the respective maneuver marker. With Principia, I can't easily place arbitrary maneuver markers anymore, but I think the rendezvous targeting frame would work really well for this, if only I could set a "virtual" target at +/- 120° phase angle of the primary satellite. Is that possible somehow? Or some other easy way of achieving equal separation along an orbit? I searched this topic for similar questions but found nothing using the obvious keywords. Or do I have to manually calculate the transfer orbits based on the orbital period?

Point taken, I guess I disregarded that paragraph because of the "Windows" heading, not realizing that the SIGABRT is relevant for Linux instead...

I'm running KSP 1.12.1 on Ubuntu 21.04 (Hirsute), and tried adding this mod (Grossmann version), together with RSS (although the problems described here also apply to an otherwise vanilla install with only Principia). First I got the "loading part upgrades" hang, I was able to fix that by deleting the DLLs in the x64 folder which shouldn't be needed on Linux. Then I got to the start menu showing Earth, but a popup told me to install libc++abi1-8. However, Hirsute only has libc++abi1-12 so I installed that, and ldd was happy. The popup went away, but I got a crash instead, with the log message That was no surprise, because in 1.12 the KSP_Data/Mono directory doesn't even exist anymore. I don't know why it was looking there however (my CWD is definitely the main KSP directory, and it certainly wouldn't be a non-existing directory), but I just created the folders referenced and symlinked to the real .so file, and that message went away, but I was still left with the same crash log as above. So is there anything else I could try? Should I just wait for official 1.12.1 support? I also tried manually installing libc++abi1-8 from Groovy but no dice. [edit] Right, as usual the best way to figure out a solution is to type out a post... so I noticed the glog directory now (would probably be helpful to mention that on the Readme and/or bug reporting page), and saw that it aborted because of the wrong KSP version. And with the appropriate principia_override_version_check it seems to be working fine now! Duh...

Yeah, thanks, that was it. I did look at the issues but didn't realize it was a drill issue rather than a TCS issue...

Is there a description of this? But anyway my problem isn't that the separators don't produce what they should (they do), but that they overheat doing so. You seem to confuse MEU-500 (the drill) and TCS (the ranger heat pump). But yes you're right, when I tried it again additional cooling systems (ranger TCS or radiators) didn't help actually. So the problem is that the drill can't move its heat fast enough to the cooling systems. But still that doesn't make sense, why would the drill have three separator bits when you can only use one of them at full efficiency without it overheating? That actually makes the bigger drills less efficient and more expensive than many smaller drills adding up to the same production capability, which the TCS can cool with no problems. I doubt that's the intended behavior.

Did the Ranger Thermal Control System get super-nerfed? I used to be able to have just one of these for a whole base of nuclear reactors and dozens of drills, now it's not even enough to cool two bits of a MEU-500 drill. If I have one bit running it's at 500K, but two bits it's 622K (only 63% efficiency) and three bits it's 667K (41% efficiency). It doesn't even matter whether there's an engineer present and the drills run at 65% load, or not and they run at 3.5% load. Strangely enough this is true even for multiple drills, so it's not a problem of the TCS being overloaded but it not getting the heat away from the drills, it seems. Either way at the moment I need three TCS for every two drills... so it's pretty useless. Or is this a KSP bug itself?

Is it possible to reduce the volume of the warp sound effect? It seems to be extremely loud compared to other sounds in the game. I basically have to turn off my speakers when warp is active. [edit] So after looking into this a bit more, I changed the drives to ModuleEnginesFX and defined an EFFECTS section accordingly. If anyone wants to try, download the files from https://github.com/jd284/WarpDrive/tree/patch-1/FOR_RELEASE/GameData/UmbraSpaceIndustries/WarpDrive/Parts I noticed the older parts have some particle effects which I left alone, not sure if they still work or if they also need an entry in the EFFECTS section now. But if so I don't know how to do this correctly. Should I make a PR for this anyway?