make more entity prototypes support rotation

[mrvn]

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.

A lot of game developers are working a decade or two behind modern programming practices, especially in C++. So it might well be that Rseding91 doesn't know about dependency injection or that's something not widely known (and therefore not welcome) at wube.

But what I wrote was:

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

A non-rotating type is just one with only 1 direction. Other entities might have 2 so you can turn them 180°. Most do have 4 with a 90° rotation and then there are rails with 8 directions and 45° rotation. Trains have 16 directions so they look better in curves, right?

So my question was: With entities with variable number of directions why is 1 a special case at all?

And the followup: Weather he knows about dependency injection or not and why it wasn't used.


I didn't ask them to change the game to use dependency injection when they didn't. It's kind of hard to do that after the code has been written. It's a fundamental design decision, not something you can just change. I asked why they made the choices they did.

[Rseding91]

… my question was: With entities with variable number of directions why is 1 a special case at all?

Because an entity with only one direction does not *have* a direction. There is no data member on the entity that stores the direction and instead the default virtual function of getDirection() simply returns north.

It’s 10:30 PM right now and I’m heading to bed with the worse case of strep throat I’ve ever had so I will reply about the other things in more detail tomorrow.

[curiosity]

A lot of game developers are working a decade or two behind modern programming practices, especially in C++. So it might well be that Rseding91 doesn't know about dependency injection or that's something not widely known (and therefore not welcome) at wube.

Pretty sure dependency injection is as old as OOP itself (though the name might be new), not to mention an obvious application of the OOP paradigm. It's safe to say that Rseding knows about it.

[Rseding91]

... Weather he knows about dependency injection or not and why it wasn't used.

Factorio uses dependency injection in a few places where it makes sense; network sockets, graphics, sounds, and so on. However, dependency injection only works when your dependency is an interface (set of virtual function) and is placed on the heap. There are some possible ways to work around those limitations but for the most part they just move those issues slightly somewhere else.

At the end of the day you still pay the sizeof() increase on what ever is storing that dependency because it can't be stored directly - it's on the heap - the class needs to store a pointer to it (minimum 8 bytes). 1 per "dependency" injected. Every usage of it will be a runtime virtual function call and jump to a separate heap allocation.

In virtually everything game-engine-wise the intermediate parts of what make up an entity are not themselves virtual or even when they are, are not individually allocated on the heap.

Take for example the boiler. These are the immediate data members of the boiler:

Code: Select all

  FluidBox* fluidBox;
  FluidBox* outputFluidBox;
  EnergySource* energySource;
  Direction direction;
  uint16_t burningCooldown = 0; // not serialized - only for animation
  uint32_t animationFrameShift; // not serialized - only for animation
  float fluidTransferredLastTick = 0; // not serialized - only for tooltip
  WakeUpList wakeUpList;

An instance of the direction class is stored by-value in the boiler and takes 1 byte of space to exist inside Boiler. When it's accessed inside the boiler code there is no indirection, no virtual function calls, no extra heap allocation to load in.

These are the immediate data members of the resource entity:

Code: Select all

  /** Amount of resource left, every mining event decreases this, when it gets to 0, resource is removed */
  uint32_t resourceAmount = 0;
  uint32_t initialAmount = 0;
  uint8_t variation = 0;

Resources don't have a direction and so there is no direction instance in this class. It's the same with the base Entity class.

[mrvn]

... Weather he knows about dependency injection or not and why it wasn't used.

Factorio uses dependency injection in a few places where it makes sense; network sockets, graphics, sounds, and so on. However, dependency injection only works when your dependency is an interface (set of virtual function) and is placed on the heap. There are some possible ways to work around those limitations but for the most part they just move those issues slightly somewhere else.

At the end of the day you still pay the sizeof() increase on what ever is storing that dependency because it can't be stored directly - it's on the heap - the class needs to store a pointer to it (minimum 8 bytes). 1 per "dependency" injected. Every usage of it will be a runtime virtual function call and jump to a separate heap allocation.

In virtually everything game-engine-wise the intermediate parts of what make up an entity are not themselves virtual or even when they are, are not individually allocated on the heap.

"Factorio uses dependency injection in ... graphics". Isn't the rotation, specifically the direction value, purely a graphics thing?

