I am suggesting a recursive way of generating values for different items which would only require values for base resources (either plates or ores depending on the current system) and recursively calculates item value based on crafting ingredients. Certain special recipe types, like rocket construction, can be chosen to be processed differently to standard smelting and crafting recipes. This would allow compatibility with mods like SE to exist, due to their changed vanilla recipes. Combined with optionally adding other resources to the base resources list depending on installed mods, could provide full/most integration with such mods.

I would like to note that full SE compatibility would require significant world generation changes to accompany the standard limited planet size that SE values so highly, but I would prefer it it was circular in chunks, or the chunk fully generates when the original tiles would have covered more than half the chunk.

I would also like to note that I am not requesting this for the next update, as this would likely be a large undertaking.

I am suggesting a recursive way of generating values for different items which would only require values for base resources (either plates or ores depending on the current system) and recursively calculates item value based on crafting ingredients. Certain special recipe types, like rocket construction, can be chosen to be processed differently to standard smelting and crafting recipes. This would allow compatibility with mods like SE to exist, due to their changed vanilla recipes. Combined with optionally adding other resources to the base resources list depending on installed mods, could provide full/most integration with such mods.

I actually already tried this once. In one of my mods from 2020-ish, I actually successfully did something similar to this. I then proceeded to rewrite it from scratch in the context of my scenario logic, but it had some ugly infinite recursion bugs. After spending too much time trying to debug it, I got fed up and hand-selected the order of the recipes that's used to calculate item values. I know that the recursive method is significantly better because it allows modded items to be integrated into the market system, and I knew I was forgoing this when I decided to go with the more hardcoded method. This will be done one day. Hopefully not too long from now. I do wish to get some of the next major features and QoL implemented first before going for mod compatibility, but I do also wish for the scenario to be compatible with mods. So, I'll get there eventually.

I would like to note that full SE compatibility would require significant world generation changes to accompany the standard limited planet size that SE values so highly, but I would prefer it it was circular in chunks, or the chunk fully generates when the original tiles would have covered more than half the chunk.

The world in this scenario actually already is circular in nature, as of either version 0.0.5 or 0.0.4. Explore far enough out and you'll see how that's achieved.

I don't know if SE adds "planet size" options, but if it does, I can make it so that the radius of the world is determined by such settings. For now, you can edit some variables at the top of the control.lua file in the scenario to change the "radius". The relevant variables are "voidChunkMinChance", "voidChunkMaxChance", "voidChunkMinDistance", and "voidChunkMaxDistance". Interpolation from min chance to max chance is quadratic, so it starts slow and suddenly approaches max chance quickly near the max distance. You can use these to customize the size of the "planet" to your liking. I'll look into SE's map generation settings, and I hope this helps!

SE adds planet size for nauvis only.

SE adds planet size for nauvis only.

Good! The ore and biter settings on startup already affect the gridtorio surface, so I can add direct support for planet size from SE. That'll come in a future update, after the planned major features are released.

I actually already tried this once. In one of my mods from 2020-ish, I actually successfully did something similar to this. I then proceeded to rewrite it from scratch in the context of my scenario logic, but it had some ugly infinite recursion bugs.

I've been building such a system for use in a Replicator mod. I don't know if you'd be at all interested in looking at it, but if you are, I can link the github.

I actually already tried this once. In one of my mods from 2020-ish, I actually successfully did something similar to this. I then proceeded to rewrite it from scratch in the context of my scenario logic, but it had some ugly infinite recursion bugs.

I've been building such a system for use in a Replicator mod. I don't know if you'd be at all interested in looking at it, but if you are, I can link the github.

Sometime! For now, fixing the issue of altered vanilla recipes crashing the game is not a priority, especially since it can be fixed without making any changes to other parts of the code. The item value calculation is in its own contained process, which will make it easy to fix at any time. In fact, a mod could be released to fix it separately. The only thing that needs to be done is to recursively calculate item values for all items in the game, modded included, and then save them to global.itemValues.

Yes, that's exactly what my code already does :D

:)

Yes, that's exactly what my code already does :D

I'm ready to look into this. Gridtorio now has all major features in place.

Yes, that's exactly what my code already does :D

I'm ready to look into this. Gridtorio now has all major features in place.

The updates seem to be comming fast, 0.2.0 was the latest version last time i checked and now it's 0.4.0. :)

Yes, that's exactly what my code already does :D

I'm ready to look into this. Gridtorio now has all major features in place.

The updates seem to be comming fast, 0.2.0 was the latest version last time i checked and now it's 0.4.0. :)

I just had Claude 3.5 Sonnet write all the code for recursive item value calculation. It somehow has enough training data to know about the Factorio API! After a few tweaks to its ~150 lines of code, I got it working in about 30 minutes. I can, however, compare the results of the item value calculation with what either you or JamesFire suggest. Here's a sample of the values it produced without modded items:

