Imagine many more existing belts _before_ the splitter. do you attempt to underground over those too? (This also means not attempting to upgrade them)

Don't know the best answer, hence why I'm now asking

With the new (niche) --run-replay option, if the replay has the player craft something, the replay crashes.
Attached is save and log.
The save file replay consists of: starting Freeplay, mining 2 rocks, crafting furnaces, then moving items in/out of the crashed ship.

From the stacktrace, I'm ...

I suggest moving the discussion here, so more people can see it

Asking for feedback on dealing with splitters
Here's some cases with splitters, where it might be ambiguous if want to underground over them.

- In the first row, it's reasonable to want to underground over the first bit
- In the second row, from feedback reasonable to _not_ underground over the ...

I've just updated the spec to have much more and cleaner explanations/motivations, with some images, to be readable by a wider audience!


That wider audience may include an LLM someday... Don't worry, there will be no vibe-coding here; my code quality standards are much higher that most LLMs have ...

More on why do this:

Searching "smart belt bug", especially recent posts, will get you a glimpse into one motivation.

While playing around found a ton of questionable behaviors in the current implementation.
It's the "I can't tell if this is intended or not" part that gets me; hence trying to ...

TL;DR
Let's overhaul smart belt — fixing bugs, adding features, and making it handle all possible scenarios! I’m volunteering to implement this.

What
I’ve drafted a complete redesign of smart belt, aiming for intuitive, consistent, and useful behavior, and handling all possible cases.
Yes ...

I'm back!
Found a few more inconsistencies in lua-api docs, introduced recently. Last checked in [2.0.63]:

Problems:
- The new BlueprintEntity variant_parameter_groups is missing "rocket_silo", making RocketSiloBlueprintControlBehavior unused.
- In the new TechnologyModifier variant_parameter ...

Problem solved:

https://mods.factorio.com/mod/cheevos_base
https://mods.factorio.com/mod/cheevos_spage


Problem not quite fully "solved":

As a note, a potential mod to revert to pre-.45 behavior won't be simple.
Removing allowed_without_fight allows you to set map generation to anything ...

I see one main reason for the disapproval of the achievement is how sudden and arbitrary it feels: the biter achievement behavior has previously existed for nearly 10 years now, all through 1.0 and 1.1, and 6 months into space age; this behavior is even listed on the wiki. Then, it's suddenly ...

Adding to the "fix it with a mod" idea, speaking as a speedrun.com admin and one of the main contributes to 1.1 100% blueprints: I'm not sure that people would want to do runs with a mod. Having to run with that feels quite contrived. The same can be said of an "88%" category that excludes the biter ...

As a note, a potential mod to revert to pre-.45 behavior won't be simple.
Removing allowed_without_fight allows you to set map generation to anything including more favorable map settings than before (e.g. biter nest size <100%).
So such a mod may be possible, but would require re-implementing the ...

If this is intended behavior and not a bug... I think it should be at least announced in the changelog.
Cuz this just broke a whole bunch of stuff

[2.0.39] the newly LuaSchedule::get_records, set_records, and clear_records have parameters of type "uint: interrupt_index" instead of "interrupt_index: uint".

...have you considered making a compiler to check for type errors? I guess I accidentally have

- only give bonus items once main item is complete.

Also possible fix: Count the ingredients as consumed for the current crafting cycle, whenever a bonus productivity item is created.

- doesn't give back item when cancel recipe like before (that could hurt player)

But please please don't ...

It requires manual input, but is possible to parallelize:



If this ends up _not_ getting fixed, factorio speedrunning may end up no longer "glitchless". Which may be an interesting world to live in?

Thanks for the fix!

Not sure those 2 saves are based on the same version. I think I loaded an old game version and copied blueprints to a new save to continue.

In any case there weren't any issues loading the saves until updating to the new version.

Narrator: it was, in fact, not fixed in 2.0.35.
(Or maybe the save was already doomed to fail in 2.0.34?)

Save file and log attached.

update... the same error seems to occur when loading the save in 2.0.33, when adding a new mod.
This might point to it being in the migration logic somewhere?

After updating to 0.34, get a crash loading a 0.33 save.
Crash message indicates this might be because I was doing demolisher shenanigans in editor mode (deleted some naturally spawning ones, added then deleted more).

Log and save are attached.

Edit: attached the correct log file this time