[KSP >= 1.3.0] TweakScale - Under Lisias' Management - 2.4.8.6 - 2024-0921

[TranceaddicT]

5 hours ago, BlinAndVodka238 said:

Any particular reason why Breaking Ground is currently not supported stock? I tried scaling the rotor engines and blades and they seem to work fine.
 

KSP.log and we can better assist.

As is, it should work out of the box.

 

5 hours ago, BlinAndVodka238 said:

And is there a way to scale everything from a root part?

No, you need to rescale each part individually.

[Nicky21]

There's an awfull amount of rogue duplicates lately ( 1.10, lots of mods ). Is this an known issue ? If it's not, do you need some screenshots or the ksp log file?

[TranceaddicT]

26 minutes ago, Nicky21 said:

There's an awfull amount of rogue duplicates lately ( 1.10, lots of mods ). Is this an known issue ? If it's not, do you need some screenshots or the ksp log file?

Yes.

LOG?

https://github.com/net-lisias-ksp/TweakScale/issues/45

[Lisias]

23 hours ago, Nicky21 said:

There's an awfull amount of rogue duplicates lately ( 1.10, lots of mods ). Is this an known issue ? If it's not, do you need some screenshots or the ksp log file?

It depends. If you forgot to remove all the old TweakScale files before updating the new one, then it's a known issue: please clean up the TweakScale folder before updating, some files are changing a lot and the aftermath is that you end up with old lefties from the last version lingering around and playing havoc.

If that is not the case, then we have a cause of rogue patching, and I will need your KSP.log (and the MM logs too!) in order to identify who is the toe stomper.

But there're some recurrent old "friends" that I can guess: if you are using TMasterson5's TweakScale patches, please remote it and install All Tweak instead.

 

23 hours ago, TranceaddicT said:

https://github.com/net-lisias-ksp/TweakScale/issues/45

That one is one I'm uncertain is an error at all. Sometimes, we really have more than one instance of something on the GameDatabase, and so something else choose that instance to use. It's like the multiple ModuleEngineFX on part, that are later selectively activate/deactivated by MultiModeEngine .

At that time (it's more than an year already), I had not such knowledge, so I decided to mark the issue to be pursued when I would had time to spare on it (or when something else happens that would force me to deal with it).

Perhaps such multiple KerbalEVAs are intentional - I just need time to research the matter to confirm it.

But as we can see, I still don't have time to spare on it.

 

Edited August 17, 2020 by Lisias
SUCH! I MEAN *SUCH*, you @#$@#$@# autocomplete from hell!!!!

[shdwlrd]

@Lisias What did you do to solve the drifting wheels and parts problems? Is it something I can do with the base game?

PS, Love the mini OPT plane.

Edited August 21, 2020 by shdwlrd

[Beetlecat]

Are the wheel spring/damper expose-able settings for manipulation by action groups (Part Actions mod?)? There could be taxi, takeoff, and landing configs...

[Lisias]

7 hours ago, shdwlrd said:

@Lisias What did you do to solve the drifting wheels and parts problems? Is it something I can do with the base game?

Wrote two lines of code!

This is the most text book, real life materialisation of this joke.

Spoiler

There is an old story of a boilermaker who was hired to fix a huge steamship boiler system that was not working well.

After listening to the engineer’s description of the problems and asking a few questions, he went to the boiler room. He looked at the maze of twisting pipes, listened to the thump of the boiler and the hiss of the escaping steam for a few minutes, and felt some pipes with his hands. Then he hummed softly to himself, reached into his overalls and took out a small hammer, and tapped a bright red valve one time. Immediately, the entire system began working perfectly, and the boilermaker went home.

When the steamship owner received a bill for one thousand dollars, he became outraged and complained that the boilermaker had only been in the engine room for fifteen minutes and requested an itemized bill. So the boilermaker sent him a bill that reads as follows:

For tapping the valve: $.50
For knowing where to tap: $999.50
TOTAL: $1,000.00”

The first breakthrough was understanding it was not a problem with the wheels (they have some, but not this one), as everybody was thinking. Anyone that tried to solve this problem looking only on code wasted his/her time.

It's a multidisciplinary problem: it was scattered on all the physics engine, a bit in each place, and once these tiny little problems get sum up by the software stack, the after math (pun not intended) is the WHOLE CRAFT drifting to the left of to the right, besides the wheels doing their job (assuming they are not under some borderline situation and are contributing to it, see below).

The Physics Engine is a discrete domain trying to simulate a continuous one, a lost fight - it's impossible. What we can do it to get near enough to an arbitrary point on the continuous domain, and then fight to get near enough another one arbitrarily chosen in the hopes nobody notices the gaps (it's exactly the same problem on sampling sounds, by the way. And since we are here, get acquainted to Nyquist).

