make more entity prototypes support rotation

[war877]

TL;DR

Allow storage containers and lamps and power poles to be rotated.

What ?

These types should be non-rotatable by default, but would enhance modding flexibility if they could be rotated.

Why ?

I currently have need of rotating non-square storage containers and lamps. Getting such objects to rotate without rotation is complicated and probably bad for UPS. EDIT: power poles as well.

[ssilk]

This makes no sense.

- not possible to make rectangular light sources, and I also don’t see a reason why, just add more lights together.
- there are already mods, which use rectangular containers, and that mods seem to have no problems to rotate
- power poles have pseudo-rotation (rotate into position after placing)
- I generally don’t understand why something needs to be rotated, when it looks equally from all directions

[Koub]

This makes no sense.

- not possible to make rectangular light sources, and I also don’t see a reason why, just add more lights together.
- there are already mods, which use rectangular containers, and that mods seem to have no problems to rotate
- power poles have pseudo-rotation (rotate into position after placing)
- I generally don’t understand why something needs to be rotated, when it looks equally from all directions

I don't agree with you Ssilk. I can't speak on the moddability of what can be rotated or not, and can't say if this would be doable or not code wise, but it totally makes sense for a modder to want to be able to mod rotatable lights or containers in for custom non square lights/containers.
One can argue that constant combinators don't "need" to be rotated, yet they can be out of the box.
Whatever placeable entity should be allowed to be rotatable, if the modder designs it so.

[mrvn]

- I generally don’t understand why something needs to be rotated, when it looks equally from all directions

Do power poles, lights, chests need to look equal from all directions? Do the circuit connection need to be in the same spot all the time?

Rectangular objects certainly don't look the same horizontal and vertical.

Please add the power switch to that list. Why can't I rotate that one? It clearly would look different when rotated.

[ssilk]

One can argue that constant combinators don't "need" to be rotated,

? But constant combinator can be rotated?

Whatever placeable entity should be allowed to be rotatable, if the modder designs it so.

I'm not longer in modding, so I dunno/not 100% sure: as far as I remember there is no reason, that any entity cannot be rotated. It just needs grafics and some configuration, but it might work out of the box.
Someone may correct me if I'm wrong, please.

- I generally don’t understand why something needs to be rotated, when it looks equally from all directions

Do power poles, lights, chests need to look equal from all directions? Do the circuit connection need to be in the same spot all the time?

Not the point here. If the entity has no grafics for rotation, the game cannot invent one. If a modder rotates an entity, that has only one graphics, it might not work. Sounds stupid, but eventually part of the problem.

Please add the power switch to that list. Why can't I rotate that one? It clearly would look different when rotated.

Ah, yes, good point, now this suggestion becomes more flesh. Could it be, that a combinators are only rotatable in two directions.

But I fear we need more expert knowledge to discuss this, because as said above I think this is partly working. Or may be totally wrong.

[Koub]

? But constant combinator can be rotated?

2021-11-18 00_03_26-Factorio 1.1.46.jpg (39.11 KiB) Viewed 3360 times

[ssilk]

Hm. I should look better before I post.

[FuryoftheStars]

If the entity has no grafics for rotation, the game cannot invent one. If a modder rotates an entity, that has only one graphics, it might not work. Sounds stupid, but eventually part of the problem.

From what little I'm able to figure out looking through the entities file, I believe this is exactly it. Rotatability does seem to appear to depend on the graphics being created for it. I don't see anything for a general "can rotate" true/false flag anywhere.

[Bilka]

Whether an entity can be rotated (sometimes conditionally, e.g. turrets or crafting machines) depends on the entity type. Neither containers, power switches or lamps can be rotated.

Moved to modding interface requests.

[Lubricus]

It would be nice to have moded rectangular chests and still be able to rotate blueprints 90 degrees.
It's a request to make mods work better without being an API request. Vanilla chests is quadrates so they don't need to be rotated but moded ones may need it. In particular I am planning to use the merge chest mod to save UPS in my Py factory but then I either have to make an vertical and horizontal version of all stations or merge the chests after the BP is built. It's also makes it harder to duplicate existing builds when needed.

