[MOD 0.16.x, 0.17.x, 0.18.x, 1.1.x] SCTM

[mexmer]

hmm, looks like change to debug messages triggered reprocessing of migration script, not sure why. should be fixed now.

[Aviator]

Thanks, but now I updated scm and a different error comes up
Error while applying migration: ScienceCostTweaker Mod (mexmer): ScienceCostTweaker_0.16.28.lua

...CostTweakerM__/migrations/ScienceCostTweaker_0.16.28.lua:1: module sctmlib not found; no such file __ScienceCostTweakerM__/migrations/sctmlib.lua no such file C:/Program Files (x86)/Steam/steamapps/common/Factorio/data/core/lualib/sctmlib.lua

edit: I'm playing Seablock with this, I did disable all the other mods and error still appears

[mexmer]

Thanks, but now I updated scm and a different error comes up
Error while applying migration: ScienceCostTweaker Mod (mexmer): ScienceCostTweaker_0.16.28.lua

...CostTweakerM__/migrations/ScienceCostTweaker_0.16.28.lua:1: module sctmlib not found; no such file __ScienceCostTweakerM__/migrations/sctmlib.lua no such file C:/Program Files (x86)/Steam/steamapps/common/Factorio/data/core/lualib/sctmlib.lua

edit: I'm playing Seablock with this, I did disable all the other mods and error still appears

can you send me save, i tried with different saves and migration doesn't trigger in first place. it should be already applied if you save has 0.16.28 or newer version of mod.

anyway i reuploaded 0.16.42 with migration script from elder version.

[mexmer]

0.16.43 was just released, this was intended to be mostly about mod maintenance and some standardization of function usage, so it should not break stuff (imo), but in the end i also added py intermediates integration, just to test out how my function lib works.

[KvaNTy]

Future plans
- add space science pack components (ingredients will be from space)

Yes please!
Surface composition samples, magnetic field measurements, multispectral imaging data, captured solar particles: all those things could be brought from space for a further scientific research.

[mexmer]

0.16.45
there is not much changes, just added Xander mod compatibility (tested only with xander alone, no other mods involved), and reduced log spam by slight margin.

[minno]

(Bringing this over from the Seablock thread)

The cost scaling of SCT expensive recipes is extreme. In the Vanilla game expensive recipes for science cost somewhere in the neighborhood of 10x as much, combining a 4x increase in technology prices with a 1x-4x increase in resources required for each science pack.

Vanilla comparison

SCT has similar scaling for each component, but by applying this to intermediate products as well, it makes the resources required become much higher by compounding the 2x-3x increase over multiple steps.

SCT+sea block comparison

The most extreme change is 3 iron to almost 200 iron for green science packs.

[mexmer]

i had not done any calculation with seablock, and tbh. don''t even plan to. i rebalanced most recipes for vanilla to get 2-4 increase in finale pack price (red is somewhate over 2, high tech and production are close to 4).

i will need to look more into bobs/angels + sct, because there are also expensive recipes in play on some materials used in science recipes, so they still scale higher than 4 when bobs + angels is in play, but it's not 100x increase, like it was for blue science.

i still need to redo calculation on science labs too, but probly next week.

[minno]

Compatibility issue with v0.16.46:

In CircuitProcessing and SeaBlock (and maybe other mods), there are a bunch of places with a pattern like

Code: Select all

if data.raw.recipe['something'].normal then
  data.raw.recipe['something'].normal.something = something
  data.raw.recipe['something'].expensive.something = something
else
  data.raw.recipe['something'].something = something
end

The new update sets normal = { the usual properties }, expensive = false in a fair number of places, which makes those checks fail when they try to access the .expensive property. It works if I remove the expensive = false lines and move the properties from .normal into the recipe itself. I think you could also set the expensive property to be equal to the normal property as well.

There are also a couple of places in SeaBlock 0.2.12 that just assume that the .normal property exists on certain recipes, which breaks when I move those properties out, but that's something that they need to fix depending on what changes you make here.

As far as the rebalanced expensive costs, they look good. The increased scaling from base ingredients being more expensive (like green circuits using 2x iron in Circuit Processing, or ore using 2x mineral sludge in Sea Block) isn't an issue at all.

[eradicator]

Or you make the other ppl fix their code? :P

Code: Select all

if data.raw.recipe['something'].normal then
  data.raw.recipe['something'].normal.something = something
  end
if data.raw.recipe['something'].expensive then
  data.raw.recipe['something'].expensive.something = something
  end
if not (data.raw.recipe['something'].normal or data.raw.recipe['something'].expensive) then
  data.raw.recipe['something'].something = something
end

[minno]

As far as I can find there isn't a single instance of "expensive = false" in the base game or any of the mods I have downloaded, so I'm not sure that it's even intended to work.

[eradicator]

As far as I can find there isn't a single instance of "expensive = false" in the base game or any of the mods I have downloaded, so I'm not sure that it's even intended to work.

