This type of code doesn't look correct to me.
The hatches and buses are not necessarily implementations from gregtech/common

          MetaTileEntity mte = GregTechAPI.META_TILE_ENTITY_REGISTRY.getObjectById(tooltipBlockStack.getItemDamage());
            if(mte instanceof MetaTileEntityItemBus || mte instanceof MetaTileEntityFluidHatch) {
                tooltip.add(1, TextFormatting.WHITE + I18n.format(infoPage.getBusTooltip()));
            }

You should instead be checking something like:

if (mte instanceof IMultiBlockAbilityPart) {
    MultiBlockAbility ability = ((IMultiBlockAbilityPart) mte)).getAbility();
    if (ability == MultiBlockAbility.EXPORT_ITEMS || etc.) 
}

I don't want to introduce feature creep, but it would be good if you implement this in a way thinks about a possible future PR
that introduces tool tips from the real structure info/recipe map,

e.g. how many hatches/buses you really need.
e.g.2 the minimum casings

pseudo code:

MultiblockAbility ability = ...;
if (controller instanceof RecipeMultiBlockController) {
   addMinTooltip(controller.recipeMap, ability));
   addMaxTooltip(controller.recipeMap, ability);
}

I don't think you can actually implement it that simplistically since these recipemap constraints are actually hidden behind predicates and might not be the real constraint?

I don't think you can actually implement it that simplistically since these recipemap constraints are actually hidden behind predicates and might not be the real constraint?

Just spitballing;

Absent some additional plumbing to expose the real constraints, you could hack it by adding something like

public MultiblockControllerBase {

    public boolean isSimpleConstraints() {
        return false; // Override on multiblocks that don't have complicated constraints
    }
}

This would give the JEI plugin a hint that it can bypass the full constraint system and use the simpler source constraints.

I have changed this PR to instead accept a Map<MultiblockAbility, List<String>> so that tooltips can instead be added to any MultiblockAbilityPart, and in addition, multiple tooltips can be added to the same part.

This is an example of multiple tooltips being added to the same part:

The "Invalid Structure" in this image was just a test of the multiple tooltips.

I also think that tooltip map could be cached in the recipe setup. It does not need to be dynamic.

I believe the way you are doing it, it will be creating that map on every rendering tick?
Probably not super important though.

This looks like good idea but I would like to open here discussion how we can make this to show minimal tier for tier dependent MultiblockParts like rotors, energy outputs and so on. As that would significantly enchant this.

but I would like to open here discussion how we can make this to show minimal tier for tier dependent MultiblockParts like rotors, energy outputs and so on

The way I see it, is that each JEI MB definition can override the generateToolTips() to add tips that are specific to its usage.

In future, if the opaque predicate problem is solved, these tool tips could instead be generated from the real MB pattern and recipe map automatically instead of having to define them in the JEI pattern.

I really like @warjort suggestion regarding implementation and I think that is the way to go forth on this. With possibility to override (and possible not call at all) default values we could make this work for anyone.
@ALongStringOfNumbers can you please try implementing that suggestion?

I have done the refactoring of how the tooltips were created and stored as suggested above. However, now I am thinking that I should store tooltips for ItemStacks instead of MultiblockAbilitys. This is so that tooltips can be added to non-multiblock parts to more easily declare part limitations for the multiblocks.

For example, when using MultiblockAbilitys, tooltips would not be able to be applied to the Heat proof casings on the EBF, which would be something that we want to do to convey the minimum part requirement of 10 for the casings.

Switching to Itemstacks would also make it easier for tooltips to be applied to more blocks in custom multiblocks created by MultiblockTweaker, as blocks in those structures have less of a chance of being MultiblockAbilitys.

I am putting this comment here for some feedback.

Does anyone know if there is a way to apply TextFormatting to TextComponentTranslatable without having the TextFormatting codes in the lang entry? I wanted to switch the Tuple<String, TextFormatting> to a TextComponentTranslatable to take advantage of the substitutions in the lang file entry (So that I could create a universal tooltip for minimum casing limit, instead of having one per multiblock), however, I was not able to find a way to apply formatting when the formatting is not in the lang entry in format codes.

Switching the formatting to being in lang codes instead of in the Tuple is not that big of a deal, I just wanted to see if anyone knew how to apply formatting outside of the localization entry.

You need to use setStyle and then apply color inside of the Style object

Does anyone know if there is a way to apply TextFormatting to TextComponentTranslatable without having the TextFormatting codes in the lang entry?

Do you mean?

new TextComponentTranslatable("translation.key").getStyle().setColor(TextFormatting.GREEN);

Using ITextComponent instead of that Tuple looks like a much better api.

I have switched to using an ITextComponent for the second map parameter and right now am working on some default tooltips for multiblocks in GTCE.

I have now added some tooltips for GTCE multiblocks, beyond the default tooltips saying that any tier hatch/bus can be used.

Some examples are:

As well as tooltips for the minimum number of casings required to form the structure:

As this information is not currently obtainable from the Pattern Builder, the limits are set manually for each structure.