Exactly why this was happening, only by getting access to the whole source code to really know (as I said, the problem is probably scattered on it), but what is happening I can say for sure: while calculating the forces on each part, something is screwing up on some calculations, generating pseudo-random tiny little torques on each Part in the 3 axis. 

This effect gets nastier as there're more parts on the scene by many reasons, and I'm sure only about what follows (at least for now):

• Since the spurious forces are applied on each part, having many parts suffering such spurious forces ends up summing them up. More parts, more sums, and so bigger is the magnetude of the resulting spurious vector.
• More parts on the Physics Range means more parts to be calculated by the physics engine, and once the CPU is overloading the game engine starts to skip some FixedUpdates (apparently), and then that gap between two arbitrary points on the continuous domain starts to get too wider, and the PIDs starts to overshoot around these points without managing to converge to them (this is the additional problem with the wheels, by the way).
  • If the spurious values where deterministic and always equal, they would ending up nullifying themselves. But since they are random on sign and magneture, one side ends up winning the lottery.

With spurious torques being summed and applied to the parts where friction is calculated, we have two more situations:

• The pitch and roll torques sabotage the contact between the parts and the ground, making the physics engine "lose" some of that arbitrary points I talked above, and the friction is miscalculated
• The yaw torque overruns the friction that manages to get calculated.

Now imagine every part of the craft doing it, and it's obvious that the few parts in the touch with the ground will not be able to withhold it.

Since I can't clamp that values inside the Physics Engine from the C# land, I just zeroed the torque on each part Driftless is applied if the craft the part belongs is "stopped enough" and it's landed - on each FixedUpdate. And voilà, no more drifting (as long you don't put the wheels/legs on that borderline situation I described, but that is another story).

And yeah, Kerbals are really just another part on the Physics Engine. So they drifts by the same reasons. It only happens that they are single part crafts, so the Kerbal you are controlling drifts way less - most of the time.  

 

7 hours ago, shdwlrd said:

PS, Love the mini OPT plane.

Me too. Mainly because all this stunt happened by observing her wheels under TweakScale 2.4.3.x (only 2.5 beta really scales wheels and legs correctly - I didn't merged the fix yet because correctly scaling wheels would make them more prone to the PID problem on bigger vessels, and TweakScale would be probably taking the blame). I got the Eureka moment when I theorised that if the problem was only on the wheels, replacing is with octogonal struts would solve it. But it didn't.

 

7 hours ago, Beetlecat said:

Are the wheel spring/damper expose-able settings for manipulation by action groups (Part Actions mod?)? There could be taxi, takeoff, and landing configs...

Now that I know how they works (besides not perfectly yet), we can even replace the "stock" PIDs with something a bit more dumb but easier to cope with potato machines. Most people don't use professional workstations for gaming.  

 

On 8/16/2020 at 8:17 AM, BlinAndVodka238 said:

Any particular reason why Breaking Ground is currently not supported stock? I tried scaling the rotor engines and blades and they seem to work fine.

And is there a way to scale everything from a root part?

Whoops....  I missed that one. Sorry!

1) Got no time to really spend playing on Serenity yet. Scaling is more that just making the parts bigger, I need to find an equilibrium between playability and reality while scaling the Module's parameters. One perfect example is the Wheels on TweakScale 2.4.3 - you scale them down now, we get impossibly strong wheels for the size.

2) Hit CTRL-K . This will scale the whole subtree the part belongs. 

Edited August 21, 2020 by Lisias
brute force post merge

[Rafael acevedo]

Lisias 

I am confused, you just released KSP recall for 1.10.1 but in the description it says that KSP recall is only needed in 1.9.1, so the question is: Do we now require KSP recall when using Tweakscale in 1.10.1? Thanks

[Lisias]

1 hour ago, Rafael acevedo said:

Lisias 

I am confused, you just released KSP recall for 1.10.1 but in the description it says that KSP recall is only needed in 1.9.1, so the question is: Do we now require KSP recall when using Tweakscale in 1.10.1? Thanks

If you are using TweakScale on KSP 1.9, you need to install KSP Recall because of the bug on handling resources on KSP 1.9 that Recall solves for everybody that changes resources (and not only for TweakScale).

