[1.12.x] VAB Organizer (August 18)

[AccidentalDisassembly]

33 minutes ago, KeaKaka said:

How easy/possible would it be to add custom subcategories via a patch?

I'm thinking that maybe if a mod were to have a set of parts that would be better suited separated from, say, other liquid engines, would it be possible for that mod to add a custom subcategory without it being included as a default one in VABO?

Yes - it's quite easy. You can create a custom category like this:

ORGANIZERSUBCATEGORY
{
  // My Fancy Category
  name = myFancyCategory // Used to refer to this category in patches
  Label = The Fanciest Freakin' Parts
  Priority = 80 // Think this controls the order of categories in the editor
  CategoryPriority = 10 // ... Or this does
}

Then you can create a patch for whatever parts you want like this:

// If you do an :AFTER[VABOrganizer] here too, presumably it would overwrite whatever VABOrganizer did/didn't do 

@PART[MYPARTNAMEHERE]:NEEDS[VABOrganizer] 
{
  %VABORGANIZER
  {
    %organizerSubcategory = myFancyCategory
  }
}

You can put both those things in the same .cfg file wherever you want, or do the categories separately from the patches.

[KeaKaka]

1 hour ago, AccidentalDisassembly said:

Yes - it's quite easy. You can create a custom category like this:

ORGANIZERSUBCATEGORY
{
  // My Fancy Category
  name = myFancyCategory // Used to refer to this category in patches
  Label = The Fanciest Freakin' Parts
  Priority = 80 // Think this controls the order of categories in the editor
  CategoryPriority = 10 // ... Or this does
}

Then you can create a patch for whatever parts you want like this:

// If you do an :AFTER[VABOrganizer] here too, presumably it would overwrite whatever VABOrganizer did/didn't do 

@PART[MYPARTNAMEHERE]:NEEDS[VABOrganizer] 
{
  %VABORGANIZER
  {
    %organizerSubcategory = myFancyCategory
  }
}

You can put both those things in the same .cfg file wherever you want, or do the categories separately from the patches.

This is perfect, thanks! 

 

EDIT:

Looks like it works exactly as anticipated, and it's definitely the first number that determines position of the subcategory in the editor  (not sure what the second one does)

Edited August 23 by KeaKaka

[SheepDog2142]

40 minutes ago, KeaKaka said:

This is perfect, thanks! 

 

EDIT:

Looks like it works exactly as anticipated, and it's definitely the first number that determines position of the subcategory in the editor  (not sure what the second one does)

Nice I think ill need to add a procedural category to my support mods.

[KspNoobUsernameTaken]

How does this mod work with procedurals? Is it based on the size profile in advanced filters?

Does it support nested categories?

Edited August 23 by KspNoobUsernameTaken
Found the procedural category in the included configs.

[Saturn1234]

Would it be possible to add engine sorting according to ISP?

[JadeOfMaar]

9 hours ago, KspNoobUsernameTaken said:

Does it support nested categories?

Highly doubt. It would get annoying fast to write configs for that if it happened. It would also get annoying fast to have to dig multiple levels if many parts have multiple levels of subcategories.

[KspNoobUsernameTaken]

20 minutes ago, JadeOfMaar said:

It would also get annoying fast to have to dig multiple levels if many parts have multiple levels of subcategories.

Fair, but once you reach 1000-1500 parts even sub-sub-subcategories are better than waiting for the search bar to do its thing.

Probably for the best not to have nested categories. My situation is an edge case with 3k parts.

[Ghosty141]

Fantastic mod, this is just what I was looking for after playing KSP 2 and coming back to KSP 1. Thanks for all the time and effort you put into your mods!

[Grenartia]

9 hours ago, Saturn1234 said:

Would it be possible to add engine sorting according to ISP?

That'd probably be a good suggestion for PRUNES

[Nertea]

On 8/22/2024 at 8:16 PM, KeaKaka said:

Looks like it works exactly as anticipated, and it's definitely the first number that determines position of the subcategory in the editor  (not sure what the second one does)

 

The second number determines the order in the category list for situation. Reminder that as mentioned in the OP there is documentation

https://github.com/post-kerbin-mining-corporation/VABOrganizer/wiki/Configuration

On 8/23/2024 at 7:30 AM, KspNoobUsernameTaken said:

Probably for the best not to have nested categories. My situation is an edge case with 3k parts.

If you have 3000 parts, you have far worse UI issues than this I'm afraid.

Working on a new feature this week: https://imgur.com/a/GgAqDSK

 

[KspNoobUsernameTaken]

2 minutes ago, Nertea said:

Working on a new feature this week: https://imgur.com/a/GgAqDSK

Very nice. Do the values the filters fetch have to be defined in code? For example, if I want to add communication power, is there a way to define in cfg files to get a specific value from ModuleDeployableAntenna?

[Nertea]

Currently things are mostly hardcoded, partially because of some need to do transformations on the data to postprocess the values (e.g. compute ASL thrust) before they're used. 

In the event that you *could* use a raw value out of a config file it should be possible for me to write something, but it's a decent amount of additional effort to implement. There's still a way to go before this is releasable though, so we'll see. 

[dlrk]

I have a feature request, but first let me say how much I, and I presume all of us, appreciate you returning to help make KSP1 the game KSP2 was supposed to be.