As said dependency injection needs an indirection, indeed. But so does the virtual table to inheritance. Both will use an indirect call. If you have an list / array / set / vector / whatever of entities and some are rotating and some are not rotating there isn't really any way around either a branch or an indirect call. So no change there.

But the thing they point to doesn't need to be heap allocated. In fact why would it? The API is defined by module you insert and that should have a static struct with all the functions. You say "store a pointer to it", so that would be a pointer to a single struct defined by the RotatingEntity or NonRotatingEntity classes that are injected in the prototype phase. Nothing is heap allocated there.

On the other hand you could store it directly instead of a pointer. You save that indirection through a pointer but then you have to store 8 byte per function the dependency has. Each entity would have a copy of the graphics API function pointers. I'm not sure anyone does this on a larger scale, the memory overhead is worse than the pointer indirection in almost all cases I believe.

So "runtime virtual function call" yes, "jump to a separate heap allocation" no. Every boiler will lookup the same static struct to jump to the same static function to draw a boiler using the same static jump table for the RotatingEntity implementation.

It's the same with virtual tables and dependency injection. You only have one table per type, not one per instance.

Take for example the boiler. These are the immediate data members of the boiler:

Code: Select all

  FluidBox* fluidBox;
  FluidBox* outputFluidBox;
  EnergySource* energySource;
  Direction direction;
  uint16_t burningCooldown = 0; // not serialized - only for animation
  uint32_t animationFrameShift; // not serialized - only for animation
  float fluidTransferredLastTick = 0; // not serialized - only for tooltip
  WakeUpList wakeUpList;

An instance of the direction class is stored by-value in the boiler and takes 1 byte of space to exist inside Boiler. When it's accessed inside the boiler code there is no indirection, no virtual function calls, no extra heap allocation to load in.

These are the immediate data members of the resource entity:

Code: Select all

  /** Amount of resource left, every mining event decreases this, when it gets to 0, resource is removed */
  uint32_t resourceAmount = 0;
  uint32_t initialAmount = 0;
  uint8_t variation = 0;

Resources don't have a direction and so there is no direction instance in this class. It's the same with the base Entity class.

Note: Direction takes 2 bytes due to padding following it. fluidTransferredLastTick takes 8 bytes, again due to padding (assuming WakeUpList has a pointer in it). Removing the direction for a non-rotating boiler would save you 0 bytes of memory because without direction the burningCooldown is then followed by 2 bytes padding.

At least in this case the Direction member variable takes no extra space in the class. That's what I mend when I said:

put those 2 (3 for rails or underground belts) bits of information into some left over bits

There frequently is enough padding in a class to add in such small bits of data in existing holes at no extra memory cost or some variable uses a larger data type then the information needs and could spare some bits.

Note2: where is the "infinite" bit stored for resources?

It's too bad that the compiler can't optimize the layout of the data members of the class to put data into holes. And not just reordering the members in the class itself but using holes in the base class as well. There probably is already a padding byte in the EntityWithHealth or whatever boiler derives from last that could store the direction making the overall class smaller.

[Rseding91]

"Factorio uses dependency injection in ... graphics". Isn't the rotation, specifically the direction value, purely a graphics thing?

Direction is used to determine the orientation of the bounding box on the entity, to determine which way input and output fluidboxes are on the entity, to determine which way something like an inserter picks up from and drops off to, is exposed to the Lua API, can be changed by the player through rotation and so on.

As for everything else you said; you completely lost me. It sounds like you have an idealized system in your head for how things should be working that doesn't come close to how it works in Factorio.

For each Prototype type that exists there is a backing C++ class that stores all of the immutable data members for that prototype instance. For a given prototype instance it can be used to create a runtime instance of that type (TreePrototype can be used to create instances of Tree). This class is hard-coded and fixed at compile time.

Each runtime instance contains the runtime mutable state of that entity and a pointer back to the prototype used to create it (the immutable state).

Runtime instances of things are done through inheritance with entities starting at at the base class Entity and things deriving from there. You can see this partially in the prototypes https://lua-api.factorio.com/latest/pro ... otype.html where it shows the inheritance path for the TreePrototype. The data stored in a given instance is hard coded and fixed at compile time.

When an entity needs to be updated it's update() function is called and it does the logic it wants to do. Inside the entities update function it has access to all of its data members and it does what it sees fit.

[mrvn]

"Factorio uses dependency injection in ... graphics". Isn't the rotation, specifically the direction value, purely a graphics thing?