If you are running KSP 1.8, 1.9 or 1.10 with or without TweakScale, you will probably want to use KSP Recall in order to solve the craft drifting on the ground.

KSP-Recall is smart nowadays, it detects the KSP version it's installed and selectively applies only the patches needed. You can, now, install KSP-Recall on anything and let it do its magic (you should be safe on installing it even on KSP <= 1.8 now).

[shdwlrd]

9 hours ago, Lisias said:

The first breakthrough was understanding it was not a problem with the wheels (they have some, but not this one), as everybody was thinking. Anyone that tried to solve this problem looking only on code wasted his/her time.

It's a multidisciplinary problem: it was scattered on all the physics engine, a bit in each place, and once these tiny little problems get sum up by the software stack, the after math (pun not intended) is the WHOLE CRAFT drifting to the left of to the right, besides the wheels doing their job (assuming they are not under some borderline situation and are contributing to it, see below).

Well you confirmed the thought I had with the wheels since Squad updated the plug-in they use for handling the wheels. Poor settings not working well with the physics engine. But I didn't realize it was the total sum of all the parts was exasperating the issue. 

9 hours ago, Lisias said:

The Physics Engine is a discrete domain trying to simulate a continuous one, a lost fight - it's impossible. What we can do it to get near enough to an arbitrary point on the continuous domain, and then fight to get near enough another one arbitrarily chosen in the hopes nobody notices the gaps (it's exactly the same problem on sampling sounds, by the way. And since we are here, get acquainted to Nyquist).

Exactly why this was happening, only by getting access to the whole source code to really know (as I said, the problem is probably scattered on it), but what is happening I can say for sure: while calculating the forces on each part, something is screwing up on some calculations, generating pseudo-random tiny little torques on each Part in the 3 axis. 

This effect gets nastier as there're more parts on the scene by many reasons, and I'm sure only about what follows (at least for now):

• Since the spurious forces are applied on each part, having many parts suffering such spurious forces ends up summing them up. More parts, more sums, and so bigger is the magnetude of the resulting spurious vector.
• More parts on the Physics Range means more parts to be calculated by the physics engine, and once the CPU is overloading the game engine starts to skip some FixedUpdates (apparently), and then that gap between two arbitrary points on the continuous domain starts to get too wider, and the PIDs starts to overshoot around these points without managing to converge to them (this is the additional problem with the wheels, by the way).
  • If the spurious values where deterministic and always equal, they would ending up nullifying themselves. But since they are random on sign and magneture, one side ends up winning the lottery.

With spurious torques being summed and applied to the parts where friction is calculated, we have two more situations:

• The pitch and roll torques sabotage the contact between the parts and the ground, making the physics engine "lose" some of that arbitrary points I talked above, and the friction is miscalculated
• The yaw torque overruns the friction that manages to get calculated.

Now imagine every part of the craft doing it, and it's obvious that the few parts in the touch with the ground will not be able to withhold it.

