1. Generates an analysis of each recipe into its component parts, and delivers insight into the balance and progression of a mod.
2. Allows for easy editing of item, recipe, building, technology properties.
3. Allows those edits to be easily exported into lua files, creating compatibility between various mods. Or at least assisting in making that compatibility happen.
This is a literate script. The source code is embedded in these code blocks, and tangled into the script using org-babel. This allows me to write a description of what I want to do, and comment on it without resorting to ~// /* */~ ugly comments.
If you open this org file raw (e.g. by clicking [[https://git.bajsicki.com/phil/factorio-recipe-analyzer/raw/branch/main/README.org][here]]), you will see that there are a number of different blocks.
There is a rough overview of the structure:
#+begin_example
,#+name: Name of the following source block.
,#+begin_src lang :tangle file.name
[code goes here]
,#+end_src
#+end_example
~:tangle~ defines the file into which the code block will be passed to ~org-babel-tangle~. To disable, pass ~no~.
In the begging of the file, we can set global (in the scope of the file) properties, such as the default target for ~:tangle~:
~#+PROPERTY: header-args :tangle no~
The easiest way to generate outputs from here is to open this file in Emacs, and run ~M-x org-babel-tangle~. If you're using [[https://github.com/doomemacs/doomemacs][Doom Emacs]], the default key binding is ~C-c C-v C-t~.
*Important note:* the files in ~./data~ are working files. They're not intrinsic parts of the script. Everything you need should ideally be contained within this one single .org file.
However, inevitably, since we're dealing with external data, there are some...
** Dependencies
1. Hard dependenciens:
1. Factorio. Obviously. You need version at least 1.1.87, since that added the ~--dump-data~ argument, which we use.
2. Perl > 5.14, for JSON::PP and Data::Dumper.
2. Soft (useful) dependencies:
1. Emacs, org-mode, org-babel. These make the workflow much easier, however you don't need these; they only save time.
2. sh so you can execute the following from within Emacs.
3. GNU coreutils (cp, mv). These aren't hard depends, since you can move the files manually. This is so you can just ~C-c C-c~ over the code blocks.
* License
I don't own the source csv files generated by Factorio, nor the mods the script is pulling from. This script itself is GPLv3, with the exception of third-party libraries licensed otherwise.
***** TODO: include GPLv3 in the repo
** Credits:
The following are mods from which .csv files have been generated. The recipe .csv files are included in the ~data~ directory.
The .csv files used as input are generated in Factorio, by loading a new game with only ~base~ and your chosen mod enabled, and running one of the following Lua scripts from the console:
** Export all recipes and ingredients that match whitelist
Create an org-mode file with all the calculations included, and complete, for a clear overview of recipe progression, subgroups, item inputs and outputs, and total cost.
For this, we'll likely want to include some metadata, like creation date, mod name, number of ingredients, maybe the total amount of raw mats needed to make one of everything?
2. Find (next) ingredient lines in this product section.
3. Pass the product and each direct input item and its number to ~raw-ingredients~. /(We can distinguish direct inputs from raw ingredients easily because org-mode supports multiple characters for defining lists. So we can just look for lines beginning with ~-~ and not really think about anything else.)/
This is not for analysis as much as helping Galdoc out with creating compat layers for [[https://github.com/Orion351/galdocs_manufacturing][Galdoc's Manufacturing.]]
This structure allows for unambiguous selection of the relevant data from the csv file, for the following reasons:
1. Amounts and categories are paired by the matching number at the end of the column name.
2. These cannot be confused with the amounts themselves, because the column names include [a-zA-Z] characters.
3. The first column makes it easy to find whether an item belongs to a particular column or not.
4. Additionally, this way we can automate creating the output .csv template, since we can check what number of columns we need for each ingredient category.
- One line per product, each product getting its own copy of all the recipes that make it (gg slag).
- Each product gets assigned a clear category. No issues, no conflicts.
- Problem: differing amounts between the recipes, so amounts need to be stated in a sep. column.
- If we use an unusual separator symbol for fields with more than one value (e.g. long lists of ingredients), we can then parse them very easily and remove ambiguity with a simple [whitespace, comma or +] test. Then situations like 'tin' being found in 'tinned wire' won't be a problem.
/Note:/ If you have this open in Emacs, move your cursor into the code block and hit ~C-c C-c~ to execute the code. It's very handy if you have commands that you use often.
From here on, all changes will take place on the basis of the ~intermediate.csv~ file, and outputs will be directed to ~output.csv~. This will prevent time loss in case of a mistyped command.
At the same time, we have 2843 entries to deal with. That's a lot, so let's start with the raw ingredients, and assign those using the following rough rules:
For this reason, it is important that we first cover the base materials.
1. If the item exists in vanilla as a raw ingredient, it should be treated as such in the compatibility layer as well. If it is made craftable by a mod, its ingredients must also be tagged as raw materials.
2. The ingredient in question may not have a recipe of its own. E.g. iron ore in vanilla Factorio, or stiratite in AngelBob. In this case, it is a raw ingredient.
- *The key problem:* it would be very challenging for a human/ person to make modifications to this export as-is. It's then necessary to create another layer of processing to make the output human-readable.
- ON the other hand, we don't yet have a system for importing recipes, items, and tech levels from a csv into Factorio mods...
- That may be something to explore to better define the constraints on this project.
E.g. If it were possible to build the Lua files programmatically from user-created CSVs... Factorio modding would become significantly more accessible and easy for a ton of people. Of course, this would not be as powerful as diving into the code, however... I do see potential here with regards to large overhaul mods.
Imagine:
1. Export factorio base to csv.
2. Change csv however you like, adding items, changing values, adding recipes, technologies, etc.
3. Run a script which compiles your csv into a mod
4. Have your mod running.
There are several issues which bear addressing:
1. Icons - in the case of a lack of icons, the script should default to something, so the GUI isn't broken.
2. The script would have to dynamically generate a lot of lua code, or at least wrap the contents of the CSV in lua code. This may create licensing issues? Maybe?
3. The item descriptions could be generated (partially) automatically, but they would still require someone to write large parts of them.
4. Localization; it may be possible to also do with the script (eg hooking into google translate, deepl or sth), at least for the item names.
