Jump to content

[1.8 - 1.12] KSPCommunityFixes - Bugfixes and QoL tweaks


Gotmachine
 Share

Recommended Posts

Thank you for this mod. I discovered that the huge amount of inventory slots for the Hitchhiker container meant that the dialog box for transferring Tourist Kerbals to other pods was mostly off my screen and therefore unusable. Therefore the basic early-mid career contracts of ferrying 3-4 Tourists to the Mun/Minmus were made impossible to do with the Hitchhiker. I was disappointed that there was no way to collapse this huge waste of UI space, and then I was delighted when I found out that the community came together to fix the issue.

Link to comment
Share on other sites

21 hours ago, Gotmachine said:

 

  • New performance tweak : TextureLoaderOptimizations [KSP 1.10.0 - 1.12.3]
    Speedup loading time by caching on disk the PNG textures KSP converts to DXT5 on every launch. Also make PNG @thumbs cargo part textures non-readable to free some RAM. This patch has no entry in settings.cfg, but is opt-in (a popup is shown on first KSP launch) and can be disabled latter in the in-game settings menu.

Why no cfg-settings-entry? I mean, why open up a second place, where someone can set up the desired settings for this Mod? 

Edited by Rakete
Link to comment
Share on other sites

22 minutes ago, Rakete said:

Why no cfg-settings-entry?

Since this optimization is patching the texture loader, it has to execute right away on KSP launch, before the asset loading phase.
ModuleManager executes during the asset loading phase and the patched configs are only available after that. This mean that this specific KSPCF patch can't make use of a MM patch to be enabled/disabled.
So while I could have kept an entry in settings.cfg, having it "immune" to a MM patch trying to change it would have been incoherent and confusing.

Beside, because this optimization can potentially lead to a lot of additional used disk space (depends on what mods you have and how they package their textures), I prefer to have that mandatory opt-in popup to warn the user.

Link to comment
Share on other sites

1 hour ago, Gotmachine said:

Beside, because this optimization can potentially lead to a lot of additional used disk space (depends on what mods you have and how they package their textures), I prefer to have that mandatory opt-in popup to warn the user.

Yeah, that's the reason I would like to opt-out before loading/executing anything of this special Fix/Optimization. Mhh... Does disabeling this caching afterwards in the menue delete the cache folder created for this - or does the user have to deep dive into the folders to find the disk space muncher :cool:

Anyway, I feel this could be separated from the rest of the mod by an extras-folder.

Little bugreport for the buyoncy patch. If I enable this patch the more complex vehicles break apart upon a parachuted waterlanding. Maybe the re-enabling of the buyoncy calculator happens too late? Especially bigger vehicles don't enter the water in a single frame. E.g. i have an SSTO which can emergency land in water by parachutes. It breaks apart upon using the performance fix.

Link to comment
Share on other sites

8 minutes ago, Rakete said:

that's the reason I would like to opt-out before loading/executing anything of this special Fix/Optimization.

Then just opt-out in the popup.

8 minutes ago, Rakete said:

Does disabeling this caching afterwards in the menue delete the cache folder created for this

Yes (although not immediately, it will be deleted on the next KSP launch).

10 minutes ago, Rakete said:

If I enable this patch the more complex vehicles break apart upon a parachuted waterlanding

Giving me a reproducible test case (ideally a craft or save file with only stock parts, or a minimal amount of modded parts alongside the mod list) would help.

Link to comment
Share on other sites

@Gotmachine

Here an example SSTO. (available only for 7 days for download cause the filehoster is free :-) )

https://www.filemail.com/d/ikubflaplrpwdrm

Did several tests with it. With your patch: Breaks upon water entry reproduceable. Without buyoncy patch: does not break in the splash moment reproduceable.

Test scenario: Fly  fully crewed SSTO over water, drain all fuel (press AG 6 and 7 to open Ox and LF valves - emergency landings require empty tanks)... stage through until all emergency parachutes open. Let it glide into the water.

Vehicle is fully stock (KSP may moan, cause it does not find waterfall if you try it in a fully stock environment - that's the only non-stock-thing about it (Waterfall + Stock waterfall effects), that KSP may want complain about... Happens in a clean stock 1.12.3 install for me.

When does the buyoncy integrator re-enable? upon situation = splashed down ? or upon situation = flying low?

 

Otherwise: just have fun with this little SSTO :-) (Normal Flight scenario is written in the part description ingame (unfortunately in german))

 

 

 