Would it be possible to have an option to add/remove parts from subcategories in the editor?

[Nertea]

10 hours ago, dlrk said:

Would it be possible to have an option to add/remove parts from subcategories in the editor?

That's a vast quantity of work for what I would percieve to be very little gain, can you describe the use case?

 

Other topic, the dev branch on git has the advanced sorting stuff in it as a mostly functional prototype now, so can be looked at if you're brave and can stomach a few bugs. Working out the list of sorters  to ship with for various categories too. 

[dlrk]

If it's a vast amount of work, it probably isn't worth  it - the use case though is being able to sort parts into subcategories from within KSP rather than having to do it via CFG

[Nertea]

Yeah for the right ROI I'd do it, but if it's simply for a more user friendly way of categorizing unsorted mods... not really worth it. 

[oleg kerman]

does it support near future tech or cryogenic engines/fuel tanks? 

Spoiler

yes, I know that Nertea made all of those mods  

 

Edited September 6 by oleg kerman
added some edits

[modus]

48 minutes ago, oleg kerman said:

does it support near future tech or cryogenic engines/fuel tanks? 

  Reveal hidden contents

yes, I know that Nertea made all of those mods  

 

Yes 

[oleg kerman]

1 hour ago, modus said:

Yes 

cool 

[modus]

5 minutes ago, oleg kerman said:

cool 

You do need to have the latest versions of those mods!

[urturino]

I'm trying to create patches for some old mods i still use. I'm having some problems with specific parts.

CCGC-7 Nuclear Lightbulb from AtomicAge end up in Light subcategories since its name contain "light"

I have create a patch

@PART[nuclearEngineKANDL,nuclearEngineLANTR,nuclearEngineLightbulb]:FOR[AtomicAge]:NEEDS[VABOrganizer]
{
  %VABORGANIZER
  {
    %organizerSubcategory = nuclearEngines
  }
}

but it still end up in Light.

There is a way to put an exception?

Edited September 8 by urturino

[Coldrifting]

2 hours ago, urturino said:

I'm trying to create patches for some old mods i still use. I'm having some problems with specific parts.

CCGC-7 Nuclear Lightbulb from AtomicAge end up in Light subcategories since its name contain "light"

I have create a patch

@PART[nuclearEngineKANDL,nuclearEngineLANTR,nuclearEngineLightbulb]:FOR[AtomicAge]:NEEDS[VABOrganizer]
{
  %VABORGANIZER
  {
    %organizerSubcategory = nuclearEngines
  }
}

but it still end up in Light.

There is a way to put an exception?

Maybe try replacing that NEEDS[VABOrganizer] with AFTER[VABOrganizer]

[urturino]

52 minutes ago, Coldrifting said:

Maybe try replacing that NEEDS[VABOrganizer] with AFTER[VABOrganizer]

Thanks for the answer, but it didn't work, it's still in "Illumination".

I also tried @PART[nuclearEngineKANDL,nuclearEngineLANTR,nuclearEngineLightbulb]:FOR[AtomicAge]:NEEDS[VABOrganizer]:AFTER[VABOrganizer]

[Lisias]

On 9/8/2024 at 6:29 AM, Coldrifting said:

Maybe try replacing that NEEDS[VABOrganizer] with AFTER[VABOrganizer]

I suggest to keep both.

Besides AFTER does imply NEEDS, the presence of the NEEDS makes patching faster for people that don't have the VABOrganizer installed, as it eliminates the patch pretty early in the process.

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

nope. I'm getting senile, as it appears...  the behaviour I was worrying about was fixed already - for years. (sigh)

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

I'm rolling back my rollback. I just checked the MM source code, puzzled about my mistake.

It happened I was right at first place - but since I'm prone to make mistakes when I'm tired, and tired I was, I wrongly concluded it was the case.

This is how MM does things (ignore any documentation saying otherwise).

1. First, MM extracts all the patches from the GameDatabase here.
   1. On this phase, the patches are extracted using this code, and this is where the :NEEDS is handled - at the very, very begging of the patching process! See here
   2. If the :NEEDS is unsatisfied at this point, the whole patch is thrown away on the spot, preventing further processing.
   3. Otherwise, the patch is "compiled" here.
2. Now MM runs the patches that survived the compiling phase.
   1. And since the unsatisfied :NEEDS patches were prevented from being compiled, we had saved some processing by using it by now.

Edited September 10 by Lisias
uh.... never mind the never mind!! X-P X-P

[JadeOfMaar]

11 hours ago, urturino said:

I'm trying to create patches for some old mods i still use. I'm having some problems with specific parts.

CCGC-7 Nuclear Lightbulb from AtomicAge end up in Light subcategories since its name contain "light"

I have create a patch

@PART[nuclearEngineKANDL,nuclearEngineLANTR,nuclearEngineLightbulb]:FOR[AtomicAge]:NEEDS[VABOrganizer]
{
  %VABORGANIZER
  {
    %organizerSubcategory = nuclearEngines
  }
}

but it still end up in Light.

There is a way to put an exception?

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
	}
}

 

8 hours ago, Lisias said:

AFTER does imply NEEDS

Yes.

8 hours ago, Lisias said:

I suggest to keep both.

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.

 

9 hours ago, urturino said:

:FOR[AtomicAge]:NEEDS[VABOrganizer]:AFTER[VABOrganizer]

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