[1.1.74] LuaPlayer.pipette_entity doesn't copy entity direction

[Atria]

Factorio API states that LuaPlayer.pipette_entity works the same as if smart pipette (Q) was invoked by player: https://lua-api.factorio.com/1.1.74/Lua ... tte_entity

However the entity direction is not copied correctly even if I'm passing LuaEntity to the LuaPlayer.pipette_entity.

After some testing I found that smart pipetteting some entity stores direction of that entity somewhere in game state. After that all entities put somehow into cursor (either by calling LuaPlayer.pipette_entity, setting LuaPlayer.cursor_ghost or calling LuaPlayer.cursor_stack.set_stack) will use that same direction.

...Until smart pipette is invoked again when the new direction is stored.

However fixing this by copying direction from LuaEntity passed to LuaPlayer.pipette_entity will still leave problem with inability to set direction of entity in cursor (LuaPlayer.cursor_stack or LuaPlayer.cursor_ghost). I've found modding interface requests which asks precisely for this: viewtopic.php?f=28&t=102682&p=569639&hi ... ty#p569639

[Rseding91]

The build direction isn't part of the game state (in the sense that it is never stored in the save file and gets reset when you save- >quit->load).

I could make writing pipette_entity update the non-game-state value but that doesn't really do anything from a scripting side of things. Since scripts can never access that value all it would ever effect is the render state of what's in the cursor and subsequent player-based actions related to the cursor.

I looked at the linked modding interface request and this bug report and i'm trying to figure out:

What is the end goal? If I change some code; what am I trying to make work that doesn't work currently?

[Atria]

At first I was trying to implement something that was part of base game for a couple of years and I never found it in Interface setting. (Ghost being put into cursor if item was not found in player's inventory)

After being told it that this feature already exists I'd say this report is reduced to just "misleading documentation", since LuaPlayer.pipette_entity doesn't really do what ingame pipette does.

Just out of curiosity...why scripts can't access this "game state" value? If the LuaPlayer.pipette_entity can be modified to modify this value, why not some other API call (getter/setter LuaPlayer.build_direction or something like that)? Would this require too large code changes for this "nice to have"?

[Rseding91]

Just out of curiosity...why scripts can't access this "game state" value? If the LuaPlayer.pipette_entity can be modified to modify this value, why not some other API call (getter/setter LuaPlayer.build_direction or something like that)? Would this require too large code changes for this "nice to have"?

I think first you don't understand what "game state" means in the Factorio context. A "game state" value is one that if you save the game, exit, and then load the game will be saved and loaded with the save file. With that definition: build direction is not game state. It is not stored in the save file.

If you are in multiplayer and ask the game "what is the build direction of player B" it has no idea; the server doesn't know, your game doesn't know - only the local instance of the game for player B knows. When player B clicks to build something it send a "build action" to the server and the server then re-distributes that build action to all connected players and the action is performed.

[Atria]

Ok, I think I understand now.

So it is not even possible to set the build direction unless new packet type is created to send this information to the target client.

And about LuaPlayer.pipette_entity: I don't know how overloads of this function work but I guess when I pass LuaEntity it just gets its name and then it works the same...sending only entity name to the target client? So again some network code would have to be modified to either pass which entity in the world should be pipetted or pass build direction along with entity name.

Bottom line for me is that I don't need this fixed anymore. I'd just ask that documentation is updated to give disclaimer about this.