These are a few API changes that I, personally, would find quite useful. Most are things others have already requested, but here I would like to explain in more detail why, at least for me, they would be useful and some ways to perhaps implement them. There are some ways to work around the lack of these API, but not all of them can be worked around nor are any of the solutions elegant. There are a few mods that people have requested that I would be happy to explore, and some of them I might work on anyway. These changes would make some mods easier to build, while allow others to exist at all.
1. Entity rotation. More specifically, the ability to graphically represent rotation for more/every entity. This is especially relevant to me right now, since I am having to write an extremely awkward work-around this very moment. The benefits are pretty self-explanatory and well requested, so I won't push further. All that would be needed is a way to tie multiple png's to the same animation, one for each direction. Most of the prototypes I've been working with already have and keep track of their direction, they just don't do anything with it nor do they show it. At the moment, the solution I've found is to create an entirely separate copy of the prototype for each direction, tie the 4 png's to those prototypes, and then through scripts manually destroy the entities and then create the new one with the right directional png every time my entity is rotated. Not efficient or easy to work with.
2. Some way to intercept or modify the game.caninsert() function (or it's 0.12 equivalent). As far as I know, caninsert() is what is used by inserters and the like to determine whether it can place an item in it's hand into a given inventory. Being able to intercept this and add further, custom conditionals would be quite useful. In fact, Lost Ninja has requested a mod with chests that only allow certain items to be placed in them. Aside from the necessary GUI elements to control the filter, this would be a simple matter to implement were I able to add an additional conditional statement to caninsert() based upon the ItemStack parameter. I don't know if there is an easy way for lua to pass conditionals to parents or if it's even possible, but I was thinking there could be an insertconditions read/write property for Lua/inventory that contains a function. caninsert() would, in addition to it's normal programming, add an "and inventory.insertconditions(itemstack)" passing the itemstack to the cuntion contained in insertconditions and then check itself against what that function returns as to whether or not it was also true before inserting the stack. By default, the function inside insertconditions ignores itemstack and always evaluates to true, causing caninsert() to function as normal. However, now either through the prototype definition or more importantly though scripts, modders can change the function contained inside insertconditions to one that uses itemstack and/or whatever else at it's disposal to determine exactly when an inventory can be inserted into and what can be placed in it.
3. A full file read/write system. From what I've seen, one can read from a custom lua file in control.lua much in the same way that it reads from defines.lua. This can be used to have a system of custom config files, however afaik these can't be written to properly from within control.lua. game.makefile() doesn't seem to work in the way I expected it to (or work in any way that I can see at all) and even still it isn't a way to more coherently control what actually is placed in the file nor how it's structured. It would be nice to be able to build complex save files that are unique to each save-game, but at the very least it would be nice to be able to change configurations in-game through a gui, and that option (again, afaik) is not possible.
4. Ability for entity prototypes that use electricity to not, and for more/all entity prototypes that previously could not use electricity to be able to through the definitions. Pretty self-explanatory. A lot of times I need to use certain entity prototypes in ways that they were clearly not meant to be used in order to gain the functionality I need. Having more control over it's power consumption would be quite nice. Sometimes I might want to make a high-tier chest that has a ton of storage, but I want to balance it beyond simply making the recipe more difficult. I might, therefore, want to require that it be hooked up to an electrical grid in order to be accessible. Other times I might want to use a higher-tier entity prototype like an assembler as a base for a lower-tier one, like a simple transport belt attachment. I don't necessarily want that item to take power, since it's supposed to be used earlier on in the game. One can constantly refill the entity's buffer via scripts, but that's inefficient and inelegant. As for entities that don't normally consume power, I suppose one could create an invisible and non-colliding "dummy" entity that consumes power in place of the real one, but again, complicated and inelegant. A simple implementation could be that if electricity use is not specified in the prototype definition, no electricity is consumed (kind of like fluidboxes). Perhaps a new parent/child placement near entitywithhealth called entitywithpower or a modification of entitywithhealth to include electricity.
I'm relatively new to modding factorio, and I'm only one person, so these requests may not carry much weight, but I'm certain that at least a few mods would exist were even one of these things implemented.
