Reassembly's May 20th update gave modders the ability to create their own custom shapes to use within a mod, rather than create blocks using only pre-existing shapes already defined within the internal files. This can be accomplished by including a shapes.lua file within a mod package. An example file that shows the definitions of all the standard shapes can be found in Reassembly\data.


Throughout this guide, I will be using the THRUSTER shape as an example due to it's simple shape, and it's property of containing non-default ports.

This graph will be used to visually represent the code in order to aid in understanding. Points in this graph will represent a single unit of distance, going up to 5 in any direction




It is easy to feel overwhelmed by the sheer size of the example file shapes.lua (The region describing the square alone is 33 lines line), but once broken down, it is suprisingly simple to understand. The incredible size of shapes.lua is mostly caused by reassembly's requirement to have every possible scale of a shape have it's own definition (The smallest scale of square is defined in only one line).

The rules concerning vertices, as described at the start of shapes.lua, are:
In addition, vertices are automatically assigned a "VTX_IDX", or ID number starting at 0 based on their order within the code.

This means that you are allowed to plot the vertices of your shape starting at any point as long as remaining points are then listed in clockwise order.
The rule concerning convex shapes isn't as strict, as it is possible to make shapes containing concave sections (Such as SENSOR) -- but these can cause the console to spew out errors, or even potentially cause crashes.

Vertices are to be listed in the format of coordinates, and are to be strictly ordered clockwise around the orgin (0,0).

For example, the code...
...creates the following shape that looks like just the block it will create in game!

The rules concerning ports, as described at the start of shapes.lua, are:


The format means that a port is defined first by it's VTX_IDX, or ID, that is assigned by it's order within the code.

LERP defines a ports position between the vertex specificed, and the next vertex in order -- looping back to 0. LERP can be a value from 0 to 1, which represents a precentage of the distance between the vertices

TYPE defines how a port interacts and what it does. If left unspecified, the port will be set to the NORMAL type. The following are valid port types:

NORMAL: Allows the block to connect to other NORMAL type ports at that point

THRUSTER_IN: Allows the block to connect to a NORMAL type port, or to a THRUSTER_OUT type port

THRUSTER_OUT: Creates a specific point where thruster effects are emitted from

MISSILE: Defines where a replicant block will try to connect to the replicator block

LAUNCHER: Defines a point where a block can be replicated

WEAPON_IN: Allows the block to connect to a NORMAL type port, or to a WEAPON_OUT type port

WEAPON_OUT: Creates a specific point were cannon fire is emitted from

ROOT: Allows the block to connect to a NORMAL type port on a seperate entity

NONE: Does not create a port

Note that it is not neccesary to use the NONE type, since if an VTX_IDX does not have an associated port defined, it will simply not create a port.


For example, the code...
...creates the following shape that behaves like just the block it will create in game!