Actually two suggestions but lets not clutter the board:
1) Make 'icon' token behave like rest of graphical tokens, i.e. accept a table of layers instead of filename. The game seems to already use overlaying for generating bullet upgrade icons for example.
2) Provide function to write files inside mod's root directory. To a limited extent data can be generated with lua already. However, locale for that data can not.
Also, generation of new data entities based on the game progress might be handy as well.
Procedural mod generation
Procedural mod generation
I do mods. Modding wiki is friend, it teaches how to mod. Api docs is friend too...
I also update mods, some of them even work.
Recently I did a mod tutorial.
I also update mods, some of them even work.
Recently I did a mod tutorial.
Re: Procedural mod generation
The second one I love.Adil wrote:Actually two suggestions but lets not clutter the board:
1) Make 'icon' token behave like rest of graphical tokens, i.e. accept a table of layers instead of filename. The game seems to already use overlaying for generating bullet upgrade icons for example.
2) Provide function to write files inside mod's root directory. To a limited extent data can be generated with lua already. However, locale for that data can not.
Also, generation of new data entities based on the game progress might be handy as well.
I have afew mods that pass in one item with the list of changes per level and outcome 20 entities, items, techs, and recipes! (can be anything like 100), being able to dynamically make locale and images for entities/icons would be amazing because my locale file looks something like:
Code: Select all
level1: thing x1
level2: thing x2
...
level20: thing x20
Will code for Food. I also have 11+ mods!
Re: Procedural mod generation
For 1: you can already define "icons" for layered icons: see how barreling does it.
For 2: this isn't likely to ever happen. It breaks determinism since running code A, saving, and loading would not be the same as just keeping running A. This determinism is a requirement for Factorios multiplayer logic to function.
For 2: this isn't likely to ever happen. It breaks determinism since running code A, saving, and loading would not be the same as just keeping running A. This determinism is a requirement for Factorios multiplayer logic to function.
If you want to get ahold of me I'm almost always on Discord.