[1.8 - 1.12] KSPCommunityFixes - Bugfixes and QoL tweaks

[SingABrightSong]

3 minutes ago, modus said:

Maybe you can scroll up a bit first before posting?

Oh, whoops. Ah, that's the issue, new version hasn't propagated to CKAN yet.

ETA: New version has in fact just propagated to CKAN the moment after I posted this.

Edited June 30, 2022 by SingABrightSong

[Gotmachine]

34 minutes ago, JonnyOThan said:

When QuickStart is configured to go to the most recently flown vessel, it just ends up in the SpaceCenter view and still has the countdown timer text on the screen

I'm using QuickStart a lot and I never had that issue. Besides, I fail to see anything in KSPCF that could affect QuickStart...

22 minutes ago, SingABrightSong said:

Just installed the latest update. VAB is borked

I just released a fixed version (1.18.1). Sorry for the inconvenience.

[dok_377]

That might actually be a bit of a stretch, but maybe it is fixable externally. There's a bug with asteroids on several versions of the game, it consists of asteroids being unable to decrease mass as they're being mined. 

The text from the bug tracker goes as follows:

Spoiler

Link (only visible if you have an account): https://bugs.kerbalspaceprogram.com/issues/25730

Title: The use of the excavator to mine asteroids increases the mass of the system

Description

When it extracts ore from the asteroid to the ship, the total mass of the system cannot change, because it is moving the ore from the asteroid to the ship and not creating ore.

Apparently, the game is keeping the total mass of the asteroid fixed and, when using the excavator, the ore's mass is added to the system.

In my test the mass of the ship is 6.7t (picture1) and the asteroid mass is 178.4t.
The total mass of the system (ship + asteroid) is 185.1t (picture2).
If I remove 1.5t of ore from the asteroid and put it on the ship, the mass of the asteroid decreases by 1.5t and the mass of the ship increases by 1.5t, so the total mass must remain 185.1t.
Picture3 shows that the amount of minerals is added to the system, indicating an increase in the total mass of the system by 1.5t. I believe there is a bug here, because the game is keeping the mass of the asteroid fixed and adding ore mass to the system.
If disengage the ship from the asteroid, the mass will return to 6.7t + 1.5t = 8.2t (picture4)
Now, if I discard the ore from the ship and connect to the asteroid again, we can see that the game keeps the mass of the asteroid fixed because it considers the total mass equal to picture2, even with the asteroid without 1.5t of ore. (picture5)

The video showing the problem https://youtu.be/SRzGvAtCRrA

 

 

[dok_377]

On 7/25/2021 at 8:30 PM, Gotmachine said:

PAWStockGroups [KSP 1.10.1 - 1.12.3]
Part Action Window groups for a selection of stock items/modules

Oh, it would also be good if this fix had an option to make all the groups be extended by default. 

[Gotmachine]

22 minutes ago, dok_377 said:

There's a bug with asteroids on several versions of the game, it consists of asteroids being unable to decrease mass as they're being mined. 

That specific bug was fixed in KSP 1.12.2, and I won't implement fixes for older KSP versions. Out of curiosity, why are you staying on 1.10 ?

This being said, there is another asteroid/comet mining related bug lying around (asteroid mass being reset to 100% when an asteroid becomes depleted by mining while timewarping), but I haven't had the courage to put my hands in that specific mess yet.

1 minute ago, dok_377 said:

it would also be good if this fix had an option to make all the groups be extended by default. 

Yeah, this has been requested a few times, but I keep forgetting about it.

[dok_377]

16 minutes ago, Gotmachine said:

Out of curiosity, why are you staying on 1.10 ?

16 minutes ago, Gotmachine said:

That specific bug was fixed in KSP 1.12.2, and I won't implement fixes for older KSP versions.

That was the exact reason for my hesitation to ask about it up until this point, I was expecting this exact reply.  
It's fine, after all it's my own decision to play the outdated version of the game. You can't have it all, there will always be something missing.

