Skip to main content

Mods Guide: Best Mods, Install & Console Tips

Mods add or change content and behavior in Mindustry — new blocks, items, liquids, units, sectors, planets and scripting hooks — enabling community-created gameplay, visuals, and maps. This page summarizes how mods are structured, what they commonly include, how to access or develop them, and practical tips for using them.

What a mod can contain

  • New blocks (walls, turrets, factories, power blocks, conveyors, special-purpose blocks). Example types shown in community examples: custom walls, wall tiles, and defense blocks.
  • New items and liquids (resources, fuels, fluids such as custom liquids).
  • New bullets/ammo types and turret ammo mappings (you can add or copy bullets and assign them to turrets).
  • New units and unit factories.
  • New planets, sectors and sector generators (including hidden or community-created sectors that replace or augment procedural sectors).
  • Visual assets and drawing layers for blocks (regions, shadows, extra draw layers).
  • Scripting, handlers and processors for custom behaviors, including Java/JavaScript content parsing.
  • Mod-side overrides and linked-block behaviors that forward item, liquid, and power handling to other tiles.

Common technical patterns and APIs

  • Content extension: Mods commonly extend base classes to create new content (e.g., extend Wall to make a custom wall, or GenericCrafter for factories). When creating content the constructor sets name, descriptions and flags like solid.
  • Copying and modifying existing content: You can copy bullets, ammo types or blocks, modify fields (damage, visuals, requirements) and register them, avoiding changes to originals.
  • Item/liquid acceptance and handling: Blocks can override acceptItem/handleItem and acceptLiquid/handleLiquid to delegate to linked tiles or implement custom routing logic. Power hooks can similarly delegate addPower calls to linked tiles.
  • Drawing and layers: Blocks define regions and may specify extra drawing layers (layer2) or custom shadow regions for visuals.
  • Build visibility and requirements: Blocks include buildVisibility, requirements, buildTime and size fields to control when/how they appear and how they're constructed.

Sectors, planets and map content

  • Mods can add complete sectors and planets. Community-created "hidden" attack maps are used by some modded campaigns and replace procedurally-generated sectors in seeds; authors often tag notes about resources and defenses (for example, maps with abundant Shock Mines, or endgame defenses with Plastanium/Phase Walls).
  • Planets can be made accessible or visible via console flags when testing (e.g., Planets..accessible = Planets..alwaysUnlocked = true).

Developing mods: languages and tools

  • Java and JavaScript are supported for creating mods. The modder workflow can use Java for core changes or ContentParser-style scripts for content JSON-like creation.
  • Essential mod assets: definitions for items, liquids, blocks, units, bullets, planets/sectors and localized bundles (name/description) are typical.
  • Beginners should start by copying and editing example content (walls, turrets, bullets) rather than reinventing from scratch.
  • Useful modding areas to learn: items & liquids, factories (GenericCrafter), production/electric blocks, turret drawing parts, effects/sounds/statuses, units/weapons/abilities, planets/sectors/generation, and locating classes/fields in the game code.
  • Tools and flows: Many modders move between Java and JavaScript (JavaJS) and use community tooling (ACD, ContentParser) when appropriate.

Installing and accessing mods

  • On Android, the official release and beta builds are available via Google Play (become a beta tester to get latest builds). iOS test builds are distributed via TestFlight.
  • Some mod content or hidden items/planets can be unlocked or made visible through the developer console (press F8) by setting the planet or object visibility flags to true.
  • Official-mod content: some mods are authored by the developer(s) and distributed as "official mods" inside the community; these appear in mod lists but behave like community mods.

Example snippets and patterns

  • Assigning a custom bullet to an existing turret's ammo table (JavaScript style):
    • Example: Blocks.duo.ammoTypes.put(Items.pyratite, Blocks.hail.ammoTypes.get(Items.pyratite))
  • Copying a bullet and changing a property:
    • Example pattern: bullet = Blocks.hail.ammoTypes.get(Items.graphite).copy(); bullet.damage = 200; Blocks.hail.ammoTypes.put(Items.titanium, bullet)
  • A minimal custom wall definition (JavaScript-like):
    • Example pattern shows setting region, health, category, size, requirements, buildTime, icons and description when extending Wall.

Best practices and community norms

  • Reuse and copy existing content where possible to stay compatible with game balance and visuals.
  • Keep localization keys in Bundles (block.[name].name and block.[name].description) to support translations.
  • Test new sectors and planets with console visibility flags before releasing.
  • Contribute via issue reports or pull requests for bugs if you can code in Java; join community channels for translations, discussion and feedback.
  • When creating complex linked blocks, ensure overridden methods properly delegate accept/handle functions and power routing to linked tiles to avoid broken supply chains.

Where mods are used

  • Mods power custom survival maps, community-made attack sectors, new campaign content and quality-of-life tools for creators.
  • Some official and community mods are packaged as add-ons and distributed through the mod browser or external hosting.

This guide covers the common structures and workflows you will encounter when using or making Mindustry mods: content extension, asset and behavior overrides, sector/planet additions, and practical steps for testing and distribution.

Pages featured in this guide