[FuryoftheStars]

viewtopic.php?f=28&t=100628

[ssilk]

merged with existing thread

Thanks to Fury, search would take me much longer without this hint to this board.

[Rseding91]

Largely the issues with making something rotatable that the base game never needs to be rotated are:

A) the entity code has to support it in a path base-game never runs (error prone)
B) the entity needs to use more RAM to store the direction for every entity even when not used by the base game
C) the save file has to save/load the direction even when it isn't being used by base game

B and C are the main factors why things don't support direction. A can largely be addressed with tests but still isn't ideal.

[Lubricus]

Largely the issues with making something rotatable that the base game never needs to be rotated are:

A) the entity code has to support it in a path base-game never runs (error prone)
B) the entity needs to use more RAM to store the direction for every entity even when not used by the base game
C) the save file has to save/load the direction even when it isn't being used by base game

B and C are the main factors why things don't support direction. A can largely be addressed with tests but still isn't ideal.

Is it possible to use Composition design pattern or something to make it possible to mix and match properties for entities more? Or will it be to messy and inefficient?

[Atria]

What about adding support for rotations of not rotatable entities by adding new field to entity prototype? This field would contain name of other entity (of same type) which is mean to be a 90° rotated version of the first entity. Making four entity prototypes chained like this would simulate rotating without modifying runtime instance of the entity.

[mrvn]

As for C: While waiting for the game to (auto)save is boring is that really something we should feature shorten the game for so it's 0.00001% faster?

Why do entities even have rotating and non-rotating types? Or if they must why isn't that using dependency injection?

The entity class should get the rotating or non-rotating support injected into the base type. That way when loading prototypes the entity factory can create a rotating or non-rotating entity for anything depending on the data instead on hardcoding which type is rotating and which is not. Same deal with animated or non animated entity. That would take care of case A too since every entity would be using the same code and with rotating and non-rotating entities in vanilla both sides get tested. A bit harder to save and load when updating versions (when changing between rotating and not, bit of a migration issue).

Or you know, just put those 2 (3 for rails or underground belts) bits of information into some left over bits in something else that doesn't need the full width of it's data type. For non-rotating entities those bits are just ignored. I can't believe there isn't some values you can clip off 3 bits. Like health for example. Do we need 65535 max health? Or is it 2/4 billion?

[Rseding91]

You're welcome to make your own game with a similar feature set to Factorio and implement it in a way you see fit.

[mrvn]

You're welcome to make your own game with a similar feature set to Factorio and implement it in a way you see fit.

Sorry if I come across snarky. You're doing a great game. I'm just sometimes amazed at some of the problems when they are well known programming issues with established solutions. It triggers the "I've learned about how not do this and that sounds exactly how this was done" syndrom.

[Qon]

I'm just sometimes amazed at some of the problems when they are well known programming issues with established solutions. It triggers the "I've learned about how not do this and that sounds exactly how this was done" syndrom.

Well, do you think Rseding91 doesn't know or considered and rejected the things you suggested, when it was first designed? Or maybe he and the team had different goals with the system and more insight into how the tradeoffs would affect the product, which means that they saw that your solution brought more issues than beneits?

"Established solution" works great for standard cookie cutter games, which Factorio is not. Inflexibility is a strength when it leads to reliable and performant systems that handle large amounts of data. And Factorio has become amazing because it is taking advantage of these strengths. Other games would have a series of levels for designing and running each system by itself.

Also, it's a bit weird to suggest completely restructuring the entity system architecture for a mod that can probably already be made with some workarounds if you try a little bit more, when it would give massive amounts of work to Wube and worsen their vanilla product.

[curiosity]

Sorry if I come across snarky. You're doing a great game. I'm just sometimes amazed at some of the problems when they are well known programming issues with established solutions. It triggers the "I've learned about how not do this and that sounds exactly how this was done" syndrom.

The devs have different priorities when it comes to Factorio and they won't budge. Rseding enumerated the relevant ones above. You have to argue in the context of those priorities if you want to convince them. For example (no-effort suggestion), make a rotatable variant of each prototype type.