[1.12.x] VAB Organizer (August 18)

[urturino]

45 minutes ago, JadeOfMaar said:

Thanks for posting your config. I clean forgot Atomic Age had engines other than the lightbulb and the jet engine which didn't appear for me.

Change the :NEEDS to :AFTER. You want to make sure that any adjustment to existing patches literally run after those that exist in VAB Organizer itself. The use of :FOR is bad for these reasons:

1. Part of how :FOR works is it tells MM that the named mod (Atomic Age) is installed (even when it actually isn't). If you happen to not have that mod installed later then compatibility patches in other mods (if they exist) will still run and can break your game. If you publish that config as-is and other people use it and don't have Atomic Age, their games can break too. This is a very terrible beginner mistake to make.
2. The patch will run within the sequence of the named mod (Atomic Age) which is alphanumerically earlier than VAB Organizer. The mod whose patches run alphanumerically later gets priority and will overwrite earlier patches.

 

I went out of my way to take care of Atomic Age (and the FTmN atomics mod) since they're owned by LinuxGuruGamer. I've submitted that patch to SheepDog's VABO config pack.

What it looks like:

// Atomic Age
@PART[nuclearEngineLightbulb]:NEEDS[SpaceTuxIndustries/RecycledParts]:AFTER[VABOrganizer]
{
	%VABORGANIZER
	{
		%organizerSubcategory = nuclearEngines
	}
}

 

Yes.

No. If a single mod is given for NEEDS and the same mod is given for AFTER then this is a needless redundancy. Just use the AFTER.

 

BEFORE, FOR, AFTER. Pick one. These control the timing of a patch.

Thank you.

It works now.

[Lisias]

On 9/8/2024 at 4:29 PM, JadeOfMaar said:

No. If a single mod is given for NEEDS and the same mod is given for AFTER then this is a needless redundancy. Just use the AFTER.

I stand corrected. Sorry for the mistake.

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

No, I was right and @JadeOfMaar was equivocated on telling otherwise.

I updated the original post with the gory details, but TL;DR:

• While the Patch Extraction phase, the :NEEDS clause is evaluated before the patch even being compiled.
  • Unsatisfied :NEEDS patches are just not compiled at all
• Later the compiled patches are applied as needed.
  • Since there's no compiled patches with an unsatisfied :NEEDS clause, we have less patches to evaluate at this time if we would not use it.
  • So, yeah. Using :AFTER and :BEFORE when the target add'on is not installed is less efficient if you don't use :NEEDS too.

Interestingly enough, I just remembered a previous interaction between us about this subject, at that time another Fellow Kerbonaut had stepped up to confirm my results!

Spoiler

 

At that time, :FOR was the focus of the discussion, but the Fellow Kerbonaut also corroborated my thesis that :NEEDS is also beneficial for :AFTER and :BEFORE.

So, yeah. Sleeping every night makes wonders for one's memory!

Edited September 11, 2024 by Lisias
Rolling back the rollback.

[D. Düsentrieb]

First of all, let me thank you very much for your work.

I would like to ask you, if it is possible to have all the subcategories not shown open as a default.

Best Regards, Daniel

[Streetwind]

This is the best mod I never knew existed. Until now.

Outstanding work as always, Nertea!

[Trainzack]

After only a few days of using this mod, I can now no longer imagine myself ever not using it. Great work!

I did notice one minor sticking point. I generally leave the sorting on profile. For all of the inline parts, I'm able to easily compare the sizes of the parts because I know what the profile is. For the surface attach parts, that's not really possible the same way. I've noticed this most when selecting antennas, and they aren't necessarily in the order I expect. I'm not sure how this issue could be fixed, but I figured I'd bring it up.

[Nertea]

On 11/13/2024 at 7:56 AM, Trainzack said:

After only a few days of using this mod, I can now no longer imagine myself ever not using it. Great work!

I did notice one minor sticking point. I generally leave the sorting on profile. For all of the inline parts, I'm able to easily compare the sizes of the parts because I know what the profile is. For the surface attach parts, that's not really possible the same way. I've noticed this most when selecting antennas, and they aren't necessarily in the order I expect. I'm not sure how this issue could be fixed, but I figured I'd bring it up.

Unfortunately often the order one expects is often different per person :D. 

The secondary sort order for identical bulkhead profiles (ie the order when 2 parts are the same) is based on part alphabetical title to have maximum correspondance with stock. This could probably be changed though.  

[superbroleon]

My lord, Chris. I don't believe my eyes... The crappy parts UI organization was the thing keeping me from going back and enjoying KSP 1 some more. This is glorious! Thank you so much for not giving up on KSP!! <3

[Cruesoe]

I am working on configs for RP-1 to organise all the parts.  I am working my way through and have a lot done already there is just one thing I can't figure out how to do so I am calling on those with better MM knowledge than myself!

The size bulkhead profiles applied by VAB Organizer are largely irrelevant to RP-1  (I may use them for other purposes, such as fuel etc). 

How can I create a simple MM patch to remove the bulkheads assigned by VAB Organizer?  I have tried a few variants but can't get it to work.  I would really appreciate some guidance if anyone knows how to remove this assignment via a MM patch.  Thank you!

[mark7]

I found a really strange bug.

With VABO installed, all of the Breaking Ground Hydraulic Cylinder stopped responding to manual input. The Rotors and hinges are fine, just the pistons. 

I found this bug several days ago, and only today did I find a reddit post from 6 yrs ago saying that Removing Filter Extensions - Default Configuration made the pistons respond to manual input. I removed VABO and things now back to normal.

I checked the debug console, no apparent errors are present.

You can find the log file here