wood = 4
iron-ore = 6
copper-ore = 5
stone = 2
coal = 2.4
uranium-ore = 12
water = 0
crude-oil = 0.25
raw-fish = 8
steam = 0.001
loader = 250
fast-loader = 600
express-loader = 1500
coin = 120
wooden-chest = 8
iron-plate = 6
iron-chest = 48
steel-plate = 30
steel-chest = 240
storage-tank = 270
iron-gear-wheel = 12
transport-belt = 9
fast-transport-belt = 69
empty-barrel = 1
crude-oil-barrel = 13.5
heavy-oil = 1
heavy-oil-barrel = 1
light-oil-barrel = 1
light-oil = 0.01922337562476
lubricant-barrel = 1
petroleum-gas-barrel = 1
petroleum-gas = 0.01922337562476
sulfur = 0.2883506343714
sulfuric-acid-barrel = 1
sulfuric-acid = 0.01922337562476
water-barrel = 1
lubricant = 1
express-transport-belt = 209
underground-belt = 52.5
fast-underground-belt = 292.5
express-underground-belt = 792.5
copper-plate = 5
copper-cable = 2.5
electronic-circuit = 13.5
splitter = 133.5
fast-splitter = 388.5
plastic-bar = 1.3922337562476
advanced-circuit = 39.784467512495
express-splitter = 986.34467512495
burner-inserter = 18
inserter = 31.5
long-handed-inserter = 49.5
fast-inserter = 70.5
filter-inserter = 124.5
stack-inserter = 492.7844675125
stack-filter-inserter = 560.2844675125
small-electric-pole = 4.5
iron-stick = 3
medium-electric-pole = 82
big-electric-pole = 199
substation = 523.92233756248
pipe = 6
pipe-to-ground = 45

It does not yet scale up item values exponentially with recipe complexity or time requirement, but that's a few edits away. It also appears to be going over fluids, too, so that's impressive. Let me know if this seems to need a change other than including the time or recipe complexity factors. It does seem to be assigning a default value of 1 when an inescapable, infinite loop is found.

Yes, that's exactly what my code already does :D

I'm ready to look into this. Gridtorio now has all major features in place.

The updates seem to be comming fast, 0.2.0 was the latest version last time i checked and now it's 0.4.0. :)

I just had Claude 3.5 Sonnet write all the code for recursive item value calculation. It somehow has enough training data to know about the Factorio API! After a few tweaks to its ~150 lines of code, I got it working in about 30 minutes. I can, however, compare the results of the item value calculation with what either you or JamesFire suggest. Here's a sample of the values it produced without modded items:

wood = 4
iron-ore = 6
copper-ore = 5
stone = 2
coal = 2.4
uranium-ore = 12
water = 0
crude-oil = 0.25
raw-fish = 8
steam = 0.001
loader = 250
fast-loader = 600
express-loader = 1500
coin = 120
wooden-chest = 8
iron-plate = 6
iron-chest = 48
steel-plate = 30
steel-chest = 240
storage-tank = 270
iron-gear-wheel = 12
transport-belt = 9
fast-transport-belt = 69
empty-barrel = 1
crude-oil-barrel = 13.5
heavy-oil = 1
heavy-oil-barrel = 1
light-oil-barrel = 1
light-oil = 0.01922337562476
lubricant-barrel = 1
petroleum-gas-barrel = 1
petroleum-gas = 0.01922337562476
sulfur = 0.2883506343714
sulfuric-acid-barrel = 1
sulfuric-acid = 0.01922337562476
water-barrel = 1
lubricant = 1
express-transport-belt = 209
underground-belt = 52.5
fast-underground-belt = 292.5
express-underground-belt = 792.5
copper-plate = 5
copper-cable = 2.5
electronic-circuit = 13.5
splitter = 133.5
fast-splitter = 388.5
plastic-bar = 1.3922337562476
advanced-circuit = 39.784467512495
express-splitter = 986.34467512495
burner-inserter = 18
inserter = 31.5
long-handed-inserter = 49.5
fast-inserter = 70.5
filter-inserter = 124.5
stack-inserter = 492.7844675125
stack-filter-inserter = 560.2844675125
small-electric-pole = 4.5
iron-stick = 3
medium-electric-pole = 82
big-electric-pole = 199
substation = 523.92233756248
pipe = 6
pipe-to-ground = 45

It does not yet scale up item values exponentially with recipe complexity or time requirement, but that's a few edits away. It also appears to be going over fluids, too, so that's impressive. Let me know if this seems to need a change other than including the time or recipe complexity factors.

Steam is labeled as 0.001, yet you need a fuel source to produce steam. When using AAI industry, a dependency of Space Exploration, you can turn any fuel into a more efficient fuel source in a very early game building. I expect the estimated value of that item to be 0 or very close to 0, as the building uses fuel as it's energy source to run a recipe which generates fuel from nothing.