Doesn't really matter if it's false or nil for checking existance. While i agree that nil would be the correct way, the assumption that existance of .normal implies existance of .expensive is simply wrong, and thus any code failing based on that needs fixing, as both normal without expensive and expensive without normal are valid recipes. There are many things that the base mod doesn't use but the engine supports. If "all modders agree on a certain way to do things" was a reasonable approach you could make assumptions like that. But that's not gonna happen :D.

[mexmer]

As far as I can find there isn't a single instance of "expensive = false" in the base game or any of the mods I have downloaded, so I'm not sure that it's even intended to work.

false for dificulty variant is correct, as stated in https://wiki.factorio.com/Prototype/Recipe (see example at end of article)
i've also discussed this with bilka and rseding some time ago on discord.

and rest was pointed by @eradicator

presence of expensive doesn't imply normal, presence of normal, doesn't imply expensive. and modders should check for that.

[eradicator]

false for dificulty variant is correct, as stated in https://wiki.factorio.com/Prototype/Recipe (see example at end of article)
i've also discussed this with bilka and rseding some time ago on discord.

Personally i'd be very interested in the reasoning of using false instead of nil. At the very least it'll break when someone does:

Code: Select all

if recipe.expensive ~= nil then
  end

Which will work fine in all other circumstances and "looks" correct (other than being a bit verbose, but new modders aren't usually lua experts) if you don't know that some people put a boolean there instead.

[mexmer]

false for dificulty variant is correct, as stated in https://wiki.factorio.com/Prototype/Recipe (see example at end of article)
i've also discussed this with bilka and rseding some time ago on discord.

Personally i'd be very interested in the reasoning of using false instead of nil. At the very least it'll break when someone does:

Code: Select all

if recipe.expensive ~= nil then
  end

Which will work fine in all other circumstances and "looks" correct (other than being a bit verbose, but new modders aren't usually lua experts) if you don't know that some people put a boolean there instead.

honestly, i don't know. i had quite long discussion with them about that, but there was not clear explanation why.

but if you do test

if not recipe.normal then

it works with both nil and false. lua is loose typed language

i used false, since it's used in example, and also because i found other mod, that did the same. can't remember now name of mod.
when i was solving compatibility issues with other mods, i found some that used false, because at first i was testing for nil too.

anyways, using false for dificulty was decision made by devs, not moders, moders only can adopt to it

[eradicator]

it works with both nil and false. lua is loose typed language

I know. But nil looks cleaner to me. And has none of the drawbacks of having an unexpected type.

anyways, using false for dificulty was decision made by devs, not moders, moders only can adopt to it

If the only place where that "decision" is communicated is a single example at the very end of a wiki page that's certainly not enough to convince me to not use nil ;). Anything that the engine doesn't enforce is not a fixed decision in my book. I guess i'll just go ask them myself...

Thanks for the answers. Back to → on topic.

[mexmer]

it works with both nil and false. lua is loose typed language

I know. But nil looks cleaner to me. And has none of the drawbacks of having an unexpected type.

anyways, using false for dificulty was decision made by devs, not moders, moders only can adopt to it

If the only place where that "decision" is communicated is a single example at the very end of a wiki page that's certainly not enough to convince me to not use nil . Anything that the engine doesn't enforce is not a fixed decision in my book. I guess i'll just go ask them myself...

Thanks for the answers. Back to → on topic.

nobody tells you to not use nil, you can use both.

just use test, that expects either.

[eradicator]

nobody tells you to not use nil, you can use both.
just use test, that expects either.

Well, i went ahead and asked Bilka, and the result is that false is not the same as nil:

Code: Select all

recipe.expensive = false

behaves equivalent to

Code: Select all

recipe.expensive = util.table.deepcopy(recipe.normal)
recipe.expensive.enabled = false

So if you use it on anything that doesn't have a technology to unlock it, it'll never be craftable on that difficulty. Which means nil is really the better option if you're not trying some super-special shenanigans.

The wiki text has been updated to mention this: https://wiki.factorio.com/Prototype/Recipe#Recipe_data

[mexmer]

nobody tells you to not use nil, you can use both.
just use test, that expects either.

Well, i went ahead and asked Bilka, and the result is that false is not the same as nil:

Code: Select all

recipe.expensive = false

behaves equivalent to

Code: Select all

recipe.expensive = util.table.deepcopy(recipe.normal)
recipe.expensive.enabled = false

So if you use it on anything that doesn't have a technology to unlock it, it'll never be craftable on that difficulty. Which means nil is really the better option if you're not trying some super-special shenanigans.

The wiki text has been updated to mention this: https://wiki.factorio.com/Prototype/Recipe#Recipe_data

well, that's interesting, i should probly copy factorio discord log, from time, when i was asking about that. and was complaining, that it should be nil, and not false.

doesn't matter tho, it's good they updated article

[mexmer]

so i tested behavior and for SCT nil/false is no change, because all recipes are unlocked trough technology, and they are enabled = false by default.

problem is with some mods, that either expect both dificulties (well, those we discussed above) or do own normalization, and then fail on false/nil dificulties.

so guess i will stick with duplicating dificulty settings, rather than leaving it nil/false