Page 1 of 1

[Lou][2.0.55] Modding - Non-Square Machines, Fluidbox, Rotation event

Posted: Fri Jun 06, 2025 12:12 am
by Honktown
What you expect:
The machine - non-square (rectangular) crafting machine with fluid_boxes and fluid_boxes_off_when_no_fluid_recipe = true
The machine can be placed, and if you try to rotate it, it doesn't rotate (conventional behavior for assemblers), and does not raise on_player_rotated_entity , or, it does rotate, and changes direction in the event and LuaEntity (which also draws different direction graphics)

What happens:
The machine can be placed, and if you try to rotate it, it doesn't rotate, and does raise on_player_rotated_entity, but the direction does not change.

Why is this a problem?
For mods that are reacting to the entity rotating and changing e.g. "attached" loaders, or other combined entities, this causes unexpected behavior, including that from a design standpoint, the entity doesn't look like it rotated, leading to a rabbit hole of "why are my graphics wrong, it did rotate?".

Example mod:

Code: Select all

local chem = data.raw["assembling-machine"]["chemical-plant"]
chem.collision_box = {
    {
      -2.2,
      -1.2
    },
    {
      2.2,
      1.2
    }
  }
chem.fluid_boxes_off_when_no_fluid_recipe = true

Code: Select all

script.on_event(defines.events.on_player_rotated_entity, function(event)
    game.print("rotated, direction: "..event.entity.direction)
end)
unexpected_rotation_0.0.1.zip
(1.18 KiB) Downloaded 33 times

Save file:
unexpected_rotation.zip
(288.42 KiB) Downloaded 30 times

For comparison, an assembling-machine-2 is beside, which elicits "This cannot be rotated." (the first example of potentially "proper" behavior). More organically, the second option of successfully rotating and altering the LuaEntity makes "sense", whether it's for direction-able assemblers, square or otherwise.

Re: [2.0.55] Modding - Non-Square Machines, Fluidbox, Rotation event

Posted: Fri Jun 06, 2025 5:42 am
by StephenB
I ran into this issue with my mod. Non-square assemblers can be rotated, but if the machine has no fluidboxes or fluid_boxes_off_when_no_fluid_recipe == true, then pressing the rotate key on it will raise the rotation event but the entity's .direction doesn't update. Basically it looks like there's an engine optimization / bug that doesn't allow entity.direction to be changed for assemblers with no fluidboxes. Assigning `entity.direction = 12` and then reading `entity.direction` will still give you the original direction, not the new one.

Not sure what the solution to this is, assuming it's not a bug. Maybe treat assemblers with 4-directional sprites as rotatable even without fluidboxes?

If you git clone my WIP mod https://github.com/StephenBarnes/Legend ... 14e51389cc you can place down the "classifier" building which is a 2x1 assembler, and it can be rotated 180 degrees. If you remove the code here https://github.com/StephenBarnes/Legend ... r.lua#L210 that adds the fluidbox, and replace it with `miniAssembler.fluid_boxes = nil`, then it stops working - rotating the assembler doesn't change the entity's .direction, so it keeps the wrong directional sprites. (Loaders will still rotate 180 degrees but that's done with separate control scripting.)

Re: [Lou][2.0.55] Modding - Non-Square Machines, Fluidbox, Rotation event

Posted: Wed Jun 11, 2025 5:44 pm
by Lou
Thank you for the report. The Honktown's case is fixed for 2.0.56 - the event will be raised only when the rotation will happen (in these cases at least).

Re: [2.0.55] Modding - Non-Square Machines, Fluidbox, Rotation event

Posted: Wed Jun 11, 2025 5:45 pm
by Lou
StephenB wrote: Fri Jun 06, 2025 5:42 am ...
that should fix your problem as well, right?

Re: [Lou][2.0.55] Modding - Non-Square Machines, Fluidbox, Rotation event

Posted: Thu Jun 12, 2025 3:32 am
by StephenB
Adding the extra fluid box solves my issue. If you remove the rotation event it doesn't affect that, I will still need the extra fluid box.

If it's intentional that .direction cannot be changed for these assemblers after they've been placed, I think there should be a note on that somewhere. Currently LuaEntity.direction says it's "Read|Write", and LuaEntity.supports_direction is true, but if you try to write a value to LuaEntity.direction for these assemblers then it just fails silently. Same for LuaEntity.mirroring. (Maybe I should put this in a separate bug report / api request though.)

My preferred behavior would be to keep sending the rotation event, and also allow control-stage code to actually assign values to those fields instead of needing the undocumented workaround of adding extra fluidboxes.

Re: [Lou][2.0.55] Modding - Non-Square Machines, Fluidbox, Rotation event

Posted: Mon Jun 16, 2025 10:55 am
by Lou
I see. Currently assembling machines are being treated (by default) as if they do not have direction (even for the purposes of LuaEntity::lueWriteDirection). The exceptions to this as of now are if any of the following:
  • has asymmetrical collision box
  • has active fluid manager
  • its energy source has direction
  • has output spot
  • is connected to circuit network and setting recipe
  • have parametrised recipe
The working assumption being, there is no reason to change the direction otherwise. May I ask about your use case - why do you need to rotate assemblers that does not satisfy any of the conditions?

Re: [Lou][2.0.55] Modding - Non-Square Machines, Fluidbox, Rotation event

Posted: Mon Jun 16, 2025 5:22 pm
by StephenB
I made a modded assembler that creates 2 attached loaders when you place it. When you rotate it the attached loaders get rotated. Noticed that the sprites weren't rotating so I tried writing .direction in my code to make it rotate but that didn't work. So I asked on the mod-dev-help discord. Honktown reproduced the behavior and made this post. Anyway this only causes problems in very niche mod situations (only other report I saw is viewtopic.php?t=102674) and doesn't matter in the base game. Up to you whether to still send the on_rotate event or support writes to .direction for these assemblers, I'm fine either way.