kirkmcdonald / kirkmcdonald.github.io Goto Github PK

The furnace used for smelting recipes should be configurable. It is currently hard-coded to the electric furnace.

Factorio 0.15 added a marathon mode, which changes the requirements of essentially every recipe in the game. The calculator should support this as an alternate dataset.

This will allow showing edges in the graph for the requested items.

The calculation appears to ignore the production bonus when calculating the factory count.

https://kirkmcdonald.github.io/calc.html#tab=graph&rate=s&min=2&furnace=steel-furnace&mprod=16&items=high-tech-science-pack:f:7
The number of copper cables is wrong. It equals their copper plates input but should be multiplied by 2.
It's ok in lower branches of graph and in Items tab. Incorrect in Factories tab.

Rocket parts are currently treated as being built in an assembling-machine-2 (or assembling-machine-3). They should be constructed in a rocket silo (crafting speed 1) instead.

At the moment, used-up-uranium-fuel cells are considered to be a resource, as they don't appear to come from anywhere, but can be used as an ingredient to obtain U-238. This throws off any recipe that uses uranium products.

The proper solution may be to add a pseudo-recipe that can stand in for a nuclear reactor, consuming fuel cells and yielding used fuel cells plus a pseudo-item representing the operation of the reactor.

Currently, ignoring a recipe in a subgroup (e.g. advanced-oil-processing) is a no-op. Either the UI should be disabled for such recipes, or it should ignore the entire subgroup.

The nature of such groups means that just ignoring one recipe in the group makes no sense. The recipes depend on one another, at least to some extent, and teasing them apart may be impractical.

The visual look could desperately use an overhaul. A Reddit commentor graciously provided this example: https://i.imgur.com/KjeMuIj.png

Add datasets for various popular mods, with checkboxes to enable/disable their items and recipes.

It would be nice to be able to calculate the required amount of blue belts.

It would be very useful to be able to ignore specific recipes when computing the requirements of things that depend on them.

For example, when creating advanced circuits, it is common for electronic circuits to be made elsewhere, in a centralized location. It would be useful to be able to see the copper cable requirements of the advanced circuit factories specifically, without also folding in the requirements of the electronic circuit factories.

Instead of a big drop-down, use a grid of icons, aping the in-game one, to select items.

If an item is produced by multiple recipes, the visualization will show the wrong rate for it.

Recalculating the solution is rather slow, and happens in response to quite a lot of UI events. There are ample opportunities for making the solution faster, and there are certain cases which cause a recalculation which do not need to. (E.g. changing a speed effect without changing a prod effect, which requires a redisplay of factory counts but not a new solution.)

The main avenue for optimizing the solution comes from pruning the possible solutions in the MatrixSolver. At the moment, it will always trawl through all 70 possible solutions to the oil matrix. This is unnecessary, and I expect that it should be possible to cut the number of possibilities down to less than 10, which should give a significant increase in UI responsiveness.

Beacons don't work with machines that don't support modules. The calculator shouldn't render the beacon UI in such a case, nor should the "copy to all recipes" button affect such recipes.

If an item with multiple recipes is used as a build target, the build target will arbitrarily use that item's "first" recipe to convert between its number of factories and its rate.

This actually works reasonably well. Solid fuel is provided by three recipes, which all have the same yield and work in the same sort of factory. Barring modules, this yields fairly good results, and the result will be split among the three recipes such that their factories will all sum up to the requested number.

On the other hand, for something like petroleum gas, it will convert a factory count into a target rate more-or-less arbitrarily, based on the yield of whatever its "first" recipe is.

There are two odd cases here, which should probably be handled differently:

1. Entering a factory count gives an arbitrary rate. I think this is fine, and in the case of solid fuel, useful.
2. Entering a rate gives an arbitrary factory count. This makes no sense and provides no benefit, and it should probably indicate this with a question mark or something.

Bob's (plus Angel's ores, and maybe some other mods) significantly expands the recipe graph, and poses a significantly greater challenge for modeling than the vanilla game does. Investigate how far this calculator can get when the Bob's data is thrown at it, and how much work it would take to make it a practical tool.

The calculator should probably omit them from the power usage feature. Alternatively, the calculator should track their fuel consumption, with an option to select the fuel type.

Now that the calculator can track electricity usage, a "Power" tab should be added to break down how many of each component would be required to power such a factory, for each of the different sorts of power plants.