(It is my Phoenix from this post in the latest iteration:

For all the others here: You may also have fun with the craft, If you like it.

Edited by Rakete
Link to comment
Share on other sites

@Gotmachine
I'm trying the new version on 1.10.1 and can't even load the game properly. 

When I'm trying to load the game with some mods, it just hangs on a texture from KAS:
JGkigdz.jpg

Then I remove KAS and it hangs on a texture from Making History dlc:

i7x2fIk.jpg

Both of the textures are normal map textures. Don't know if that has something to do with anything. 

Update: apparently there is something. The game seems to only hang on texture names that end with NRM.png, even on the clean install.
rRWNNHY.jpg



Here are the things:

KAS Hang KSP.log: https://drive.google.com/file/d/1jyNXmHLAKFE2WEZK85_mlAxKPXFD5AZm
KAS Hang Player.log: https://drive.google.com/file/d/1s9gQQ92ZhO480yzmG3rk1V3u5vkNIyZR

Making History Hang KSP.log: https://drive.google.com/file/d/1jbDS---X6BXFeRBPd7YJcwNKagHpJ3ST
Making History Hang Player.log: https://drive.google.com/file/d/1gWqpuWz2xm3H63oQnDm6qprkp2fi9y6C


There's definitely some stuff happening at the end of these logs. 

Edited by dok_377
Added some stuff and removed irrelevant info.
Link to comment
Share on other sites

Addendum to my previous post:

The dockingport-twistfix does not work properly: here some docked Sr. Ports,  I tried to rotate - they bend around the wrong axis):

LbsK2yh.png

 

I could provide a Savefile for this. but unlike my SSTO from the previous post (which was stock) for the buyoncy issue, you'd need all of those mods (mostly Nertea-Stuff) for the complete savefile for this dockingport issue: (But none of them affect the sr. docking ports)

VNahXn1.png

If you want to track this dockingport issue down, here is my savefile:

https://www.filemail.com/d/lwiotjwxskxkhqu

Just load the quicksave - it should put you directly to the shown station. Just play around with the docking port's twisting option.

Edited by Rakete
Link to comment
Share on other sites

Posted (edited)
1 hour ago, dok_377 said:

I'm trying the new version on 1.10.1 and can't even load the game properly. 

Whoops. ModuleManager is right, I'm using something in Unity that isn't available in versions older than 1.12.
Turns out I did some modifications after I checked compatibility with older versions.
I will push an update that limit this patch to 1.12 ASAP.

2 hours ago, Rakete said:

Did several tests with it. With your patch: Breaks upon water entry reproduceable. Without buyoncy patch: does not break in the splash moment reproduceable.

I can't reproduce it.

Did the test in a pure stock install and in another with KSPCommunityFixes, with the vessel fully drained of all LF/OX hitting the water at a consistent 8.3 m/s.
Parachutes pre-deployed and teleporting the vessel at 200m altitude and SAS disabled, in order to hit the water with exactly the same angle every time.
It neither break in stock or with KSPCF, tested five times in each.

But if I force the vessel orientation to be slightly different, I can manage to break it under the same conditions, both in stock and with KSPCF.
The vessel has several underbelly parts having only a crash resistance of 6 m/s  (FL-T400, FL-TX1800), so depending at what angle you hit the water, those parts will break easily.
With the tanks about 25% full, I'm hitting the water at 9.4 m/s and the vessel consistently breaks in both installs.

I also double checked that the part buoyancy integrator is running in all those tests.

1 hour ago, Rakete said:

The dockingport-twistfix does not work properly: here some docked Sr. Ports,  I tried to rotate:

I think I know what's going on, I will look into it latter.

