Create Extension Systems

import {
  Asteroid,
  Home,
  Level,
  Dimensions,
  DimensionsData,
  PositionData,
  Spawned,
  UsedTiles,
  P_AsteroidData,
  P_Asteroid,
  P_Blueprint,
  P_EnumToPrototype,
  P_MaxLevel,
  P_RequiredTile,
  P_Terrain,
} from "primodium/index.sol";

Previously we imported Tables directly, one at a time. However, MUD collects and exposes them in index.sol automatically, so we're going to use that now.

import { EBuilding } from "primodium/common.sol";

Primodium stores lists of entity lookup keys in common.sol as enumerations. Here we can find buildings, resources, units, etc.

import { Bounds, EResource } from "src/Types.sol";
import { BuildingKey, ExpansionKey } from "src/Keys.sol";

We use structs to pass around collections of related data; these can be found in Types.sol. Similarly, we have some internal keys we used look up data, and those can be found in Keys.sol.

import { FunctionSelectors } from "@latticexyz/world/src/codegen/tables/FunctionSelectors.sol";

Normally we won't need this. However, there is a bug (opens in a new tab) in how MUD v2.0.1 handles function selectors when using callFrom. We need to use callFrom to interact with systems that take action for the user, so we're going to use this to workaround the bug until it is resolved in future versions.

bool playerIsSpawned = Spawned.get(playerEntity);

Spawned is a Primodium Table we can call to check if a player has started playing. You can examine the imported contract, and see what types to expect in return, and any other functionality it provides. Most of the time we will only be using get() and set().

EBuilding building = EBuilding.IronMine;

Enumerations let us use clear names instead of magic numbers to represent data. It makes the code much more readable. Enumerations decode to uint8 in the abi.

PositionData memory position = getTilePosition(asteroidEntity, building);

This function gets pretty complex. We will walk through it in detail later, but at the high level, the map on each asteroid is broken into a tile grid, and this function walks the map and looks for an appropriate tile for the building passed in.

ResourceId buildSystemId = WorldResourceIdLib.encode(RESOURCE_SYSTEM, PRIMODIUM_NAMESPACE, "BuildSystem");
bytes memory buildingEntity = IPrimodiumWorld(_world()).callFrom(
    _msgSender(),
    buildSystemId,
    abi.encodeWithSignature("Primodium__build(uint8,(int32,int32,bytes32))", building, (position))
);

This is normally how we would call a System that is going to take action for the user. Find the ResourceId for the system, and execute a callFrom using _msgSender() to identify the user, with the signature of the of the function being called. The target System needs to have received delegation permission from the user in advance. We'll discuss delegation later.

The parameters of the function signature deconstruct the struct into its internal native types, to match the abi. Note the extra () around position to indicate that the struct is a tuple.

bytes4 worldFunctionSelector = IPrimodiumWorld(_world()).Primodium__build.selector;
 
(ResourceId buildSystemId, bytes4 buildSystemFunctionSelector) = FunctionSelectors.get(worldFunctionSelector);
 
bytes memory result = IPrimodiumWorld(_world()).callFrom(
  _msgSender(),
  buildSystemId,
  abi.encodeWithSelector(
    bytes4(buildSystemFunctionSelector),
    building,
    position.x,
    position.y,
    position.parentEntity
  )
);

This is our workaround for the MUD function selector bug. The function selector used by the World is different from the original function selector derived from the function signature.

We start in the same place, and find the original signature. Then we check the FunctionSelectors table to retrieve the actual function selector we need to use in callFrom.

Finally, we execute the callFrom using manually built calldata.

buildingEntity = abi.decode(result, bytes32);

callFrom returns bytes memory, so we convert it to the bytes32 we expect and return.