Direction is used to determine the orientation of the bounding box on the entity, to determine which way input and output fluidboxes are on the entity, to determine which way something like an inserter picks up from and drops off to, is exposed to the Lua API, can be changed by the player through rotation and so on.

As for everything else you said; you completely lost me. It sounds like you have an idealized system in your head for how things should be working that doesn't come close to how it works in Factorio.

For each Prototype type that exists there is a backing C++ class that stores all of the immutable data members for that prototype instance. For a given prototype instance it can be used to create a runtime instance of that type (TreePrototype can be used to create instances of Tree). This class is hard-coded and fixed at compile time.

Each runtime instance contains the runtime mutable state of that entity and a pointer back to the prototype used to create it (the immutable state).

Runtime instances of things are done through inheritance with entities starting at at the base class Entity and things deriving from there. You can see this partially in the prototypes https://lua-api.factorio.com/latest/pro ... otype.html where it shows the inheritance path for the TreePrototype. The data stored in a given instance is hard coded and fixed at compile time.

When an entity needs to be updated it's update() function is called and it does the logic it wants to do. Inside the entities update function it has access to all of its data members and it does what it sees fit.

Nothing of that really goes against what I described. Except the direction being accessible through lua and from other entitites too. That certainly puts a crimp in considering direction graphics only.

Things like the inserters pick up / drop off position and pipe connections I would have though you determine only when things get build/destroyed and then save the rotated location. But you are right that you need the direction there too to calculate them in the first place even if just once per change. My bad. Speed shouldn't be a major concern there but access needs to exist outside of the graphics dependency. Any overhead from having a non-rotatable entity being stored as rotated 0 degrees should be neglible speed wise though, placing entities is relatively rare.

I was only thinking about drawing entities because the game does that every frame. Overhead there slows down the game. And there obj->dependency->function() is the same as obj->virt_table->function(). And rotation and scaling of the graphics is done by the GPU. Having all entities use the same transformation even when rotating by 0 degrees sounds like the easier solution than having one draw function for rotatable and one for non-rotatable entities. That was my thought process anyway.

But you mention update(). Does the entities update really care about the direction? As said I would assume inserters and pipes are calculated once and then every update there is nothing direction specific there. For inserters for example you go through the wakeUpList. You don't look at the direction, determine the inserter north by 3 tiles can reach the rotated collision box of the entity and then wake up the inserter. At least I hope you don't.

[Rseding91]

I feel like this conversation has gotten off-topic and still nothing has been explained to you to let you understand the limitations.

"Make more entity prototypes support rotation" the topic title:

"Support rotation" is entirely dependent on a given entity for what that means. For something like a tree it currently has no meaning. Tree sprites are not rotatable in how they're designed. Trying to rotate one would be gibbrish. So if a tree was made to "support direction" that meaning has to be defined and programmed into the tree.

• Would it maybe make some leaves move around on the tree? Some branches move around?
• Would it maybe just straight up rotate the drawn sprites all looney-tunes like with the tree-trunk facing to the weast?
• Something else crazy?

There is no good meaning I can associate with rotating a tree currently.

Maybe something else like a resource entity:

• Directly would looney-tunes rotate the sprite to be drawn I guess
• Add the data member that stores the direction
• Add save/load of the direction data member
• Add the overloads for getting/setting direction on the resource entity
• Add the code to set direction when created via Lua
• Add the code to ensure direction is cloned when the resource entity is cloned
• Should copy-paste on the resource copy direction? If so, that need to be added
• Should fast-replace on the resource copy the direct? If so, that needs to be added
• Add the drawing code to draw the sprite rotated when the direction is given
• Add the direction to the tooltip (if wanted, maybe not?)
• Does having a direction make the bounding box of the resource rotate or is this pure visual?
• If it does rotate the bounding box: can it be changed runtime? If so, is it ok to change-direction and have the bounding box collide with something after rotation or should that be blocked? Should it work like boilers where they can be flipped end to end but not rotated 90 degrees since it would change what the bounding box collides with potentially

And that's JUST the resource entity with zero other game interactions. Every single entity you have to ask these questions about every single mechanic the entity has and how direction is supposed to interact with those mechanics and then program that interaction into the entity - because that interaction is most likely going to be specific to that entity and that interaction. A tree with direction doesn't need to care about fluidboxes.

Next lamps:

