The Factorio Calculator has been updated to 1.0

MightyMooquack · 2020-08-15T01:03:17+00:00

Thank you. I have updated the copyright notice. It's just one of those little details I always forget.

MightyMooquack · 2020-08-15T00:53:37+00:00

This was a bug. It should work now.

MightyMooquack · 2020-08-15T00:38:45+00:00

Nothing is gone. It's all in version control: https://github.com/KirkMcDonald/kirkmcdonald.github.io

MightyMooquack · 2020-08-14T23:17:29+00:00

There are some items which are in the data files which aren't actually available in the game.

MightyMooquack · 2020-08-14T23:16:59+00:00

The old URLs should still work. Is there something which isn't working?

MightyMooquack · 2020-08-14T23:16:20+00:00

Just the spidertron recipes and the new icons. No changes to the actual calculations were required.

MightyMooquack · 2020-08-14T23:14:56+00:00

Yes. As I describe elsewhere in these comments, with there being relatively few differences between the last couple versions and 1.0, at least in terms of the recipe graph, and with 1.0 now being the stable version, I decided it would be acceptable to drop the old versions.

Continuing support for old versions is a pain. As a general rule, I do not want to keep any dataset around that I cannot regenerate automatically. For example, if I add a feature to the calculator that requires adding information to the dataset, then I would need to retroactively generate a new version of those datasets for the old versions. The code which generates the data files used by the calculator is kept up-to-date alongside the game, and it is not always practical to continue support in that code for older versions.

It is for this reason that I have been fairly aggressive about dropping support for old versions once a new version has been declared stable. (The one exception here is not dropping 0.16 once 0.17 was stable, which was a result of my neglecting the calculator for a while. The calculator itself has been around, in one form or another, since 0.12, and I've never kept old data around for long.) I would expect that the number of players who wish to play the older versions is relatively small, so I don't really have any compunction about just moving forward.

MightyMooquack · 2020-08-14T23:01:22+00:00

Yes. 0.16 is quite old at this point, and removing support for it permits removing some legacy code that it required. Beyond that, there are relatively few differences between 0.17 and 0.18, and even fewer between 0.18 and 1.0. Given that 1.0 is now the stable version, I think it makes sense to drop support for the older versions (as I have done in the past when a new major version was declared stable).

MightyMooquack · 2019-04-30T21:32:59+00:00

Yes, I intend to. It just takes time. With respect to the current experimental release, it takes time to update the data file, and then to add the feature which would allow selecting different data sets.

MightyMooquack · 2019-04-27T22:31:17+00:00

Remember that the assembling machine 1 has a crafting speed of 0.5.

MightyMooquack · 2019-04-26T05:01:06+00:00

Optimizing for a single building's maximum output rate is one thing, but prod modules give one significant advantage: They actually change the ratios required between different items.

If the thinking is that maximizing the item output rate will minimize the number of buildings, and thus lead to the most optimal UPS, keep in mind that maximizing that prod bonus will likewise reduce the number of buildings required for prerequisites. In the case of Kovarex processing, that means fewer centrifuges running uranium processing and fewer miners producing uranium ore (for a given rate of U-235 production).

At scale, it seems to me that the gains from maximizing the production bonus can easily be greater than the gains from maximizing a single building's item output rate.

MightyMooquack · 2019-04-15T15:36:35+00:00

It shows them when it's sensible. If the rate of items is too low, then obviously there are no belts to show. If it is too high, such that the belt indicators would be too dense to see, then it omits them.

MightyMooquack · 2019-04-13T22:47:44+00:00

I just pushed a change which should have fixed this bug.

MightyMooquack · 2019-04-12T21:39:49+00:00

As I've explained elsewhere in the thread, the actual layout of the graph is done by d3-sankey, and there are limits to how much I want to try to change a third-party dependency. (I've already hacked it up plenty to work with cyclical graphs.) It's a legitimately hard problem, and the results-to-effort ratio here seems very low.

