[1.8 - 1.12] KSPCommunityFixes - Bugfixes and QoL tweaks

[JonnyOThan]

1 hour ago, Gotmachine said:

Okay, this has nothing to do with the path of the install, sorry for that.

Since mipmap level is in the settings.cfg of the root folder that’s probably where the red herring came from.

[Scottmm78]

3 hours ago, Gotmachine said:

The file is correctly found, that's not the issue.

Okay, this has nothing to do with the path of the install, sorry for that.
This is caused by having a lower than max global mipmap level active during loading.
The workaround is to set "texture quality" to "full res" in the KSP main menu video settings (and given that you have quite decent hardware, you probably should anyway), then to restart the game.
But I will investigate how to avoid that issue anyway.

Ok setting the Texture to Full did the trick. I don't think I would have ever figured that out. 

Thank you

[Krazy1]

Maybe someone can come up with at least a partial fix here... super annoyed trying to scan a surface feature with a scanning arm: "vessel moved, scan aborted" or "arm hit object, scan aborted" The KSP sliding bug combined with extreme sensitivity to movement makes it almost impossible to finish the scan. My ship was moving 6 mm/s and it still failed. Is a workaround like giving science credit at the beginning of the scan possible? Or somehow disabling the check for movement?

Edited May 4 by Krazy1
typo

[Gotmachine]

New release :

• FastLoader : fixed the PNG loader behavior not being similar as in stock. It was wrongly generating mipmaps, notably resulting in NPOT textures not showing when texture quality wasn't set to full resolution (see issue #224).
• FastLoader : fixed cached PNG textures loading not using the data loaded by the threaded reader, but instead reading the file again synchronously (!). Unsurprisingly, fixing that is massively improving texture loading time.

Thanks to @Scottmm78 for reporting the first issue.

22 hours ago, Krazy1 said:

Is a workaround like giving science credit at the beginning of the scan possible? Or somehow disabling the check for movement?

I will open an issue so I remember to take a look. It might be possible to bump a bit the "vessel moving" threshold.

[Rodger]

On 5/5/2024 at 8:21 AM, Krazy1 said:

Maybe someone can come up with at least a partial fix here... super annoyed trying to scan a surface feature with a scanning arm: "vessel moved, scan aborted" or "arm hit object, scan aborted" The KSP sliding bug combined with extreme sensitivity to movement makes it almost impossible to finish the scan. My ship was moving 6 mm/s and it still failed. Is a workaround like giving science credit at the beginning of the scan possible? Or somehow disabling the check for movement?

I made a patch for myself to address this issue a while ago, it might be worth a try:

@PART[RobotArmScanner_S*]:FINAL
{
    @MODULE[ModuleRobotArmScanner]
    {
        @cancelScanDistance = 1
        @emergencyStopDistanceFromSurface = 0.1
        @firstJointRotationLimit = 95
    }
}

Just copy that into a new txt file inside your GameData folder (I keep all my own patches inside a folder like "MyPatches" inside GameData to keep track of them), and change the extension from .txt to .cfg

[anis]

This looks amazing ! How can a group of modders surpass the devs like this ?!

I haven't tried it yet, but with a pretty bad config, this promises to help me immensely !

Amazing work done there

[Manul]

I'm trying to find a fix for hatch obstruction bug introduced in KSP 1.11 that makes hatch obstruction check ridiculously strict and makes many pre 1.11 built crafts unusable and some parts like Buffalo 2 side hatch useless (Kerbals can go in but can't go out). With this bug Kerbals can't EVA if there is any object within 2m distance from the airlock, before 1.11 update they could EVA into much tighter spaces.

KSP api documentation says that there are public attributes for PART class:

float Part.hatchObstructionCheckInwardDistance = 1.1f

float Part.hatchObstructionCheckInwardOffset = 1f float Part.hatchObstructionCheckOutwardDistance = 1f I tried to override these values in part config and it did work, all what's left is to test this "fix" for unforeseen consequences and find correct values for these parameters so that they represent the actual size of an EVA Kerbal. This is where I need help because it requires a lot of testing.

