Certain prototypes are not writeable with disabled_by_script, even though they have frozen variations that operate exactly like their disabled counterparts would be expected to operate. Specifically, transport-belt, splitter, underground-belt, pipe-to-ground, and pipe, although the list is likely ...

Ruyeex wrote: Mon Mar 17, 2025 7:03 pm You can enable filters and drag the item you want onto the filter

The request is to not have to enable filtering before dragging the item into the filter

TL;DR
Clicking an inserter filter slot while filtering (`Use filters`) is disabled should enable filtering and set a filter.

What?
Currently, clicking on the inserter filter slots does nothing when `Use filters` is off, because the filter slots are non-interactable. I would like to be able to ...

+1

To me, this sounds like the exact opposite of what fluids 2.0 wanted to achieve - FFF-416 .


Linking an entire FFF doesn't prove a point. Fluids 2.0 was implemented to solve a few key issues: lag, junctions, unpredictability, black box nature, and flow limitations. It swung way past what it was ...

There are many solutions, yes. But I'm not looking for a way to do it. I'm asking for the right way to do it to be made available. :D I have a working hack to smuggle the relevant information from the prototype/data stage through to the control stage. But that's not the right way to do it, and it ...

I think that each fluid should have some viscosity or flow speed multiplier property, such that each fluid can flow faster or slower through a network. Stuff like gases can be uber fast, and liquids can be slower. Perhaps also a temperature dependent multiplier as well, so that hotter/colder fluids ...

When doing mods like these, I prefer to use entity-name instead of any other properties. (Most) mods follow the same conventions for naming similar entities (pipes, splitters, pipe to grounds, underground belts) so by knowing what the convention is, you should be able to find what the associated ...

Ideally, we don't want hardcoded quality levels as mods can change that (i.e. add or remove levels), so we need either tuple-factor as was suggested above, or use expression formula like "80 + 20*q", and we definitely would need a special flag "override_quality_control" (default: false) on ...

Distributed weight results would be perfect. I've looked to try to do this before but I never liked the potential for getting a random number of outputs.

+1, perhaps instead you could write to the output slots and if it's beyond the current recipe outputs, it becomes trash slots?

+1 for being able to specify categories

+1

Perhaps having a per-player property, modifiable by mods, to ignore selection boxes of a specified priority range, or of specific flags? That way you could just ignore the elevated rails, or just ignore belts, etc

+1, would help immensely in a number of scenarios I've seen recently.


A built-in quality draw option would be welcome too if something icon specific is being added anyways, but unlike the above it already has workarounds.


This would also be awesome, perhaps when specifying a sprite for LuaGUI ...

FactorioBot wrote: Wed Feb 26, 2025 2:28 pm Scripting

• Added LuaSchedule.
• Added LuaSpacePlatform::get_schedule().
• Added LuaTrain::get_schedule().

This. Is. Awesome.

+1

+1

+1

When accessing the on_marked_for_deconstruction event, any LuaEntity of type `pipe-to-ground` cannot have it's `direction` property queried. If attempted, it crashes the game. This is likely due to it being in a deconstructed state. I attempted to get around this by temporarily reconstructing it ...