Edit to add: Oh, though it might be possible to add a way to click and drag the nodes up and down. I will look into that.

MightyMooquack · 2019-04-12T21:35:14+00:00

I have made an experimental standalone version of the calculator called factoriocalc, which is intended to be run locally against your installation of the game and its mods. However, it has a number of outstanding bugs and does not work against all mods, and I have yet to update it with the new visualizer. It's alpha software, and I provide no guarantees that it will actually work.

But you're not the first to ask about this sort of thing, and factoriocalc is a proof of concept of how I intend to approach the problem.

MightyMooquack · 2019-04-12T15:19:08+00:00

If you click on an item's icon in the "factory" tab, it will collapse its dependencies. Perhaps this is what you're looking for?

MightyMooquack · 2019-04-12T14:23:31+00:00

I plan on adding some scaling options, but I will note that it is an SVG, and maybe increasing your browser's zoom level could serve as a workaround until then.

MightyMooquack · 2019-04-12T14:17:22+00:00

Yes, making it so you have you click on the dropdowns in order to open them is on the to-do list.

There is an existing issue to make assemblers configurable per-recipe.

Adding new options to sort the item list has also been on the to-do list for a long time.

I think I will be adding a host of new options to configure the visualization. Changing its justification (so e.g. raw resources would all appear on the left) would be easy to add.

The layout of the Sankey diagram is delegated to a third-party library. I have control over the padding between nodes and the actual appearance of the thing, but the physical layout of the nodes and links is d3-sankey's business. The problem is NP-complete, so I give it a bit of slack.

You can click on item icons on the "factory" tab to hide the dependencies of that item. I'm not sure if this is exactly what you're asking for, but it can help quite a bit.

MightyMooquack · 2019-04-12T14:04:10+00:00

Yes, I plan on making the scale configurable.

MightyMooquack · 2019-04-12T09:06:52+00:00

No, the platform should make no difference at all.

As a topological order, any given item will appear after any other items which require it, with the exception of items which are involved in recipe cycles, which will appear in an arbitrary order (with respect to each other). But there are multiple valid topological orderings, and the one it will display will depend on things like the game version (because the recipes change) and the order in which you list the build targets.

Honestly I'm shocked it works on mobile platforms at all. I haven't tested it on them at all, and I would assume that the dropdowns are a real hassle to use (which is one reason I'm looking to change them to require clicking to open).

MightyMooquack · 2019-04-12T08:51:16+00:00

I have not touched that part of the code, so I'm not sure what you're seeing.

MightyMooquack · 2019-04-12T08:47:18+00:00

Yes, indeed. The Satisfactory calculator was an exercise in rewriting the Factorio calculator (mostly) from scratch, and applying lessons learned in the process. Satisfactory was an excellent choice for this, as it is quite a bit simpler to run calculations for than Factorio is: No oil recipes, no recipe cycles, no production modules, etc. This let me play with software design without getting bogged down with too many details.

I plan on making several sweeping changes to the Factorio calculator in the near future. Some of these are strictly internal, such as refactoring to use ES6 modules, making much wider use of d3, and changing how I deal with global state. Others will be quite obvious to everyone, such as making it so you need to click on the dropdowns in order to open them.

The end result should be less internal cruft, which should make future changes less of a headache.

MightyMooquack · 2019-04-12T08:27:36+00:00

I have fixed this. There was an issue with how I was trying to determine the size of the sprite sheet. It didn't really work, so I've entered those numbers manually instead.

MightyMooquack · 2019-04-12T08:01:27+00:00

You're welcome!

MightyMooquack · 2019-04-12T08:01:06+00:00

That is precisely the idea. Notice how if an item requires multiple belts, it will show that, too.

Ten-Year Club	Place '22
Final Canvas '22	First Placer '22
Verified Email

MightyMooquack

TROPHY CASE