[JonnyOThan]

21 minutes ago, Manul said:

introduced in KSP 1.11

Should be easy enough for us to check what changed.

one of my mods (can’t remember if it’s FreeIVA or kerbalVR) forcibly changes these numbers because of false positives like you mention. So that’s at least one compatibility wrinkle…

[Manul]

12 minutes ago, JonnyOThan said:

Should be easy enough for us to check what changed.

Not sure that it was exactly 1.11, it's just the changelog says that they "made hatch obstruction checks more consistent". I skipped a few updates due to my "use stable updates only" approach and switched my main KSP install from 1.9 to 1.11.2 so I don't know exactly when that happened.

[flart]

Feature request:

Maybe it makes sense to generate all volumes at runtime in this mod,
because the KSPCF could also regenerate volumes if related settings is changed without requiring a game restart (how the KSP part volume works).

 

Feature request 2:

Option to disable all bodies except for home planet, its sun, its moons.
It is for quicker load / performance impovement if for testing purpose user do not need other bodies for now. 

Edited May 29 by flart

[JonnyOThan]

19 hours ago, flart said:

Feature request:

Maybe it makes sense to generate all volumes at runtime in this mod,
because the KSPCF could also regenerate volumes if related settings is changed without requiring a game restart (how the KSP part volume works).

 

Feature request 2:

Option to disable all bodies except for home planet, its sun, its moons.
It is for quicker load / performance impovement if for testing purpose user do not need other bodies for now. 

The first one is just Part Volumes without requiring a restart? Sounds like the feature request should be made to Part Volumes instead.

The second should be possible with a kopernicus patch, so not suitable for KSPCF.  I’d be surprised if it actually improves performance, but maybe…

If you’re looking for better performance when working on a mod, I suggest deleting the DLC, and all stock parts that you don’t need for actual testing. I can boot in ~20 seconds doing that. QuickStart is also helpful to shave off a few seconds of UI interactions.

[flart]

On 5/30/2024 at 1:31 PM, JonnyOThan said:

The second should be possible with a kopernicus patch, so not suitable for KSPCF.

So no possible optimization there, on Harmony level?  Like, for example, for the start of career temporary disable other planets?

 

Another one, a limit of a zoom in the map mod.
It makes complicated to target vessel, that is close enough to active vessel. 

[theJesuit]

Hi ksp modding gurus!

I have a QoL request below please  :

Request:
If a Part Variant contains only ONE option then could it not show in the VAB PAW, possibly even having the tear drop removed in the VAB thumbnails (not so important I guess?)

I do a fair bit of ubiopart welding to make new 'parts' out of stock parts, but often with ReStock.  I have to work around the PartVariant textures which fight each other.  One way of dealing with this if I have used a model that has part texture variants, to only use one and to remove all but of the variants from PartVariant module in the part.cfg file.  But this leaves variant choice in the PAW in the VAB, even though it has one option.  So, hence my request please to please have  variant thing not show in the PAW in the VAB.

 

Peace.

[Lisias]

Guys...

