Don't hard-error a game on a nil value in 'game'

[Honktown]

Sounds like you are setting yourself for using unreliable data which needs lots of hacks to be used instead of simply using the existing api.

Aside from that api dev view of it, I as a mod author certainly would rather use the reliable format of the prototype data in control over having to deal with the bullshit that things like data stage recipe products/ingredients format combined with difficulties are.

If I want certain values I can't use the existing API. If I can access data one way I expect it to be redundant somewhere else. The data.raw table is useful to have. Plenty of people would want to be able to access it the same way during data-final-fixes as during runtime, and yes, it would be so much easier than waiting on you guys to add special commands stored in various places which requires knowing that you broke basic language features like pairs. Just keep data.raw around, that's all it would take to solve my problems. But no.

[Rseding91]

LuaItemPrototype is one of the parts where I know every single property that is actually useful is exposed through it. I went over every single item prototype about a year ago and added everything.

It sounds like you just don't know how to make Factorio mods and are doing a bunch of useless work arounds for things you don't need to work around.

All you're going to accomplish once you release your mod is me blocking however you're passing garbage between data stage and control stage.

So, you can do it if you want - but i'm going to disable what ever method you're using to pass bulk data between the two stages. So, it will break in the future.

Or, you can use the actual API that won't be purposefully broken.

[Klonan]

I need stack sizes while the game is running, to limit an increase in rewards that will be affected by during-runtime values.

You can access the stack size here:
https://lua-api.factorio.com/latest/Lua ... stack_size

The data.raw table is useful to have.
...
Just keep data.raw around, that's all it would take to solve my problems. But no.

data.raw is super unreliable. First and foremost, a lot of things have default values that are only shown inside the source code. Data raw will show them as 'nil', but at runtime they will have the appropriate value defined by the default inside the engine.

Secondly, a lot of data.raw is discarded, mutated, unused or otherwise different to the final values at runtime. Knowing these values is not relevant to the actual runtime gamestate.

Thirdly, any mod can come in after yours in 'data-final-fixes' and scramble everything.



It seems you are trying to make a painful solution to something that isn't an issue.