Factorio Forums

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 functions

Implement (in C), the following functions and expose them to the lua environment (most of these are from WoW):

1. 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
2. newstr = strtrim(str[, chars]), where |chars| is a string with characters to trim, defaults to \t\r\n
3. joinedstr = strjoin(delimiter, str, str,...)
4. 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
5. table = table.wipe(table) / tbl:wipe
6. table.contains(tbl, value) / tbl:contains
7. maybe put this in the global scope like serpent; https://github.com/kikito/semver.lua/bl ... semver.lua (or similar)

And yes, I know most of the above can be done easily (though some are actually not easy) in Lua. That's not the point.

2. GUI stuff

1. 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)
2. 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
3. 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.
4. Some way to add text on top of a spritebutton (more specifically, lower right on a sprite button, like the inventory slots).
5. Dont show any labels in the blueprint library on the right side, only show the icons
6. 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.
7. 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)

3. Other

1. For http://lua-api.factorio.com/latest/LuaB ... aise_event please allow varargs as input, so script.raise_event(id, ...)
2. 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)
3. 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
4. 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
5. Make it possible to clear a keyboard shortcut, so that it's "Not set" or whatever
6. At the same time, allow "" or something on a custom-input to be "Not set" by default
7. 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.
8. 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.
9. Require locale strings to be scoped (that is to say, have a [header]), and error if they do not
10. 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
11. Ability to add - at runtime - PNG masks or color tints to luaentities and units (and yes, I'm aware of the stickers)
12. 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
13. Make sure defines.group_state.finished is actually applied to a luaunitgroups state when it should be in all cases
14. 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()
15. Add a LuaForce method call that returns all existing luaunitgroups
16. Implement table.deepcopy and other dataloader stuff in C, because mods are getting big and numerous

Shhh keep this a secret but you might find it useful to check out this set of instructions for posting ideas too I'd hate for some of these to get lost because you've done a batch upload

My Factorio fantasy is to be stranded alone on my very own planet, just like in the game. I think I prefer biters above my own daily responsibilities.

JohnyDL wrote:Shhh keep this a secret but you might find it useful to check out this set of instructions for posting ideas too I'd hate for some of these to get lost because you've done a batch upload

I failed! Thank you, I guess the thread will just be removed.

I don't think you've failed and I don't think it'll just get deleted you've got some very useful suggestions but because they're all ontop of one another discussing them is a bit difficult

Take the 'Make it possible to clear a keyboard shortcut, so that it's "Not set" or whatever' this would be an awesome idea when you've got several different mods all vying for the same shortcut and you just want to re build them all from scratch, something probably a lot of people might want, I want it in vanilla to remove my ability to craft totally while I'm going for the lazy achievement. Not just a different key that I could press by accident a pet could by jumping on the keyboard, but then locked behind options and mouse movements. But it's hidden as number 5 in other way down the list and anyone looking at your list of suggestions could easily overlook it because they've read the Lua functions and gone 'this is beyond my experience to comment on'.

And the thing about being able to show or hide or even change the way the blueprint menu is laid out to personal preference would be great, personally I'd like to see it use the standard windows interface so I can either look at a bunch of icons or I can look at a bunch of names in a list or even better details and be able to sort them by name, by size, area, machine count, author (oh I'd love for that to be implemented into blueprints so you can exchange blueprints but the originator gets credit) and more renaming being as simple as F2 or a second click and rearranging them be the same as files in explorer. Then when I want to play not organise back to giant icon mode.

Search tabbing to complete and then enter to select is another useful thing that could be applied not only to assemblers but to the research tab and a bunch of other places but we can't discuss that and really hash out where it'd be useful now without adding a third discussion into the mix and it's starting to sound a bit like noise, and without lots of quoting how can we keep track of the various discussions, and who wants to read a bunch of quoting over and over anyway.

On the other hand a bunch of Lua functions added to prototypes or extra libraries that could be invoked without having those same libraries needing to be repeatedly included inside different mods would probably work well as a single post, because they're all with the purpose of making the mod coding a bunch easier and though implementing one might not be helpful as an aggregated idea the thing functions well together, although the whys for each need a bit more explaining for me to understand them

JohnyDL wrote:I don't think you've failed and I don't think it'll just get deleted you've got some very useful suggestions but because they're all ontop of one another discussing them is a bit difficult

I have. The post (that I should have read before posting this thread) informs me that I have failed.

From my perspective there is nothing to discuss, the ideas can either be implemented or not. If any of the ideas are ambigous in any way, that's another failure on my part. Then I would need to explain what I meant, specifically. That's not a discussion.

But if you do, simply referring to the item number is sufficient to clarify which part you're referring to.
1.3, 2.2, or 3.10, for example.
Or just selectively quote it. I fail to see the problem.

