Mega 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
Mega Tree has three fixed categories - You, Staff and Store - 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.
The three built-in tabs are always drawn, even when one is empty - a greyed "Store · SOON" tells the player more is coming. The Mods tab is the opposite: with no mod installed it is not drawn at all.
The reason is what a greyed tab promises. "Store" is work I owe the player. "Mods" would be offering something they cannot get by waiting - they would have to go and find a mod that might not exist yet.
Declaring your sub-tab
One call, once, and you keep the module it returns:
var tree = MegaTreeApi.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 Megastore Overhaul" | Rodo's Extended M cut + logged |
"" | your plugin guid |
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 M".
When there are many mods
The row shows five sub-tabs at a time. Past that, arrows appear at the ends and page through the list five at a time, greying out when there is nothing more in that direction.
There is no scrollbar and no drag: paging by arrows keeps the header free of a second scroll region fighting the tree's own.
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.
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, and deliberately unlike the three game colours. 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 carries your sub-tab name, where a built-in branch carries the category name.
- Your branch is scaled to your own width. Mega Tree fits each tab to the window on its own, so a mod with two nodes gets a full-size drawing even if another mod has thirty. Trees of different sizes are not squashed to a common ruler.
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 You. |
| A mod registers while the window is open | Both rows rebuild on the next repaint. |