[Request] Inserter pivot point offset

[Deadlock989]

Following this. It would be very useful to be able to offset the point around which the inserter arm pivots when moving. Something as simple as a shift vector:

Code: Select all

data:extend {{
    name = "fairy-dust-powered-inserter",
    type = "inserter",
    pivot_offset = {0,-0.225},
    ...
}}

This would only affect the point around which the inserter's lower arm section rotates, the point where it "joins" the platform. It would not affect the target of the inserter: an inserter with an adjusted pivot point would still target the same insert and pickup positions relative to the entity's position. Essentially it is only a visual tweak. If it results in distortions of the inserter arm then I imagine there is scope for adjusting that with the existing hand_size parameter.

Use case: taller platforms for inserters, e.g. a platform with pipe connections.

[eradicator]

Is one offset sufficient for all 4 directions?

[Deadlock989]

Is one offset sufficient for all 4 directions?

Uh ... probably, for my use case. You could assume the platform is just rotating around the Z axis through the same pivot point, in which case, the centre of the platform would be offset by the same amount regardless of direction.

But I guess it wouldn't hurt to be able to define it in a table of directions if that were no more difficult to achieve.

To be honest even just a Y axis shift would do me - I can't think of any use case where an inserter platform would be rotating around a non-central point. It's the simulation of Z height we're trying to achieve, which on the screen is all on the Y axis. There is some precedent for this sort of thing (e.g. storage tank fluid level flow sprites).

[Rseding91]

This isn't likely to happen since it would mean all base game inserters have 1 more dynamic property to read in each tick as they move slowing them down just that tiny bit more for something they will never use in base game.

Inserters are currently the highest CPU consumer by far on almost every save except ones with 50,000+ robots in the air all the time.

[Klonan]

This isn't likely to happen since it would mean all base game inserters have 1 more dynamic property to read in each tick as they move slowing them down just that tiny bit more for something they will never use in base game.

Inserters are currently the highest CPU consumer by far on almost every save except ones with 50,000+ robots in the air all the time.

If it was just for used for rendering, it won't make any performance difference

[Deadlock989]

I'm not asking to change the behaviour of inserters in any way at all. I don't need it to be a dynamic property (by which I understand accessible at runtime). It's purely about the rendering of the stretchy arm segments.