Difference between revisions of "StructureLink"
m |
(categorized) |
||
| (8 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
[[Category:In-Game Objects]] |
[[Category:In-Game Objects]] |
||
| + | [[File:Empty_StructureLink.png|frame|An empty link]] |
||
[https://docs.screeps.com/api/#StructureLink API Reference] |
[https://docs.screeps.com/api/#StructureLink API Reference] |
||
| − | StructureLinks ('links') are [[ |
+ | StructureLinks ('links') are [[structure]]s that allow the transfer of [[energy]] from one link to another in the same [[room]] instantaneously while incurring a cost of <code>total * 0.03</code> energy per transmission. Links can hold up to 800 energy at a time and do not allow other resources. Once an energy transfer is initiated, the sending link has a cooldown equal to the linear distance between the sending and receiving links. StructureLink inherits the methods and values of [[RoomObject]], [[Structure]], and [[OwnedStructure]]. |
== Common Usage of Links == |
== Common Usage of Links == |
||
| − | There are multiple uses of links, all of which either directly or indirectly reduce the need for creep travel/pathfinding, thereby reducing overall CPU. |
+ | There are multiple uses of links, all of which either directly or indirectly reduce the need for [[creep]] travel/[[Pathfinding|pathfinding]], thereby reducing overall [[CPU]] costs. |
=== Storage Link === |
=== Storage Link === |
||
| − | A link near a storage is referred to as a storage link. This is typically a link that receives energy from other links, which are then transferred into the |
+ | A link near a [[StructureStorage|storage]] is referred to as a storage link. This is typically a link that receives energy from other links, which are then transferred into the storage in the room. |
=== Source Link === |
=== Source Link === |
||
| Line 18: | Line 19: | ||
=== Controller Link === |
=== Controller Link === |
||
| − | Controller links are in range of a |
+ | Controller links are in range of a [[StructureController]], allowing for static upgraders, who move in range of the room's controller and stay in a single position for the remainder of their ticksToLive, upgrading and withdrawing from a link or container. |
=== Remote Link === |
=== Remote Link === |
||
| Line 26: | Line 27: | ||
=== Extension Link === |
=== Extension Link === |
||
| − | If it is infeasible to place your extension farm close to your [[ |
+ | If it is infeasible to place your extension farm close to your [[StructureStorage|storage]], the creeps that fill your extensions could withdraw from an Extension Link located closer to your extensions. |
=== Tower Link === |
=== Tower Link === |
||
| Line 42: | Line 43: | ||
=== Static Type to Type Transfers === |
=== Static Type to Type Transfers === |
||
| − | This method involves identifying each applicable type of links, and attempt sends from a single type to another single type. Multiple type-to-type send attempts are typically performed, such as storageLink |
+ | This method involves identifying each applicable type of links, and attempt sends from a single type to another single type. Multiple type-to-type send attempts are typically performed, such as storageLink → controllerLink, remoteLink → storageLink, sourceLink → storageLink. This implementation is typically used if you have a very small number of destination links. |
=== Link Balancing === |
=== Link Balancing === |
||
This method attempts to ensure that each link is filled to exactly an identified amount as often as possible. If one link is above the target amount and another is under, a send is executed to balance out the link infrastructure. This is most often used when most of the links in a room are multi-use, which require both sends and receives. |
This method attempts to ensure that each link is filled to exactly an identified amount as often as possible. If one link is above the target amount and another is under, a send is executed to balance out the link infrastructure. This is most often used when most of the links in a room are multi-use, which require both sends and receives. |
||
| + | [[Category:Game Knowledge]] |
||
Latest revision as of 12:42, 28 October 2020
StructureLinks ('links') are structures that allow the transfer of energy from one link to another in the same room instantaneously while incurring a cost of total * 0.03 energy per transmission. Links can hold up to 800 energy at a time and do not allow other resources. Once an energy transfer is initiated, the sending link has a cooldown equal to the linear distance between the sending and receiving links. StructureLink inherits the methods and values of RoomObject, Structure, and OwnedStructure.
Common Usage of Links[edit | edit source]
There are multiple uses of links, all of which either directly or indirectly reduce the need for creep travel/pathfinding, thereby reducing overall CPU costs.
Storage Link[edit | edit source]
A link near a storage is referred to as a storage link. This is typically a link that receives energy from other links, which are then transferred into the storage in the room.
Source Link[edit | edit source]
A link near a source of energy is referred to as a source link. These are typically used as senders in conjunction with a storage link to perform link mining.
Controller Link[edit | edit source]
Controller links are in range of a StructureController, allowing for static upgraders, who move in range of the room's controller and stay in a single position for the remainder of their ticksToLive, upgrading and withdrawing from a link or container.
Remote Link[edit | edit source]
Remote links are placed close to the exit of a room to save distance that creeps bringing in energy from remote rooms have to travel into the room.
Extension Link[edit | edit source]
If it is infeasible to place your extension farm close to your storage, the creeps that fill your extensions could withdraw from an Extension Link located closer to your extensions.
Tower Link[edit | edit source]
A tower link is used to provide energy to tower filler creeps, and allow for towers closer to likely avenues of approach, instead of keeping them close to your storage.
Common Implementations[edit | edit source]
All of the below implementations typically involve the use of thresholds to identify when a link is eligible to send or receive. These thresholds are used to prevent a link from either running completely empty, or becoming full for too long.
Link Priorities[edit | edit source]
This method of implementing links involves assigning priorities to each link in the room. When a lower priority link becomes full or reaches a threshold, it will attempt to send to the highest priority link that is below a specific threshold. If the highest priority link is not below its receive threshold, the sending link attempts to send to the second highest priority link. The process is continued until the energy is sent, or it cannot find a link with a higher priority than itself. This can be used if multiple destination links are in place.
Static Type to Type Transfers[edit | edit source]
This method involves identifying each applicable type of links, and attempt sends from a single type to another single type. Multiple type-to-type send attempts are typically performed, such as storageLink → controllerLink, remoteLink → storageLink, sourceLink → storageLink. This implementation is typically used if you have a very small number of destination links.
Link Balancing[edit | edit source]
This method attempts to ensure that each link is filled to exactly an identified amount as often as possible. If one link is above the target amount and another is under, a send is executed to balance out the link infrastructure. This is most often used when most of the links in a room are multi-use, which require both sends and receives.