What i'm saying is that the program may need to factor in the costs of the energy source required to run the recipe - say how many Joules you need to complete the recipe, what source the structure(s) producing the recipe require and the cheapest way to acquire such amount of energy with that source.

I've tinkered with the algorithm, and it appears to be highly problematic that some mods like Krastorio 2 or pY add many recipes which create infinite loops, making it quite difficult to infer a "correct" item value amidst the mess. James Fire, does your code account for this?

I've implemented an algorithm that seems to work. It is extremely slow with SE+K2, but it gets the job done. With K2 alone, it's not so slow, but SE+K2 combined make it take over 10 minutes to calculate item values, meaning you'll be stuck on the "Loading new game..." screen for much longer than you'd expect. It seems that every item has some calculated value, some much higher than others, so it appears to be working okay... minus the insane loading time. I don't even want to try loading it with pY this time. It'll probably sit there for an entire day calculating item values. The goal has been achieved: to make markets show trades for modded items, where the item value calculation (hopefully) accurately determines the value of all craftable items in the game.

It appears to be struggling very much with oil derivatives when K2 is installed. In vanilla, every single craftable item or fluid has a reasonable value assigned to it, but with K2, it can only find negative values (so it leaves them unassigned) for oil products like light-oil or heavy-oil. This means that partial mod support exists for SE+K2, and it can be fixed with an external mod that fills in the gaps.

Yes, that's exactly what my code already does :D

I'm ready to look into this. Gridtorio now has all major features in place.

https://github.com/James-Fire/fire-replicators_1.0.0/blob/main/prototypes/Replication%20Generation.lua

You can check out my code to do it here.

I do have loop handling.

I used to have an insane loading time, but then I made some changes to how I handled stuff and reduced it by 99.8% (That is not a joke)

(Also sorry I didn't see this, my email notifs appear to be broken)

The mod in that repository is fully functional, you could download and use it to see how it does.

The code can also handle rocket launch products, and the % chance thing some recipes have

The mod in that repository is fully functional, you could download and use it to see how it does.

The code can also handle rocket launch products, and the % chance thing some recipes have

Thanks for getting back to me on this. How should I integrate the functionality of replicators into Gridtorio so that item value calculation inherits proper values for modded content? None of the functions seem to stand out to me. I will need your help integrating this.

The file I linked handles value calculation and creating my techs and recipes based on that value calculation.

You don't need the function addMatterRecipe at line 478, nor any in the group starting at line 715 til line 937.

The optimization I mentioned earlier was pre-sorting items, and then using the list of allowed items instead of the raw list of all items. This takes place starting at line 111 all the way to line 399

The actual value calculation is handled by the GetRecipeIngredientBreakdown function, starting at line 537. It recursively handles an item, and any ingredients of it that aren't already calculated.

Is that enough, or do you need more help?

The file I linked handles value calculation and creating my techs and recipes based on that value calculation.

You don't need the function addMatterRecipe at line 478, nor any in the group starting at line 715 til line 937.

The optimization I mentioned earlier was pre-sorting items, and then using the list of allowed items instead of the raw list of all items. This takes place starting at line 111 all the way to line 399

The actual value calculation is handled by the GetRecipeIngredientBreakdown function, starting at line 537. It recursively handles an item, and any ingredients of it that aren't already calculated.

Is that enough, or do you need more help?

Thanks for pointing that out to me! It seems like it'll be useful! :) If you publish your code under a mod, I'll use the functions through that mod. Otherwise, my only option is to copy/paste your code, if that's fine by you. I'll ensure to put a disclaimer that it's not my code.

Use it, make sure you credit me :)

The file I linked handles value calculation and creating my techs and recipes based on that value calculation.

You don't need the function addMatterRecipe at line 478, nor any in the group starting at line 715 til line 937.

The optimization I mentioned earlier was pre-sorting items, and then using the list of allowed items instead of the raw list of all items. This takes place starting at line 111 all the way to line 399

The actual value calculation is handled by the GetRecipeIngredientBreakdown function, starting at line 537. It recursively handles an item, and any ingredients of it that aren't already calculated.

Is that enough, or do you need more help?

It turns out that I need to make some modifications to how recipes are searched. Gridtorio runs entirely in the runtime stage, but your mod runs in the data stage, which means that recipe tables are simplified and stored elsewhere. I'll get around to making these changes soon.

Ah well I hope my code helps still

Ah well I hope my code helps still

It most definitely will! The part that I could never get right was the loop handling, the underlying algorithm. When I adapt your code to Gridtorio, this will solve all of my problems with excessively long loading times and recipe alteration incompatibilities, so thank you so much!

Ah well I hope my code helps still

Actually, it's looking like a large part of it needs to be rewritten since it makes heavy use of data.raw, and it's not in any script.on_init(), so I can't simply replace all "data.raw" with "game" (which doesn't exist until the script has been initialized).

Unfortunate