API restructuring (Terraria.ModLoader namespace)

The core ModLoader namespace has always suffered from scope creep and bloating. Some classes have been moved to the Core and Engine namespaces, but there’s currently no bookkeeping thread for the class list and naming conventions. First we’ll categorise all classes in this namespace, then we’ll provide refactoring/restructuring suggestions. Most of this will likely not happen till 1.4 for compatibility but we should be prepared with our designs.

Content Classes

These classes correspond to Terraria game objects, and need to be tracked by tML with data and hooks. Instantiated at load time.

Content	Global	Loader	Extra
Mod		ModLoader	ModProperties, ModSide
ModBackgroundStyle	GlobalBackgroundStyle	BackgroundStyleLoaders
		BackgroundTextureLoader
ModBuff	GlobalBuff	BuffLoader
ModCommand		CommandLoader
ModDust		DustLoader
EquipTexture		EquipLoader	EquipType, AutoloadEquip
ModGore		GoreLoader
ModKeybind		KeybindLoader
ModItem	GlobalItem	ItemLoader
MapEntry		MapLoader	MapLegend
ModMount		MountLoader	MountTextureType
ModNPC	GlobalNPC	NPCLoader	NPCSpawnInfo
		NPCHeadLoader	AutoloadHead
ModPlayer		PlayerLoader
ModPrefix		PrefixLoader
ModProjectile	GlobalProjectile	ProjectileLoader
ModRecipe	GlobalRecipe	RecipeLoader
ModSound		SoundLoader	SoundType
ModTile	GlobalTile	TileLoader
ModTileEntity		missing
ModTranslation		LocalizationLoader
ModWall	GlobalWall	WallLoader
ModWaterStyle		WaterStyleLoader
ModSystem		SystemLoader
ModTree/ ModPalmTree/ ModCactus		> TileLoader
PlayerDrawLayer		PlayerDrawLayerLoader

Utility Classes

Public classes which are used by mods to interact with hooks or perform common functions. Instantiated during gameplay. Classified as either hooks or helpers.

Class	Designation
DrawableTooltipLine	Hook
DrawInfo	Hook
DrawLayer	Hook
ModPacket	Hook
NPCSpawnHelper	Helper
RecipeGroupHelper	Helper
MusicPriority	Hook
TooltipLine	Hook

ModLoader Core Classes

Core mod content management classes, with public functions mods are expected to use.

Class
CombinedHooks
ErrorLogger (Deprecated)
FrameworkVersion
Logging
ModContent
ModNet
MonoModHooks
TopoSort
MusicWrappers

Proposed Refactors

• ~ModProperties -> AutoloadProperties~ removed
• Move helper utilities to “Helper” or “Utilities” sub-namespace
• ~Check ModUgBgStyle/ModSurfaceBgStyle for common code~ unified via ModBackgroundStyle
• ModMountData -> ModMount
• Loader vs Hooks naming. Currently roughly LoaderX if GlobalX exists, otherwise HookX. Should we keep this, and fix the non-conformers, or just pick one and stick to it.
• Missing loader classes. Should all static bookkeeping be done in a separate Loader/Hook class? Most of the missing loader classes just weren’t made because there weren’t enough hooks required, or just a single id array/dictionary.
• Mod Translation loader, the autoloader is currently in ModInternals, and ModContent handles all the Translation -> LocalizedText updates, should we split this out?
• Pretty much every content class has common fields Mod mod; string name;. Make a parent class for all tracked mod content.
• Move all autoloading code out of Mod, or at least to partial class with more shared code between functions
• Merge a lot of the Mod.AddX common code, and move the other parts to the loader classes]

[JavidPack]

I want to make sure we throw an error in XType and GetX, rather than return 0 or null. A TryGetX or something would be needed.

Returning 0 isn’t usually an issue, but it’s a little weird.

[Chicken-Bones]

This is mostly done. Closing. Remaining issues #1347, #1506