In any case it's not worth talking about since the thread will either be removed or ignored completely.

JohnyDL wrote:Take the 'Make it possible to clear a keyboard shortcut, so that it's "Not set" or whatever' this would be an awesome idea

Thank you. Besides being awesome, it's also 100% standard for games to allow keybindings to be unset.

JohnyDL wrote:And the thing about being able to show or hide or even change the way the blueprint menu is laid out to personal preference

Everything is a personal preference, this is what the most recent FFF was about. Their in-house interface designer would simply take my idea and do whatever he wants.

JohnyDL wrote:Search tabbing to complete

I never mentioned or asked for tabbing to complete, and would oppose it aggressively.

0.b Your suggestion is from a forum member to the forum members
If the developers find your suggestion good, they will use it.

If not, you have to convince the forum members. Not the devs!

Explaining and discussing the ideas and getting people on board helps. You can't keep track of who's on board with what ideas in a monster post like this. You can if you wanted break up your post into new ones, that's what I'd suggest if not I'm going to take the ones I like and think people will like to discuss and do threads on them myself. I'm not trying to be mean I'm trying to be helpful. I'm giving you some feedback to encourage you to try again I think you took the 'you fail' joke in that post a little too seriously, you just learned one way not to make a suggestion thread

JohnyDL wrote:Explaining and discussing the ideas and getting people on board helps.

It does? I would assume and hope it has little or no impact.
Design-by-forum-committee is traditionally a horrible approach to game design. It's what reduced the number of active WoW players from 12 million to 5, after Blizzard started listening to the crybabies on the forums.

But I can certainly make individual posts for each item in my list.

I'd really like to know if it's worth the effort first, and that it won't annoy anyone - because it seems to me such a number of threads should be considered spam, especially when most of the ideas are tiny ones.

The game isn't designed by committee there is no guarantee that an idea once posted will get implemented but the reason it's not just a mailbox you dump your ideas in and walk away from is that by making useful posts with some discussion and ideas added which other can critique and then fleshed out is far more useful to the devs. The reasons why and the discussions about why a change is wanted more than what and how the change you want is implemented, lets the developers get a feel for how useful the suggestion is, there's maybe 20-30 people who seem to have actively posted on this forum over the past week, if you can convince every one of those people that an idea is a good one, with all their different wants and desires and thoughts about the game that shows your idea has legs and it might be useful in more than a one off case. And by posting and getting discussion the post stays on the top page for longer and it's far more likely to be seen by people who do things like make mods, and believe it or not a working implementation of a tiny but useful idea is worth 1,000,000x more to the devs than the best possible description of the best possible addition to the game that anyone could come up with ever. (source: this sticky viewtopic.php?f=6&t=30240 )

Like I said above there are some ideas up there that deserve a post each because they are completely different from everything else that's in the post, but all the Lua changes, because they all have the same reasoning, could be lumped under one heading "Improvements to the game code to allow easier Modding" and then explain what each of the little useful bits of code are and what it does and why exactly that would add to the ability to make mods. Including where you'd find it really useful in your own code would also help, as abstract ideas that generally improve modding they're one thing but if you can show that there's a genuine use case for them and how you get round them being missing and what problems and bugs that causes that's a huge pile of reasons for them to be added.

And 2 of the biggest points from that first guide I linked that apply to you

-1. Every rule has it's exception!
This is a guide, no law. If you have a good reason, then break the rule; nobody will cry.

You have a very good reason to bundle some of your ideas together so break that rule as far as I can tell they're in effect only one suggestion. But for the others make separate posts.

It is easy to write a subject like "I have some idea" and plug all your thoughts in it. It is more difficult, to part that into several posts. And the best would be to find already existing threads and just add your thoughts.

And that is as best as I can tell an excuse if you wanted to to give every single point it's own topic mod approved too.

I'm gonna also suggest using the template here viewtopic.php?f=6&t=47316 to make your suggestions, you will get sick of reading it I promise but hey might as well lead by example we've had a lot more 'bad' posts on here recently than just yours according to Ssilk (like 3* as many as a while ago) so you could swing that back the way of good stuff just think carefully is it something that you think is easily paired with another idea or is it a separate idea entirely and should have it's own post you can't get it wrong

JohnyDL wrote:... by making useful posts with some discussion and ideas added which other can critique and then fleshed out is far more useful to the devs. The reasons why and the discussions about why a change is wanted more than what and how the change you want is implemented, lets the developers get a feel for how useful the suggestion is, there's maybe 20-30 people who seem to have actively posted on this forum over the past week, if you can convince every one of those people that an idea is a good one, with all their different wants and desires and thoughts about the game that shows your idea has legs and it might be useful in more than a one off case.