Edited June 30, 2022 by dok_377

[maledin]

Ever since I updated this morning, I've experienced a strange bug wherein  every time I try to place something radially, it just spams the thing I'm holding wherever I move my cursor. However, if I save and reload the vessel, the added parts disappear (and the part count never actually increases). That said, I'm unable to place a "real" part at all. Here's a screenshot of what it ends up looking like:

 

Build mode is basically unusable as long as this is happening, so I'm going to downgrade to the previous version until further notice. I have no idea what could be causing this -- I'll save my recent console info if needed.

[JonnyOThan]

59 minutes ago, Gotmachine said:

I'm using QuickStart a lot and I never had that issue. Besides, I fail to see anything in KSPCF that could affect QuickStart...

Interesting, there are a few other peculiarities of my setup, I will have to test on something a little more typical...Sorry!

[Gotmachine]

Mkay. Well, there is definitely a performance impact in 1.11 / 1.12 due to the planets revamp (but arguably, they look much better).
As for the "poorly made" comment, there are a few issues indeed but not any more or less than in previous versions.
And this put aside, the 1.11 and 1.12 updates cycles definitely fixed a lot of bugs, and many active mods have also matured a lot in that timeframe.

[maledin]

Just saw the previous comment on this topic and decided to change AutostrutActions to false and everything appears to be function correctly again. Just a FYI, but I still had the issue despite having the supposed hotfix in version 1.18.1

[dok_377]

6 minutes ago, Gotmachine said:

Well, there is definitely a performance impact in 1.11 / 1.12 due to the planets revamp (but arguably, they look much better).

It's not about revamps. Same vehicles in the same places just perform worse for some reason. I haven't completely given up on it though, I might do some more testing. Who knows how it might turn out. 

[JonnyOThan]

37 minutes ago, dok_377 said:

It's not about revamps. Same vehicles in the same places just perform worse for some reason. I haven't completely given up on it though, I might do some more testing. Who knows how it might turn out. 

If you provide your save files maybe someone can figure it out and someone can include a fix in KSPCF.

[dok_377]

7 minutes ago, JonnyOThan said:

If you provide your save files maybe someone can figure it out and someone can include a fix in KSPCF.

There's no point in providing empty save files. It's THAT bad. 

[Russos]

