Tech Tree API

The Mods tab

Where your node ends up, why you do not get to pick a category, and the 18-character rule for your sub-tab name.

Two rows of tabs

Tech Tree has three fixed categories - Staff, Store and You - and you cannot add a fourth or put a node into one of them. Everything registered through the API goes into a single extra tab called Mods, which only exists once at least one mod has registered something.

Inside Mods there is a second row: one sub-tab per mod. That is the row your label lands in.

Top row - fixed, at most four

Staff Store You Mods ×

Second row - one per mod, only while Mods is open

‹ Big Boxes Night Owl SuperCart ›

Declaring your sub-tab

One call, once, and you keep the module it returns:

csharp

var tree = TechTreeApi.ForPlugin("BigBoxes", "Big Boxes");
//                                ^guid       ^sub-tab label

Argument	What it is for
`pluginGuid`	The identity of the sub-tab. Two mods that pick the same label still get two separate tabs, because the guid differs.
`tabName`	What the player reads. Trimmed to 18 characters; empty falls back to the guid.

Calling ForPlugin again with the same guid returns the same module and renames the tab. That is what makes hot-reload work.

The 18-character rule

Sub-tabs are a fixed width so that every label gets the same space no matter how many mods are installed. A long name would either squash everyone else's or overflow the row, so it is cut at 18 characters at registration, with a warning in the log. If the trimmed name still does not fit the tab at the player's resolution, the UI ellipsises it.

You pass	Player sees
`"Big Boxes"`	Big Boxes
`"Night Owl Overhaul"`	Night Owl Overhaul 18, exactly fits
`"Rodo's Extended Supermarket Overhaul"`	Rodo's Extended S cut + logged
`""`	your plugin guid

Pick the short name on purpose

Do not name the tab after your mod's full Nexus title. Name it after what the upgrades do. "Big Boxes" reads better in a row of tabs than "Rodo's Extended S".

When there are many mods

The row shows as many sub-tabs as fit at the player's window size. Past that, arrows appear at the ends and page through the list a screenful at a time. They grey out at the ends, and the selected mod is always kept inside the visible page - clicking an arrow never hides the tab you are looking at.

There is no scrollbar and no drag: paging by arrows keeps the header free of a second scroll region fighting the game's own canvas.

Node order inside your tab

Your nodes become the columns of your branch, left to right by SortOrder, then by id. Setting SortOrder explicitly is worth it: the id fallback is alphabetical, which rarely matches the order you would teach someone.

csharp

tree.Register(new UpgradeDefinition { Id = "bigboxes.capacity", SortOrder = 0, /* ... */ });
tree.Register(new UpgradeDefinition { Id = "bigboxes.discount", SortOrder = 1, /* ... */ });
tree.Register(new UpgradeDefinition { Id = "bigboxes.auto",     SortOrder = 2, /* ... */ });

What the tab looks like

The branch colour of the Mods tab is violet, the same for every mod. Node colour is not something a mod chooses - a tree where each mod picks its own palette stops reading as one tree.
The root of your branch is the Tech Tree logo, like every other branch.
Node size is the same in every tab, yours included - it is derived from the built-in categories and nothing a mod registers changes it. A branch wider than the window uses the horizontal scrolling that is already there.

Disappearing tabs

Situation	Result
Your registrations all failed	No sub-tab. If yours was the only mod, no Mods tab either.
You unregistered every node	Your sub-tab goes; the view falls to the first remaining mod.
The last mod is gone	The Mods tab goes; the view falls back to Staff.
A mod registers while the window is open	Both rows rebuild on the next repaint.