This is completely counter-intuitive to me. It has certainly never been the case on any project I've worked on for any entity. It has always been a dictatorship that randomly receives input and might or might not act on it - depending on whatever factor the dictator wants to weight, but mostly monetary.

I presume that a developer will simply read my initial post and do what he wills based on his initial gut-reaction to reading it, regardless of what any forum member posts below. Either the idea has instant merit to allow for further internal/inhouse mulling over, or it doesn't.

But, you have convinced me that this developer (Wube) thinks otherwise, or at least imagine that they function otherwise, so there is no need to talk further on this point. And in fact, you already had convinced me before this last post.

Also, by engaging in such lengthy replies, you've convinced me that my ideas have enough merit for me to produce the effort require to author such posts. But it might be that I falsely equivalate attention with merit.

And also, if I was the one who had to read the forum, someone spamming it with 20 posts would annoy me. I'm not convinced that doing that won't have a negative effect; and if it did, it would go contrary to someone reading the ideas in a neutral context, which would impact their gut reaction to them.

That last paragraph is important, because it is certainly how I would react to such an influx of posts. I would personally favor reading the kind of post I made here - which is why I made it - for the kinds of ideas that I've proposed. There's maybe a few of them that deserve their own threads.

The only way to alleviate such a concern would be for me to throttle the posts over a period of weeks or months. Which is way more effort than I am willing to put into it.

I'm prepared to simply state that my post is the exception that proves the rule. With the exception of maybe a handful of the ideas proposed, that merit individual posts.
However, I'm also prepared to make individual posts for each idea, even though I don't like it.

Okay, well there's merit in sticking around but if you don't want to then don't (2 posts a day for a week would get a decent number of these done without overload but that's up to you) if you want to get it all done today and walk away I'd focus on doing individual ones for 2.5, 2.7 (with 2.6 where I thought the tab to complete would be a part of it) 3.4 (though I'll readily admit that's to satisfy my own curiosity over what exactly it means and how and why it'd work if it's what I imagine that could be super useful), 3.5 (with 3.6), 3.8 (though how do you move without a keyboard? are you suggesting controller, that'd be interesting to play using bumpers to scroll your toolbar triggers to interact, a mouse controlling stick and a movement controlling stick). Then you could leave this discussion as the combined everything else, that's 5 new posts not 20.

JohnyDL wrote:3.8 (though how do you move without a keyboard?

Haha, thank you, that's an excellent point, I should have listed that among the most obvious things that need to be remedied immediately

I'm just going to wait and see if there are any official responses to this post in the first days of the coming week, and react accordingly.

Alright, so since there has been no response and I'm stuck on my laptop for the immediate future, I'll go ahead and post some of these individually.

No post is deleted, cause it's just not fitting. But cause that's are mainly modding issues I move it to modding suggestions.

And in for about half of the points I don't understand the "why". That's important, cause that's the base of good discussion.

folk wrote: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)

The base game GUIs aren't lua GUIs. They are far more complex and are almost certnaly never going to be exposed to Lua to read or modify as they contain non-game-state data. For instance this is less than half of the train GUI: http://i.imgur.com/zsZFsP1.png with the full thing spanning multiple classes and files.

folk wrote:For http://lua-api.factorio.com/latest/LuaB ... aise_event please allow varargs as input, so script.raise_event(id, ...)

There's no point in doing that. Put the args in a table and pass that instead.

folk wrote: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.

Factorio requries a keyboard and mouse. If you don't have both then your configuration is not supported.

folk wrote:Require locale strings to be scoped (that is to say, have a [header]), and error if they do not

That's invalid. Locale strings require no scope.

folk wrote:Ability to add - at runtime - PNG masks or color tints to luaentities and units (and yes, I'm aware of the stickers)

Every runtime option we add has to be saved in the map file and handled for every entity. We're not going to add this into the base game and bloat save files, RAM usage, and performance for the 99%+ case where it's not used.

folk wrote: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

Units and unit groups are first and formost designed to work how the base game uses them. The Lua API was created to make the trailer and has had some minor patching to fix bugs but it was never designed to do what you're trying to do - that's outside the scope of what they're designed for.

folk wrote: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()

The cursor position is not part of the game state. If it was, every game tick we would have to record the real mouse position and send it as a player action into the game effectivly acting like you're perpetually holding a key down and listen to it repeat every game tick. It would add a ton of overhead that would go virtually unused 99%+ of the time.

folk wrote:Implement table.deepcopy and other dataloader stuff in C, because mods are getting big and numerous

You don't appear to understand how programming works... also Factorio is written in C++ not C. "copy a lua table in C++" is literally the same overhead as copying it in Lua just done through the C++ API. The exact same code would get executed.