Factorio Forums

If you call getblueprintentities() on a blueprint itemstack with an assembler in it that has no recipe you get back a table with an invalid recipe object instead of no recipe value. Also if you try and call setblueprintentities() with the same table you will get an error.

If you setup a rail signal on a curved+straight section of track you will get a valid blueprint that can't be imported with the new lua itemstack API. The error you get it "Entity i collides with entity j," error. Example:

I believe it's not just the end of curved sections, it will fail on all signals placed next to diagonal rails.

Using the new itemstack API in 0.11.1 exporting and then importing a connected belt-to-ground will lose the hood faces. The rotation is stored (which way the belts flow) but the way the hood faces is not retrained (not sure of the property name).
This image shows what i mean. Left is what i copied for the blueprint. Right is after i export and import the itemstack grid.

Ah yes, you can't tell which of them is IN and which one is OUT.
Did you test, that that property is actually stored and not actually just re-computed while placing the blueprint?

I think it could be tested by a setup like this
===>--->===>---->===>
= overground belt
> entrance/exit
- underground belt
(The last entrance is unpaired)

blueprint-capture the area from 2nd to 4th entrance/exit
place it
if the entraces turn into exits and vice versa, then the property isn't stored properly

It must be stored as you can see it in the ghosts and blueprints work in game with underground belts. It is not accessible to mods and lua though.

MF- wrote:if the entraces turn into exits and vice versa, then the property isn't stored properly

That's actually a different issue, where entrance and exit are properly connected but their direction is reversed. I suspect this is simply because the side that gets placed first becomes the entrance.

This is not the case. If you place the underground belts as ghosts, it depends totally from random in which direction they are placed. I think id depends on which side is built first, which depends on, which robot serves first.

Which is of course stupid... but I don't know, how this could be solved. You need some indicator of the direction, otherwise you cannot build stuff like this: https://forums.factorio.com/wiki/inde ... anes_trick

ssilk wrote:This is not the case. If you place the underground belts as ghosts, it depends totally from random in which direction they are placed. I think id depends on which side is built first, which depends on, which robot serves first.

Isn't that exactly what I said?

When I manually build an entrance or exit on top of the wrong-facing ones from a blueprint, the ghost remains in place. Not sure if this problem is related to the above issue, related to the similar problem with turret ghosts (fixed for next version) or something entirely new. For now I'll just post it here.

getblueprintentities() does not export the inventory limit for chests.

Normal blueprints do copy the inventory limit, but it is not accessible through getblueprintentities().

This is the mirror bug that when copying the settings of a chest, the stack limits aren't copied, too. (not sure, if this is in 0.11 still so, but in 0.10 it was).

I will merge all the blueprint api problems into one thread, they will be fixed alltogether.

The inserter gui allows you to enter count=0, but setblueprintentities() does not.

Steps to reproduce:
1. Put a blueprint in the first slot of your toolbar.
2. Run this command: The result is

Cannot execute command. Error: [string "..."]:1:Item stack count has to a be in the range of 1 - 2147483647

setblueprintentities() messes up all diagonal straight rails.

If you input direction=1, the blueprint has direction=7.
If you input direction=3, the blueprint has direction=5.
If you input direction=5, the blueprint has direction=7.
If you input direction=7, the blueprint has direction=5.

Hello, the blueprint api had been heavily refactored, and most of the problems hould be fixed in 0.11.9 (Thanks to RSeding91).

For different problems that you might find in the future 0.11.9, please create a separate thread.