It would probably be useful if this tab had a box where an arbitrary amount of additional power could be added to the computed amount. It might also be useful to provide an estimate for the power usage of inserters, etc, but such numbers would necessarily be an educated guess at best. These numbers also tend to be quite trivial compared to the rest of the factory, and could probably be easily ignored.

Power estimates also do not include the power requirements of beacons, which can be quite substantial, but naively multiplying the power needs of a single beacon by the number of beacons implied by the calculator's settings would be the wrong approach: Most factory designs will, as a rule, attempt to spread a single beacon's effect to as many entities as possible, rendering the actual number of beacons in play difficult to estimate from the calculator's settings alone. A dedicated "number of beacons" box might be a useful feature.

The number of entities required is entirely trivial to compute for solar power, though the exact arithmetic is slightly annoying to derive. (12500 ticks full bright, 5000 ticks dusk, 2500 ticks full dark, 5000 ticks dawn. Dawn and dusk are a simple linear rise/drop in light levels. The rest is computing how much excess solar capacity is required during the day, and the quantity of accumulator capacity that is needed to store it for use at night. These numbers are a flat multiple of the required power level, and it may be simplest to hard-code that multiple.)

These numbers are even more trivial for steam power (at least ideally; the actual fluid mechanics of the game might introduce some loss), and it would be useful to provide a number for the rate of fuel consumption, alongside an option for selecting the user's preferred fuel type. (This same option could be used to calculate the fuel needs of stone and steel furnaces.)

Nuclear power is only slightly more difficult, given the need to account for a reactor's neighbor bonus. Mathematically, it seems reasonable to simply provide numbers for a 2xN reactor that satisfies the required power needs. (And even more than steam power, the game's fluid mechanics introduce an incalculable source of loss, which it is easiest to simply ignore.)

Nuclear power could be made more complicated by attempting to provide numbers for a fuel-controlled/steam-buffered nuclear reactor, but this sort of trickery is probably outside the scope of this calculator, and providing the simple numbers needed to satisfy demand is probably adequate.

It should take rocket parts and a satellite as ingredients and return space science as a product.

When I switched to "expensive" recipes, the "factories" tab was empty. Changing tabs and "shift-reloading" didn't seem to fix it, but once I navigated to another website and went "back", it started working and it retained the "expensive" recipe selection.

I'm on the latest Chrome.

Currently, if a user enters a target rate of, e.g., 2 items/minute, and then changes the display rate to items/second, it will change the target rate to 2 items/second.

The underlying rate should remain unchanged when the display rate is changed, and the text in the "rate" boxes should be updated after the unit conversion.

For example, the ability to specify a rate of advanced circuits based on an input rate of electronic circuits. The user could enter a rate of 800 green circuits/minute, and the calculator would produce a solution for 400 red circuits/minute.

There are some limitations on how this could be combined with using multiple build targets, but with a single target, this can be trivially solved by producing a solution for the target item at an arbitrary rate (e.g. 1/second), and multiplying by the ratio between the input item's rate in that solution, and its desired rate.

