Folks Factorio Wishlist (mostly modding related, but not entirely)I am going to update this list as we go along, when I feel like it. And when I do, I will make a new post in the thread and clearly mark the entries that have been added.
Devs, if you can tell me which ones are definitely NOT going to be done, ever, I will simply strike them out / remove them to clear up the list. Hopefully that won't be many
1. Lua functionsImplement (in C), the following functions and expose them to the lua environment (most of these are from WoW):
- s1, s2, s3 ... sn = strsplit("delimiter", "subject"[, pieces]), where |pieces| is the max number of pieces to return, and anything beyond that is returned as the last piece
- newstr = strtrim(str[, chars]), where |chars| is a string with characters to trim, defaults to \t\r\n
- joinedstr = strjoin(delimiter, str, str,...)
- seterrorhandler(func), that would allow us to trap errors without them propagating to the game engine, but probably not for the purpose you're assuming when reading this
- table = table.wipe(table) / tbl:wipe
- table.contains(tbl, value) / tbl:contains
- maybe put this in the global scope like serpent; https://github.com/kikito/semver.lua/bl ... semver.lua (or similar)
2. GUI stuff
- Expose the entire vanilla luagui to the addon context, so that we can anchor custom frames to them (anchor buttons to the top of the quickbar, and so forth)
- Add new button type that is basically a luainventory with 1 (at least) slot that the player can pick an item from, and have events trigger properly like a standard inventory. Basically an interactive sprite button
- Allow us to hook into the tooltip display to add/remove text or whatever. And by "tooltip" I mean both the box that shows on the right side below the minimap, AND the tooltip when you hover UI elements.
- Some way to add text on top of a spritebutton (more specifically, lower right on a sprite button, like the inventory slots).
- Dont show any labels in the blueprint library on the right side, only show the icons
- When keyboard-filtering in the interface (like typing to find recipe, etc), first of all fix spaces, but also allow multi-word filtering like in my folk-shuttle mod filter box. But frankly the most powerful way to filter input is the way vscode does it for the command palette, where it matches input to the first letter (case-insensitive, of course) of each word of a command, so "wtm" matches "will this match?". It's the quickest way of filtering by user input I've ever seen.
- When keyboard-filtering an assembler recipe, hitting Enter should apply the recipe in the top left position (or at least if there is only one result remaining, apply that one)
- For http://lua-api.factorio.com/latest/LuaB ... aise_event please allow varargs as input, so script.raise_event(id, ...)
- Add a new dependency type to the info.json file; library_dependencies (or required_deps, whatever), that would be forcefully downloaded alongside the mod by the game, and if users downloaded manually through the portal, the game would keep the mod in a forcefully disabled state until the user either installed the library zip manually, or hit "Update" in the mods window. The required_deps field would ideally explicitly require a semver per entry, and the game would not allow you to play with conflicting library versions. (like https://docs.npmjs.com/files/package.json#dependencies - I would say ^version is the most important one)
- More granular control of where exactly recipes/items should show up ingame; specifically, I want to be able to hide recipes from the player but have them show up in an assembler-type entities interface
- Allow recipes to require a virtual signal "item" in an ingredient slot, either picked by the player or a fixed one from the recipe-prototype
- Make it possible to clear a keyboard shortcut, so that it's "Not set" or whatever
- At the same time, allow "" or something on a custom-input to be "Not set" by default
- Remove "script-only" and "all" consuming on custom inputs. Mods should never do that. Not least because it's theoretically impossible for a mod to determine which order it has in the consuming chain, so it's entirely useless to presume that you'll be first in line and able to consume at all.
- As Factorio developers, try playing the game without a keyboard. There's a few obvious things you should add immediately; the ability to open the game menu and the player inventory with the mouse. There's way more things missing, but those are the worst offenders.
- Require locale strings to be scoped (that is to say, have a [header]), and error if they do not
- Warn mod developers (determined by if they are using unzipped mods?) if they are polluting the global data-scope or setting-scope, at least in stdout, to minimize potential foolery where players say "this isn't working" to a mod dev, and dont provide the mod dev with a list of their installed addons
- Ability to add - at runtime - PNG masks or color tints to luaentities and units (and yes, I'm aware of the stickers)
- Persistent (that means they exist forever, even with zero members, until you do .destroy() on them) LuaUnitGroups that do not magically disappear, and that don't randomly remove units
- Make sure defines.group_state.finished is actually applied to a luaunitgroups state when it should be in all cases
- I don't understand how you can provide a selection-tool item, but not a way for mods to read the player cursor (tile x/y, not actual position) position (which could obviously be on a different luasurface, or not on a luasurface in which case it should return nil). If one desyncs, then both should. So the API should be something like: local LuaTile, LuaSurface = LuaPlayer:get_cursor()
- Add a LuaForce method call that returns all existing luaunitgroups
- Implement table.deepcopy and other dataloader stuff in C, because mods are getting big and numerous