LuaItemStack Rotation access

[Bigfootmech]

So, I'm currently working on a blueprint editor.

viewtopic.php?f=97&t=53634

And I've hit a bit of a brick wall with this one. To the point where I've searched through the forums, checked the documentation, checked the hidden docs, and all I could, but didn't find anything.

Maybe I'm missing something really easy.

Basically: When you pick up a blueprint in your hand, it will have an orientation.

If you put it back in your hotbar/inventory, and take it out again, it will keep the same orientation as you left it in

This orientation doesn't affect the entities, or tiles contained in the blueprint

You can check this, by ripping all the info from a blueprint, and creating a new one from a new blueprint (like my mod does on "changing anchor point" using the numpad. All of the entities will be there, but the blueprint will pop back to its original orientation (and out of any toolbar slots).

I could potentially use the event on_player_cursor_stack_changed , and do a keybind for R and SHIFT-R to track the orientation... until the player lets go of the blueprint, at which point I lose track of it.

I could then try to implement a deep table equals, and trawl the player's whole inventory,toolbar, and hand to try to guess which blueprint is being pulled, store all the "rotation states" myself that the game saves...

but that seems A: Overkill. B: Doubling already awkward stateful functionality. C: Too much work for too little output

Does anyone know anywhere where this "rotated direction of blueprint/stack" is exposed? (yes, I have checked LuaEntity, but this is a LuaItemStack issue)

Or would I need to request that the devs expose this as part of the modding API?

[Rseding91]

The rotation for a blueprint isn't saved as part of the game state data. If you rotate one then save, exit, and load the game it won't be rotated anymore. As such, it's not available for mods to read because it isn't deterministic.

The only time the game uses it is during rendering (not part of the game state) and during creation of input actions (not part of the game state).

[Rseding91]

I'm not sure what code your'e running but you only need to edit the blueprint in the players hand directly and it will retain any custom rotation value it had. Don't clear() it and then insert() a new one - just edit the blueprint entities directly.

[Bigfootmech]

I'm not sure what code your'e running but you only need to edit the blueprint in the players hand directly and it will retain any custom rotation value it had. Don't clear() it and then insert() a new one - just edit the blueprint entities directly.

I realize that.

Except, I want to use the numberpad to move all entities, so that the "origin" of the blueprint (on the mouse) moves to a point on the blueprint

viewtopic.php?f=6&t=49445

Code: Select all

7--8--9
|\ | /|
| \|/ |
4--5--6
| /|\ |
|/ | \|
1--2--3

ie: you hit numpad 7, and the blueprint shifts, so that you're placing it from the top left corner.

The only issue is, that if the player rotates it, I have the option to:

A: Delete the blueprint, and recreate it, resetting the rotation value, and also removing it from toolbar (seems jarring for the player)

or

B: Replace all the entities, but then the keypad numbers are misaligned to the corner/point on the blueprint since it's been rotated. (case which I spoke about, where changing what keypad -> corner means by tracking rotation of the blueprint)

OR

C: Try to force the game to NOT rotate the blueprint somehow, and rotate the full contents, and anchor correctly

I guess what my mod is doing is mixing the concepts, and making deterministic what is usually only a rendering aspect. So by your model, I should do option C, stop the game rotating blueprints, and rotate them myself, if possible.

If you wanna check out quickly how it's working currently
https://mods.factorio.com/mods/Bigfootmech/BPEdit
It's doing option A, and people are reporting it as a bug (because it is a weird player experience)