• Lamp sprites are currently not just ready to be drawn rotated and you'd end up with upside-down or weast facing lamps that would make no sense
• What else is there to do with a direction on a lamp?

Next electric poles:

• Electric poles have a "direction" based off the connected wires that the bit on the top of the pole draws using a variation defined in the prototype. This tries to make it look nicer with all the wires connected to the pole but otherwise is a pure visual aspect.
• Letting a mod change this through some Lua API would be trivial.. but nobody has asked for it because it's not technically a direction on the entity. It's just an 8-bit unsigned number that determines which sprite variation is used.
• What would an electric pole having a direction even mean? What gets drawn different if one was rotated?

Next storage containers:

• What does setting direction on these do? Currently every container in base game is 1x1 and has no meaning to be rotated. If one wasn't 1x1, what would rotating it do? It's still some rectangle so if it's a symmetric square, it functionally has no difference when rotated since it's still a symmetric square. If it's not, this goes back to the "can it rotate into colliding things? If no, that has to be handled some how and that code doesn't currently exist so it needs to be written, tested, and maintained.
• ???

[curiosity]

Letting a mod change this through some Lua API would be trivial.. but nobody has asked for it because it's not technically a direction on the entity. It's just an 8-bit unsigned number that determines which sprite variation is used.

I wonder, if people knew that having a script-controlled sprite variation was possible, maybe they would ask for that instead of rotatable entities.

[mrvn]

There are two parts to the direction of an entity:

1) the collision box rotates, the direction of the belt changes, the location of pipe connection changes.
2) You get a different graphic.

I agree that rotating a tree makes little sense. Well, the first 90° rotation makes the tree a fallen tree. That could still work. 180° rotation producing an upside down tree? Not sensible.

But nobody said every entity must be rotatable in 90° steps. A tree simple has just one direction to rotate through. There is nothing stopping the tree from having a direction that must always be 0 other than it being unnecessary to store that. Now if someone makes a sunflower that can point it's flower in different directions then maybe they want it to be a tree with multiple directions. For example the entity could be rotated via LUA script so the flower follows the sun over the course of a day.

Similar with resources. They have variations. Since resources are square rotating them (point 1) has no effect and you are only left with different graphics (point 2). So resource placement would simply set random rotations instead of random variations. You would have gotten resource variations for free with rotatable resources.


You say: "Support rotation" is entirely dependent on a given entity for what that means.

I take rotation as rotation of the entity around the Z axis (reaching out of the ground). As everything is 2D in the game that means the selection and collision boxes rotate and the graphics should match that effect. Any connections like pipes or wires should rotate so the entity visually looks like it rotates. That is the meaning of rotation in the game at the moment. For buildings this works because they are generally retangular and scewed so they don't exceed the footprint they would have as 3D model.

As you said for some things that makes rotation nonsense. Like trees. Unlike buildings they are not designed to have a selection/collision box matching their base plate but the box encompasses the whole tree as projected. Rotating them would make them wider than high instead of rotating them around their roots. One could say the error here is that trees should have a square collision box with the crown growing out of the box. Then they could be rotated to give the same tree as seen from different sides.

Would it maybe just straight up rotate the drawn sprites all looney-tunes like with the tree-trunk facing to the weast?

Not sure how you come to that idea. I believe none of the rotatable entities has just one sprite sheet that the game then just draws rotated. That doesn't work with the viewpoint shown in the game. To make an entity rotatable the user has to provide the rotated graphics and all the information for how wire connections change and such just like for already rotatable entities.

So if the user defines a tree that is rotatable then the most natural would be to simply render a single 3D tree model from different sides. But since the user can't rotate trees it could also be just a collection of different trees. Variants of trees and the map generator makes a more natural looking forest by picking different rotations of one oak tree entity instead of having 20 slightly different oak entities. Same idea for resource entities. It's just variations.

My current use case would be a rotatable chest. I'm working on a simpler crafting combinator that can change the recipe of an assembler placed next to it with circuit logic. Internally it is a chest because I want the user to be able to store module items in it. Currently the assembler can be placed on any side of the crafting combinator making it a problem if the crafting combinator is placed between 2 assemblers. Since internally it is a chest the crafting combinator can't be rotated so I can't make it only connect to an assembler on one side and have the user rotate it to face the assembler it should connect to.