Hello. After the release of the new version, I observe a conflict with the Komplexity (

 

I am upgrading the launch pad. I go to the VAB, I go out - the launch pad returned to the previous level, and the money was written off.

 

what additional information do you need to tell (logs and so on) to sort out the conflict situation?

[zer0Kerbal]

23 minutes ago, Russos said:

Hello. After the release of the new version, I observe a conflict with the Komplexity (

 

I am upgrading the launch pad. I go to the VAB, I go out - the launch pad returned to the previous level, and the money was written off.

 

what additional information do you need to tell (logs and so on) to sort out the conflict situation?

Just for some information, Komplexity is just a specific set of patches that are enabled by @sarbian's CustomBarnKit (CBK)

Edited June 30, 2022 by zer0Kerbal

[Gotmachine]

34 minutes ago, Russos said:

I am upgrading the launch pad. I go to the VAB, I go out - the launch pad returned to the previous level, and the money was written off.

Yeah, this isn't even a bad interaction with CustomBarnKit, it's a bad interaction between the MemoryLeak patch and some stock code doing something unusual that I didn't anticipate.
The issue happens in stock too. Will provide (another) fixed release ASAP.

Edited June 30, 2022 by Gotmachine

[Gotmachine]

@RussosDone, version 1.18.2 fixes that issue and should be available on CKAN in a while.

Sorry to all for the inconvenience.

[Russos]

Thanks a lot. I'm waiting for a new version.

wow! how fast! Thank you!

did a quick test.

Install KSP (No lang patch, no DLC)

Install Module Manager (SCAN)

Install HarmonyKSP (SCAN)

Install Custom Barn Kit (SCAN)

RUN KSP — all ok

Install KSP Community Fixes 1.18.2 (zip)

RUN KSP, start new carrer

And problem still exists

Edited June 30, 2022 by Russos

[Russos]

18 minutes ago, Gotmachine said:

@RussosDone, version 1.18.2 fixes that issue and should be available on CKAN in a while.

Sorry to all for the inconvenience.

I'm sorry. Problem still exists.

[flart]

stock bug:

if you put the service bay 2.5m right above the engine plate 2.5m, and some other part below engine plate to close the engine plate,
then the service bay in the flight will not be opening. After decoupling the engine plate, the service bay will open properly.

[Gotmachine]

1 hour ago, Russos said:

I'm sorry. Problem still exists.

Don't be sorry, thank you for testing and reporting

There was indeed an additional bad interaction between CustomBarnKit and KSPCF (and turns out other mods as well).
Hopefully, things should now work fine with KSPCF 1.18.3 !

[Gotmachine]

31 minutes ago, flart said:

if you put the service bay 2.5m right above the engine plate 2.5m, and some other part below engine plate to close the engine plate,
then the service bay in the flight will not be opening. After decoupling the engine plate, the service bay will open properly.

Yeah... tricky one...

What is happening is that "ModuleDecouple" on the engine plate is setting all attached parts as "shielded from airstream", excepted the part attached to the node defined in the "bottomNodeName" of the "ModuleJettison" module.
Which make sense, but somehow they forgot that "all attached parts" also mean the part attached to the top node.
In your example, this is the service bay, which then refuse to open because it is considered as in a fairing. But on the bright side, that part now doesn't cause any drag !

This is tricky to fix because this would require having an extra config field to specify additional nodes that shouldn't be shielded.
Putting aside the fact that adding extra config fields to existing modules is difficult and messy, this would also mean that we need actual config patchs for every part using "ModuleDecouple" with "isEnginePlate = true".

Alternatively, I could add an hardcoded exclusion for the usual top node id ("top") that might cover this issue for stock parts, but also might not work correctly in other cases (modded parts...).

[maledin]

52 minutes ago, Gotmachine said:

Don't be sorry, thank you for testing and reporting

There was indeed an additional bad interaction between CustomBarnKit and KSPCF (and turns out other mods as well).
Hopefully, things should now work fine with KSPCF 1.18.3 !

Man, you're a rock star with these hot fixes! Oh and btw, the memory leak fix is AMAZING. Before, I'd have to reset the game after an hour or so as load times between ships reached up to five+ minutes. Now, it's nearly instantaneous despite having the game running for a while. You're doing the dev's work here!

[Aelfhe1m]

3 hours ago, Gotmachine said:

Yeah... tricky one...

What is happening is that "ModuleDecouple" on the engine plate is setting all attached parts as "shielded from airstream", excepted the part attached to the node defined in the "bottomNodeName" of the "ModuleJettison" module.
Which make sense, but somehow they forgot that "all attached parts" also mean the part attached to the top node.
In your example, this is the service bay, which then refuse to open because it is considered as in a fairing. But on the bright side, that part now doesn't cause any drag !

This is tricky to fix because this would require having an extra config field to specify additional nodes that shouldn't be shielded.
Putting aside the fact that adding extra config fields to existing modules is difficult and messy, this would also mean that we need actual config patchs for every part using "ModuleDecouple" with "isEnginePlate = true".

Perhaps use the orientation of the nodes? The decouple node and the various engine nodes all point one direction while the top node that connects to the rest of the vessel points the opposite direction. That's an already present distinction which doesn't rely on node names.

 

 

[swjr-swis]

4 hours ago, Gotmachine said:

This is tricky to fix because this would require having an extra config field to specify additional nodes that shouldn't be shielded.

Or... and hear me out a moment... add an option for us to entirely disable (and I really do mean with absolute prejudice disable) the code that does the 'let's disable stuff when parts are shielded' thing.

That would solve So. Many. Bugs. in one fell swoop.

Anyway. Never mind me.