Official Factorio Wiki - User contributions [en]

Talk:Blueprint string format

2024-11-22T05:56:12Z

GlassBricks: /* Probably complete BlueprintEntity type for v2.0 */

== Decode snippets ==

Since there are some short snippets to decode blueprint strings to JSON / Lua tables I think it would make sense to also have snippets for the inverse operation. -- [[User:Fgardt|fgardt]] ([[User talk:Fgardt|talk]]) 03:35, 3 August 2024 (CEST)

== v2.x introduced new "wires" array of uncertain structure ==

My [https://github.com/nyurik/fatul FaTul tool] minimizes versioned blueprint storage in git by making all IDs relative - e.g. connected to (-1,0) instead of a long entity number. Wires used to work in 1.x, but now I am observing a new "wires" blueprint root entry - this is an example of two electric poles connected by copper, red, and green wires. The format of the "wires" seem to be a list of connections, with each sub-array always having 4 numbers:

* source entity_number
* color of the wire at the source
* destination entity_number
* color of the wire at the destination

I guess the developers were trying to allow color-changing in the wire, e.g. starts as green, but ends as red? For now, I only saw same color on both sides (2nd and 4th value is always the same). The color indexes are: 5 - copper, 1 - red, 2 - green.

{
"blueprint": {
"icons": [{"signal": {"name": "big-electric-pole"}, "index": 1}],
"entities": [
{"entity_number": 1, "name": "big-electric-pole", "position": {"x": 163, "y": -240}},
{"entity_number": 2, "name": "big-electric-pole", "position": {"x": 195, "y": -240}}
],
"wires": [[1, 1, 2, 1], [1, 2, 2, 2], [1, 5, 2, 5]],
"item": "blueprint",
"version": 562949954076673
}
}

=== Response ===

I have done some research on this. The wire "color" is actually a merge of wire color and the old `circuit_connector_id`, which was removed. The format seem to be:

* source entity_number
* color of the wire at the source, +2 if it is connected to the "output" of the object for green or red, or +1 for copper
* destination entity_number
* color of the wire at the destination, +2 if it is connected to the "output" of the object for green or red, or +1 for copper

e.g. an arithmetic combinator which has its output connected to the input of another combinator (or any 1 sided object) with green wire would be:

[1,4,2,2]

While if it were connected to the output, it would be:

[1,4,2,4]

Or, for 2 power poles connected with a switch:

[[1, 5, 2, 5], [2, 6, 3, 5]]

It also seems to normalize and sort the connections by lowest entity number. You'll note that rather than the old method of setting connections on both objects, there is on one "wire" entry per connection, and it seems to always pick the lower entity number to be at the start of the "wire" entry.

=== Edit ===
After more research, it's based on `wire_connector_id`, which was added to the defines:

wire_connector_id = {
circuit_green = 2,
circuit_red = 1,
combinator_input_green = 2,
combinator_input_red = 1,
combinator_output_green = 4,
combinator_output_red = 3,
pole_copper = 5,
power_switch_left_copper = 5,
power_switch_right_copper = 6
},

-- [[User:HuFlungDu|HuFlungDu]] ([[User talk:HuFlungDu|talk]])

== v2.X SignalID has optional "type" now ==

Blueprint:

<code>0eNqVkd1uhCAQhd9lrnGzWm2ir9JsDOLEnRQGC2hrDO9e0Dbbqza9Y5hzvvnbYdALzo44QLcDKcseupcdPE0sdf5jaRA6kN6jGTTxVBip7sRYVBAFEI/4AV0ZbwKQAwXCk3AEW8+LGdAlgfiVJGC2Ppkt55oZeL00Ajboni5NKuNQ0Zzd5CwXE0pXvN8RNXyn+rdF6lQwSdg6I3OGApqzGRp/jDI7Oy4q0JrkhUlvjcckpzqJuSdeU//Wbaf7EdUCfJDq9Zg4RvE3+mtN/4NfM/yWd5qNCfw4k4AVnT8W1TxXbd22TV3WVVWWMX4CClCeDw==
</code>

Beginning of JSON:

{
"blueprint": {
"icons": [
{
"signal": {
"name": "assembling-machine-2"
},
"index": 1
}
],

Notice there is no <code>"type": "item"</code> property.

== v2.x introduced new "stock_connections" array for trains(?) ==

Similar to above, for my [https://github.com/nyurik/fatul FaTul] blueprint GIT management tool, I am seeing a new <code>stock_connections</code> top level property for connections entities like trains. If my entities represent a train with 4 cargo wagons (entities 1-4) and two locomotives (entities 5 and 6), this represents their connectivity LCCCCL:

"stock_connections": [
{"back": 1, "stock": 5},
{"back": 2, "front": 5, "stock": 1},
{"back": 3, "front": 1, "stock": 2},
{"back": 4, "front": 2, "stock": 3},
{"back": 6, "front": 3, "stock": 4},
{"front": 4, "stock": 6}
]

== Probably complete BlueprintEntity type for v2.0 ==

BlueprintEntity format is actually https://lua-api.factorio.com/latest/concepts/BlueprintEntity.html

Notably, this contains the "wires" field, which is already documented, and some others, so no need to reverse engineer that.

However, there's still a ton attributes not documented, but I've slowly dug them out:
The results can be found here:
https://github.com/GlassBricks/typed-factorio/blob/3632b3d5eca9a9f5f3b85345ddf33d23f995dbdd/runtime/generated/concepts.d.ts#L2824
Or the manually defined input here, which might be more clear:
https://github.com/GlassBricks/typed-factorio/blob/3632b3d5eca9a9f5f3b85345ddf33d23f995dbdd/generator/input/manual-defs-runtime.ts#L568
Even if you don't know typescript its probably readable.

Non-documented types are BlueprintRequestFilters, BlueprintEquipment, BlueprintEntity (in ''addition'' to the ones already documented), BlueprintControlBehavior, BlueprintInventory, InfinityContainerFilter.
All other types you should be able to find (also) on lua-api.factorio.com.

You can show the entities of a blueprint in-game, in your cursor, with /c game.print(serpent.block(game.player.cursor_stack.get_blueprint_entities())) .
You can also use log() instead of game.print() to put it to Factorio logs

There might still be new stuff in the Blueprint json itself (not just entities).

Talk:Blueprint string format

2024-11-22T05:55:32Z

GlassBricks: /* Near complete reverse engineering work for BlueprintEntity type */

== Decode snippets ==

Since there are some short snippets to decode blueprint strings to JSON / Lua tables I think it would make sense to also have snippets for the inverse operation. -- [[User:Fgardt|fgardt]] ([[User talk:Fgardt|talk]]) 03:35, 3 August 2024 (CEST)

== v2.x introduced new "wires" array of uncertain structure ==

My [https://github.com/nyurik/fatul FaTul tool] minimizes versioned blueprint storage in git by making all IDs relative - e.g. connected to (-1,0) instead of a long entity number. Wires used to work in 1.x, but now I am observing a new "wires" blueprint root entry - this is an example of two electric poles connected by copper, red, and green wires. The format of the "wires" seem to be a list of connections, with each sub-array always having 4 numbers:

* source entity_number
* color of the wire at the source
* destination entity_number
* color of the wire at the destination

I guess the developers were trying to allow color-changing in the wire, e.g. starts as green, but ends as red? For now, I only saw same color on both sides (2nd and 4th value is always the same). The color indexes are: 5 - copper, 1 - red, 2 - green.

{
"blueprint": {
"icons": [{"signal": {"name": "big-electric-pole"}, "index": 1}],
"entities": [
{"entity_number": 1, "name": "big-electric-pole", "position": {"x": 163, "y": -240}},
{"entity_number": 2, "name": "big-electric-pole", "position": {"x": 195, "y": -240}}
],
"wires": [[1, 1, 2, 1], [1, 2, 2, 2], [1, 5, 2, 5]],
"item": "blueprint",
"version": 562949954076673
}
}

=== Response ===

I have done some research on this. The wire "color" is actually a merge of wire color and the old `circuit_connector_id`, which was removed. The format seem to be:

* source entity_number
* color of the wire at the source, +2 if it is connected to the "output" of the object for green or red, or +1 for copper
* destination entity_number
* color of the wire at the destination, +2 if it is connected to the "output" of the object for green or red, or +1 for copper

e.g. an arithmetic combinator which has its output connected to the input of another combinator (or any 1 sided object) with green wire would be:

[1,4,2,2]

While if it were connected to the output, it would be:

[1,4,2,4]

Or, for 2 power poles connected with a switch:

[[1, 5, 2, 5], [2, 6, 3, 5]]

It also seems to normalize and sort the connections by lowest entity number. You'll note that rather than the old method of setting connections on both objects, there is on one "wire" entry per connection, and it seems to always pick the lower entity number to be at the start of the "wire" entry.

=== Edit ===
After more research, it's based on `wire_connector_id`, which was added to the defines:

wire_connector_id = {
circuit_green = 2,
circuit_red = 1,
combinator_input_green = 2,
combinator_input_red = 1,
combinator_output_green = 4,
combinator_output_red = 3,
pole_copper = 5,
power_switch_left_copper = 5,
power_switch_right_copper = 6
},

-- [[User:HuFlungDu|HuFlungDu]] ([[User talk:HuFlungDu|talk]])

== v2.X SignalID has optional "type" now ==

Blueprint:

<code>0eNqVkd1uhCAQhd9lrnGzWm2ir9JsDOLEnRQGC2hrDO9e0Dbbqza9Y5hzvvnbYdALzo44QLcDKcseupcdPE0sdf5jaRA6kN6jGTTxVBip7sRYVBAFEI/4AV0ZbwKQAwXCk3AEW8+LGdAlgfiVJGC2Ppkt55oZeL00Ajboni5NKuNQ0Zzd5CwXE0pXvN8RNXyn+rdF6lQwSdg6I3OGApqzGRp/jDI7Oy4q0JrkhUlvjcckpzqJuSdeU//Wbaf7EdUCfJDq9Zg4RvE3+mtN/4NfM/yWd5qNCfw4k4AVnT8W1TxXbd22TV3WVVWWMX4CClCeDw==
</code>

Beginning of JSON:

{
"blueprint": {
"icons": [
{
"signal": {
"name": "assembling-machine-2"
},
"index": 1
}
],

Notice there is no <code>"type": "item"</code> property.

== v2.x introduced new "stock_connections" array for trains(?) ==

Similar to above, for my [https://github.com/nyurik/fatul FaTul] blueprint GIT management tool, I am seeing a new <code>stock_connections</code> top level property for connections entities like trains. If my entities represent a train with 4 cargo wagons (entities 1-4) and two locomotives (entities 5 and 6), this represents their connectivity LCCCCL:

"stock_connections": [
{"back": 1, "stock": 5},
{"back": 2, "front": 5, "stock": 1},
{"back": 3, "front": 1, "stock": 2},
{"back": 4, "front": 2, "stock": 3},
{"back": 6, "front": 3, "stock": 4},
{"front": 4, "stock": 6}
]

== Probably complete BlueprintEntity type for v2.0 ==

BlueprintEntity format is actually https://lua-api.factorio.com/latest/concepts/BlueprintEntity.html

Notably, this contains the "wires" field, which is already documented, and some others, so no need to reverse engineer that.

However, there's still a ton attributes not documented, but I've slowly dug them out:
The results can be found here:
https://github.com/GlassBricks/typed-factorio/blob/3632b3d5eca9a9f5f3b85345ddf33d23f995dbdd/runtime/generated/concepts.d.ts#L2824
Or the manually defined input here, which might be more clear:
https://github.com/GlassBricks/typed-factorio/blob/3632b3d5eca9a9f5f3b85345ddf33d23f995dbdd/generator/input/manual-defs-runtime.ts#L568
Even if you don't know typescript its probably readable.

Non-documented types are BlueprintRequestFilters, BlueprintEquipment, BlueprintEntity (in ''addition'' to the ones already documented), BlueprintControlBehavior, BlueprintInventory, InfinityContainerFilter.
All other types you should be able to find (also) on lua-api.factorio.com.

You can show the entities of a blueprint in-game, in your cursor, with /c game.print(serpent.block(game.player.cursor_stack.get_blueprint_entities())) .
You can also use log() instead of game.print() to put it to Factorio logs

There might still be new types for the Blueprint json itself (not just entities).

Talk:Blueprint string format

2024-11-22T05:54:06Z

GlassBricks: /* Near complete reverse engineering work for BlueprintEntity type */ new section

== Decode snippets ==

Since there are some short snippets to decode blueprint strings to JSON / Lua tables I think it would make sense to also have snippets for the inverse operation. -- [[User:Fgardt|fgardt]] ([[User talk:Fgardt|talk]]) 03:35, 3 August 2024 (CEST)

== v2.x introduced new "wires" array of uncertain structure ==

My [https://github.com/nyurik/fatul FaTul tool] minimizes versioned blueprint storage in git by making all IDs relative - e.g. connected to (-1,0) instead of a long entity number. Wires used to work in 1.x, but now I am observing a new "wires" blueprint root entry - this is an example of two electric poles connected by copper, red, and green wires. The format of the "wires" seem to be a list of connections, with each sub-array always having 4 numbers:

* source entity_number
* color of the wire at the source
* destination entity_number
* color of the wire at the destination

I guess the developers were trying to allow color-changing in the wire, e.g. starts as green, but ends as red? For now, I only saw same color on both sides (2nd and 4th value is always the same). The color indexes are: 5 - copper, 1 - red, 2 - green.

{
"blueprint": {
"icons": [{"signal": {"name": "big-electric-pole"}, "index": 1}],
"entities": [
{"entity_number": 1, "name": "big-electric-pole", "position": {"x": 163, "y": -240}},
{"entity_number": 2, "name": "big-electric-pole", "position": {"x": 195, "y": -240}}
],
"wires": [[1, 1, 2, 1], [1, 2, 2, 2], [1, 5, 2, 5]],
"item": "blueprint",
"version": 562949954076673
}
}

=== Response ===

I have done some research on this. The wire "color" is actually a merge of wire color and the old `circuit_connector_id`, which was removed. The format seem to be:

* source entity_number
* color of the wire at the source, +2 if it is connected to the "output" of the object for green or red, or +1 for copper
* destination entity_number
* color of the wire at the destination, +2 if it is connected to the "output" of the object for green or red, or +1 for copper

e.g. an arithmetic combinator which has its output connected to the input of another combinator (or any 1 sided object) with green wire would be:

[1,4,2,2]

While if it were connected to the output, it would be:

[1,4,2,4]

Or, for 2 power poles connected with a switch:

[[1, 5, 2, 5], [2, 6, 3, 5]]

It also seems to normalize and sort the connections by lowest entity number. You'll note that rather than the old method of setting connections on both objects, there is on one "wire" entry per connection, and it seems to always pick the lower entity number to be at the start of the "wire" entry.

=== Edit ===
After more research, it's based on `wire_connector_id`, which was added to the defines:

wire_connector_id = {
circuit_green = 2,
circuit_red = 1,
combinator_input_green = 2,
combinator_input_red = 1,
combinator_output_green = 4,
combinator_output_red = 3,
pole_copper = 5,
power_switch_left_copper = 5,
power_switch_right_copper = 6
},

-- [[User:HuFlungDu|HuFlungDu]] ([[User talk:HuFlungDu|talk]])

== v2.X SignalID has optional "type" now ==

Blueprint:

<code>0eNqVkd1uhCAQhd9lrnGzWm2ir9JsDOLEnRQGC2hrDO9e0Dbbqza9Y5hzvvnbYdALzo44QLcDKcseupcdPE0sdf5jaRA6kN6jGTTxVBip7sRYVBAFEI/4AV0ZbwKQAwXCk3AEW8+LGdAlgfiVJGC2Ppkt55oZeL00Ajboni5NKuNQ0Zzd5CwXE0pXvN8RNXyn+rdF6lQwSdg6I3OGApqzGRp/jDI7Oy4q0JrkhUlvjcckpzqJuSdeU//Wbaf7EdUCfJDq9Zg4RvE3+mtN/4NfM/yWd5qNCfw4k4AVnT8W1TxXbd22TV3WVVWWMX4CClCeDw==
</code>

Beginning of JSON:

{
"blueprint": {
"icons": [
{
"signal": {
"name": "assembling-machine-2"
},
"index": 1
}
],

Notice there is no <code>"type": "item"</code> property.

== v2.x introduced new "stock_connections" array for trains(?) ==

Similar to above, for my [https://github.com/nyurik/fatul FaTul] blueprint GIT management tool, I am seeing a new <code>stock_connections</code> top level property for connections entities like trains. If my entities represent a train with 4 cargo wagons (entities 1-4) and two locomotives (entities 5 and 6), this represents their connectivity LCCCCL:

"stock_connections": [
{"back": 1, "stock": 5},
{"back": 2, "front": 5, "stock": 1},
{"back": 3, "front": 1, "stock": 2},
{"back": 4, "front": 2, "stock": 3},
{"back": 6, "front": 3, "stock": 4},
{"front": 4, "stock": 6}
]

== Near complete reverse engineering work for BlueprintEntity type ==

BlueprintEntity format is actually https://lua-api.factorio.com/latest/concepts/BlueprintEntity.html

Notably, this contains the "wires" field, which is already documented, and some others, so no need to reverse engineer that.

However, there's still a ton attributes not documented, but I've slowly dug them out:
The results can be found here:
https://github.com/GlassBricks/typed-factorio/blob/3632b3d5eca9a9f5f3b85345ddf33d23f995dbdd/runtime/generated/concepts.d.ts#L2824
Or the manually defined input here, which might be more clear:
https://github.com/GlassBricks/typed-factorio/blob/3632b3d5eca9a9f5f3b85345ddf33d23f995dbdd/generator/input/manual-defs-runtime.ts#L568
Even if you don't know typescript its probably readable.

Non-documented types are BlueprintRequestFilters, BlueprintEquipment, BlueprintEntity (in ''addition'' to the ones already documented), BlueprintControlBehavior, BlueprintInventory, InfinityContainerFilter.
All other types you should be able to find (also) on lua-api.factorio.com.

You can show the entities of a blueprint in-game, in your cursor, with /c game.print(serpent.block(game.player.cursor_stack.get_blueprint_entities())) .
You can also use log() instead of game.print() to put it to Factorio logs

There might still be new types for the Blueprint json itself (not just entities).