Since I can't clamp that values inside the Physics Engine from the C# land, I just zeroed the torque on each part Driftless is applied if the craft the part belongs is "stopped enough" and it's landed - on each FixedUpdate. And voilà, no more drifting (as long you don't put the wheels/legs on that borderline situation I described, but that is another story).

And yeah, Kerbals are really just another part on the Physics Engine. So they drifts by the same reasons. It only happens that they are single part crafts, so the Kerbal you are controlling drifts way less - most of the time.  

OK, so what you are saying, the game is trying to simulate all the forces and do to compounding errors, the force applied is overwhelming the friction setting or causing the part to "hop" across the surface.

And your fix is to "zero out" the forces.

[TranceaddicT]

6 minutes ago, shdwlrd said:

OK, so what you are saying, the game is trying to simulate all the forces and do to compounding errors, the force applied is overwhelming the friction setting or causing the part to "hop" across the surface.

And your fix is to "zero out" the forces.

More simply, physics calcs are "missing" times when the wheels are actually on the ground. Actual friction is being incorrectly calc'd because of those missing instances.

The result is your craft "slides" because of the "lower" friction (and in the direction of YOUR rig's RNG bias.)

Edited August 21, 2020 by TranceaddicT

[Rafael acevedo]

21 minutes ago, Lisias said:

If you are using TweakScale on KSP 1.9, you need to install KSP Recall because of the bug on handling resources on KSP 1.9 that Recall solves for everybody that changes resources (and not only for TweakScale).

If you are running KSP 1.8, 1.9 or 1.10 with or without TweakScale, you will probably want to use KSP Recall in order to solve the craft drifting on the ground.

KSP-Recall is smart nowadays, it detects the KSP version it's installed and selectively applies only the patches needed. You can, now, install KSP-Recall on anything and let it do its magic (you should be safe on installing it even on KSP <= 1.8 now).

Thank you

[Lisias]

1 hour ago, TranceaddicT said:

More simply, physics calcs are "missing" times when the wheels are actually on the ground. Actual friction is being incorrectly calc'd because of those missing instances.

The result is your craft "slides" because of the "lower" friction (and in the direction of YOUR rig's RNG bias.)

Yes. This is the root cause of the drift on wheels, but not the only cause for drifting. Kerbals and crafts without landing legs and wheels drift too, but by the reasons I explained previously: spurious torque being applied (and the source of such spurious torque is probably something failing to clamp too small values, inducing pseudo-random noise on the chain).

We have many source of problems acting together here.

 

1 hour ago, shdwlrd said:

Well you confirmed the thought I had with the wheels since Squad updated the plug-in they use for handling the wheels. Poor settings not working well with the physics engine. But I didn't realize it was the total sum of all the parts was exasperating the issue.

Everybody though the same, including me. I only realized the spurious torque problem because I decided put my assumptions on check, and realized that Kerbals and crafts without wheels and legs drifts the same.

 

1 hour ago, shdwlrd said:

OK, so what you are saying, the game is trying to simulate all the forces and do to compounding errors, the force applied is overwhelming the friction setting or causing the part to "hop" across the surface.

Yes and no. The gaming is simulating the things, but it's failing to detect events needed to counter act them.

With the sum of the spurious torques of every part being applied to the part touching the ground, you get this part "flickering" the contact. Lets say the parts "jumps" every 25ms. This tiny little jumps are already enough to sabotage what was expected to be a "continuous" contact that generates friction, but if we consider that the simulation quantum (the Mas Physics Delta-Time thingy) is 50 ms, and that everything that happens between two simulated events just didn't happens at all in practice, we quickly realize that we are losing half of that touching events, making a bad situation even worse. If that tiny little jumps happens each 5ms, so suddenly only 10% of the friction is computed. In essence, a sampling rate problem [and the spurious torques are only one of the triggers for it].

Adding offense to the insult, that spurious torque is another concurrent problem. By some reason (something failing to clamp very small values and making things behave like pseudo random generators when casting to higher or lower precision; some dumb cast on the C++ land injecting noise on part of the forces; whatever), random on sign and magnetude torques are being generated on each part, and this is triggering the problem I described on the previous paragraph.

[Now, about the wheels and landing legs, with the Physics Engine skipping some FixedUpdates, suddenly any PID on it end up applying their forces for more time than intended, and when finally its FixedUpdate is called again, way more then the expected 50ms had passed, and the result is that the PID detects it had terribly overshoot and then tries to "overshoot back" - but so, another FixedUpdate is skipped and when the PID realizes what's happening, yells "whata the hell?" and tries to counter the counter-overshot, and so goes on. On a closed system with two PIDs overshooting each other, we see things escalating pretty fast - and this is what essentially the Landing Legs and Wheels are nowadays.]

 

1 hour ago, shdwlrd said:

And your fix is to "zero out" the forces.

Selectively zeroing out the forces, otherwise I would just break the simulation.

If the craft is landed and is "stopped enough" all the torques are zeroed. Otherwise nothing is done.

I don't have access to the places (I'm betting this is scattered on the codebase) where that spurious source of noise should be being clamped, so I need to overrule the bad results of the computations when needed. One obvious and deterministic situation where such torques should be zeroed is when the craft is landed and at rest (i.e. the magnetude of the rigidbody's velocity is pretty small).

It's perfectly possible that there are more situations were such spurious torque are a problem, and when they are detected and confirmed, more code will be added to Recall to handle that specific situation.

I considered once just clamp the torques and call it a day, but then I realized that by doing that, I could be hindering legit small torques. So I took the safer approach.

Edited August 21, 2020 by Lisias
Hit "save" too soon.

[shdwlrd]

@Lisias I was being very general with my summary of what you discovered and the fix you implemented, but thank you for the detailed explanations. 

This is reminding me of a change log from the 1.0.x days. Squad did something to the clamping of forces. I don't remember which version Squad made the change. The way I noticed was because KER stopped reporting all balls for movement when landed or splashed  and stopped. I know in .90 and earlier and early 1.0 days KER used to show no movement, and you wouldn't drift. (Unless you were resting on physics-less parts. Weird things could happen depending on the situation.) Now it never settles on zero when stopped.

If someone can find that change log, maybe we can get Squad to revisit that change and see if it's truly necessary now.

[Lisias]

Hi, @JEBEDIAH KERBAL PLAYER. Just found your post on Modular Launch Pads.

On 8/20/2020 at 1:53 PM, JEBEDIAH KERBAL PLAYER said:

hello, i have a question and i need help, i use the mod in version 1.10 of the game, but the platforms got bigger than normal after i installed the tweak scale mod, i tried to uninstall the tweak scale and it didn't work, so i reinstalled the modular launch  pads, but this problem continues to occur, can someone help me?

Now you are on the right place.

First, this is not a "TweakScale problem" exactly. It's more like someone wrote a bad patch on TweakScale, and now TweakScale is getting the heat. But in a way or another, I'm the best guy to help you on the issue.

Modular Launch Pads is not a standard patch from TweakScale, so I can't help you without further information. I need your full KSP.log (and the name of the part with problems) so I can inspect the log looking for who could be patching the affected part. By inspecting each one of the configs that is patching the affected part, I will be able to pinpoint the culprit.

Cheers!

 

8 hours ago, shdwlrd said:

@Lisias I was being very general with my summary of what you discovered and the fix you implemented, but thank you for the detailed explanations. 

I entered in "corporate SAS covering mode" again. Sorry!

[Azic Minar]

@Lisias You are two steps from writing code that can stop the death spins by pressing a side bar button

[BananaDealer]

Sooo... Haven't played Kerbal in a fair bit. Coming back to it, I got 18 "fatal" errors to do with TweakScale...

Here's the log file, assistance would be very appreciated:
https://drive.google.com/file/d/1SzbZG1AxhmEXaTfGRl0HeV5Hu7WAW0Al/view?usp=sharing

[Lisias]

20 hours ago, Azic Minar said:

@Lisias You are two steps from writing code that can stop the death spins by pressing a side bar button

This is going to wait a bit, as it appears. It came to my attention that some Add'Ons in BETA are causing some rampage[cut]and I need to give them some care.

 

8 hours ago, BananaDealer said:

Sooo... Haven't played Kerbal in a fair bit. Coming back to it, I got 18 "fatal" errors to do with TweakScale...

Here's the log file, assistance would be very appreciated:
https://drive.google.com/file/d/1SzbZG1AxhmEXaTfGRl0HeV5Hu7WAW0Al/view?usp=sharing

The errors are not to with TweakScale. They were detected by TweakScale. Please authorize me to download the logs and I will check it for you.

Edited August 23, 2020 by Lisias
Not exactly that, I misundertood a english slang.

[Lisias]

18 hours ago, BananaDealer said:

Sooo... Haven't played Kerbal in a fair bit. Coming back to it, I got 18 "fatal" errors to do with TweakScale...

Here's the log file, assistance would be very appreciated:
https://drive.google.com/file/d/1SzbZG1AxhmEXaTfGRl0HeV5Hu7WAW0Al/view?usp=sharing

It's Contares double patching NFC:

[LOG 23:15:56.180] Applying update Contares/Patches/CONTARES_TweakScale/@PART[truss-octo-*] to NearFutureConstruction/Parts/Truss/truss-octo/truss-octo-01.cfg/PART[truss-octo-01]
[....]
[LOG 23:16:18.007] Applying update TweakScale/patches/NF/NFC_TweakScale/@PART[truss-octo-01] to NearFutureConstruction/Parts/Truss/truss-octo/truss-octo-01.cfg/PART[truss-octo-01]

As a matter of fact, it's the exact same problem that bite you almost exactly one year ago.  And the fix is still the same.

The proper fix would be to fix Contares, but since until this moment nobody bored to fix it, I think I will have to handle this the harsh way.

Please install the latest TweakScale Companion for Near Future. It will fix your problem for good (at least, until someone else decides to stomp on its toes - but by then...  ) . The Compantion for NF is a complete rewrite from scratch for every patch for every NF add'on, double checked and following the TweakScale guidelines. Unless I did some mistake (and I think any eventual one would be already reported), it is the way to go from now. And, of course, if adds patches to all current NF parts (without loosing support fot the legacy ones when needed).

In a way or another, backup everything before applying it (just in case).

 

[TranceaddicT]

22 minutes ago, Lisias said:

As a matter of fact, it's the exact same problem that bite you almost exactly one year ago.  And the fix is still the same.

If there is one thing that ticks me off more than anything here, it's this:  people put in ZERO effort to find a solution for their situation.

[Krazy1]

On 8/16/2020 at 10:02 AM, TranceaddicT said:

On 8/16/2020 at 4:17 AM, BlinAndVodka238 said:

And is there a way to scale everything from a root part?

No, you need to rescale each part individually.

I thought @Lisias said there was a way... Ctrl + K maybe? 

[BananaDealer]

On 8/23/2020 at 6:31 PM, Lisias said:

It's Contares double patching NFC:

[LOG 23:15:56.180] Applying update Contares/Patches/CONTARES_TweakScale/@PART[truss-octo-*] to NearFutureConstruction/Parts/Truss/truss-octo/truss-octo-01.cfg/PART[truss-octo-01]
[....]
[LOG 23:16:18.007] Applying update TweakScale/patches/NF/NFC_TweakScale/@PART[truss-octo-01] to NearFutureConstruction/Parts/Truss/truss-octo/truss-octo-01.cfg/PART[truss-octo-01]

As a matter of fact, it's the exact same problem that bite you almost exactly one year ago.  And the fix is still the same.

The proper fix would be to fix Contares, but since until this moment nobody bored to fix it, I think I will have to handle this the harsh way.

Please install the latest TweakScale Companion for Near Future. It will fix your problem for good (at least, until someone else decides to stomp on its toes - but by then...  ) . The Compantion for NF is a complete rewrite from scratch for every patch for every NF add'on, double checked and following the TweakScale guidelines. Unless I did some mistake (and I think any eventual one would be already reported), it is the way to go from now. And, of course, if adds patches to all current NF parts (without loosing support fot the legacy ones when needed).

In a way or another, backup everything before applying it (just in case).

 

Thank you!

On 8/23/2020 at 6:56 PM, TranceaddicT said:

If there is one thing that ticks me off more than anything here, it's this:  people put in ZERO effort to find a solution for their situation.

I guess sorry for not remembering I had a problem a year ago, or what it stemmed from (which, in that case was a different mod), or how to fix it...

In any case, Contares removed (it was a deprecated mod anyway) and Companion applied... lets see if it works.

 

Edit: Whooo! No more "Show-stopper" errors! Still got 17 "normal"(?) errors, but at least it's not "EXIT THE GAME AND SEEK HELP NOW, OR BOB GETS IT!" anymore (poor Bob...).

Edited August 25, 2020 by BananaDealer

[Lisias]

On 8/24/2020 at 3:50 AM, Krazy1 said:

I thought @Lisias said there was a way... Ctrl + K maybe? 

Yes.

 

44 minutes ago, BananaDealer said:

Edit: Whooo! No more "Show-stopper" errors! Still got 17 "normal"(?) errors, but at least it's not "EXIT THE GAME AND SEEK HELP NOW, OR BOB GETS IT!" anymore (poor Bob...).

That "normal" are thingies long due to be implemented, as support for FSBuyoancy from FireSpitter. That already have a Companion, by the way, implementing it. (Still Alpha).

TS 2.4.4 will focus on geting rid of these ones.

 

48 minutes ago, BananaDealer said:

In any case, Contares removed (it was a deprecated mod anyway) and Companion applied... lets see if it works.

It's a pitty nobody fixed it yet, but I'm going to tackle down these ones too on the Companion Program. Check that page now and then, I'm publishing things as they are done (and they get done as time allows! )

[BananaDealer]

2 minutes ago, Lisias said:

It's a pitty nobody fixed it yet, but I'm going to tackle down these ones too on the Companion Program. Check that page now and then, I'm publishing things as they are done (and they get done as time allows! )

It apparently got split into several sub-mods, which are getting updates, but it looks like it evolved into parts packs for stock-alikes of smaller/vaguer programs (like the Indian, Chinese and Japanese launchers and such)... Not exactly what I'm looking for. Anyway - thank you again!

[TranceaddicT]

7 hours ago, Lisias said:

On 8/23/2020 at 11:50 PM, Krazy1 said:

I thought @Lisias said there was a way... Ctrl + K maybe? 

Yes.

How, with as many hours as I've invested in KSP, did I not know this? :smdh:

Welp, I've learned my lesson for the day.