Edit : Just opened your save. Can't reproduce it. Are you sure you're on the latest KSPCF version (and that the patch is enabled) ?
There is such an issue (docking port rotating around the wrong axis) in stock (so it would happen if the "DockingPortRotationDriftAndFixes" patch isn't enabled), and I didn't fix it until KSPCF 1.10.1

Edit2 : Ok, turns out it happens on one side and not the other. Will look into it.
Aaand it's autostruts...
I will look into how to fix it.
In the meantime, you can avoid it by ensuring both docking ports are unlocked ("Rotation gesperrt") before attempting to rotate.

Edited by Gotmachine
Link to comment
Share on other sites

V1.11.1 is out.

Available from GitHub and CKAN.

Changes in that release :

  • TextureLoaderOptimizations hotfix : was causing loading to hang on KSP 1.10 and 1.11 due to using an Unity method only available since KSP 1.12. Will restore compatibility later, for now the patch is disabled for all versions below 1.12.
  • AutoStrutDrift bugfix : fixed potential ArgumentOutOfRangeException.

Thanks to @Rakete and @dok_377 for the bug reports.

Link to comment
Share on other sites

7 hours ago, Gotmachine said:

Whoops. ModuleManager is right, I'm using something in Unity that isn't available in versions older than 1.12.
Turns out I did some modifications after I checked compatibility with older versions.
I will push an update that limit this patch to 1.12 ASAP.

I can't reproduce it.

Did the test in a pure stock install and in another with KSPCommunityFixes, with the vessel fully drained of all LF/OX hitting the water at a consistent 8.3 m/s.
Parachutes pre-deployed and teleporting the vessel at 200m altitude and SAS disabled, in order to hit the water with exactly the same angle every time.
It neither break in stock or with KSPCF, tested five times in each.

But if I force the vessel orientation to be slightly different, I can manage to break it under the same conditions, both in stock and with KSPCF.
The vessel has several underbelly parts having only a crash resistance of 6 m/s  (FL-T400, FL-TX1800), so depending at what angle you hit the water, those parts will break easily.
With the tanks about 25% full, I'm hitting the water at 9.4 m/s and the vessel consistently breaks in both installs.

I also double checked that the part buoyancy integrator is running in all those tests.

I think I know what's going on, I will look into it latter.

Edit : Just opened your save. Can't reproduce it. Are you sure you're on the latest KSPCF version (and that the patch is enabled) ?
There is such an issue (docking port rotating around the wrong axis) in stock (so it would happen if the "DockingPortRotationDriftAndFixes" patch isn't enabled), and I didn't fix it until KSPCF 1.10.1

Edit2 : Ok, turns out it happens on one side and not the other. Will look into it.
Aaand it's autostruts...
I will look into how to fix it.
In the meantime, you can avoid it by ensuring both docking ports are unlocked ("Rotation gesperrt") before attempting to rotate.

Buyoancy: Mhhh strange.... in my tests there was a difference, but i did not test it twenty times only two to three times. Mhh.. then ignore my input. :wink:

 

Rotation of ports: So it will not happen, if I unlock both opposed ports? I will try it tomorrow or so. Today it's too late. (Almost after midnight in my timezone). 

And yes i had KSPCF 1.10.1 installed.

Edited by Rakete
Link to comment
Share on other sites

V1.11.2 is out.

Available from GitHub and CKAN.

Changes in that release :

  • TextureLoaderOptimizations : restored compatibility with KSP 1.10 and 1.11
  • DockingPortRotationDriftAndFixes : fixed autostruts crossing docking ports not being disabled if only one of the port pair is rotation-unlocked.
Link to comment
Share on other sites

1 hour ago, Gotmachine said:

V1.11.2 is out.

Available from GitHub and CKAN.

Changes in that release :

  • TextureLoaderOptimizations : restored compatibility with KSP 1.10 and 1.11
  • DockingPortRotationDriftAndFixes : fixed autostruts crossing docking ports not being disabled if only one of the port pair is rotation-unlocked.

Just a question for understanding: when (both) the dockingports are unlocked, the crossing autostruts are disabled? And after locking them again the autostruts are re-connected?

Link to comment
Share on other sites

22 minutes ago, Rakete said:

Just a question for understanding: when (both) the dockingports are unlocked, the crossing autostruts are disabled? And after locking them again the autostruts are re-connected?

Yes and yes.
And to be clear, this will happen even if only one docking port is unlocked. To have autostruts crossing docking ports, you have to make sure both ports are locked.
And side note : you can visualize autostruts in flight (or in the editor) by going into the ALT+F12 menu > Physics > Visualize Autostruts

Link to comment
Share on other sites

5 hours ago, Gotmachine said:

Yes and yes.
And to be clear, this will happen even if only one docking port is unlocked. 

But only for the new patch. For the versions before I have to unlock both of them, right? Hadn't got the time to increment my KSPCF version yet.

Link to comment
Share on other sites

A small QoL feature could be to show the full list of action groups, including the custom ones, by default in the editor. Instead of now having to click on an item to be able to see the custom groups. Basically reverting it to how it was a few KSP versions ago.

Link to comment
Share on other sites

On 4/16/2022 at 10:20 AM, Rakete said:

But only for the new patch. For the versions before I have to unlock both of them, right? Hadn't got the time to increment my KSPCF version yet.

Correct.

Link to comment
Share on other sites

V1.12.0 is out.

Available from GitHub and CKAN.

Changes in that release :

  • New QoL patch : AutoSavedCraftNameAtLaunch [KSP 1.8.0 - 1.12.3]
    Append [Auto-Saved Ship] when relevant in the Launchpad / Runway UI.
    AutoSavedCraftNameAtLaunch.png
  • New KSP bugfix : StockAlarmDescPreserveLineBreak [KSP 1.12.0 - 1.12.3]
    Stock alarm preserve line breaks (and tabs) in the description field.
  • New KSP bugfix : DeltaVHideWhenDisabled [KSP 1.12.0 - 1.12.3]
    Hide the stock stage delta-v UI elements and navball extended burn info when DELTAV_CALCULATIONS_ENABLED and DELTAV_APP_ENABLED are disabled by another mod or in the KSP settings.cfg file. Courtesy of @NathanKell
Link to comment
Share on other sites

Bugfixproposal: 

Runway/Launchpad-UI only lists Vessels in the root directory of the VAB/SPH. Vesselfiles in subdirectorys of KSPs own 1.12-vessel-directorysystem are not found. Usefull would it be to have a similar UI Loading window for Launchpad/Runways as in the VAB/SPH with shown directories

Edited by Rakete
Link to comment
Share on other sites

QoL-Proposal:

The stock burntime-calculator needs a switchbutton (not in the menue. Rather directly in the flight scene) to calculate burntimes only for active already staged engines (Usecase 1) and all already staged engines (Usecase 2).

Usecase 1: SSTOs where you intentionally shut off e.g. the rapiers and only leave the nerv engines on. Here you need only the calculations for active engines

Usecase 2: The Far future engines by Nertea, where some of which are always offline until ignition (e.g. the antimatter ones). This can currently only be worked around by using KER... but KER doesn't function in Usecase 1. So an all-in-one-thing would be good. Here you'd need the burn time calculations for all (even offline) already staged engines.

 

Also: the stock dV calculator is subject to incorrect dV calculations for some mods. E.g. I could provide a craft with e.g. some engines from the Nertea cosmos, where the stock system says e.g. 100 m/s dV, but KER does correctly calculate 7.xxx m/s dV for the stage. So the stock calculations in flight are not as robust, as KERs calculations are. Funnily KSP calculates the dV in the VAB correctly for vacuum, but not in the flight scene.

Edited by Rakete
Link to comment
Share on other sites

9 minutes ago, Rakete said:

Usefull would it be to have a similar UI Loading window for Launchpad/Runways as in the VAB/SPH with shown directories

Well, there are already a bunch of related launchpad/runway dialog UI suggestions on the github issue tracker.
I agree that the stock UI is quite lacking, and while I could see a replacement being a KSPCF feature, this would be quite a bit of work and I personally don't care much (mainly because I almost never use the launchpad/runway UI).
I will accept contributions on the matter (as long as they are of reasonable quality), but this is something I will probably never work on myself.

Link to comment
Share on other sites

2 minutes ago, Gotmachine said:

Well, there are already a bunch of related launchpad/runway dialog UI suggestions on the github issue tracker.
I agree that the stock UI is quite lacking, and while I could see a replacement being a KSPCF feature, this would be quite a bit of work and I personally don't care much (mainly because I almost never use the launchpad/runway UI).
I will accept contributions on the matter (as long as they are of reasonable quality), but this is something I will probably never work on myself.

Alright, it was just a proposal. :) 

Maybe the other proposals are more interesting for KSPCF?

Edited by Rakete
Link to comment
Share on other sites

4 minutes ago, Rakete said:

QoL-Proposal: [...] stock burntime-calculator

Same deal here. I'm not really interested in fixing anything related to the stock DV stuff. This is a complicated matter and there are already mods (KER, Mechjeb...) doing a much better job.
Ideally, those mods should be updated to override the stock DV calcs and hijack the stock DV UI.
This would take much less effort than trying to fix the stock DV calcs.

Note that the "Basic Delta-V" mod is exactly that, it reuse the KER calculations to feed the stock UI :

Unfortunately, it is more or less abandoned and doesn't work in recent KSP versions.

Link to comment
Share on other sites

46 minutes ago, Gotmachine said:

Same deal here. I'm not really interested in fixing anything related to the stock DV stuff. This is a complicated matter and there are already mods (KER, Mechjeb...) doing a much better job.
Ideally, those mods should be updated to override the stock DV calcs and hijack the stock DV UI.
This would take much less effort than trying to fix the stock DV calcs.

Note that the "Basic Delta-V" mod is exactly that, it reuse the KER calculations to feed the stock UI :

Unfortunately, it is more or less abandoned and doesn't work in recent KSP versions.

Again: it were just proposals as I tend to be a fan of your efforts to fix that bugmonster KSP. 

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...