KSPCF is replacing DDS from 3rd parties with DXT3 ones (that KSP doesn't supports), preventing the textures from being loaded.

I consider this way less than ideal - because, again, KSPCF is replacing working textures with borked ones.

I found at least one trigger for the problem - if there's a PNG file and a DDS one, both with the same texture name (the filename without extension), KSP will ignore the PNG and load the DDS, but this triggers KSPCF into replacing de DDS with a DXT3 one, and we get black textured parts instead of the intended texture.

Ideally you should not replace working assets, at least without a solid reason (not to mention that you should warn about the action in the KSP.log). But if KSPCF would not be using DXT3 on the process, the truth is that nothing bad would had happened.

So I suggest:

• Log a warning when KSPCF replaces something on the GameData; and
• DO NOT USE DXT3 when creating textures that will be loaded by KSP.

Counting with your support.

=== == = POST EDIT = == ===

I misdiagnosed the problem. KSP was masking a latent problem on the distribution (I was really shoving DXT3 files on the thing), KSPCF unmasked the problem by ignoring PNG files when a DDS is present.

I stand corrected on this one - I ended up shooting the messenger by accident.

Edited July 4 by Lisias
I stand corrected.

[JonnyOThan]

5 hours ago, Lisias said:

KSPCF is replacing DDS from 3rd parties with DXT3 ones

Can you...provide any information about what files or mods might be affected?  A log?  Repro steps?

I'm not super familiar with the texture conversion system, but I'm pretty sure it doesn't create DXT3 textures.

https://github.com/KSPModdingLibs/KSPCommunityFixes/blob/441f2d7e0ab844cbc3bd86ef2c5410c245f08cb9/KSPCommunityFixes/Performance/FastLoader.cs#L2101

Edited July 4 by JonnyOThan

[Lisias]

2 hours ago, JonnyOThan said:

Can you...provide any information about what files or mods might be affected?  A log?  Repro steps?

I'm not super familiar with the texture conversion system, but I'm pretty sure it doesn't create DXT3 textures.

https://github.com/KSPModdingLibs/KSPCommunityFixes/blob/441f2d7e0ab844cbc3bd86ef2c5410c245f08cb9/KSPCommunityFixes/Performance/FastLoader.cs#L2101

I reproduced the problem pretty easily:

1. Get a clean KSP 1.12.5 (Stock, DLC and Module Manager)
2. Install KAX
3. Fire up KSP - no problems
4. Install KSPCF
5. Fire up KSP - DXT3 problems on some KAX textures.

[LOG 03:25:45.116] Load DDS texture: KAX/Parts/KAX_radialProp/radialPropBlu
[WRN 03:25:45.117] LOAD FAILED : DDS: The 'DXT3' format isn't supported, use DXT1 for RGB textures or DXT5 for RGBA textures
[WRN 03:25:45.117] Duplicate PNG texture 'KAX/Parts/KAX_radialProp/radialPropBlu' with extension 'png' won't be loaded
[LOG 03:25:45.144] Load DDS texture: KAX/Parts/KAX_radialProp/radialPropChk
[WRN 03:25:45.144] LOAD FAILED : DDS: The 'DXT3' format isn't supported, use DXT1 for RGB textures or DXT5 for RGBA textures
[WRN 03:25:45.217] Duplicate PNG texture 'KAX/Parts/KAX_radialProp/radialPropChk' with extension 'png' won't be loaded
[LOG 03:25:45.469] Load DDS texture: KAX/Parts/KAX_radialProp/radialPropRed
[WRN 03:26:24.211] LOAD FAILED : DDS: The 'DXT3' format isn't supported, use DXT1 for RGB textures or DXT5 for RGBA textures
[LOG 03:26:24.439] [ModuleManager] INFO: Loading Physics.cfg
[WRN 03:26:24.447] Duplicate PNG texture 'KAX/Parts/KAX_radialProp/radialPropRed' with extension 'png' won't be loaded

The trigger I found is having a PNG and a DDS with the sane name (for example, radialPropBlu.png and  radialPropBlu.dds). Somehow, KSPCF decides to overwrite radialPropBlu.dds the with a new one, but on DXT3.

I'm unaware if there're more triggers for this problem.

Removing the PNG's dupers (and restoring the original DDS's) prevents triggering the problem (next KAX release will have it sorted out), but the problem is still there on KSPCF waiting to bite another one.

IMHO, KSPCF should not silently rewrite 3rd party assets (would had allow me to diagnose the problem way quicker) and, yet more important, when doing it, do not use a texture format not supported by KSP (what would had prevented the problem at first place).

=== == = POST EDIT = == ===

I was wrong. KSPCF unmasked the problem, by ignoring PNG files when a DDS is present.

Edited July 4 by Lisias
POST EDIT.

[JonnyOThan]

48 minutes ago, Lisias said:

The trigger I found is having a PNG and a DDS with the sane name (for example, radialPropBlu.png and  radialPropBlu.dds). Somehow, KSPCF decides to overwrite radialPropBlu.dds the with a new one, but on DXT3.

