Overview
If “blocks.lua” means anything to you, this might be a helpful reference.
Preamble
While Reassembly at the time of writing doesn’t support things like Steam Workshop for sharing weird new blocks and changes and whatever, the developer of the game has made modifying the game pretty simple to anyone with a working text editor!
I have by no means any extensive knowledge of this game, I was never an alpha tester and only jumped into the game sometime in March. However, having compiled a short reference document for my own benefit, I’ve decided to post it up as a guide for others in case anyone can help fill in the gaps of what I have.
As a result, this guide is gonna be ugly given it was originally just my personal notes. Advice for presentation would be well received, I’m not entirely sure how to format what I have already.
What even is a blocks.lua anyway
The secret to block modification relies upon the file blocks.lua. This file will be located in your home directory (which is C:Users[yourname] on Windows, and on every other OS you probably have a better idea of what your home directory is) under Saved Games/Reassembly on Windows, and, uh, possibly the same folder for other OSes. (Please feel free to correct me on this for people using other OSes.)
Or, most likely, if you aren’t familiar with “blocks.lua”, it will not be there. To get the game to generate it, we need to edit a file called cvars.txt in the same location.
Inside this file, to CREATE blocks.lua, add this to the end of cvars.txt after everything else:
Run Reassembly and then close it. Delete this line (or set it to 0) when you see blocks.lua has been created. If you do not change it back to not writing the blocks.lua file, all changes you make to blocks.lua will be overwritten on game launch.
Now, to make the game USE blocks.lua, you need to add this to the end of cvars.txt:
This will cause the game to read in blocks from blocks.lua as opposed to generating them from hardcoded information. You can now freely modify blocks.lua to add and edit whatever blocks you like! Remember to back up your changes to blocks.lua, preferably in a different file, just in case the game decides to overwrite it with the hardcoded information for any reason in the future.
Useful Testing Information, or, An Incredibly Abridged Guide to the Sandbox
As said in the past section, block definitions you come up with should ideally be edited and saved in some text file somewhere safe, separate from any of Reassembly’s files. While you’re testing out individual block definitions and experimenting, you probably don’t want to be editing blocks.lua over and over again with each minor change.
Fortunately, with the sandbox, you don’t need to keep saving blocks.lua, quitting Reassembly and relaunching it! You can instead use the command “block {your definition here}” to spawn a block with the definition you’ve created! I haven’t covered what a definition requires yet, but this is great for testing random changes. Some knowledge of the sandbox might be helpful too. I was planning to write a complete guide to the sandbox, but I’m still not sure what some of the more obscure commands do.
Some useful things to keep in mind with regards to the sandbox:
– You can toggle the cursor with .
– You can make the console bigger or smaller by typing [ and ] with your cursor NOT over the console.
– The console only takes input when your cursor is over it.
– You can move the sandbox cursor by double-clicking anywhere (or by using the commands ‘cursor’ or ‘rcursor’).
– You can change sandbox modes by using the number keys.
- 1 with a ship selected lets you fly the ship.
- 2 is the default select ship command mode.
- 3 activates editor mode for the entire world, with the same commands and keys as in the editor.
- 4 is plant mode and I don’t have any idea at all how plant mode works or what it does.
– You can spawn a palette of blocks for a faction by typing ‘minpalette [faction]’ for blocks and ‘palette [faction]’ for all sizes of all specified blocks.
– You can spawn all of the ships for a faction by typing ‘fleetpalette [faction]’ to quickly get ships to test fly with.
– And to quickly get a random assortment of ships to test, ‘fleet [faction]’ will just put down some ships of a faction.
However! There is a drawback to defining blocks at runtime in this way. Any connections between identical but resized blocks won’t exist (so you can’t resize blocks in the editor), blueprints won’t be formed for runtime defined blocks, and you can’t duplicate runtime defined blocks while they’re connected to anything. They’re finnicky. You’ll probably want to put blocks you’re happy with into blocks.lua to make sure they work better.
Block Definitions
Blocks are defined as Lua table literals. As such, the information is given in a key-value setup encased in {curly brackets}, where a key is defined and set to some value using =, eg. {key=”value”}. Lua tables can also contain tables, eg. {table={thing=3}}, and don’t require types to be specified for the values associated with keys, as Lua is a weakly typed scripting language. This isn’t necessary to know, but I felt it was worth mentioning.
In this guide I will be giving keys and the expected type for the value in [square brackets]. If none of my terms make any sense to people in North America, I’m sorry, I’m encasing things in the symbols I’m trying to describe just to make it clearer what the hell I’m talking about.
Block definitions must be enclosed in curly brackets and can contain as much or as little definition as is required. There are defaults for values not given, but I’m not 100% sure on what the defaults are for all parameters.
Oh, and an extra thing to keep in mind: when you give your blocks IDs and put them into the blocks.lua file, make sure to put them somewhere where they fit in numerical order. For example, if your block IDs are in somewhere of a range between 16000 and 60000, make sure to put them after block ID 16135 and before block ID 60100, or they won’t load in the proper order.
Common Block Properties
id [number]
– This part is not actually labelled and is always the first element in the block definition, eg. {101} by itself is a valid block definition that sets the block id to 101.
name [string]
– Names the block. Simple. eg. name=”Block”
blurb [string]
– This is the description of the block. Rarer than names because coming up with descriptions for blocks gets incredibly tiresome very fast. eg. blurb=”This is a block. How droll.”
features [flags]
– This is interesting and consists of a list of flags chained with | (bitwise or), eg. COMMAND|EXPLODE|INTLINES. The features themselves are discussed later in the guide.
group [number]
– This assigns the faction the block is associated with. Obviously everyone is familiar at this point with the standard ~15-16 that many other guides that aren’t this guide have covered in much greater detail, but other things to note are faction 100, used for block fonts, and that agents will be assigned an arbitrary unused faction when they are pulled into the game. As far as picking a custom faction number, I have no idea what best practices are, but try to stay away from higher numbers as they seem to be what agents get assigned to.
NOTE: THIS DOES NOT POPULATE THE IN-GAME EDITOR PALETTE. I have no idea how to do this as a default thing! It IS possible to edit your save files (and I barely understand how myself, unfortunately) to change the editor in one of your saved games to show arbitrary blocks, but as far as starting out, I’m pretty sure things are hardcoded.
blockshape [flag]
– This’ll be covered later on. There’s a lot of them. Not specifying a blockshape gives you a standard square. eg. blockshape=RECT_LAUNCHER
blockscale [number]
– This determines how big the block is, and defaults to 1. This determines if the block is 2x, 3x, 4x etc. sized — but BE INCREDIBLY CAREFUL, because invalid blockscales will cause a physics crash! It’s worth noting that duplicated definitions of blocks that only vary in blockscale will be ‘connected’ together as different sizes of the same block. This lets you control just how much you can resize a block. eg. blockscale=2
health [number]
– This doesn’t do anything. It seems to be left-over. You want durability for health.
durability [number]
– Calculates health based on the block’s area, and defaults to 1. For fragile components, make this number smaller. For more durable, bigger. eg. durability=0.800
density [number]
– Calculates mass based on the block’s area, and defaults to 1. For light components, make this number smaller. For heavier, bigger. eg. density=5.200
fillColor [color]
– The first colour a block has. Given in 0xRRGGBB format (I hope you know how hex colours!) eg. fillColor=0xFF0000
fillColor1 [color]
– The second colour a block has. Blocks will slowly fade between both colours, giving Reassembly its distinct look. eg. fillColor1=0xFFFF00
lineColor [color]
– 0xRRGGBB, yadda yadda yadda, line colour. Some factions have lighter line colours than their fills, and some don’t. eg. lineColor=0xFFFFFF
capacity [number]
– The amount of R a block holds. Defaults to 0. eg. capacity=100
growRate [number]
– How fast the block regenerates. Default is 16.50. No idea what the units are but higher numbers lead to faster regeneration. eg. growRate=20.000
Block Features & Related Properties
These are flags that define more advanced behaviour for blocks, and make them, well, do anything interesting. Some features require additional information, which is given underneath their description.
ENVIRONMENTAL
– Plants can grow on this block. Whee.
ROOT
– This block can anchor the probably-a-building-or-a-plant it’s part of to a something-else.
INTLINES
– This block will show its outlines regardless of anything else it’s connected to. This gives faction 6 ships a pretty interesting look.
MELEE
– This block withstands collision force more readily, and inflicts five times more damage on collision.
AUTOFIRE
– Makes a weapon autofire! This basically causes a block to act as a point defense weapon. You just need to set the flag. Nothing else is needed.
FACTORY
– Makes the block a factory. Make sure to keep attachment points clear for faction command modules to spawn on it!
ASSEMBLER
– This block will regenerate and pull blocks to repair the rest of the ship it’s attached to. Pretty much always found as a feature on command modules. Probably isn’t designed to be a feature of anything else.
FREERES
– Free resources? Doesn’t need resources? No idea what this means.
REGROWER
– Weird plant behaviour that makes plants grow into their blueprint from their seed instead of assembling like normal ships.
SELFFACTORY
– This block is used by faction 7 and screws all the rules and causes terrible crashes and basically just don’t use this.
TELEPORTER
– This block allows for teleportation, which the player can’t use.
TELESPAWN
– Does this even do anything? Only some stations for faction 8 have this. Seems like a leftover.
DEACTIVATES
– When this block is destroyed, the block deactivates but remains intact. Only faction 8 station command modules have this.
THRUSTER
– This block provides thrust! Probably best to use this with thruster blocktypes.
Related properties:
thrusterForce [number]
– How much force this thruster provides. eg. thrusterForce=2000.000
thrusterColor [color]
– 0xAARRGGBB format, every block I’ve seen in blocks.lua uses 90 (144 in decimal) for alpha, defines the main particle trail colour. eg. thrusterColor=0x902010F0
thrusterColor1 [color]
– 0xAARRGGBB, harder to nail down exactly what this colour effects. Seems to be a ‘slower’ trail that is most visible for faction 12 ships.
TORQUER
– This block provides torque. Mostly used in missiles and drones and some command modules, and no existing blocks in the main game have this property by themselves. It basically lets things turn without needing thrusters and is therefore required by single block ‘ships’ to turn.
Related properties:
torquerTorque [number]
– Amount of torque force provided, not sure of units. eg. torquerTorque=2000.000
EXPLODE
– This block EXPLODES! On a timer. Good for mines and missiles.
Related properties:
lifetime [number]
– Amount of seconds the block lives before exploding. eg. lifetime=10.000
explodeDamage [number]
– How much damage the explosion causes, and proportionally how much force the explosion has in it. eg. explodeDamage=100.000
exploreRadius [number]
– How big the radius of the explosion is. eg. explodeRadius=100.000
GENERATOR
– This block produces power, and will explode when destroyed.
Related properties:
powerCapacity [number]
– How much power this generator can hold. eg. powerCapacity=100.000
generatorCapacityPerSec [number]
– How much power this generator can produce per second. eg. generatorCapacityPerSec=10.000
TURRET
– This block has a turret for its weapon. I haven’t tried defining this without also defining a weapon. I don’t advise doing it.
Related properties:
turretSpeed [number]
– How quickly the turret turns. Not sure of units, possibly radians or degrees per second. eg. turretSpeed=20.000
CHARGING
– Allows a weapon to charge. No idea how this actually affects the weapon. Presumably it boosts some properties, but I am not sure entirely how.
Related properties:
chargeMaxTime [number]
– Amount of time to charge to maximum. eg. chargeMaxTime=5.000
chargeMin [number]
– I’m gonna be honest here. I don’t know if this is a minimum time or minimum proportion of charge required to fire. The only existing examples use 0.5, 0.3 and 0.2 as values.
PHOTOSYNTH
– This block generates resources from starlight or whatever.
Related properties:
photosynthPerSec [number]
– Amount of resources generated per second. The higher the amount, the faster the graphical effect spins. eg. photosynthPerSec=5.000
TRACTOR
– Pulls resources into ship. Pretty straightforward. Most command modules have this.
Related properties:
tractorRange [number]
– Radius of the range the tractor can reach.
SEED
– Plants are weird and play by their own rules. Seed blocks will latch onto environmental blocks and begin to grow.
Related properties:
launchSpeed [number]
– The speed at which the seed launches from its former plant. eg. launchSpeed=200.000
launchLifetime [number]
– The amount of seconds the seed has to plant before it dies, ungrows and becomes precious, precious R. eg. launchLifetime=30.000
launchResources [number]
– The precious, precious R the seed actually contains at launch. eg. launchResources=1.250
seedLifetime [number]
– The amount of seconds the plant lives as a whole from seed launch. eg. seedLifetime=180.000
Complex Table-Based Block Features
(or, ‘only a section because guide sections have character limits’)
These flags require their parameters to be specified in a complex table format. Tables within tables!
COMMAND
– This block is a command module. I have to admit I’m not too clear on the properties of this one.
Related properties (FAR FROM COMPLETE):
command
– A table filled with command-specific properties. Here’s an example:
{faction=[faction number], disruptTime=[number, amount of time in seconds of, uh, disruption? not sure what this is], ident=[number, something in hex, probably auto-assigned, best not to touch], resources=[number, amount of resources owned by ship], energy=[amount of energy available to ship], blueprint=[string, name of ship design that this ship will conform to], flags=[chain of flags, hardcoded how they’re assigned, probably best to ignore these]}
CANNON
– Cannon weapon.
Related properties:
cannon
– The definition for the cannon.
Inside the table will be the following parameters:
roundsPerSec [number]
– The amount of rounds fired per second.
roundsPerBurst [number]
– How many rounds fire per burst. Used for burstyness, I think.
muzzleVel [number]
– How fast the bullets are fired. Note that Newton’s third law is in full effect: for every action, there is an equal and opposite reaction. Faster bullets means harder recoil.
spread [number]
– An angle in radians that’s used for spread. Keep in mind this angle is used for half of the arc, ie. an angle of 1.571 will provide a semicircle firing spread. An angle of 3.142 will produce a full circle of bullets as seen in the blast pulser for faction 8.
burstyness [number]
– A value between 0 and 1 that makes the weapon more burstful in how it fires. Hard to explain, easier to see in action.
power [number]
– How much energy it costs to fire this weapon, or each projectile, not sure yet.
damage [number]
– How much damage an individual bullet does. More damage makes the bullet larger and with more mass, which increases recoil and knockback.
color [color]
– 0xRRGGBB format. Color of the projectiles fired.
range [number]
– How far the projectile will travel before ceasing to exist.
explosive [flag]
– If defined, the bullets are explosive. You have these options for the flag:
- ENABLED – makes the projectiles explosive on contact.
- PROXIMITY – makes the projectiles explode if their explosion radius would hit a target, I think.
- FINAL – makes the projectiles explode at the end of their life.
explodeRadius [number]
– The radius of the explosion of the projectiles.
eg. cannon={roundsPerSec=7.000, roundsPerBurst=3, explosive=PROXIMITY, burstyness=0.300, muzzleVel=1000.000, power=3.000, damage=10.000, color=0xcf1090, range=400.000, explodeRadius=30.000}
CANNON_BOOST
– Cannon augment.
Related properties:
cannonBoost
– The definition for the augment. This is a weird one. Each parameter inside the cannonBoost requires a smaller table of two values. The first value is a multiplier, which multiplies the appropriate parameter of whatever cannon/part/whatever this is attached by itself. The second value is an added bonus, which is added to the parameter instead. So, for example, {1.5, 0} means “multiply parameter by 1.5 (ie. +50%), add 0” to whatever parameter. {1, 10} means “multiply parameter by 1 (ie. don’t change it), add 10”. You can in theory probably mix these but I haven’t tried to.
Properties that take this format:
power [{multiplier, added}]
– Changes how much power cost a projectile round takes to fire.
damage [{multiplier, added}]
– Changes the damage of a projectile.
muzzleVel [{multiplier, added}]
– Changes how fast a projectile is on launch.
range [{multiplier, added}]
– Changes how far a projectile will go before dying.
roundsPerSec [{multiplier, added}]
– Changes how fast the weapon fires.
eg. cannonBoost={muzzleVel={1.000, 100.000}, power={1.000, 10.000}, range={1.000, 400.000}}
LASER
– Lasers! Everyone loves instantaneous damage.
Related properties:
laser
– The definition for the laser.
Inside the table will be the following parameters:
pulsesPerSec [number]
– Amount of pulses per second. eg. pulsesPerSec=3
pulseAvailability [number]
– I don’t have any idea. It’s a number between 0 to 1. eg. pulseAvailability=0.500
burstyness [number]
– Possibly concentrates pulses in the same way burstyness works for cannon rounds. eg. burstyness=0.850
decay [number]
– Possibly controls how fast laser dies away for bursts. Not sure of units. Only existing examples have values set to 0.5 and 1.0. eg. decay=0.500
power [number]
– Not sure if this energy cost is per second or per pulse. Given that lasers can be constant, this is probably per second. eg. power=20.000
width [number]
– Width of the laser. Pretty straightforward! eg. width=6.000
damage [number]
– Damage dealt… over time? Not sure. Probably damage per second of contact. eg. damage=30.000
color [color]
– 0xAARRGGBB format. Colour of the laser! eg. color=0x7f00e0a0
range [number]
– How far the laser fires. eg. range=1500.000
explodeRadius [number]
– Radius of explosions caused by the laser hitting something. eg. explodeRadius=20.000
eg. laser={power=50.000, width=4.000, damage=2000.000, color=0x7f00b7e9, range=300.000}
LAUNCHER
– Launches a block.
Related properties:
replicateBlock [block specification]
– Oh boy. So, the way the launchers work is you specify a block they launch in here. In order to do that, I’d recommend defining the block you want to launch separately and then pasting it in here. Here’s some tips for your blocks to launch. If you want the launched block to move, don’t forget to give it a THRUSTER and TORQUER and the associated properties. If you want the block to be able to ‘think’ about where to go and what to attack, give it the COMMAND flag and a command property (command={}). If you don’t, don’t put these in. AUTOFIRE might be useful too based on what you want the launched block to target, as AUTOFIRE will target everything hostile much like . Everything else is up to you!
eg. replicateBlock={65562, command={}, features=COMMAND|THRUSTER|TORQUER|EXPLODE, group=15, blockshape=MISSILE, lifetime=4.000, durability=0.500, density=0.150, fillColor=0x505050, fillColor1=0x96bc2a, lineColor=0xdfe0e2, capacity=100.000, thrusterForce=2400.000, thrusterColor=0x9054f5c4, thrusterColor1=0x90cff5e9, torquerTorque=4000.000, explodeDamage=10.000, explodeRadius=20.000}
– This creates a homing missile that explodes after 4 seconds.
replicateTime [number]
– Amount of seconds it takes to regenerate the block launched. eg. replicateTime=0.800
launcherPower [number]
– Amount of power it takes to launch (or regenerate the block, not sure which). eg. launcherPower=50.000
launcherOutSpeed [number]
– Speed block is launched at. eg. launcherSpeed=700.000
launcherAngVel [number]
– Angular speed block is launched at, if you want things to spin wildly on launch. eg. launcherAngVel=12.000
SHIELD
– You’re probably well aware of how useful these things are.
Related properties:
shield
– The definition for the shield.
Inside the table will be the following parameters:
strength [number]
– Amount of damage soaked by the shield before collapse.
regen [number]
– How quickly the shield restores health, in health per second.
radius [number]
– The radius of the shield.
color [color]
– 0xAARRGGBB format. Colour of the shield when operational.
lineColor [color]
– 0xRRGGBB format. Colour of the shield outline.
damagedColor [color]
– 0xAARRGGBB format. Colour of the shield when collapsed or collapsing.
eg. shield={strength=1200.000, regen=250.000, radius=200.000, color=0x19332202, lineColor=0xc332202, damagedColor=0x4c8d5e06}
Command Flags
This section is probably pointless, but for the sake of completeness, here are the known flags that the command component can have. These are assigned on creation of the command module based on likely hardcoded behaviours, and I don’t know what half of them do. Enjoy!
Command flags and their (guessed) behaviours:
NONE – no idea
METAMORPHOSIS – presumably the ship can change its design
FLOCKING – presumably the ship tries to flock
RECKLESS – I dunno
CAUTIOUS – no idea
SOCIAL – prefers own kind?
DODGES – actively tries to avoid fire
AGGRESSIVE – more prone to chasing ships??
PEACEFUL – less likely to attack unless provoked??
WANDER – ship moves aimlessly around
FORGIVING – I have absolute no idea what this flag does because I have never seen ships forgive
TRACTOR_TRANSIENT – ships will pull arbitrary debris onto themselves to improve their capabilities and in practice lose all control and spin wildly around
RIPPLE_FIRE – the ship uses the ripple fire method of using its weapons
BAD_AIM – this ship apparently has no idea how to fire at a target
SMART_FIRE – probably only fires when necessary?
NO_PARENT – unsure
GROW_ON_OK – no idea
HATES_PLANTS – will attack plants
Blockshapes
0. none specified is a simple square block
1. OCTAGON (8 sided regular polygon)
2. THRUSTER (chunky thruster)
3. CANNON (standard fixed cannon block)
4. MISSILE (well, uh, it’s, uh, a missile)
5. RECT (weird block that has interesting ratios of sizes to compensate for situations of cruel and unusual geometry)
6. HEXAGON (6 sided regular polygon)
7. TRI (isoceles triangle)
8. COMMAND (the iconic not quite box, not quite octagon shape used by most command blocks)
9. SENSOR (unused block, throws assert errors, probably don’t use this)
10. WING (causes a physics crash on creation and locks up the game – don’t use!!)
11. ADAPTER (weird block that can be used to change from odd numbers of attachment points to even and vice versa)
12. CUSTOM (causes a physics crash on creation and locks up the game – don’t use!!)
13. PENTAGON (5 sided regular polygon)
14. RHOMBUS_72_108 (one of the penrose rhombus tiles, this is ‘penrose one’, it’s the thicker rhombus)
15. RHOMBUS_36_144 (one of the penrose rhombus tiles, this is ‘penrose zero’, it’s the skinnier rhombus)
16. THRUSTER_PENT (used by penrose tiling thrusters that need to fit in a more friendly manner for their unique geometry)
17. DISH_WEAPON (used by some weapon mods eg damage amplifier)
18. DISH_THRUSTER (used by most thrusters)
19. RIGHT_TRI (right angled isoceles triangle)
20. RECT_LAUNCHER (shape for ideal launching of things eg. missiles, drones, staggered off from main body, TWO LAUNCH POINTS)
21. RECT_CANNON (base cannon for the modular weapons)
22. RECT_CANNON_BOOST (used by some weapon mods eg range amplifier)
23. invalid, not recognised, causes a physics crash
24. RECT_LONG (adjustable on one dimension only)
25. ISOTRI_72 (half of a thick rhombus, end point angle is 72 degrees)
26. ISOTRI_36 (half of a thin rhombus, 36 degrees)
27. RIGHT_TRI2L (right angled scalene triangle, forms an L when shortest side is aligned with bottom edge of screen)
28. RIGHT_TRI2R (the mirrored version of the L forming scalene triangle)
29. SEED_1 (same shape as gem 1, but with special anchor point at base to connect to terrain)
30. SEED_2 (same shape as gem 2, but with special anchor point at base to connect to terrain)
31. SEED_3 (same shape as gem 3, but with special anchor point at base to connect to terrain)
32. SEED_4 (same shape as gem 4, but with special anchor point at base to connect to terrain)
33. RECT_LONG_NARROW (the same but narrower I guess)
34. RECT_LAUNCHER1 (shape for launching things, ONE LARGER LAUNCH POINT)
35. RIGHT_TRI_22_5L (as before, 22.5 degree angle)
36. RIGHT_TRI_22_5R (as before and so on and so forth)
37. DISH_MISSILE (used by faction 8 drones)
38. RECT_ROOT (a thin rectangle that connects one side of x attachment points to one side of one attachment point, used to anchor buildings)
39. GEM_1 (weird organic shape, narrow to wide with one connector at the end)
40. GEM_2 (weird organic shape, narrow to wide with two sides and connectors at the end)
41. GEM_3 (weird organic shape, narrow to wide with three sides and connectors at the end)
42. GEM_4 (weird organic shape, narrow to wide with four sides and connectors at the end)
43. ISOTRI_25 (narrow, 25 degrees)
44. ISOTRI_25_MISSILE (it’s a triangular missile!)
45. ISOTRI_13 (narrower, 13 degrees)
46. ISOTRI_13_MISSILE (doesn’t seem to be used but is a narrower missile than the 25-degree triangle missile)
47. ISOTRI_6 (really narrow, 6 degrees)
48. HEPTAGON_LAUNCHER (a flower of missiles and pain)
49. HEPTAGON (7 sided regular polygon)
50. GEM_2_LAUNCHER (end attach points are for launched blocks only)
51. GEM_3_LAUNCHER (end attach points are for launched blocks only)
52. GEM_4_LAUNCHER (end attach points are for launched blocks only)
53. RECT_QUARTER (the same as RECT_LONG but much much smaller)
54. ISOTRI_3 (the narrowest, 3 degrees, !!!NEVER EVER USE WITH BLOCK SCALE BELOW 2!!!)
55. ISOTRI_25_WEAPON (used by some weapon mods eg rate amplifier)
56. NONAGON (9 sided regular polygon)
57. ISOTRI_80 (almost but not quite a right angled triangle)
58. THRUSTER_RECT (an even chunkier thruster)
59. SQUARE_HALF (half the size of a regular block, so closer to 1/4 in volume)
60. SQUARE_LAUNCHER (the unfortunate fact is this will never be able to use all its launch points)
61. SQUARE_MISSILE (pretty much only used for faction 6 drones)
62. RIGHT_TRI_30L (sort of different with one less attachment point?? 30 degree angle)
63. RIGHT_TRI_30R (and then mirrored)
64. OCTAGON_1 (an octagon with one attachment point)
65. SQUARE_1 (a square with one attachment point)
66. CANNON2 (fixed shotgun/gauss beam block)
67. RECT_V1 (causes a physics crash on creation and locks up the game – don’t use!!)
68. MISSILE_LAUNCHER (a missile with launcher attachment points!!!)
69. MISSILE_SHORT (stubby missile, has launch attach points??)
Misc:
COMMAND
SENSOR
A note on sensor: Not sure how stable the shape is, given the number of assert errors thrown. Use at your own risk.
Thrusters:
THRUSTER
DISH_THRUSTER
THRUSTER_PENT
THRUSTER_RECT
A note on thrusters: they have a unique attachment point (thatI can tell) that only thrusters and ‘thrust’ can attach to. Non-thruster blockshapes used as thrusters have always active thrust coming from every unexposed attachment point. I would not recommend doing this!
Cannons:
CANNON
CANNON2
RECT_CANNON
Weapon augments:
DISH_WEAPON
RECT_CANNON_BOOST
ISOTRI_25_WEAPON
A note on weapon augments: they can attach to the ends of CANNON and RECT_CANNON, but not CANNON2.
Launchers:
RECT_LAUNCHER
RECT_LAUNCHER1
GEM_2_LAUNCHER
GEM_3_LAUNCHER
GEM_4_LAUNCHER
SQUARE_LAUNCHER
HEPTAGON_LAUNCHER
MISSILE_LAUNCHER
MISSILE_SHORT
Missiles:
MISSILE
MISSILE_LAUNCHER
MISSILE_SHORT
ISOTRI_25_MISSILE
ISOTRI_13_MISSILE
DISH_MISSILE
SQUARE_MISSILE
A note on missiles: they have no attachment points and can’t be tractored as transient blocks. You can see what happens when you use a block with attachment points for a projectile by seeing how faction 7 ships interact with faction 8 mines.
Rectangles:
[none]
ADAPTER
SQUARE_HALF
RECT
RECT_LONG
RECT_LONG_NARROW
RECT_QUARTER
RECT_ROOT
Rhombuses:
RHOMBUS_72_108
RHOMBUS_36_144
Triangles:
RIGHT_TRI
TRI
RIGHT_TRI2L
RIGHT_TRI2R
RIGHT_TRI_30L
RIGHT_TRI_30R
RIGHT_TRI_22_5L
RIGHT_TRI_22_5R
ISOTRI_80
ISOTRI_72
ISOTRI_36
ISOTRI_25
ISOTRI_13
ISOTRI_6
ISOTRI_3
Regular Polygons of Five or More Sides:
PENTAGON
HEXAGON
HEPTAGON
OCTAGON
NONAGON
Weird Single Attachment Point Variants:
OCTAGON_1
SQUARE_1
Gems:
GEM_1
GEM_2
GEM_3
GEM_4
Seeds:
SEED_1
SEED_2
SEED_3
SEED_4
Unstable, Never Use:
WING
CUSTOM
Blockshape 23
RECT_V1
A note on these: Seriously, don’t use them.
That’s All!
I hope this guide helps as a guide into trying to experiment with making blocks yourself!
This is sort of getting off the point of this guide, but look into the ssave and sopen commands to try saving ships made of your own faction palette, if you’ve defined one. You can also use export and import to save/load from more accessible directories than what Reassembly uses, hopefully. I’m still not sure how to entirely create new factions along with map generation and so on, but this is all I know as far as block creation goes. There’s still much I don’t know.
Have fun!