When there are multiple build targets, this would only work when there is a constant ratio between the chosen input item and its corresponding build target. (I.e. it can't pass through a multiple-recipe item, although it can be such an item.)

The URL fragments can quickly become unwieldy when there are many end-products or modules in use. Find a way to shorten them.

The brute force solution would be to compress and base64-encode the existing string. It may also be possible to find a more compact representation without resorting to that.

Add ability to compute requirements for multiple simultaneous outputs.

Dumping the graph to .dot format should be easy, and I believe there's more than one dot renderer available for JavaScript. Other graph-rendering methods might also be worth looking at.

Example output from the tool:

https://kirkmcdonald.github.io/calc.html#rate=s&min=3&items=science-pack-1:r:5&modules=science-pack-1:p3:p3:p3:p3;s3:12

Given the following formula, in calculating production per second:

(Amount per craft / base craft time of item) * machine speed * productivity amount = items per second

for Sci 1, with 4 prod + 12 beacons (speed) this comes out to:

(1 / 5) * 8 * 1.4 = 2.24 ips

to reach 5 sci 1 per second:

5 / 2.24 = 2.232 factories

The tool however shows 4.2 factories needed, almost twice as many.. Haven't had a chance to look thru the code to figure out why; or am I missing something??

Add an option to select a module by default, for example to put prod3 modules everywhere that they are allowed automatically. As a bonus, this could easily help reduce the length of the URL fragment when heavily using modules.

Corresponding default beacon settings should go along with this.

One of the issues I run into with calculators is that I get lost in a sea of details when I'm trying to work out a new build for a specific piece of the factory. As an oversimplified example, let's say I'm working on a red circuit build:

The whole oil processing subgraph just outputs a single item: plastic bars. I'd like to have it just stop calculating after plastic bars to simplify the graph and make it easier to comprehend since I'm focusing on red circuits right now. Of course I'll want to back out and look at oil production in detail eventually, but for now all I want to know is that I need to produce plastic bars at a rate of X/min.

What would you think about adding a selectable list of "terminal recipes" that are just assumed to be fulfilled and their details are omitted (besides raw rate) when they are a dependency? And to make it easier to look at those details separately, add a link to a new tab that calculates the terminal recipes as outputs?

I'd like to contribute this myself but I wanted to get your opinion first. Thanks for the awesome tool!

Something is busted in displaySolution().

The recipe ignore feature does nothing when used on recipes that have no ingredients. The UI should be disabled for such recipes.

The items tab as it is now is fairly pointless. Originally, it was a quick way of representing the flow of items between recipes, but the current visualization is superior in virtually every way. It should probably be reworked into a list of total item-rates for each item. Those totals are not easily available elsewhere in the calculator, and it could even break down the item-rates in terms of belts, inserters, and/or logistic bots required to service that rate.

The synthetic "rocket-launch" recipe is currently set up to use the rocket silo as its factory. This is probably not useful. The recipe's crafting time is not meaningful, and modules in the building should properly be thought of as affecting the rocket-part recipe. Although the rocket launch does occur in the rocket silo, this is basically a coincidence as far as the calculator should be concerned.

One wrinkle is that, although the rocket silo makes rocket parts and then launches a rocket when it has 100 of them, it requires a bit of time to play the rocket launch animation (approximately 12 seconds; should verify this exactly). This limits how quickly a single silo can launch rockets, and it might be useful to communicate this, somehow, when giving the factory count for the rocket-launch or rocket-part recipes.

Another wrinkle is that this means it isn't useful to use a factory count when specifying space science as a build target. Some additional logic should be added to properly handle the case of a build target not using a factory. (This bug already exists in the case of crude oil, which is the only other item to not use a factory. Specifying it as a build target results in an exception.) Instead of defaulting to 1 factory, such items should default to some arbitrary rate (e.g. 1 item/second), and the "Factories:" box should be grayed out.

1. Focus the Beacon text input
2. Type a number (don't change focus)
3. Hover any module selector
4. Click to change the module selection

Actual result: The module selection is ignored (though the number is updated).
Expected result: The module I clicked should be selected.

Pressing the browser's back and forward buttons will change the URL fragment, but this will not prompt the page to update itself without reloading it. The application should use the HTML 5 "hashchange" event to properly update itself.

When clicking on an item to ignore it, any components of that item, being removed from the list, lose their module settings. It would be nice if the module settings were retained when the ignored item is toggled back on.

For example:

1. Calculate for Advanced Circuits.
2. Set modules for Iron Plate production.
3. Click to ignore Electronic Circuit.
4. Click Electronic Circuit again to re-enable.

Result: Iron Plate no longer has modules set.

Rates and counts currently round "half-up," but counts ultimately represent discrete units, and it would be most meaningful for them to round up.

Given the default count precision of 1, the current behavior means that if a factory count is shown as 1.0, the actual count could be anywhere in the range 0.95 <= x < 1.05, with the exception of x = 1.0, which would cause it to display as 1 (with no decimal point). That it could be greater than 1 is a problem, since in real terms that means the factory would actually require two structures.

Thus, the range 0.9 < x < 1.0 should display as "1.0", the value 1.0 should display as "1", the range 1.0 < x <= 1.1 should display as "1.1", and so on.

Rates should continue to use the existing behavior.

This is currently partially implemented: If the count precision is set to 0, it will ceil() the value to display it.

When the visualization is too wide, it will intersect with the vertical line of the tab-box, which looks ugly. Need to tweak the CSS to fix this.

Rather than the current module dropdowns, which display all of the modules in a single column, they should be displayed in a number of rows, with each module type on its own row.

The list of recipes is currently sorted alphabetically. Multiple people have expressed a desire for the ability to sort the recipes in some other way, such as in a topological order, or by some column other than the name.

Sometimes, when a dropdown is closed, the icon for the selected item is misaligned by roughly half of its height. Seems like a CSS issue?

The precision with which decimal values are formatted should be configurable.

The URL fragment should include the currently-viewed tab. This would allow e.g. sharing a link directly to a particular visualization.