The-Grim-Sleeper

Errmmm. I'd like that 'feature' removed, or at least better reflected in the descriptions (altough yes, on reflection, the level up button did say 'lvl 0 -> lvl 1, and not lvl 1 -> lvl 2). I was about to file a bug report. But beyond that, Field Training Labs works fine with KSP v1.12.2!

I am having some difficulties here. Below the last checkpoint there is some empty space and then the 'Checkpoint mode | add new checkpoint' buttons. I am using Firefox 95.0.2 if that could be relevant.

Just found this tool going to try it later today. Questions: Does using the 'Route Type: effecient' effecivly calculate a gravity assist via the intermediaries, or is it more like a full stop and awaiting a favorable transfer to the next leg? Is there a way to tally up the total Delta-v for a mission. If not, (where) can I request the feature to display the sum of the Delta-v for all the legs of the trip in vacuum and/or in non-zero admospheric pressure?

Bug report/feature request: When I manually rename a maneuver node alarm, don't rename it back to the craft name, and give to option to unlink the alarm from the node, so if the node is deleted, the alarm can stay. I like to use Maneuver node to get an estimate on the time to switch back to do something that isn't an actual maneuver. Yes, I can turn off the auto-rename, but I actually like that on most of the time, just not when I need a little bit more info on the name tag.

I donno. I do wonder how much KAC you'd need to have installed to trick other mods into cooperation. I can't really speak for others preference. An alternative would be for somebody to pick up KAC again and give it the same 'replace stock button' as 'Alternate Resource Panel'. I do have another feature request: contract details on the alarm clock.

Moar feature requests: Closest Approach timer A pass-though so that mods trying to add a timer to 'Kerbal Alarm Clock' will be added to the stock alarm instead. Yes, it would be better if those mods are just updated properly, but imma ask anyway.

I am Patient zero of this issue and I just ran a quick test with NavInstuments-0.8.0.5. I still have more or less the same results. That said, I can confirm that reducing system load in minor ways seems to alleviate the issue, and having a lot of GUI elements open (but not NavInstuments Compass specifically) causes a lesser version of this problem with framerate and my system in general. NavInstuments is a big contributor, but that is probably due to the Compass being a bit more graphical than text-boxes used by most mods. It is indeed more a Linux-Unity problem, and is out-of-scope for any mods to fix. I will pursue other solutions to this problem.

That would be great. I'd have to defer to Ser (or Kujuman) for a full adoption, but having a 1.12 version would at least allow me to continue troubleshooting during my normal play-time.

Thank you. I am trying to compile a version with debug logging enabled (GlobalVariables.cs, ln 84 bool enableDebugging = false), but even a simple recompile is an uphill battle. Looks like my references list is to blame, but a full import of KSP_Data/managed just causes conflicts and versioning errors. I've run out of time to work on this. Welp, I'll just have to make do without this one for a while.

I am having a malfunction with This specific scenario. For reference, I've turned off engineers for parachutes requirements (I'd like to leave that on if possible, but this is for troubleshooting) I have a craft with 3 seats (Mk1 command pod, Mk1 Crew Cabin). Assigned crew: Valentina (pilot), Clauke (tourist) and Melnard (tourist). And saved this status Going to launch with these settings works fine. But any change to the craft (adding or removing any part), loading the same craft, or reverting to VAB causes the crew assignment to be scrambled: Valentina (pilot), Corrim (tourist) and Dunbus (tourist). These 2 are simply the first 2 tourists in the available crew list; the names of the tourists are not properly saved with the craft. Log file: KSP(BetterCrewAssignmentScramble).log

I'm using this mod with Contract pack: Tourism Plus in KSP 1.12.2, but I am experiencing some crew-ing issues: assigned tourists keep getting bumped in favor of Lvl1 engineers and random tourists. (Yeah my 1-use $8k and seven bottlecaps craft lands with parachutes) I take it that this is something that can be resolved with the module manager file, line 107, importance of engineers for parachute modules. But I am a not sure how this field works. Does a higher value for importance mean that it gets a higher priority? Are negative values allowed? Is there a way to set the 'profession = tourist' importance to make sure planned tourism flights get their assigned passenger load-out, even at the cost of 'vital personnel'?

Just did that complete refresh, with JUST NavUtilities and nothing else. Complete starting directory wipe, fresh install from steam, all local dependencies up-to-date. The stutter starts whenever the NavUtilities-radar is open and I hold right mouse to move the view. IVA is fine, rotating the camera without the NavUtilities-radar open is fine. No if/and/or/but about it: NavUtilities does not function properly. The scenario for this issue is consistent. This issue is systemic. It might be because of something on my system, but this issue is not part of KSP vanilla or related to any other mods. If anybody has a log file that could be used to make a comparison, knows some way to turn on debug mode for NavUtilities or knows where @Ser keeps the source code, I could look at that. Until that happens, I can not do anything. MOAR logs: https://drive.google.com/file/d/1zsFmOCvbLPk4V8fTq67KsyQGCPIMAHIs/view?usp=sharing

I don't and I think that is why our experience is different. IVA the nav utils work fine, but 3rd person vehicle view causes me problems. Could you share an assessment of your frame-rate when using that view-mode?