Creating graphics and defining wire connections for a rotatable chest would be my job. The game just rotates the bounding boxes and selects the sprites defined for the selected rotation. It's my job to make the rotation make sense.

Letting a mod change this through some Lua API would be trivial.. but nobody has asked for it because it's not technically a direction on the entity. It's just an 8-bit unsigned number that determines which sprite variation is used.

I wonder, if people knew that having a script-controlled sprite variation was possible, maybe they would ask for that instead of rotatable entities.

Kind of but not totally. For my example above for the crafting combinator the user has to be able to rotate the entity before placing it. It should be rotatable as ghost or after being build as well, ideally. So access only through LUA wouldn't be enough. If you only need that then you can define 4 entities and swap them in LUA whenever you want to "rotate". Slightly complex but totally doable now.

For the crafting combinator I now need to use one entity that is rotatable, like a constant combinator, and then have a second chest entity that gets created on-entity-built and do some ugly tricks to make blueprints, copy&paste and wire connections work correctly. User interface wise it's suboptimal too. In the middle you get the selection box of the chest and can open the chest to place modules. Going off center you get the selection box of the constant combinator and can rotate it.

Side Note: I just remembered a mod called "Landfill Painting" that has rotatable landfill. Rotating gives different variations of landfill. I should look how they did that since normally landfill (tiles) isn't rotatable in the UI. Maybe they same would work for a chest? For me the the GUI interaction (rotating when placing the entity) is more important than it being a rotatable entity internally.

[Rseding91]

Everything you just described is the concept of "variation" in Factorio which we already have for most things. Direction is completely unrelated and it seems like what you want is to highjack direction to mean variation on a bunch of entities where direction makes no sense.

Trees have variations.
Resources have variations.
Electric poles have variations (currently auto-set based off the connected wires)

And then you want the rotate hotkey to cycle between variations.

So really the topic tittle (for you) is not "make more entities support rotation" but "make more entities support variation and give a way to control that when building them."

Unless I'm missing something.

[BrainGamer_]

when an entity has a square collision box rotation effectively is just a variation but if its not a square and the collision box also needs to adapt that would then be a rotation right? ignoring other things that would need to also adapt like potential fluidboxes, wire connection points, ...

[mrvn]

No, my need is an actually rotating chest that has a functional (where the LUA code then connects to an assembler) and visible (the graphics showing where it would connect) direction.

I just mentioned that variations could be merged with direction because you brought up trees and resources and asked what meaning direction could have for them.

For the graphics part they are basically the same thing under a different member variable. The object has a variable that says which index of the sprites sheets should be used to draw it. Functionally rotation on trees or resources has no meaning and assuming the bounding boxes of trees are made square would simply have no effect other than changing the graphics. Something now implemented as special case in the form of variations.

I'm not saying you should change variations into rotations or anything. It's just an example of what meaning rotation could have for trees. How the same effect could have been achieved by another means.

[mrvn]

when an entity has a square collision box rotation effectively is just a variation but if its not a square and the collision box also needs to adapt that would then be a rotation right? ignoring other things that would need to also adapt like potential fluidboxes, wire connection points, ...

The box must also be centered. Otherwise rotating changes where the box ends up.

[curiosity]

Everything you just described is the concept of "variation" in Factorio which we already have for most things. Direction is completely unrelated and it seems like what you want is to highjack direction to mean variation on a bunch of entities where direction makes no sense.

Trees have variations.
Resources have variations.
Electric poles have variations (currently auto-set based off the connected wires)

And then you want the rotate hotkey to cycle between variations.

So really the topic tittle (for you) is not "make more entities support rotation" but "make more entities support variation and give a way to control that when building them."

Unless I'm missing something.

They literally "just described" that they have a non-square container that needs to be rotatable.

Which reminds me of my own idea. Rotatable beacons would be great.

[curiosity]

Side Note: I just remembered a mod called "Landfill Painting" that has rotatable landfill. Rotating gives different variations of landfill. I should look how they did that since normally landfill (tiles) isn't rotatable in the UI. Maybe they same would work for a chest? For me the the GUI interaction (rotating when placing the entity) is more important than it being a rotatable entity internally.

Tiles went in a different developmental direction, one that has already been mentioned here: have multiple prototypes that point at each other. Most importantly, this even works with blueprints. And it avoids the two major issues that Rseding outlined: extra memory per entity and extra save data. There doesn't seem to be any drawbacks/problems with implementing this.