This isn't what's happening.

The radialPropBlu.dds file that is in KAX *is* in DXT3 format.  I haven't confirmed the repro yet, but if it's correct then there must be something about KSPCF that is causing that to get used instead of the PNG.

Confirmed.  Without KSPCF, you see this in the logs:

[LOG 10:49:25.131] Load(Texture): KAX/Parts/KAX_radialProp/radialPropBlu
[ERR 10:49:25.133] DDS: DXT3(2048x2048, MipMap=True) - DXT3 format is NOT supported. Use DXT5
[WRN 10:49:25.133] Texture load error in 'C:\Program Files (x86)\Steam\steamapps\common\KSP Vanilla\GameData\KAX\Parts\KAX_radialProp\radialPropBlu.dds'
[LOG 10:49:25.134] Load(Texture): KAX/Parts/KAX_radialProp/radialPropBlu

So it tries to load the dds first, fails, and then successfully loads the png.  KSPCF reports the "duplicate png texture" line even for the failed DXT3 load, so I bet that's probably the issue.

Assuming you came across this while supporting someone for KAX, in the short term until this gets fixed you could update your dxt3 textures to dxt5, or just remove them so that it uses the png.

 

Filed here: https://github.com/KSPModdingLibs/KSPCommunityFixes/issues/237

Edited July 4 by JonnyOThan

[Lisias]

44 minutes ago, JonnyOThan said:

This isn't what's happening.

You are right, my apologies. I, indeed, ended up shoving DXT3 DDS files on the distribution, and KSP ignored them loading the PNG files instead - masking the problem. KSPCF is ignoring PNG files when a DDS texture is present (a reasonable decision), and then KSP, finaly, spits the warning on the log.

 

47 minutes ago, JonnyOThan said:

Assuming you came across this while supporting someone for KAX, in the short term until this gets fixed you could update your dxt3 textures to dxt5, or just remove them so that it uses the png.

Yes, this is going to done before the end of the day.

 

48 minutes ago, JonnyOThan said:

Filed here: https://github.com/KSPModdingLibs/KSPCommunityFixes/issues/237

Thank you!

[major_1129]

With the kspcommunityfixes installed, i can't get into cabin view.

 

 

Edited July 11 by major_1129

[Gargamel]

@major_1129, I’ve merged your two posts into one.    It’s best, if you have a question about a mod, to post in that mods thread first.     And please, outside of the “international” sub-forums, include an English translation.    Thank you.   
 

，我把你的两篇帖子合并为一篇了。如果你对某个 mod 有疑问，最好先在该 mods 主题中发帖。并且，请在“国际”子论坛之外附上英文翻译。谢谢。

[major_1129]

2 hours ago, Gargamel said:

@major_1129, I’ve merged your two posts into one.    It’s best, if you have a question about a mod, to post in that mods thread first.     And please, outside of the “international” sub-forums, include an English translation.    Thank you.   
 

，我把你的两篇帖子合并为一篇了。如果你对某个 mod 有疑问，最好先在该 mods 主题中发帖。并且，请在“国际”子论坛之外附上英文翻译。谢谢。

ok，thank you

[major_1129]

Why can't I get into the cabin view after installing kspcommunityfixes?

Edited July 11 by major_1129

[Gargamel]

19 minutes ago, major_1129 said:

Why can't I get into the cabin view after installing kspcommunityfixes?

Please do not crosspost the same question in multiple locations, it leads to fractured conversations and confusion.   
 

Do not expect immediate answers.   When somebody has an answer, they’ll post it.   
 

Meanwhile, check the mod thread OP for directions on getting help if it’s there, and check the “HOW TO GET HELP” Sticky under the tech support pages.   There’s a lot of self diagnosing that could happen.   

[JonnyOThan]

2 hours ago, major_1129 said:

Why can't I get into the cabin view after installing kspcommunityfixes?

Did you enable the option that removes all IVAs?

[major_1129]

12 hours ago, JonnyOThan said:

Did you enable the option that removes all IVAs?

Where can I turn this option off?