I just tried this and weirdly enough, there is a positive effect, but no real solution. In Kerbal-perspective mode, a tap of Right Mouse Button to enable free-look, the stutter quickly fades and stays away, even when I switch back the external view. But if the free-look is turn off, and Right Mouse Button is held down enable free-look in the external view, the stutter comes back with gusto. Rukhafi, do you use RPM? Or otherwise fly a lot in Kerbal-perspective mode? Does anybody know if there is there some way to turn on a sort of debug mode for NavUtils?

Change the camera as in change the angle or the view mode?

Can you share a .log file of your game when this occurs? I want to look if there is any notable overlap between our cases.

Just did a quick check with just NavUtilities on Stock KSP, and I get severe frame rate stutter if the NavUtilities-radar is open while I turn the camera. If the radar window is closed, the stuttering disappears/does not happen. Logs: https://drive.google.com/file/d/1eOeoam7mBeDC-O9v2ujDjHfYjuzR4MiM/view?usp=sharing https://drive.google.com/file/d/1ONnuZPukJGw4L_QF6TCaqBWOXxYoyVMk/view?usp=sharing

I am having serious problems while using this mod in KSP 1.12.2. Whenever the NavUtilities box is open, either just launched from the toolbar or already active when a save is loaded, my computer slows to a crawl, and KSP itself is effectively frozen. I am under the impression that the slowdown starts the moment the box is open, and reaches a critical state after about a second. This allows for a brief window of interaction, but I wouldn't know where to start with troubleshooting. Log file link below. I gave it a quick look-through, but I didn't see any obvious signals. I cannot exclude the possibility that this is caused by a weird system interaction outside KSP. I will list my system spec just in case it is: Linux Ubuntu 18.04 KSP 1.12.2 (with Making History 1.12 and Breaking Ground 1.7.1) NavUtilities version 0.7.2 (acquired via CKAN) Log file on google drive: https://drive.google.com/file/d/1mrME5DICrwW9r7YgjJcJ2ytgOGJKoE9N/view?usp=sharing

I can confirm this issue in version 1.8.3.6 of AFBW with KSP 1.12.2 in ubuntu 18.04. Local name of lib-file is: libSDL2-2.0.so.0 libSDL2-2.0.so.0.8.0 I can also confirm that reverting to version 1.8.3.3 of AFBW fixes the problem. .log file in link below, but I am willing to bet the relevant lines are the ones in the code-block: [EXC 22:51:05.971] DllNotFoundException: libSDL2-2.14 KSPAdvancedFlyByWire.SDLController.InitializeSDL () (at <2905308acfc04190829794ba2853e45a>:0) KSPAdvancedFlyByWire.SDLController.SDLUpdateState () (at <2905308acfc04190829794ba2853e45a>:0) KSPAdvancedFlyByWire.AdvancedFlyByWire.Update () (at <2905308acfc04190829794ba2853e45a>:0) UnityEngine.DebugLogHandler:LogException(Exception, Object) ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object) UnityEngine.Debug:CallOverridenDebugHandler(Exception, Object) Google drive link: https://drive.google.com/file/d/14cEmHmqcl__ZTjltHljyvH2bz0YJeec9/view?usp=sharing

So at this moment, DBS doesn't make use of the toolbar mod (first made by Blizzy78, now maintained by linuxgurugamer). I wanted to ask if that is a feature that is either planned for some future release. a stretch goal too far-flung for anything more then a 'probably not'. a won't-do on principle, even if somebody else was to offer a pull request to make it so.

I am vaguely under the impression that some of the shoulder/chine segments are slightly model and/or texture mismatched. 2 long Mk3 chine segments, placed end to end will not align, but if one of them is flipped, it will match up. Likewise, the long chine segments will rare line up properly with chine caps or chine RCS blocks. I don't know enough about 3D modeling to troubleshoot this issue. What can I do to help?

A whole lot of docking ports, to make ridiculous ring stations. Yeah, I haven't really found a satisfactory solution either. I was kinda hoping that this change would be reverted. I used to have a lot of fun EVA-strutting my stations together.

Not at all; it is more like a twitch I got when I tried my hand at making a GUI a long time ago. Initial development of that caused a lot off lag, because the 'put info from gui into memory'-step would run way to often. My quick fix for that is to make a button that does that job specifically. But a lot of users would get frustrated that some of their input was 'forgotten' because they were accustomed to more advanced GUI-stuff that I could not provide or understand. So I got a lot of emails and had to respond allot with 'it works fine, you just didn't do the thing'.

I can confirm that in version 1.11, parts placed in inflight construction will form recoupler-joints, after the recoupler menu is opened and the settings applied. 100% in line expected behavior: the links will be made once the player says they should. (pics in spoiler below) It is also possible to remove links using the existing system. It is also possible to deconstruct parts after the recoupler-joints have been removed. Removing a part that has recoupler-joints active (but in stock ksp would not have any attached parts) will cause instant kraken. (Removing a part that has attached parts will produce the usual warning) Part removal is very hard on the frame-rate, but I have no idea if that is part of the vanilla experience or due to any mods I have installed, inc recoupler looked into it and it was caused by Ferram Aerospace Research Continued; their thread is currently a frenzy of debugging activity.

You might be looking for the ''Recoupler" mod by Booots: