StarMade Wiki - User contributions [en]

Blueprint File Formats

2016-08-22T21:27:06Z

Olxinos: /* smd3.bt */

Below are the details of the blueprint data files. This information is intended for those who are interested in writing external tools to inspect and modify blueprints.

==Versions==
As '''StarMade''' is under active development, file formats and layouts could change with each version. As a result, the information on this page may become inaccurate over time. If you find errors in this information, please provide corrections and note the version and changes in the [[#Changelog|Changelog]] section at the bottom of this page.

==File Layout==
Blueprints are comprised of several files arranged in the blueprints directories in the StarMade installation directory. There are three such directories:
{| class="wikitable"
! Directory !! Purpose
|-
| blueprints || Player-saved blueprints (the local catalog) as well as the initial pirate ship blueprints
|-
| blueprints-default || Also contains pirate blueprints
|-
| blueprints-stations || Station blueprints, organized into directories for each of the NPC factions.
|}

Within each blueprint directory are directories for each ship or station. Within each of those directories are the following files:
{| class="wikitable"
! File Name !! Purpose
|-
| header.smbph || The [[#header|header]] file.
|-
| meta.smbpm || The [[#meta|metadata]] file.
|-
| logic.smbpl || The [[#logic|logic]] file.
|-
| DATA/ || A directory containing the *.smd2 block [[#data|chunk data]] files.
|}

==Header==

The header file describes the following basic bits of information about the blueprint:

; Entity Type : Indicates whether the blueprint is for a Ship, Shop, Space Station, Asteroid or Planet.
; Bounding Box : A pair of three-dimensional coordinates providing the minimum and maximum block coordinates for the blueprint. These are relative to a 0,0,0 base, so the minimum coordinates will be negative and the maximum coordinates will be positive. The size of the blueprint is determined by subtracting the minimum coordinates from the maximum ones in each dimension.
; Element Map: An array of structures describing the number and types of each block in the blueprint.

With the information from the header, it's possible to calculate the size and composition of the blueprint to, for example, produce a list of materials needed for construction or determine if a ship can fit in a particular space.

==Metadata==

The metadata file contains all the other information about a blueprint except for block positions. This includes things like docked turrets, contents of storage boxes on the ship, etc. It is arranged in two sections: docking and Tags.

; Docking : This section contains an array of structures describing the name of the blueprint for the docked entity, its size and position, the docking style and its docked orientation.
; Tags : This is a hierarchical data format which may contain binary information of several types, optionally named. See the file format section for additional details.

The Tags section may be compressed, requiring zlib compression functionality to work with. Each Tag contains the following information:
; Type : The type of data contained in the payload.
; Name (optional): If present this is the name of this tag
; Payload : A variable format data structure which describes one of the following values:
:* Byte (8-bit value)
:* Short (16-bit value)
:* Int (32-bit value)
:* Long (64-bit value)
:* Float (32-bit single-precision value)
:* Double (64-bit double-precision value)
:* Byte Array
:* String (UTF-encoded with a length prefix)
:* Vector3f (a vector of 3 floats)
:* Vector3i (a vector of 3 integers)
:* Vector3b (a vector of 3 bytes)
:* List (A list of Payloads which all contain the same type of data)
:* Structure (A list of Tags of varying types)
:* FactoryId (a 8-bit value used for factory registration)
:* Vector4f (A vector of 4 floats)

==Logic==

The logic file describes all of the [[Linking|linked]] module groups in the ship. It is structured as an array or arrays of block information.

; Controller Map : An array of Controller Entity structures, one for each linked master.
; Controller Entity : Contains the position of the controller (master) block and an array of Controller Group structures describing the master and slaved blocks.
; Controller Group : Contains the type of block and an array of positions of each slaved block of that type

There is a hierarchy of groups, starting with the Controller Entity with controller position 8, 8, 8 (corresponding to the [[Ship Core]]) which will contain a list of Controller Groups containing the master blocks (such as the various computers.) Within each of these groups will be the positions of those master blocks, and those positions will correspond to the Controller Entity positions of the other Entities in the Controller Map.

==Data==

Data files are contained within the DATA directory for a given blueprint. These files contain the actual block data - types, positions and orientations, organized into segments and further organized into regions. Each region will be in its own file named with the following format <blueprintname>.<regionX>.<regionY>.<regionZ>.smd2. For a blueprint called Alpha, the data file for region 0, 0, 0 would be called Alpha.0.0.0.smd2.

The region file contains the following information:
; Segment Index : A 16x16x16 array of segment indexes, pointing to Segment Data in the data array
; Segment Timestamps : A 16x16x16 array of timestamps.
; Segment Data : An array of up to 16x16x16 (4096) entries containing the data pointed to by the Segment Index. Each Segment Data contains the segment timestamp, the segment position within the region, the type of segment and a compressed array of Block Data.
; Block Data : A bit-packed structure describing the block id, orientation, hitpoints and whether the block is active.

===Block Data===
The Block Data structure consists of three bytes which contain a bit-packed representation of each block in the blueprint.

{| class=wikitable
! ||MSB !! colspan=22 | Bit Offsets !! LSB
|-
! Type !! 23 !! 22 !! 21 !! 20 !! 19 !! 18 !! 17 !! 16
! 15 !! 14 !! 13 !! 12 !! 11 !! 10 !! 9 !! 8 !! 7 !! 6 !! 5 !! 4 !! 3 !! 2 !! 1 !! 0
|-
| rowspan=2 | Type 1
| colspan=3 bgcolor=red align=center | Orientation
| bgcolor=teal align=center | Active
| colspan=9 bgcolor=blue align=center | Hit Points
| colspan=12 bgcolor=green align=center | Block ID
|-
| colspan=24 | For blocks with an activation status, like a [[Standard Factory]] or [[Activation Module]] 
|-
| rowspan=2 | Type 2
| colspan=4 bgcolor=red align=center | Orientation
| colspan=9 bgcolor=blue align=center | Hit Points
| colspan=12 bgcolor=green align=center | Block ID
|-
| colspan=24 | For all other blocks except [[Grey Standard Armor Corner|corners]] 
|-
| rowspan=2 | Type 3
| colspan=5 bgcolor=red align=center | Orientation
| colspan=8 bgcolor=blue align=center | Hit Points
| colspan=12 bgcolor=green align=center | Block ID
|-
| colspan=24 | For [[Grey Standard Armor Corner|corner]] blocks 
|}

The Orientation field represents how the block is facing in the blueprint. When all the bits in this field are zero, the block will be in its default orientation. The bits are interpeted as follows - if the bit is not part of the orientation :

{| class=wikitable padding=2
! Type !! colspan=3 | Bits !! Description
|-
| Type1 || 23 || 22 || 21 || The block facing
|-
| rowspan=2 | Type 2 || 23 || 22 || || The axis of rotation.
*00 : +Y
*01 : -Y
*10 : -Z
*11 : +Z
|-
| 21 || 20 || || The amount of clockwise rotation around the axis of rotation, in 90-degree steps
|-
| rowspan=2 | Type 3 || 19 || 23 || 22 || The axis of rotation.
*000 : +Y
*001 : -Y
*010 : -Z
*011 : +Z
*100 : -X
*101 : +X
|-
| 21 || 20 || || The amount of clockwise rotation around the axis of rotation, in 90-degree steps
|}

==Additional Resources==
In order to assist developers, the following files are provided to help understand and work with blueprint files.

===010 Editor===
The following *.bt files are format definitions for the [http://www.sweetscape.com/010editor 010 Hex Editor]. Their format is largely similar to C structures and should be easily translatable to your language of choice.

====smbph.bt====
<pre>
//--------------------------------------
//--- 010 Editor v6.0 Binary Template
//
// File: smbph.bt
// Author: Cliff Hudson
// Revision: 0.1867
// Purpose: StarMade Blueprint Header file
//--------------------------------------

struct Vector3f
{
float x;
float y;
float z;
};

enum <unsigned int> EntityType
{
Ship = 0,
Shop = 1,
SpaceStatiion = 2,
Asteroid = 3,
Planet = 4
};

typedef struct
{
Vector3f min;
Vector3f max;
} BoundingBox;

typedef struct
{
short blockId;
int blockCount;
} Element;

typedef struct
{
int numElements;
Element elements[numElements];
} ElementCountMap;

typedef struct
{
int version;
EntityType entityType;
BoundingBox boundingBox;
ElementCountMap elementCountMap;
} Header;

Header header;
</pre>

====smbpl.bt====
<pre>
//--------------------------------------
//--- 010 Editor v6.0 Binary Template
//
// File: smbpl.bt
// Author: Cliff Hudson
// Revision: 0.1867
// Purpose: StarMade Blueprint Logic file
//--------------------------------------

struct Vector3s
{
short x;
short y;
short z;
};

typedef struct
{
short blockId;
int numBlocks;
Vector3s blockPositions[numBlocks];
} ControllerGroup <optimize=false>;

typedef struct
{
Vector3s controllerPosition;
int numGroups;
ControllerGroup groups[numGroups];
} ControllerEntity <optimize=false>;

typedef struct
{
int version;
int numControllers;
ControllerEntity entities[numControllers];
} ControllerMap <optimize=false>;

ControllerMap controllerMap;
</pre>

====smbpm.bt====
<pre>
//--------------------------------------
//--- 010 Editor v6.0 Binary Template
//
// File: smbpm.bt
// Author: Cliff Hudson
// Revision: 0.1867
// Purpose: StarMade Blueprint Meta file
//--------------------------------------
enum <byte> TagType
{
Finish = 1,
SegManager = 2,
Docking = 3
};

struct TagList;
struct TagStructure;
struct Payload;

typedef struct
{
byte x;
byte y;
byte z;
} Vector3b;

typedef struct
{
int x;
int y;
int z;
} Vector3i;

typedef struct
{
float x;
float y;
float z;
} Vector3f;

typedef struct
{
float x;
float y;
float z;
float w;
} Vector4f;

typedef struct
{
short nameLen;
char name[nameLen];
Vector3i dockingPos;
Vector3f dockingSize;
short dockingStyle;
byte dockingOrientation;
} DockedEntry <optimize=false>;

typedef struct
{
int dockedCount;
DockedEntry dockedEntry[dockedCount];
} DockedBlueprints <optimize=false>;

typedef struct
{
unsigned short stringLen;
char str[stringLen];
} String <optimize=false>;

typedef struct
{
int length;
byte data[length];
} ByteArray <optimize=false>;

typedef struct (byte type)
{
switch(type)
{
case 0:
break;
case 1: // Byte
byte dataByte;
break;
case 2: // Short
short dataShort;
break;
case 3: // Int
int dataInt;
break;
case 4: //Long
int64 dataLong;
break;
case 5: // Float
float dataFloat;
break;
case 6: // Double
double dataDouble;
break;
case 7: // Byte array
ByteArray byteArray;
break;
case 8: // String
String dataString;
break;
case 9: // Float vector
Vector3f floatVector;
break;
case 10: // int vector
Vector3i intVector;
break;
case 11: // Byte vector
Vector3b byteVector;
break;
case 12: // List
TagList list;
break;
case 13: // Struct
TagStructure structure;
break;
case 14: // Factory registration
byte factoryId;
break;
case 15: // Float4 vector
Vector4f float4Vector;
break;
}
} Payload <optimize=false>;

typedef struct
{
byte type;
if(type > 0)
{
String name;
}
if(type != 0)
{
Payload payload(Abs(type));
}
} Tag <optimize=false>;

typedef struct
{
byte listType;
int listLength;
Payload payload(listType)[listLength];
} TagList <optimize=false>;

typedef struct
{
do
{
Tag tag;
}
while(tag.type != 0);
} TagStructure<optimize=false>;

typedef struct
{
short version; // Current unused. If this value is 0x1f8b, then from here
// forward - including these bytes - is a gzip compressed stream
// whose contents follow the same structure as the uncompressed
// version.
Tag tag;
} TagRoot <optimize=false>;

typedef struct
{
unsigned int version;
do
{
byte tagType;
switch(tagType)
{
case Finish:
break;

case SegManager:
TagRoot segmentManager;
return;

case Docking:
DockedBlueprints dockedBlueprints;
break;
}
} while(tagType != Finish);
} Metadata;

Metadata metadata;
</pre>

====smd2.bt====
<pre>
//--------------------------------------
//--- 010 Editor v6.0 Binary Template
//
// File: smd2.bt
// Author: Cliff Hudson
// Revision: 0.1867
// Purpose: Starmade Region Data file
//--------------------------------------

typedef struct
{
BitfieldDisablePadding();
BitfieldLeftToRight();
byte orientation : 3;
byte hitpoints: 8;
byte isActive: 1;
ushort blockId: 12;
} BlockData;

typedef struct
{
int x;
int y;
int z;
} Vector3i;

typedef struct
{
int segmentId;
int segmentSize;
} SegmentIndex;

typedef struct
{
int version;
SegmentIndex indices[16*16*16];
int64 timestamps[16*16*16];
} RegionHeader;

typedef struct
{
// NOTE: This struct will always come out to 5120 bytes total, even if the
// data field ends up being shorter (it will simply be padded out.)
// This allows the SegmentIndex to trivially find the data on disk without
// loading the entire file.
// No longer the newest format, though this format may apply to blueprints with
// an SMD file version of 0.
int64 timestamp;
Vector3i segmentPosition;
int dataLength;
unsigned byte segmentType;
byte data[5120-25]; // zlib compressed array of BlockData
} SegmentDataOld;

typedef struct
{
byte version;
// NOTE: This struct will always come out to 5120 bytes total, even if the
// data field ends up being shorter (it will simply be padded out.)
// This allows the SegmentIndex to trivially find the data on disk without
// loading the entire file.
// Valid as of 0.1867, smd file version 1 (RegionHeader.version).
int64 timestamp;
Vector3i segmentPosition;
unsigned byte dataByte; // If 1, there is valid data here
int compressedSize;
byte data[5120-26]; // zlib compressed array of BlockData
} SegmentData;

typedef struct
{
RegionHeader header;
SegmentData data[4096];
} Region;

Region region;
</pre>

====smd3.bt====
<pre>
//--------------------------------------
//--- 010 Editor v6.0 Binary Template
//
// File: smd3.bt
// Revision: 0.199.159
// Purpose: Starmade Region Data file
//--------------------------------------

typedef struct
{
BitfieldDisablePadding();
BitfieldLeftToRight();
byte orientation : 3;
byte isActive: 1;
byte hitpoints: 9;
ushort blockId: 11;
} BlockData;

typedef struct
{
int32 x;
int32 y;
int32 z;
} Vector3i;

typedef struct
{
int16 segmentId;
int16 segmentSize;
} SegmentIndex;

typedef struct
{
int32 version;
SegmentIndex indices[16*16*16];
} RegionHeader;

typedef struct
{
// NOTE: This struct will always come out to 49152 bytes total, even if the
// data field ends up being shorter (it will simply be padded out.)
// This allows the SegmentIndex to trivially find the data on disk without
// loading the entire file.
byte version;
int64 timestamp;
Vector3i segmentPosition;
unsigned byte dataByte; // If 1, there is valid data here
int compressedSize;
byte data[49152-26]; // zlib compressed array of (32x32x32) BlockData
} SegmentData;

typedef struct
{
RegionHeader header;
SegmentData data[4096];
} Region;

Region region;
</pre>

==Changelog==
Added SegmentDataOld to smd2 format, reflecting the previous format for block data for this file. It changed somewhere prior to v0.1867, but this is verified correct on 0.1867.
Initial creation for version 0.1867.

Blueprint File Formats

2016-08-22T16:27:07Z

Olxinos: /* smd3.bt */

Below are the details of the blueprint data files. This information is intended for those who are interested in writing external tools to inspect and modify blueprints.

==Versions==
As '''StarMade''' is under active development, file formats and layouts could change with each version. As a result, the information on this page may become inaccurate over time. If you find errors in this information, please provide corrections and note the version and changes in the [[#Changelog|Changelog]] section at the bottom of this page.

==File Layout==
Blueprints are comprised of several files arranged in the blueprints directories in the StarMade installation directory. There are three such directories:
{| class="wikitable"
! Directory !! Purpose
|-
| blueprints || Player-saved blueprints (the local catalog) as well as the initial pirate ship blueprints
|-
| blueprints-default || Also contains pirate blueprints
|-
| blueprints-stations || Station blueprints, organized into directories for each of the NPC factions.
|}

Within each blueprint directory are directories for each ship or station. Within each of those directories are the following files:
{| class="wikitable"
! File Name !! Purpose
|-
| header.smbph || The [[#header|header]] file.
|-
| meta.smbpm || The [[#meta|metadata]] file.
|-
| logic.smbpl || The [[#logic|logic]] file.
|-
| DATA/ || A directory containing the *.smd2 block [[#data|chunk data]] files.
|}

==Header==

The header file describes the following basic bits of information about the blueprint:

; Entity Type : Indicates whether the blueprint is for a Ship, Shop, Space Station, Asteroid or Planet.
; Bounding Box : A pair of three-dimensional coordinates providing the minimum and maximum block coordinates for the blueprint. These are relative to a 0,0,0 base, so the minimum coordinates will be negative and the maximum coordinates will be positive. The size of the blueprint is determined by subtracting the minimum coordinates from the maximum ones in each dimension.
; Element Map: An array of structures describing the number and types of each block in the blueprint.

With the information from the header, it's possible to calculate the size and composition of the blueprint to, for example, produce a list of materials needed for construction or determine if a ship can fit in a particular space.

==Metadata==

The metadata file contains all the other information about a blueprint except for block positions. This includes things like docked turrets, contents of storage boxes on the ship, etc. It is arranged in two sections: docking and Tags.

; Docking : This section contains an array of structures describing the name of the blueprint for the docked entity, its size and position, the docking style and its docked orientation.
; Tags : This is a hierarchical data format which may contain binary information of several types, optionally named. See the file format section for additional details.

The Tags section may be compressed, requiring zlib compression functionality to work with. Each Tag contains the following information:
; Type : The type of data contained in the payload.
; Name (optional): If present this is the name of this tag
; Payload : A variable format data structure which describes one of the following values:
:* Byte (8-bit value)
:* Short (16-bit value)
:* Int (32-bit value)
:* Long (64-bit value)
:* Float (32-bit single-precision value)
:* Double (64-bit double-precision value)
:* Byte Array
:* String (UTF-encoded with a length prefix)
:* Vector3f (a vector of 3 floats)
:* Vector3i (a vector of 3 integers)
:* Vector3b (a vector of 3 bytes)
:* List (A list of Payloads which all contain the same type of data)
:* Structure (A list of Tags of varying types)
:* FactoryId (a 8-bit value used for factory registration)
:* Vector4f (A vector of 4 floats)

==Logic==

The logic file describes all of the [[Linking|linked]] module groups in the ship. It is structured as an array or arrays of block information.

; Controller Map : An array of Controller Entity structures, one for each linked master.
; Controller Entity : Contains the position of the controller (master) block and an array of Controller Group structures describing the master and slaved blocks.
; Controller Group : Contains the type of block and an array of positions of each slaved block of that type

There is a hierarchy of groups, starting with the Controller Entity with controller position 8, 8, 8 (corresponding to the [[Ship Core]]) which will contain a list of Controller Groups containing the master blocks (such as the various computers.) Within each of these groups will be the positions of those master blocks, and those positions will correspond to the Controller Entity positions of the other Entities in the Controller Map.

==Data==

Data files are contained within the DATA directory for a given blueprint. These files contain the actual block data - types, positions and orientations, organized into segments and further organized into regions. Each region will be in its own file named with the following format <blueprintname>.<regionX>.<regionY>.<regionZ>.smd2. For a blueprint called Alpha, the data file for region 0, 0, 0 would be called Alpha.0.0.0.smd2.

The region file contains the following information:
; Segment Index : A 16x16x16 array of segment indexes, pointing to Segment Data in the data array
; Segment Timestamps : A 16x16x16 array of timestamps.
; Segment Data : An array of up to 16x16x16 (4096) entries containing the data pointed to by the Segment Index. Each Segment Data contains the segment timestamp, the segment position within the region, the type of segment and a compressed array of Block Data.
; Block Data : A bit-packed structure describing the block id, orientation, hitpoints and whether the block is active.

===Block Data===
The Block Data structure consists of three bytes which contain a bit-packed representation of each block in the blueprint.

{| class=wikitable
! ||MSB !! colspan=22 | Bit Offsets !! LSB
|-
! Type !! 23 !! 22 !! 21 !! 20 !! 19 !! 18 !! 17 !! 16
! 15 !! 14 !! 13 !! 12 !! 11 !! 10 !! 9 !! 8 !! 7 !! 6 !! 5 !! 4 !! 3 !! 2 !! 1 !! 0
|-
| rowspan=2 | Type 1
| colspan=3 bgcolor=red align=center | Orientation
| bgcolor=teal align=center | Active
| colspan=9 bgcolor=blue align=center | Hit Points
| colspan=12 bgcolor=green align=center | Block ID
|-
| colspan=24 | For blocks with an activation status, like a [[Standard Factory]] or [[Activation Module]] 
|-
| rowspan=2 | Type 2
| colspan=4 bgcolor=red align=center | Orientation
| colspan=9 bgcolor=blue align=center | Hit Points
| colspan=12 bgcolor=green align=center | Block ID
|-
| colspan=24 | For all other blocks except [[Grey Standard Armor Corner|corners]] 
|-
| rowspan=2 | Type 3
| colspan=5 bgcolor=red align=center | Orientation
| colspan=8 bgcolor=blue align=center | Hit Points
| colspan=12 bgcolor=green align=center | Block ID
|-
| colspan=24 | For [[Grey Standard Armor Corner|corner]] blocks 
|}

The Orientation field represents how the block is facing in the blueprint. When all the bits in this field are zero, the block will be in its default orientation. The bits are interpeted as follows - if the bit is not part of the orientation :

{| class=wikitable padding=2
! Type !! colspan=3 | Bits !! Description
|-
| Type1 || 23 || 22 || 21 || The block facing
|-
| rowspan=2 | Type 2 || 23 || 22 || || The axis of rotation.
*00 : +Y
*01 : -Y
*10 : -Z
*11 : +Z
|-
| 21 || 20 || || The amount of clockwise rotation around the axis of rotation, in 90-degree steps
|-
| rowspan=2 | Type 3 || 19 || 23 || 22 || The axis of rotation.
*000 : +Y
*001 : -Y
*010 : -Z
*011 : +Z
*100 : -X
*101 : +X
|-
| 21 || 20 || || The amount of clockwise rotation around the axis of rotation, in 90-degree steps
|}

==Additional Resources==
In order to assist developers, the following files are provided to help understand and work with blueprint files.

===010 Editor===
The following *.bt files are format definitions for the [http://www.sweetscape.com/010editor 010 Hex Editor]. Their format is largely similar to C structures and should be easily translatable to your language of choice.

====smbph.bt====
<pre>
//--------------------------------------
//--- 010 Editor v6.0 Binary Template
//
// File: smbph.bt
// Author: Cliff Hudson
// Revision: 0.1867
// Purpose: StarMade Blueprint Header file
//--------------------------------------

struct Vector3f
{
float x;
float y;
float z;
};

enum <unsigned int> EntityType
{
Ship = 0,
Shop = 1,
SpaceStatiion = 2,
Asteroid = 3,
Planet = 4
};

typedef struct
{
Vector3f min;
Vector3f max;
} BoundingBox;

typedef struct
{
short blockId;
int blockCount;
} Element;

typedef struct
{
int numElements;
Element elements[numElements];
} ElementCountMap;

typedef struct
{
int version;
EntityType entityType;
BoundingBox boundingBox;
ElementCountMap elementCountMap;
} Header;

Header header;
</pre>

====smbpl.bt====
<pre>
//--------------------------------------
//--- 010 Editor v6.0 Binary Template
//
// File: smbpl.bt
// Author: Cliff Hudson
// Revision: 0.1867
// Purpose: StarMade Blueprint Logic file
//--------------------------------------

struct Vector3s
{
short x;
short y;
short z;
};

typedef struct
{
short blockId;
int numBlocks;
Vector3s blockPositions[numBlocks];
} ControllerGroup <optimize=false>;

typedef struct
{
Vector3s controllerPosition;
int numGroups;
ControllerGroup groups[numGroups];
} ControllerEntity <optimize=false>;

typedef struct
{
int version;
int numControllers;
ControllerEntity entities[numControllers];
} ControllerMap <optimize=false>;

ControllerMap controllerMap;
</pre>

====smbpm.bt====
<pre>
//--------------------------------------
//--- 010 Editor v6.0 Binary Template
//
// File: smbpm.bt
// Author: Cliff Hudson
// Revision: 0.1867
// Purpose: StarMade Blueprint Meta file
//--------------------------------------
enum <byte> TagType
{
Finish = 1,
SegManager = 2,
Docking = 3
};

struct TagList;
struct TagStructure;
struct Payload;

typedef struct
{
byte x;
byte y;
byte z;
} Vector3b;

typedef struct
{
int x;
int y;
int z;
} Vector3i;

typedef struct
{
float x;
float y;
float z;
} Vector3f;

typedef struct
{
float x;
float y;
float z;
float w;
} Vector4f;

typedef struct
{
short nameLen;
char name[nameLen];
Vector3i dockingPos;
Vector3f dockingSize;
short dockingStyle;
byte dockingOrientation;
} DockedEntry <optimize=false>;

typedef struct
{
int dockedCount;
DockedEntry dockedEntry[dockedCount];
} DockedBlueprints <optimize=false>;

typedef struct
{
unsigned short stringLen;
char str[stringLen];
} String <optimize=false>;

typedef struct
{
int length;
byte data[length];
} ByteArray <optimize=false>;

typedef struct (byte type)
{
switch(type)
{
case 0:
break;
case 1: // Byte
byte dataByte;
break;
case 2: // Short
short dataShort;
break;
case 3: // Int
int dataInt;
break;
case 4: //Long
int64 dataLong;
break;
case 5: // Float
float dataFloat;
break;
case 6: // Double
double dataDouble;
break;
case 7: // Byte array
ByteArray byteArray;
break;
case 8: // String
String dataString;
break;
case 9: // Float vector
Vector3f floatVector;
break;
case 10: // int vector
Vector3i intVector;
break;
case 11: // Byte vector
Vector3b byteVector;
break;
case 12: // List
TagList list;
break;
case 13: // Struct
TagStructure structure;
break;
case 14: // Factory registration
byte factoryId;
break;
case 15: // Float4 vector
Vector4f float4Vector;
break;
}
} Payload <optimize=false>;

typedef struct
{
byte type;
if(type > 0)
{
String name;
}
if(type != 0)
{
Payload payload(Abs(type));
}
} Tag <optimize=false>;

typedef struct
{
byte listType;
int listLength;
Payload payload(listType)[listLength];
} TagList <optimize=false>;

typedef struct
{
do
{
Tag tag;
}
while(tag.type != 0);
} TagStructure<optimize=false>;

typedef struct
{
short version; // Current unused. If this value is 0x1f8b, then from here
// forward - including these bytes - is a gzip compressed stream
// whose contents follow the same structure as the uncompressed
// version.
Tag tag;
} TagRoot <optimize=false>;

typedef struct
{
unsigned int version;
do
{
byte tagType;
switch(tagType)
{
case Finish:
break;

case SegManager:
TagRoot segmentManager;
return;

case Docking:
DockedBlueprints dockedBlueprints;
break;
}
} while(tagType != Finish);
} Metadata;

Metadata metadata;
</pre>

====smd2.bt====
<pre>
//--------------------------------------
//--- 010 Editor v6.0 Binary Template
//
// File: smd2.bt
// Author: Cliff Hudson
// Revision: 0.1867
// Purpose: Starmade Region Data file
//--------------------------------------

typedef struct
{
BitfieldDisablePadding();
BitfieldLeftToRight();
byte orientation : 3;
byte hitpoints: 8;
byte isActive: 1;
ushort blockId: 12;
} BlockData;

typedef struct
{
int x;
int y;
int z;
} Vector3i;

typedef struct
{
int segmentId;
int segmentSize;
} SegmentIndex;

typedef struct
{
int version;
SegmentIndex indices[16*16*16];
int64 timestamps[16*16*16];
} RegionHeader;

typedef struct
{
// NOTE: This struct will always come out to 5120 bytes total, even if the
// data field ends up being shorter (it will simply be padded out.)
// This allows the SegmentIndex to trivially find the data on disk without
// loading the entire file.
// No longer the newest format, though this format may apply to blueprints with
// an SMD file version of 0.
int64 timestamp;
Vector3i segmentPosition;
int dataLength;
unsigned byte segmentType;
byte data[5120-25]; // zlib compressed array of BlockData
} SegmentDataOld;

typedef struct
{
byte version;
// NOTE: This struct will always come out to 5120 bytes total, even if the
// data field ends up being shorter (it will simply be padded out.)
// This allows the SegmentIndex to trivially find the data on disk without
// loading the entire file.
// Valid as of 0.1867, smd file version 1 (RegionHeader.version).
int64 timestamp;
Vector3i segmentPosition;
unsigned byte dataByte; // If 1, there is valid data here
int compressedSize;
byte data[5120-26]; // zlib compressed array of BlockData
} SegmentData;

typedef struct
{
RegionHeader header;
SegmentData data[4096];
} Region;

Region region;
</pre>

====smd3.bt====
<pre>
//--------------------------------------
//--- 010 Editor v6.0 Binary Template
//
// File: smd3.bt
// Revision: 0.199.159
// Purpose: Starmade Region Data file
//--------------------------------------

typedef struct
{
BitfieldDisablePadding();
BitfieldLeftToRight();
byte orientation : 3;
byte isActive: 1;
byte hitpoints: 9;
ushort blockId: 11;
} BlockData;

typedef struct
{
int32 x;
int32 y;
int32 z;
} Vector3i;

typedef struct
{
int16 segmentId;
int16 segmentSize;
} SegmentIndex;

typedef struct
{
int32 version;
SegmentIndex indices[16*16*16];
} RegionHeader;

typedef struct
{
// NOTE: This struct will always come out to 49152 bytes total, even if the
// data field ends up being shorter (it will simply be padded out.)
// This allows the SegmentIndex to trivially find the data on disk without
// loading the entire file.
// Valid as of 0.199.159, smd file version 1 (RegionHeader.version).
byte version;
int64 timestamp;
Vector3i segmentPosition;
unsigned byte dataByte; // If 1, there is valid data here
int compressedSize;
byte data[49152-26]; // zlib compressed array of (32x32x32) BlockData
} SegmentData;

typedef struct
{
RegionHeader header;
SegmentData data[4096];
} Region;

Region region;
</pre>

==Changelog==
Added SegmentDataOld to smd2 format, reflecting the previous format for block data for this file. It changed somewhere prior to v0.1867, but this is verified correct on 0.1867.
Initial creation for version 0.1867.

Blueprint File Formats

2016-08-22T16:23:01Z

Olxinos: added smd3 file format

Below are the details of the blueprint data files. This information is intended for those who are interested in writing external tools to inspect and modify blueprints.

==Versions==
As '''StarMade''' is under active development, file formats and layouts could change with each version. As a result, the information on this page may become inaccurate over time. If you find errors in this information, please provide corrections and note the version and changes in the [[#Changelog|Changelog]] section at the bottom of this page.

==File Layout==
Blueprints are comprised of several files arranged in the blueprints directories in the StarMade installation directory. There are three such directories:
{| class="wikitable"
! Directory !! Purpose
|-
| blueprints || Player-saved blueprints (the local catalog) as well as the initial pirate ship blueprints
|-
| blueprints-default || Also contains pirate blueprints
|-
| blueprints-stations || Station blueprints, organized into directories for each of the NPC factions.
|}

Within each blueprint directory are directories for each ship or station. Within each of those directories are the following files:
{| class="wikitable"
! File Name !! Purpose
|-
| header.smbph || The [[#header|header]] file.
|-
| meta.smbpm || The [[#meta|metadata]] file.
|-
| logic.smbpl || The [[#logic|logic]] file.
|-
| DATA/ || A directory containing the *.smd2 block [[#data|chunk data]] files.
|}

==Header==

The header file describes the following basic bits of information about the blueprint:

; Entity Type : Indicates whether the blueprint is for a Ship, Shop, Space Station, Asteroid or Planet.
; Bounding Box : A pair of three-dimensional coordinates providing the minimum and maximum block coordinates for the blueprint. These are relative to a 0,0,0 base, so the minimum coordinates will be negative and the maximum coordinates will be positive. The size of the blueprint is determined by subtracting the minimum coordinates from the maximum ones in each dimension.
; Element Map: An array of structures describing the number and types of each block in the blueprint.

With the information from the header, it's possible to calculate the size and composition of the blueprint to, for example, produce a list of materials needed for construction or determine if a ship can fit in a particular space.

==Metadata==

The metadata file contains all the other information about a blueprint except for block positions. This includes things like docked turrets, contents of storage boxes on the ship, etc. It is arranged in two sections: docking and Tags.

; Docking : This section contains an array of structures describing the name of the blueprint for the docked entity, its size and position, the docking style and its docked orientation.
; Tags : This is a hierarchical data format which may contain binary information of several types, optionally named. See the file format section for additional details.

The Tags section may be compressed, requiring zlib compression functionality to work with. Each Tag contains the following information:
; Type : The type of data contained in the payload.
; Name (optional): If present this is the name of this tag
; Payload : A variable format data structure which describes one of the following values:
:* Byte (8-bit value)
:* Short (16-bit value)
:* Int (32-bit value)
:* Long (64-bit value)
:* Float (32-bit single-precision value)
:* Double (64-bit double-precision value)
:* Byte Array
:* String (UTF-encoded with a length prefix)
:* Vector3f (a vector of 3 floats)
:* Vector3i (a vector of 3 integers)
:* Vector3b (a vector of 3 bytes)
:* List (A list of Payloads which all contain the same type of data)
:* Structure (A list of Tags of varying types)
:* FactoryId (a 8-bit value used for factory registration)
:* Vector4f (A vector of 4 floats)

==Logic==

The logic file describes all of the [[Linking|linked]] module groups in the ship. It is structured as an array or arrays of block information.

; Controller Map : An array of Controller Entity structures, one for each linked master.
; Controller Entity : Contains the position of the controller (master) block and an array of Controller Group structures describing the master and slaved blocks.
; Controller Group : Contains the type of block and an array of positions of each slaved block of that type

There is a hierarchy of groups, starting with the Controller Entity with controller position 8, 8, 8 (corresponding to the [[Ship Core]]) which will contain a list of Controller Groups containing the master blocks (such as the various computers.) Within each of these groups will be the positions of those master blocks, and those positions will correspond to the Controller Entity positions of the other Entities in the Controller Map.

==Data==

Data files are contained within the DATA directory for a given blueprint. These files contain the actual block data - types, positions and orientations, organized into segments and further organized into regions. Each region will be in its own file named with the following format <blueprintname>.<regionX>.<regionY>.<regionZ>.smd2. For a blueprint called Alpha, the data file for region 0, 0, 0 would be called Alpha.0.0.0.smd2.

The region file contains the following information:
; Segment Index : A 16x16x16 array of segment indexes, pointing to Segment Data in the data array
; Segment Timestamps : A 16x16x16 array of timestamps.
; Segment Data : An array of up to 16x16x16 (4096) entries containing the data pointed to by the Segment Index. Each Segment Data contains the segment timestamp, the segment position within the region, the type of segment and a compressed array of Block Data.
; Block Data : A bit-packed structure describing the block id, orientation, hitpoints and whether the block is active.

===Block Data===
The Block Data structure consists of three bytes which contain a bit-packed representation of each block in the blueprint.

{| class=wikitable
! ||MSB !! colspan=22 | Bit Offsets !! LSB
|-
! Type !! 23 !! 22 !! 21 !! 20 !! 19 !! 18 !! 17 !! 16
! 15 !! 14 !! 13 !! 12 !! 11 !! 10 !! 9 !! 8 !! 7 !! 6 !! 5 !! 4 !! 3 !! 2 !! 1 !! 0
|-
| rowspan=2 | Type 1
| colspan=3 bgcolor=red align=center | Orientation
| bgcolor=teal align=center | Active
| colspan=9 bgcolor=blue align=center | Hit Points
| colspan=12 bgcolor=green align=center | Block ID
|-
| colspan=24 | For blocks with an activation status, like a [[Standard Factory]] or [[Activation Module]] 
|-
| rowspan=2 | Type 2
| colspan=4 bgcolor=red align=center | Orientation
| colspan=9 bgcolor=blue align=center | Hit Points
| colspan=12 bgcolor=green align=center | Block ID
|-
| colspan=24 | For all other blocks except [[Grey Standard Armor Corner|corners]] 
|-
| rowspan=2 | Type 3
| colspan=5 bgcolor=red align=center | Orientation
| colspan=8 bgcolor=blue align=center | Hit Points
| colspan=12 bgcolor=green align=center | Block ID
|-
| colspan=24 | For [[Grey Standard Armor Corner|corner]] blocks 
|}

The Orientation field represents how the block is facing in the blueprint. When all the bits in this field are zero, the block will be in its default orientation. The bits are interpeted as follows - if the bit is not part of the orientation :

{| class=wikitable padding=2
! Type !! colspan=3 | Bits !! Description
|-
| Type1 || 23 || 22 || 21 || The block facing
|-
| rowspan=2 | Type 2 || 23 || 22 || || The axis of rotation.
*00 : +Y
*01 : -Y
*10 : -Z
*11 : +Z
|-
| 21 || 20 || || The amount of clockwise rotation around the axis of rotation, in 90-degree steps
|-
| rowspan=2 | Type 3 || 19 || 23 || 22 || The axis of rotation.
*000 : +Y
*001 : -Y
*010 : -Z
*011 : +Z
*100 : -X
*101 : +X
|-
| 21 || 20 || || The amount of clockwise rotation around the axis of rotation, in 90-degree steps
|}

==Additional Resources==
In order to assist developers, the following files are provided to help understand and work with blueprint files.

===010 Editor===
The following *.bt files are format definitions for the [http://www.sweetscape.com/010editor 010 Hex Editor]. Their format is largely similar to C structures and should be easily translatable to your language of choice.

====smbph.bt====
<pre>
//--------------------------------------
//--- 010 Editor v6.0 Binary Template
//
// File: smbph.bt
// Author: Cliff Hudson
// Revision: 0.1867
// Purpose: StarMade Blueprint Header file
//--------------------------------------

struct Vector3f
{
float x;
float y;
float z;
};

enum <unsigned int> EntityType
{
Ship = 0,
Shop = 1,
SpaceStatiion = 2,
Asteroid = 3,
Planet = 4
};

typedef struct
{
Vector3f min;
Vector3f max;
} BoundingBox;

typedef struct
{
short blockId;
int blockCount;
} Element;

typedef struct
{
int numElements;
Element elements[numElements];
} ElementCountMap;

typedef struct
{
int version;
EntityType entityType;
BoundingBox boundingBox;
ElementCountMap elementCountMap;
} Header;

Header header;
</pre>

====smbpl.bt====
<pre>
//--------------------------------------
//--- 010 Editor v6.0 Binary Template
//
// File: smbpl.bt
// Author: Cliff Hudson
// Revision: 0.1867
// Purpose: StarMade Blueprint Logic file
//--------------------------------------

struct Vector3s
{
short x;
short y;
short z;
};

typedef struct
{
short blockId;
int numBlocks;
Vector3s blockPositions[numBlocks];
} ControllerGroup <optimize=false>;

typedef struct
{
Vector3s controllerPosition;
int numGroups;
ControllerGroup groups[numGroups];
} ControllerEntity <optimize=false>;

typedef struct
{
int version;
int numControllers;
ControllerEntity entities[numControllers];
} ControllerMap <optimize=false>;

ControllerMap controllerMap;
</pre>

====smbpm.bt====
<pre>
//--------------------------------------
//--- 010 Editor v6.0 Binary Template
//
// File: smbpm.bt
// Author: Cliff Hudson
// Revision: 0.1867
// Purpose: StarMade Blueprint Meta file
//--------------------------------------
enum <byte> TagType
{
Finish = 1,
SegManager = 2,
Docking = 3
};

struct TagList;
struct TagStructure;
struct Payload;

typedef struct
{
byte x;
byte y;
byte z;
} Vector3b;

typedef struct
{
int x;
int y;
int z;
} Vector3i;

typedef struct
{
float x;
float y;
float z;
} Vector3f;

typedef struct
{
float x;
float y;
float z;
float w;
} Vector4f;

typedef struct
{
short nameLen;
char name[nameLen];
Vector3i dockingPos;
Vector3f dockingSize;
short dockingStyle;
byte dockingOrientation;
} DockedEntry <optimize=false>;

typedef struct
{
int dockedCount;
DockedEntry dockedEntry[dockedCount];
} DockedBlueprints <optimize=false>;

typedef struct
{
unsigned short stringLen;
char str[stringLen];
} String <optimize=false>;

typedef struct
{
int length;
byte data[length];
} ByteArray <optimize=false>;

typedef struct (byte type)
{
switch(type)
{
case 0:
break;
case 1: // Byte
byte dataByte;
break;
case 2: // Short
short dataShort;
break;
case 3: // Int
int dataInt;
break;
case 4: //Long
int64 dataLong;
break;
case 5: // Float
float dataFloat;
break;
case 6: // Double
double dataDouble;
break;
case 7: // Byte array
ByteArray byteArray;
break;
case 8: // String
String dataString;
break;
case 9: // Float vector
Vector3f floatVector;
break;
case 10: // int vector
Vector3i intVector;
break;
case 11: // Byte vector
Vector3b byteVector;
break;
case 12: // List
TagList list;
break;
case 13: // Struct
TagStructure structure;
break;
case 14: // Factory registration
byte factoryId;
break;
case 15: // Float4 vector
Vector4f float4Vector;
break;
}
} Payload <optimize=false>;

typedef struct
{
byte type;
if(type > 0)
{
String name;
}
if(type != 0)
{
Payload payload(Abs(type));
}
} Tag <optimize=false>;

typedef struct
{
byte listType;
int listLength;
Payload payload(listType)[listLength];
} TagList <optimize=false>;

typedef struct
{
do
{
Tag tag;
}
while(tag.type != 0);
} TagStructure<optimize=false>;

typedef struct
{
short version; // Current unused. If this value is 0x1f8b, then from here
// forward - including these bytes - is a gzip compressed stream
// whose contents follow the same structure as the uncompressed
// version.
Tag tag;
} TagRoot <optimize=false>;

typedef struct
{
unsigned int version;
do
{
byte tagType;
switch(tagType)
{
case Finish:
break;

case SegManager:
TagRoot segmentManager;
return;

case Docking:
DockedBlueprints dockedBlueprints;
break;
}
} while(tagType != Finish);
} Metadata;

Metadata metadata;
</pre>

====smd2.bt====
<pre>
//--------------------------------------
//--- 010 Editor v6.0 Binary Template
//
// File: smd2.bt
// Author: Cliff Hudson
// Revision: 0.1867
// Purpose: Starmade Region Data file
//--------------------------------------

typedef struct
{
BitfieldDisablePadding();
BitfieldLeftToRight();
byte orientation : 3;
byte hitpoints: 8;
byte isActive: 1;
ushort blockId: 12;
} BlockData;

typedef struct
{
int x;
int y;
int z;
} Vector3i;

typedef struct
{
int segmentId;
int segmentSize;
} SegmentIndex;

typedef struct
{
int version;
SegmentIndex indices[16*16*16];
int64 timestamps[16*16*16];
} RegionHeader;

typedef struct
{
// NOTE: This struct will always come out to 5120 bytes total, even if the
// data field ends up being shorter (it will simply be padded out.)
// This allows the SegmentIndex to trivially find the data on disk without
// loading the entire file.
// No longer the newest format, though this format may apply to blueprints with
// an SMD file version of 0.
int64 timestamp;
Vector3i segmentPosition;
int dataLength;
unsigned byte segmentType;
byte data[5120-25]; // zlib compressed array of BlockData
} SegmentDataOld;

typedef struct
{
byte version;
// NOTE: This struct will always come out to 5120 bytes total, even if the
// data field ends up being shorter (it will simply be padded out.)
// This allows the SegmentIndex to trivially find the data on disk without
// loading the entire file.
// Valid as of 0.1867, smd file version 1 (RegionHeader.version).
int64 timestamp;
Vector3i segmentPosition;
unsigned byte dataByte; // If 1, there is valid data here
int compressedSize;
byte data[5120-26]; // zlib compressed array of BlockData
} SegmentData;

typedef struct
{
RegionHeader header;
SegmentData data[4096];
} Region;

Region region;
</pre>

====smd3.bt====
<pre>
//--------------------------------------
//--- 010 Editor v6.0 Binary Template
//
// File: smd3.bt
// Revision: 0.199.159
// Purpose: Starmade Region Data file
//--------------------------------------

typedef struct
{
BitfieldDisablePadding();
BitfieldLeftToRight();
byte orientation : 3;
byte isActive: 1;
byte hitpoints: 9;
ushort blockId: 11;
} BlockData;

typedef struct
{
int32 x;
int32 y;
int32 z;
} Vector3i;

typedef struct
{
int16 segmentId;
int16 segmentSize;
} SegmentIndex;

typedef struct
{
int32 version;
SegmentIndex indices[16*16*16];
} RegionHeader;

typedef struct
{
// NOTE: This struct will always come out to 49152 bytes total, even if the
// data field ends up being shorter (it will simply be padded out.)
// This allows the SegmentIndex to trivially find the data on disk without
// loading the entire file.
// Valid as of 0.199.159, smd file version 1 (RegionHeader.version).
byte version;
int64 timestamp;
Vector3i segmentPosition;
unsigned byte dataByte; // If 1, there is valid data here
int compressedSize;
byte data[49152-26]; // zlib compressed array of BlockData
} SegmentData;

typedef struct
{
RegionHeader header;
SegmentData data[4096];
} Region;

Region region;
</pre>

==Changelog==
Added SegmentDataOld to smd2 format, reflecting the previous format for block data for this file. It changed somewhere prior to v0.1867, but this is verified correct on 0.1867.
Initial creation for version 0.1867.

Thruster Module

2016-08-18T10:20:17Z

Olxinos: corrected thrust formula

{{Stub}}
{{infobox block/Thruster_Module}}
'''Thruster Modules''' are the primary propulsion method in the game. They are designed to allow ships to move both within and between sectors. For faster modes of travel players will need to use a [[Jump Drive Computer|jump drive]].

==Item Description==
"The Thruster Module is capable of providing propulsion for ships of all shapes and sizes. Their main fuel source is power, taken from the ships Power Capacitors."

{{production/Thruster_Module}}

[[Category:Ship]] [[Category:Element]]

==Usage==
{|class="wikitable" style="float:right; margin-left: 10px;"
!colspan="2"|LEGEND
|-
|colspan="2"|'''N'''= Number of Thruster Modules on a ship
|-
|colspan="2"|'''P'''= Power consumed per second (when Thruster Modules are active)
|-
|colspan="2"|'''T'''= Thrust generated
|-
!width="200px"|<big>Power Formula</big> || width="200px"|<big>Thrust Formula</big>
|-
|height="50px" width="100px" style="text-align:center;" |P = N / 0.03 || height="50px" width="100px" style="text-align:center;" |T = 0.75 * (N * 5.50)0.87
|+ style="caption-side:bottom;| Any decimal answers produced by these formulas should be rounded to 1 decimal place.
|}
{{main|Propulsion Systems}}
'''Thruster Modules''' do not require linking in order to operate, they simply need to be placed on a ship. They require power to operate, and generate a certain amount of thrust based on the number of them attached to a ship. They do not have any grouping mechanics; two physically separate Thruster Modules will have the same effect as two which are adjacent to each other. The exact values for thrust generation and power consumption can be calculated by the formulas shown below.

A large ship will require a greater number of Thruster Modules to achieve the same acceleration as a lighter ship with a smaller quantity of Thruster Modules fitted. This is because the acceleration of a ship is determined by its thrust:mass ratio, and also because the thrust generated by each consecutive Thruster Module added to a ship suffers from diminishing returns - each module added will increase thrust by slightly less than the one before it, meaning that smaller ships have a decided advantage in reaching higher thrust:mass ratios, and therefore higher levels of acceleration.

If you were to press the {{K|activate module}} key on a Thruster Module you will bring up the [[Thrust Management Menu]]. This menu grants you more advanced options such as direct control of the acceleration of your ship based on the thrust direction. This menu also allows you to activate/deactivate things such as the Inertia Dampeners which allow your ships to automatically stop when you are not pressing any of the movement keys ({{k|forwards}}{{k|strafe left}}{{k|backwards}}{{k|strafe right}}).

ID list

2016-08-12T11:08:08Z

Olxinos: Rammet charged circuit ID was incorrect (581 instead of 582)

{{WIP}}

This is a list with the IDs needed for the /giveid [[Commands | command]].

The IDs 698-817, 833-865, 890-901, 924-935, 942-974 are used for [[Slabs | slabs]], using them for the command gives you a not placeable slab.

==Systems==
{|class="wikitable"
!width="40"| ID
!colspan="2"|Name
|-
! 1
| [[Ship Core]] || [[File:Ship_Core.png | 50px]]
|-
! 2
| [[Power Reactor Module]] || [[File:Power_Reactor_Module.png | 50px]]
|-
! 331
| [[Power Capacitor]] || [[File:Power_Capacitor.png | 50px]]
|-
! 3
| [[Shield Capacitor]] || [[File:Shield_Capacitor.png | 50px]]
|-
! 478
| [[Shield-Recharger]] || [[File:Shield-Recharger.png | 50px]]
|-
! 8
| [[Thruster Module]] || [[File:Thruster_Module.png | 50px]]
|-
! 544
| [[Jump Drive Computer]] || [[File:Jump_Drive_Computer.png | 50px]]
|-
! 545
| [[Jump Drive Module]] || [[File:Jump_Drive_Module.png | 50px]]
|-
! 681
| [[Jump Inhibitor Computer]] || [[File:Jump_Inhibitor_Computer.png | 50px]]
|-
! 682
| [[Jump Inhibitor Module]] || [[File:Jump_Inhibitor_Module.png | 50px]]
|-
! 687
| [[Transporter Controller]] || [[File:Transporter_Controller.png | 50px]]
|-
! 688
| [[Transporter Module]] || [[File:Transporter_Module.png | 50px]]
|-
! 654
| [[Scanner Computer]] || [[File:Scanner_Computer.png | 50px]]
|-
! 655
| [[Scanner Antenna]] || [[File:Scanner_Antenna.png | 50px]]
|-
! 56
| [[Gravity Unit]] || [[File:Gravity_Unit.png | 50px]]
|-
! 120
| [[Storage]] || [[File:Storage.png | 50px]]
|-
! 689
| [[Cargo Space]] || [[File:Cargo_Space.png | 50px]]
|-
! 123
| [[Build Block]] || [[File:Build_Block.png | 50px]]
|-
! 22
| [[Cloaker]] || [[File:Cloaker.png | 50px]]
|-
! 15
| [[RadarJammer]] || [[File:RadarJammer.png | 50px]]
|-
! 47
| [[Camera]] || [[File:Camera.png | 50px]]
|-
! 121
| [[BOBBY AI Module]] || [[File:BOBBY_AI_Module.png | 50px]]
|}

==Armor==
===Basic Hull===
{|class="wikitable"
!colspan="2"| ID
!colspan="2"|Block
! ID
!colspan="2"|Wedge
! ID
!colspan="2"|Corner
! ID
!colspan="2"|Tetra
! ID
!colspan="2"|Hepta
|-
|style="width: 25px; background-color:lightgrey;"|
! width="40px"|598
| [[Grey Hull]] || [[File:Grey Hull.png| 50px]]
! width="40px"|599
| [[Grey Hull Wedge]] || [[File:Grey Hull Wedge.png| 50px]]
! width="40px"|600
| [[Grey Hull Corner]] || [[File:Grey Hull Corner.png| 50px]]
! width="40px"|602
| [[Grey Hull Tetra]] || [[File:Grey Hull Tetra.png| 50px]]
! width="40px"|601
| [[Grey Hull Hepta]] || [[File:Grey Hull Hepta.png| 50px]]
|-
|style="width: 25px; background-color:black;"|
! width="40px"|603
| [[Black Hull]] || [[File:Black Hull.png| 50px]]
! width="40px"|604
| [[Black Hull Wedge]] || [[File:Black Hull Wedge.png| 50px]]
! width="40px"|605
| [[Black Hull Corner]] || [[File:Black Hull Corner.png| 50px]]
! width="40px"| 607
| [[Black Hull Tetra]] || [[File:Black Hull Tetra.png| 50px]]
! width="40px"| 606
| [[Black Hull Hepta]] || [[File:Black Hull Hepta.png| 50px]]
|-
|style="width: 25px; background-color:white;"|
! width="40px"| 608
| [[White Hull]] || [[File:White Hull.png|50px]]
! width="40px"| 609
| [[White Hull Wedge]] || [[File:White Hull Wedge.png|50px]]
! width="40px"| 610
| [[White Hull Corner]] || [[File:White Hull Corner.png|50px]]
! width="40px"| 612
| [[White Hull Tetra]] || [[File:White Hull Tetra.png|50px]]
! width="40px"| 611
| [[White Hull Hepta]] || [[File:White Hull Hepta.png|50px]]
|-
|style="width: 25px; background-color:purple;"|
! width="40px"| 613
| [[Purple Hull]] || [[File:Purple Hull.png| 50px]]
! width="40px"| 614
| [[Purple Hull Wedge]] || [[File:Purple Hull Wedge.png| 50px]]
! width="40px"| 615
| [[Purple Hull Corner]] || [[File:Purple Hull Corner.png| 50px]]
! width="40px"| 617
| [[Purple Hull Tetra]] || [[File:Purple Hull Tetra.png| 50px]]
! width="40px"| 616
| [[Purple Hull Hepta]] || [[File:Purple Hull Hepta.png| 50px]]
|-
|style="width: 25px; background-color:blue;"|
! 618
| [[Blue Hull]] || [[File:Blue Hull.png| 50px]]
! 619
| [[Blue Hull Wedge]] || [[File:Blue Hull Wedge.png| 50px]]
! 620
| [[Blue Hull Corner]] || [[File:Blue Hull Corner.png| 50px]]
! 622
| [[Blue Hull Tetra]] || [[File:Blue Hull Tetra.png| 50px]]
! 621
| [[Blue Hull Hepta]] || [[File:Blue Hull Hepta.png| 50px]]
|-
|style="width: 25px; background-color:green;"|
! 623
| [[Green Hull]] || [[File:Green Hull.png| 50px]]
! 624
| [[Green Hull Wedge]] || [[File:Green Hull Wedge.png| 50px]]
! 625
| [[Green Hull Corner]] || [[File:Green Hull Corner.png| 50px]]
! 627
| [[Green Hull Tetra]] || [[File:Green Hull Tetra.png| 50px]]
! 626
| [[Green Hull Hepta]] || [[File:Green Hull Hepta.png| 50px]]
|-
|style="width: 25px; background-color:yellow;"|
! 628
| [[Yellow Hull]] || [[File:Yellow Hull.png| 50px]]
! 629
| [[Yellow Hull Wedge]] || [[File:Yellow Hull Wedge.png| 50px]]
! 630
| [[Yellow Hull Corner]] || [[File:Yellow Hull Corner.png| 50px]]
! 632
| [[Yellow Hull Tetra]] || [[File:Yellow Hull Tetra.png| 50px]]
! 631
| [[Yellow Hull Hepta]] || [[File:Yellow Hull Hepta.png| 50px]]
|-
|style="width: 25px; background-color:orange;"|
! 633
| [[Orange Hull]] || [[File:Orange Hull.png| 50px]]
! 634
| [[Orange Hull Wedge]] || [[File:Orange Hull Wedge.png| 50px]]
! 635
| [[Orange Hull Corner]] || [[File:Orange Hull Corner.png| 50px]]
! 637
| [[Orange Hull Tetra]] || [[File:Orange Hull Tetra.png| 50px]]
! 636
| [[Orange Hull Hepta]] || [[File:Orange Hull Hepta.png| 50px]]
|-
|style="width: 25px; background-color:red;"|
! 638
| [[Red Hull]] || [[File:Red Hull.png| 50px]]
! 639
| [[Red Hull Wedge]] || [[File:Red Hull Wedge.png| 50px]]
! 640
| [[Red Hull Corner]] || [[File:Red Hull Corner.png| 50px]]
! 642
| [[Red Hull Tetra]] || [[File:Red Hull Tetra.png| 50px]]
! 641
| [[Red Hull Hepta]] || [[File:Red Hull Hepta.png| 50px]]
|-
|style="width: 25px; background-color:chocolate;"|
! 643
| [[Brown Hull]] || [[File:Brown Hull.png| 50px]]
! 644
| [[Brown Hull Wedge]] || [[File:Brown Hull Wedge.png| 50px]]
! 645
| [[Brown Hull Corner]] || [[File:Brown Hull Corner.png| 50px]]
! 647
| [[Brown Hull Tetra]] || [[File:Brown Hull Tetra.png| 50px]]
! 646
| [[Brown Hull Hepta]] || [[File:Brown Hull Hepta.png| 50px]]
|-
|style="width: 25px; background-color:dimgrey;"|
! 828
| [[Dark Grey Hull]] || [[File:Dark Grey Hull.png| 50px]]
! 829
| [[Dark Grey Hull Wedge]] || [[File:Dark Grey Hull Wedge.png| 50px]]
! 830
| [[Dark Grey Hull Corner]] || [[File:Dark Grey Hull Corner.png| 50px]]
! 832
| [[Dark Grey Hull Tetra]] || [[File:Dark Grey Hull Tetra.png| 50px]]
! 831
| [[Dark Grey Hull Hepta]] || [[File:Dark Grey Hull Hepta.png| 50px]]
|-
|style="width: 25px; background-color:teal;"|
! 878
| [[Teal Hull]] || [[File:Teal Hull.png| 50px]]
! 879
| [[Teal Hull Wedge]] || [[File:Teal Hull Wedge.png| 50px]]
! 880
| [[Teal Hull Corner]] || [[File:Teal Hull Corner.png| 50px]]
! 882
| [[Teal Hull Tetra]] || [[File:Teal Hull Tetra.png| 50px]]
! 881
| [[Teal Hull Hepta]] || [[File:Teal Hull Hepta.png| 50px]]
|-
|style="width: 25px; background-color:hotpink;"|
! 912
| [[Pink Hull]] || [[File:Pink Hull.png| 50px]]
! 913
| [[Pink Hull Wedge]] || [[File:Pink Hull Wedge.png| 50px]]
! 914
| [[Pink Hull Corner]] || [[File:Pink Hull Corner.png| 50px]]
! 916
| [[Pink Hull Tetra]] || [[File:Pink Hull Tetra.png| 50px]]
! 915
| [[Pink Hull Hepta]] || [[File:Pink Hull Hepta.png| 50px]]
|-
|style="width: 25px"|
! 63
| [[Glass]] || [[File:Glass.png| 50px]]
! 329
| [[Glass Wedge]] || [[File:Glass Wedge.png| 50px]]
! 330
| [[Glass Corner]] || [[File:Glass Corner.png| 50px]]
! 368
| [[Glass Tetra]] || [[File:Glass Tetra.png| 50px]]
! 367
| [[Glass Hepta]] || [[File:Glass Hepta.png| 50px]]
|}

===Standard Armor===
{|class="wikitable"
!colspan="3"| ID
!colspan="2"|Block
! ID
!colspan="2"|Wedge
! ID
!colspan="2"|Corner
! ID
!colspan="2"|Tetra
! ID
!colspan="2"|Hepta
|-
|colspan="2" style="width: 25px; background-color:lightgrey"|
!width="40px"| 5
| [[Grey Standard Armor]] || [[File:Grey Standard Armor.png|50px]]
!width="40px"| 293
| [[Grey Standard Armor Wedge]] || [[File:Grey Standard Armor Wedge.png|50px]]
!width="40px"| 302
| [[Grey Standard Armor Corner]] || [[File:Grey Standard Armor Corner.png|50px]]
!width="40px"| 348
| [[Grey Standard Armor Tetra]] || [[File:Grey Standard Armor Tetra.png|50px]]
!width="40px"| 357
| [[Grey Standard Armor Hepta]] || [[File:Grey Standard Armor Hepta.png|50px]]
|-
|colspan="2" style="width: 25px; background-color:purple;"|
! 69
| [[Purple Standard Armor]] || [[File:Purple Standard Armor.png|50px]]
! 294
| [[Purple Standard Armor Wedge]] || [[File:Purple Standard Armor Wedge.png|50px]]
! 303
| [[Purple Standard Armor Corner]] || [[File:Purple Standard Armor Corner.png|50px]]
! 395
| [[Purple Standard Armor Tetra]] || [[File:Purple Standard Armor Tetra.png|50px]]
! 387
| [[Purple Standard Armor Hepta]] || [[File:Purple Standard Armor Hepta.png|50px]]
|-
|colspan="2" style="width: 25px; background-color:chocolate;"|
! 70
| [[Brown Standard Armor]] || [[File:Brown Standard Armor.png|50px]]
! 295
| [[Brown Standard Armor Wedge]] || [[File:Brown Standard Armor Wedge.png|50px]]
! 304
| [[Brown Standard Armor Corner]] || [[File:Brown Standard Armor Corner.png|50px]]
! 404
| [[Brown Standard Armor Tetra]] || [[File:Brown Standard Armor Tetra.png|50px]]
! 403
| [[Brown Standard Armor Hepta]] || [[File:Brown Standard Armor Hepta.png|50px]]
|-
|colspan="2" style="width: 25px; background-color:black;"|
! 75
| [[Black Standard Armor]] || [[File:Black Standard Armor.png|50px]]
! 296
| [[Black Standard Armor Wedge]] || [[File:Black Standard Armor Wedge.png|50px]]
! 305
| [[Black Standard Armor Corner]] || [[File:Black Standard Armor Corner.png|50px]]
! 393
| [[Black Standard Armor Tetra]] || [[File:Black Standard Armor Tetra.png|50px]]
! 385
| [[Black Standard Armor Hepta]] || [[File:Black Standard Armor Hepta.png|50px]]
|-
|colspan="2" style="width: 25px; background-color:red;"|
! 76
| [[Red Standard Armor]] || [[File:Red Standard Armor.png|50px]]
! 297
| [[Red Standard Armor Wedge]] || [[File:Red Standard Armor Wedge.png|50px]]
! 306
| [[Red Standard Armor Corner]] || [[File:Red Standard Armor Corner.png|50px]]
! 394
| [[Red Standard Armor Tetra]] || [[File:Red Standard Armor Tetra.png|50px]]
! 386
| [[Red Standard Armor Hepta]] || [[File:Red Standard Armor Hepta.png|50px]]
|-
|colspan="2" style="width: 25px; background-color:blue;"|
! 77
| [[Blue Standard Armor]] || [[File:Blue Standard Armor.png|50px]]
! 298
| [[Blue Standard Armor Wedge]] || [[File:Blue Standard Armor Wedge.png|50px]]
! 307
| [[Blue Standard Armor Corner]] || [[File:Blue Standard Armor Corner.png|50px]]
! 396
| [[Blue Standard Armor Tetra]] || [[File:Blue Standard Armor Tetra.png|50px]]
! 388
| [[Blue Standard Armor Hepta]] || [[File:Blue Standard Armor Hepta.png|50px]]
|-
|colspan="2" style="width: 25px; background-color:green;"|
! 78
| [[Green Standard Armor]] || [[File:Green Standard Armor.png|50px]]
! 299
| [[Green Standard Armor Wedge]] || [[File:Green Standard Armor Wedge.png|50px]]
! 308
| [[Green Standard Armor Corner]] || [[File:Green Standard Armor Corner.png|50px]]
! 397
| [[Green Standard Armor Tetra]] || [[File:Green Standard Armor Tetra.png|50px]]
! 389
| [[Green Standard Armor Hepta]] || [[File:Green Standard Armor Hepta.png|50px]]
|-
|colspan="2" style="width: 25px; background-color:yellow;"|
! 79
| [[Yellow Standard Armor]] || [[File:Yellow Standard Armor.png|50px]]
! 300
| [[Yellow Standard Armor Wedge]] || [[File:Yellow Standard Armor Wedge.png|50px]]
! 309
| [[Yellow Standard Armor Corner]] || [[File:Yellow Standard Armor Corner.png|50px]]
! 398
| [[Yellow Standard Armor Tetra]] || [[File:Yellow Standard Armor Tetra.png|50px]]
! 391
| [[Yellow Standard Armor Hepta]] || [[File:Yellow Standard Armor Hepta.png|50px]]
|-
|colspan="2" style="width: 25px; background-color:white;"|
! 81
| [[White Standard Armor]] || [[File:White Standard Armor.png|50px]]
! 301
| [[White Standard Armor Wedge]] || [[File:White Standard Armor Wedge.png|50px]]
! 310
| [[White Standard Armor Corner]] || [[File:White Standard Armor Corner.png|50px]]
! 400
| [[White Standard Armor Tetra]] || [[File:White Standard Armor Tetra.png|50px]]
! 392
| [[White Standard Armor Hepta]] || [[File:White Standard Armor Hepta.png|50px]]
|-
|colspan="2" style="width: 25px; background-color:orange;"|
! 426
| [[Orange Standard Armor]] || [[File:Orange Standard Armor.png|50px]]
! 427
| [[Orange Standard Armor Wedge]] || [[File:Orange Standard Armor Wedge.png|50px]]
! 428
| [[Orange Standard Armor Corner]] || [[File:Orange Standard Armor Corner.png|50px]]
! 430
| [[Orange Standard Armor Tetra]] || [[File:Orange Standard Armor Tetra.png|50px]]
! 429
| [[Orange Standard Armor Hepta]] || [[File:Orange Standard Armor Hepta.png|50px]]
|-
|style="background-color:gold;"| ||style="background-color:black;"|
! 436
| [[Yellow Hazard Armor]] || [[File:Yellow Hazard Armor.png|50px]]
! 437
| [[Yellow Hazard Armor Wedge]] || [[File:Yellow Hazard Armor Wedge.png|50px]]
! 648
| [[Yellow Hazard Armor Corner]] || [[File:Yellow Hazard Armor Corner.png|50px]]
! 650
| [[Yellow Hazard Armor Tetra]] || [[File:Yellow Hazard Armor Tetra.png|50px]]
! 649
| [[Yellow Hazard Armor Hepta]] || [[File:Yellow Hazard Armor Hepta.png|50px]]
|-
|style= background-color:forestgreen;"| ||style="background-color:black;"|
! 438
| [[Green Hazard Armor]] || [[File:Green Hazard Armor.png|50px]]
! 439
| [[Green Hazard Armor Wedge]] || [[File:Green Hazard Armor Wedge.png|50px]]
! 651
| [[Green Hazard Armor Corner]] || [[File:Green Hazard Armor Corner.png|50px]]
! 653
| [[Green Hazard Armor Tetra]] || [[File:Green Hazard Armor Tetra.png|50px]]
! 652
| [[Green Hazard Armor Hepta]] || [[File:Green Hazard Armor Hepta.png|50px]]
|-
|colspan="2" style="width: 25px; background-color:dimgrey;"|
! 818
| [[Dark Grey Standard Armor]] || [[File:Dark Grey Standard Armor.png|50px]]
! 819
| [[Dark Grey Standard Armor Wedge]] || [[File:Dark Grey Standard Armor Wedge.png|50px]]
! 820
| [[Dark Grey Standard Armor Corner]] || [[File:Dark Grey Standard Armor Corner.png|50px]]
! 822
| [[Dark Grey Standard Armor Tetra]] || [[File:Dark Grey Standard Armor Tetra.png|50px]]
! 821
| [[Dark Grey Standard Armor Hepta]] || [[File:Dark Grey Standard Armor Hepta.png|50px]]
|-
|colspan="2" style="width: 25px; background-color:teal;"|
! 868
| [[Teal Standard Armor]] || [[File:Teal Standard Armor.png|50px]]
! 869
| [[Teal Standard Armor Wedge]] || [[File:Teal Standard Armor Wedge.png|50px]]
! 870
| [[Teal Standard Armor Corner]] || [[File:Teal Standard Armor Corner.png|50px]]
! 872
| [[Teal Standard Armor Tetra]] || [[File:Teal Standard Armor Tetra.png|50px]]
! 871
| [[Teal Standard Armor Hepta]] || [[File:Teal Standard Armor Hepta.png|50px]]
|-
|colspan="2" style="width: 25px; background-color:hotpink;"|
! 902
| [[Pink Standard Armor]] || [[File:Pink Standard Armor.png|50px]]
! 903
| [[Pink Standard Armor Wedge]] || [[File:Pink Standard Armor Wedge.png|50px]]
! 904
| [[Pink Standard Armor Corner]] || [[File:Pink Standard Armor Corner.png|50px]]
! 906
| [[Pink Standard Armor Tetra]] || [[File:Pink Standard Armor Tetra.png|50px]]
! 905
| [[Pink Standard Armor Hepta]] || [[File:Pink Standard Armor Hepta.png|50px]]
|}

===Advanced Armor===
{|class="wikitable"
!colspan="2"| ID
!colspan="2"|Block
! ID
!colspan="2"|Wedge
! ID
!colspan="2"|Corner
! ID
!colspan="2"|Tetra
! ID
!colspan="2"|Hepta
|-
|style="width: 25px; background-color:lightgrey;"|
! width="40px"| 263
| [[Grey Advanced Armor]] || [[File:Grey Advanced Armor.png|50px]]
! width="40px"| 311
| [[Grey Advanced Armor Wedge]] || [[File:Grey Advanced Armor Wedge.png|50px]]
!width="40px"| 320
| [[Grey Advanced Armor Corner]] || [[File:Grey Advanced Armor Corner.png|50px]]
!width="40px"| 402
| [[Grey Advanced Armor Tetra]] || [[File:Grey Advanced Armor Tetra.png|50px]]
!width="40px"| 401
| [[Grey Advanced Armor Hepta]] || [[File:Grey Advanced Armor Hepta.png|50px]]
|-
|style="width: 25px; background-color:black;"|
! 264
| [[Black Advanced Armor]] || [[File:Black Advanced Armor.png|50px]]
! 312
| [[Black Advanced Armor Wedge]] || [[File:Black Advanced Armor Wedge.png|50px]]
! 321
| [[Black Advanced Armor Corner]] || [[File:Black Advanced Armor Corner.png|50px]]
! 377
| [[Black Advanced Armor Tetra]] || [[File:Black Advanced Armor Tetra.png|50px]]
! 369
| [[Black Advanced Armor Hepta]] || [[File:Black Advanced Armor Hepta.png|50px]]
|-
|style="width: 25px; background-color:red;"|
! 265
| [[Red Advanced Armor]] || [[File:Red Advanced Armor.png|50px]]
! 313
| [[Red Advanced Armor Wedge]] || [[File:Red Advanced Armor Wedge.png|50px]]
! 322
| [[Red Advanced Armor Corner]] || [[File:Red Advanced Armor Corner.png|50px]]
! 378
| [[Red Advanced Armor Tetra]] || [[File:Red Advanced Armor Tetra.png|50px]]
! 370
| [[Red Advanced Armor Hepta]] || [[File:Red Advanced Armor Hepta.png|50px]]
|-
|style="width: 25px; background-color:purple;"|
! 266
| [[Purple Advanced Armor]] || [[File:Purple Advanced Armor.png|50px]]
! 314
| [[Purple Advanced Armor Wedge]] || [[File:Purple Advanced Armor Wedge.png|50px]]
! 323
| [[Purple Advanced Armor Corner]] || [[File:Purple Advanced Armor Corner.png|50px]]
! 379
| [[Purple Advanced Armor Tetra]] || [[File:Purple Advanced Armor Tetra.png|50px]]
! 371
| [[Purple Advanced Armor Hepta]] || [[File:Purple Advanced Armor Hepta.png|50px]]
|-
|style="width: 25px; background-color:blue;"|
! 267
| [[Blue Advanced Armor]] || [[File:Blue Advanced Armor.png|50px]]
! 315
| [[Blue Advanced Armor Wedge]] || [[File:Blue Advanced Armor Wedge.png|50px]]
! 324
| [[Blue Advanced Armor Corner]] || [[File:Blue Advanced Armor Corner.png|50px]]
! 380
| [[Blue Advanced Armor Tetra]] || [[File:Blue Advanced Armor Tetra.png|50px]]
! 372
| [[Blue Advanced Armor Hepta]] || [[File:Blue Advanced Armor Hepta.png|50px]]
|-
|style="width: 25px; background-color:green;"|
! 268
| [[Green Advanced Armor]] || [[File:Green Advanced Armor.png|50px]]
! 316
| [[Green Advanced Armor Wedge]] || [[File:Green Advanced Armor Wedge.png|50px]]
! 325
| [[Green Advanced Armor Corner]] || [[File:Green Advanced Armor Corner.png|50px]]
! 381
| [[Green Advanced Armor Tetra]] || [[File:Green Advanced Armor Tetra.png|50px]]
! 373
| [[Green Advanced Armor Hepta]] || [[File:Green Advanced Armor Hepta.png|50px]]
|-
|style="width: 25px; background-color:chocolate;"|
! 269
| [[Brown Advanced Armor]] || [[File:Brown Advanced Armor.png|50px]]
! 317
| [[Brown Advanced Armor Wedge]] || [[File:Brown Advanced Armor Wedge.png|50px]]
! 326
| [[Brown Advanced Armor Corner]] || [[File:Brown Advanced Armor Corner.png|50px]]
! 382
| [[Brown Advanced Armor Tetra]] || [[File:Brown Advanced Armor Tetra.png|50px]]
! 374
| [[Brown Advanced Armor Hepta]] || [[File:Brown Advanced Armor Hepta.png|50px]]
|-
|style="width: 25px; background-color:yellow;"|
! 270
| [[Yellow Advanced Armor]] || [[File:Yellow Advanced Armor.png|50px]]
! 318
| [[Yellow Advanced Armor Wedge]] || [[File:Yellow Advanced Armor Wedge.png|50px]]
! 327
| [[Yellow Advanced Armor Corner]] || [[File:Yellow Advanced Armor Corner.png|50px]]
! 383
| [[Yellow Advanced Armor Tetra]] || [[File:Yellow Advanced Armor Tetra.png|50px]]
! 375
| [[Yellow Advanced Armor Hepta]] || [[File:Yellow Advanced Armor Hepta.png|50px]]
|-
|style="width: 25px; background-color:white;"|
! 271
| [[White Advanced Armor]] || [[File:White Advanced Armor.png|50px]]
! 319
| [[White Advanced Armor Wedge]] || [[File:White Advanced Armor Wedge.png|50px]]
! 328
| [[White Advanced Armor Corner]] || [[File:White Advanced Armor Corner.png|50px]]
! 384
| [[White Advanced Armor Tetra]] || [[File:White Advanced Armor Tetra.png|50px]]
! 376
| [[White Advanced Armor Hepta]] || [[File:White Advanced Armor Hepta.png|50px]]
|-
|style="width: 25px; background-color:orange;"|
! 431
| [[Orange Advanced Armor]] || [[File:Orange Advanced Armor.png|50px]]
! 432
| [[Orange Advanced Armor Wedge]] || [[File:Orange Advanced Armor Wedge.png|50px]]
! 433
| [[Orange Advanced Armor Corner]] || [[File:Orange Advanced Armor Corner.png|50px]]
! 435
| [[Orange Advanced Armor Tetra]] || [[File:Orange Advanced Armor Tetra.png|50px]]
! 434
| [[Orange Advanced Armor Hepta]] || [[File:Orange Advanced Armor Hepta.png|50px]]
|-
|style="width: 25px; background-color:dimgrey;"|
! 823
| [[Dark Grey Advanced Armor]] || [[File:Dark Grey Advanced Armor.png|50px]]
! 824
| [[Dark Grey Advanced Armor Wedge]] || [[File:Dark Grey Advanced Armor Wedge.png|50px]]
! 825
| [[Dark Grey Advanced Armor Corner]] || [[File:Dark Grey Advanced Armor Corner.png|50px]]
! 827
| [[Dark Grey Advanced Armor Tetra]] || [[File:Dark Grey Advanced Armor Tetra.png|50px]]
! 826
| [[Dark Grey Advanced Armor Hepta]] || [[File:Dark Grey Advanced Armor Hepta.png|50px]]
|-
|style="width: 25px; background-color:teal;"|
! 873
| [[Teal Advanced Armor]] || [[File:Teal Advanced Armor.png|50px]]
! 874
| [[Teal Advanced Armor Wedge]] || [[File:Teal Advanced Armor Wedge.png|50px]]
! 875
| [[Teal Advanced Armor Corner]] || [[File:Teal Advanced Armor Corner.png|50px]]
! 877
| [[Teal Advanced Armor Tetra]] || [[File:Teal Advanced Armor Tetra.png|50px]]
! 876
| [[Teal Advanced Armor Hepta]] || [[File:Teal Advanced Armor Hepta.png|50px]]
|-
|style="width: 25px; background-color:hotpink;"|
! 907
| [[Pink Advanced Armor]] || [[File:Pink Advanced Armor.png|50px]]
! 908
| [[Pink Advanced Armor Wedge]] || [[File:Pink Advanced Armor Wedge.png|50px]]
! 909
| [[Pink Advanced Armor Corner]] || [[File:Pink Advanced Armor Corner.png|50px]]
! 911
| [[Pink Advanced Armor Tetra]] || [[File:Pink Advanced Armor Tetra.png|50px]]
! 910
| [[Pink Advanced Armor Hepta]] || [[File:Pink Advanced Armor Hepta.png|50px]]
|}

===Crystal Armor===
{|class="wikitable"
!colspan="2"| ID
!colspan="2"|Block
! ID
!colspan="2"|Wedge
! ID
!colspan="2"|Corner
! ID
!colspan="2"|Tetra
! ID
!colspan="2"|Hepta
|-
|style="width: 25px; background-color:white;"|
!width="40px"| 507
| [[White Crystal Armor]] || [[File:White Crystal Armor.png|50px]]
!width="40px"| 508
| [[White Crystal Armor Wedge]] || [[File:White Crystal Armor Wedge.png|50px]]
!width="40px"| 509
| [[White Crystal Armor Corner]] || [[File:White Crystal Armor Corner.png|50px]]
!width="40px"| 511
| [[White Crystal Armor Tetra]] || [[File:White Crystal Armor Tetra.png|50px]]
!width="40px"| 510
| [[White Crystal Armor Hepta]] || [[File:White Crystal Armor Hepta.png|50px]]
|-
|style="width: 25px; background-color:red;"|
! 512
| [[Red Crystal Armor]] || [[File:Red Crystal Armor.png|50px]]
! 513
| [[Red Crystal Armor Wedge]] || [[File:Red Crystal Armor Wedge.png|50px]]
! 514
| [[Red Crystal Armor Corner]] || [[File:Red Crystal Armor Corner.png|50px]]
! 516
| [[Red Crystal Armor Tetra]] || [[File:Red Crystal Armor Tetra.png|50px]]
! 515
| [[Red Crystal Armor Hepta]] || [[File:Red Crystal Armor Hepta.png|50px]]
|-
|style="width: 25px; background-color:orange;"|
! 517
| [[Orange Crystal Armor]] || [[File:Orange Crystal Armor.png|50px]]
! 518
| [[Orange Crystal Armor Wedge]] || [[File:Orange Crystal Armor Wedge.png|50px]]
! 519
| [[Orange Crystal Armor Corner]] || [[File:Orange Crystal Armor Corner.png|50px]]
! 521
| [[Orange Crystal Armor Tetra]] || [[File:Orange Crystal Armor Tetra.png|50px]]
! 520
| [[Orange Crystal Armor Hepta]] || [[File:Orange Crystal Armor Hepta.png|50px]]
|-
|style="width: 25px; background-color:yellow;"|
! 522
| [[Yellow Crystal Armor]] || [[File:Yellow Crystal Armor.png|50px]]
! 523
| [[Yellow Crystal Armor Wedge]] || [[File:Yellow Crystal Armor Wedge.png|50px]]
! 524
| [[Yellow Crystal Armor Corner]] || [[File:Yellow Crystal Armor Corner.png|50px]]
! 526
| [[Yellow Crystal Armor Tetra]] || [[File:Yellow Crystal Armor Tetra.png|50px]]
! 525
| [[Yellow Crystal Armor Hepta]] || [[File:Yellow Crystal Armor Hepta.png|50px]]
|-
|style="width: 25px; background-color:green;"|
! 527
| [[Green Crystal Armor]] || [[File:Green Crystal Armor.png|50px]]
! 528
| [[Green Crystal Armor Wedge]] || [[File:Green Crystal Armor Wedge.png|50px]]
! 529
| [[Green Crystal Armor Corner]] || [[File:Green Crystal Armor Corner.png|50px]]
! 531
| [[Green Crystal Armor Tetra]] || [[File:Green Crystal Armor Tetra.png|50px]]
! 530
| [[Green Crystal Armor Hepta]] || [[File:Green Crystal Armor Hepta.png|50px]]
|-
|style="width: 25px; background-color:blue;"|
! 532
| [[Blue Crystal Armor]] || [[File:Blue Crystal Armor.png|50px]]
! 533
| [[Blue Crystal Armor Wedge]] || [[File:Blue Crystal Armor Wedge.png|50px]]
! 534
| [[Blue Crystal Armor Corner]] || [[File:Blue Crystal Armor Corner.png|50px]]
! 536
| [[Blue Crystal Armor Tetra]] || [[File:Blue Crystal Armor Tetra.png|50px]]
! 535
| [[Blue Crystal Armor Hepta]] || [[File:Blue Crystal Armor Hepta.png|50px]]
|-
|style="width: 25px; background-color:purple;"|
! 537
| [[Purple Crystal Armor]] || [[File:Purple Crystal Armor.png|50px]]
! 538
| [[Purple Crystal Armor Wedge]] || [[File:Purple Crystal Armor Wedge.png|50px]]
! 539
| [[Purple Crystal Armor Corner]] || [[File:Purple Crystal Armor Corner.png|50px]]
! 541
| [[Purple Crystal Armor Tetra]] || [[File:Purple Crystal Armor Tetra.png|50px]]
! 540
| [[Purple Crystal Armor Hepta]] || [[File:Purple Crystal Armor Hepta.png|50px]]
|-
|style="width: 25px; background-color:black;"|
! 593
| [[Black Crystal Armor]] || [[File:Black Crystal Armor.png|50px]]
! 594
| [[Black Crystal Armor Wedge]] || [[File:Black Crystal Armor Wedge.png|50px]]
! 595
| [[Black Crystal Armor Corner]] || [[File:Black Crystal Armor Corner.png|50px]]
! 597
| [[Black Crystal Armor Tetra]] || [[File:Black Crystal Armor Tetra.png|50px]]
! 596
| [[Black Crystal Armor Hepta]] || [[File:Black Crystal Armor Hepta.png|50px]]
|-
|style="width: 25px; background-color:chocolate;"|
! 690
| [[Brown Crystal Armor]] || [[File:Brown Crystal Armor.png|50px]]
! 691
| [[Brown Crystal Armor Wedge]] || [[File:Brown Crystal Armor Wedge.png|50px]]
! 692
| [[Brown Crystal Armor Corner]] || [[File:Brown Crystal Armor Corner.png|50px]]
! 694
| [[Brown Crystal Armor Tetra]] || [[File:Brown Crystal Armor Tetra.png|50px]]
! 693
| [[Brown Crystal Armor Hepta]] || [[File:Brown Crystal Armor Hepta.png|50px]]
|-
|style="width: 25px; background-color:teal;"|
! 883
| [[Teal Crystal Armor]] || [[File:Teal Crystal Armor.png|50px]]
! 884
| [[Teal Crystal Armor Wedge]] || [[File:Teal Crystal Armor Wedge.png|50px]]
! 885
| [[Teal Crystal Armor Corner]] || [[File:Teal Crystal Armor Corner.png|50px]]
! 887
| [[Teal Crystal Armor Tetra]] || [[File:Teal Crystal Armor Tetra.png|50px]]
! 886
| [[Teal Crystal Armor Hepta]] || [[File:Teal Crystal Armor Hepta.png|50px]]
|-
|style="width: 25px; background-color:hotpink;"|
! 917
| [[Pink Crystal Armor]] || [[File:Pink Crystal Armor.png|50px]]
! 918
| [[Pink Crystal Armor Wedge]] || [[File:Pink Crystal Armor Wedge.png|50px]]
! 919
| [[Pink Crystal Armor Corner]] || [[File:Pink Crystal Armor Corner.png|50px]]
! 921
| [[Pink Crystal Armor Tetra]] || [[File:Pink Crystal Armor Tetra.png|50px]]
! 920
| [[Pink Crystal Armor Hepta]] || [[File:Pink Crystal Armor Hepta.png|50px]]
|}

===Doors===
{|class="wikitable"
! width="40px"|ID
!colspan="2"|Name
!width="40px"| ID
!colspan="2"|Name
|-
! 122
| [[Plex Door]] || [[File:Plex Door.png|50px]]
! 588
| [[Plex Door Wedge]] || [[File:Plex Door Wedge.png|50px]]
|-
! 589
| [[Glass Door]] || [[File:Glass Door.png|50px]]
! 590
| [[Glass Door Wedge]] || [[File:Glass Door Wedge.png|50px]]
|-
! 591
| [[Blast Door]] || [[File:Blast Door.png|50px]]
! 592
| [[Blast Door Wedge]] || [[File:Blast Door Wedge.png|50px]]
|-
! 659
| [[Forcefield (Red)]] || [[File:Forcefield (Red).png|50px]]
! 673
| [[Forcefield Wedge (Red)]] || [[File:Forcefield Wedge (Red).png|50px]]
|-
! 660
| [[Forcefield (Blue)]] || [[File:Forcefield (Blue).png|50px]]
! 674
| [[Forcefield Wedge (Blue)]] || [[File:Forcefield Wedge (Blue).png|50px]]
|-
! 661
| [[Forcefield (Yellow)]] || [[File:Forcefield (Yellow).png|50px]]
! 675
| [[Forcefield Wedge (Yellow)]] || [[File:Forcefield Wedge (Yellow).png|50px]]
|}

==Docking==

===Old Docking===
{|class="wikitable"
!width="40px"| ID
!colspan="2"| Name
|-
! 7
| [[Turret Docking Unit]] || [[File:Turret Docking Unit.png|50px]]
|-
! 88
| [[Turret Docking Enhancer Unit]] || [[File:Turret Docking Enhancer Unit.png|50px]]
|-
! 289
| [[Docking Module]] || [[File:Docking Module.png|50px]]
|-
! 290
| [[Docking Enhancer]] || [[File:Docking Enhancer.png|50px]]
|}

===Rails===
{|class="wikitable
!width="40px"| ID
!colspan="2"| Name
|-
! 662
| [[Rail Basic]] || [[File:Rail Basic.png|50px]]
|-
! 663
| [[Rail Docker]] || [[File:Rail Docker.png|50px]]
|-
! 664
| [[Rail Rotator Clock Wise]] || [[File:Rail Rotator Clock Wise.png|50px]]
|-
! 665
| [[Rail Turret Axis]] || [[File:Rail Turret Axis.png|50px]]
|-
! 669
| [[Rail Rotator Counter Clock Wise]] || [[File:Rail Rotator Counter Clock Wise.png|50px]]
|-
! 671
| [[Rail Mass Enhancer]] || [[File:Rail Mass Enhancer.png|50px]]
|-
! 672
| [[Rail Speed Controller]] || [[File:Rail Speed Controller.png|50px]]
|-
! 937
| [[Pickup Point]] || [[File:Pickup Point.png|50px]]
|-
! 938
| [[Pickup Rail]] || [[File:Pickup Rail.png|50px]]
|-
! 939
| [[Shootout Rail]] || [[File:Shootout Rail.png|50px]]
|}

==Effects==
{|class="wikitable"
!width="40px"| ID
!colspan="2"| Name
!width="40px"| ID
!colspan="2"| Name
|-
! 418
| [[Piercing Effect Computer]] || [[File:Piercing Effect Computer.png|50px]]
! 419
| [[Piercing Effect Module]] || [[File:Piercing Effect Module.png|50px]]
|-
! 420
| [[Explosive Effect Computer]] || [[File:Explosive Effect Computer.png|50px]]
! 421
| [[Explosive Effect Module]] || [[File:Explosive Effect Module.png|50px]]
|-
! 422
| [[Punch-Through Effect Computer]] || [[File:Punch-Through Effect Computer.png|50px]]
! 423
| [[Punch-Through Effect Module]] || [[File:Punch-Through Effect Module.png|50px]]
|-
! 424
| [[EMP Effect Computer]] || [[File:EMP Effect Computer.png|50px]]
! 425
| [[EMP Effect Module]] || [[File:EMP Effect Module.png|50px]]
|-
! 460
| [[Stop Effect Computer]] || [[File:Stop Effect Computer.png|50px]]
! 461
| [[Stop Effect Module]] || [[File:Stop Effect Module.png|50px]]
|-
! 462
| [[Push Effect Computer]] || [[File:Push Effect Computer.png|50px]]
! 463
| [[Push Effect Module]] || [[File:Push Effect Module.png|50px]]
|-
! 464
| [[Pull Effect Computer]] || [[File:Pull Effect Computer.png|50px]]
! 465
| [[Pull Effect Module]] || [[File:Pull Effect Module.png|50px]]
|-
! 466
| [[Ion Effect Computer]] || [[File:Ion Effect Computer.png|50px]]
! 467
| [[Ion Effect Module]] || [[File:Ion Effect Module.png|50px]]
|-
! 476
| [[Overdrive Effect Computer]] || [[File:Overdrive Effect Computer.png|50px]]
! 477
| [[Overdrive Effect Module]] || [[File:Overdrive Effect Module.png|50px]]
|}

==Weapons==
{|class="wikitable"
!width="40px"| ID
! colspan="2"|Name
!width="40px"| ID
!colspan="2"| Name
|-
! 14
| [[Warhead]] || [[File:Warhead.png | 50px]]
|-
! 6
| [[Cannon Computer]] || [[File:Cannon_Computer.png | 50px]]
! 16
| [[Cannon Barrel]] || [[File:Cannon_Barrel.png | 50px]]
|-
! 38
| [[Missile Computer]] || [[File:Missile_Computer.png | 50px]]
! 32
| [[Missile Tube]] || [[File:Missile_Tube.png | 50px]]
|-
! 414
| [[Damage Beam Computer]] || [[File:Damage_Beam_Computer.png | 50px]]
! 415
| [[Damage Beam Module]] || [[File:Damage_Beam_Module.png | 50px]]
|-
! 416
| [[Damage Pulse Computer]] || [[File:Damage_Pulse_Computer.png | 50px]]
! 417
| [[Damage Pulse Module]] || [[File:Damage_Pulse_Module.png | 50px]]
|}

==Support Tools==
{|class="wikitable"
! ID !! Name !! ID !! Name
|-
| 4 || [[Salvage Computer]] || 24 || [[Salvage Module]]
|-
| 39 || [[Astrotech Computer]] || 30 || [[Astrotech Module]]
|-
| 46 || [[Shield Drain Computer]] || 40 || [[Shield Drain Module]]
|-
| 54 || [[Shield Supply Computer]] || 48 || [[Shield Supply Module]]
|-
| 332 || [[Power Drain Computer]] || 333 || [[Power Drain Module]]
|-
| 334 || [[Power Supply Computer]] || 335 || [[Power Supply Module]]
|-
| 344 || [[Push Pulse Computer]] || 345 || [[Push Pulse Computer]]
|}

==Logic==
{|class="wikitable"
! ID !! Name
|-
| 405 || [[Activation Module]]
|-
| 406 || [[Signal (Delay-Non-Repeating)]]
|-
| 407 || [[DELAY-Signal]]
|-
| 408 || [[AND-Signal]]
|-
| 409 || [[OR-Signal]]
|-
| 410 || [[NOT-Signal]]
|-
| 411 || [[Trigger (Area)]]
|-
| 412 || [[Trigger (Step On)]]
|-
| 413 || [[Trigger (Area) Controller]]
|-
| 666 || [[Button]]
|-
| 667 || [[Flip Flop]]
|-
| 668 || [[Wireless Logic Module]]
|-
| 670 || [[Inner Ship Remote]]
|-
| 685 || [[Activation Gate Controller]]
|-
| 686 || [[Activation Gate Module]]
|}

==Crafting Materials==
{|class="wikitable"
! ID !! Name !! Pic
|-
| 143 || [[Larimar Capsule]] || [[File:Larimar_Capsule.png | 32px]]
|-
| 152 || [[Chabaz Capsule]] || [[File:Chabaz_Capsule.png | 32px]]
|-
| 156 || [[Lukrah Capsule]] || [[File:Lukrah_Capsule.png | 32px]]
|-
| 160 || [[Dolom Capsule]] || [[File:Dolom_Capsule.png | 32px]]
|-
| 164 || [[Sugil Capsule]] || [[File:Sugil_Capsule.png | 32px]]
|-
| 172 || [[Cinnabar Capsule]] || [[File:Cinnabar_Capsule.png | 32px]]
|-
| 180 || [[Varis Capsule]] || [[File:Varis_Capsule.png | 32px]]
|-
| 204 || [[Tekt Capsule]] || [[File:Tekt_Capsule.png | 32px]]
|-
| 220 || [[Crystal Composite]] || [[File:Crystal_Composite.png | 32px]]
|-
| 440 || [[Alloyed Metal Mesh]] || [[File:Alloyed_Metal_Mesh.png | 32px]]
|-
| 238 || [[Orange Paint]] || [[File:Orange_Paint.png | 32px]]
|-
| 239 || [[Red Paint]] || [[File:Red_Paint.png | 32px]]
|-
| 240 || [[Purple Paint]] || [[File:Purple_Paint.png | 32px]]
|-
| 241 || [[Brown Paint]] || [[File:Brown_Paint.png | 32px]]
|-
| 242 || [[Green Paint]] || [[File:Green_Paint.png | 32px]]
|-
| 243 || [[Yellow Paint]] || [[File:Yellow_Paint.png | 32px]]
|-
| 244 || [[Black Paint]] || [[File:Black_Paint.png | 32px]]
|-
| 245 || [[White Paint]] || [[File:White_Paint.png | 32px]]
|-
| 246 || [[Blue Paint]] || [[File:Blue_Paint.png | 32px]]
|-
| 546 || [[Scrap Alloy]] || [[File:Scrap_Alloy.png | 32px]]
|-
| 547 || [[Scrap Composite]] || [[File:Scrap_Composite.png | 32px]]
|-
| 866 || [[Standard Hardener]] || [[File:Standard_Hardener.png | 32px]]
|-
| 867 || [[Advanced Hardener]] || [[File:Advanced_Hardener.png | 32px]]
|}

===Shards===
{|class="wikitable"
! ID !! Name !! Pic !! ID !! Name !! Pic
|-
| 480 || [[Hattel Shard Raw]] || [[File:Hattel_Shard_Raw.png | 32px]] || 182 || [[Hattel Capsule]] || [[File:Hattel_Capsule.png | 32px]]
|-
| 481 || [[Sintyr Shard Raw]] || [[File:Sintyr_Shard_Raw.png | 32px]] || 146 || [[Sintyr Capsule]] || [[File:Sintyr_Capsule.png | 32px]]
|-
| 482 || [[Mattise Shard Raw]] || [[File:Mattise_Shard_Raw.png | 32px]] || 194 || [[Mattise Capsule]] || [[File:Mattise_Capsule.png | 32px]]
|-
| 483 || [[Rammet Shard Raw]] || [[File:Rammet_Shard_Raw.png | 32px]] || 174 || [[Rammet Capsule]] || [[File:Rammet_Capsule.png | 32px]]
|-
| 484 || [[Varat Shard Raw]] || [[File:Varat_Shard_Raw.png | 32px]] || 190 || [[Varat Capsule]] || [[File:Varat_Capsule.png | 32px]]
|-
| 485 || [[Bastyn Shard Raw]] || [[File:Bastyn_Shard_Raw.png | 32px]] || 186 || [[Bastyn Capsule]] || [[File:Bastyn_Capsule.png | 32px]]
|-
| 486 || [[Parseen Shard Raw]] || [[File:Parseen_Shard_Raw.png | 32px]] || 166 || [[Parseen Capsule]] || [[File:Parseen_Capsule.png | 32px]]
|-
| 487 || [[Nocx Shard Raw]] || [[File:Nocx_Shard_Raw.png | 32px]] || 198 || [[Nocx Capsule]] || [[File:Nocx_Capsule.png | 32px]]
|}

===Ores===
{|class="wikitable"
! ID !! Name !! Pic !! ID !! Name !! Pic
|-
| 488 || [[Threns Ore Raw]] || [[File:Threns_Ore_Raw.png | 32px]] || 154 || [[Threns Capsule]] || [[File:Threns_Capsule.png | 32px]]
|-
| 489 || [[Jisper Ore Raw]] || [[File:Jisper_Ore_Raw.png | 32px]] || 150 || [[Jisper Capsule]] || [[File:Jisper_Capsule.png | 32px]]
|-
| 490 || [[Zercaner Ore Raw]] || [[File:Zercaner_Ore_Raw.png | 32px]] || 170 || [[Zercaner Capsule]] || [[File:Zercaner_Capsule.png | 32px]]
|-
| 491 || [[Sertise Ore Raw]] || [[File:Sertise_Ore_Raw.png | 32px]] || 162 || [[Sertise Capsule]] || [[File:Sertise_Capsule.png | 32px]]
|-
| 492 || [[Hylat Ore Raw]] || [[File:Hylat_Ore_Raw.png | 32px]] || 142 || [[Hylat Capsule]] || [[File:Hylat_Capsule.png | 32px]]
|-
| 493 || [[Fertikeen Ore Raw]] || [[File:Fertikeen_Ore_Raw.png | 32px]] || 178 || [[Fertikeen Capsule]] || [[File:Fertikeen_Capsule.png | 32px]]
|-
| 494 || [[Sapsun Ore Raw]] || [[File:Sapsun_Ore_Raw.png | 32px]] || 158 || [[Sapsun Capsule]] || [[File:Sapsun_Capsule.png | 32px]]
|-
| 495 || [[Macet Ore Raw]] || [[File:Macet_Ore_Raw.png | 32px]] || 202 || [[Macet Capsule]] || [[File:Macet_Capsule.png | 32px]]
|}

==Factions==
{|class="wikitable"
! ID !! Name !! Pic
|-
| 291 || [[Faction Module]] || [[File:Faction_Module.png | 32px]]
|-
| 346 || [[Public Permission Module]] || [[File:Public_Permission_Module.png | 32px]]
|-
| 936 || [[Faction Permission Module]] || [[File:Faction_Permission_Module.png | 32px]]
|}

==Station only==
{|class="wikitable"
! ID !! Name !! Pic
|-
| 94 || [[Undeathinator]]
|-
| 113 || [[Plex Lift]]
|-
| 211 || [[Basic Factory]]
|-
| 217 || [[Standard Factory]] || [[File:Standard_Factory.png | 32px]]
|-
| 259 || [[Advanced Factory]]
|-
| 213 || [[Capsule Refinery]]
|-
| 215 || [[Micro Assembler]]
|-
| 212 || [[Factory Enhancer]]
|-
| 347 || [[Shop Module]]
|-
| 542 || [[Warp Gate Computer]]
|-
| 543 || [[Warp Gate Module]]
|-
| 677 || [[Shipyard Computer]]
|-
| 678 || [[Shipyard Module]]
|-
| 679 || [[Shipyard Core Anchor]]
|-
| 683 || [[Race Gate Controller]]
|-
| 684 || [[Race Gate Module]]
|}

==Decorative==
{|class="wikitable"
! ID !! Name
|-
| 479 || [[Display Module]]
|-
| 336 || [[Decorative Switchboard]]
|-
| 337 || [[Decorative Server]]
|-
| 338 || [[Decorative Pipes]]
|-
| 339 || [[Decorative Panel]]
|-
| 447 || [[Decorative Screen (Red)]]
|-
| 448 || [[Decorative Screen (Blue)]]
|-
| 449 || [[Decorative Computer (Green)]]
|-
| 450 || [[Decorative Computer (Orange)]]
|-
| 451 || [[Personal Computer (Blue)]]
|-
| 657 || [[Decorative Charts]]
|-
| 658 || [[Conduit (Blue)]]
|-
| 680 || [[Decorative Fan]]
|-
| 941 || [[Girder]]
|-
| 975 || [[Decorative Console (Blue)]]
|-
| 976 || [[Pipe]]
|-
| 144 || [[Carved Larimar]]
|-
| 153 || [[Carved Chabaz]]
|-
| 157 || [[Carved Lukrah]]
|-
| 161 || [[Carved Dolom]]
|-
| 165 || [[Carved Sugil]]
|-
| 173 || [[Carved Cinnabar]]
|-
| 181 || [[Carved Varis]]
|-
| 205 || [[Carved Tekt]]
|-
| 656 || [[Scaffold]]
|-
| 676 || [[Scaffold Wedge]]
|-
| 219 || [[Crystal Composite Wedge]]
|-
| 441 || [[Alloyed Metal Mesh Wedge]]
|-
| 442 || [[Metal Grill]]
|-
| 443 || [[Metal Grill Wedge]]
|-
| 444 || [[Ice Crystal Wedge]]
|-
| 940 || [[Ice Wedge]]
|}

===Lighting===

{|class="wikitable"
! ID !! Name !! ID !! Name
|-
| 977 || [[White Light Bar]]
|-
| 55 || [[White Light]] || 499 || [[White Rod Light]]
|-
| 282 || [[Red light | Red Light]] || 501 || [[Red Rod Light]]
|-
| 283 || [[Blue Light]] || 505 || [[Blue Rod Light]]
|-
| 284 || [[Green Light]] || 504 || [[Green Rod Light]]
|-
| 285 || [[Yellow Light]] || 340 || [[Yellow Rod Light]]
|-
| 496 || [[Purple Light]] || 506 || [[Purple Rod Light]]
|-
| 497 || [[Orange Light]] || 502 || [[Orange Rod Light]]
|-
| 498 || [[Black Light]] || 500 || [[Black Rod Light]]
|-
| 888 || [[Teal Light]] || 889 || [[Teal Light Rod | Teal Rod Light]]
|-
| 922 || [[Pink Light]] || 923 || [[Pink Light Rod | Pink Rod Light]]
|-
| 62 || [[Beacon]] || 503 || [[Beacon Rod]]
|}

===Crystals===

{|class="wikitable"
! ID !! Name !! ID !! Name
|-
| 452 || [[Rammet Crystal]] || 550 || [[Rammet Crystal Wedge]]
|-
| 453 || [[Nocx Crystal]] || 548 || [[Nocx Crystal Wedge]]
|-
| 454 || [[Parseen Crystal]] || 549 || [[Parseen Crystal Wedge]]
|-
| 455 || [[Hattel Crystal]] || 553 || [[Hattel Crystal Wedge]]
|-
| 456 || [[Mattise Crystal]] || 555 || [[Mattise Crystal Wedge]]
|-
| 457 || [[Sintyr Crystal]] || 554 || [[Sintyr Crystal Wedge]]
|-
| 458 || [[Bastyn Crystal]] || 552 || [[Bastyn Crystal Wedge]]
|-
| 459 || [[Varat Crystal]] || 551 || [[Varat Crystal Wedge]]
|}

===Ingots===

{|class="wikitable"
! ID !! Name !! ID !! Name
|-
| 468 || [[Sertise Ingot]] || 558 || [[Sertise Ingot Wedge]]
|-
| 469 || [[Macet Ingot]] || 556 || [[Macet Ingot Wedge]]
|-
| 470 || [[Sapsun Ingot]] || 557 || [[Sapsun Ingot Wedge]]
|-
| 471 || [[Threns Ingot]] || 561 || [[Threns Ingot Wedge]]
|-
| 472 || [[Zercaner Ingot]] || 563 || [[Zercaner Ingot Wedge]]
|-
| 473 || [[Jisper Ingot]] || 562 || [[Jisper Ingot Wedge]]
|-
| 474 || [[Fertikeen Ingot]] || 560 || [[Fertikeen Ingot Wedge]]
|-
| 475 || [[Hylat Ingot]] || 559 || [[Hylat Ingot Wedge]]
|}

===Motherboards===

{|class="wikitable"
! ID !! Name !! ID !! Name
|-
| 223 || [[Fertikeen Motherboard]] || 576 || [[Fertikeen Motherboard Wedge]]
|-
| 226 || [[Zercaner Motherboard]] || 579 || [[Zercaner Motherboard Wedge]]
|-
| 229 || [[Hylat Motherboard]] || 575 || [[Hylat Motherboard Wedge]]
|-
| 232 || [[Sapsun Motherboard]] || 573 || [[Sapsun Motherboard Wedge]]
|-
| 235 || [[Threns Motherboard]] || 577 || [[Threns Motherboard Wedge]]
|-
| 247 || [[Jisper Motherboard]] || 578 || [[Jisper Motherboard Wedge]]
|-
| 250 || [[Sertise Motherboard]] || 574 || [[Sertise Motherboard Wedge]]
|-
| 254 || [[Macet Motherboard]] || 572 || [[Macet Motherboard Wedge]]
|}

===Circuits===

{|class="wikitable"
! ID !! Name !! ID !! Name
|-
| 224 || [[Bastyn Circuit]] || 568 || [[Bastyn Circuit Wedge]]
|-
| 227 || [[Mattise Circuit]] || 571 || [[Mattise Circuit Wedge]]
|-
| 230 || [[Varat Circuit]] || 567 || [[Varat Circuit Wedge]]
|-
| 233 || [[Parseen Circuit]] || 565 || [[Parseen Circuit Wedge]]
|-
| 236 || [[Hattel Circuit]] || 569 || [[Hattel Circuit Wedge]]
|-
| 248 || [[Sintyr Circuit]] || 570 || [[Sintyr Circuit Wedge]]
|-
| 251 || [[Rammet Circuit]] || 566 || [[Rammet Circuit Wedge]]
|-
| 272 || [[Nocx Circuit]] || 564 || [[Nocx Circuit Wedge]]
|-
| 225 || [[Bastyn Charged Circuit]] || 584 || [[Bastyn Charged Circuit Wedge]]
|-
| 228 || [[Mattise Charged Circuit]] || 587 || [[Mattise Charged Circuit Wedge]]
|-
| 231 || [[Varat Charged Circuit]] || 583 || [[Varat Charged Circuit Wedge]]
|-
| 234 || [[Parseen Charged Circuit]] || 581 || [[Parseen Charged Circuit Wedge]]
|-
| 237 || [[Hattel Charged Circuit]] || 585 || [[Hattel Charged Circuit Wedge]]
|-
| 249 || [[Sintyr Charged Circuit]] || 586 || [[Sintyr Charged Circuit Wedge]]
|-
| 252 || [[Rammet Charged Circuit]] || 582 || [[Rammet Charged Circuit Wedge]]
|-
| 273 || [[Nocx Charged Circuit]] || 580 || [[Nocx Charged Circuit Wedge]]
|-
| 253 || [[Beacon Charged Circuit]]
|}

==Medical==
{|class="wikitable
! ID !! Name
|-
| 445 || [[Medical Supplies]]
|-
| 446 || [[Medical Cabinet]]
|}

==Nature==
{|class="wikitable"
! ID !! Name
|-
| 64 || [[Ice]]
|-
| 73 || [[Rock]]
|-
| 74 || [[Sand]]
|-
| 80 || [[Lava]]
|-
| 82 || [[Grass]]
|-
| 83 || [[Grassy Rock]]
|-
| 84 || [[Wood]]
|-
| 85 || [[Foliage]]
|-
| 86 || [[Water]]
|-
| 87 || [[Soil]]
|-
| 89 || [[Cactus]]
|-
| 90 || [[Purple Top Stuff]]
|-
| 91 || [[Purple Rock Stuff]]
|-
| 92 || [[Purple Vine Stuff]]
|-
| 183 || [[Red Planet Terrain]]
|-
| 139 || [[Blue Rock]]
|-
| 140 || [[Red Dirt]]
|-
| 141 || [[Rock Red Planet Terrain]]
|-
| 274 || [[Snowy Rock Surface]]
|-
| 275 || [[Frozen Rock]]
|-
| 276 || [[Frozen Wood]]
|-
| 277 || [[Frozen Leaves]]
|-
| 286 || [[Ice Crystal]]
|-
| 287 || [[Red Wood]]
|-
| 288 || [[Red Wood Leaves]]
|-
| 143 || [[Larimar]]
|-
| 151 || [[Chabaz]]
|-
| 155 || [[Lukrah]]
|-
| 159 || [[Dolom]]
|-
| 163 || [[Sugil]]
|-
| 171 || [[Cinnabar]]
|-
|179 || [[Varis]]
|-
| 203 || [[Tekt]]
|-
| 93 || [[Blue Flowers]]
|-
| 95 || [[Small Cactus]]
|-
| 96 || [[Coral]]
|-
| 97 || [[Fan Flower]]
|-
| 98 || [[Long Grass]]
|-
| 99 || [[Desert Flowers]]
|-
| 100 || [[Fungal Growth]]
|-
| 101 || [[Glow Trap]]
|-
| 102 || [[Small Berry Bush]]
|-
| 103 || [[Arched Cactus]]
|-
| 104 || [[Mushroom]]
|-
| 105 || [[Purple Weed]]
|-
| 106 || [[Yellow Flowers]]
|-
| 107 || [[Stone Fragment]]
|-
| 108 || [[Funal Trap]]
|-
| 109 || [[Yhole]]
|-
| 278 || [[Ice Fan Flower]]
|-
| 279 || [[Ice Crag]]
|-
| 280 || [[Ice Coral]]
|-
| 281 || [[Snowbuds]]
|}

==Out Of Use==
{|class="wikitable"
|-
| 65 || [[Death Star Core]]
|-
| 210 || [[Burnt Black Dirt]]
|-
| 72 || [[Black Dirt]]
|-
| 199 || [[Black Lava]]
|-
| 200 || [[Black Water]]
|-
| 201 || [[Black Poison]]
|-
| 208 || [[Burnt Blue Dirt ]]
|-
| 128 || [[Blue Dirt]]
|-
| 191 || [[Blue Lava]]
|-
| 192 || [[Blue Water]]
|-
| 193 || [[Blue Poison]]
|-
| 129 || [[Burnt Orange Dirt]]
|-
| 130 || [[Orange Dirt]]
|-
| 147 || [[Orange Lava]]
|-
|148 || [[Orange Water]]
|-
| 149 || [[Orange Poison]]
|-
| 134 || [[Burnt White Dirt]]
|-
| 132 || [[White Dirt]]
|-
| 167 || [[White Lava]]
|-
| 168 || [[White Water]]
|-
| 169 || [[White Poison]]
|-
| 136 || [[Burnt Purple Dirt]]
|-
| 133 || [[Purple Dirt]]
|-
| 175 || [[Purple Lava]]
|-
| 176 || [[Purple Water]]
|-
| 209 || [[Burnt Red Dirt]]
|-
| 135 || [[Red Dirt]]
|-
| 195 || [[Red Lava]]
|-
| 196 || [[Red Water]]
|-
| 197 || [[Red Poison]]
|-
| 207 || [[Burnt Green Dirt]]
|-
| 137 || [[Green Dirt]]
|-
| 187 || [[Green Lava]]
|-
| 188 || [[Green Water]]
|-
| 189 || [[Green Poison]]
|-
| 206 || [[Burnt Yellow Dirt]]
|-
| 183 || [[Yellow Lava]]
|-
| 184 || [[Yellow Water]]
|-
| 185 || [[Yellow Poison]]
|-
| 112 || [[PlexLander]]
|-
| 114 || [[Recycler]]
|-
| 131 || [[Placeholder]]
|-
| 214 || [[Capsule Refinery Enhancer]]
|-
| 216 || [[Micro Assembler Enhancer]]
|-
| 218 || [[PowerBlockFactoryEnhancer]]
|-
| 222 || [[PARTICLE PRESS]]
|-
| 255 || [[SCHEMADYNE 10000]]
|-
| 256 || [[ SCHEMADYNE 20000]]
|-
| 257 || [[SCHEMADYNE 30000]]
|-
| 258 || [[SCHEMADYNE ADVANCED]]
|-
| 260 || [[SCHEMADYNE 2000]]
|-
| 261 || [[SCHEMADYNE 3000]]
|-
| 262 || [[MINERAL SEPERATOR]]
|-
| 292 || [[Faction Hub]]
|-
| 341 || [[Bronze Bar]]
|-
| 342 || [[Silver Bar]]
|-
| 343 || [[Gold Bar]]
|}

Legacy Power Systems

2016-08-09T16:50:58Z

Olxinos: updated a couple values

This page describes the power generation and storage mechanisms in '''StarMade'''.

==Power Generation and Storage Blocks==
Power is generated using the [[Power Reactor Module]], though on ships, the [[Ship Core]] will generate 1 energy (or e) per second (called e/s) by itself. [[Planet|Planets]] and [[Space Station|Space Stations]] do not generate any power by themselves. There is a default storage amount of 50,000e on ships, but no default storage for planets and space stations. Power storage can be augmented using [[Power Capacitor|Power Capacitors]]. While these units can be placed anywhere on a ship, planet or station and contribute to either power generation or storage respectively, they are more effective when arranged according to the rules described below. This is particularly important when space is constrained as on most ships.

An important consideration regarding power capacity is that all systems use power from the '''capacity''' of a ship or station. If the instantaneous demand for power is not satisfied by the remaining capacity, then the action that is demanding the power will fail to occur. For example, one or all of the missiles that have been commanded to fire will fail to fire due to demanding more power than is currently in storage. However, the power will not be consumed by the failed action. At a minimum, a ship or station should have enough capacity to at least simultaneously fire all the weapon systems attached. Other considerations are the constant demand being made by always-active systems, and how much simultaneous demand will be made when shields begin to recharge, and thrusters need to fire. Power generation is used to refill the power capacity of a ship or station, and needs to be large enough to provide power during sustained demand. Power generation need not equal or exceed all possible demands. For example, charging a jump drive may drain the capacity faster than the power generation can refill it, but as long as the capacity is enough to charge the jump drive without being fully drained, this may be considered to be more than adequate for a given ship.

==Power Reactor Rules (Single Group Formula)==
[[Power Reactor Module|Power Reactors]] have a somewhat complex set of rules associated with them when it comes to creating efficient or compact power systems. This comes from how their power output is calculated, which is not simply by adding up the blocks and multiplying them by some power factor. Instead, the formula for a '''single''' [[Module Group|group]] of power reactors is as follows:

<tt style="font-size: large">'''GroupPower''' = BlockPower + SizePower</tt>

where:

<tt style="font-size: large">'''BlockPower''' = 25 * NumberOfBlocks</tt>

and:

<tt style="font-size: large">'''SizePower''' = 2000000 * 2 / ( 1 + 1.000348-0.333*(SumOfDimensions/3)1.7) - 2000000</tt>

'''GroupPower''' is fairly straightforward, as it is the simple sum of the other two pieces.

'''BlockPower''' is the amount of power contributed directly by the [[Power Reactor Module]]s in the group, which is just 25e per module.

'''SizePower''' is the amount of power contributed by the '''size''' of the group, and is only dependent on '''SumOfDimensions''' which is the sum of the dimensions of the smallest bounding box which can encompass the entire group. Because SumOfDimensions is a plain sum, a 3x3x3 box, 1x1x7 box and a 2x2x5 box are the same (9) for the purposes of this part of the equation. This is the part of the equation which is most important when considering how to maximize a group of reactors because SizePower is a power function, which means that each successive incremental increase in the value of SumOfDimensions gives much greater benefits than the next lower value.

Note that SizePower caps out at 2,000,000e. Also note that for multiple reactor groups, the above formula is modified, and results in a diminishing return. Total Power of a ship is not the sum of the Group Power of each group. See the [[#Power Reactor Advanced Analysis|Advanced Analysis]] section for a more detailed explanation of the equation.

Here are some examples of power reactor groups and how their power outputs are calculated.

<gallery mode="traditional" widths=300px heights=300px perrow=3 caption="Example power reactor groups and power values">
Image:Bounding Box 1.jpg|A power reactor by itself has a bounding box with dimensions 1 x 1 x 1. SumOfDimensions=3. BlockPower=25e. SizePower=115e. GroupPower=140e.
Image:Bounding Box 2.jpg|A power reactor group of 3 modules with a bounding box with dimensions 2 x 1 x 2. SumOfDimensions=5. BlockPower=75e. SizePower=276e. GroupPower=351e.
Image:Bounding Box 3.jpg|A power reactor group of 7 modules with a bounding box with dimensions 3 x 3 x 3. SumOfDimensions=9. BlockPower =175e. SizePower=750e. GroupPower=925e.
</gallery>

===Relationship between BlockPower, SizePower and TotalPower===

When there is only one power reactor block group in or on an entity, the GroupPower and the total power of the entity is identical. However, when there is more than one group, the total power provided to a ship, station or planet is ''not'' the sum of the GroupPower of all groups. Rather, '''TotalPower''' of an entity with multiple power reactor groups is subject to diminishing returns, and is given by the following formula:

<tt style="font-size: large">'''TotalPower''' = BlockPower + GroupSumSizePower</tt>

where:

<tt style="font-size: large">'''BlockPower''' = 25 * TotalNumberOfBlocksInAllGroups</tt>

and:

<tt style="font-size: large">'''GroupSumSizePower''' = 2000000 * 2 / ( 1 + 1.000348-0.333 * GroupSumPower) - 2000000</tt>

where:

<tt style="font-size:large">'''GroupSumPower''' = (SumOfDimensionsOfGroup1/3)1.7 + (SumOfDimensionsOfGroup2/3)1.7 ... + (SumOfDimensionsOfGroup''n''/3)1.7</tt>, where ''n'' is the number of groups.

To understand the relationship between SizePower, BlockPower and TotalPower, consider a 3x3x3 space in which to place a set of reactor modules. Below are three layouts in this 3x3 space. Note that values are rounded which may lead to small apparent discrepancies.

<gallery mode="traditional" widths=300px heights=300px perrow=3 caption="Example 3x3x3 layouts with power values">
Image:3x3x3Cube.jpg|A single power reactor group of 27 modules in a 3x3x3 space. BlockPower=675e. SizePower=750e. TotalPower=1425e
Image:3x3x3SingleEdge.jpg|A single power reactor group of 7 modules in a 3x3x3 space. BlockPower=175e. SizePower=750e. TotalPower=925e.
Image:3x3x3DoubleEdge.jpg|Two power reactor groups of 7 modules each (14 total modules) in a 3x3x3 space. BlockPower=350e. SizePower=1500e. TotalPower=1850e.
</gallery>

Notice that the first and second versions have the same SizePower, as SizePower depends only on the dimensions of the group and not the number of blocks. The first of course produces more total power than the second because it has more blocks and each only has a single group, but SizePower still contributes more to the total than the number of blocks does. Then look at the third version, which has the same dimensions but two groups instead of one. The SizePower is twice that of the other two because there are two groups and because SizePower counts for much more than BlockPower the TotalPower of the third version is much higher than the first one, in spite of only having half as many blocks in it (and thus a lower BlockPower).

Please note that with the very small groups in the cubic structure above, the diminishing returns of TotalPower with multiple groups is not noticeable with such small power output rounded to a whole number. But note the case of a group of 1000 power reactors in one group, 500 in one group, and finally a third case of two groups of 500, for a total of 1000 blocks.

# 1000 in one group: GroupPower/TotalPower = 1647409.7 e/sec
# 500 in one group: GroupPower/TotalPower = 683737.4 e/sec
# 1000 in two groups of 500: TotalPower = 1231567.2 e/sec, not the double of 683737.4.

===Optimal layouts===
None of the examples above are optimal layouts for the cubic 3x3x3 volume, though the third version is getting close. To create an optimal layout in a given space is rather complex, but it boils down to the following three rules:
* Maximize the SumOfDimensions for each group, because this contributes the most to the power equation through SizePower.
* Maximize the number of such groups in the space, because this allows you to take advantage of SizePower for each group
* Minimize the number of empty spaces - that is, spaces which don't contain power reactor modules - without reducing the number of groups. When doing this, be mindful of the fact that a block in a group of its own is worth 140e/s, while a block added to an existing group is only worth 25e/s if it doesn't also add to the physical size of the group.

The optimal layout for the 3x3x3 example above fills in as many spaces as possible in the cube without the two groups touching. By filling in empty spaces of the third example above, we can increase the BlockPower of each group to 250e/s, and we are left with only 7 empty spaces (6 exterior and the block in the middle is omitted). It looks like the following:

<gallery mode="traditional" widths=300px heights=300px perrow=1 caption="Optimal 3x3 reactor layout">
Image:3x3Maximized.jpg|A 3x3 cube with two reactor groups which maximizes the power output in the provided space. BlockPower=500e/s. SizePower=1499e/s TotalPower=1999e/s.
</gallery>

Once you have put in as many [[Power Reactor Module|Power Reactor Modules]] as you can into the space, you can fill the remaining spaces with any other module, except you should not use [[Power Capacitor|Power Capacitors]] because they can benefit from grouping as well, though it differs from power reactors. Using [[Shield Recharger]]s or [[Shield Capacitor|Shield Capacitors]] for this purpose is common.

Layouts need not be cube-shaped to be optimal, even though this page uses them for examples. The above 3x3x3 example is the optimal '''cubic''' structure, for the most power that can be generated in the smallest cubic volume, but does not provide the most power that can be generated for the blocks used, which is 20. The layout shape will typically be dictated by the ship or station dimensions. Keep in mind that since other shapes provide more power than a cubic volume, it is unlikely that a ship or station would be best served with a perfectly cubic power structure, even if the ship is itself a large cube.

<gallery mode="traditional" widths=900px heights=300px perrow=1 caption="Optimal maximum-output layouts">
Image:OptimalPowerStructures.jpg|Five reactor groups which maximize the power output for 20 blocks. BlockPower=500e/s. SizePower=3426.8e/s TotalPower=3926.8e/s.
</gallery>

Note that though not pictured above, a simple straight line of Power Reactor blocks is also a maximum-output layout as well.

In the picture above, the first structure on the left uses the same number of cubes as the 3x3x3 cubic power structure shown in the lower middle, but generates almost twice the power at 3926.8e/s. For 20 blocks, this is the maximum power that can be generated. However, other shapes can also achieve the same box dimension sum as the first structure. Each of the other four structures on the upper deck in the picture above '''also''' generate the maximum power of 3926.8e/s. Thus it is likely for almost any ship volume that a custom, non-cubic reactor structure will generate more power than simply using an efficient cubic volume. Furthermore, the true cubic volume of all of the structures in the image above is actually '''20'''. In other words, each of the above structures have an identical impact on the internal volume of a given ship, which is to consume 20 blocks of the ship's total internal volume, but the 3x3x3 cubic shape only generates '''half''' of the other structure's power per second.

The goal in design of a ship's power generation should be to both maximize the power reactor structure's box dimensions while also reserving large contiguous volumes within the ship for weapons and effects groups, functional areas like a core room, computer room, shuttle docking bay, or cargo hold, and usually some role-play areas, like a cockpit or command deck, medical facility, captain's quarters, corridors, elevators, etc. A cubic volume is not capable of fulfilling this goal.

Taking these things into consideration, the process for designing an optimized power system for a ship is:
# Build the largest optimized group possible within the volume of the ship. An optimized group is one in which each added power reactor always increases the block dimensions of the group.
# An allowed exception for the above rule would be, when following the inside of the hull from front to back, it might be necessary to go down before heading back up in order to go further to the back of the ship. (Some of the blocks won't increase the box-dimensions of the group, but they connect and make a contiguous group from front to back, so the group isn't optimal, but it is as close as possible while maximizing contiguous ship volume. Note that if a group consists of 100 blocks, but twenty of these blocks are connector blocks that do not increase the box-dimensions of the group, then this group should be considered as an 80-block system for purposes of calculating its SizePower, as the 20 connector blocks only add 25e/sec each, and do not increase the SizePower efficiency bonus.)
# Once the first group is laid in, if needing more e/sec, lay in parallel, un-connected groups, extending along the first group as far as possible. In most cases, it is possible to build with symmetry, thus building at least two groups at a time.
# Finally, even single reactors placed alone, unconnected, will yield 140e/sec, so filling in small pockets with single blocks is better than connecting them to existing groups if they do not also increase the box-dimensions of the group, in which case they only yield 25e/sec.

There is also a diminishing return as the e/sec of a ship approach 2 million e/sec. See the [[#Power Reactor Advanced Analysis|Advanced Analysis]] section below.

Additional optimal layouts may be found [[#Sample optimized reactor layouts|below]].

==Power Capacitor Rules==
[[Power Capacitor|Power Capacitors]] have a simpler equation governing their storage capacity, and designing layouts is subsequently vastly simpler.

<tt style="font-size: large">'''GroupPower''' = 1000 * '''NumBlocks'''1.05</tt>

Unlike [[Power Reactor Module|Power Reactor Modules]], there is no SumOfDimensions value, so the dimensions of the group are irrelevant. All that matters is how many modules are in the group. Since '''GroupPower''' is a power function again, the more blocks are in the group the more benefit the group gets from each block. This is called '''BonusPerBlock''' below. Thus, for a given number of [[Power Capacitor|Power Capacitors]] is it better to have fewer larger groups than many smaller groups.

''Ideally, a ship only has one group of Capacitors. Even if there are necessarily several clumps, they would have a line of capacitors running between them to connect them all into one group.''

Here's some sample group sizes and their value breakdowns. Note that values are rounded.

{|class="wikitable"
!NumBlocks !! GroupPower !! BonusPerBlock
|-
|1||1,000||0
|-
|2||2,071||35
|-
|3||3,169||56
|-
|4||4,287||72
|-
|5||5,419||84
|-
|6||6,562||94
|-
|7||7,715||102
|-
|8||8,877||110
|-
|9||10,045||116
|-
|10||11,220||122
|-
|50||60,802||216
|-
|100||125,893||259
|}

==Power Reactor Advanced Analysis==

This data is mostly of use for builders of large and very large ships. Even though a mid-sized ship might be able to make use of 2 million e/sec, it might not have the internal volume to make an optimized group of 800 or more power reactor modules. However, this analysis does show that small to medium ships should still try to utilize the largest optimized block structures that they can manage within the volume of their ship, as opposed to a higher number of smaller block structures, such as those used in the '''efficient cube''' structures.

The following table lists the SizePower value generated by an optimal group of blocks of the given number. Note that SizePower does not fully max out at 2,000,000 until the optimized group has 3415 blocks. An optimized group is one with the largest possible box-dimensions for the number of blocks, or a group in which no block fails to increase the box-dimensions of the group:

{|class="wikitable"
!Blocks !! Max SizePower !! BlockPower !! GroupPower !! Power/Block Ratio
|-
|25||4854.7||625.0||5479.7||219.2
|-
|50||14792.4||1250.0||16042.4||320.8
|-
|100||46492.6||2500.0||48992.6||489.9
|-
|200||148300||5000.0||153300||766.5
|-
|300||292236.1||7500.0||299736.1||999.1
|-
|400||469724.5||10000.0||479724.5||1199.3
|-
|500||671237.4||12500.0||683737.4||1367.5
|-
|600||885221.5||15000.0||900221.5||1500.4
|-
|700||1098666.6||17500.0||1116166.6||1594.5
|-
|800||1298843.6||20000.0||1318843.6||1648.6
|- style="font-style: bold; background-color: green;"
|895||1467322.0||22375||1489697.0||1664.5
|-
|900||1475480.8||22500.0||1497980.8||1664.4
|-
|1000||1622409.7||25000.0||1647409.7||1647.4
|-
|1100||1738002.7||27500.0||1765502.7||1605.0
|-
|1200||1824394.0||30000.0||1854394.0||1545.3
|-
|1300||1886032.9||32500.0||1918532.9||1475.8
|-
|1400||1928219.9||35000.0||1963219.9||1402.3
|-
|1500||1956037.9||37500.0||1993537.9||1329.0
|-
|1600||1973774.6||40000.0||2013774.6||1258.6
|-
|1700||1984741.6||42500.0||2027241.6||1192.5
|-
|1800||1991332.7||45000.0||2036332.7||1131.3
|-
|1900||1995189.4||47500.0||2042689.4||1075.1
|-
|2000||1997389.4||50000.0||2047389.4||1023.7
|-
|2100||1998614.2||52500.0||2051114.2||976.7
|-
|2200||1999280.1||55000.0||2054280.1||933.8
|-
|2300||1999633.8||57500.0||2057133.8||894.4
|-
|2400||1999817.6||60000.0||2059817.6||858.3
|-
|2500||1999911.0||62500.0||2062411.0||825.0
|-
|2600||1999957.5||65000.0||2064957.5||794.2
|-
|2700||1999980.1||67500.0||2067480.1||765.7
|-
|2800||1999990.8||70000.0||2069990.8||739.3
|-
|2900||1999995.9||72500.0||2072495.9||714.7
|-
|3000||1999998.2||75000.0||2074998.2||691.7
|-
|3100||1999999.2||77500.0||2077499.2||670.2
|-
|3200||1999999.7||80000.0||2079999.7||650.0
|-
|3300||1999999.9||82500.0||2082499.9||631.1
|-
|3400||1999999.9||85000.0||2084999.9||613.2
|-
|3415||2000000.0||85375.0||2085375.0||610.7
|}

The above table is illustrated better in the following chart:

<gallery mode="traditional" widths=600px heights=400px perrow=1 caption="Graphs of SizePower and GroupPower per Block">
Image:Max_SizePower_Curve.jpg|SizePower per optimized group of blocks of a given number, and the GroupPower per Block of each group.
</gallery>

It is easy to see that SizePower has diminishing returns after about 900 blocks. The precise number is 895. This is the number of blocks in a group that yields the largest bonus per block, 1664.5, after which it begins to fall. This is due to the S-curve shape of the SizePower graph. Consequently, if building a large ship with thousands of power reactor blocks, ''it would seem'' the power system should be composed of optimized groups of about 700 to 1000 blocks each, this range being close enough to 895 that it does not greatly affect the resulting e/sec produced by a large system. However, there is another diminishing return factor applied to multiple groups within a ship. For example, in the chart above a group of 1000 power reactors, optimally, yields 1647409.7.0 e/sec, and a group of 500 power reactors yields 683737.4 e/sec. This has been verified in-game with build '''0.199.132'''. However, using two groups of 500 power reactors does not yield double the 683737.4 e/sec value (i.e 1367474.8), but only 1231567.2 instead. Likewise, 1200 blocks would yield 1854394.0 e/sec, but two groups of 600 only yield 1510422.0 e/sec, not double the 900221.5 e/sec of one group of 600.

This diminishing return factor for groups is a soft limit which effectively limits ships to not much more than 2 million e/sec in practice. Consequently large ships are currently either limited to this value, or else use a ''docked '''power module''' daughter-ship'' and power drain beams to add more power generation capacity to a base ship.

To get to 2 million e/sec (using optimal layouts with each group):
{|class="wikitable"
!NumGroups!!GroupSize!!TotalBlocks!!MaxSizePower!!BlockPower!!TotalPower!!Power/Block
|-
|1||1528||1528||1961859.7||38250||2000059.7||1308.9
|-
|2||983||1966||1975701.3||49150||2000276.3||1017.4
|-
|3||758||2274||1981077.4||56850||2000027.4||879.5
|-
|4||631||2524||1984801.0||63100||2000576.0||792.6
|-
|6||486||2916||1988313.8||72900||2000463.8||686.0
|-
|12||311||3732||1993938.6||93300||2001713.6||536.4
|-
|18||239||4302||1996248.5||107550||2002223.5||465.4
|-
|34||158||5372||2001017.1||134300||2004967.1||373.2
|-
|52||119||6188||1999927.0||154700||2002902.0||323.7
|-
|94||80||7520||1999194.0||188000||2001194.0||266.1
|-
|253||41||10373||2008595.1||259325||2009620.1||193.7
|}

In terms of ship mass, larger groups are more efficient.

==Sample Optimized Reactor Layouts==

<gallery mode="traditional" widths=300px heights=300px perrow=2 caption="Optimal 2x2 and 3x3 reactor layouts">
Image:2x2Maximized.jpg|A 2x2 cube with two reactor groups. BlockPower=125e (100+25) SizePower=492e (376+115) TotalPower=617e
Image:3x3Maximized.jpg|A 3x3 cube with two reactor groups. BlockPower=500e (250+250) SizePower=1499e (749 + 749) TotalPower=1999e
</gallery>

<gallery mode="traditional" widths=300px heights=300px perrow=4 caption="Optimal 4x4 reactor layout">
Image:4x4MaximizedLayer1.jpg|A 4x4 cube with four reactor groups - layer 1. BlockPower=825e (100+200+250+275) SizePower=3719e (376+897+1223+1223) TotalPower=4544e
Image:4x4MaximizedLayer2.jpg|A 4x4 cube with four reactor groups - layer 2.
Image:4x4MaximizedLayer3.jpg|A 4x4 cube with four reactor groups - layer 3.
Image:4x4MaximizedLayer4.jpg|A 4x4 cube with four reactor groups - layer 4.
</gallery>

<gallery mode="traditional" widths=1000px heights=200px perrow=1 caption="Optimal 5x5 reactor layout">
Image:Power Block Compact.png|A 5x5 cube with 5 reactor groups. BlockPower=1725e (375+375+375+375+225) SizePower=8282e (1787+1787+1787+1787+1054) TotalPower=9927e
</gallery>

[[Category:Articles]]
[[Category:Game Mechanics]]

Legacy Power Systems

2016-08-09T16:32:14Z

Olxinos: forgot to remove a label

This page describes the power generation and storage mechanisms in '''StarMade'''.

==Power Generation and Storage Blocks==
Power is generated using the [[Power Reactor Module]], though on ships, the [[Ship Core]] will generate 1 energy (or e) per second (called e/s) by itself. [[Planet|Planets]] and [[Space Station|Space Stations]] do not generate any power by themselves. There is a default storage amount of 50,000e on ships, but no default storage for planets and space stations. Power storage can be augmented using [[Power Capacitor|Power Capacitors]]. While these units can be placed anywhere on a ship, planet or station and contribute to either power generation or storage respectively, they are more effective when arranged according to the rules described below. This is particularly important when space is constrained as on most ships.

An important consideration regarding power capacity is that all systems use power from the '''capacity''' of a ship or station. If the instantaneous demand for power is not satisfied by the remaining capacity, then the action that is demanding the power will fail to occur. For example, one or all of the missiles that have been commanded to fire will fail to fire due to demanding more power than is currently in storage. However, the power will not be consumed by the failed action. At a minimum, a ship or station should have enough capacity to at least simultaneously fire all the weapon systems attached. Other considerations are the constant demand being made by always-active systems, and how much simultaneous demand will be made when shields begin to recharge, and thrusters need to fire. Power generation is used to refill the power capacity of a ship or station, and needs to be large enough to provide power during sustained demand. Power generation need not equal or exceed all possible demands. For example, charging a jump drive may drain the capacity faster than the power generation can refill it, but as long as the capacity is enough to charge the jump drive without being fully drained, this may be considered to be more than adequate for a given ship.

==Power Reactor Rules (Single Group Formula)==
[[Power Reactor Module|Power Reactors]] have a somewhat complex set of rules associated with them when it comes to creating efficient or compact power systems. This comes from how their power output is calculated, which is not simply by adding up the blocks and multiplying them by some power factor. Instead, the formula for a '''single''' [[Module Group|group]] of power reactors is as follows:

<tt style="font-size: large">'''GroupPower''' = BlockPower + SizePower</tt>

where:

<tt style="font-size: large">'''BlockPower''' = 25 * NumberOfBlocks</tt>

and:

<tt style="font-size: large">'''SizePower''' = 2000000 * 2 / ( 1 + 1.000348-0.333*(SumOfDimensions/3)1.7) - 2000000</tt>

'''GroupPower''' is fairly straightforward, as it is the simple sum of the other two pieces.

'''BlockPower''' is the amount of power contributed directly by the [[Power Reactor Module]]s in the group, which is just 25e per module.

'''SizePower''' is the amount of power contributed by the '''size''' of the group, and is only dependent on '''SumOfDimensions''' which is the sum of the dimensions of the smallest bounding box which can encompass the entire group. Because SumOfDimensions is a plain sum, a 3x3x3 box, 1x1x7 box and a 2x2x5 box are the same (9) for the purposes of this part of the equation. This is the part of the equation which is most important when considering how to maximize a group of reactors because SizePower is a power function, which means that each successive incremental increase in the value of SumOfDimensions gives much greater benefits than the next lower value.

Note that SizePower caps out at 1,000,000e. Also note that for multiple reactor groups, the above formula is modified, and results in a diminishing return. Total Power of a ship is not the sum of the Group Power of each group. See the [[#Power Reactor Advanced Analysis|Advanced Analysis]] section for a more detailed explanation of the equation.

Here are some examples of power reactor groups and how their power outputs are calculated.

<gallery mode="traditional" widths=300px heights=300px perrow=3 caption="Example power reactor groups and power values">
Image:Bounding Box 1.jpg|A power reactor by itself has a bounding box with dimensions 1 x 1 x 1. SumOfDimensions=3. BlockPower=25e. SizePower=115e. GroupPower=140e.
Image:Bounding Box 2.jpg|A power reactor group of 3 modules with a bounding box with dimensions 2 x 1 x 2. SumOfDimensions=5. BlockPower=75e. SizePower=276e. GroupPower=351e.
Image:Bounding Box 3.jpg|A power reactor group of 7 modules with a bounding box with dimensions 3 x 3 x 3. SumOfDimensions=9. BlockPower =175e. SizePower=749e. GroupPower=924e.
</gallery>

===Relationship between BlockPower, SizePower and TotalPower===

When there is only one power reactor block group in or on an entity, the GroupPower and the total power of the entity is identical. However, when there is more than one group, the total power provided to a ship, station or planet is ''not'' the sum of the GroupPower of all groups. Rather, '''TotalPower''' of an entity with multiple power reactor groups is subject to diminishing returns, and is given by the following formula:

<tt style="font-size: large">'''TotalPower''' = BlockPower + GroupSumSizePower</tt>

where:

<tt style="font-size: large">'''BlockPower''' = 25 * TotalNumberOfBlocksInAllGroups</tt>

and:

<tt style="font-size: large">'''GroupSumSizePower''' = 2000000 * 2 / ( 1 + 1.000348-0.333 * GroupSumPower) - 2000000</tt>

where:

<tt style="font-size:large">'''GroupSumPower''' = (SumOfDimensionsOfGroup1/3)1.7 + (SumOfDimensionsOfGroup2/3)1.7 ... + (SumOfDimensionsOfGroup''n''/3)1.7</tt>, where ''n'' is the number of groups.

To understand the relationship between SizePower, BlockPower and TotalPower, consider a 3x3 space in which to place a set of reactor modules. Below are three layouts in this 3x3 space. Note that values are rounded which may lead to small apparent discrepancies.

<gallery mode="traditional" widths=300px heights=300px perrow=3 caption="Example 3x3 layouts with power values">
Image:3x3Cube.jpg|A single power reactor group of 27 modules in a 3x3 space. BlockPower=675e. SizePower=749e. TotalPower=1424e
Image:3x3SingleEdge.jpg|A single power reactor group of 7 modules in a 3x3 space. BlockPower=175e. SizePower=749e. TotalPower=924e.
Image:3x3DoubleEdge.jpg|Two power reactor groups of 7 modules each (14 total modules) in a 3x3 space. BlockPower=175e each (350e total). SizePower=749e each (1499e total). TotalPower=1849e.
</gallery>

Notice that the first and second versions have the same SizePower, as SizePower depends only on the dimensions of the group and not the number of blocks. The first of course produces more total power than the second because it has more blocks and each only has a single group, but SizePower still contributes more to the total than the number of blocks does. Then look at the third version, which has the same dimensions but two groups instead of one. The SizePower is twice that of the other two because there are two groups and because SizePower counts for much more than BlockPower the TotalPower of the third version is much higher than the first one, in spite of only having half as many blocks in it (and thus a lower BlockPower).

Please note that with the very small groups in the cubic structure above, the diminishing returns of TotalPower with multiple groups is not noticeable with such small power output rounded to a whole number. But note the case of a group of 1000 power reactors in one group, 500 in one group, and finally a third case of two groups of 500, for a total of 1000 blocks.

# 1000 in one group: GroupPower/TotalPower = 1003486.0 e/sec
# 500 in one group: GroupPower/TotalPower = 615706.3 e/sec
# 1000 in two groups of 500: TotalPower = 909558.9 e/sec, not the sum of 615706.3 twice.

===Optimal layouts===
None of the examples above are optimal layouts for the cubic 3x3x3 volume, though the third version is getting close. To create an optimal layout in a given space is rather complex, but it boils down to the following three rules:
* Maximize the SumOfDimensions for each group, because this contributes the most to the power equation through SizePower.
* Maximize the number of such groups in the space, because this allows you to take advantage of SizePower for each group
* Minimize the number of empty spaces - that is, spaces which don't contain power reactor modules - without reducing the number of groups. When doing this, be mindful of the fact that a block in a group of its own is worth 140e/s, while a block added to an existing group is only worth 25e/s if it doesn't also add to the physical size of the group.

The optimal layout for the 3x3 example above fills in as many spaces as possible in the cube without the two groups touching. By filling in empty spaces of the third example above, we can increase the BlockPower of each group to 250e/s, and we are left with only 7 empty spaces (6 exterior and the block in the middle is omitted). It looks like the following:

<gallery mode="traditional" widths=300px heights=300px perrow=1 caption="Optimal 3x3 reactor layout">
Image:3x3Maximized.jpg|A 3x3 cube with two reactor groups which maximizes the power output in the provided space. BlockPower=500e/s. SizePower=1499e/s TotalPower=1999e/s.
</gallery>

Once you have put in as many [[Power Reactor Module]]s as you can into the space, you can fill the remaining spaces with any other module, except you should not use [[Power Capacitor]]s because they can benefit from grouping as well, though it differs from power reactors. Using [[Shield Recharger]]s or [[Shield Capacitor|Shield Capacitors]] for this purpose is common.

Layouts need not be cube-shaped to be optimal, even though this page uses them for examples. The above 3x3x3 example is the optimal '''cubic''' structure, for the most power that can be generated in the smallest cubic volume, but does not provide the most power that can be generated for the blocks used, which is 20. The layout shape will typically be dictated by the ship or station dimensions. Keep in mind that since other shapes provide more power than a cubic volume, it is unlikely that a ship or station would be best served with a perfectly cubic power structure, even if the ship is itself a large cube.

<gallery mode="traditional" widths=900px heights=300px perrow=1 caption="Optimal maximum-output layouts">
Image:OptimalPowerStructures.jpg|Five reactor groups which maximize the power output for 20 blocks. BlockPower=500e/s. SizePower=3426.8e/s TotalPower=3926.8e/s.
</gallery>

Note that though not pictured above, a simple straight line of Power Reactor blocks is also a maximum-output layout as well.

In the picture above, the first structure on the left uses the same number of cubes as the 3x3x3 cubic power structure shown in the lower middle, but generates almost twice the power at 3926.8e/s. For 20 blocks, this is the maximum power that can be generated. However, other shapes can also achieve the same box dimension sum as the first structure. Each of the other four structures on the upper deck in the picture above '''also''' generate the maximum power of 3926.8e/s. Thus it is likely for almost any ship volume that a custom, non-cubic reactor structure will generate more power than simply using an efficient cubic volume. Furthermore, the true cubic volume of all of the structures in the image above is actually '''20'''. In other words, each of the above structures have an identical impact on the internal volume of a given ship, which is to consume 20 blocks of the ship's total internal volume, but the 3x3x3 cubic shape only generates '''half''' of the other structure's power per second.

The goal in design of a ship's power generation should be to both maximize the power reactor structure's box dimensions while also reserving large contiguous volumes within the ship for weapons and effects groups, functional areas like a core room, computer room, shuttle docking bay, or cargo hold, and usually some role-play areas, like a cockpit or command deck, medical facility, captain's quarters, corridors, elevators, etc. A cubic volume is not capable of fulfilling this goal.

Taking these things into consideration, the process for designing an optimized power system for a ship is:
# Build the largest optimized group possible within the volume of the ship. An optimized group is one in which each added power reactor always increases the block dimensions of the group.
# An allowed exception for the above rule would be, when following the inside of the hull from front to back, it might be necessary to go down before heading back up in order to go further to the back of the ship. (Some of the blocks won't increase the box-dimensions of the group, but they connect and make a contiguous group from front to back, so the group isn't optimal, but it is as close as possible while maximizing contiguous ship volume. Note that if a group consists of 100 blocks, but twenty of these blocks are connector blocks that do not increase the box-dimensions of the group, then this group should be considered as an 80-block system for purposes of calculating its SizePower, as the 20 connector blocks only add 25e/sec each, and do not increase the SizePower efficiency bonus.)
# Once the first group is laid in, if needing more e/sec, lay in parallel, un-connected groups, extending along the first group as far as possible. In most cases, it is possible to build with symmetry, thus building at least two groups at a time.
# Finally, even single reactors placed alone, unconnected, will yield 140e/sec, so filling in small pockets with single blocks is better than connecting them to existing groups if they do not also increase the box-dimensions of the group, in which case they only yield 25e/sec.

There is also a diminishing return as the e/sec of a ship approach 1 million e/sec. See the [[#Power Reactor Advanced Analysis|Advanced Analysis]] section below.

Additional optimal layouts may be found [[#Sample optimized reactor layouts|below]].

==Power Capacitor Rules==
[[Power Capacitor|Power Capacitors]] have a simpler equation governing their storage capacity, and designing layouts is subsequently vastly simpler.

<tt style="font-size: large">'''GroupPower''' = 1000 * '''NumBlocks'''1.05</tt>

Unlike [[Power Reactor Module|Power Reactor Modules]], there is no SumOfDimensions value, so the dimensions of the group are irrelevant. All that matters is how many modules are in the group. Since '''GroupPower''' is a power function again, the more blocks are in the group the more benefit the group gets from each block. This is called '''BonusPerBlock''' below. Thus, for a given number of [[Power Capacitor|Power Capacitors]] is it better to have fewer larger groups than many smaller groups.

''Ideally, a ship only has one group of Capacitors. Even if there are necessarily several clumps, they would have a line of capacitors running between them to connect them all into one group.''

Here's some sample group sizes and their value breakdowns. Note that values are rounded.

{|class="wikitable"
!NumBlocks !! GroupPower !! BonusPerBlock
|-
|1||1,000||0
|-
|2||2,071||35
|-
|3||3,169||56
|-
|4||4,287||72
|-
|5||5,419||84
|-
|6||6,562||94
|-
|7||7,715||102
|-
|8||8,877||110
|-
|9||10,045||116
|-
|10||11,220||122
|-
|50||60,802||216
|-
|100||125,893||259
|}

==Power Reactor Advanced Analysis==

This data is mostly of use for builders of large and very large ships. Even though a mid-sized ship might be able to make use of 2 million e/sec, it might not have the internal volume to make an optimized group of 800 or more power reactor modules. However, this analysis does show that small to medium ships should still try to utilize the largest optimized block structures that they can manage within the volume of their ship, as opposed to a higher number of smaller block structures, such as those used in the '''efficient cube''' structures.

The following table lists the SizePower value generated by an optimal group of blocks of the given number. Note that SizePower does not fully max out at 2,000,000 until the optimized group has 3415 blocks. An optimized group is one with the largest possible box-dimensions for the number of blocks, or a group in which no block fails to increase the box-dimensions of the group:

{|class="wikitable"
!Blocks !! Max SizePower !! BlockPower !! GroupPower !! Power/Block Ratio
|-
|25||4854.7||625.0||5479.7||219.2
|-
|50||14792.4||1250.0||16042.4||320.8
|-
|100||46492.6||2500.0||48992.6||489.9
|-
|200||148300||5000.0||153300||766.5
|-
|300||292236.1||7500.0||299736.1||999.1
|-
|400||469724.5||10000.0||479724.5||1199.3
|-
|500||671237.4||12500.0||683737.4||1367.5
|-
|600||885221.5||15000.0||900221.5||1500.4
|-
|700||1098666.6||17500.0||1116166.6||1594.5
|-
|800||1298843.6||20000.0||1318843.6||1648.6
|- style="font-style: bold; background-color: green;"
|895||1467322.0||22375||1489697.0||1664.5
|-
|900||1475480.8||22500.0||1497980.8||1664.4
|-
|1000||1622409.7||25000.0||1647409.7||1647.4
|-
|1100||1738002.7||27500.0||1765502.7||1605.0
|-
|1200||1824394.0||30000.0||1854394.0||1545.3
|-
|1300||1886032.9||32500.0||1918532.9||1475.8
|-
|1400||1928219.9||35000.0||1963219.9||1402.3
|-
|1500||1956037.9||37500.0||1993537.9||1329.0
|-
|1600||1973774.6||40000.0||2013774.6||1258.6
|-
|1700||1984741.6||42500.0||2027241.6||1192.5
|-
|1800||1991332.7||45000.0||2036332.7||1131.3
|-
|1900||1995189.4||47500.0||2042689.4||1075.1
|-
|2000||1997389.4||50000.0||2047389.4||1023.7
|-
|2100||1998614.2||52500.0||2051114.2||976.7
|-
|2200||1999280.1||55000.0||2054280.1||933.8
|-
|2300||1999633.8||57500.0||2057133.8||894.4
|-
|2400||1999817.6||60000.0||2059817.6||858.3
|-
|2500||1999911.0||62500.0||2062411.0||825.0
|-
|2600||1999957.5||65000.0||2064957.5||794.2
|-
|2700||1999980.1||67500.0||2067480.1||765.7
|-
|2800||1999990.8||70000.0||2069990.8||739.3
|-
|2900||1999995.9||72500.0||2072495.9||714.7
|-
|3000||1999998.2||75000.0||2074998.2||691.7
|-
|3100||1999999.2||77500.0||2077499.2||670.2
|-
|3200||1999999.7||80000.0||2079999.7||650.0
|-
|3300||1999999.9||82500.0||2082499.9||631.1
|-
|3400||1999999.9||85000.0||2084999.9||613.2
|-
|3415||2000000.0||85375.0||2085375.0||610.7
|}

The above table is illustrated better in the following chart:

<gallery mode="traditional" widths=600px heights=400px perrow=1 caption="Graphs of SizePower and GroupPower per Block">
Image:Max_SizePower_Curve.jpg|SizePower per optimized group of blocks of a given number, and the GroupPower per Block of each group.
</gallery>

It is easy to see that SizePower has diminishing returns after about 900 blocks. The precise number is 895. This is the number of blocks in a group that yields the largest bonus per block, 1664.5, after which it begins to fall. This is due to the S-curve shape of the SizePower graph. Consequently, if building a large ship with thousands of power reactor blocks, ''it would seem'' the power system should be composed of optimized groups of about 700 to 1000 blocks each, this range being close enough to 895 that it does not greatly affect the resulting e/sec produced by a large system. However, there is another diminishing return factor applied to multiple groups within a ship. For example, in the chart above a group of 1000 power reactors, optimally, yields 1647409.7.0 e/sec, and a group of 500 power reactors yields 683737.4 e/sec. This has been verified in-game with build '''0.199.132'''. However, using two groups of 500 power reactors does not yield double the 683737.4 e/sec value (i.e 1367474.8), but only 1231567.2 instead. Likewise, 1200 blocks would yield 1854394.0 e/sec, but two groups of 600 only yield 1510422.0 e/sec, not double the 900221.5 e/sec of one group of 600.

This diminishing return factor for groups is a soft limit which effectively limits ships to not much more than 2 million e/sec in practice. Consequently large ships are currently either limited to this value, or else use a ''docked '''power module''' daughter-ship'' and power drain beams to add more power generation capacity to a base ship.

To get to 2 million e/sec (using optimal layouts with each group):
{|class="wikitable"
!NumGroups!!GroupSize!!TotalBlocks!!MaxSizePower!!BlockPower!!TotalPower!!Power/Block
|-
|1||1528||1528||1961859.7||38250||2000059.7||1308.9
|-
|2||983||1966||1975701.3||49150||2000276.3||1017.4
|-
|3||758||2274||1981077.4||56850||2000027.4||879.5
|-
|4||631||2524||1984801.0||63100||2000576.0||792.6
|-
|6||486||2916||1988313.8||72900||2000463.8||686.0
|-
|12||311||3732||1993938.6||93300||2001713.6||536.4
|-
|18||239||4302||1996248.5||107550||2002223.5||465.4
|-
|34||158||5372||2001017.1||134300||2004967.1||373.2
|-
|52||119||6188||1999927.0||154700||2002902.0||323.7
|-
|94||80||7520||1999194.0||188000||2001194.0||266.1
|-
|253||41||10373||2008595.1||259325||2009620.1||193.7
|}

In terms of ship mass, larger groups are more efficient.

==Sample Optimized Reactor Layouts==

<gallery mode="traditional" widths=300px heights=300px perrow=2 caption="Optimal 2x2 and 3x3 reactor layouts">
Image:2x2Maximized.jpg|A 2x2 cube with two reactor groups. BlockPower=125e (100+25) SizePower=492e (376+115) TotalPower=617e
Image:3x3Maximized.jpg|A 3x3 cube with two reactor groups. BlockPower=500e (250+250) SizePower=1499e (749 + 749) TotalPower=1999e
</gallery>

<gallery mode="traditional" widths=300px heights=300px perrow=4 caption="Optimal 4x4 reactor layout">
Image:4x4MaximizedLayer1.jpg|A 4x4 cube with four reactor groups - layer 1. BlockPower=825e (100+200+250+275) SizePower=3719e (376+897+1223+1223) TotalPower=4544e
Image:4x4MaximizedLayer2.jpg|A 4x4 cube with four reactor groups - layer 2.
Image:4x4MaximizedLayer3.jpg|A 4x4 cube with four reactor groups - layer 3.
Image:4x4MaximizedLayer4.jpg|A 4x4 cube with four reactor groups - layer 4.
</gallery>

<gallery mode="traditional" widths=1000px heights=200px perrow=1 caption="Optimal 5x5 reactor layout">
Image:Power Block Compact.png|A 5x5 cube with 5 reactor groups. BlockPower=1725e (375+375+375+375+225) SizePower=8282e (1787+1787+1787+1787+1054) TotalPower=9927e
</gallery>

[[Category:Articles]]
[[Category:Game Mechanics]]

File:Max SizePower Curve.jpg

2016-08-09T16:27:26Z

Olxinos:

Legacy Power Systems

2016-08-09T15:49:33Z

Olxinos: forgot to update a couple values

This page describes the power generation and storage mechanisms in '''StarMade'''.

==Power Generation and Storage Blocks==
Power is generated using the [[Power Reactor Module]], though on ships, the [[Ship Core]] will generate 1 energy (or e) per second (called e/s) by itself. [[Planet|Planets]] and [[Space Station|Space Stations]] do not generate any power by themselves. There is a default storage amount of 50,000e on ships, but no default storage for planets and space stations. Power storage can be augmented using [[Power Capacitor|Power Capacitors]]. While these units can be placed anywhere on a ship, planet or station and contribute to either power generation or storage respectively, they are more effective when arranged according to the rules described below. This is particularly important when space is constrained as on most ships.

An important consideration regarding power capacity is that all systems use power from the '''capacity''' of a ship or station. If the instantaneous demand for power is not satisfied by the remaining capacity, then the action that is demanding the power will fail to occur. For example, one or all of the missiles that have been commanded to fire will fail to fire due to demanding more power than is currently in storage. However, the power will not be consumed by the failed action. At a minimum, a ship or station should have enough capacity to at least simultaneously fire all the weapon systems attached. Other considerations are the constant demand being made by always-active systems, and how much simultaneous demand will be made when shields begin to recharge, and thrusters need to fire. Power generation is used to refill the power capacity of a ship or station, and needs to be large enough to provide power during sustained demand. Power generation need not equal or exceed all possible demands. For example, charging a jump drive may drain the capacity faster than the power generation can refill it, but as long as the capacity is enough to charge the jump drive without being fully drained, this may be considered to be more than adequate for a given ship.

==Power Reactor Rules (Single Group Formula)==
[[Power Reactor Module|Power Reactors]] have a somewhat complex set of rules associated with them when it comes to creating efficient or compact power systems. This comes from how their power output is calculated, which is not simply by adding up the blocks and multiplying them by some power factor. Instead, the formula for a '''single''' [[Module Group|group]] of power reactors is as follows:

<tt style="font-size: large">'''GroupPower''' = BlockPower + SizePower</tt>

where:

<tt style="font-size: large">'''BlockPower''' = 25 * NumberOfBlocks</tt>

and:

<tt style="font-size: large">'''SizePower''' = 2000000 * 2 / ( 1 + 1.000348-0.333*(SumOfDimensions/3)1.7) - 2000000</tt>

'''GroupPower''' is fairly straightforward, as it is the simple sum of the other two pieces.

'''BlockPower''' is the amount of power contributed directly by the [[Power Reactor Module]]s in the group, which is just 25e per module.

'''SizePower''' is the amount of power contributed by the '''size''' of the group, and is only dependent on '''SumOfDimensions''' which is the sum of the dimensions of the smallest bounding box which can encompass the entire group. Because SumOfDimensions is a plain sum, a 3x3x3 box, 1x1x7 box and a 2x2x5 box are the same (9) for the purposes of this part of the equation. This is the part of the equation which is most important when considering how to maximize a group of reactors because SizePower is a power function, which means that each successive incremental increase in the value of SumOfDimensions gives much greater benefits than the next lower value.

Note that SizePower caps out at 1,000,000e. Also note that for multiple reactor groups, the above formula is modified, and results in a diminishing return. Total Power of a ship is not the sum of the Group Power of each group. See the [[#Power Reactor Advanced Analysis|Advanced Analysis]] section for a more detailed explanation of the equation.

Here are some examples of power reactor groups and how their power outputs are calculated.

<gallery mode="traditional" widths=300px heights=300px perrow=3 caption="Example power reactor groups and power values">
Image:Bounding Box 1.jpg|A power reactor by itself has a bounding box with dimensions 1 x 1 x 1. SumOfDimensions=3. BlockPower=25e. SizePower=115e. GroupPower=140e.
Image:Bounding Box 2.jpg|A power reactor group of 3 modules with a bounding box with dimensions 2 x 1 x 2. SumOfDimensions=5. BlockPower=75e. SizePower=276e. GroupPower=351e.
Image:Bounding Box 3.jpg|A power reactor group of 7 modules with a bounding box with dimensions 3 x 3 x 3. SumOfDimensions=9. BlockPower =175e. SizePower=749e. GroupPower=924e.
</gallery>

===Relationship between BlockPower, SizePower and TotalPower===

When there is only one power reactor block group in or on an entity, the GroupPower and the total power of the entity is identical. However, when there is more than one group, the total power provided to a ship, station or planet is ''not'' the sum of the GroupPower of all groups. Rather, '''TotalPower''' of an entity with multiple power reactor groups is subject to diminishing returns, and is given by the following formula:

<tt style="font-size: large">'''TotalPower''' = BlockPower + GroupSumSizePower</tt>

where:

<tt style="font-size: large">'''BlockPower''' = 25 * TotalNumberOfBlocksInAllGroups</tt>

and:

<tt style="font-size: large">'''GroupSumSizePower''' = 2000000 * 2 / ( 1 + 1.000348-0.333 * GroupSumPower) - 2000000</tt>

where:

<tt style="font-size:large">'''GroupSumPower''' = (SumOfDimensionsOfGroup1/3)1.7 + (SumOfDimensionsOfGroup2/3)1.7 ... + (SumOfDimensionsOfGroup''n''/3)1.7</tt>, where ''n'' is the number of groups.

To understand the relationship between SizePower, BlockPower and TotalPower, consider a 3x3 space in which to place a set of reactor modules. Below are three layouts in this 3x3 space. Note that values are rounded which may lead to small apparent discrepancies.

<gallery mode="traditional" widths=300px heights=300px perrow=3 caption="Example 3x3 layouts with power values">
Image:3x3Cube.jpg|A single power reactor group of 27 modules in a 3x3 space. BlockPower=675e. SizePower=749e. TotalPower=1424e
Image:3x3SingleEdge.jpg|A single power reactor group of 7 modules in a 3x3 space. BlockPower=175e. SizePower=749e. TotalPower=924e.
Image:3x3DoubleEdge.jpg|Two power reactor groups of 7 modules each (14 total modules) in a 3x3 space. BlockPower=175e each (350e total). SizePower=749e each (1499e total). TotalPower=1849e.
</gallery>

Notice that the first and second versions have the same SizePower, as SizePower depends only on the dimensions of the group and not the number of blocks. The first of course produces more total power than the second because it has more blocks and each only has a single group, but SizePower still contributes more to the total than the number of blocks does. Then look at the third version, which has the same dimensions but two groups instead of one. The SizePower is twice that of the other two because there are two groups and because SizePower counts for much more than BlockPower the TotalPower of the third version is much higher than the first one, in spite of only having half as many blocks in it (and thus a lower BlockPower).

Please note that with the very small groups in the cubic structure above, the diminishing returns of TotalPower with multiple groups is not noticeable with such small power output rounded to a whole number. But note the case of a group of 1000 power reactors in one group, 500 in one group, and finally a third case of two groups of 500, for a total of 1000 blocks.

# 1000 in one group: GroupPower/TotalPower = 1003486.0 e/sec
# 500 in one group: GroupPower/TotalPower = 615706.3 e/sec
# 1000 in two groups of 500: TotalPower = 909558.9 e/sec, not the sum of 615706.3 twice.

===Optimal layouts===
None of the examples above are optimal layouts for the cubic 3x3x3 volume, though the third version is getting close. To create an optimal layout in a given space is rather complex, but it boils down to the following three rules:
* Maximize the SumOfDimensions for each group, because this contributes the most to the power equation through SizePower.
* Maximize the number of such groups in the space, because this allows you to take advantage of SizePower for each group
* Minimize the number of empty spaces - that is, spaces which don't contain power reactor modules - without reducing the number of groups. When doing this, be mindful of the fact that a block in a group of its own is worth 140e/s, while a block added to an existing group is only worth 25e/s if it doesn't also add to the physical size of the group.

The optimal layout for the 3x3 example above fills in as many spaces as possible in the cube without the two groups touching. By filling in empty spaces of the third example above, we can increase the BlockPower of each group to 250e/s, and we are left with only 7 empty spaces (6 exterior and the block in the middle is omitted). It looks like the following:

<gallery mode="traditional" widths=300px heights=300px perrow=1 caption="Optimal 3x3 reactor layout">
Image:3x3Maximized.jpg|A 3x3 cube with two reactor groups which maximizes the power output in the provided space. BlockPower=500e/s. SizePower=1499e/s TotalPower=1999e/s.
</gallery>

Once you have put in as many [[Power Reactor Module]]s as you can into the space, you can fill the remaining spaces with any other module, except you should not use [[Power Capacitor]]s because they can benefit from grouping as well, though it differs from power reactors. Using [[Shield Recharger]]s or [[Shield Capacitor|Shield Capacitors]] for this purpose is common.

Layouts need not be cube-shaped to be optimal, even though this page uses them for examples. The above 3x3x3 example is the optimal '''cubic''' structure, for the most power that can be generated in the smallest cubic volume, but does not provide the most power that can be generated for the blocks used, which is 20. The layout shape will typically be dictated by the ship or station dimensions. Keep in mind that since other shapes provide more power than a cubic volume, it is unlikely that a ship or station would be best served with a perfectly cubic power structure, even if the ship is itself a large cube.

<gallery mode="traditional" widths=900px heights=300px perrow=1 caption="Optimal maximum-output layouts">
Image:OptimalPowerStructures.jpg|Five reactor groups which maximize the power output for 20 blocks. BlockPower=500e/s. SizePower=3426.8e/s TotalPower=3926.8e/s.
</gallery>

Note that though not pictured above, a simple straight line of Power Reactor blocks is also a maximum-output layout as well.

In the picture above, the first structure on the left uses the same number of cubes as the 3x3x3 cubic power structure shown in the lower middle, but generates almost twice the power at 3926.8e/s. For 20 blocks, this is the maximum power that can be generated. However, other shapes can also achieve the same box dimension sum as the first structure. Each of the other four structures on the upper deck in the picture above '''also''' generate the maximum power of 3926.8e/s. Thus it is likely for almost any ship volume that a custom, non-cubic reactor structure will generate more power than simply using an efficient cubic volume. Furthermore, the true cubic volume of all of the structures in the image above is actually '''20'''. In other words, each of the above structures have an identical impact on the internal volume of a given ship, which is to consume 20 blocks of the ship's total internal volume, but the 3x3x3 cubic shape only generates '''half''' of the other structure's power per second.

The goal in design of a ship's power generation should be to both maximize the power reactor structure's box dimensions while also reserving large contiguous volumes within the ship for weapons and effects groups, functional areas like a core room, computer room, shuttle docking bay, or cargo hold, and usually some role-play areas, like a cockpit or command deck, medical facility, captain's quarters, corridors, elevators, etc. A cubic volume is not capable of fulfilling this goal.

Taking these things into consideration, the process for designing an optimized power system for a ship is:
# Build the largest optimized group possible within the volume of the ship. An optimized group is one in which each added power reactor always increases the block dimensions of the group.
# An allowed exception for the above rule would be, when following the inside of the hull from front to back, it might be necessary to go down before heading back up in order to go further to the back of the ship. (Some of the blocks won't increase the box-dimensions of the group, but they connect and make a contiguous group from front to back, so the group isn't optimal, but it is as close as possible while maximizing contiguous ship volume. Note that if a group consists of 100 blocks, but twenty of these blocks are connector blocks that do not increase the box-dimensions of the group, then this group should be considered as an 80-block system for purposes of calculating its SizePower, as the 20 connector blocks only add 25e/sec each, and do not increase the SizePower efficiency bonus.)
# Once the first group is laid in, if needing more e/sec, lay in parallel, un-connected groups, extending along the first group as far as possible. In most cases, it is possible to build with symmetry, thus building at least two groups at a time.
# Finally, even single reactors placed alone, unconnected, will yield 140e/sec, so filling in small pockets with single blocks is better than connecting them to existing groups if they do not also increase the box-dimensions of the group, in which case they only yield 25e/sec.

There is also a diminishing return as the e/sec of a ship approach 1 million e/sec. See the [[#Power Reactor Advanced Analysis|Advanced Analysis]] section below.

Additional optimal layouts may be found [[#Sample optimized reactor layouts|below]].

==Power Capacitor Rules==
[[Power Capacitor|Power Capacitors]] have a simpler equation governing their storage capacity, and designing layouts is subsequently vastly simpler.

<tt style="font-size: large">'''GroupPower''' = 1000 * '''NumBlocks'''1.05</tt>

Unlike [[Power Reactor Module|Power Reactor Modules]], there is no SumOfDimensions value, so the dimensions of the group are irrelevant. All that matters is how many modules are in the group. Since '''GroupPower''' is a power function again, the more blocks are in the group the more benefit the group gets from each block. This is called '''BonusPerBlock''' below. Thus, for a given number of [[Power Capacitor|Power Capacitors]] is it better to have fewer larger groups than many smaller groups.

''Ideally, a ship only has one group of Capacitors. Even if there are necessarily several clumps, they would have a line of capacitors running between them to connect them all into one group.''

Here's some sample group sizes and their value breakdowns. Note that values are rounded.

{|class="wikitable"
!NumBlocks !! GroupPower !! BonusPerBlock
|-
|1||1,000||0
|-
|2||2,071||35
|-
|3||3,169||56
|-
|4||4,287||72
|-
|5||5,419||84
|-
|6||6,562||94
|-
|7||7,715||102
|-
|8||8,877||110
|-
|9||10,045||116
|-
|10||11,220||122
|-
|50||60,802||216
|-
|100||125,893||259
|}

==Power Reactor Advanced Analysis==

This data is mostly of use for builders of large and very large ships. Even though a mid-sized ship might be able to make use of 2 million e/sec, it might not have the internal volume to make an optimized group of 800 or more power reactor modules. However, this analysis does show that small to medium ships should still try to utilize the largest optimized block structures that they can manage within the volume of their ship, as opposed to a higher number of smaller block structures, such as those used in the '''efficient cube''' structures.

The following table lists the SizePower value generated by an optimal group of blocks of the given number. Note that SizePower does not fully max out at 2,000,000 until the optimized group has 3415 blocks. An optimized group is one with the largest possible box-dimensions for the number of blocks, or a group in which no block fails to increase the box-dimensions of the group:

{|class="wikitable"
!Blocks !! Max SizePower !! BlockPower !! GroupPower !! Power/Block Ratio
|-
|25||4854.7||625.0||5479.7||219.2
|-
|50||14792.4||1250.0||16042.4||320.8
|-
|100||46492.6||2500.0||48992.6||489.9
|-
|200||148300||5000.0||153300||766.5
|-
|300||292236.1||7500.0||299736.1||999.1
|-
|400||469724.5||10000.0||479724.5||1199.3
|-
|500||671237.4||12500.0||683737.4||1367.5
|-
|600||885221.5||15000.0||900221.5||1500.4
|-
|700||1098666.6||17500.0||1116166.6||1594.5
|-
|800||1298843.6||20000.0||1318843.6||1648.6
|- style="font-style: bold; background-color: green;"
|895||1467322.0||22375||1489697.0||1664.5
|-
|900||1475480.8||22500.0||1497980.8||1664.4
|-
|1000||1622409.7||25000.0||1647409.7||1647.4
|-
|1100||1738002.7||27500.0||1765502.7||1605.0
|-
|1200||1824394.0||30000.0||1854394.0||1545.3
|-
|1300||1886032.9||32500.0||1918532.9||1475.8
|-
|1400||1928219.9||35000.0||1963219.9||1402.3
|-
|1500||1956037.9||37500.0||1993537.9||1329.0
|-
|1600||1973774.6||40000.0||2013774.6||1258.6
|-
|1700||1984741.6||42500.0||2027241.6||1192.5
|-
|1800||1991332.7||45000.0||2036332.7||1131.3
|-
|1900||1995189.4||47500.0||2042689.4||1075.1
|-
|2000||1997389.4||50000.0||2047389.4||1023.7
|-
|2100||1998614.2||52500.0||2051114.2||976.7
|-
|2200||1999280.1||55000.0||2054280.1||933.8
|-
|2300||1999633.8||57500.0||2057133.8||894.4
|-
|2400||1999817.6||60000.0||2059817.6||858.3
|-
|2500||1999911.0||62500.0||2062411.0||825.0
|-
|2600||1999957.5||65000.0||2064957.5||794.2
|-
|2700||1999980.1||67500.0||2067480.1||765.7
|-
|2800||1999990.8||70000.0||2069990.8||739.3
|-
|2900||1999995.9||72500.0||2072495.9||714.7
|-
|3000||1999998.2||75000.0||2074998.2||691.7
|-
|3100||1999999.2||77500.0||2077499.2||670.2
|-
|3200||1999999.7||80000.0||2079999.7||650.0
|-
|3300||1999999.9||82500.0||2082499.9||631.1
|-
|3400||1999999.9||85000.0||2084999.9||613.2
|-
|3415||2000000.0||85375.0||2085375.0||610.7
|}

The above table is illustrated better in the following chart:

<gallery mode="traditional" widths=600px heights=400px perrow=1 caption="Graphs of SizePower and GroupPower per Block">
Image:Max_SizePower_Curve.jpg|SizePower per optimized group of blocks of a given number, and the GroupPower per Block of each group.
</gallery>

It is easy to see that SizePower has diminishing returns after about 900 blocks. The precise number is 895. This is the number of blocks in a group that yields the largest bonus per block, 1664.5, after which it begins to fall. This is due to the S-curve shape of the SizePower graph. Consequently, if building a large ship with thousands of power reactor blocks, ''it would seem'' the power system should be composed of optimized groups of about 700 to 1000 blocks each, this range being close enough to 895 that it does not greatly affect the resulting e/sec produced by a large system. However, there is another diminishing return factor applied to multiple groups within a ship. For example, in the chart above a group of 1000 power reactors, optimally, yields 1647409.7.0 e/sec, and a group of 500 power reactors yields 683737.4 e/sec. This has been verified in-game with build '''0.199.132'''. However, using two groups of 500 power reactors does not yield double the 683737.4 e/sec value (i.e 1367474.8), but only 1231567.2 instead. Likewise, 1200 blocks would yield 1854394.0 e/sec, but two groups of 600 only yield 1510422.0 e/sec, not double the 900221.5 e/sec of one group of 600.

This diminishing return factor for groups is a soft limit which effectively limits ships to not much more than 2 million e/sec in practice. Consequently large ships are currently either limited to this value, or else use a ''docked '''power module''' daughter-ship'' and power drain beams to add more power generation capacity to a base ship.

To get to 2 million e/sec (using optimal layouts with each group):
{|class="wikitable"
!NumGroups!!GroupSize!!TotalBlocks!!SumGroupX!!MaxSizePower!!BlockPower!!TotalPower!!Power/Block
|-
|1||1528||1528||1961859.7||38250||2000059.7||1308.9
|-
|2||983||1966||1975701.3||49150||2000276.3||1017.4
|-
|3||758||2274||1981077.4||56850||2000027.4||879.5
|-
|4||631||2524||1984801.0||63100||2000576.0||792.6
|-
|6||486||2916||1988313.8||72900||2000463.8||686.0
|-
|12||311||3732||1993938.6||93300||2001713.6||536.4
|-
|18||239||4302||1996248.5||107550||2002223.5||465.4
|-
|34||158||5372||2001017.1||134300||2004967.1||373.2
|-
|52||119||6188||1999927.0||154700||2002902.0||323.7
|-
|94||80||7520||1999194.0||188000||2001194.0||266.1
|-
|253||41||10373||2008595.1||259325||2009620.1||193.7
|}

In terms of ship mass, larger groups are more efficient.

==Sample Optimized Reactor Layouts==

<gallery mode="traditional" widths=300px heights=300px perrow=2 caption="Optimal 2x2 and 3x3 reactor layouts">
Image:2x2Maximized.jpg|A 2x2 cube with two reactor groups. BlockPower=125e (100+25) SizePower=492e (376+115) TotalPower=617e
Image:3x3Maximized.jpg|A 3x3 cube with two reactor groups. BlockPower=500e (250+250) SizePower=1499e (749 + 749) TotalPower=1999e
</gallery>

<gallery mode="traditional" widths=300px heights=300px perrow=4 caption="Optimal 4x4 reactor layout">
Image:4x4MaximizedLayer1.jpg|A 4x4 cube with four reactor groups - layer 1. BlockPower=825e (100+200+250+275) SizePower=3719e (376+897+1223+1223) TotalPower=4544e
Image:4x4MaximizedLayer2.jpg|A 4x4 cube with four reactor groups - layer 2.
Image:4x4MaximizedLayer3.jpg|A 4x4 cube with four reactor groups - layer 3.
Image:4x4MaximizedLayer4.jpg|A 4x4 cube with four reactor groups - layer 4.
</gallery>

<gallery mode="traditional" widths=1000px heights=200px perrow=1 caption="Optimal 5x5 reactor layout">
Image:Power Block Compact.png|A 5x5 cube with 5 reactor groups. BlockPower=1725e (375+375+375+375+225) SizePower=8282e (1787+1787+1787+1787+1054) TotalPower=9927e
</gallery>

[[Category:Articles]]
[[Category:Game Mechanics]]

Legacy Power Systems

2016-08-09T15:48:07Z

Olxinos: corrected values

This page describes the power generation and storage mechanisms in '''StarMade'''.

==Power Generation and Storage Blocks==
Power is generated using the [[Power Reactor Module]], though on ships, the [[Ship Core]] will generate 1 energy (or e) per second (called e/s) by itself. [[Planet|Planets]] and [[Space Station|Space Stations]] do not generate any power by themselves. There is a default storage amount of 50,000e on ships, but no default storage for planets and space stations. Power storage can be augmented using [[Power Capacitor|Power Capacitors]]. While these units can be placed anywhere on a ship, planet or station and contribute to either power generation or storage respectively, they are more effective when arranged according to the rules described below. This is particularly important when space is constrained as on most ships.

An important consideration regarding power capacity is that all systems use power from the '''capacity''' of a ship or station. If the instantaneous demand for power is not satisfied by the remaining capacity, then the action that is demanding the power will fail to occur. For example, one or all of the missiles that have been commanded to fire will fail to fire due to demanding more power than is currently in storage. However, the power will not be consumed by the failed action. At a minimum, a ship or station should have enough capacity to at least simultaneously fire all the weapon systems attached. Other considerations are the constant demand being made by always-active systems, and how much simultaneous demand will be made when shields begin to recharge, and thrusters need to fire. Power generation is used to refill the power capacity of a ship or station, and needs to be large enough to provide power during sustained demand. Power generation need not equal or exceed all possible demands. For example, charging a jump drive may drain the capacity faster than the power generation can refill it, but as long as the capacity is enough to charge the jump drive without being fully drained, this may be considered to be more than adequate for a given ship.

==Power Reactor Rules (Single Group Formula)==
[[Power Reactor Module|Power Reactors]] have a somewhat complex set of rules associated with them when it comes to creating efficient or compact power systems. This comes from how their power output is calculated, which is not simply by adding up the blocks and multiplying them by some power factor. Instead, the formula for a '''single''' [[Module Group|group]] of power reactors is as follows:

<tt style="font-size: large">'''GroupPower''' = BlockPower + SizePower</tt>

where:

<tt style="font-size: large">'''BlockPower''' = 25 * NumberOfBlocks</tt>

and:

<tt style="font-size: large">'''SizePower''' = 2000000 * 2 / ( 1 + 1.000348-0.333*(SumOfDimensions/3)1.7) - 2000000</tt>

'''GroupPower''' is fairly straightforward, as it is the simple sum of the other two pieces.

'''BlockPower''' is the amount of power contributed directly by the [[Power Reactor Module]]s in the group, which is just 25e per module.

'''SizePower''' is the amount of power contributed by the '''size''' of the group, and is only dependent on '''SumOfDimensions''' which is the sum of the dimensions of the smallest bounding box which can encompass the entire group. Because SumOfDimensions is a plain sum, a 3x3x3 box, 1x1x7 box and a 2x2x5 box are the same (9) for the purposes of this part of the equation. This is the part of the equation which is most important when considering how to maximize a group of reactors because SizePower is a power function, which means that each successive incremental increase in the value of SumOfDimensions gives much greater benefits than the next lower value.

Note that SizePower caps out at 1,000,000e. Also note that for multiple reactor groups, the above formula is modified, and results in a diminishing return. Total Power of a ship is not the sum of the Group Power of each group. See the [[#Power Reactor Advanced Analysis|Advanced Analysis]] section for a more detailed explanation of the equation.

Here are some examples of power reactor groups and how their power outputs are calculated.

<gallery mode="traditional" widths=300px heights=300px perrow=3 caption="Example power reactor groups and power values">
Image:Bounding Box 1.jpg|A power reactor by itself has a bounding box with dimensions 1 x 1 x 1. SumOfDimensions=3. BlockPower=25e. SizePower=115e. GroupPower=140e.
Image:Bounding Box 2.jpg|A power reactor group of 3 modules with a bounding box with dimensions 2 x 1 x 2. SumOfDimensions=5. BlockPower=75e. SizePower=276e. GroupPower=351e.
Image:Bounding Box 3.jpg|A power reactor group of 7 modules with a bounding box with dimensions 3 x 3 x 3. SumOfDimensions=9. BlockPower =175e. SizePower=749e. GroupPower=924e.
</gallery>

===Relationship between BlockPower, SizePower and TotalPower===

When there is only one power reactor block group in or on an entity, the GroupPower and the total power of the entity is identical. However, when there is more than one group, the total power provided to a ship, station or planet is ''not'' the sum of the GroupPower of all groups. Rather, '''TotalPower''' of an entity with multiple power reactor groups is subject to diminishing returns, and is given by the following formula:

<tt style="font-size: large">'''TotalPower''' = BlockPower + GroupSumSizePower</tt>

where:

<tt style="font-size: large">'''BlockPower''' = 25 * TotalNumberOfBlocksInAllGroups</tt>

and:

<tt style="font-size: large">'''GroupSumSizePower''' = 2000000 * 2 / ( 1 + 1.000348-0.333 * GroupSumPower) - 2000000</tt>

where:

<tt style="font-size:large">'''GroupSumPower''' = (SumOfDimensionsOfGroup1/3)1.7 + (SumOfDimensionsOfGroup2/3)1.7 ... + (SumOfDimensionsOfGroup''n''/3)1.7</tt>, where ''n'' is the number of groups.

To understand the relationship between SizePower, BlockPower and TotalPower, consider a 3x3 space in which to place a set of reactor modules. Below are three layouts in this 3x3 space. Note that values are rounded which may lead to small apparent discrepancies.

<gallery mode="traditional" widths=300px heights=300px perrow=3 caption="Example 3x3 layouts with power values">
Image:3x3Cube.jpg|A single power reactor group of 27 modules in a 3x3 space. BlockPower=675e. SizePower=749e. TotalPower=1424e
Image:3x3SingleEdge.jpg|A single power reactor group of 7 modules in a 3x3 space. BlockPower=175e. SizePower=749e. TotalPower=924e.
Image:3x3DoubleEdge.jpg|Two power reactor groups of 7 modules each (14 total modules) in a 3x3 space. BlockPower=175e each (350e total). SizePower=749e each (1499e total). TotalPower=1849e.
</gallery>

Notice that the first and second versions have the same SizePower, as SizePower depends only on the dimensions of the group and not the number of blocks. The first of course produces more total power than the second because it has more blocks and each only has a single group, but SizePower still contributes more to the total than the number of blocks does. Then look at the third version, which has the same dimensions but two groups instead of one. The SizePower is twice that of the other two because there are two groups and because SizePower counts for much more than BlockPower the TotalPower of the third version is much higher than the first one, in spite of only having half as many blocks in it (and thus a lower BlockPower).

Please note that with the very small groups in the cubic structure above, the diminishing returns of TotalPower with multiple groups is not noticeable with such small power output rounded to a whole number. But note the case of a group of 1000 power reactors in one group, 500 in one group, and finally a third case of two groups of 500, for a total of 1000 blocks.

# 1000 in one group: GroupPower/TotalPower = 1003486.0 e/sec
# 500 in one group: GroupPower/TotalPower = 615706.3 e/sec
# 1000 in two groups of 500: TotalPower = 909558.9 e/sec, not the sum of 615706.3 twice.

===Optimal layouts===
None of the examples above are optimal layouts for the cubic 3x3x3 volume, though the third version is getting close. To create an optimal layout in a given space is rather complex, but it boils down to the following three rules:
* Maximize the SumOfDimensions for each group, because this contributes the most to the power equation through SizePower.
* Maximize the number of such groups in the space, because this allows you to take advantage of SizePower for each group
* Minimize the number of empty spaces - that is, spaces which don't contain power reactor modules - without reducing the number of groups. When doing this, be mindful of the fact that a block in a group of its own is worth 140e/s, while a block added to an existing group is only worth 25e/s if it doesn't also add to the physical size of the group.

The optimal layout for the 3x3 example above fills in as many spaces as possible in the cube without the two groups touching. By filling in empty spaces of the third example above, we can increase the BlockPower of each group to 250e/s, and we are left with only 7 empty spaces (6 exterior and the block in the middle is omitted). It looks like the following:

<gallery mode="traditional" widths=300px heights=300px perrow=1 caption="Optimal 3x3 reactor layout">
Image:3x3Maximized.jpg|A 3x3 cube with two reactor groups which maximizes the power output in the provided space. BlockPower=500e/s. SizePower=1499e/s TotalPower=1999e/s.
</gallery>

Once you have put in as many [[Power Reactor Module]]s as you can into the space, you can fill the remaining spaces with any other module, except you should not use [[Power Capacitor]]s because they can benefit from grouping as well, though it differs from power reactors. Using [[Shield Recharger]]s or [[Shield Capacitor|Shield Capacitors]] for this purpose is common.

Layouts need not be cube-shaped to be optimal, even though this page uses them for examples. The above 3x3x3 example is the optimal '''cubic''' structure, for the most power that can be generated in the smallest cubic volume, but does not provide the most power that can be generated for the blocks used, which is 20. The layout shape will typically be dictated by the ship or station dimensions. Keep in mind that since other shapes provide more power than a cubic volume, it is unlikely that a ship or station would be best served with a perfectly cubic power structure, even if the ship is itself a large cube.

<gallery mode="traditional" widths=900px heights=300px perrow=1 caption="Optimal maximum-output layouts">
Image:OptimalPowerStructures.jpg|Five reactor groups which maximize the power output for 20 blocks. BlockPower=500e/s. SizePower=3426.8e/s TotalPower=3926.8e/s.
</gallery>

Note that though not pictured above, a simple straight line of Power Reactor blocks is also a maximum-output layout as well.

In the picture above, the first structure on the left uses the same number of cubes as the 3x3x3 cubic power structure shown in the lower middle, but generates almost twice the power at 3926.8e/s. For 20 blocks, this is the maximum power that can be generated. However, other shapes can also achieve the same box dimension sum as the first structure. Each of the other four structures on the upper deck in the picture above '''also''' generate the maximum power of 3926.8e/s. Thus it is likely for almost any ship volume that a custom, non-cubic reactor structure will generate more power than simply using an efficient cubic volume. Furthermore, the true cubic volume of all of the structures in the image above is actually '''20'''. In other words, each of the above structures have an identical impact on the internal volume of a given ship, which is to consume 20 blocks of the ship's total internal volume, but the 3x3x3 cubic shape only generates '''half''' of the other structure's power per second.

The goal in design of a ship's power generation should be to both maximize the power reactor structure's box dimensions while also reserving large contiguous volumes within the ship for weapons and effects groups, functional areas like a core room, computer room, shuttle docking bay, or cargo hold, and usually some role-play areas, like a cockpit or command deck, medical facility, captain's quarters, corridors, elevators, etc. A cubic volume is not capable of fulfilling this goal.

Taking these things into consideration, the process for designing an optimized power system for a ship is:
# Build the largest optimized group possible within the volume of the ship. An optimized group is one in which each added power reactor always increases the block dimensions of the group.
# An allowed exception for the above rule would be, when following the inside of the hull from front to back, it might be necessary to go down before heading back up in order to go further to the back of the ship. (Some of the blocks won't increase the box-dimensions of the group, but they connect and make a contiguous group from front to back, so the group isn't optimal, but it is as close as possible while maximizing contiguous ship volume. Note that if a group consists of 100 blocks, but twenty of these blocks are connector blocks that do not increase the box-dimensions of the group, then this group should be considered as an 80-block system for purposes of calculating its SizePower, as the 20 connector blocks only add 25e/sec each, and do not increase the SizePower efficiency bonus.)
# Once the first group is laid in, if needing more e/sec, lay in parallel, un-connected groups, extending along the first group as far as possible. In most cases, it is possible to build with symmetry, thus building at least two groups at a time.
# Finally, even single reactors placed alone, unconnected, will yield 140e/sec, so filling in small pockets with single blocks is better than connecting them to existing groups if they do not also increase the box-dimensions of the group, in which case they only yield 25e/sec.

There is also a diminishing return as the e/sec of a ship approach 1 million e/sec. See the [[#Power Reactor Advanced Analysis|Advanced Analysis]] section below.

Additional optimal layouts may be found [[#Sample optimized reactor layouts|below]].

==Power Capacitor Rules==
[[Power Capacitor|Power Capacitors]] have a simpler equation governing their storage capacity, and designing layouts is subsequently vastly simpler.

<tt style="font-size: large">'''GroupPower''' = 1000 * '''NumBlocks'''1.05</tt>

Unlike [[Power Reactor Module|Power Reactor Modules]], there is no SumOfDimensions value, so the dimensions of the group are irrelevant. All that matters is how many modules are in the group. Since '''GroupPower''' is a power function again, the more blocks are in the group the more benefit the group gets from each block. This is called '''BonusPerBlock''' below. Thus, for a given number of [[Power Capacitor|Power Capacitors]] is it better to have fewer larger groups than many smaller groups.

''Ideally, a ship only has one group of Capacitors. Even if there are necessarily several clumps, they would have a line of capacitors running between them to connect them all into one group.''

Here's some sample group sizes and their value breakdowns. Note that values are rounded.

{|class="wikitable"
!NumBlocks !! GroupPower !! BonusPerBlock
|-
|1||1,000||0
|-
|2||2,071||35
|-
|3||3,169||56
|-
|4||4,287||72
|-
|5||5,419||84
|-
|6||6,562||94
|-
|7||7,715||102
|-
|8||8,877||110
|-
|9||10,045||116
|-
|10||11,220||122
|-
|50||60,802||216
|-
|100||125,893||259
|}

==Power Reactor Advanced Analysis==

This data is mostly of use for builders of large and very large ships. Even though a mid-sized ship might be able to make use of 1 million e/sec, it might not have the internal volume to make an optimized group of 500 or more power reactor modules. However, this analysis does show that small to medium ships should still try to utilize the largest optimized block structures that they can manage within the volume of their ship, as opposed to a higher number of smaller block structures, such as those used in the '''efficient cube''' structures.

The following table lists the SizePower value generated by an optimal group of blocks of the given number. Note that SizePower does not fully max out at 1,000,000 until the optimized group has 3374 blocks. An optimized group is one with the largest possible box-dimensions for the number of blocks, or a group in which no block fails to increase the box-dimensions of the group:

{|class="wikitable"
!Blocks !! Max SizePower !! BlockPower !! GroupPower !! Power/Block Ratio
|-
|25||4854.7||625.0||5479.7||219.2
|-
|50||14792.4||1250.0||16042.4||320.8
|-
|100||46492.6||2500.0||48992.6||489.9
|-
|200||148300||5000.0||153300||766.5
|-
|300||292236.1||7500.0||299736.1||999.1
|-
|400||469724.5||10000.0||479724.5||1199.3
|-
|500||671237.4||12500.0||683737.4||1367.5
|-
|600||885221.5||15000.0||900221.5||1500.4
|-
|700||1098666.6||17500.0||1116166.6||1594.5
|-
|800||1298843.6||20000.0||1318843.6||1648.6
|- style="font-style: bold; background-color: green;"
|895||1467322.0||22375||1489697.0||1664.5
|-
|900||1475480.8||22500.0||1497980.8||1664.4
|-
|1000||1622409.7||25000.0||1647409.7||1647.4
|-
|1100||1738002.7||27500.0||1765502.7||1605.0
|-
|1200||1824394.0||30000.0||1854394.0||1545.3
|-
|1300||1886032.9||32500.0||1918532.9||1475.8
|-
|1400||1928219.9||35000.0||1963219.9||1402.3
|-
|1500||1956037.9||37500.0||1993537.9||1329.0
|-
|1600||1973774.6||40000.0||2013774.6||1258.6
|-
|1700||1984741.6||42500.0||2027241.6||1192.5
|-
|1800||1991332.7||45000.0||2036332.7||1131.3
|-
|1900||1995189.4||47500.0||2042689.4||1075.1
|-
|2000||1997389.4||50000.0||2047389.4||1023.7
|-
|2100||1998614.2||52500.0||2051114.2||976.7
|-
|2200||1999280.1||55000.0||2054280.1||933.8
|-
|2300||1999633.8||57500.0||2057133.8||894.4
|-
|2400||1999817.6||60000.0||2059817.6||858.3
|-
|2500||1999911.0||62500.0||2062411.0||825.0
|-
|2600||1999957.5||65000.0||2064957.5||794.2
|-
|2700||1999980.1||67500.0||2067480.1||765.7
|-
|2800||1999990.8||70000.0||2069990.8||739.3
|-
|2900||1999995.9||72500.0||2072495.9||714.7
|-
|3000||1999998.2||75000.0||2074998.2||691.7
|-
|3100||1999999.2||77500.0||2077499.2||670.2
|-
|3200||1999999.7||80000.0||2079999.7||650.0
|-
|3300||1999999.9||82500.0||2082499.9||631.1
|-
|3400||1999999.9||85000.0||2084999.9||613.2
|-
|3415||2000000.0||85375.0||2085375.0||610.7
|}

The above table is illustrated better in the following chart:

<gallery mode="traditional" widths=600px heights=400px perrow=1 caption="Graphs of SizePower and GroupPower per Block">
Image:Max_SizePower_Curve.jpg|SizePower per optimized group of blocks of a given number, and the GroupPower per Block of each group.
</gallery>

It is easy to see that SizePower has diminishing returns after about 900 blocks. The precise number is 895. This is the number of blocks in a group that yields the largest bonus per block, 1664.5, after which it begins to fall. This is due to the S-curve shape of the SizePower graph. Consequently, if building a large ship with thousands of power reactor blocks, ''it would seem'' the power system should be composed of optimized groups of about 700 to 1000 blocks each, this range being close enough to 895 that it does not greatly affect the resulting e/sec produced by a large system. However, there is another diminishing return factor applied to multiple groups within a ship. For example, in the chart above a group of 1000 power reactors, optimally, yields 1647409.7.0 e/sec, and a group of 500 power reactors yields 683737.4 e/sec. This has been verified in-game with build '''0.199.132'''. However, using two groups of 500 power reactors does not yield double the 683737.4 e/sec value (i.e 1367474.8), but only 1231567.2 instead. Likewise, 1200 blocks would yield 1854394.0 e/sec, but two groups of 600 only yield 1510422.0 e/sec, not double the 900221.5 e/sec of one group of 600.

This diminishing return factor for groups is a soft limit which effectively limits ships to not much more than 2 million e/sec in practice. Consequently large ships are currently either limited to this value, or else use a ''docked '''power module''' daughter-ship'' and power drain beams to add more power generation capacity to a base ship.

To get to 2 million e/sec (using optimal layouts with each group):
{|class="wikitable"
!NumGroups!!GroupSize!!TotalBlocks!!SumGroupX!!MaxSizePower!!BlockPower!!TotalPower!!Power/Block
|-
|1||1528||1528||1961859.7||38250||2000059.7||1308.9
|-
|2||983||1966||1975701.3||49150||2000276.3||1017.4
|-
|3||758||2274||1981077.4||56850||2000027.4||879.5
|-
|4||631||2524||1984801.0||63100||2000576.0||792.6
|-
|6||486||2916||1988313.8||72900||2000463.8||686.0
|-
|12||311||3732||1993938.6||93300||2001713.6||536.4
|-
|18||239||4302||1996248.5||107550||2002223.5||465.4
|-
|34||158||5372||2001017.1||134300||2004967.1||373.2
|-
|52||119||6188||1999927.0||154700||2002902.0||323.7
|-
|94||80||7520||1999194.0||188000||2001194.0||266.1
|-
|253||41||10373||2008595.1||259325||2009620.1||193.7
|}

In terms of ship mass, larger groups are more efficient.

==Sample Optimized Reactor Layouts==

<gallery mode="traditional" widths=300px heights=300px perrow=2 caption="Optimal 2x2 and 3x3 reactor layouts">
Image:2x2Maximized.jpg|A 2x2 cube with two reactor groups. BlockPower=125e (100+25) SizePower=492e (376+115) TotalPower=617e
Image:3x3Maximized.jpg|A 3x3 cube with two reactor groups. BlockPower=500e (250+250) SizePower=1499e (749 + 749) TotalPower=1999e
</gallery>

<gallery mode="traditional" widths=300px heights=300px perrow=4 caption="Optimal 4x4 reactor layout">
Image:4x4MaximizedLayer1.jpg|A 4x4 cube with four reactor groups - layer 1. BlockPower=825e (100+200+250+275) SizePower=3719e (376+897+1223+1223) TotalPower=4544e
Image:4x4MaximizedLayer2.jpg|A 4x4 cube with four reactor groups - layer 2.
Image:4x4MaximizedLayer3.jpg|A 4x4 cube with four reactor groups - layer 3.
Image:4x4MaximizedLayer4.jpg|A 4x4 cube with four reactor groups - layer 4.
</gallery>

<gallery mode="traditional" widths=1000px heights=200px perrow=1 caption="Optimal 5x5 reactor layout">
Image:Power Block Compact.png|A 5x5 cube with 5 reactor groups. BlockPower=1725e (375+375+375+375+225) SizePower=8282e (1787+1787+1787+1787+1054) TotalPower=9927e
</gallery>

[[Category:Articles]]
[[Category:Game Mechanics]]

Legacy Power Systems

2016-08-06T16:52:54Z

Olxinos: /* Power Reactor Rules (Single Group Formula) */

This page describes the power generation and storage mechanisms in '''StarMade'''.

==Power Generation and Storage Blocks==
Power is generated using the [[Power Reactor Module]], though on ships, the [[Ship Core]] will generate 1 energy (or e) per second (called e/s) by itself. [[Planet|Planets]] and [[Space Station|Space Stations]] do not generate any power by themselves. There is a default storage amount of 50,000e on ships, but no default storage for planets and space stations. Power storage can be augmented using [[Power Capacitor|Power Capacitors]]. While these units can be placed anywhere on a ship, planet or station and contribute to either power generation or storage respectively, they are more effective when arranged according to the rules described below. This is particularly important when space is constrained as on most ships.

An important consideration regarding power capacity is that all systems use power from the '''capacity''' of a ship or station. If the instantaneous demand for power is not satisfied by the remaining capacity, then the action that is demanding the power will fail to occur. For example, one or all of the missiles that have been commanded to fire will fail to fire due to demanding more power than is currently in storage. However, the power will not be consumed by the failed action. At a minimum, a ship or station should have enough capacity to at least simultaneously fire all the weapon systems attached. Other considerations are the constant demand being made by always-active systems, and how much simultaneous demand will be made when shields begin to recharge, and thrusters need to fire. Power generation is used to refill the power capacity of a ship or station, and needs to be large enough to provide power during sustained demand. Power generation need not equal or exceed all possible demands. For example, charging a jump drive may drain the capacity faster than the power generation can refill it, but as long as the capacity is enough to charge the jump drive without being fully drained, this may be considered to be more than adequate for a given ship.

==Power Reactor Rules (Single Group Formula)==
[[Power Reactor Module|Power Reactors]] have a somewhat complex set of rules associated with them when it comes to creating efficient or compact power systems. This comes from how their power output is calculated, which is not simply by adding up the blocks and multiplying them by some power factor. Instead, the formula for a '''single''' [[Module Group|group]] of power reactors is as follows:

<tt style="font-size: large">'''GroupPower''' = BlockPower + SizePower</tt>

where:

<tt style="font-size: large">'''BlockPower''' = 25 * NumberOfBlocks</tt>

and:

<tt style="font-size: large">'''SizePower''' = 2000000 * 2 / ( 1 + 1.000348-0.333*(SumOfDimensions/3)1.7) - 2000000</tt>

'''GroupPower''' is fairly straightforward, as it is the simple sum of the other two pieces.

'''BlockPower''' is the amount of power contributed directly by the [[Power Reactor Module]]s in the group, which is just 25e per module.

'''SizePower''' is the amount of power contributed by the '''size''' of the group, and is only dependent on '''SumOfDimensions''' which is the sum of the dimensions of the smallest bounding box which can encompass the entire group. Because SumOfDimensions is a plain sum, a 3x3x3 box, 1x1x7 box and a 2x2x5 box are the same (9) for the purposes of this part of the equation. This is the part of the equation which is most important when considering how to maximize a group of reactors because SizePower is a power function, which means that each successive incremental increase in the value of SumOfDimensions gives much greater benefits than the next lower value.

Note that SizePower caps out at 1,000,000e. Also note that for multiple reactor groups, the above formula is modified, and results in a diminishing return. Total Power of a ship is not the sum of the Group Power of each group. See the [[#Power Reactor Advanced Analysis|Advanced Analysis]] section for a more detailed explanation of the equation.

Here are some examples of power reactor groups and how their power outputs are calculated.

<gallery mode="traditional" widths=300px heights=300px perrow=3 caption="Example power reactor groups and power values">
Image:Bounding Box 1.jpg|A power reactor by itself has a bounding box with dimensions 1 x 1 x 1. SumOfDimensions=3. BlockPower=25e. SizePower=115e. GroupPower=140e.
Image:Bounding Box 2.jpg|A power reactor group of 3 modules with a bounding box with dimensions 2 x 1 x 2. SumOfDimensions=5. BlockPower=75e. SizePower=276e. GroupPower=351e.
Image:Bounding Box 3.jpg|A power reactor group of 7 modules with a bounding box with dimensions 3 x 3 x 3. SumOfDimensions=9. BlockPower =175e. SizePower=749e. GroupPower=924e.
</gallery>

===Relationship between BlockPower, SizePower and TotalPower===

When there is only one power reactor block group in or on an entity, the GroupPower and the total power of the entity is identical. However, when there is more than one group, the total power provided to a ship, station or planet is ''not'' the sum of the GroupPower of all groups. Rather, '''TotalPower''' of an entity with multiple power reactor groups is subject to diminishing returns, and is given by the following formula:

<tt style="font-size: large">'''TotalPower''' = BlockPower + GroupSumSizePower</tt>

where:

<tt style="font-size: large">'''BlockPower''' = 25 * TotalNumberOfBlocksInAllGroups</tt>

and:

<tt style="font-size: large">'''GroupSumSizePower''' = 2000000 * 2 / ( 1 + 1.000348-0.333 * GroupSumPower) - 2000000</tt>

where:

<tt style="font-size:large">'''GroupSumPower''' = (SumOfDimensionsOfGroup1/3)1.7 + (SumOfDimensionsOfGroup2/3)1.7 ... + (SumOfDimensionsOfGroup''n''/3)1.7</tt>, where ''n'' is the number of groups.

To understand the relationship between SizePower, BlockPower and TotalPower, consider a 3x3 space in which to place a set of reactor modules. Below are three layouts in this 3x3 space. Note that values are rounded which may lead to small apparent discrepancies.

<gallery mode="traditional" widths=300px heights=300px perrow=3 caption="Example 3x3 layouts with power values">
Image:3x3Cube.jpg|A single power reactor group of 27 modules in a 3x3 space. BlockPower=675e. SizePower=749e. TotalPower=1424e
Image:3x3SingleEdge.jpg|A single power reactor group of 7 modules in a 3x3 space. BlockPower=175e. SizePower=749e. TotalPower=924e.
Image:3x3DoubleEdge.jpg|Two power reactor groups of 7 modules each (14 total modules) in a 3x3 space. BlockPower=175e each (350e total). SizePower=749e each (1499e total). TotalPower=1849e.
</gallery>

Notice that the first and second versions have the same SizePower, as SizePower depends only on the dimensions of the group and not the number of blocks. The first of course produces more total power than the second because it has more blocks and each only has a single group, but SizePower still contributes more to the total than the number of blocks does. Then look at the third version, which has the same dimensions but two groups instead of one. The SizePower is twice that of the other two because there are two groups and because SizePower counts for much more than BlockPower the TotalPower of the third version is much higher than the first one, in spite of only having half as many blocks in it (and thus a lower BlockPower).

Please note that with the very small groups in the cubic structure above, the diminishing returns of TotalPower with multiple groups is not noticeable with such small power output rounded to a whole number. But note the case of a group of 1000 power reactors in one group, 500 in one group, and finally a third case of two groups of 500, for a total of 1000 blocks.

# 1000 in one group: GroupPower/TotalPower = 1003486.0 e/sec
# 500 in one group: GroupPower/TotalPower = 615706.3 e/sec
# 1000 in two groups of 500: TotalPower = 909558.9 e/sec, not the sum of 615706.3 twice.

===Optimal layouts===
None of the examples above are optimal layouts for the cubic 3x3x3 volume, though the third version is getting close. To create an optimal layout in a given space is rather complex, but it boils down to the following three rules:
* Maximize the SumOfDimensions for each group, because this contributes the most to the power equation through SizePower.
* Maximize the number of such groups in the space, because this allows you to take advantage of SizePower for each group
* Minimize the number of empty spaces - that is, spaces which don't contain power reactor modules - without reducing the number of groups. When doing this, be mindful of the fact that a block in a group of its own is worth 140e/s, while a block added to an existing group is only worth 25e/s if it doesn't also add to the physical size of the group.

The optimal layout for the 3x3 example above fills in as many spaces as possible in the cube without the two groups touching. By filling in empty spaces of the third example above, we can increase the BlockPower of each group to 250e/s, and we are left with only 7 empty spaces (6 exterior and the block in the middle is omitted). It looks like the following:

<gallery mode="traditional" widths=300px heights=300px perrow=1 caption="Optimal 3x3 reactor layout">
Image:3x3Maximized.jpg|A 3x3 cube with two reactor groups which maximizes the power output in the provided space. BlockPower=500e/s. SizePower=1499e/s TotalPower=1999e/s.
</gallery>

Once you have put in as many [[Power Reactor Module]]s as you can into the space, you can fill the remaining spaces with any other module, except you should not use [[Power Capacitor]]s because they can benefit from grouping as well, though it differs from power reactors. Using [[Shield Recharger]]s or [[Shield Capacitor|Shield Capacitors]] for this purpose is common.

Layouts need not be cube-shaped to be optimal, even though this page uses them for examples. The above 3x3x3 example is the optimal '''cubic''' structure, for the most power that can be generated in the smallest cubic volume, but does not provide the most power that can be generated for the blocks used, which is 20. The layout shape will typically be dictated by the ship or station dimensions. Keep in mind that since other shapes provide more power than a cubic volume, it is unlikely that a ship or station would be best served with a perfectly cubic power structure, even if the ship is itself a large cube.

<gallery mode="traditional" widths=900px heights=300px perrow=1 caption="Optimal maximum-output layouts">
Image:OptimalPowerStructures.jpg|Five reactor groups which maximize the power output for 20 blocks. BlockPower=500e/s. SizePower=3426.8e/s TotalPower=3926.8e/s.
</gallery>

Note that though not pictured above, a simple straight line of Power Reactor blocks is also a maximum-output layout as well.

In the picture above, the first structure on the left uses the same number of cubes as the 3x3x3 cubic power structure shown in the lower middle, but generates almost twice the power at 3926.8e/s. For 20 blocks, this is the maximum power that can be generated. However, other shapes can also achieve the same box dimension sum as the first structure. Each of the other four structures on the upper deck in the picture above '''also''' generate the maximum power of 3926.8e/s. Thus it is likely for almost any ship volume that a custom, non-cubic reactor structure will generate more power than simply using an efficient cubic volume. Furthermore, the true cubic volume of all of the structures in the image above is actually '''20'''. In other words, each of the above structures have an identical impact on the internal volume of a given ship, which is to consume 20 blocks of the ship's total internal volume, but the 3x3x3 cubic shape only generates '''half''' of the other structure's power per second.

The goal in design of a ship's power generation should be to both maximize the power reactor structure's box dimensions while also reserving large contiguous volumes within the ship for weapons and effects groups, functional areas like a core room, computer room, shuttle docking bay, or cargo hold, and usually some role-play areas, like a cockpit or command deck, medical facility, captain's quarters, corridors, elevators, etc. A cubic volume is not capable of fulfilling this goal.

Taking these things into consideration, the process for designing an optimized power system for a ship is:
# Build the largest optimized group possible within the volume of the ship. An optimized group is one in which each added power reactor always increases the block dimensions of the group.
# An allowed exception for the above rule would be, when following the inside of the hull from front to back, it might be necessary to go down before heading back up in order to go further to the back of the ship. (Some of the blocks won't increase the box-dimensions of the group, but they connect and make a contiguous group from front to back, so the group isn't optimal, but it is as close as possible while maximizing contiguous ship volume. Note that if a group consists of 100 blocks, but twenty of these blocks are connector blocks that do not increase the box-dimensions of the group, then this group should be considered as an 80-block system for purposes of calculating its SizePower, as the 20 connector blocks only add 25e/sec each, and do not increase the SizePower efficiency bonus.)
# Once the first group is laid in, if needing more e/sec, lay in parallel, un-connected groups, extending along the first group as far as possible. In most cases, it is possible to build with symmetry, thus building at least two groups at a time.
# Finally, even single reactors placed alone, unconnected, will yield 140e/sec, so filling in small pockets with single blocks is better than connecting them to existing groups if they do not also increase the box-dimensions of the group, in which case they only yield 25e/sec.

There is also a diminishing return as the e/sec of a ship approach 1 million e/sec. See the [[#Power Reactor Advanced Analysis|Advanced Analysis]] section below.

Additional optimal layouts may be found [[#Sample optimized reactor layouts|below]].

==Power Capacitor Rules==
[[Power Capacitor|Power Capacitors]] have a simpler equation governing their storage capacity, and designing layouts is subsequently vastly simpler.

<tt style="font-size: large">'''GroupPower''' = 1000 * '''NumBlocks'''1.05</tt>

Unlike [[Power Reactor Module|Power Reactor Modules]], there is no SumOfDimensions value, so the dimensions of the group are irrelevant. All that matters is how many modules are in the group. Since '''GroupPower''' is a power function again, the more blocks are in the group the more benefit the group gets from each block. This is called '''BonusPerBlock''' below. Thus, for a given number of [[Power Capacitor|Power Capacitors]] is it better to have fewer larger groups than many smaller groups.

''Ideally, a ship only has one group of Capacitors. Even if there are necessarily several clumps, they would have a line of capacitors running between them to connect them all into one group.''

Here's some sample group sizes and their value breakdowns. Note that values are rounded.

{|class="wikitable"
!NumBlocks !! GroupPower !! BonusPerBlock
|-
|1||1,000||0
|-
|2||2,071||35
|-
|3||3,169||56
|-
|4||4,287||72
|-
|5||5,419||84
|-
|6||6,562||94
|-
|7||7,715||102
|-
|8||8,877||110
|-
|9||10,045||116
|-
|10||11,220||122
|-
|50||60,802||216
|-
|100||125,893||259
|}

==Power Reactor Advanced Analysis==

This data is mostly of use for builders of large and very large ships. Even though a mid-sized ship might be able to make use of 1 million e/sec, it might not have the internal volume to make an optimized group of 500 or more power reactor modules. However, this analysis does show that small to medium ships should still try to utilize the largest optimized block structures that they can manage within the volume of their ship, as opposed to a higher number of smaller block structures, such as those used in the '''efficient cube''' structures.

The following table lists the SizePower value generated by an optimal group of blocks of the given number. Note that SizePower does not fully max out at 1,000,000 until the optimized group has 3374 blocks. An optimized group is one with the largest possible box-dimensions for the number of blocks, or a group in which no block fails to increase the box-dimensions of the group:

{|class="wikitable"
!Blocks !! Max SizePower !! BlockPower !! GroupPower !! Power/Block Ratio
|-
|25||4853.8||625.0||5478.8||219.2
|-
|50||14789.0||1250.0||16039.0||320.8
|-
|100||46459.4||2500.0||48959.4||489.6
|-
|200||147463.8||5000.0||152463.8||762.3
|-
|300||286080.1||7500.0||293580.1||978.6
|-
|400||445102.1||10000.0||455102.1||1137.8
|-
|500||603206.3||12500.0||615706.3||1231.4
|- style="font-style: bold; background-color: green;"
|594||732790.3||14850.0||747640.3||1258.7
|-
|600||740136.2||15000.0||755136.2||1258.6
|-
|700||843919.1||17500.0||861419.1||1230.6
|-
|800||913509.0||20000.0||933509.0||1166.9
|-
|900||955432.2||22500.0||977932.2||1086.6
|-
|1000||978486.0||25000.0||1003486.0||1003.5
|-
|1100||990213.8||27500.0||1017713.8||925.2
|-
|1200||995787.6||30000.0||1025787.6||854.8
|-
|1300||998279.2||32500.0||1030779.2||792.9
|-
|1400||999331.5||35000.0||1034331.5||738.8
|-
|1500||999752.7||37500.0||1037252.7||691.5
|-
|1600||999912.7||40000.0||1039912.7||649.9
|-
|1700||999970.6||42500.0||1042470.6||613.2
|-
|1800||999990.5||45000.0||1044990.5||580.6
|-
|1900||999997.1||47500.0||1047497.1||551.3
|-
|2000||999999.1||50000.0||1049999.1||525.0
|-
|2100||999999.8||52500.0||1052499.8||501.2
|-
|2200||999999.9||55000.0||1054999.9||479.5
|-
|2300||1000000.0||57500.0||1057500.0||459.8
|-
|2400||1000000.0||60000.0||1060000.0||441.7
|-
|2500||1000000.0||62500.0||1062500.0||425.0
|-
|2600||1000000.0||65000.0||1065000.0||409.6
|-
|2700||1000000.0||67500.0||1067500.0||395.4
|-
|2800||1000000.0||70000.0||1070000.0||382.1
|-
|2900||1000000.0||72500.0||1072500.0||369.8
|-
|3000||1000000.0||75000.0||1075000.0||358.3
|-
|3100||1000000.0||77500.0||1077500.0||347.6
|-
|3200||1000000.0||80000.0||1080000.0||337.5
|-
|3374||1000000.0||84350.0||1084350.0||321.4
|}

The above table is illustrated better in the following chart:

<gallery mode="traditional" widths=600px heights=400px perrow=1 caption="Graphs of SizePower and GroupPower per Block">
Image:Max_SizePower_Curve.jpg|SizePower per optimized group of blocks of a given number, and the GroupPower per Block of each group.
</gallery>

It is easy to see that SizePower has diminishing returns after about 600 blocks. The precise number is 594. This is the number of blocks in a group that yields the largest bonus per block, 1258.7, after which it begins to fall. This is due to the S-curve shape of the SizePower graph. Consequently, if building a large ship with thousands of power reactor blocks, ''it would seem'' the power system should be composed of optimized groups of about 500 to 700 blocks each, this range being close enough to 594 that it does not greatly affect the resulting e/sec produced by a large system. However, there is another diminishing return factor applied to multiple groups within a ship. For example, in the chart above a group of 1000 power reactors, optimally, yields 1003486.0 e/sec, and a group of 500 power reactors yields 615706.3 e/sec. This has been verified in-game with build '''.1867'''. However, using two groups of 500 power reactors does not yield double the 615706.3 e/sec value, but only 909558.9 instead. Likewise, 1200 blocks would yield 1025787.6 e/sec, but two groups of 600 only yield 986370.9 e/sec, not double the 755136.2 e/sec of one group of 600.

This diminishing return factor for groups is a soft limit which effectively limits ships to not much more than 1 million e/sec in practice. Consequently large ships are currently either limited to this value, or else use a ''docked '''power module''' daughter-ship'' and power drain beams to add more power generation capacity to a base ship.

To get to 1 million e/sec (using optimal layouts with each group):
{|class="wikitable"
!NumGroups!!GroupSize!!TotalBlocks!!SumGroupX!!MaxSizePower!!BlockPower!!TotalPower!!Power/Block
|-
|1||1000||1000||19515.0||978486.0||25000||1003486.0||1003.5
|-
|2||700||1400||21315.6||985772.0||35000||1020772.0||729.1
|-
|2||650||1300||18799.4||974655.6||32500||1007155.6||774.7
|-
|3||500||1500||18080.5||970131.0||37500||1007631.0||671.8
|-
|4||400||1600||16524.9||957445.3||40000||997445.3||623.4
|-
|6||300||1800||15242.5||943141.8||45000||988141.8||549.0
|-
|12||200||2400||15387.7||944970.1||60000||1004970.1||418.7
|-
|18||150||2700||14233.1||928695.3||67500||996195.3||369.0
|-
|34||100||3400||13645.6||918720.2||85000||1003720.2||295.2
|-
|52||75||3900.0||12939.9||904968.8||97500||1002468.8||257.0
|-
|94||50||4700.0||12001.3||883230.7||117500||1000730.7||212.9
|-
|253||25||6325.0||10600.7||842003.8||158125||1000128.8||158.1
|}

In terms of ship mass, larger groups are more efficient.

==Sample Optimized Reactor Layouts==

<gallery mode="traditional" widths=300px heights=300px perrow=2 caption="Optimal 2x2 and 3x3 reactor layouts">
Image:2x2Maximized.jpg|A 2x2 cube with two reactor groups. BlockPower=125e (100+25) SizePower=492e (376+115) TotalPower=617e
Image:3x3Maximized.jpg|A 3x3 cube with two reactor groups. BlockPower=500e (250+250) SizePower=1499e (749 + 749) TotalPower=1999e
</gallery>

<gallery mode="traditional" widths=300px heights=300px perrow=4 caption="Optimal 4x4 reactor layout">
Image:4x4MaximizedLayer1.jpg|A 4x4 cube with four reactor groups - layer 1. BlockPower=825e (100+200+250+275) SizePower=3719e (376+897+1223+1223) TotalPower=4544e
Image:4x4MaximizedLayer2.jpg|A 4x4 cube with four reactor groups - layer 2.
Image:4x4MaximizedLayer3.jpg|A 4x4 cube with four reactor groups - layer 3.
Image:4x4MaximizedLayer4.jpg|A 4x4 cube with four reactor groups - layer 4.
</gallery>

<gallery mode="traditional" widths=1000px heights=200px perrow=1 caption="Optimal 5x5 reactor layout">
Image:Power Block Compact.png|A 5x5 cube with 5 reactor groups. BlockPower=1725e (375+375+375+375+225) SizePower=8282e (1787+1787+1787+1787+1054) TotalPower=9927e
</gallery>

[[Category:Articles]]
[[Category:Game Mechanics]]

Legacy Power Systems

2016-08-06T16:52:40Z

Olxinos: /* Power Reactor Rules (Single Group Formula) */

This page describes the power generation and storage mechanisms in '''StarMade'''.

==Power Generation and Storage Blocks==
Power is generated using the [[Power Reactor Module]], though on ships, the [[Ship Core]] will generate 1 energy (or e) per second (called e/s) by itself. [[Planet|Planets]] and [[Space Station|Space Stations]] do not generate any power by themselves. There is a default storage amount of 50,000e on ships, but no default storage for planets and space stations. Power storage can be augmented using [[Power Capacitor|Power Capacitors]]. While these units can be placed anywhere on a ship, planet or station and contribute to either power generation or storage respectively, they are more effective when arranged according to the rules described below. This is particularly important when space is constrained as on most ships.

An important consideration regarding power capacity is that all systems use power from the '''capacity''' of a ship or station. If the instantaneous demand for power is not satisfied by the remaining capacity, then the action that is demanding the power will fail to occur. For example, one or all of the missiles that have been commanded to fire will fail to fire due to demanding more power than is currently in storage. However, the power will not be consumed by the failed action. At a minimum, a ship or station should have enough capacity to at least simultaneously fire all the weapon systems attached. Other considerations are the constant demand being made by always-active systems, and how much simultaneous demand will be made when shields begin to recharge, and thrusters need to fire. Power generation is used to refill the power capacity of a ship or station, and needs to be large enough to provide power during sustained demand. Power generation need not equal or exceed all possible demands. For example, charging a jump drive may drain the capacity faster than the power generation can refill it, but as long as the capacity is enough to charge the jump drive without being fully drained, this may be considered to be more than adequate for a given ship.

==Power Reactor Rules (Single Group Formula)==
[[Power Reactor Module|Power Reactors]] have a somewhat complex set of rules associated with them when it comes to creating efficient or compact power systems. This comes from how their power output is calculated, which is not simply by adding up the blocks and multiplying them by some power factor. Instead, the formula for a '''single''' [[Module Group|group]] of power reactors is as follows:

<tt style="font-size: large">'''GroupPower''' = BlockPower + SizePower</tt>

where:

<tt style="font-size: large">'''BlockPower''' = 25 * NumberOfBlocks</tt>

and:

<tt style="font-size: large">'''SizePower''' = 2000000 * 2 / ( 1 + 1.000348-0.333*(SumOfDimensions/3)1.7) - 1000000</tt>

'''GroupPower''' is fairly straightforward, as it is the simple sum of the other two pieces.

'''BlockPower''' is the amount of power contributed directly by the [[Power Reactor Module]]s in the group, which is just 25e per module.

'''SizePower''' is the amount of power contributed by the '''size''' of the group, and is only dependent on '''SumOfDimensions''' which is the sum of the dimensions of the smallest bounding box which can encompass the entire group. Because SumOfDimensions is a plain sum, a 3x3x3 box, 1x1x7 box and a 2x2x5 box are the same (9) for the purposes of this part of the equation. This is the part of the equation which is most important when considering how to maximize a group of reactors because SizePower is a power function, which means that each successive incremental increase in the value of SumOfDimensions gives much greater benefits than the next lower value.

Note that SizePower caps out at 1,000,000e. Also note that for multiple reactor groups, the above formula is modified, and results in a diminishing return. Total Power of a ship is not the sum of the Group Power of each group. See the [[#Power Reactor Advanced Analysis|Advanced Analysis]] section for a more detailed explanation of the equation.

Here are some examples of power reactor groups and how their power outputs are calculated.

<gallery mode="traditional" widths=300px heights=300px perrow=3 caption="Example power reactor groups and power values">
Image:Bounding Box 1.jpg|A power reactor by itself has a bounding box with dimensions 1 x 1 x 1. SumOfDimensions=3. BlockPower=25e. SizePower=115e. GroupPower=140e.
Image:Bounding Box 2.jpg|A power reactor group of 3 modules with a bounding box with dimensions 2 x 1 x 2. SumOfDimensions=5. BlockPower=75e. SizePower=276e. GroupPower=351e.
Image:Bounding Box 3.jpg|A power reactor group of 7 modules with a bounding box with dimensions 3 x 3 x 3. SumOfDimensions=9. BlockPower =175e. SizePower=749e. GroupPower=924e.
</gallery>

===Relationship between BlockPower, SizePower and TotalPower===

When there is only one power reactor block group in or on an entity, the GroupPower and the total power of the entity is identical. However, when there is more than one group, the total power provided to a ship, station or planet is ''not'' the sum of the GroupPower of all groups. Rather, '''TotalPower''' of an entity with multiple power reactor groups is subject to diminishing returns, and is given by the following formula:

<tt style="font-size: large">'''TotalPower''' = BlockPower + GroupSumSizePower</tt>

where:

<tt style="font-size: large">'''BlockPower''' = 25 * TotalNumberOfBlocksInAllGroups</tt>

and:

<tt style="font-size: large">'''GroupSumSizePower''' = 2000000 * 2 / ( 1 + 1.000348-0.333 * GroupSumPower) - 2000000</tt>

where:

<tt style="font-size:large">'''GroupSumPower''' = (SumOfDimensionsOfGroup1/3)1.7 + (SumOfDimensionsOfGroup2/3)1.7 ... + (SumOfDimensionsOfGroup''n''/3)1.7</tt>, where ''n'' is the number of groups.

To understand the relationship between SizePower, BlockPower and TotalPower, consider a 3x3 space in which to place a set of reactor modules. Below are three layouts in this 3x3 space. Note that values are rounded which may lead to small apparent discrepancies.

<gallery mode="traditional" widths=300px heights=300px perrow=3 caption="Example 3x3 layouts with power values">
Image:3x3Cube.jpg|A single power reactor group of 27 modules in a 3x3 space. BlockPower=675e. SizePower=749e. TotalPower=1424e
Image:3x3SingleEdge.jpg|A single power reactor group of 7 modules in a 3x3 space. BlockPower=175e. SizePower=749e. TotalPower=924e.
Image:3x3DoubleEdge.jpg|Two power reactor groups of 7 modules each (14 total modules) in a 3x3 space. BlockPower=175e each (350e total). SizePower=749e each (1499e total). TotalPower=1849e.
</gallery>

Notice that the first and second versions have the same SizePower, as SizePower depends only on the dimensions of the group and not the number of blocks. The first of course produces more total power than the second because it has more blocks and each only has a single group, but SizePower still contributes more to the total than the number of blocks does. Then look at the third version, which has the same dimensions but two groups instead of one. The SizePower is twice that of the other two because there are two groups and because SizePower counts for much more than BlockPower the TotalPower of the third version is much higher than the first one, in spite of only having half as many blocks in it (and thus a lower BlockPower).

Please note that with the very small groups in the cubic structure above, the diminishing returns of TotalPower with multiple groups is not noticeable with such small power output rounded to a whole number. But note the case of a group of 1000 power reactors in one group, 500 in one group, and finally a third case of two groups of 500, for a total of 1000 blocks.

# 1000 in one group: GroupPower/TotalPower = 1003486.0 e/sec
# 500 in one group: GroupPower/TotalPower = 615706.3 e/sec
# 1000 in two groups of 500: TotalPower = 909558.9 e/sec, not the sum of 615706.3 twice.

===Optimal layouts===
None of the examples above are optimal layouts for the cubic 3x3x3 volume, though the third version is getting close. To create an optimal layout in a given space is rather complex, but it boils down to the following three rules:
* Maximize the SumOfDimensions for each group, because this contributes the most to the power equation through SizePower.
* Maximize the number of such groups in the space, because this allows you to take advantage of SizePower for each group
* Minimize the number of empty spaces - that is, spaces which don't contain power reactor modules - without reducing the number of groups. When doing this, be mindful of the fact that a block in a group of its own is worth 140e/s, while a block added to an existing group is only worth 25e/s if it doesn't also add to the physical size of the group.

The optimal layout for the 3x3 example above fills in as many spaces as possible in the cube without the two groups touching. By filling in empty spaces of the third example above, we can increase the BlockPower of each group to 250e/s, and we are left with only 7 empty spaces (6 exterior and the block in the middle is omitted). It looks like the following:

<gallery mode="traditional" widths=300px heights=300px perrow=1 caption="Optimal 3x3 reactor layout">
Image:3x3Maximized.jpg|A 3x3 cube with two reactor groups which maximizes the power output in the provided space. BlockPower=500e/s. SizePower=1499e/s TotalPower=1999e/s.
</gallery>

Once you have put in as many [[Power Reactor Module]]s as you can into the space, you can fill the remaining spaces with any other module, except you should not use [[Power Capacitor]]s because they can benefit from grouping as well, though it differs from power reactors. Using [[Shield Recharger]]s or [[Shield Capacitor|Shield Capacitors]] for this purpose is common.

Layouts need not be cube-shaped to be optimal, even though this page uses them for examples. The above 3x3x3 example is the optimal '''cubic''' structure, for the most power that can be generated in the smallest cubic volume, but does not provide the most power that can be generated for the blocks used, which is 20. The layout shape will typically be dictated by the ship or station dimensions. Keep in mind that since other shapes provide more power than a cubic volume, it is unlikely that a ship or station would be best served with a perfectly cubic power structure, even if the ship is itself a large cube.

<gallery mode="traditional" widths=900px heights=300px perrow=1 caption="Optimal maximum-output layouts">
Image:OptimalPowerStructures.jpg|Five reactor groups which maximize the power output for 20 blocks. BlockPower=500e/s. SizePower=3426.8e/s TotalPower=3926.8e/s.
</gallery>

Note that though not pictured above, a simple straight line of Power Reactor blocks is also a maximum-output layout as well.

In the picture above, the first structure on the left uses the same number of cubes as the 3x3x3 cubic power structure shown in the lower middle, but generates almost twice the power at 3926.8e/s. For 20 blocks, this is the maximum power that can be generated. However, other shapes can also achieve the same box dimension sum as the first structure. Each of the other four structures on the upper deck in the picture above '''also''' generate the maximum power of 3926.8e/s. Thus it is likely for almost any ship volume that a custom, non-cubic reactor structure will generate more power than simply using an efficient cubic volume. Furthermore, the true cubic volume of all of the structures in the image above is actually '''20'''. In other words, each of the above structures have an identical impact on the internal volume of a given ship, which is to consume 20 blocks of the ship's total internal volume, but the 3x3x3 cubic shape only generates '''half''' of the other structure's power per second.

The goal in design of a ship's power generation should be to both maximize the power reactor structure's box dimensions while also reserving large contiguous volumes within the ship for weapons and effects groups, functional areas like a core room, computer room, shuttle docking bay, or cargo hold, and usually some role-play areas, like a cockpit or command deck, medical facility, captain's quarters, corridors, elevators, etc. A cubic volume is not capable of fulfilling this goal.

Taking these things into consideration, the process for designing an optimized power system for a ship is:
# Build the largest optimized group possible within the volume of the ship. An optimized group is one in which each added power reactor always increases the block dimensions of the group.
# An allowed exception for the above rule would be, when following the inside of the hull from front to back, it might be necessary to go down before heading back up in order to go further to the back of the ship. (Some of the blocks won't increase the box-dimensions of the group, but they connect and make a contiguous group from front to back, so the group isn't optimal, but it is as close as possible while maximizing contiguous ship volume. Note that if a group consists of 100 blocks, but twenty of these blocks are connector blocks that do not increase the box-dimensions of the group, then this group should be considered as an 80-block system for purposes of calculating its SizePower, as the 20 connector blocks only add 25e/sec each, and do not increase the SizePower efficiency bonus.)
# Once the first group is laid in, if needing more e/sec, lay in parallel, un-connected groups, extending along the first group as far as possible. In most cases, it is possible to build with symmetry, thus building at least two groups at a time.
# Finally, even single reactors placed alone, unconnected, will yield 140e/sec, so filling in small pockets with single blocks is better than connecting them to existing groups if they do not also increase the box-dimensions of the group, in which case they only yield 25e/sec.

There is also a diminishing return as the e/sec of a ship approach 1 million e/sec. See the [[#Power Reactor Advanced Analysis|Advanced Analysis]] section below.

Additional optimal layouts may be found [[#Sample optimized reactor layouts|below]].

==Power Capacitor Rules==
[[Power Capacitor|Power Capacitors]] have a simpler equation governing their storage capacity, and designing layouts is subsequently vastly simpler.

<tt style="font-size: large">'''GroupPower''' = 1000 * '''NumBlocks'''1.05</tt>

Unlike [[Power Reactor Module|Power Reactor Modules]], there is no SumOfDimensions value, so the dimensions of the group are irrelevant. All that matters is how many modules are in the group. Since '''GroupPower''' is a power function again, the more blocks are in the group the more benefit the group gets from each block. This is called '''BonusPerBlock''' below. Thus, for a given number of [[Power Capacitor|Power Capacitors]] is it better to have fewer larger groups than many smaller groups.

''Ideally, a ship only has one group of Capacitors. Even if there are necessarily several clumps, they would have a line of capacitors running between them to connect them all into one group.''

Here's some sample group sizes and their value breakdowns. Note that values are rounded.

{|class="wikitable"
!NumBlocks !! GroupPower !! BonusPerBlock
|-
|1||1,000||0
|-
|2||2,071||35
|-
|3||3,169||56
|-
|4||4,287||72
|-
|5||5,419||84
|-
|6||6,562||94
|-
|7||7,715||102
|-
|8||8,877||110
|-
|9||10,045||116
|-
|10||11,220||122
|-
|50||60,802||216
|-
|100||125,893||259
|}

==Power Reactor Advanced Analysis==

This data is mostly of use for builders of large and very large ships. Even though a mid-sized ship might be able to make use of 1 million e/sec, it might not have the internal volume to make an optimized group of 500 or more power reactor modules. However, this analysis does show that small to medium ships should still try to utilize the largest optimized block structures that they can manage within the volume of their ship, as opposed to a higher number of smaller block structures, such as those used in the '''efficient cube''' structures.

The following table lists the SizePower value generated by an optimal group of blocks of the given number. Note that SizePower does not fully max out at 1,000,000 until the optimized group has 3374 blocks. An optimized group is one with the largest possible box-dimensions for the number of blocks, or a group in which no block fails to increase the box-dimensions of the group:

{|class="wikitable"
!Blocks !! Max SizePower !! BlockPower !! GroupPower !! Power/Block Ratio
|-
|25||4853.8||625.0||5478.8||219.2
|-
|50||14789.0||1250.0||16039.0||320.8
|-
|100||46459.4||2500.0||48959.4||489.6
|-
|200||147463.8||5000.0||152463.8||762.3
|-
|300||286080.1||7500.0||293580.1||978.6
|-
|400||445102.1||10000.0||455102.1||1137.8
|-
|500||603206.3||12500.0||615706.3||1231.4
|- style="font-style: bold; background-color: green;"
|594||732790.3||14850.0||747640.3||1258.7
|-
|600||740136.2||15000.0||755136.2||1258.6
|-
|700||843919.1||17500.0||861419.1||1230.6
|-
|800||913509.0||20000.0||933509.0||1166.9
|-
|900||955432.2||22500.0||977932.2||1086.6
|-
|1000||978486.0||25000.0||1003486.0||1003.5
|-
|1100||990213.8||27500.0||1017713.8||925.2
|-
|1200||995787.6||30000.0||1025787.6||854.8
|-
|1300||998279.2||32500.0||1030779.2||792.9
|-
|1400||999331.5||35000.0||1034331.5||738.8
|-
|1500||999752.7||37500.0||1037252.7||691.5
|-
|1600||999912.7||40000.0||1039912.7||649.9
|-
|1700||999970.6||42500.0||1042470.6||613.2
|-
|1800||999990.5||45000.0||1044990.5||580.6
|-
|1900||999997.1||47500.0||1047497.1||551.3
|-
|2000||999999.1||50000.0||1049999.1||525.0
|-
|2100||999999.8||52500.0||1052499.8||501.2
|-
|2200||999999.9||55000.0||1054999.9||479.5
|-
|2300||1000000.0||57500.0||1057500.0||459.8
|-
|2400||1000000.0||60000.0||1060000.0||441.7
|-
|2500||1000000.0||62500.0||1062500.0||425.0
|-
|2600||1000000.0||65000.0||1065000.0||409.6
|-
|2700||1000000.0||67500.0||1067500.0||395.4
|-
|2800||1000000.0||70000.0||1070000.0||382.1
|-
|2900||1000000.0||72500.0||1072500.0||369.8
|-
|3000||1000000.0||75000.0||1075000.0||358.3
|-
|3100||1000000.0||77500.0||1077500.0||347.6
|-
|3200||1000000.0||80000.0||1080000.0||337.5
|-
|3374||1000000.0||84350.0||1084350.0||321.4
|}

The above table is illustrated better in the following chart:

<gallery mode="traditional" widths=600px heights=400px perrow=1 caption="Graphs of SizePower and GroupPower per Block">
Image:Max_SizePower_Curve.jpg|SizePower per optimized group of blocks of a given number, and the GroupPower per Block of each group.
</gallery>

It is easy to see that SizePower has diminishing returns after about 600 blocks. The precise number is 594. This is the number of blocks in a group that yields the largest bonus per block, 1258.7, after which it begins to fall. This is due to the S-curve shape of the SizePower graph. Consequently, if building a large ship with thousands of power reactor blocks, ''it would seem'' the power system should be composed of optimized groups of about 500 to 700 blocks each, this range being close enough to 594 that it does not greatly affect the resulting e/sec produced by a large system. However, there is another diminishing return factor applied to multiple groups within a ship. For example, in the chart above a group of 1000 power reactors, optimally, yields 1003486.0 e/sec, and a group of 500 power reactors yields 615706.3 e/sec. This has been verified in-game with build '''.1867'''. However, using two groups of 500 power reactors does not yield double the 615706.3 e/sec value, but only 909558.9 instead. Likewise, 1200 blocks would yield 1025787.6 e/sec, but two groups of 600 only yield 986370.9 e/sec, not double the 755136.2 e/sec of one group of 600.

This diminishing return factor for groups is a soft limit which effectively limits ships to not much more than 1 million e/sec in practice. Consequently large ships are currently either limited to this value, or else use a ''docked '''power module''' daughter-ship'' and power drain beams to add more power generation capacity to a base ship.

To get to 1 million e/sec (using optimal layouts with each group):
{|class="wikitable"
!NumGroups!!GroupSize!!TotalBlocks!!SumGroupX!!MaxSizePower!!BlockPower!!TotalPower!!Power/Block
|-
|1||1000||1000||19515.0||978486.0||25000||1003486.0||1003.5
|-
|2||700||1400||21315.6||985772.0||35000||1020772.0||729.1
|-
|2||650||1300||18799.4||974655.6||32500||1007155.6||774.7
|-
|3||500||1500||18080.5||970131.0||37500||1007631.0||671.8
|-
|4||400||1600||16524.9||957445.3||40000||997445.3||623.4
|-
|6||300||1800||15242.5||943141.8||45000||988141.8||549.0
|-
|12||200||2400||15387.7||944970.1||60000||1004970.1||418.7
|-
|18||150||2700||14233.1||928695.3||67500||996195.3||369.0
|-
|34||100||3400||13645.6||918720.2||85000||1003720.2||295.2
|-
|52||75||3900.0||12939.9||904968.8||97500||1002468.8||257.0
|-
|94||50||4700.0||12001.3||883230.7||117500||1000730.7||212.9
|-
|253||25||6325.0||10600.7||842003.8||158125||1000128.8||158.1
|}

In terms of ship mass, larger groups are more efficient.

==Sample Optimized Reactor Layouts==

<gallery mode="traditional" widths=300px heights=300px perrow=2 caption="Optimal 2x2 and 3x3 reactor layouts">
Image:2x2Maximized.jpg|A 2x2 cube with two reactor groups. BlockPower=125e (100+25) SizePower=492e (376+115) TotalPower=617e
Image:3x3Maximized.jpg|A 3x3 cube with two reactor groups. BlockPower=500e (250+250) SizePower=1499e (749 + 749) TotalPower=1999e
</gallery>

<gallery mode="traditional" widths=300px heights=300px perrow=4 caption="Optimal 4x4 reactor layout">
Image:4x4MaximizedLayer1.jpg|A 4x4 cube with four reactor groups - layer 1. BlockPower=825e (100+200+250+275) SizePower=3719e (376+897+1223+1223) TotalPower=4544e
Image:4x4MaximizedLayer2.jpg|A 4x4 cube with four reactor groups - layer 2.
Image:4x4MaximizedLayer3.jpg|A 4x4 cube with four reactor groups - layer 3.
Image:4x4MaximizedLayer4.jpg|A 4x4 cube with four reactor groups - layer 4.
</gallery>

<gallery mode="traditional" widths=1000px heights=200px perrow=1 caption="Optimal 5x5 reactor layout">
Image:Power Block Compact.png|A 5x5 cube with 5 reactor groups. BlockPower=1725e (375+375+375+375+225) SizePower=8282e (1787+1787+1787+1787+1054) TotalPower=9927e
</gallery>

[[Category:Articles]]
[[Category:Game Mechanics]]

Legacy Power Systems

2016-08-06T16:13:09Z

Olxinos: /* Power Reactor Rules (Single Group Formula) */

This page describes the power generation and storage mechanisms in '''StarMade'''.

==Power Generation and Storage Blocks==
Power is generated using the [[Power Reactor Module]], though on ships, the [[Ship Core]] will generate 1 energy (or e) per second (called e/s) by itself. [[Planet|Planets]] and [[Space Station|Space Stations]] do not generate any power by themselves. There is a default storage amount of 50,000e on ships, but no default storage for planets and space stations. Power storage can be augmented using [[Power Capacitor|Power Capacitors]]. While these units can be placed anywhere on a ship, planet or station and contribute to either power generation or storage respectively, they are more effective when arranged according to the rules described below. This is particularly important when space is constrained as on most ships.

An important consideration regarding power capacity is that all systems use power from the '''capacity''' of a ship or station. If the instantaneous demand for power is not satisfied by the remaining capacity, then the action that is demanding the power will fail to occur. For example, one or all of the missiles that have been commanded to fire will fail to fire due to demanding more power than is currently in storage. However, the power will not be consumed by the failed action. At a minimum, a ship or station should have enough capacity to at least simultaneously fire all the weapon systems attached. Other considerations are the constant demand being made by always-active systems, and how much simultaneous demand will be made when shields begin to recharge, and thrusters need to fire. Power generation is used to refill the power capacity of a ship or station, and needs to be large enough to provide power during sustained demand. Power generation need not equal or exceed all possible demands. For example, charging a jump drive may drain the capacity faster than the power generation can refill it, but as long as the capacity is enough to charge the jump drive without being fully drained, this may be considered to be more than adequate for a given ship.

==Power Reactor Rules (Single Group Formula)==
[[Power Reactor Module|Power Reactors]] have a somewhat complex set of rules associated with them when it comes to creating efficient or compact power systems. This comes from how their power output is calculated, which is not simply by adding up the blocks and multiplying them by some power factor. Instead, the formula for a '''single''' [[Module Group|group]] of power reactors is as follows:

<tt style="font-size: large">'''GroupPower''' = BlockPower + SizePower</tt>

where:

<tt style="font-size: large">'''BlockPower''' = 25 * NumberOfBlocks</tt>

and:

<tt style="font-size: large">'''SizePower''' = 2000000 * 2 / ( 1 + 1.000348-0.333*(SumOfDimensions/3)1.7) - 1000000</tt>

'''GroupPower''' is fairly straightforward, as it is the simple sum of the other two pieces.

'''BlockPower''' is the amount of power contributed directly by the [[Power Reactor Module]]s in the group, which is just 25e per module.

'''SizePower''' is the amount of power contributed by the '''size''' of the group, and is only dependent on '''SumOfDimensions''' which is the sum of the dimensions of the smallest bounding box which can encompass the entire group. Because SumOfDimensions is a plain sum, a 3x3x3 box, 1x1x7 box and a 2x2x5 box are the same (9) for the purposes of this part of the equation. This is the part of the equation which is most important when considering how to maximize a group of reactors because SizePower is a power function, which means that each successive incremental increase in the value of SumOfDimensions gives much greater benefits than the next lower value.

Note that SizePower caps out at 1,000,000e. Also note that for multiple reactor groups, the above formula is modified, and results in a diminishing return. Total Power of a ship is not the sum of the Group Power of each group. See the [[#Power Reactor Advanced Analysis|Advanced Analysis]] section for a more detailed explanation of the equation.

Here are some examples of power reactor groups and how their power outputs are calculated.

<gallery mode="traditional" widths=300px heights=300px perrow=3 caption="Example power reactor groups and power values">
Image:Bounding Box 1.jpg|A power reactor by itself has a bounding box with dimensions 1 x 1 x 1. SumOfDimensions=3. BlockPower=25e. SizePower=115e. GroupPower=140e.
Image:Bounding Box 2.jpg|A power reactor group of 3 modules with a bounding box with dimensions 2 x 1 x 2. SumOfDimensions=5. BlockPower=75e. SizePower=276e. GroupPower=351e.
Image:Bounding Box 3.jpg|A power reactor group of 7 modules with a bounding box with dimensions 3 x 3 x 3. SumOfDimensions=9. BlockPower =175e. SizePower=749e. GroupPower=924e.
</gallery>

===Relationship between BlockPower, SizePower and TotalPower===

When there is only one power reactor block group in or on an entity, the GroupPower and the total power of the entity is identical. However, when there is more than one group, the total power provided to a ship, station or planet is ''not'' the sum of the GroupPower of all groups. Rather, '''TotalPower''' of an entity with multiple power reactor groups is subject to diminishing returns, and is given by the following formula:

<tt style="font-size: large">'''TotalPower''' = BlockPower + GroupSumSizePower</tt>

where:

<tt style="font-size: large">'''BlockPower''' = 25 * TotalNumberOfBlocksInAllGroups</tt>

and:

<tt style="font-size: large">'''GroupSumSizePower''' = 2000000 * 2 / ( 1 + 1.000348-0.333 * GroupSumPower) - 1000000</tt>

where:

<tt style="font-size:large">'''GroupSumPower''' = (SumOfDimensionsOfGroup1/3)1.7 + (SumOfDimensionsOfGroup2/3)1.7 ... + (SumOfDimensionsOfGroup''n''/3)1.7</tt>, where ''n'' is the number of groups.

To understand the relationship between SizePower, BlockPower and TotalPower, consider a 3x3 space in which to place a set of reactor modules. Below are three layouts in this 3x3 space. Note that values are rounded which may lead to small apparent discrepancies.

<gallery mode="traditional" widths=300px heights=300px perrow=3 caption="Example 3x3 layouts with power values">
Image:3x3Cube.jpg|A single power reactor group of 27 modules in a 3x3 space. BlockPower=675e. SizePower=749e. TotalPower=1424e
Image:3x3SingleEdge.jpg|A single power reactor group of 7 modules in a 3x3 space. BlockPower=175e. SizePower=749e. TotalPower=924e.
Image:3x3DoubleEdge.jpg|Two power reactor groups of 7 modules each (14 total modules) in a 3x3 space. BlockPower=175e each (350e total). SizePower=749e each (1499e total). TotalPower=1849e.
</gallery>

Notice that the first and second versions have the same SizePower, as SizePower depends only on the dimensions of the group and not the number of blocks. The first of course produces more total power than the second because it has more blocks and each only has a single group, but SizePower still contributes more to the total than the number of blocks does. Then look at the third version, which has the same dimensions but two groups instead of one. The SizePower is twice that of the other two because there are two groups and because SizePower counts for much more than BlockPower the TotalPower of the third version is much higher than the first one, in spite of only having half as many blocks in it (and thus a lower BlockPower).

Please note that with the very small groups in the cubic structure above, the diminishing returns of TotalPower with multiple groups is not noticeable with such small power output rounded to a whole number. But note the case of a group of 1000 power reactors in one group, 500 in one group, and finally a third case of two groups of 500, for a total of 1000 blocks.

# 1000 in one group: GroupPower/TotalPower = 1003486.0 e/sec
# 500 in one group: GroupPower/TotalPower = 615706.3 e/sec
# 1000 in two groups of 500: TotalPower = 909558.9 e/sec, not the sum of 615706.3 twice.

===Optimal layouts===
None of the examples above are optimal layouts for the cubic 3x3x3 volume, though the third version is getting close. To create an optimal layout in a given space is rather complex, but it boils down to the following three rules:
* Maximize the SumOfDimensions for each group, because this contributes the most to the power equation through SizePower.
* Maximize the number of such groups in the space, because this allows you to take advantage of SizePower for each group
* Minimize the number of empty spaces - that is, spaces which don't contain power reactor modules - without reducing the number of groups. When doing this, be mindful of the fact that a block in a group of its own is worth 140e/s, while a block added to an existing group is only worth 25e/s if it doesn't also add to the physical size of the group.

The optimal layout for the 3x3 example above fills in as many spaces as possible in the cube without the two groups touching. By filling in empty spaces of the third example above, we can increase the BlockPower of each group to 250e/s, and we are left with only 7 empty spaces (6 exterior and the block in the middle is omitted). It looks like the following:

<gallery mode="traditional" widths=300px heights=300px perrow=1 caption="Optimal 3x3 reactor layout">
Image:3x3Maximized.jpg|A 3x3 cube with two reactor groups which maximizes the power output in the provided space. BlockPower=500e/s. SizePower=1499e/s TotalPower=1999e/s.
</gallery>

Once you have put in as many [[Power Reactor Module]]s as you can into the space, you can fill the remaining spaces with any other module, except you should not use [[Power Capacitor]]s because they can benefit from grouping as well, though it differs from power reactors. Using [[Shield Recharger]]s or [[Shield Capacitor|Shield Capacitors]] for this purpose is common.

Layouts need not be cube-shaped to be optimal, even though this page uses them for examples. The above 3x3x3 example is the optimal '''cubic''' structure, for the most power that can be generated in the smallest cubic volume, but does not provide the most power that can be generated for the blocks used, which is 20. The layout shape will typically be dictated by the ship or station dimensions. Keep in mind that since other shapes provide more power than a cubic volume, it is unlikely that a ship or station would be best served with a perfectly cubic power structure, even if the ship is itself a large cube.

<gallery mode="traditional" widths=900px heights=300px perrow=1 caption="Optimal maximum-output layouts">
Image:OptimalPowerStructures.jpg|Five reactor groups which maximize the power output for 20 blocks. BlockPower=500e/s. SizePower=3426.8e/s TotalPower=3926.8e/s.
</gallery>

Note that though not pictured above, a simple straight line of Power Reactor blocks is also a maximum-output layout as well.

In the picture above, the first structure on the left uses the same number of cubes as the 3x3x3 cubic power structure shown in the lower middle, but generates almost twice the power at 3926.8e/s. For 20 blocks, this is the maximum power that can be generated. However, other shapes can also achieve the same box dimension sum as the first structure. Each of the other four structures on the upper deck in the picture above '''also''' generate the maximum power of 3926.8e/s. Thus it is likely for almost any ship volume that a custom, non-cubic reactor structure will generate more power than simply using an efficient cubic volume. Furthermore, the true cubic volume of all of the structures in the image above is actually '''20'''. In other words, each of the above structures have an identical impact on the internal volume of a given ship, which is to consume 20 blocks of the ship's total internal volume, but the 3x3x3 cubic shape only generates '''half''' of the other structure's power per second.

The goal in design of a ship's power generation should be to both maximize the power reactor structure's box dimensions while also reserving large contiguous volumes within the ship for weapons and effects groups, functional areas like a core room, computer room, shuttle docking bay, or cargo hold, and usually some role-play areas, like a cockpit or command deck, medical facility, captain's quarters, corridors, elevators, etc. A cubic volume is not capable of fulfilling this goal.

Taking these things into consideration, the process for designing an optimized power system for a ship is:
# Build the largest optimized group possible within the volume of the ship. An optimized group is one in which each added power reactor always increases the block dimensions of the group.
# An allowed exception for the above rule would be, when following the inside of the hull from front to back, it might be necessary to go down before heading back up in order to go further to the back of the ship. (Some of the blocks won't increase the box-dimensions of the group, but they connect and make a contiguous group from front to back, so the group isn't optimal, but it is as close as possible while maximizing contiguous ship volume. Note that if a group consists of 100 blocks, but twenty of these blocks are connector blocks that do not increase the box-dimensions of the group, then this group should be considered as an 80-block system for purposes of calculating its SizePower, as the 20 connector blocks only add 25e/sec each, and do not increase the SizePower efficiency bonus.)
# Once the first group is laid in, if needing more e/sec, lay in parallel, un-connected groups, extending along the first group as far as possible. In most cases, it is possible to build with symmetry, thus building at least two groups at a time.
# Finally, even single reactors placed alone, unconnected, will yield 140e/sec, so filling in small pockets with single blocks is better than connecting them to existing groups if they do not also increase the box-dimensions of the group, in which case they only yield 25e/sec.

There is also a diminishing return as the e/sec of a ship approach 1 million e/sec. See the [[#Power Reactor Advanced Analysis|Advanced Analysis]] section below.

Additional optimal layouts may be found [[#Sample optimized reactor layouts|below]].

==Power Capacitor Rules==
[[Power Capacitor|Power Capacitors]] have a simpler equation governing their storage capacity, and designing layouts is subsequently vastly simpler.

<tt style="font-size: large">'''GroupPower''' = 1000 * '''NumBlocks'''1.05</tt>

Unlike [[Power Reactor Module|Power Reactor Modules]], there is no SumOfDimensions value, so the dimensions of the group are irrelevant. All that matters is how many modules are in the group. Since '''GroupPower''' is a power function again, the more blocks are in the group the more benefit the group gets from each block. This is called '''BonusPerBlock''' below. Thus, for a given number of [[Power Capacitor|Power Capacitors]] is it better to have fewer larger groups than many smaller groups.

''Ideally, a ship only has one group of Capacitors. Even if there are necessarily several clumps, they would have a line of capacitors running between them to connect them all into one group.''

Here's some sample group sizes and their value breakdowns. Note that values are rounded.

{|class="wikitable"
!NumBlocks !! GroupPower !! BonusPerBlock
|-
|1||1,000||0
|-
|2||2,071||35
|-
|3||3,169||56
|-
|4||4,287||72
|-
|5||5,419||84
|-
|6||6,562||94
|-
|7||7,715||102
|-
|8||8,877||110
|-
|9||10,045||116
|-
|10||11,220||122
|-
|50||60,802||216
|-
|100||125,893||259
|}

==Power Reactor Advanced Analysis==

This data is mostly of use for builders of large and very large ships. Even though a mid-sized ship might be able to make use of 1 million e/sec, it might not have the internal volume to make an optimized group of 500 or more power reactor modules. However, this analysis does show that small to medium ships should still try to utilize the largest optimized block structures that they can manage within the volume of their ship, as opposed to a higher number of smaller block structures, such as those used in the '''efficient cube''' structures.

The following table lists the SizePower value generated by an optimal group of blocks of the given number. Note that SizePower does not fully max out at 1,000,000 until the optimized group has 3374 blocks. An optimized group is one with the largest possible box-dimensions for the number of blocks, or a group in which no block fails to increase the box-dimensions of the group:

{|class="wikitable"
!Blocks !! Max SizePower !! BlockPower !! GroupPower !! Power/Block Ratio
|-
|25||4853.8||625.0||5478.8||219.2
|-
|50||14789.0||1250.0||16039.0||320.8
|-
|100||46459.4||2500.0||48959.4||489.6
|-
|200||147463.8||5000.0||152463.8||762.3
|-
|300||286080.1||7500.0||293580.1||978.6
|-
|400||445102.1||10000.0||455102.1||1137.8
|-
|500||603206.3||12500.0||615706.3||1231.4
|- style="font-style: bold; background-color: green;"
|594||732790.3||14850.0||747640.3||1258.7
|-
|600||740136.2||15000.0||755136.2||1258.6
|-
|700||843919.1||17500.0||861419.1||1230.6
|-
|800||913509.0||20000.0||933509.0||1166.9
|-
|900||955432.2||22500.0||977932.2||1086.6
|-
|1000||978486.0||25000.0||1003486.0||1003.5
|-
|1100||990213.8||27500.0||1017713.8||925.2
|-
|1200||995787.6||30000.0||1025787.6||854.8
|-
|1300||998279.2||32500.0||1030779.2||792.9
|-
|1400||999331.5||35000.0||1034331.5||738.8
|-
|1500||999752.7||37500.0||1037252.7||691.5
|-
|1600||999912.7||40000.0||1039912.7||649.9
|-
|1700||999970.6||42500.0||1042470.6||613.2
|-
|1800||999990.5||45000.0||1044990.5||580.6
|-
|1900||999997.1||47500.0||1047497.1||551.3
|-
|2000||999999.1||50000.0||1049999.1||525.0
|-
|2100||999999.8||52500.0||1052499.8||501.2
|-
|2200||999999.9||55000.0||1054999.9||479.5
|-
|2300||1000000.0||57500.0||1057500.0||459.8
|-
|2400||1000000.0||60000.0||1060000.0||441.7
|-
|2500||1000000.0||62500.0||1062500.0||425.0
|-
|2600||1000000.0||65000.0||1065000.0||409.6
|-
|2700||1000000.0||67500.0||1067500.0||395.4
|-
|2800||1000000.0||70000.0||1070000.0||382.1
|-
|2900||1000000.0||72500.0||1072500.0||369.8
|-
|3000||1000000.0||75000.0||1075000.0||358.3
|-
|3100||1000000.0||77500.0||1077500.0||347.6
|-
|3200||1000000.0||80000.0||1080000.0||337.5
|-
|3374||1000000.0||84350.0||1084350.0||321.4
|}

The above table is illustrated better in the following chart:

<gallery mode="traditional" widths=600px heights=400px perrow=1 caption="Graphs of SizePower and GroupPower per Block">
Image:Max_SizePower_Curve.jpg|SizePower per optimized group of blocks of a given number, and the GroupPower per Block of each group.
</gallery>

It is easy to see that SizePower has diminishing returns after about 600 blocks. The precise number is 594. This is the number of blocks in a group that yields the largest bonus per block, 1258.7, after which it begins to fall. This is due to the S-curve shape of the SizePower graph. Consequently, if building a large ship with thousands of power reactor blocks, ''it would seem'' the power system should be composed of optimized groups of about 500 to 700 blocks each, this range being close enough to 594 that it does not greatly affect the resulting e/sec produced by a large system. However, there is another diminishing return factor applied to multiple groups within a ship. For example, in the chart above a group of 1000 power reactors, optimally, yields 1003486.0 e/sec, and a group of 500 power reactors yields 615706.3 e/sec. This has been verified in-game with build '''.1867'''. However, using two groups of 500 power reactors does not yield double the 615706.3 e/sec value, but only 909558.9 instead. Likewise, 1200 blocks would yield 1025787.6 e/sec, but two groups of 600 only yield 986370.9 e/sec, not double the 755136.2 e/sec of one group of 600.

This diminishing return factor for groups is a soft limit which effectively limits ships to not much more than 1 million e/sec in practice. Consequently large ships are currently either limited to this value, or else use a ''docked '''power module''' daughter-ship'' and power drain beams to add more power generation capacity to a base ship.

To get to 1 million e/sec (using optimal layouts with each group):
{|class="wikitable"
!NumGroups!!GroupSize!!TotalBlocks!!SumGroupX!!MaxSizePower!!BlockPower!!TotalPower!!Power/Block
|-
|1||1000||1000||19515.0||978486.0||25000||1003486.0||1003.5
|-
|2||700||1400||21315.6||985772.0||35000||1020772.0||729.1
|-
|2||650||1300||18799.4||974655.6||32500||1007155.6||774.7
|-
|3||500||1500||18080.5||970131.0||37500||1007631.0||671.8
|-
|4||400||1600||16524.9||957445.3||40000||997445.3||623.4
|-
|6||300||1800||15242.5||943141.8||45000||988141.8||549.0
|-
|12||200||2400||15387.7||944970.1||60000||1004970.1||418.7
|-
|18||150||2700||14233.1||928695.3||67500||996195.3||369.0
|-
|34||100||3400||13645.6||918720.2||85000||1003720.2||295.2
|-
|52||75||3900.0||12939.9||904968.8||97500||1002468.8||257.0
|-
|94||50||4700.0||12001.3||883230.7||117500||1000730.7||212.9
|-
|253||25||6325.0||10600.7||842003.8||158125||1000128.8||158.1
|}

In terms of ship mass, larger groups are more efficient.

==Sample Optimized Reactor Layouts==

<gallery mode="traditional" widths=300px heights=300px perrow=2 caption="Optimal 2x2 and 3x3 reactor layouts">
Image:2x2Maximized.jpg|A 2x2 cube with two reactor groups. BlockPower=125e (100+25) SizePower=492e (376+115) TotalPower=617e
Image:3x3Maximized.jpg|A 3x3 cube with two reactor groups. BlockPower=500e (250+250) SizePower=1499e (749 + 749) TotalPower=1999e
</gallery>

<gallery mode="traditional" widths=300px heights=300px perrow=4 caption="Optimal 4x4 reactor layout">
Image:4x4MaximizedLayer1.jpg|A 4x4 cube with four reactor groups - layer 1. BlockPower=825e (100+200+250+275) SizePower=3719e (376+897+1223+1223) TotalPower=4544e
Image:4x4MaximizedLayer2.jpg|A 4x4 cube with four reactor groups - layer 2.
Image:4x4MaximizedLayer3.jpg|A 4x4 cube with four reactor groups - layer 3.
Image:4x4MaximizedLayer4.jpg|A 4x4 cube with four reactor groups - layer 4.
</gallery>

<gallery mode="traditional" widths=1000px heights=200px perrow=1 caption="Optimal 5x5 reactor layout">
Image:Power Block Compact.png|A 5x5 cube with 5 reactor groups. BlockPower=1725e (375+375+375+375+225) SizePower=8282e (1787+1787+1787+1787+1054) TotalPower=9927e
</gallery>

[[Category:Articles]]
[[Category:Game Mechanics]]

Legacy Power Systems

2016-08-06T08:53:01Z

Olxinos: /* Power Reactor Rules (Single Group Formula) */

This page describes the power generation and storage mechanisms in '''StarMade'''.

==Power Generation and Storage Blocks==
Power is generated using the [[Power Reactor Module]], though on ships, the [[Ship Core]] will generate 1 energy (or e) per second (called e/s) by itself. [[Planet|Planets]] and [[Space Station|Space Stations]] do not generate any power by themselves. There is a default storage amount of 50,000e on ships, but no default storage for planets and space stations. Power storage can be augmented using [[Power Capacitor|Power Capacitors]]. While these units can be placed anywhere on a ship, planet or station and contribute to either power generation or storage respectively, they are more effective when arranged according to the rules described below. This is particularly important when space is constrained as on most ships.

An important consideration regarding power capacity is that all systems use power from the '''capacity''' of a ship or station. If the instantaneous demand for power is not satisfied by the remaining capacity, then the action that is demanding the power will fail to occur. For example, one or all of the missiles that have been commanded to fire will fail to fire due to demanding more power than is currently in storage. However, the power will not be consumed by the failed action. At a minimum, a ship or station should have enough capacity to at least simultaneously fire all the weapon systems attached. Other considerations are the constant demand being made by always-active systems, and how much simultaneous demand will be made when shields begin to recharge, and thrusters need to fire. Power generation is used to refill the power capacity of a ship or station, and needs to be large enough to provide power during sustained demand. Power generation need not equal or exceed all possible demands. For example, charging a jump drive may drain the capacity faster than the power generation can refill it, but as long as the capacity is enough to charge the jump drive without being fully drained, this may be considered to be more than adequate for a given ship.

==Power Reactor Rules (Single Group Formula)==
[[Power Reactor Module|Power Reactors]] have a somewhat complex set of rules associated with them when it comes to creating efficient or compact power systems. This comes from how their power output is calculated, which is not simply by adding up the blocks and multiplying them by some power factor. Instead, the formula for a '''single''' [[Module Group|group]] of power reactors is as follows:

<tt style="font-size: large">'''GroupPower''' = BlockPower + SizePower</tt>

where:

<tt style="font-size: large">'''BlockPower''' = 25 * NumberOfBlocks</tt>

and:

<tt style="font-size: large">'''SizePower''' = 2000000 / ( 1 + 1.000348-0.333*(SumOfDimensions/3)1.7) - 1000000</tt>

'''GroupPower''' is fairly straightforward, as it is the simple sum of the other two pieces.

'''BlockPower''' is the amount of power contributed directly by the [[Power Reactor Module]]s in the group, which is just 25e per module.

'''SizePower''' is the amount of power contributed by the '''size''' of the group, and is only dependent on '''SumOfDimensions''' which is the sum of the dimensions of the smallest bounding box which can encompass the entire group. Because SumOfDimensions is a plain sum, a 3x3x3 box, 1x1x7 box and a 2x2x5 box are the same (9) for the purposes of this part of the equation. This is the part of the equation which is most important when considering how to maximize a group of reactors because SizePower is a power function, which means that each successive incremental increase in the value of SumOfDimensions gives much greater benefits than the next lower value.

Note that SizePower caps out at 1,000,000e. Also note that for multiple reactor groups, the above formula is modified, and results in a diminishing return. Total Power of a ship is not the sum of the Group Power of each group. See the [[#Power Reactor Advanced Analysis|Advanced Analysis]] section for a more detailed explanation of the equation.

Here are some examples of power reactor groups and how their power outputs are calculated.

<gallery mode="traditional" widths=300px heights=300px perrow=3 caption="Example power reactor groups and power values">
Image:Bounding Box 1.jpg|A power reactor by itself has a bounding box with dimensions 1 x 1 x 1. SumOfDimensions=3. BlockPower=25e. SizePower=115e. GroupPower=140e.
Image:Bounding Box 2.jpg|A power reactor group of 3 modules with a bounding box with dimensions 2 x 1 x 2. SumOfDimensions=5. BlockPower=75e. SizePower=276e. GroupPower=351e.
Image:Bounding Box 3.jpg|A power reactor group of 7 modules with a bounding box with dimensions 3 x 3 x 3. SumOfDimensions=9. BlockPower =175e. SizePower=749e. GroupPower=924e.
</gallery>

===Relationship between BlockPower, SizePower and TotalPower===

When there is only one power reactor block group in or on an entity, the GroupPower and the total power of the entity is identical. However, when there is more than one group, the total power provided to a ship, station or planet is ''not'' the sum of the GroupPower of all groups. Rather, '''TotalPower''' of an entity with multiple power reactor groups is subject to diminishing returns, and is given by the following formula:

<tt style="font-size: large">'''TotalPower''' = BlockPower + GroupSumSizePower</tt>

where:

<tt style="font-size: large">'''BlockPower''' = 25 * TotalNumberOfBlocksInAllGroups</tt>

and:

<tt style="font-size: large">'''GroupSumSizePower''' = 2000000 / ( 1 + 1.000348-0.333 * GroupSumPower) - 1000000</tt>

where:

<tt style="font-size:large">'''GroupSumPower''' = (SumOfDimensionsOfGroup1/3)1.7 + (SumOfDimensionsOfGroup2/3)1.7 ... + (SumOfDimensionsOfGroup''n''/3)1.7</tt>, where ''n'' is the number of groups.

To understand the relationship between SizePower, BlockPower and TotalPower, consider a 3x3 space in which to place a set of reactor modules. Below are three layouts in this 3x3 space. Note that values are rounded which may lead to small apparent discrepancies.

<gallery mode="traditional" widths=300px heights=300px perrow=3 caption="Example 3x3 layouts with power values">
Image:3x3Cube.jpg|A single power reactor group of 27 modules in a 3x3 space. BlockPower=675e. SizePower=749e. TotalPower=1424e
Image:3x3SingleEdge.jpg|A single power reactor group of 7 modules in a 3x3 space. BlockPower=175e. SizePower=749e. TotalPower=924e.
Image:3x3DoubleEdge.jpg|Two power reactor groups of 7 modules each (14 total modules) in a 3x3 space. BlockPower=175e each (350e total). SizePower=749e each (1499e total). TotalPower=1849e.
</gallery>

Notice that the first and second versions have the same SizePower, as SizePower depends only on the dimensions of the group and not the number of blocks. The first of course produces more total power than the second because it has more blocks and each only has a single group, but SizePower still contributes more to the total than the number of blocks does. Then look at the third version, which has the same dimensions but two groups instead of one. The SizePower is twice that of the other two because there are two groups and because SizePower counts for much more than BlockPower the TotalPower of the third version is much higher than the first one, in spite of only having half as many blocks in it (and thus a lower BlockPower).

Please note that with the very small groups in the cubic structure above, the diminishing returns of TotalPower with multiple groups is not noticeable with such small power output rounded to a whole number. But note the case of a group of 1000 power reactors in one group, 500 in one group, and finally a third case of two groups of 500, for a total of 1000 blocks.

# 1000 in one group: GroupPower/TotalPower = 1003486.0 e/sec
# 500 in one group: GroupPower/TotalPower = 615706.3 e/sec
# 1000 in two groups of 500: TotalPower = 909558.9 e/sec, not the sum of 615706.3 twice.

===Optimal layouts===
None of the examples above are optimal layouts for the cubic 3x3x3 volume, though the third version is getting close. To create an optimal layout in a given space is rather complex, but it boils down to the following three rules:
* Maximize the SumOfDimensions for each group, because this contributes the most to the power equation through SizePower.
* Maximize the number of such groups in the space, because this allows you to take advantage of SizePower for each group
* Minimize the number of empty spaces - that is, spaces which don't contain power reactor modules - without reducing the number of groups. When doing this, be mindful of the fact that a block in a group of its own is worth 140e/s, while a block added to an existing group is only worth 25e/s if it doesn't also add to the physical size of the group.

The optimal layout for the 3x3 example above fills in as many spaces as possible in the cube without the two groups touching. By filling in empty spaces of the third example above, we can increase the BlockPower of each group to 250e/s, and we are left with only 7 empty spaces (6 exterior and the block in the middle is omitted). It looks like the following:

<gallery mode="traditional" widths=300px heights=300px perrow=1 caption="Optimal 3x3 reactor layout">
Image:3x3Maximized.jpg|A 3x3 cube with two reactor groups which maximizes the power output in the provided space. BlockPower=500e/s. SizePower=1499e/s TotalPower=1999e/s.
</gallery>

Once you have put in as many [[Power Reactor Module]]s as you can into the space, you can fill the remaining spaces with any other module, except you should not use [[Power Capacitor]]s because they can benefit from grouping as well, though it differs from power reactors. Using [[Shield Recharger]]s or [[Shield Capacitor|Shield Capacitors]] for this purpose is common.

Layouts need not be cube-shaped to be optimal, even though this page uses them for examples. The above 3x3x3 example is the optimal '''cubic''' structure, for the most power that can be generated in the smallest cubic volume, but does not provide the most power that can be generated for the blocks used, which is 20. The layout shape will typically be dictated by the ship or station dimensions. Keep in mind that since other shapes provide more power than a cubic volume, it is unlikely that a ship or station would be best served with a perfectly cubic power structure, even if the ship is itself a large cube.

<gallery mode="traditional" widths=900px heights=300px perrow=1 caption="Optimal maximum-output layouts">
Image:OptimalPowerStructures.jpg|Five reactor groups which maximize the power output for 20 blocks. BlockPower=500e/s. SizePower=3426.8e/s TotalPower=3926.8e/s.
</gallery>

Note that though not pictured above, a simple straight line of Power Reactor blocks is also a maximum-output layout as well.

In the picture above, the first structure on the left uses the same number of cubes as the 3x3x3 cubic power structure shown in the lower middle, but generates almost twice the power at 3926.8e/s. For 20 blocks, this is the maximum power that can be generated. However, other shapes can also achieve the same box dimension sum as the first structure. Each of the other four structures on the upper deck in the picture above '''also''' generate the maximum power of 3926.8e/s. Thus it is likely for almost any ship volume that a custom, non-cubic reactor structure will generate more power than simply using an efficient cubic volume. Furthermore, the true cubic volume of all of the structures in the image above is actually '''20'''. In other words, each of the above structures have an identical impact on the internal volume of a given ship, which is to consume 20 blocks of the ship's total internal volume, but the 3x3x3 cubic shape only generates '''half''' of the other structure's power per second.

The goal in design of a ship's power generation should be to both maximize the power reactor structure's box dimensions while also reserving large contiguous volumes within the ship for weapons and effects groups, functional areas like a core room, computer room, shuttle docking bay, or cargo hold, and usually some role-play areas, like a cockpit or command deck, medical facility, captain's quarters, corridors, elevators, etc. A cubic volume is not capable of fulfilling this goal.

Taking these things into consideration, the process for designing an optimized power system for a ship is:
# Build the largest optimized group possible within the volume of the ship. An optimized group is one in which each added power reactor always increases the block dimensions of the group.
# An allowed exception for the above rule would be, when following the inside of the hull from front to back, it might be necessary to go down before heading back up in order to go further to the back of the ship. (Some of the blocks won't increase the box-dimensions of the group, but they connect and make a contiguous group from front to back, so the group isn't optimal, but it is as close as possible while maximizing contiguous ship volume. Note that if a group consists of 100 blocks, but twenty of these blocks are connector blocks that do not increase the box-dimensions of the group, then this group should be considered as an 80-block system for purposes of calculating its SizePower, as the 20 connector blocks only add 25e/sec each, and do not increase the SizePower efficiency bonus.)
# Once the first group is laid in, if needing more e/sec, lay in parallel, un-connected groups, extending along the first group as far as possible. In most cases, it is possible to build with symmetry, thus building at least two groups at a time.
# Finally, even single reactors placed alone, unconnected, will yield 140e/sec, so filling in small pockets with single blocks is better than connecting them to existing groups if they do not also increase the box-dimensions of the group, in which case they only yield 25e/sec.

There is also a diminishing return as the e/sec of a ship approach 1 million e/sec. See the [[#Power Reactor Advanced Analysis|Advanced Analysis]] section below.

Additional optimal layouts may be found [[#Sample optimized reactor layouts|below]].

==Power Capacitor Rules==
[[Power Capacitor|Power Capacitors]] have a simpler equation governing their storage capacity, and designing layouts is subsequently vastly simpler.

<tt style="font-size: large">'''GroupPower''' = 1000 * '''NumBlocks'''1.05</tt>

Unlike [[Power Reactor Module|Power Reactor Modules]], there is no SumOfDimensions value, so the dimensions of the group are irrelevant. All that matters is how many modules are in the group. Since '''GroupPower''' is a power function again, the more blocks are in the group the more benefit the group gets from each block. This is called '''BonusPerBlock''' below. Thus, for a given number of [[Power Capacitor|Power Capacitors]] is it better to have fewer larger groups than many smaller groups.

''Ideally, a ship only has one group of Capacitors. Even if there are necessarily several clumps, they would have a line of capacitors running between them to connect them all into one group.''

Here's some sample group sizes and their value breakdowns. Note that values are rounded.

{|class="wikitable"
!NumBlocks !! GroupPower !! BonusPerBlock
|-
|1||1,000||0
|-
|2||2,071||35
|-
|3||3,169||56
|-
|4||4,287||72
|-
|5||5,419||84
|-
|6||6,562||94
|-
|7||7,715||102
|-
|8||8,877||110
|-
|9||10,045||116
|-
|10||11,220||122
|-
|50||60,802||216
|-
|100||125,893||259
|}

==Power Reactor Advanced Analysis==

This data is mostly of use for builders of large and very large ships. Even though a mid-sized ship might be able to make use of 1 million e/sec, it might not have the internal volume to make an optimized group of 500 or more power reactor modules. However, this analysis does show that small to medium ships should still try to utilize the largest optimized block structures that they can manage within the volume of their ship, as opposed to a higher number of smaller block structures, such as those used in the '''efficient cube''' structures.

The following table lists the SizePower value generated by an optimal group of blocks of the given number. Note that SizePower does not fully max out at 1,000,000 until the optimized group has 3374 blocks. An optimized group is one with the largest possible box-dimensions for the number of blocks, or a group in which no block fails to increase the box-dimensions of the group:

{|class="wikitable"
!Blocks !! Max SizePower !! BlockPower !! GroupPower !! Power/Block Ratio
|-
|25||4853.8||625.0||5478.8||219.2
|-
|50||14789.0||1250.0||16039.0||320.8
|-
|100||46459.4||2500.0||48959.4||489.6
|-
|200||147463.8||5000.0||152463.8||762.3
|-
|300||286080.1||7500.0||293580.1||978.6
|-
|400||445102.1||10000.0||455102.1||1137.8
|-
|500||603206.3||12500.0||615706.3||1231.4
|- style="font-style: bold; background-color: green;"
|594||732790.3||14850.0||747640.3||1258.7
|-
|600||740136.2||15000.0||755136.2||1258.6
|-
|700||843919.1||17500.0||861419.1||1230.6
|-
|800||913509.0||20000.0||933509.0||1166.9
|-
|900||955432.2||22500.0||977932.2||1086.6
|-
|1000||978486.0||25000.0||1003486.0||1003.5
|-
|1100||990213.8||27500.0||1017713.8||925.2
|-
|1200||995787.6||30000.0||1025787.6||854.8
|-
|1300||998279.2||32500.0||1030779.2||792.9
|-
|1400||999331.5||35000.0||1034331.5||738.8
|-
|1500||999752.7||37500.0||1037252.7||691.5
|-
|1600||999912.7||40000.0||1039912.7||649.9
|-
|1700||999970.6||42500.0||1042470.6||613.2
|-
|1800||999990.5||45000.0||1044990.5||580.6
|-
|1900||999997.1||47500.0||1047497.1||551.3
|-
|2000||999999.1||50000.0||1049999.1||525.0
|-
|2100||999999.8||52500.0||1052499.8||501.2
|-
|2200||999999.9||55000.0||1054999.9||479.5
|-
|2300||1000000.0||57500.0||1057500.0||459.8
|-
|2400||1000000.0||60000.0||1060000.0||441.7
|-
|2500||1000000.0||62500.0||1062500.0||425.0
|-
|2600||1000000.0||65000.0||1065000.0||409.6
|-
|2700||1000000.0||67500.0||1067500.0||395.4
|-
|2800||1000000.0||70000.0||1070000.0||382.1
|-
|2900||1000000.0||72500.0||1072500.0||369.8
|-
|3000||1000000.0||75000.0||1075000.0||358.3
|-
|3100||1000000.0||77500.0||1077500.0||347.6
|-
|3200||1000000.0||80000.0||1080000.0||337.5
|-
|3374||1000000.0||84350.0||1084350.0||321.4
|}

The above table is illustrated better in the following chart:

<gallery mode="traditional" widths=600px heights=400px perrow=1 caption="Graphs of SizePower and GroupPower per Block">
Image:Max_SizePower_Curve.jpg|SizePower per optimized group of blocks of a given number, and the GroupPower per Block of each group.
</gallery>

It is easy to see that SizePower has diminishing returns after about 600 blocks. The precise number is 594. This is the number of blocks in a group that yields the largest bonus per block, 1258.7, after which it begins to fall. This is due to the S-curve shape of the SizePower graph. Consequently, if building a large ship with thousands of power reactor blocks, ''it would seem'' the power system should be composed of optimized groups of about 500 to 700 blocks each, this range being close enough to 594 that it does not greatly affect the resulting e/sec produced by a large system. However, there is another diminishing return factor applied to multiple groups within a ship. For example, in the chart above a group of 1000 power reactors, optimally, yields 1003486.0 e/sec, and a group of 500 power reactors yields 615706.3 e/sec. This has been verified in-game with build '''.1867'''. However, using two groups of 500 power reactors does not yield double the 615706.3 e/sec value, but only 909558.9 instead. Likewise, 1200 blocks would yield 1025787.6 e/sec, but two groups of 600 only yield 986370.9 e/sec, not double the 755136.2 e/sec of one group of 600.

This diminishing return factor for groups is a soft limit which effectively limits ships to not much more than 1 million e/sec in practice. Consequently large ships are currently either limited to this value, or else use a ''docked '''power module''' daughter-ship'' and power drain beams to add more power generation capacity to a base ship.

To get to 1 million e/sec (using optimal layouts with each group):
{|class="wikitable"
!NumGroups!!GroupSize!!TotalBlocks!!SumGroupX!!MaxSizePower!!BlockPower!!TotalPower!!Power/Block
|-
|1||1000||1000||19515.0||978486.0||25000||1003486.0||1003.5
|-
|2||700||1400||21315.6||985772.0||35000||1020772.0||729.1
|-
|2||650||1300||18799.4||974655.6||32500||1007155.6||774.7
|-
|3||500||1500||18080.5||970131.0||37500||1007631.0||671.8
|-
|4||400||1600||16524.9||957445.3||40000||997445.3||623.4
|-
|6||300||1800||15242.5||943141.8||45000||988141.8||549.0
|-
|12||200||2400||15387.7||944970.1||60000||1004970.1||418.7
|-
|18||150||2700||14233.1||928695.3||67500||996195.3||369.0
|-
|34||100||3400||13645.6||918720.2||85000||1003720.2||295.2
|-
|52||75||3900.0||12939.9||904968.8||97500||1002468.8||257.0
|-
|94||50||4700.0||12001.3||883230.7||117500||1000730.7||212.9
|-
|253||25||6325.0||10600.7||842003.8||158125||1000128.8||158.1
|}

In terms of ship mass, larger groups are more efficient.

==Sample Optimized Reactor Layouts==

<gallery mode="traditional" widths=300px heights=300px perrow=2 caption="Optimal 2x2 and 3x3 reactor layouts">
Image:2x2Maximized.jpg|A 2x2 cube with two reactor groups. BlockPower=125e (100+25) SizePower=492e (376+115) TotalPower=617e
Image:3x3Maximized.jpg|A 3x3 cube with two reactor groups. BlockPower=500e (250+250) SizePower=1499e (749 + 749) TotalPower=1999e
</gallery>

<gallery mode="traditional" widths=300px heights=300px perrow=4 caption="Optimal 4x4 reactor layout">
Image:4x4MaximizedLayer1.jpg|A 4x4 cube with four reactor groups - layer 1. BlockPower=825e (100+200+250+275) SizePower=3719e (376+897+1223+1223) TotalPower=4544e
Image:4x4MaximizedLayer2.jpg|A 4x4 cube with four reactor groups - layer 2.
Image:4x4MaximizedLayer3.jpg|A 4x4 cube with four reactor groups - layer 3.
Image:4x4MaximizedLayer4.jpg|A 4x4 cube with four reactor groups - layer 4.
</gallery>

<gallery mode="traditional" widths=1000px heights=200px perrow=1 caption="Optimal 5x5 reactor layout">
Image:Power Block Compact.png|A 5x5 cube with 5 reactor groups. BlockPower=1725e (375+375+375+375+225) SizePower=8282e (1787+1787+1787+1787+1054) TotalPower=9927e
</gallery>

[[Category:Articles]]
[[Category:Game Mechanics]]

Legacy Power Systems

2016-08-06T08:52:42Z

Olxinos: /* Relationship between BlockPower, SizePower and TotalPower */

This page describes the power generation and storage mechanisms in '''StarMade'''.

==Power Generation and Storage Blocks==
Power is generated using the [[Power Reactor Module]], though on ships, the [[Ship Core]] will generate 1 energy (or e) per second (called e/s) by itself. [[Planet|Planets]] and [[Space Station|Space Stations]] do not generate any power by themselves. There is a default storage amount of 50,000e on ships, but no default storage for planets and space stations. Power storage can be augmented using [[Power Capacitor|Power Capacitors]]. While these units can be placed anywhere on a ship, planet or station and contribute to either power generation or storage respectively, they are more effective when arranged according to the rules described below. This is particularly important when space is constrained as on most ships.

An important consideration regarding power capacity is that all systems use power from the '''capacity''' of a ship or station. If the instantaneous demand for power is not satisfied by the remaining capacity, then the action that is demanding the power will fail to occur. For example, one or all of the missiles that have been commanded to fire will fail to fire due to demanding more power than is currently in storage. However, the power will not be consumed by the failed action. At a minimum, a ship or station should have enough capacity to at least simultaneously fire all the weapon systems attached. Other considerations are the constant demand being made by always-active systems, and how much simultaneous demand will be made when shields begin to recharge, and thrusters need to fire. Power generation is used to refill the power capacity of a ship or station, and needs to be large enough to provide power during sustained demand. Power generation need not equal or exceed all possible demands. For example, charging a jump drive may drain the capacity faster than the power generation can refill it, but as long as the capacity is enough to charge the jump drive without being fully drained, this may be considered to be more than adequate for a given ship.

==Power Reactor Rules (Single Group Formula)==
[[Power Reactor Module|Power Reactors]] have a somewhat complex set of rules associated with them when it comes to creating efficient or compact power systems. This comes from how their power output is calculated, which is not simply by adding up the blocks and multiplying them by some power factor. Instead, the formula for a '''single''' [[Module Group|group]] of power reactors is as follows:

<tt style="font-size: large">'''GroupPower''' = BlockPower + SizePower</tt>

where:

<tt style="font-size: large">'''BlockPower''' = 25 * NumberOfBlocks</tt>

and:

<tt style="font-size: large">'''SizePower''' = 2000000 / ( 1 + 1,000348-0.333*(SumOfDimensions/3)1.7) - 1000000</tt>

'''GroupPower''' is fairly straightforward, as it is the simple sum of the other two pieces.

'''BlockPower''' is the amount of power contributed directly by the [[Power Reactor Module]]s in the group, which is just 25e per module.

'''SizePower''' is the amount of power contributed by the '''size''' of the group, and is only dependent on '''SumOfDimensions''' which is the sum of the dimensions of the smallest bounding box which can encompass the entire group. Because SumOfDimensions is a plain sum, a 3x3x3 box, 1x1x7 box and a 2x2x5 box are the same (9) for the purposes of this part of the equation. This is the part of the equation which is most important when considering how to maximize a group of reactors because SizePower is a power function, which means that each successive incremental increase in the value of SumOfDimensions gives much greater benefits than the next lower value.

Note that SizePower caps out at 1,000,000e. Also note that for multiple reactor groups, the above formula is modified, and results in a diminishing return. Total Power of a ship is not the sum of the Group Power of each group. See the [[#Power Reactor Advanced Analysis|Advanced Analysis]] section for a more detailed explanation of the equation.

Here are some examples of power reactor groups and how their power outputs are calculated.

<gallery mode="traditional" widths=300px heights=300px perrow=3 caption="Example power reactor groups and power values">
Image:Bounding Box 1.jpg|A power reactor by itself has a bounding box with dimensions 1 x 1 x 1. SumOfDimensions=3. BlockPower=25e. SizePower=115e. GroupPower=140e.
Image:Bounding Box 2.jpg|A power reactor group of 3 modules with a bounding box with dimensions 2 x 1 x 2. SumOfDimensions=5. BlockPower=75e. SizePower=276e. GroupPower=351e.
Image:Bounding Box 3.jpg|A power reactor group of 7 modules with a bounding box with dimensions 3 x 3 x 3. SumOfDimensions=9. BlockPower =175e. SizePower=749e. GroupPower=924e.
</gallery>

===Relationship between BlockPower, SizePower and TotalPower===

When there is only one power reactor block group in or on an entity, the GroupPower and the total power of the entity is identical. However, when there is more than one group, the total power provided to a ship, station or planet is ''not'' the sum of the GroupPower of all groups. Rather, '''TotalPower''' of an entity with multiple power reactor groups is subject to diminishing returns, and is given by the following formula:

<tt style="font-size: large">'''TotalPower''' = BlockPower + GroupSumSizePower</tt>

where:

<tt style="font-size: large">'''BlockPower''' = 25 * TotalNumberOfBlocksInAllGroups</tt>

and:

<tt style="font-size: large">'''GroupSumSizePower''' = 2000000 / ( 1 + 1.000348-0.333 * GroupSumPower) - 1000000</tt>

where:

<tt style="font-size:large">'''GroupSumPower''' = (SumOfDimensionsOfGroup1/3)1.7 + (SumOfDimensionsOfGroup2/3)1.7 ... + (SumOfDimensionsOfGroup''n''/3)1.7</tt>, where ''n'' is the number of groups.

To understand the relationship between SizePower, BlockPower and TotalPower, consider a 3x3 space in which to place a set of reactor modules. Below are three layouts in this 3x3 space. Note that values are rounded which may lead to small apparent discrepancies.

<gallery mode="traditional" widths=300px heights=300px perrow=3 caption="Example 3x3 layouts with power values">
Image:3x3Cube.jpg|A single power reactor group of 27 modules in a 3x3 space. BlockPower=675e. SizePower=749e. TotalPower=1424e
Image:3x3SingleEdge.jpg|A single power reactor group of 7 modules in a 3x3 space. BlockPower=175e. SizePower=749e. TotalPower=924e.
Image:3x3DoubleEdge.jpg|Two power reactor groups of 7 modules each (14 total modules) in a 3x3 space. BlockPower=175e each (350e total). SizePower=749e each (1499e total). TotalPower=1849e.
</gallery>

Notice that the first and second versions have the same SizePower, as SizePower depends only on the dimensions of the group and not the number of blocks. The first of course produces more total power than the second because it has more blocks and each only has a single group, but SizePower still contributes more to the total than the number of blocks does. Then look at the third version, which has the same dimensions but two groups instead of one. The SizePower is twice that of the other two because there are two groups and because SizePower counts for much more than BlockPower the TotalPower of the third version is much higher than the first one, in spite of only having half as many blocks in it (and thus a lower BlockPower).

Please note that with the very small groups in the cubic structure above, the diminishing returns of TotalPower with multiple groups is not noticeable with such small power output rounded to a whole number. But note the case of a group of 1000 power reactors in one group, 500 in one group, and finally a third case of two groups of 500, for a total of 1000 blocks.

# 1000 in one group: GroupPower/TotalPower = 1003486.0 e/sec
# 500 in one group: GroupPower/TotalPower = 615706.3 e/sec
# 1000 in two groups of 500: TotalPower = 909558.9 e/sec, not the sum of 615706.3 twice.

===Optimal layouts===
None of the examples above are optimal layouts for the cubic 3x3x3 volume, though the third version is getting close. To create an optimal layout in a given space is rather complex, but it boils down to the following three rules:
* Maximize the SumOfDimensions for each group, because this contributes the most to the power equation through SizePower.
* Maximize the number of such groups in the space, because this allows you to take advantage of SizePower for each group
* Minimize the number of empty spaces - that is, spaces which don't contain power reactor modules - without reducing the number of groups. When doing this, be mindful of the fact that a block in a group of its own is worth 140e/s, while a block added to an existing group is only worth 25e/s if it doesn't also add to the physical size of the group.

The optimal layout for the 3x3 example above fills in as many spaces as possible in the cube without the two groups touching. By filling in empty spaces of the third example above, we can increase the BlockPower of each group to 250e/s, and we are left with only 7 empty spaces (6 exterior and the block in the middle is omitted). It looks like the following:

<gallery mode="traditional" widths=300px heights=300px perrow=1 caption="Optimal 3x3 reactor layout">
Image:3x3Maximized.jpg|A 3x3 cube with two reactor groups which maximizes the power output in the provided space. BlockPower=500e/s. SizePower=1499e/s TotalPower=1999e/s.
</gallery>

Once you have put in as many [[Power Reactor Module]]s as you can into the space, you can fill the remaining spaces with any other module, except you should not use [[Power Capacitor]]s because they can benefit from grouping as well, though it differs from power reactors. Using [[Shield Recharger]]s or [[Shield Capacitor|Shield Capacitors]] for this purpose is common.

Layouts need not be cube-shaped to be optimal, even though this page uses them for examples. The above 3x3x3 example is the optimal '''cubic''' structure, for the most power that can be generated in the smallest cubic volume, but does not provide the most power that can be generated for the blocks used, which is 20. The layout shape will typically be dictated by the ship or station dimensions. Keep in mind that since other shapes provide more power than a cubic volume, it is unlikely that a ship or station would be best served with a perfectly cubic power structure, even if the ship is itself a large cube.

<gallery mode="traditional" widths=900px heights=300px perrow=1 caption="Optimal maximum-output layouts">
Image:OptimalPowerStructures.jpg|Five reactor groups which maximize the power output for 20 blocks. BlockPower=500e/s. SizePower=3426.8e/s TotalPower=3926.8e/s.
</gallery>

Note that though not pictured above, a simple straight line of Power Reactor blocks is also a maximum-output layout as well.

In the picture above, the first structure on the left uses the same number of cubes as the 3x3x3 cubic power structure shown in the lower middle, but generates almost twice the power at 3926.8e/s. For 20 blocks, this is the maximum power that can be generated. However, other shapes can also achieve the same box dimension sum as the first structure. Each of the other four structures on the upper deck in the picture above '''also''' generate the maximum power of 3926.8e/s. Thus it is likely for almost any ship volume that a custom, non-cubic reactor structure will generate more power than simply using an efficient cubic volume. Furthermore, the true cubic volume of all of the structures in the image above is actually '''20'''. In other words, each of the above structures have an identical impact on the internal volume of a given ship, which is to consume 20 blocks of the ship's total internal volume, but the 3x3x3 cubic shape only generates '''half''' of the other structure's power per second.

The goal in design of a ship's power generation should be to both maximize the power reactor structure's box dimensions while also reserving large contiguous volumes within the ship for weapons and effects groups, functional areas like a core room, computer room, shuttle docking bay, or cargo hold, and usually some role-play areas, like a cockpit or command deck, medical facility, captain's quarters, corridors, elevators, etc. A cubic volume is not capable of fulfilling this goal.

Taking these things into consideration, the process for designing an optimized power system for a ship is:
# Build the largest optimized group possible within the volume of the ship. An optimized group is one in which each added power reactor always increases the block dimensions of the group.
# An allowed exception for the above rule would be, when following the inside of the hull from front to back, it might be necessary to go down before heading back up in order to go further to the back of the ship. (Some of the blocks won't increase the box-dimensions of the group, but they connect and make a contiguous group from front to back, so the group isn't optimal, but it is as close as possible while maximizing contiguous ship volume. Note that if a group consists of 100 blocks, but twenty of these blocks are connector blocks that do not increase the box-dimensions of the group, then this group should be considered as an 80-block system for purposes of calculating its SizePower, as the 20 connector blocks only add 25e/sec each, and do not increase the SizePower efficiency bonus.)
# Once the first group is laid in, if needing more e/sec, lay in parallel, un-connected groups, extending along the first group as far as possible. In most cases, it is possible to build with symmetry, thus building at least two groups at a time.
# Finally, even single reactors placed alone, unconnected, will yield 140e/sec, so filling in small pockets with single blocks is better than connecting them to existing groups if they do not also increase the box-dimensions of the group, in which case they only yield 25e/sec.

There is also a diminishing return as the e/sec of a ship approach 1 million e/sec. See the [[#Power Reactor Advanced Analysis|Advanced Analysis]] section below.

Additional optimal layouts may be found [[#Sample optimized reactor layouts|below]].

==Power Capacitor Rules==
[[Power Capacitor|Power Capacitors]] have a simpler equation governing their storage capacity, and designing layouts is subsequently vastly simpler.

<tt style="font-size: large">'''GroupPower''' = 1000 * '''NumBlocks'''1.05</tt>

Unlike [[Power Reactor Module|Power Reactor Modules]], there is no SumOfDimensions value, so the dimensions of the group are irrelevant. All that matters is how many modules are in the group. Since '''GroupPower''' is a power function again, the more blocks are in the group the more benefit the group gets from each block. This is called '''BonusPerBlock''' below. Thus, for a given number of [[Power Capacitor|Power Capacitors]] is it better to have fewer larger groups than many smaller groups.

''Ideally, a ship only has one group of Capacitors. Even if there are necessarily several clumps, they would have a line of capacitors running between them to connect them all into one group.''

Here's some sample group sizes and their value breakdowns. Note that values are rounded.

{|class="wikitable"
!NumBlocks !! GroupPower !! BonusPerBlock
|-
|1||1,000||0
|-
|2||2,071||35
|-
|3||3,169||56
|-
|4||4,287||72
|-
|5||5,419||84
|-
|6||6,562||94
|-
|7||7,715||102
|-
|8||8,877||110
|-
|9||10,045||116
|-
|10||11,220||122
|-
|50||60,802||216
|-
|100||125,893||259
|}

==Power Reactor Advanced Analysis==

This data is mostly of use for builders of large and very large ships. Even though a mid-sized ship might be able to make use of 1 million e/sec, it might not have the internal volume to make an optimized group of 500 or more power reactor modules. However, this analysis does show that small to medium ships should still try to utilize the largest optimized block structures that they can manage within the volume of their ship, as opposed to a higher number of smaller block structures, such as those used in the '''efficient cube''' structures.

The following table lists the SizePower value generated by an optimal group of blocks of the given number. Note that SizePower does not fully max out at 1,000,000 until the optimized group has 3374 blocks. An optimized group is one with the largest possible box-dimensions for the number of blocks, or a group in which no block fails to increase the box-dimensions of the group:

{|class="wikitable"
!Blocks !! Max SizePower !! BlockPower !! GroupPower !! Power/Block Ratio
|-
|25||4853.8||625.0||5478.8||219.2
|-
|50||14789.0||1250.0||16039.0||320.8
|-
|100||46459.4||2500.0||48959.4||489.6
|-
|200||147463.8||5000.0||152463.8||762.3
|-
|300||286080.1||7500.0||293580.1||978.6
|-
|400||445102.1||10000.0||455102.1||1137.8
|-
|500||603206.3||12500.0||615706.3||1231.4
|- style="font-style: bold; background-color: green;"
|594||732790.3||14850.0||747640.3||1258.7
|-
|600||740136.2||15000.0||755136.2||1258.6
|-
|700||843919.1||17500.0||861419.1||1230.6
|-
|800||913509.0||20000.0||933509.0||1166.9
|-
|900||955432.2||22500.0||977932.2||1086.6
|-
|1000||978486.0||25000.0||1003486.0||1003.5
|-
|1100||990213.8||27500.0||1017713.8||925.2
|-
|1200||995787.6||30000.0||1025787.6||854.8
|-
|1300||998279.2||32500.0||1030779.2||792.9
|-
|1400||999331.5||35000.0||1034331.5||738.8
|-
|1500||999752.7||37500.0||1037252.7||691.5
|-
|1600||999912.7||40000.0||1039912.7||649.9
|-
|1700||999970.6||42500.0||1042470.6||613.2
|-
|1800||999990.5||45000.0||1044990.5||580.6
|-
|1900||999997.1||47500.0||1047497.1||551.3
|-
|2000||999999.1||50000.0||1049999.1||525.0
|-
|2100||999999.8||52500.0||1052499.8||501.2
|-
|2200||999999.9||55000.0||1054999.9||479.5
|-
|2300||1000000.0||57500.0||1057500.0||459.8
|-
|2400||1000000.0||60000.0||1060000.0||441.7
|-
|2500||1000000.0||62500.0||1062500.0||425.0
|-
|2600||1000000.0||65000.0||1065000.0||409.6
|-
|2700||1000000.0||67500.0||1067500.0||395.4
|-
|2800||1000000.0||70000.0||1070000.0||382.1
|-
|2900||1000000.0||72500.0||1072500.0||369.8
|-
|3000||1000000.0||75000.0||1075000.0||358.3
|-
|3100||1000000.0||77500.0||1077500.0||347.6
|-
|3200||1000000.0||80000.0||1080000.0||337.5
|-
|3374||1000000.0||84350.0||1084350.0||321.4
|}

The above table is illustrated better in the following chart:

<gallery mode="traditional" widths=600px heights=400px perrow=1 caption="Graphs of SizePower and GroupPower per Block">
Image:Max_SizePower_Curve.jpg|SizePower per optimized group of blocks of a given number, and the GroupPower per Block of each group.
</gallery>

It is easy to see that SizePower has diminishing returns after about 600 blocks. The precise number is 594. This is the number of blocks in a group that yields the largest bonus per block, 1258.7, after which it begins to fall. This is due to the S-curve shape of the SizePower graph. Consequently, if building a large ship with thousands of power reactor blocks, ''it would seem'' the power system should be composed of optimized groups of about 500 to 700 blocks each, this range being close enough to 594 that it does not greatly affect the resulting e/sec produced by a large system. However, there is another diminishing return factor applied to multiple groups within a ship. For example, in the chart above a group of 1000 power reactors, optimally, yields 1003486.0 e/sec, and a group of 500 power reactors yields 615706.3 e/sec. This has been verified in-game with build '''.1867'''. However, using two groups of 500 power reactors does not yield double the 615706.3 e/sec value, but only 909558.9 instead. Likewise, 1200 blocks would yield 1025787.6 e/sec, but two groups of 600 only yield 986370.9 e/sec, not double the 755136.2 e/sec of one group of 600.

This diminishing return factor for groups is a soft limit which effectively limits ships to not much more than 1 million e/sec in practice. Consequently large ships are currently either limited to this value, or else use a ''docked '''power module''' daughter-ship'' and power drain beams to add more power generation capacity to a base ship.

To get to 1 million e/sec (using optimal layouts with each group):
{|class="wikitable"
!NumGroups!!GroupSize!!TotalBlocks!!SumGroupX!!MaxSizePower!!BlockPower!!TotalPower!!Power/Block
|-
|1||1000||1000||19515.0||978486.0||25000||1003486.0||1003.5
|-
|2||700||1400||21315.6||985772.0||35000||1020772.0||729.1
|-
|2||650||1300||18799.4||974655.6||32500||1007155.6||774.7
|-
|3||500||1500||18080.5||970131.0||37500||1007631.0||671.8
|-
|4||400||1600||16524.9||957445.3||40000||997445.3||623.4
|-
|6||300||1800||15242.5||943141.8||45000||988141.8||549.0
|-
|12||200||2400||15387.7||944970.1||60000||1004970.1||418.7
|-
|18||150||2700||14233.1||928695.3||67500||996195.3||369.0
|-
|34||100||3400||13645.6||918720.2||85000||1003720.2||295.2
|-
|52||75||3900.0||12939.9||904968.8||97500||1002468.8||257.0
|-
|94||50||4700.0||12001.3||883230.7||117500||1000730.7||212.9
|-
|253||25||6325.0||10600.7||842003.8||158125||1000128.8||158.1
|}

In terms of ship mass, larger groups are more efficient.

==Sample Optimized Reactor Layouts==

<gallery mode="traditional" widths=300px heights=300px perrow=2 caption="Optimal 2x2 and 3x3 reactor layouts">
Image:2x2Maximized.jpg|A 2x2 cube with two reactor groups. BlockPower=125e (100+25) SizePower=492e (376+115) TotalPower=617e
Image:3x3Maximized.jpg|A 3x3 cube with two reactor groups. BlockPower=500e (250+250) SizePower=1499e (749 + 749) TotalPower=1999e
</gallery>

<gallery mode="traditional" widths=300px heights=300px perrow=4 caption="Optimal 4x4 reactor layout">
Image:4x4MaximizedLayer1.jpg|A 4x4 cube with four reactor groups - layer 1. BlockPower=825e (100+200+250+275) SizePower=3719e (376+897+1223+1223) TotalPower=4544e
Image:4x4MaximizedLayer2.jpg|A 4x4 cube with four reactor groups - layer 2.
Image:4x4MaximizedLayer3.jpg|A 4x4 cube with four reactor groups - layer 3.
Image:4x4MaximizedLayer4.jpg|A 4x4 cube with four reactor groups - layer 4.
</gallery>

<gallery mode="traditional" widths=1000px heights=200px perrow=1 caption="Optimal 5x5 reactor layout">
Image:Power Block Compact.png|A 5x5 cube with 5 reactor groups. BlockPower=1725e (375+375+375+375+225) SizePower=8282e (1787+1787+1787+1787+1054) TotalPower=9927e
</gallery>

[[Category:Articles]]
[[Category:Game Mechanics]]

Legacy Power Systems

2016-08-06T08:51:56Z

Olxinos: /* Power Reactor Rules (Single Group Formula) */

This page describes the power generation and storage mechanisms in '''StarMade'''.

==Power Generation and Storage Blocks==
Power is generated using the [[Power Reactor Module]], though on ships, the [[Ship Core]] will generate 1 energy (or e) per second (called e/s) by itself. [[Planet|Planets]] and [[Space Station|Space Stations]] do not generate any power by themselves. There is a default storage amount of 50,000e on ships, but no default storage for planets and space stations. Power storage can be augmented using [[Power Capacitor|Power Capacitors]]. While these units can be placed anywhere on a ship, planet or station and contribute to either power generation or storage respectively, they are more effective when arranged according to the rules described below. This is particularly important when space is constrained as on most ships.

An important consideration regarding power capacity is that all systems use power from the '''capacity''' of a ship or station. If the instantaneous demand for power is not satisfied by the remaining capacity, then the action that is demanding the power will fail to occur. For example, one or all of the missiles that have been commanded to fire will fail to fire due to demanding more power than is currently in storage. However, the power will not be consumed by the failed action. At a minimum, a ship or station should have enough capacity to at least simultaneously fire all the weapon systems attached. Other considerations are the constant demand being made by always-active systems, and how much simultaneous demand will be made when shields begin to recharge, and thrusters need to fire. Power generation is used to refill the power capacity of a ship or station, and needs to be large enough to provide power during sustained demand. Power generation need not equal or exceed all possible demands. For example, charging a jump drive may drain the capacity faster than the power generation can refill it, but as long as the capacity is enough to charge the jump drive without being fully drained, this may be considered to be more than adequate for a given ship.

==Power Reactor Rules (Single Group Formula)==
[[Power Reactor Module|Power Reactors]] have a somewhat complex set of rules associated with them when it comes to creating efficient or compact power systems. This comes from how their power output is calculated, which is not simply by adding up the blocks and multiplying them by some power factor. Instead, the formula for a '''single''' [[Module Group|group]] of power reactors is as follows:

<tt style="font-size: large">'''GroupPower''' = BlockPower + SizePower</tt>

where:

<tt style="font-size: large">'''BlockPower''' = 25 * NumberOfBlocks</tt>

and:

<tt style="font-size: large">'''SizePower''' = 2000000 / ( 1 + 1,000348-0.333*(SumOfDimensions/3)1.7) - 1000000</tt>

'''GroupPower''' is fairly straightforward, as it is the simple sum of the other two pieces.

'''BlockPower''' is the amount of power contributed directly by the [[Power Reactor Module]]s in the group, which is just 25e per module.

'''SizePower''' is the amount of power contributed by the '''size''' of the group, and is only dependent on '''SumOfDimensions''' which is the sum of the dimensions of the smallest bounding box which can encompass the entire group. Because SumOfDimensions is a plain sum, a 3x3x3 box, 1x1x7 box and a 2x2x5 box are the same (9) for the purposes of this part of the equation. This is the part of the equation which is most important when considering how to maximize a group of reactors because SizePower is a power function, which means that each successive incremental increase in the value of SumOfDimensions gives much greater benefits than the next lower value.

Note that SizePower caps out at 1,000,000e. Also note that for multiple reactor groups, the above formula is modified, and results in a diminishing return. Total Power of a ship is not the sum of the Group Power of each group. See the [[#Power Reactor Advanced Analysis|Advanced Analysis]] section for a more detailed explanation of the equation.

Here are some examples of power reactor groups and how their power outputs are calculated.

<gallery mode="traditional" widths=300px heights=300px perrow=3 caption="Example power reactor groups and power values">
Image:Bounding Box 1.jpg|A power reactor by itself has a bounding box with dimensions 1 x 1 x 1. SumOfDimensions=3. BlockPower=25e. SizePower=115e. GroupPower=140e.
Image:Bounding Box 2.jpg|A power reactor group of 3 modules with a bounding box with dimensions 2 x 1 x 2. SumOfDimensions=5. BlockPower=75e. SizePower=276e. GroupPower=351e.
Image:Bounding Box 3.jpg|A power reactor group of 7 modules with a bounding box with dimensions 3 x 3 x 3. SumOfDimensions=9. BlockPower =175e. SizePower=749e. GroupPower=924e.
</gallery>

===Relationship between BlockPower, SizePower and TotalPower===

When there is only one power reactor block group in or on an entity, the GroupPower and the total power of the entity is identical. However, when there is more than one group, the total power provided to a ship, station or planet is ''not'' the sum of the GroupPower of all groups. Rather, '''TotalPower''' of an entity with multiple power reactor groups is subject to diminishing returns, and is given by the following formula:

<tt style="font-size: large">'''TotalPower''' = BlockPower + GroupSumSizePower</tt>

where:

<tt style="font-size: large">'''BlockPower''' = 25 * TotalNumberOfBlocksInAllGroups</tt>

and:

<tt style="font-size: large">'''GroupSumSizePower''' = 2000000 / ( 1 + 1.000696-0.333 * GroupSumPower) - 1000000</tt>

where:

<tt style="font-size:large">'''GroupSumPower''' = (SumOfDimensionsOfGroup1/3)1.7 + (SumOfDimensionsOfGroup2/3)1.7 ... + (SumOfDimensionsOfGroup''n''/3)1.7</tt>, where ''n'' is the number of groups.

To understand the relationship between SizePower, BlockPower and TotalPower, consider a 3x3 space in which to place a set of reactor modules. Below are three layouts in this 3x3 space. Note that values are rounded which may lead to small apparent discrepancies.

<gallery mode="traditional" widths=300px heights=300px perrow=3 caption="Example 3x3 layouts with power values">
Image:3x3Cube.jpg|A single power reactor group of 27 modules in a 3x3 space. BlockPower=675e. SizePower=749e. TotalPower=1424e
Image:3x3SingleEdge.jpg|A single power reactor group of 7 modules in a 3x3 space. BlockPower=175e. SizePower=749e. TotalPower=924e.
Image:3x3DoubleEdge.jpg|Two power reactor groups of 7 modules each (14 total modules) in a 3x3 space. BlockPower=175e each (350e total). SizePower=749e each (1499e total). TotalPower=1849e.
</gallery>

Notice that the first and second versions have the same SizePower, as SizePower depends only on the dimensions of the group and not the number of blocks. The first of course produces more total power than the second because it has more blocks and each only has a single group, but SizePower still contributes more to the total than the number of blocks does. Then look at the third version, which has the same dimensions but two groups instead of one. The SizePower is twice that of the other two because there are two groups and because SizePower counts for much more than BlockPower the TotalPower of the third version is much higher than the first one, in spite of only having half as many blocks in it (and thus a lower BlockPower).

Please note that with the very small groups in the cubic structure above, the diminishing returns of TotalPower with multiple groups is not noticeable with such small power output rounded to a whole number. But note the case of a group of 1000 power reactors in one group, 500 in one group, and finally a third case of two groups of 500, for a total of 1000 blocks.

# 1000 in one group: GroupPower/TotalPower = 1003486.0 e/sec
# 500 in one group: GroupPower/TotalPower = 615706.3 e/sec
# 1000 in two groups of 500: TotalPower = 909558.9 e/sec, not the sum of 615706.3 twice.

===Optimal layouts===
None of the examples above are optimal layouts for the cubic 3x3x3 volume, though the third version is getting close. To create an optimal layout in a given space is rather complex, but it boils down to the following three rules:
* Maximize the SumOfDimensions for each group, because this contributes the most to the power equation through SizePower.
* Maximize the number of such groups in the space, because this allows you to take advantage of SizePower for each group
* Minimize the number of empty spaces - that is, spaces which don't contain power reactor modules - without reducing the number of groups. When doing this, be mindful of the fact that a block in a group of its own is worth 140e/s, while a block added to an existing group is only worth 25e/s if it doesn't also add to the physical size of the group.

The optimal layout for the 3x3 example above fills in as many spaces as possible in the cube without the two groups touching. By filling in empty spaces of the third example above, we can increase the BlockPower of each group to 250e/s, and we are left with only 7 empty spaces (6 exterior and the block in the middle is omitted). It looks like the following:

<gallery mode="traditional" widths=300px heights=300px perrow=1 caption="Optimal 3x3 reactor layout">
Image:3x3Maximized.jpg|A 3x3 cube with two reactor groups which maximizes the power output in the provided space. BlockPower=500e/s. SizePower=1499e/s TotalPower=1999e/s.
</gallery>

Once you have put in as many [[Power Reactor Module]]s as you can into the space, you can fill the remaining spaces with any other module, except you should not use [[Power Capacitor]]s because they can benefit from grouping as well, though it differs from power reactors. Using [[Shield Recharger]]s or [[Shield Capacitor|Shield Capacitors]] for this purpose is common.

Layouts need not be cube-shaped to be optimal, even though this page uses them for examples. The above 3x3x3 example is the optimal '''cubic''' structure, for the most power that can be generated in the smallest cubic volume, but does not provide the most power that can be generated for the blocks used, which is 20. The layout shape will typically be dictated by the ship or station dimensions. Keep in mind that since other shapes provide more power than a cubic volume, it is unlikely that a ship or station would be best served with a perfectly cubic power structure, even if the ship is itself a large cube.

<gallery mode="traditional" widths=900px heights=300px perrow=1 caption="Optimal maximum-output layouts">
Image:OptimalPowerStructures.jpg|Five reactor groups which maximize the power output for 20 blocks. BlockPower=500e/s. SizePower=3426.8e/s TotalPower=3926.8e/s.
</gallery>

Note that though not pictured above, a simple straight line of Power Reactor blocks is also a maximum-output layout as well.

In the picture above, the first structure on the left uses the same number of cubes as the 3x3x3 cubic power structure shown in the lower middle, but generates almost twice the power at 3926.8e/s. For 20 blocks, this is the maximum power that can be generated. However, other shapes can also achieve the same box dimension sum as the first structure. Each of the other four structures on the upper deck in the picture above '''also''' generate the maximum power of 3926.8e/s. Thus it is likely for almost any ship volume that a custom, non-cubic reactor structure will generate more power than simply using an efficient cubic volume. Furthermore, the true cubic volume of all of the structures in the image above is actually '''20'''. In other words, each of the above structures have an identical impact on the internal volume of a given ship, which is to consume 20 blocks of the ship's total internal volume, but the 3x3x3 cubic shape only generates '''half''' of the other structure's power per second.

The goal in design of a ship's power generation should be to both maximize the power reactor structure's box dimensions while also reserving large contiguous volumes within the ship for weapons and effects groups, functional areas like a core room, computer room, shuttle docking bay, or cargo hold, and usually some role-play areas, like a cockpit or command deck, medical facility, captain's quarters, corridors, elevators, etc. A cubic volume is not capable of fulfilling this goal.

Taking these things into consideration, the process for designing an optimized power system for a ship is:
# Build the largest optimized group possible within the volume of the ship. An optimized group is one in which each added power reactor always increases the block dimensions of the group.
# An allowed exception for the above rule would be, when following the inside of the hull from front to back, it might be necessary to go down before heading back up in order to go further to the back of the ship. (Some of the blocks won't increase the box-dimensions of the group, but they connect and make a contiguous group from front to back, so the group isn't optimal, but it is as close as possible while maximizing contiguous ship volume. Note that if a group consists of 100 blocks, but twenty of these blocks are connector blocks that do not increase the box-dimensions of the group, then this group should be considered as an 80-block system for purposes of calculating its SizePower, as the 20 connector blocks only add 25e/sec each, and do not increase the SizePower efficiency bonus.)
# Once the first group is laid in, if needing more e/sec, lay in parallel, un-connected groups, extending along the first group as far as possible. In most cases, it is possible to build with symmetry, thus building at least two groups at a time.
# Finally, even single reactors placed alone, unconnected, will yield 140e/sec, so filling in small pockets with single blocks is better than connecting them to existing groups if they do not also increase the box-dimensions of the group, in which case they only yield 25e/sec.

There is also a diminishing return as the e/sec of a ship approach 1 million e/sec. See the [[#Power Reactor Advanced Analysis|Advanced Analysis]] section below.

Additional optimal layouts may be found [[#Sample optimized reactor layouts|below]].

==Power Capacitor Rules==
[[Power Capacitor|Power Capacitors]] have a simpler equation governing their storage capacity, and designing layouts is subsequently vastly simpler.

<tt style="font-size: large">'''GroupPower''' = 1000 * '''NumBlocks'''1.05</tt>

Unlike [[Power Reactor Module|Power Reactor Modules]], there is no SumOfDimensions value, so the dimensions of the group are irrelevant. All that matters is how many modules are in the group. Since '''GroupPower''' is a power function again, the more blocks are in the group the more benefit the group gets from each block. This is called '''BonusPerBlock''' below. Thus, for a given number of [[Power Capacitor|Power Capacitors]] is it better to have fewer larger groups than many smaller groups.

''Ideally, a ship only has one group of Capacitors. Even if there are necessarily several clumps, they would have a line of capacitors running between them to connect them all into one group.''

Here's some sample group sizes and their value breakdowns. Note that values are rounded.

{|class="wikitable"
!NumBlocks !! GroupPower !! BonusPerBlock
|-
|1||1,000||0
|-
|2||2,071||35
|-
|3||3,169||56
|-
|4||4,287||72
|-
|5||5,419||84
|-
|6||6,562||94
|-
|7||7,715||102
|-
|8||8,877||110
|-
|9||10,045||116
|-
|10||11,220||122
|-
|50||60,802||216
|-
|100||125,893||259
|}

==Power Reactor Advanced Analysis==

This data is mostly of use for builders of large and very large ships. Even though a mid-sized ship might be able to make use of 1 million e/sec, it might not have the internal volume to make an optimized group of 500 or more power reactor modules. However, this analysis does show that small to medium ships should still try to utilize the largest optimized block structures that they can manage within the volume of their ship, as opposed to a higher number of smaller block structures, such as those used in the '''efficient cube''' structures.

The following table lists the SizePower value generated by an optimal group of blocks of the given number. Note that SizePower does not fully max out at 1,000,000 until the optimized group has 3374 blocks. An optimized group is one with the largest possible box-dimensions for the number of blocks, or a group in which no block fails to increase the box-dimensions of the group:

{|class="wikitable"
!Blocks !! Max SizePower !! BlockPower !! GroupPower !! Power/Block Ratio
|-
|25||4853.8||625.0||5478.8||219.2
|-
|50||14789.0||1250.0||16039.0||320.8
|-
|100||46459.4||2500.0||48959.4||489.6
|-
|200||147463.8||5000.0||152463.8||762.3
|-
|300||286080.1||7500.0||293580.1||978.6
|-
|400||445102.1||10000.0||455102.1||1137.8
|-
|500||603206.3||12500.0||615706.3||1231.4
|- style="font-style: bold; background-color: green;"
|594||732790.3||14850.0||747640.3||1258.7
|-
|600||740136.2||15000.0||755136.2||1258.6
|-
|700||843919.1||17500.0||861419.1||1230.6
|-
|800||913509.0||20000.0||933509.0||1166.9
|-
|900||955432.2||22500.0||977932.2||1086.6
|-
|1000||978486.0||25000.0||1003486.0||1003.5
|-
|1100||990213.8||27500.0||1017713.8||925.2
|-
|1200||995787.6||30000.0||1025787.6||854.8
|-
|1300||998279.2||32500.0||1030779.2||792.9
|-
|1400||999331.5||35000.0||1034331.5||738.8
|-
|1500||999752.7||37500.0||1037252.7||691.5
|-
|1600||999912.7||40000.0||1039912.7||649.9
|-
|1700||999970.6||42500.0||1042470.6||613.2
|-
|1800||999990.5||45000.0||1044990.5||580.6
|-
|1900||999997.1||47500.0||1047497.1||551.3
|-
|2000||999999.1||50000.0||1049999.1||525.0
|-
|2100||999999.8||52500.0||1052499.8||501.2
|-
|2200||999999.9||55000.0||1054999.9||479.5
|-
|2300||1000000.0||57500.0||1057500.0||459.8
|-
|2400||1000000.0||60000.0||1060000.0||441.7
|-
|2500||1000000.0||62500.0||1062500.0||425.0
|-
|2600||1000000.0||65000.0||1065000.0||409.6
|-
|2700||1000000.0||67500.0||1067500.0||395.4
|-
|2800||1000000.0||70000.0||1070000.0||382.1
|-
|2900||1000000.0||72500.0||1072500.0||369.8
|-
|3000||1000000.0||75000.0||1075000.0||358.3
|-
|3100||1000000.0||77500.0||1077500.0||347.6
|-
|3200||1000000.0||80000.0||1080000.0||337.5
|-
|3374||1000000.0||84350.0||1084350.0||321.4
|}

The above table is illustrated better in the following chart:

<gallery mode="traditional" widths=600px heights=400px perrow=1 caption="Graphs of SizePower and GroupPower per Block">
Image:Max_SizePower_Curve.jpg|SizePower per optimized group of blocks of a given number, and the GroupPower per Block of each group.
</gallery>

It is easy to see that SizePower has diminishing returns after about 600 blocks. The precise number is 594. This is the number of blocks in a group that yields the largest bonus per block, 1258.7, after which it begins to fall. This is due to the S-curve shape of the SizePower graph. Consequently, if building a large ship with thousands of power reactor blocks, ''it would seem'' the power system should be composed of optimized groups of about 500 to 700 blocks each, this range being close enough to 594 that it does not greatly affect the resulting e/sec produced by a large system. However, there is another diminishing return factor applied to multiple groups within a ship. For example, in the chart above a group of 1000 power reactors, optimally, yields 1003486.0 e/sec, and a group of 500 power reactors yields 615706.3 e/sec. This has been verified in-game with build '''.1867'''. However, using two groups of 500 power reactors does not yield double the 615706.3 e/sec value, but only 909558.9 instead. Likewise, 1200 blocks would yield 1025787.6 e/sec, but two groups of 600 only yield 986370.9 e/sec, not double the 755136.2 e/sec of one group of 600.

This diminishing return factor for groups is a soft limit which effectively limits ships to not much more than 1 million e/sec in practice. Consequently large ships are currently either limited to this value, or else use a ''docked '''power module''' daughter-ship'' and power drain beams to add more power generation capacity to a base ship.

To get to 1 million e/sec (using optimal layouts with each group):
{|class="wikitable"
!NumGroups!!GroupSize!!TotalBlocks!!SumGroupX!!MaxSizePower!!BlockPower!!TotalPower!!Power/Block
|-
|1||1000||1000||19515.0||978486.0||25000||1003486.0||1003.5
|-
|2||700||1400||21315.6||985772.0||35000||1020772.0||729.1
|-
|2||650||1300||18799.4||974655.6||32500||1007155.6||774.7
|-
|3||500||1500||18080.5||970131.0||37500||1007631.0||671.8
|-
|4||400||1600||16524.9||957445.3||40000||997445.3||623.4
|-
|6||300||1800||15242.5||943141.8||45000||988141.8||549.0
|-
|12||200||2400||15387.7||944970.1||60000||1004970.1||418.7
|-
|18||150||2700||14233.1||928695.3||67500||996195.3||369.0
|-
|34||100||3400||13645.6||918720.2||85000||1003720.2||295.2
|-
|52||75||3900.0||12939.9||904968.8||97500||1002468.8||257.0
|-
|94||50||4700.0||12001.3||883230.7||117500||1000730.7||212.9
|-
|253||25||6325.0||10600.7||842003.8||158125||1000128.8||158.1
|}

In terms of ship mass, larger groups are more efficient.

==Sample Optimized Reactor Layouts==

<gallery mode="traditional" widths=300px heights=300px perrow=2 caption="Optimal 2x2 and 3x3 reactor layouts">
Image:2x2Maximized.jpg|A 2x2 cube with two reactor groups. BlockPower=125e (100+25) SizePower=492e (376+115) TotalPower=617e
Image:3x3Maximized.jpg|A 3x3 cube with two reactor groups. BlockPower=500e (250+250) SizePower=1499e (749 + 749) TotalPower=1999e
</gallery>

<gallery mode="traditional" widths=300px heights=300px perrow=4 caption="Optimal 4x4 reactor layout">
Image:4x4MaximizedLayer1.jpg|A 4x4 cube with four reactor groups - layer 1. BlockPower=825e (100+200+250+275) SizePower=3719e (376+897+1223+1223) TotalPower=4544e
Image:4x4MaximizedLayer2.jpg|A 4x4 cube with four reactor groups - layer 2.
Image:4x4MaximizedLayer3.jpg|A 4x4 cube with four reactor groups - layer 3.
Image:4x4MaximizedLayer4.jpg|A 4x4 cube with four reactor groups - layer 4.
</gallery>

<gallery mode="traditional" widths=1000px heights=200px perrow=1 caption="Optimal 5x5 reactor layout">
Image:Power Block Compact.png|A 5x5 cube with 5 reactor groups. BlockPower=1725e (375+375+375+375+225) SizePower=8282e (1787+1787+1787+1787+1054) TotalPower=9927e
</gallery>

[[Category:Articles]]
[[Category:Game Mechanics]]

File:Crystal Composite.png

2016-07-14T10:26:49Z

Olxinos:

File:Hylat Capsule.png

2016-07-14T10:26:34Z

Olxinos:

File:Standard Factory.png

2016-07-14T10:19:49Z

Olxinos:

File:Cannon Barrel.png

2016-07-14T10:16:45Z

Olxinos: Olxinos uploaded a new version of File:Cannon Barrel.png

File:Cannon Computer.png

2016-07-14T10:15:27Z

Olxinos: Olxinos uploaded a new version of File:Cannon Computer.png

File:Cannon Computer.png

2016-07-14T10:08:41Z

Olxinos: Olxinos uploaded a new version of File:Cannon Computer.png

File:Cannon Barrel.png

2016-07-14T10:06:35Z

Olxinos:

File:Cannon Computer.png

2016-07-14T10:05:52Z

Olxinos:

Mod API

2016-07-13T11:07:56Z

Olxinos: Reproduced old wiki page (16 july 2015)

This section is intended for mod authors and those who are interested in writing tools that work with StarMade data files

==Data Files==
[[Blueprint File Formats]]

Cannon Computer

2016-07-13T11:00:57Z

Olxinos: added the WIP template

{{WIP}}
{{infobox block
|type=Cannon Computer
|hp=50
|armor=0%
|ahp=0
|shp=75
|mass=0.1
|light=no
|dv=6
}}

The '''Cannon Computer''' is one of the four main weapons systems in StarMade and is the only weapon system provided to all new players who start the game.

==Item Description==

The '''Cannon Computer''' is required for creating functioning Cannon systems.

It is capable of controlling any amount of [[Cannon Barrel|Cannon Barrels]], although using multiple groups imparts a 10% power consumption penalty for each group beyond the first. Once placed, you can select/deselect it with {{K|Select module}}, and link [[Cannon Barrel|Cannon Barrels]] using {{K|Connect module}} while it is selected and you are looking at a [[Cannon Barrel]].

Press {{K|Activate module}} to get in/out of the Computer."

==Manufacturing==

{{mfg
|type=factory
|using=Standard Factory
|ic1=500
|ic2=1000
|it1=Hylat Capsule
|it2=Crystal Composite
|oc1=1
|ot1=Cannon Computer
}}

==Usage==
:''Main article: [[Weapon Systems]]''

The unslaved cannon is the most simple and straight forward weapon system in the game. When linked with [[Cannon Barrels|Cannon Barrel]], it will fire one projectile per reload. In many ways it is comparable to a semi-automatic rifle. All Cannon variations require the user to lead their target as the projectile does not hit instantaneously like [[Damage Beam Computer|Damage Beams]]. Unlike [[Damage Beam Computer|Damage Beams]], the Cannons offer more range and an overall better damage per block ratio.

As of version 0.19282<ref>http://star-made.org/news/starmade-v0-19282-putting-more-fun-into-battles-also-boarding</ref>, Cannons' projectiles can destroy multiple blocks.

==Weapon Slaves==
=== Machine Gun ===
{| class="floatright" style="width: 21.5em;"
|-
| '''Slave:''' [[Cannon Computer|Cannon]]
|-
| '''PROS:'''
* Extremely versatile
* Requires fewer Power Capacitors
|-
| '''CONS:'''
* Its low damage per shot may fail to overcome high shield regenerations
|}

This combination is one of the most popular in the game. It fares well against armor, shields and systems alike and requires very few [[Power Capacitor|Power Capacitors]] to boot thanks to its low power consumption per shot.

====Notable Uses====
* All-purpose 
Often combined with a [[Punch Through Effect Computer|Punch-Through]] effect or more rarely with an [[Overdrive Effect Computer|Overdrive]] effect, this is your typical all-purpose weapon. They are sometimes found in groups of 891/891/891 or 443/443/443 (depending on whether you use Punch-Through or Overdrive) to destroy one [[Advanced Armor Block]] with full passives per shot.
* Shield-Nullifier 
High firerates help keeping an opponent's shields depleted, leaving its hull vulnerable. This is even more pronounced if combined with a [[Ion Effect Computer|Ion]] effect.
* Momentum Guns 
Combined with a [[Push Effect Computer|Push]], [[Pull Effect Computer|Pull]] or [[Stop Effect Computer|Stop]] effect, the Machine gun affects the target's movement at the expense of overall weapon damage.It's an effective means of position enemies where you want them(i.e pulling them in to get a better shot, pushing them away, or holding them in space).
* Anti-missile system 
Cannons are the only weapon able to hit missiles and missiles are always destroyed in one shot, hence small fast firing cannons are often used as anti-missile system.
* Flak Gun: 
AI turrets that feature Cannon+Cannon systems can completely fill the skies with projectiles and is a good way of pressuring your enemy.

===Shotgun===
{| class="floatright" style="width: 21.5em;"
|-
| '''Slave:''' [[Missile Computer|Missile]]
|-
| '''PROS:'''
* Capable of hitting multiple targets at once
|-
| '''CONS:'''
* Extremely poor accuracy unless at point blank range
|}

One of the most unique weapon combinations, the Shotgun allows the cannon to damage more than one block at a time. Increasing the amount of Missile tubes connected to the slave will increase the amount of projectiles fired from a single grouping. At a 1:1 Master/Slave ratio the cannon will fire 10 bullets from every grouping although unfortunately more projectiles comes at the cost of damage per bullet. Current game limitations prevent shot spreads from being truly random thus making every bullet fly in the same pattern/direction.
At the present (Alpha Version 0.19174), the Shotgun is only useful in highly specialized weapon configurations.

====Notable Uses====
* Flak Cannon 
In large enough groupings, Shotgun arrays can fill the entire screen with bullets. They are sometimes used as an auxiliary anti-missile system.
----
=== Sniper Cannon ===
{| class="floatright" style="width: 21.5em;"
|-
| '''Slave:''' [[Damage Beam Computer|Damage Beam]]
|-
| '''PROS:'''
* Second longest range in the game
* Faster Bullets
* Moderately high damage per shot
|-
| '''CONS:'''
* Difficult to aim at longer distances
* High energy usage
|}

Depending on the server size and ai accuracy settings you're playing with, the range boost can be negligible or an interesting asset. The increased projectile speed however is always useful and the moderate damage per shot increase nicely complements the Cannon slave version. Unfortunately, it is impossible to really benefit from the increased range when firing these weapons manually so it will often be left to turrets and other AI controlled weapons.

====Notable Uses====

* Piercing cannon 
While a Cannon slave is usually more efficient (since it requires fewer capacitors), the increased damage per shot of this combination makes it interesting to pierce through what could otherwise be near impenetrable defenses (like multiple layers of [[Advanced Armor Block|Advanced Armor]] or very high shield regeneration rates). It is especially efficient when paired with either [[Punch Through Effect Computer|Punch-Through]], partial or total [[Ion Effect Computer|Ion]] or even [[Piercing Effect Computer|Piercing]] effects depending on what kind of defenses you plan to overcome.
* (AI only) Detection system 
As of Alpha Version 0.19174, The AI's ability to detect a enemy is completely dependent on the range of its weapons. Even with the smallest possible configuration a 1:1 Sniper system will allow the AI to "see" targets coming at the maximum range the game allows.

----

=== Siege Cannon ===
{| class="floatright" style="width: 21.5em;"
|-
| '''Slave:''' [[Damage Pulse Computer|Damage Pulse]]
|-
| '''PROS:'''
* High damage per shot
|-
| '''CONS:'''
* Requires a lot of Power Capacitors
* Long reload time
|}

This combination suffers from the comparison with either the Sniper Cannon for low power capacity ships, or other power-hungry weapons like Smart Missiles for low power regeneration ships. It can however deal massive damage assuming you can reliably hit your target and may help deplete large shield pools.

====Notable Uses====

* Heavy Anti-Shield Cannon 
Due to shields being a single entity a High damage cannon system can help deplete large portions of it.

==Trivia==
* Currently the Cannon is the only weapon in the game whose projectile changes in size to represent its damage output.
* Despite what one might think, Machine Gun system's(Cannon+Cannon) rapid fire speed can not be fully replicated via a logic clock.
* Prior to the Weapon update (Alpha Version 0.15), The Cannon (Formerly called "Anti-Matter Cannon") was extremely over powered. Adding more weapon modules increased virtually all stats (Damage, Range, Rate of fire). Massive groups were capable of firing faster than 1:1 Cannon+Cannon combos, Had ranges of multiple sectors, and each bullet doing thousands of points of damage.

==References==
<references/>

Server.cfg

2016-07-13T10:59:33Z

Olxinos: Reproduced old wiki page (20 july 2015)

{{WIP}}
The server.cfg is a file containing the server settings. It can be edited to change settings for the server, including but not limited to: speed limit and the amount of blocks that can be placed removed or modified using the advanced build option.

==Default Config Settings (As of Alpha 0.19174)==
WORLD = world0 //set world to use (set 'old' for using the old world). if no world exists a new one will be set automatically 
PROTECT_STARTING_SECTOR = false //Protects the starting sector 
ENABLE_SIMULATION = true //Universe AI simulation 
CONCURRENT_SIMULATION = 256 //How many simulation groups may be in the universe simultaniously (performance) 
ENEMY_SPAWNING = true //Enables enemy spawing 
SECTOR_SIZE = 2000 //Sets the size of sectors in the universe **WARNING** scaling the size of an existing universe down may cause issues 
BLUEPRINT_DEFAULT_PRIVATE = true //If true, set blueprints private as default (else they are public) 
FLOATING_ITEM_LIFETIME_SECS = 240 //How much seconds items floating in space should be alive 
SIMULATION_SPAWN_DELAY = 420 //How much seconds between simulation spawn ticks 
SIMULATION_TRADING_FILLS_SHOPS = true //Trading guild will deliver stock to shops 
SECTOR_INACTIVE_TIMEOUT = 20 //Time in secs after which sectors go inactive (-1 = off) 
SECTOR_INACTIVE_CLEANUP_TIMEOUT = 10 //Time in secs after which inactive sectors are completely removed from memory (-1 = off) 
USE_STARMADE_AUTHENTICATION = false //allow star-made.org authentication 
REQUIRE_STARMADE_AUTHENTICATION = false //require star-made.org authentication (USE_STARMADE_AUTHENTICATION must be true) 
PROTECTED_NAMES_BY_ACCOUNT = 10 //How many player names a player may protect with his account (if exceeded, the player name, that was logged in the longest time ago gets unprotected) 
DEFAULT_BLUEPRINT_ENEMY_USE = true //Default option to use uploaded ships in waves 
LOCK_FACTION_SHIPS = true //If true, ships of other factions cant be edited, activated, or entered 
DEBUG_FSM_STATE = false //transfer debug FSM state. Turning this on may slow down network 
PHYSICS_SHAPE_CASTING_TUNNELING_PREVENTION = false //Makes a convex cast for hight speed object to prevent clipping. High Cost. (Bugged right now, so dont turn it on) 
CATALOG_SLOTS_PER_PLAYER = -1 //How many slots per player for saved ships (-1 for unlimited) 
UNIVERSE_DAY_IN_MS = 1200000 //how long is a 'day' (stellar system rotation) in milliseconds (-1 to switch off system rotation) 
FORCE_DISK_WRITE_COMPLETION = false //forces writing operations of raw data to disk directly after operation. For some OS this prevents raw data corruption 
ASTEROIDS_ENABLE_DYNAMIC_PHYSICS = true //enables asteroids to be able to move in space 
ENABLE_BREAK_OFF = false //debug (don't activate unless you know what you're doing) 
COLLISION_DAMAGE = false //colliding into another object does damage 
COLLISION_DAMAGE_THRESHOLD = 2.0 //Threshold of Impulse that does damage (the lower, the less force is needed for damage) 
SKIN_ALLOW_UPLOAD = true //if off, skin uploading to server is deactivated 
CATALOG_NAME_COLLISION_HANDLING = false //if off, saving with an existing entry is denied, if on the name is automatically changed by adding numbers on the end 
SECTOR_AUTOSAVE_SEC = 300 //Time interval in secs the server will autosave (-1 for never) 
PHYSICS_SLOWDOWN_THRESHOLD = 40 //Milliseconds a collision test may take before anti-slowdown mode is activated 
THRUST_SPEED_LIMIT = 75 //How fast ships, etc. may go in m/s . Too high values may induce physics tunneling effects 
MAX_CLIENTS = 32 //Max number of clients allowed on this server 
SUPER_ADMIN_PASSWORD_USE = false //Enable super admin for this server 
SUPER_ADMIN_PASSWORD = mypassword //Super admin password for this server 
SERVER_LISTEN_IP = all //Enter specific ip for the server to listen to. use "all" to listen on every ip 
SOCKET_BUFFER_SIZE = 65536 //buffer size of incoming and outgoing data per socket 
PHYSICS_LINEAR_DAMPING = 0.05 //how much object slow down naturally (must be between 0 and 1): 0 is no slowdown 
PHYSICS_ROTATIONAL_DAMPING = 0.05 //how much object slow down naturally (must be between 0 and 1): 0 is no slowdown 
AI_DESTRUCTION_LOOT_COUNT_MULTIPLIER = 0.9 //multiply amount of items in a loot stack. use values smaller 1 for less and 0 for none 
AI_DESTRUCTION_LOOT_STACK_MULTIPLIER = 0.9 //multiply amount of items spawned after AI destruction. use values smaller 1 for less and 0 for none 
CHEST_LOOT_COUNT_MULTIPLIER = 0.9 //multiply amount of items in a loot stack. use values smaller 1 for less and 0 for none 
CHEST_LOOT_STACK_MULTIPLIER = 0.9 //multiply amount of items spawned in chests of generated chests. use values smaller 1 for less and 0 for none 
USE_WHITELIST = false //only names/ips from whitelist.txt are allowed 
FILTER_CONNECTION_MESSAGES = false //don't display join/disconnect messages 
USE_UDP = false //Use 'User Datagram Protocol' (UDP) instead of 'Transmission Control Protocol' (TCP) for connections 
AUTO_KICK_MODIFIED_BLUEPRINT_USE = false //Kick players that spawn modified blueprints 
AUTO_BAN_ID_MODIFIED_BLUEPRINT_USE = false //Ban player by name that spawn modified blueprints 
AUTO_BAN_IP_MODIFIED_BLUEPRINT_USE = false //Ban player by IP that spawn modified blueprints 
REMOVE_MODIFIED_BLUEPRINTS = false //Auto-removes a modified blueprint 
DEBUG_SEGMENT_WRITING = false //Debugs correctness of writing of segments (costs server performance) 
TCP_NODELAY = true //Naggles algorithm (WARNING: only change when you know what you're doing) 
PING_FLUSH = false //flushes ping/pong immediately (WARNING: only change when you know what you're doing) 
RECIPE_BLOCK_COST = 5000 //How much blocks have to be invested to create a recipe (min 0) 
SHOP_SPAWNING_PROBABILITY = 0.1 //(must be between 0 and 1): 0 is no shops spawned in asteroid sectors, 1 is shop spawned in everyone (default: 8% -> 0.08) 
RECIPE_REFUND_MULT = 0.5 //how much blocks are refunded from selling a recipe (must be between 0 and 1): 0 no refund, 1 full refund 
RECIPE_LEVEL_AMOUNT = 4000 //On how much created blocks will a recipe level up (base value) (min 0) 
DEFAULT_SPAWN_SECTOR_X = 2 //DEFAULT Spawn Sector X Coordinate 
DEFAULT_SPAWN_SECTOR_Y = 2 //DEFAULT Spawn Sector Y Coordinate 
DEFAULT_SPAWN_SECTOR_Z = 2 //DEFAULT Spawn Sector Z Coordinate 
MODIFIED_BLUEPRINT_TOLERANCE = 0.1 //Tolerance of modified blueprint trigger (default = 10%) 
TURNING_DIMENSION_SCALE = 1.1 //Scaling of tuning speed VS ship dimension (default = 1.1) 
DEFAULT_SPAWN_LOCALPOINT_X_1 = 0.0 //First Rotating Spawn: Local Pos X Coordinate 
DEFAULT_SPAWN_LOCALPOINT_Y_1 = -6.5 //First Rotating Spawn: Local Pos Y Coordinate 
DEFAULT_SPAWN_LOCALPOINT_Z_1 = -8.0 //First Rotating Spawn: Local Pos Z Coordinate 
DEFAULT_SPAWN_LOCALPOINT_X_2 = 7.0 //Second Rotating Spawn: Local Pos X Coordinate 
DEFAULT_SPAWN_LOCALPOINT_Y_2 = -6.5 //Second Rotating Spawn: Local Pos Y Coordinate 
DEFAULT_SPAWN_LOCALPOINT_Z_2 = 0.0 //Second Rotating Spawn: Local Pos Z Coordinate 
DEFAULT_SPAWN_LOCALPOINT_X_3 = 0.0 //Third Rotating Spawn: Local Pos X Coordinate 
DEFAULT_SPAWN_LOCALPOINT_Y_3 = -6.5 //Third Rotating Spawn: Local Pos Y Coordinate 
DEFAULT_SPAWN_LOCALPOINT_Z_3 = 7.0 //Third Rotating Spawn: Local Pos Z Coordinate 
DEFAULT_SPAWN_LOCALPOINT_X_4 = -8.0 //Forth Rotating Spawn: Local Pos X Coordinate 
DEFAULT_SPAWN_LOCALPOINT_Y_4 = -6.5 //Forth Rotating Spawn: Local Pos Y Coordinate 
DEFAULT_SPAWN_LOCALPOINT_Z_4 = 0.0 //Forth Rotating Spawn: Local Pos Z Coordinate 
PLAYER_DEATH_CREDIT_PUNISHMENT = 0.1 //players credits lost of total on death (must be between 0 and 1): 1 = lose all, 0 = keep all 
PLAYER_DEATH_CREDIT_DROP = false //drop credits lost on death into space instead 
PLAYER_DEATH_BLOCK_PUNISHMENT = false //player will drop all his blocks into space on death 
PLAYER_DEATH_PUNISHMENT_TIME = 300 //Time interval in seconds after death of a player in which the player is not punished 
PLAYER_DEATH_INVULNERABILITY_TIME = 5 //Time the player is invulnerable after death in sec 
PLAYER_HISTORY_BACKLOG = 30 //how many login history objects (with name, IP, account-name, and time) should be saved by player state 
PROJECTILES_ADDITIVE_VELOCITY = false //initial projectile speed depend on relative linear velocity of object fired from 
PROJECTILES_VELOCITY_MULTIPLIER = 1.0 //multiplicator for projectile velocity 
IGNORE_DOCKING_AREA = false //ignores docking area size 
ALLOW_UPLOAD_FROM_LOCAL_BLUEPRINTS = true //enables clients being able to upload their pre-build-blueprints to the server 
SHOP_NPC_STARTING_CREDITS = 10000000 //how much credits do shops start with 
SHOP_NPC_RECHARGE_CREDITS = 100000 //how much credits do shops gain about every 10 min 
AI_WEAPON_AIMING_ACCURACY = 10 //how accurate the AI aims (the higher the value the more accurate vs distance. 10 = about 99% accuracy at 10m) 
BROADCAST_SHIELD_PERCENTAGE = 5 //percent of shields changed for the server to broadcast a shield synch 
BROADCAST_POWER_PERCENTAGE = 50 //percent of power changed for the server to broadcast a power synch (not that critical) 
ADMINS_CIRCUMVENT_STRUCTURE_CONTROL = true //admins can enter ships of any faction 
STAR_DAMAGE = true //suns dealing damage to entities 
SQL_NIO_FILE_SIZE = 256 //megabyte limit of .data file when to use NIO (faster) (must be power of 2) 
PLANET_SIZE_MEAN = 175.0 //Planet size mean (normal gaussian distribution) (min 50) 
PLANET_SIZE_DEVIATION = 100.0 //Planet size standard deviation (normal gaussian distribution) (min 0) 
PLAYER_MAX_BUILD_AREA = 10 //max area a player may add/remove in adv. build mode 
NT_SPAM_PROTECT_TIME_MS = 30000 //period of spam protection 
NT_SPAM_PROTECT_MAX_ATTEMPTS = 30 //max attempts before refusing connections in spam protect period (default is 1/sec for 30 sec) 
NT_SPAM_PROTECT_EXCEPTIONS = 127.0.0.1 //ips excepted from spam control (separate multiple with comma) (default is localhost) 
NT_SPAM_PROTECT_ACTIVE = true //enables connection spawn protection (flooding servers with login attempts) 
USE_PERSONAL_SECTORS = false //will spawn a player in a locked sector sandbox (warning, don't use unless you know what you do) 
BATTLE_MODE = false //turn on battlemode (warning, don't use unless you know what you're doing) 
BATTLE_MODE_CONFIG = battleSector=0,0,0,Physics.smsec;battleSector=15,15,15,Physics.smsec;countdownRound=300;countdownStart=30;maxMass=-1;maxDim=300;maxMassPerFaction=-1; //General config for battlemode 
BATTLE_MODE_FACTIONS = [TeamA, fighters, 500,500,500, 0.5,0.1,0.9];[TeamB, fighters, -500,-500,-500, 0.5,0.9,0.2];[TeamFFA,ffa, 0,0,-500, 0.2,0.9,0.9];[Spectators,spectators, 0,500,0,0.8,0.4,0.8] //Faction config for battlemode 
LEADERBOARD_BACKLOG = 24 //time in hours to keep leaderboard backlog (the more time, the more data has to be sent to client) 
ANNOUNCE_SERVER_TO_SERVERLIST = false //announces the server to the starmade server list so clients can find it. Hostname must be provided for HOST_NAME_TO_ANNOUNCE_TO_SERVER_LIST! 
HOST_NAME_TO_ANNOUNCE_TO_SERVER_LIST = //this must be a valid hostname (either ip or host, e.g. play.star-made.org) 
SERVER_LIST_NAME = NoName //max length 64 characters 
SERVER_LIST_DESCRIPTION = NoDescription //max length 128 characters 
MISSILE_DEFENSE_FRIENDLY_FIRE = true //can shoot down own or missiles from own faction 
USE_DYNAMIC_RECIPE_PRICES = true //use recipe based prices (the price is the price of the parts it is made out of in crafting) 
MAKE_HOMBASE_ATTACKABLE_ON_FP_DEFICIT = true //Home bases become attackable if a faction's Faction Points are in the minus and the faction doesn't own any territory 
PLANET_SPECIAL_REGION_PROPABILITY = 240 //one out of thisValue chance of a special region spawning per planet plate (cities, pyramids, etc) (changing this value migth change some plates, but won't change any plates that are already modified by a player) 
NT_BLOCKUPDATE_QUEUE_SIZE = 127 //how many blocks are sent per update. Huge placements will shot faster, but it will consume more bandwidth and is subject to spamming players 
CHUNK_REQUEST_THREAD_POOL_SIZE_TOTAL = 25 //Thead pool size for chunk requests (from disk and generated) 
CHUNK_REQUEST_THREAD_POOL_SIZE_CPU = 3 //Available threads of total for CPU generation. WARNING: too high can cause cpu spikes. About the amount of available cores minus one is best 
BUY_BLUEPRINTS_WITH_CREDITS = false //buy blueprints directly with credits 
SHOP_USE_STATIC_SELL_BUY_PRICES = false //shop buy and sell price change depending on stock (shop prices will always stay the same if true) 
SHOP_SELL_BUY_PRICES_UPPER_LIMIT = 1.2 //maximum of base price a shop will want depending on its stock (e.g. max 120 credits if the normal cost is 100) 
SHOP_SELL_BUY_PRICES_LOWER_LIMIT = 0.8 //minimum of base price a shop will want depending on its stock (e.g. max 80 credits if the normal cost is 100) 
MINING_BONUS = 1 //general multiplier on all mining 
MAX_COORDINATE_BOOKMARKS = 20 //coordinate bookmarks per player allowed 
ALLOWED_STATIONS_PER_SECTOR = 1 //how many stations are allowed per sector 
STATION_CREDIT_COST = 1000000 //how much does a station or station blueprint cost 
SKIN_SERVER_UPLOAD_BLOCK_SIZE = 256 //how fast should skins be transferred from server to clients (too high might cause lag) [default 256 ~ 16kb/s]

Old Weapon Systems

2016-07-12T15:18:06Z

Olxinos: Updated values

{{WIP}}

Weapons are used to fight enemies. They can be built on any object, and can be either fired manually or be triggered by logic.

==Construction==
Each weapon has a computer and one or more [[Linking|linked]] modules. Each weapon computer has its own associated module block type. Weapon modules which share at least one face with another weapon module of the same type will be in the same [[Module_Group|group]]. The more modules in each group linked to the weapon computer, the more powerful the weapon will become, with a commensurate increase in power consumption. Any number of groups may be linked to the same weapon computer, though there is a power consumption penalty for each group beyond the first linked in this way. Additionally, one weapon module will be the '''output''' module for the group - this is the module from which projectiles or beams will be emitted for the whole group. For any given group, this can be changed by pointing at the desired output module and pressing {{K|Make Output}}. If the module is already the current output, the text "(CURRENT)" will show next to the module.

See the [[#Tables|Tables]] section for detailed numerical information on the base attributes of each weapon system.

==Linked systems==
In ''StarMade'' weapons can be modified by [[linking]] in order to give different abilities or additional effects, usually with some trade-off such as power consumption or recharge time. There are two kinds of links for weapon systems: [[#support systems|support systems]] and [[#effect systems|effect systems]] as described below.

In these linked systems, the original system is called the master. The system that gives the different abilities is called the slave. Only weapons can be used as slaves, not the [[Support Tool Systems|support tool systems]]. The slave system doesn't actually get fired, only the master system does. Weapons, and only weapons, can also be linked to [[#Effect Systems|effect systems]]. The amount of change provided by the slaved system is proportional to the number of modules in the master and slave. For example, if the master has 10 modules and the slave has 5, only 50% of the slave's effect will be applied and this will be the percentage which shows in the [[Weapons Tab]]. If there are 10 modules in each, the maximum effect of the slaved system is applied and the weapons panel will show 100%. Support and effect ratios are independent of each other; therefore, if you have 10 master modules, you may have up to 10 ''support'' modules and up to 10 ''effect'' modules to achieve the maximum effect, for a total of 30 modules (10 master, 10 support and 10 effect).

See [[Linking]] for a description of the methods of establishing links between systems.

===Support systems===
A support system is a weapon system which is slaved to another weapon system or [[Support Tool Systems|support tool system]]. Any weapon or support tool can support zero or one support systems at a time, and these may be either linked manually during building, or on-the-fly using the [[Weapons Tab]] by dragging the associated support computer into the support slot for the weapon or support tool.

Each weapon system has the following general effect when slaved to another valid system:

{|class="wikitable"
! Support Computer !! Description
|-
| [[Damage Beam Computer]] || Improves range and/or speed
|-
| [[Cannon Computer]] || Improves firing rate
|-
| [[Missile Computer]] || Increases the number of projectiles
|-
| [[Damage Pulse Computer]] || Increases damage
|}

See the [[#Tables|Tables]] section for detailed numerical information on how support systems affect linked weapons.

===Effect systems===
An effect system is an [[:Category:Effect|effect computer]] slaved to a weapon system. Any weapon can support zero or one effect systems at a time, and these may either be linked manually during building, or on-the-fly using the [[Weapons Tab]] by dragging the associated effect computer into the effect slot for the weapon.

Each effect system has the following general effect when slaved to a valid weapon system:

{|class="wikitable"
! Effect Computer !! Description
|-
| [[EMP Effect Computer]] || Converts weapon damage to reduce power in the hit ship.
|-
| [[Explosive Effect Computer]] || For beams and cannons, adds an explosive effect, spreading the weapon damage over the six blocks adjacent to the hit block. For missiles and pulse, the radius of the blast is increased.
|-
| [[Ion Effect Computer]] || Increased damage to shields but reduced damage to blocks.
|-
| [[Overdrive Effect Computer]] || Increases overall weapon damage at the expense of dramatically higher energy usage.
|-
| [[Piercing Effect Computer]] || Does damage to blocks behind the point of impact, but decreases shield damage and direct damage to the targeted block. Does not work on missiles.
|-
| [[Punch-Through Effect Computer]] || If the attack would destroy a block, remaining damage is applied to consecutive blocks until all the damage is used up. Does not work on missiles.
|-
| [[Push Effect Computer]] || Reduces damage in exchange for a pushing effect on the target.
|-
| [[Pull Effect Computer]] || Reduces damage in exchange for a pulling effect on the target.
|-
| [[Stop Effect Computer]] || Converts damage into a braking effect to hold the target in place.
|}
See the [[#Tables|Tables]] section for detailed numerical information on how effect systems affect linked weapons.

==Coloring==
The projectile or effect animation color can be altered by [[linking]] the weapon computer to any light emitting block.

==Tables==
This wiki uses tables to show the stats of the different systems. Example of a table:
{|class="wikitable"
!colspan="3"|Stats for this system
!colspan="4"|Values for this system's slaves
|-
!width="200pt" | Name (unit)
!width="90pt" | Per module
!width="110pt" | Values
!width="110pt" | Cannon
!width="110pt" | Missile
!width="110pt" | Damage beam
!width="110pt" | Damage pulse
|-
| Value 1 (x/y)
| style="text-align:center" | yes
| style="text-align:right" | 40.0
| style="text-align:right" | -
| style="text-align:right" | -
| style="text-align:right" | 120.0
| style="text-align:right" | 240.0
|-
| Value 2 (a/b)
| style="text-align:center" | no
| style="text-align:right" | 2.0
| style="text-align:right" | 1.0
| style="text-align:right" | -
| style="text-align:right" | -
| style="text-align:right" | 12.0
|}

The first large section of the table, "Stats for this system", shows all the stats for the master system. The first column shows the name of the stat and the unit it is in. An example of a unit would be e/s (energy per second). The second column shows whether the values are per module or not. If something isn't per module, that value will be set and the amount of modules has no influence on it. If it is per module, the value that belongs to that stat needs to be multiplied by the total amount of modules in that system, including the slave systems. If an effect system is added, that value also needs to be multiplied for the amount of modules in the effect system that wouldn't let the ratio go over 100%. Only then is the effect applied over that total value. The column "Values" shows the value that goes with that stat.

Next, the second section, "Values for this system's slaves", shows all the values for the possible slave systems. As mentioned earlier, only the weapon systems can be used as slave system. This means that any system that can have slave systems will shows the exact column headers shown above. If a value there is different to the value listed for the master system, it means it has changed, and that the value listed there will be the one that gets used in any calculation. '''The values listed by the slave systems are those for a 100% ratio.''' If a system has less than a 100% ratio, those values won't apply to it. Furthermore, if there is a " - ", that value will be the same as the value for the master system. The grey zeros are there to make it easier to see which value is high and which is low.

The following table describes the effects of weapons systems as supports for other weapon systems.<ref>blockBehaviorConfig.xml</ref> See the [[Support Tool Systems]] section for descriptions of the effects on those systems.

{|class="wikitable"
!colspan="7"|Cannon
|-
!colspan="3"|Stats for this system
!colspan="4"|Values for this system's slaves
|-
!width="200pt" | Name (unit)
!width="90pt" | Per module
!width="110pt" | Values
!width="110pt" | Cannon
!width="110pt" | Missile
!width="110pt" | Damage beam
!width="110pt" | Damage pulse
|-
| Damage (per activation)
| style="text-align:center" | yes
| style="text-align:right" | 10.0
| style="text-align:right" | 1
| style="text-align:right" | 20
| style="text-align:right" | 40.0
| style="text-align:right" | 160.0
|-
| Reload (seconds)
| style="text-align:center" | no
| style="text-align:right" | 1.0
| style="text-align:right" | 0.1
| style="text-align:right" | 2.0
| style="text-align:right" | 4.0
| style="text-align:right" | 16.0
|-
| Range (sectors)
| style="text-align:center" | no
| style="text-align:right" | 1.0
| style="text-align:right" | 1.0
| style="text-align:right" | 1.0
| style="text-align:right" | 3.0
| style="text-align:right" | 1.0
|-
| Speed (times normal ship)
| style="text-align:center" | no
| style="text-align:right" | 10.0
| style="text-align:right" | 10.0
| style="text-align:right" | 10.0
| style="text-align:right" | 20.0
| style="text-align:right" | 10.0
|-
| Power (per activation)
| style="text-align:center" | yes
| style="text-align:right" | 100.0
| style="text-align:right" | 10.0
| style="text-align:right" | 200.0
| style="text-align:right" | 400.0
| style="text-align:right" | 1600.0
|-
| Special
| style="text-align:center" |
| style="text-align:right" |
| style="text-align:right" |
| style="text-align:right" | Shotgun
| style="text-align:right" |
| style="text-align:right" |
|}

{|class="wikitable"
!colspan="7"|Missile
|-
!colspan="3"|Stats for this system
!colspan="4"|Values for this system's slaves
|-
!width="200pt" | Name (unit)
!width="90pt" | Per module
!width="110pt" | Values
!width="110pt" | Cannon
!width="110pt" | Missile
!width="110pt" | Damage beam
!width="110pt" | Damage pulse
|-
| Damage (per activation)
| style="text-align:center" | yes
| style="text-align:right" | 300.0
| style="text-align:right" | 20
| style="text-align:right" | 300
| style="text-align:right" | 900.0
| style="text-align:right" | 1800.0
|-
| Reload (seconds)
| style="text-align:center" | no
| style="text-align:right" | 15.0
| style="text-align:right" | 3
| style="text-align:right" | 15
| style="text-align:right" | 45.0
| style="text-align:right" | 90.0
|-
| Range (sectors)
| style="text-align:center" | no
| style="text-align:right" | 1.6
| style="text-align:right" | 1.6
| style="text-align:right" | 1.6
| style="text-align:right" | 4.8
| style="text-align:right" | 1.6
|-
| Speed (times normal ship)
| style="text-align:center" | no
| style="text-align:right" | 2.48
| style="text-align:right" | 7.44
| style="text-align:right" | 1.24
| style="text-align:right" | 4.96
| style="text-align:right" | 0.827
|-
| Power (energy/activation)
| style="text-align:center" | yes
| style="text-align:right" | 1500
| style="text-align:right" | 100
| style="text-align:right" | 1500
| style="text-align:right" | 4500
| style="text-align:right" | 9000
|-
| Missiles
| style="text-align:center" | no
| style="text-align:right" | 1
| style="text-align:right" | 1
| style="text-align:right" | 10
| style="text-align:right" | 1
| style="text-align:right" | 1
|-
| Blast Radius (blocks max)
| style="text-align:center" | no
| style="text-align:right" | 12
| style="text-align:right" | 6
| style="text-align:right" | 4
| style="text-align:right" | 12
| style="text-align:right" | 48
|-
| rowspan="2"| Special
| style="text-align:center" |
| style="text-align:right" | Dumb-fire
| style="text-align:right" | Dumb-fire
| style="text-align:right" | Heat-seeker
| style="text-align:right" | Smart
| style="text-align:right" | Smart
|}

{|class="wikitable"
!colspan="7"|Damage Beam
|-
!colspan="3"|Stats for this system
!colspan="4"|Values for this system's slaves
|-
!width="200pt" | Name (unit)
!width="90pt" | Per module
!width="110pt" | Values
!width="110pt" | Cannon
!width="110pt" | Missile
!width="110pt" | Damage beam
!width="110pt" | Damage pulse
|-
| Damage (damage/hit)
| style="text-align:center" | yes
| style="text-align:right" | 10
| style="text-align:right" | 1
| style="text-align:right" | 10
| style="text-align:right" | 30
| style="text-align:right" | 110
|-
| Reload (secs/activation)
| style="text-align:center" | no
| style="text-align:right" | 5
| style="text-align:right" | 1
| style="text-align:right" | 5
| style="text-align:right" | 15
| style="text-align:right" | 55
|-
| Power (energy/activation)
| style="text-align:center" | yes
| style="text-align:right" | 500
| style="text-align:right" | 20
| style="text-align:right" | 500
| style="text-align:right" | 1500
| style="text-align:right" | 5500
|-
| Hit Rate (hit/sec)
| style="text-align:center" | no
| style="text-align:right" | 5
| style="text-align:right" | 5
| style="text-align:right" | 5
| style="text-align:right" | 5
| style="text-align:right" | 5
|-
| Range (sectors)
| style="text-align:center" | no
| style="text-align:right" | 0.5
| style="text-align:right" | 0.5
| style="text-align:right" | 0.5
| style="text-align:right" | 1.5
| style="text-align:right" | 0.5
|-
| Beam Time (secs/activation)
| style="text-align:center" | no
| style="text-align:right" | 1
| style="text-align:right" | 1
| style="text-align:right" | 1
| style="text-align:right" | 1
| style="text-align:right" | 1
|-
| Special
|
|
|
| Split-beam
|
|
|}

{|class="wikitable"
!colspan="7"|Damage Pulse
|-
!colspan="3"|Stats for this system
!colspan="4"|Values for this system's slaves
|-
!width="200pt" | Name (unit)
!width="90pt" | Per module
!width="110pt" | Values
!width="110pt" | Cannon
!width="110pt" | Missile
!width="110pt" | Damage beam
!width="110pt" | Damage pulse
|-
| Damage (per activation)
| style="text-align:center" | yes
| style="text-align:right" | 100
| style="text-align:right" | 20
| style="text-align:right" | 20
| style="text-align:right" | 300
| style="text-align:right" | 600
|-
| Reload (seconds)
| style="text-align:center" | no
| style="text-align:right" | 10
| style="text-align:right" | 2
| style="text-align:right" | 2
| style="text-align:right" | 30
| style="text-align:right" | 60
|-
| Power (energy/activation)
| style="text-align:center" | yes
| style="text-align:right" | 500
| style="text-align:right" | 100
| style="text-align:right" | 100
| style="text-align:right" | 1500
| style="text-align:right" | 6000
|-
| Radius (blocks)
| style="text-align:center" | no
| style="text-align:right" | 10
| style="text-align:right" | 10
| style="text-align:right" | 10
| style="text-align:right" | 25
| style="text-align:right" | 40
|}

{|class="wikitable"
! rowspan="2"| Slave !!colspan="4"|Master
|-
| [[Damage Beam Computer|Beam]] || [[Cannon Computer|Cannon]] || [[Missile Computer|Missile]] || [[Damage Pulse Computer|Pulse]]
|-
| [[Damage Beam Computer|Beam]] || +Range || +Range, +Projectile speed || +Range, Lock-on homing || +Damage radius
|-
| [[Cannon Computer|Cannon]] || +Hit rate, -Damage per hit || -Reload time, -Damage, -Power cost || -Reload time, -Damage, -Blast radius, -Power cost || -Reload time, -Damage, -Power cost
|-
| [[Missile Computer|Missile]] || -Power, +Beams || -Damage, +Projectiles || +Missiles, heat-seeking (indiscriminate) || -Reload time, -Damage, -Power
|-
| [[Damage Pulse Computer|Pulse]] || -Hit Rate, +Damage per hit || +Damage, +Reload time, +Power cost || +Damage, +Reload time, -Missile speed, +Blast radius || +Damage, +Reload time
|}

==Trivia==
*A 5th Weapon system, Called the '''"Mine Layer"''', was originally part of the Weapon Overhaul (Alpha Version 0.15) but for unknown reasons, Schema halted work on it. It is still planned to be released but no date has been set.
**It would lay free floating mines that explode after an entity (ship,player, etc.) collides with it or a certain amount of time has passed.
** It's Slaved property would be "Delayed Action" and would give its master system unique timed/charging functions. For example, the Damage Beam+ Mine Layer combination would allow the player to hold down the Left Mouse Button to charge up the beam in order to fire a more powerful version of it.

==References==

<references/>

[[Category:Articles]]
[[Category:Ship]]
[[Category:Game Mechanics]]

Cannon Computer

2016-07-12T14:57:16Z

Olxinos: Tried to recreate the page based on the old wiki (I rewrote some things though since it was a bit long and sometimes outdated)

{{infobox block
|type=Cannon Computer
|hp=50
|armor=0%
|ahp=0
|shp=75
|mass=0.1
|light=no
|dv=6
}}

The '''Cannon Computer''' is one of the four main weapons systems in StarMade and is the only weapon system provided to all new players who start the game.

==Item Description==

The '''Cannon Computer''' is required for creating functioning Cannon systems.

It is capable of controlling any amount of [[Cannon Barrel|Cannon Barrels]], although using multiple groups imparts a 10% power consumption penalty for each group beyond the first. Once placed, you can select/deselect it with {{K|Select module}}, and link [[Cannon Barrel|Cannon Barrels]] using {{K|Connect module}} while it is selected and you are looking at a [[Cannon Barrel]].

Press {{K|Activate module}} to get in/out of the Computer."

==Manufacturing==

{{mfg
|type=factory
|using=Standard Factory
|ic1=500
|ic2=1000
|it1=Hylat Capsule
|it2=Crystal Composite
|oc1=1
|ot1=Cannon Computer
}}

==Usage==
:''Main article: [[Weapon Systems]]''

The unslaved cannon is the most simple and straight forward weapon system in the game. When linked with [[Cannon Barrels|Cannon Barrel]], it will fire one projectile per reload. In many ways it is comparable to a semi-automatic rifle. All Cannon variations require the user to lead their target as the projectile does not hit instantaneously like [[Damage Beam Computer|Damage Beams]]. Unlike [[Damage Beam Computer|Damage Beams]], the Cannons offer more range and an overall better damage per block ratio.

As of version 0.19282<ref>http://star-made.org/news/starmade-v0-19282-putting-more-fun-into-battles-also-boarding</ref>, Cannons' projectiles can destroy multiple blocks.

==Weapon Slaves==
=== Machine Gun ===
{| class="floatright" style="width: 21.5em;"
|-
| '''Slave:''' [[Cannon Computer|Cannon]]
|-
| '''PROS:'''
* Extremely versatile
* Requires fewer Power Capacitors
|-
| '''CONS:'''
* Its low damage per shot may fail to overcome high shield regenerations
|}

This combination is one of the most popular in the game. It fares well against armor, shields and systems alike and requires very few [[Power Capacitor|Power Capacitors]] to boot thanks to its low power consumption per shot.

====Notable Uses====
* All-purpose 
Often combined with a [[Punch Through Effect Computer|Punch-Through]] effect or more rarely with an [[Overdrive Effect Computer|Overdrive]] effect, this is your typical all-purpose weapon. They are sometimes found in groups of 891/891/891 or 443/443/443 (depending on whether you use Punch-Through or Overdrive) to destroy one [[Advanced Armor Block]] with full passives per shot.
* Shield-Nullifier 
High firerates help keeping an opponent's shields depleted, leaving its hull vulnerable. This is even more pronounced if combined with a [[Ion Effect Computer|Ion]] effect.
* Momentum Guns 
Combined with a [[Push Effect Computer|Push]], [[Pull Effect Computer|Pull]] or [[Stop Effect Computer|Stop]] effect, the Machine gun affects the target's movement at the expense of overall weapon damage.It's an effective means of position enemies where you want them(i.e pulling them in to get a better shot, pushing them away, or holding them in space).
* Anti-missile system 
Cannons are the only weapon able to hit missiles and missiles are always destroyed in one shot, hence small fast firing cannons are often used as anti-missile system.
* Flak Gun: 
AI turrets that feature Cannon+Cannon systems can completely fill the skies with projectiles and is a good way of pressuring your enemy.

===Shotgun===
{| class="floatright" style="width: 21.5em;"
|-
| '''Slave:''' [[Missile Computer|Missile]]
|-
| '''PROS:'''
* Capable of hitting multiple targets at once
|-
| '''CONS:'''
* Extremely poor accuracy unless at point blank range
|}

One of the most unique weapon combinations, the Shotgun allows the cannon to damage more than one block at a time. Increasing the amount of Missile tubes connected to the slave will increase the amount of projectiles fired from a single grouping. At a 1:1 Master/Slave ratio the cannon will fire 10 bullets from every grouping although unfortunately more projectiles comes at the cost of damage per bullet. Current game limitations prevent shot spreads from being truly random thus making every bullet fly in the same pattern/direction.
At the present (Alpha Version 0.19174), the Shotgun is only useful in highly specialized weapon configurations.

====Notable Uses====
* Flak Cannon 
In large enough groupings, Shotgun arrays can fill the entire screen with bullets. They are sometimes used as an auxiliary anti-missile system.
----
=== Sniper Cannon ===
{| class="floatright" style="width: 21.5em;"
|-
| '''Slave:''' [[Damage Beam Computer|Damage Beam]]
|-
| '''PROS:'''
* Second longest range in the game
* Faster Bullets
* Moderately high damage per shot
|-
| '''CONS:'''
* Difficult to aim at longer distances
* High energy usage
|}

Depending on the server size and ai accuracy settings you're playing with, the range boost can be negligible or an interesting asset. The increased projectile speed however is always useful and the moderate damage per shot increase nicely complements the Cannon slave version. Unfortunately, it is impossible to really benefit from the increased range when firing these weapons manually so it will often be left to turrets and other AI controlled weapons.

====Notable Uses====

* Piercing cannon 
While a Cannon slave is usually more efficient (since it requires fewer capacitors), the increased damage per shot of this combination makes it interesting to pierce through what could otherwise be near impenetrable defenses (like multiple layers of [[Advanced Armor Block|Advanced Armor]] or very high shield regeneration rates). It is especially efficient when paired with either [[Punch Through Effect Computer|Punch-Through]], partial or total [[Ion Effect Computer|Ion]] or even [[Piercing Effect Computer|Piercing]] effects depending on what kind of defenses you plan to overcome.
* (AI only) Detection system 
As of Alpha Version 0.19174, The AI's ability to detect a enemy is completely dependent on the range of its weapons. Even with the smallest possible configuration a 1:1 Sniper system will allow the AI to "see" targets coming at the maximum range the game allows.

----

=== Siege Cannon ===
{| class="floatright" style="width: 21.5em;"
|-
| '''Slave:''' [[Damage Pulse Computer|Damage Pulse]]
|-
| '''PROS:'''
* High damage per shot
|-
| '''CONS:'''
* Requires a lot of Power Capacitors
* Long reload time
|}

This combination suffers from the comparison with either the Sniper Cannon for low power capacity ships, or other power-hungry weapons like Smart Missiles for low power regeneration ships. It can however deal massive damage assuming you can reliably hit your target and may help deplete large shield pools.

====Notable Uses====

* Heavy Anti-Shield Cannon 
Due to shields being a single entity a High damage cannon system can help deplete large portions of it.

==Trivia==
* Currently the Cannon is the only weapon in the game whose projectile changes in size to represent its damage output.
* Despite what one might think, Machine Gun system's(Cannon+Cannon) rapid fire speed can not be fully replicated via a logic clock.
* Prior to the Weapon update (Alpha Version 0.15), The Cannon (Formerly called "Anti-Matter Cannon") was extremely over powered. Adding more weapon modules increased virtually all stats (Damage, Range, Rate of fire). Massive groups were capable of firing faster than 1:1 Cannon+Cannon combos, Had ranges of multiple sectors, and each bullet doing thousands of points of damage.

==References==
<references/>

Cannon Barrel

2016-07-12T11:29:46Z

Olxinos: /* Manufacturing */

{{Stub}}
{{infobox block
|type=Cannon Barrel
|hp=100
|armor=0%
|ahp=0
|shp=100
|mass=0.1
|light=no
|dv=16
}}

==Item Description==

The '''Cannon Barrel''', when used in conjunction with a [[Cannon Computer]], can create a basic but effective weapon system firing a simple projectile in a straight line.

==Manufacturing==
{{mfg
|type=factory
|using=Standard Factory
|ic1=50
|ic2=100
|it1=Hylat Capsule
|it2=Crystal Composite
|oc1=1
|ot1=Cannon Barrel
}}

==Usage==
:''Main article: [[Cannon Computer]]''

'''Cannon Barrels''' must be linked to a [[Cannon Computer]] in order to function. To that end the computer must be selected with the {{K|Select module}} key, then either the {{K|Connect module}} or {{K|Connect modules}} keys (bulk connection) may be used to link or unlink the desired '''Cannon Barrels'''.

[[Category:Stubs]] [[Category:Ship]] [[Category:Weapons]]

Template:Mfg

2016-07-12T11:27:46Z

Olxinos: replaced some French terms with English terms

<table class="darktable {{{bodyclass|}}}" cellspacing="5" style="text-align: center; line-height: 1.5em; font-size: 100%; margin: 0; {{{bodystyle|}}}">
{{#if: 1 {{{type|}}} |
<tr style="font-size: 125%;">
{{#ifeq: {{{type|}}} | refinery |
<th colspan="6" style="text-align: center; {{headerstyle}}}">Infos de raffinage</th>|
<th colspan="6" style="text-align: center; {{headerstyle}}}">Production Info</th>
}}
</tr>

<tr>
{{#ifeq: {{{type}}} | refinery
| <td colspan="3" style="font-size: 100%; font-weight: bold; text-align: center; {{headerstyle}}}">Raffiné dans une</td>
| <td colspan="3" style="font-size: 100%; font-weight: bold; text-align: center; {{headerstyle}}}">Produced in a</td>
}}
{{mfg/entry| type={{{using}}} | 3col=true | lastcol=true }}
</tr>
}}

<tr>
<th colspan="3" style="border-right: solid 1px; text-align: center; {{headerstyle}}}">Requires</th><th colspan="3" style="text-align: center; {{{headerstyle}}}">To create</th>
</tr>

<tr>
{{mfg/entry| count= {{{ic1|1}}} | type={{{it1}}} }}
{{mfg/entry| count= {{{oc1|1}}} | type={{{ot1}}} | lastcol=true }}
</tr>
{{#if: {{{it2|}}}{{{ot2|}}} |
<tr>
{{#if: {{{it2|}}} |
{{mfg/entry| count= {{{ic2|1}}} | type={{{it2}}} }} |
<td colspan="3" style="border-right: solid 1px;" />
}}
{{#if: {{{ot2|}}} |
{{mfg/entry| count= {{{oc2|1}}} | type={{{ot2}}} | lastcol=true }} |
<td colspan="3"/>
}}
</tr>
}}

{{#if: {{{it3|}}}{{{ot3|}}} |
<tr>
{{#if: {{{it3|}}} |
{{mfg/entry| count= {{{ic3|1}}} | type={{{it3}}} }} |
<td colspan="3" style="border-right: solid 1px;"/>
}}
{{#if: {{{ot3|}}} |
{{mfg/entry| count= {{{oc3|1}}} | type={{{ot3}}} | lastcol=true }} |
<td colspan="3"/>
}}
</tr>
}}

{{#if: {{{it4|}}}{{{ot4|}}} |
<tr>
{{#if: {{{it4|}}} |
{{mfg/entry| count= {{{ic4|1}}} | type={{{it4}}} }} |
<td colspan="3" style="border-right: solid 1px;"/>
}}
{{#if: {{{ot4|}}} |
{{mfg/entry| count= {{{oc4|1}}} | type={{{ot4}}} | lastcol=true }} |
<td colspan="3"/>
}}
</tr>
}}
</table><noinclude>
{{Documentation}}
</noinclude>

Cannon Barrel

2016-07-12T11:21:48Z

Olxinos: correctly uses the mfg template

{{Stub}}
{{infobox block
|type=Cannon Barrel
|hp=100
|armor=0%
|ahp=0
|shp=100
|mass=0.1
|light=no
|dv=16
}}

==Item Description==

The '''Cannon Barrel''', when used in conjunction with a [[Cannon Computer]], can create a basic but effective weapon system firing a simple projectile in a straight line.

==Manufacture==
{{mfg
|type=factory
|using=Standard Factory
|ic1=50
|ic2=100
|it1=Hylat Capsule
|it2=Crystal Composite
|oc1=1
|ot1=Cannon Barrel
}}

==Usage==
:''Main article: [[Cannon Computer]]''

'''Cannon Barrels''' must be linked to a [[Cannon Computer]] in order to function. To that end the computer must be selected with the {{K|Select module}} key, then either the {{K|Connect module}} or {{K|Connect modules}} keys (bulk connection) may be used to link or unlink the desired '''Cannon Barrels'''.

[[Category:Stubs]] [[Category:Ship]] [[Category:Weapons]]

Cannon Barrel

2016-07-12T10:12:36Z

Olxinos: Created page with "{{Stub}} {{infobox block |type=Cannon Barrel |hp=100 |armor=0% |ahp=0 |shp=100 |mass=0.1 |light=no |dv=16 }} ==Item Description== The '''Cannon Barrel''', when used..."

{{Stub}}
{{infobox block
|type=Cannon Barrel
|hp=100
|armor=0%
|ahp=0
|shp=100
|mass=0.1
|light=no
|dv=16
}}

==Item Description==

The '''Cannon Barrel''', when used in conjunction with a [[Cannon Computer]], can create a basic but effective weapon system firing a simple projectile in a straight line.

==Manufacture==

It is constructed in a [[Standard Factory]] using:
{| class="wikitable"
!Resource
!Quantity Needed
|-
|[[Hylat Capsule]]
|50
|-
|[[Crystal Composite]]
|100
|}

==Usage==
:''Main article: [[Cannon Computer]]''

'''Cannon Barrels''' must be linked to a [[Cannon Computer]] in order to function. To that end the computer must be selected with the {{K|Select module}} key, then either the {{K|Connect module}} or {{K|Connect modules}} keys (bulk connection) may be used to link or unlink the desired '''Cannon Barrels'''.

[[Category:Stubs]] [[Category:Ship]] [[Category:Weapons]]

Template:Infobox block

2016-07-12T10:10:07Z

Olxinos: replaced French terms by English terms

{{infobox
|name =
|bodystyle = width: 21.5em; padding: 0em;
|above = {{{name|{{PAGENAME}}}}}
|abovestyle = font-size: large; padding:5px;
|image =
|imagestyle =
|caption =
|captionstyle =
|headerstyle = padding: 0em; height: 1.8em;
|labelstyle = padding: 0.1em 0.5em;
|datastyle = padding: 0.1em 0.5em;

|data2 = {{{image|[[File:{{PAGENAME}}.png|150px]]}}}
|label3 = Type
|data3 = {{{type|}}}
|label4 = Hit Points
|data4 = {{{hp|}}}
|label5 = Armor
|data5 = {{{armor|}}}
|label6 = Armor HP
|data6 = {{{ahp}}}
|label7 = Structure HP
|data7 = {{{shp}}}
|label8 = Mass
|data8 = {{{mass|}}}
|label9 = Luminosity
|data9 = {{{light|}}}
|label10 = Data Value (ID)
|data10 = {{{dv|}}}
}}<noinclude>{{Documentation}}</noinclude>

Defense Systems

2016-07-09T07:27:25Z

Olxinos: Corrected combat regeneration

In [[StarMade]], each block has a [[Defense_Systems#Hit Points|hit point]] (HP) and an [[Defense_Systems#Armor|armor]] value. If a block is hit by any offensive weapon, the HP value of the block is lowered. If a block's HP is lowered to zero, the block is destroyed.

A pilot is instantly killed if the [[Ship Core]] is destroyed. The empty ship can then be looted, salvaged, or left in space for a short period before the core explodes (unless a player initiates a reboot before the timer is up by approaching the core in [[Modes#Astronaut Mode|Astronaut Mode]] and pressing {{K|Activate module}}).

==Shields==

Shields are currently the most useful defensive system. They are made of two blocks, the [[Shield Capacitator]] and the [[Shield-Recharger]]. The amount of shield health, and speed of regeneration, are set by the amount of [[Shield Capacitator]]s and [[Shield-Recharger]]s on the ship. While your ship has any amount of shield health remaining, no blocks can be destroyed. As soon as all shields are depleted, the ship's blocks will begin taking damage.

Once a ship's shields have been fully depleted, they will stop recharging for 10 seconds. After this 10 seconds has elapsed, the shields will begin recharging once more. However, if the ship is still taking damage, it is likely that they will be rapidly depleted again, and another 10 second recovery time will begin.

Unlike most other ship systems, Shield systems require no controller, nor do they have any placement rules which affect efficiency. Thus [[Shield Capacitator]]s and [[Shield-Recharger]]s may be placed anywhere on the ship, do not need to be grouped or linked, and are often used to fill in any spaces or pockets within the ship. The only design consideration is choosing the amount of shielding capacity and the speed of shield regeneration, keeping in consideration the power demands the [[Shield-Recharger]]s will make on the ship's [[Power_Systems|power system]].

===Shield Rules===
{| class="wikitable"
|-
! '''LEGEND'''
|-
| '''C''' || Shield Capacity
|-
| '''NC''' || Number of Shield Capacitators
|-
| '''NR''' || Number of Shield-Rechargers
|-
| '''R''' || Shield Regeneration per Second
|-
| '''S''' || Current amount of shields
|-
| '''P''' || Power Usage
|}

The exact capacity, regeneration, and power consumption of a shield system can be calculated by using a few different formulas.
Any decimal results produced by these formulas should be rounded down to the nearest whole number.

The shield capacity, '''C''', of a ship with '''NC''' number of [[Shield Capacitator]]s, can be found by the formula: 
<tt style="font-size: large">'''C''' = '''NC'''0.9791797578 * '''110''' + '''220'''</tt>.

The shield regeneration per second, '''R''', of a ship with '''NR''' number of [[Shield-Recharger]]s, can be found by the formula: 
<tt style="font-size: large">'''R''' = '''NR''' * '''5.5'''</tt>

Upon taking a hit, the shield regeneration per second drops to 
<tt style="font-size: large">'''R''' = '''NR''' * '''5.5''' * '''0.25''' * ('''1''' - '''0.5''' * '''S''' / '''C''')</tt> 
for 1mn where '''S''' is the current amount of remaining shields (effectively reducing the shield regeneration by 82.25% to 75% depending if your ship's shields are full or nearly depleted)

The power usage per second, '''P''', for a given number of [[Shield-Recharger]]s changes depending on whether or not the ship's shields are fully charged.

If the shields are fully charged: 
<tt style="font-size: large">'''P''' = '''R''' </tt>

If the shields are not fully charged: 
<tt style="font-size: large">'''P''' = '''10''' * '''R''' </tt>

==Armor==
[[File:Armor_and_Piercing_Explained.png|thumb|An explanation of how armor reduction works]]
All blocks have an '''armor''' value. Armor diminishes the hit point (HP) damage taken by the block from a weapon. The more armor a block has, the less HP damage it will take per hit. For damage done with an [[Effects|effect]] that deals additional damage to other blocks, the independent armor values for the other affected blocks are calculated into the damage reduction formula before damage is applied to them.
 
For example, if an advanced armor block (which has an armor value of 75%) is attacked with a [[Damage_Beam_Computer|Damage Beam]] that also has the [[Effects|Piercing effect]] linked to it, the damage taken by the advanced armor block is first reduced by 75%. Every block that follows behind that one will reduce the damage it takes by its own armor value before the HP damage is applied. A visual example with mathematical calculations is provided in the image to the right. The information in the light-blue box is what initially occurs, while the information in the blue box is what actually occurs (due to the Piercing effect).
 
In practice, armor generally proves to be an ineffective way to defend against attacks, and one or more of the other methods are required.

==Hit Points==
[[File:Damaged_Blocks.png|thumb|Blocks in various damaged states]]
In addition to having an armor value, all blocks have a '''hit point (HP)''' value as well. The HP of a block determines whether or not the block continues to exist after being influenced by a foreign source. As a block takes HP damage, the color of the block will begin to turn a bright orange, similar to that of [[Lava|lava]]. The more lava-like a block appears, the less HP it has. When a block's HP reaches zero, the block will be destroyed and will no longer be usable by anyone. See the image to the right for an example of what blocks look like in various damaged states, as well as what a block looks like when it is destroyed.
 
The ship as a whole also has an HP value based on the HP of the blocks it is made of. The HP of a ship is separated into two types: Structure HP and Armor HP.
System blocks, such as weapon modules, computers, shield blocks, and power blocks, add their HP to the Structure HP of the ship. Weapons that cause damage to a system block will reduce the HP of that individual block as well as the total Structure HP of the ship. If the Structure HP of a ship drops below a certain percentage, it begins to lose functionality in different systems, regardless of whether those systems were ever directly damaged by a weapon. The lower the Structure HP becomes, the more systems are affected. Ships will also overheat if their Structure HP drops too low, forcing the player out of the core.
Armor HP is calculated by the armor value of armor and hull blocks. When a weapon does damage to an armor block, half of the damage is applied to the Armor HP rather than to the Structure HP. Armor HP will not cause major losses in ship system performance if it drops too low.
Larger ships take more damage per block hit than smaller ships.

While below full Structure HP, changes made to the ship will not affect HP as normal. Removing blocks will only reduce current HP; there is no effect on maximum HP. Conversely, adding blocks will only increase maximum HP and have no effect on current HP. Thus, adding or removing blocks only reduces the current percent of HP while the structure HP is below full.

To restore the HP of a ship, a player must initiate a system reboot. To initiate a reboot, the pilot must press {{K|Select previous entity}} while inside the core or, if the ship is overheating, activate {{K|Activate Module}} the ship core. While rebooting, power and shields will drain and the ship will not be controllable. Rebooting the ship takes longer the more HP the ship is missing. Reboots can be finished instantly for a price at shops. After the reboot has finished, the maximum HP of the ship will change to accurately represent the HP of the blocks that make it up, and the current percent HP will become 100%. Armor is not restored through a reboot; it must be repaired at a shop for a price. Note that a reboot will not restore blocks that have been destroyed, so manual repairs must be made after a reboot.

==Turrets==

[[Ship|Ships]], [[Space Station|stations]], and [[Planet|planets]] can be equipped with [[Turret|turrets]]. Turrets can be designed defensively to attack enemy ships and missiles.

While small ships are not usually a significant threat to large ships (except in groups), the large ship will likely have difficulty bringing its forward weapon batteries to bear on a smaller, more mobile target. In this situation, if the large ship has turrets, it can defend itself effectively against the small ship. Turrets can be controlled by a player or a [[BOBBY AI Module]]. When designing your turrets, keep in mind that just like ships, a larger turret may carry more shielding and weapons making it less vulnerable to attack and more dangerous, but it also turns more slowly making it less able to hit small, fast targets. On very large ships, it is often wise to mount turrets of different sizes of turrets to handle a broad range of targets.

To defend against missiles with turrets, it is advised to use a [[BOBBY AI Module]] that fires a cannon weapon and is set to attack missiles only. The power of this weapon is not relevant, as missiles have 1 HP and 0 armor. It is best to slave cannons (for rapid fire) or missiles (for spread fire) to the primary cannons as these increase the number of projectiles fired, increasing the chance of hitting the missile. Originally, only beams could destroy missiles, but this is no longer the case. Only cannons work in recent versions, although the [[BOBBY AI Module]] will fire any weapon at missiles regardless of whether the particular weapon can actually destroy the missile.

==Effect Modules as a Defense==

In addition to being a tertiary modification for weapons, effect modules can be used on their own for defensive purposes. For example, the [[Ion_Effect_Computer|Ion Effect system]] can provide defense if left un-linked to a weapons system. When activated, it will provide a boost to the shield system, based on the ratio of [[Ion_Effect_Module|Ion Effect modules]] to ship mass.

See the [[Effects#Defensive Use|Defensive Use]] section of the Effects page for more information.

[[Category:Ship]]

Thruster Module

2016-07-09T07:18:56Z

Olxinos: /* Formulas */

This article details the existence and use of a Thruster Module

==The Essentials==

A Thruster Module (Formerly known as a Hypercoil Thruster) is required to give a ship propulsion, and subsequently, the ability to move. Thrust used to only impact a ship's acceleration, however as of [http://star-made.org/news/starmade-v0-19538-new-thruster-mechanics 0.19538] it also determines the max speed of a ship (ranging from half the server speed to three times the server speed, which can be further increased with the help of a defensive [[Overdrive Effect Computer|Overdrive effect]]). Even if a core on its own doesn't provide any thrust, a ship made of a single core and a couple blocks is faster than an astronaut (in vanilla and most server configurations) while reasonably maneuverable. However if a player wants anything to move at a decent speed then additional Thruster Modules will be required.

Starmade's thrust system has diminishing returns. In other words, the mother thrusters you have, the less each thruster block adds to your thrust. In practice, this makes ships slower and less maneuverable as their mass increases.

==Module Use==

Thrusters are very commonly used for decorative purposes, either in large groups or scattered around individually. Thruster Module do not gain any additional bonuses from being adjacent to another Thruster Module, and so may be placed freely without any constraints. Often times it's seen as a good idea to have small groups of thrusters separated around a ship, so that it's harder to target them down and shut down a ship's movement. While it may be difficult with the many other modules in place, it's certainly recommended for absolute safety.

Not only that, but considering the amount of thruster modules often needed, while uncommon, they can be used as a "system shield" to layer over other more important/more expensive systems so as to keep them safer, possibly increasing a ship's combat endurance. This ultimately depends on the ship and it's role, but for say a brawler where speed is not exactly important, it could be a good idea to use Thruster Modules to protect the more defensive/tanky modules.

Thrust carries between entities. You may have a separate entity made up entirely of Thruster Modules, and dock it to a much larger ship, giving the parent ship the thrust from the child ship (you however have to "inherit thrusters from docks", this option is available under the Structure/Thrust menu). Your total thrust will then be calculated as if all your Thruster Modules were placed on the main entity rather than divided between several docked entities.

==Formulas==

The total thrust of a ship is determined by its number of Thruster Modules only (including the Thruster Modules placed on docked entities if you inherited thrusters from docks). The formula is as follows:

<tt style="font-size: large">'''Thrust''' = 0.75 * (5.5 * '''NumberOfThrusterModules''')0.87</tt>

Therefore, the required number of Thruster Modules to have a given Thrust score is:

<tt style="font-size: large">'''NumberOfThrusterModules''' = ('''Thrust''' / 0.75)1/0.87 / 5.5</tt>

The maximal speed is determined by the thrust to mass ratio of a ship and the server speed setting (this speed may then be further increased with an [[Overdrive Effect Computer|Overdrive effect]]):

<tt style="font-size: large">'''MaxSpeed''' = (max('''Thrust''' / '''Mass''', 2.5) + 0.5) * '''ServerSpeed'''</tt>

The thrusters' power consumption per second is linear in the number of Thruster Modules:

<tt style="font-size: large">'''EnergyConsumption''' = 100 * '''NumberOfThrusterModules''' / 3</tt>

Thruster Module

2016-07-09T07:18:37Z

Olxinos: /* Formulas */

This article details the existence and use of a Thruster Module

==The Essentials==

A Thruster Module (Formerly known as a Hypercoil Thruster) is required to give a ship propulsion, and subsequently, the ability to move. Thrust used to only impact a ship's acceleration, however as of [http://star-made.org/news/starmade-v0-19538-new-thruster-mechanics 0.19538] it also determines the max speed of a ship (ranging from half the server speed to three times the server speed, which can be further increased with the help of a defensive [[Overdrive Effect Computer|Overdrive effect]]). Even if a core on its own doesn't provide any thrust, a ship made of a single core and a couple blocks is faster than an astronaut (in vanilla and most server configurations) while reasonably maneuverable. However if a player wants anything to move at a decent speed then additional Thruster Modules will be required.

Starmade's thrust system has diminishing returns. In other words, the mother thrusters you have, the less each thruster block adds to your thrust. In practice, this makes ships slower and less maneuverable as their mass increases.

==Module Use==

Thrusters are very commonly used for decorative purposes, either in large groups or scattered around individually. Thruster Module do not gain any additional bonuses from being adjacent to another Thruster Module, and so may be placed freely without any constraints. Often times it's seen as a good idea to have small groups of thrusters separated around a ship, so that it's harder to target them down and shut down a ship's movement. While it may be difficult with the many other modules in place, it's certainly recommended for absolute safety.

Not only that, but considering the amount of thruster modules often needed, while uncommon, they can be used as a "system shield" to layer over other more important/more expensive systems so as to keep them safer, possibly increasing a ship's combat endurance. This ultimately depends on the ship and it's role, but for say a brawler where speed is not exactly important, it could be a good idea to use Thruster Modules to protect the more defensive/tanky modules.

Thrust carries between entities. You may have a separate entity made up entirely of Thruster Modules, and dock it to a much larger ship, giving the parent ship the thrust from the child ship (you however have to "inherit thrusters from docks", this option is available under the Structure/Thrust menu). Your total thrust will then be calculated as if all your Thruster Modules were placed on the main entity rather than divided between several docked entities.

==Formulas==

The total thrust of a ship is determined by its number of Thruster Modules only (including the Thruster Modules placed on docked entities if you inherited thrusters from docks). The formula is as follows:

<tt style="font-size: large">'''Thrust''' = 0.75 * (5.5 * '''NumberOfThrusterModules''')0.87</tt>

Therefore, the required number of Thruster Modules to have a given Thrust score is:

<tt style="font-size: large">'''NumberOfThrusterModules''' = ('''NumberOfThrusterModules''' / 0.75)1/0.87 / 5.5</tt>

The maximal speed is determined by the thrust to mass ratio of a ship and the server speed setting (this speed may then be further increased with an [[Overdrive Effect Computer|Overdrive effect]]):

<tt style="font-size: large">'''MaxSpeed''' = (max('''Thrust''' / '''Mass''', 2.5) + 0.5) * '''ServerSpeed'''</tt>

The thrusters' power consumption per second is linear in the number of Thruster Modules:

<tt style="font-size: large">'''EnergyConsumption''' = 100 * '''NumberOfThrusterModules''' / 3</tt>

Effects

2016-07-09T07:16:20Z

Olxinos: Updated piercing/punch-through effects added the blast radius increase of overdrive on missiles/pulses

{{WIP}}

'''Effects''' are modifications to a ship that can be used either offensively or defensively. When [[Linking|linked]] (slaved) to a [[Weapon_Systems|weapon]], the projectile produced from the weapon will have an added effect that modifies how that weapon behaves. <ref>http://star-made.org/news/balance-and-effects</ref> When used independently, the ship will either perform a defensive action or it will create a defensive effect for the ship, so long as the computer producing the effect remains activated in the hotbar.

==Offensive Use==

Effects linked to [[Weapon_Systems|weapons]] are a tertiary modification that alters the weapon's overall behaviour (the secondary being [[Weapon_Systems#Support_systems|weapon supports]], which are created by linking two weapon computers together). The number of effect modules linked to their respective computer determines how much of the effect is applied to the linked weapon's output. In order to achieve 100% effect on a weapon, the number of effect modules linked to the effect's computer must be on a 1:1 ratio to the number of weapon modules that the effect's computer is linked to. Most effect modules uses the fraction of parent weapon's damage and converts it into effect value, while some systems amplify the base damage for specific targets, while reducing it efficiency against others. Regardless, effect modules would increase the overall size of the weapon and it's damage output similar to weapon modules. 
 
Example: 
There are 40 missile tubes on a ship that is being built. The owner wants to add a stop effect to the missiles, but still wants the missiles to do damage, so the owner would like the stop effect to be at 25%. 
Since there are 40 missile tubes on the ship, in order to achieve the desired 25% effect (1:4 ratio), a total of 10 stop modules will need to be placed on the ship and linked to a stop computer; this stop computer will then need to be linked (slaved) to the missile computer in the [[Weapons_Tab|Weapons Tab]] in order to be applied to the projectiles produced by the weapon. As result, missile system built by the owner will convert 25% of it's damage into a Stop effect' strength.

===Offensive Effects===

{|class="wikitable"
! Effect Name !! Description
|-
| EMP Effect || Converts block damage into damage that reduces the target's power supply instead.
|-
| Explosive Effect || For damage beams and cannons, spreads the weapon's damage to also affect the six blocks adjacent to the hit block. For missiles and pulses, increases the blast radius.
|-
| Ion Effect || Increases damage done to shields, but reduces damage done to blocks.
|-
| Overdrive Effect || Increases block damage, but dramatically increases the amount of power required to fire the weapon. Also increases the blast radius for missiles and pulses.
|-
| Piercing Effect || For damage beams and cannons, slightly increases block damage and decreases opponent armor efficiency, but decreases shield damage. For missiles and pulses, slightly increases the blast radius and decreases opponent armor efficiency.
|-
| Pull Effect || Reduces block damage in exchange for an effect that pulls the target towards the damage source.
|-
| Punch-Through Effect || For damage beams and cannons, increases block and armor damage. For missiles and pulses, slightly increases the blast radius and increases armor damage.
|-
| Push Effect || Reduces block damage in exchange for an effect that pushes the target away from the damage source.
|-
| Stop Effect || Converts block damage into a braking effect to hold the target in place.
|}

==Defensive Use==

Effect computers that are placed on the hotbar without being linked (slaved) to a weapon will produce a defensive effect for the ship. Some effects are activated ("on/off switch") and remain persistent so long as its respective computer is "on", while others produce a burst effect. Effects that remain active increase the power consumption (cons) of the ship.
 
The efficiency of the effect produced is proportional to the mass of the ship using the computer (awaiting confirmation). Keep in mind that modules and computers add mass to the ship as well.

===Defensive Effects===

{|class="wikitable"
! Effect Name !! Description !! Type
|-
| EMP Effect || '''Power Damage Protection:''' Reduces damage that would target the ship's power supply. || Activated
|-
| Explosive Effect || '''Moment[sic] Effect Protection:''' Reduces the effectiveness of weapons that modify a ship's position. || Activated
|-
| Ion Effect || '''Shield Protection Bonus:''' Decreases damage that would be dealt to the ship's shields. || Activated
|-
| Overdrive Effect || '''Top Speed Bonus:''' Increases the top speed achievable by the ship. 100% efficiency system will double the top speed. || Activated
|-
| Piercing Effect || '''Block Armor Bonus:''' Increases the effectiveness of armor on armored blocks. || Activated
|-
| Pull Effect || '''Evade Burst:''' Produces a burst of motion that propels the ship backward. || Burst
|-
| Punch-Through Effect || '''Protection Against Piercing Projectiles:''' Reduces the damage taken by blocks affected by a weapon that is utilizing the Piercing Effect. || Activated
|-
| Push Effect || '''Take Off Burst:''' Produces a burst of motion that propels the ship forward. || Burst
|-
| Stop Effect || '''Anti Gravity:''' Reduces the effect of gravitational pull from sources such as planets and black holes. || Activated
|}

==References==
<references/>

[[Category:Effect]]

Thruster Module

2016-07-09T07:09:13Z

Olxinos:

This article details the existence and use of a Thruster Module

==The Essentials==

A Thruster Module (Formerly known as a Hypercoil Thruster) is required to give a ship propulsion, and subsequently, the ability to move. Thrust used to only impact a ship's acceleration, however as of [http://star-made.org/news/starmade-v0-19538-new-thruster-mechanics 0.19538] it also determines the max speed of a ship (ranging from half the server speed to three times the server speed, which can be further increased with the help of a defensive [[Overdrive Effect Computer|Overdrive effect]]). Even if a core on its own doesn't provide any thrust, a ship made of a single core and a couple blocks is faster than an astronaut (in vanilla and most server configurations) while reasonably maneuverable. However if a player wants anything to move at a decent speed then additional Thruster Modules will be required.

Starmade's thrust system has diminishing returns. In other words, the mother thrusters you have, the less each thruster block adds to your thrust. In practice, this makes ships slower and less maneuverable as their mass increases.

==Module Use==

Thrusters are very commonly used for decorative purposes, either in large groups or scattered around individually. Thruster Module do not gain any additional bonuses from being adjacent to another Thruster Module, and so may be placed freely without any constraints. Often times it's seen as a good idea to have small groups of thrusters separated around a ship, so that it's harder to target them down and shut down a ship's movement. While it may be difficult with the many other modules in place, it's certainly recommended for absolute safety.

Not only that, but considering the amount of thruster modules often needed, while uncommon, they can be used as a "system shield" to layer over other more important/more expensive systems so as to keep them safer, possibly increasing a ship's combat endurance. This ultimately depends on the ship and it's role, but for say a brawler where speed is not exactly important, it could be a good idea to use Thruster Modules to protect the more defensive/tanky modules.

Thrust carries between entities. You may have a separate entity made up entirely of Thruster Modules, and dock it to a much larger ship, giving the parent ship the thrust from the child ship (you however have to "inherit thrusters from docks", this option is available under the Structure/Thrust menu). Your total thrust will then be calculated as if all your Thruster Modules were placed on the main entity rather than divided between several docked entities.

==Formulas==

The total thrust of a ship is determined by its number of Thruster Modules (including the Thruster placed on docked entities if you inherited thrusters from docks) only. The formula is as follows:

<tt style="font-size: large">'''Thrust''' = 0.75 * (5.5 * '''NumberOfThrusterModules''')0.87</tt>

Therefore, the required number of Thruster Modules to have a given Thrust score is:

<tt style="font-size: large">'''NumberOfThrusterModules''' = ('''NumberOfThrusterModules''' / 0.75)1/0.87 / 5.5</tt>

The maximal speed is determined by the thrust to mass ratio of a ship and the server speed setting (this speed may then be further increased with an [[Overdrive Effect Computer|Overdrive effect]]):

<tt style="font-size: large">'''MaxSpeed''' = (max('''Thrust''' / '''Mass''', 2.5) + 0.5) * '''ServerSpeed'''</tt>

The thrusters' power consumption per second is linear in the number of Thruster Modules:

<tt style="font-size: large">'''EnergyConsumption''' = 100 * '''NumberOfThrusterModules''' / 3</tt>

Thruster Module

2016-07-09T06:50:19Z

Olxinos: /* Module Use */

Thruster Module

2016-07-09T06:48:51Z

Olxinos: /* Module Use */

This article details the existence and use of a Thruster Module

==The Essentials==

A Thruster Module (Formerly known as a Hypercoil Thruster) is required to give a ship propulsion, and subsequently, the ability to move. Thrust used to only impact a ship's acceleration, however as of [http://star-made.org/news/starmade-v0-19538-new-thruster-mechanics 0.19538] it also determines the max speed of a ship (ranging from half the server speed to three times the server speed, which can be further increased with the help of a defensive [[Overdrive Effect Computer|Overdrive effect]]). Even if a core on its own doesn't provide any thrust, a ship made of a single core and a couple blocks is faster than an astronaut (in vanilla and most server configurations) while reasonably maneuverable. However if a player wants anything to move at a decent speed then additional Thruster Modules will be required.

Starmade's thrust system has diminishing returns. In other words, the mother thrusters you have, the less each thruster block adds to your thrust. In practice, this makes ships slower and less maneuverable as their mass increases.

==Module Use==

Thrusters are very commonly used for decorative purposes, either in large groups or scattered around individually. Thruster Module do not gain any additional bonuses from being adjacent to another Thruster Module, and so may be placed freely without any constraints. Often times it's seen as a good idea to have small groups of thrusters separated around a ship, so that it's harder to target them down and shut down a ship's movement. While it may be difficult with the many other modules in place, it's certainly recommended for absolute safety.

Not only that, but considering the amount of thruster modules often needed, while uncommon, they can be used as a "system shield" to layer over other more important/more expensive systems so as to keep them safer, possibly increasing a ship's combat endurance. This ultimately depends on the ship and it's role, but for say a brawler where speed is not exactly important, it could be a good idea to use Thruster Modules to protect the more defensive/tanky modules.

Thrust carries between entities. You may have a separate entity made up entirely of Thruster Modules, and dock it to a much larger ship, giving the parent ship the thrust from the child ship (you however have to "inherit thrust from docks", this option is available under the Structure/Thrust menu). Your total thrust will then be calculated as if all your Thruster Modules were placed on the main entity rather than divided between several docked entities.

Thruster Module

2016-07-09T06:48:15Z

Olxinos: /* Module Use */

This article details the existence and use of a Thruster Module

==The Essentials==

A Thruster Module (Formerly known as a Hypercoil Thruster) is required to give a ship propulsion, and subsequently, the ability to move. Thrust used to only impact a ship's acceleration, however as of [http://star-made.org/news/starmade-v0-19538-new-thruster-mechanics 0.19538] it also determines the max speed of a ship (ranging from half the server speed to three times the server speed, which can be further increased with the help of a defensive [[Overdrive Effect Computer|Overdrive effect]]). Even if a core on its own doesn't provide any thrust, a ship made of a single core and a couple blocks is faster than an astronaut (in vanilla and most server configurations) while reasonably maneuverable. However if a player wants anything to move at a decent speed then additional Thruster Modules will be required.

Starmade's thrust system has diminishing returns. In other words, the mother thrusters you have, the less each thruster block adds to your thrust. In practice, this makes ships slower and less maneuverable as their mass increases.

==Module Use==

Thrusters are very commonly used for decorative purposes, either in large groups or scattered around individually. Thruster Module do not gain any additional bonuses from being adjacent to another Thruster Module, and so may be placed freely without any constraints. Often times it's seen as a good idea to have small groups of thrusters separated around a ship, so that it's harder to target them down and shut down a ship's movement. While it may be difficult with the many other modules in place, it's certainly recommended for absolute safety.

Not only that, but considering the amount of thruster modules often needed, while uncommon, they can be used as a "system shield" to layer over other more important/more expensive systems so as to keep them safer, possibly increasing a ship's combat endurance. This ultimately depends on the ship and it's role, but for say a brawler where speed is not exactly important, it could be a good idea to use Thruster Modules to protect the more defensive/tanky modules.

Thrust carries between entities. You may have a separate entity made up entirely of Thruster Modules, and dock it to a much larger ship, giving the parent ship the thrust from the child ship (you however have to "inherit thrust from docks", this option is available under the thrust menu). Your total thrust will then be calculated as if all your Thruster Modules were placed on the main entity rather than divided between several docked entities.

Thruster Module

2016-07-09T06:47:33Z

Olxinos: /* Module Use */

This article details the existence and use of a Thruster Module

==The Essentials==

A Thruster Module (Formerly known as a Hypercoil Thruster) is required to give a ship propulsion, and subsequently, the ability to move. Thrust used to only impact a ship's acceleration, however as of [http://star-made.org/news/starmade-v0-19538-new-thruster-mechanics 0.19538] it also determines the max speed of a ship (ranging from half the server speed to three times the server speed, which can be further increased with the help of a defensive [[Overdrive Effect Computer|Overdrive effect]]). Even if a core on its own doesn't provide any thrust, a ship made of a single core and a couple blocks is faster than an astronaut (in vanilla and most server configurations) while reasonably maneuverable. However if a player wants anything to move at a decent speed then additional Thruster Modules will be required.

Starmade's thrust system has diminishing returns. In other words, the mother thrusters you have, the less each thruster block adds to your thrust. In practice, this makes ships slower and less maneuverable as their mass increases.

==Module Use==

Thrusters are very commonly used for decorative purposes, either in large groups or scattered around individually. Thruster Module do not gain any additional bonuses from being adjacent to another Thruster Module, and so may be placed freely without any constraints. Often times it's seen as a good idea to have small groups of thrusters separated around a ship, so that it's harder to target them down and shut down a ship's movement. While it may be difficult with the many other modules in place, it's certainly recommended for absolute safety.

Not only that, but considering the amount of thruster modules often needed, while uncommon, they can be used as a "system shield" to layer over other more important/more expensive systems so as to keep them safer, possibly increasing a ship's combat endurance. This ultimately depends on the ship and it's role, but for say a brawler where speed is not exactly important, it could be a good idea to use Thruster Modules to protect the more defensive/tanky modules.

Thrust carries between entities. You may have a separate entity made up entirely of Thruster Modules, and dock it to a much larger ship, giving the parent ship the thrust from the child ship (you however have to "inherit thrust from docks", this option is available under the thrust menu). Your total thrust will then be calculated as if all your thrusters were placed on the main entity rather than divided between several docked entities.

Thruster Module

2016-07-09T06:42:12Z

Olxinos: /* The Essentials */

Ship Design

2016-07-09T06:17:24Z

Olxinos: Replaced outdated descriptions of piercing and punch-through effects

This article describes basic and intermediate ship design.

==The Basics==

For a ship to be considered a ship, it must have the following components

* A [[Ship Core]]
* At least one [[Propulsion Systems|Propulsion System]] (usually a thruster)
* A power source (see [[Power Reactor Module]] and [[Power Systems]])

While a ship can technically consist of just a [[Ship Core]], this has mediocre thrust, no defense should it be attacked, and serves no functional purpose other than quick transport over small distances. The same can be said for a ship with just a [[Ship Core]], a single [[Power Reactor Module]] and a single [[Thruster Module]], which is more commonly made to serve the same purpose as just having the [[Ship Core]].

==Hull and Armour==

Hulls and Armour is the primary means of defending against incoming attacks, providing basic protection and will generally increase the survivability of a ship. There are four types of Hull/Armour:

*[[Basic Hull]] with 0.05 Mass, 5 System HP, 50 Armour HP, 75 Block HP and 0 Block Armour (Per block)
*[[Standard Armour]] with 0.15 Mass, 5 System HP, 75 Armour HP, 100 Block HP and 0.6 Block Armour (Per block)
*[[Advanced Armour]] with 0.25 Mass, 5 System HP, 100 Armour HP, 250 Block HP and 0.8 Block Armour (Per Block)
*[[Crystal Armour]] with the same stats as Advanced Armour, however is transparent (Somewhat Opaque)

The cost of the armour increases as the quality does, with [[Basic Hull]] requiring only [[Alloyed Metal Mesh]] and [[Crystal Composite]] to be made, with [[Standard Armour]] requiring the [[Basic Hull]] and a [[Standard hardener]], [[Advanced Armour]] requiring [[Standard Armour]] and an [[Advanced Hardener]] and [[Crystal Armour]] requiring [[Advanced Armour]] and a Crystal Block.

Most times it's best to vary between the different armour types, as each provides their own look and allows for making the outer hull of a ship look better. Often times [[Standard Armour]] is used for the primary armour shell that covers the majority of the ship, with [[Advanced Armour]] claiming the interior and the central systems and [[Basic Hull]] being used for details, while [[Crystal Armour]] is used for glass/windows. However, the player is encouraged to vary between them all for every part of the ship to attain the best decorative value, and sometimes using only one armour type can be useful.

Hull/Armour can also be coloured, though with rather tedious methods. In order to get coloured [[Basic Hull]], a player must run both [[Grey Hull]] and the [[Paint]] of their choice through a [[Basic Factory]], producing the [[Basic Hull]] of that colour. To attain coloured [[Standard Armour]], a player must run the coloured hull of their choice and a [[Standard Hardener]] through a [[Standard Factory]]. To produce coloured [[Advanced Armour]], a player must run the coloured [[Standard Armour]] of their choice and an [[Advanced Hardener]] through an [[Advanced Factory]]. To gain [[Crystal Armour]], a player must run the coloured [[Advanced Armour]] of their choice and the corresponding Crystal Block of that colour.

==Weaponry==

Weaponry is necessary for any ship to attack or defend in a battle. There are four primary [[Weapon Systems]]:

*[[Cannon Computer|Cannons]] - Standard projectile weaponry
*[[Missile Computer|Missiles]] - Missile weaponry that explodes on impact
*[[Damage Beam Computer|Damage Beams]] - Beam weaponry that does instantaneous damage at a limited range
*[[Damage Pulse Computer|Damage Pulse]] - A pulse that damages anything in a small area

Certain [[Weapon Systems]] can be slaved to others to have varying effects:

*[[Cannon Computer|Cannons]] increases weapon's fire rate
*[[Missile Computer|Missiles]] increases projectile count per shot (when slaved to [[Missile Computer|Missiles]], fire mode is set to heat-seeking)
*[[Damage Beam Computer|Damage Beams]] increases weapon's range (when slaved to [[Missile Computer|Missiles]], fire mode is set to lock-on)
*[[Damage Pulse Computer|Damage Pulse]] increases weapon's raw damage output per shot

Each of these acting as slaves allows for a more diverse rang of weaponry, giving players more freedom over the construction of their ships. A couple of rather popular combinations would consist of [[Cannon Computer|Cannon]]/[[Cannon Computer|Cannon]] (Machine Gun), [[Missile Computer|Missiles]]/[[Damage Beam Computer|Damage Beam]] (Standard use Missile/Lock on Missile) and [[Damage Beam Computer|Damage Beam]]/[[Damage Pulse Computer|Damage Pulse]] (Anti-shield beam.)

Along with the ability to slave [[Weapon Systems|Weapons]] to one another to create new types of [[Weapon Systems|Weapons]], there are also [[Effects]] which further increase the customization possible for a ship's weaponry. There are nine [[Effects]] in total:

*[[EMP Effect Computer|EMP]] - Puts damage into targets power system rather than hull, damaging the amount of power in its capacitors, while dealing less hull damage
*[[Ion Effect Computer|Ion]] - Puts damage into shield damage, causing more damage to shields but less to hull
*[[Explosive Effect Computer|Explosive]] - Adds additional AOE damage, while reducing the primary impact damage
*[[Punch-Through Effect Computer|Punch-Through]] - Increases block and armor damage
*[[Piercing Effect Computer|Pierce]] - Increases block damage and decreases opponents' armor efficiency, but decreases shield damage
*[[Push Effect Computer|Push]] - Converts damage to momentum which pushes the target, but reduces the raw damage output
*[[Pull Effect Computer|Pull]] - Converts damage to momentum which pulls the target towards the one firing, but reduces the raw damage output
*[[Stop Effect Computer|Stop]] - Converts damage to momentum which stops/slows the target, but reduces the raw damage output
*[[Overdrive Effect Computer|Overdrive]] - Increases damage but greatly increases power consumption

Using these [[Effects]] a player can create highly specialized weapons. For example, a common anti-shield weapon would consist of [[Damage Beam Computer|Damage Beam]]/[[Damage Pulse Computer|Damage Pulse]]/[[Ion Effect Computer|Ion]], and a common anti-hull cannon would consist of [[Cannon Computer|Cannon]]/[[Cannon Computer|Cannon]]/[[Explosive Effect Computer|Explosive]].

For a detailed infographic on the various [[Weapon Systems]] and [[Effects]], please see here: [https://starmadedock.net/threads/a-simple-graph-for-weapon-linking.3751/ Starmade Dock: A Small Graph for Weapon Linking]

Note: Piercing and Punch-Through effects once granted damage propagation, however as of [http://star-made.org/news/starmade-v0-19282-putting-more-fun-into-battles-also-boarding 0.19282] their effects have changed to match the new armor mechanics and the natural damage propagation of cannons and beams

==Utility==

* [[Docking]]
* [[Turrets]]
* [[Plex Door|Doors]]
* [[Lights]]

==Other considerations==
* Multiple people on a single ship
* Damage and repair

==Instructional Videos==
The following YouTubers are known to make high quality builds and instructional videos for building ships.

* [https://www.youtube.com/user/00Raiben]

[[Category:Ship]]