Request: module_specification.allowed_module_categories

[Deadlock989]

The way that modules, effects, beacons, labs and crafting machines currently interact is a bit odd and a bit limiting. Modules have to have a category specified. This is just a string, but that string must match a registered Prototype/ModuleCategory. Once that's done, as far as I can tell, this category is never again used for anything else anywhere in the API and serves no apparent purpose.

If you want to stop a machine from benefiting from a certain effect, you do have some options, but it's all a bit inconsistent. If it's a machine that works with a recipe, you can limit any given module to a list of specific recipes. If it is an assembler, furnace or beacon, you can also specify "allowed_effects" on the root of the entity prototype - but these work using the effect types on the module, not the module category.

Furthermore, the lab prototype does not have allowed_effects, and labs don't work with recipes - they are not part of the CraftingMachine hierarchy - so any module will always work on any lab.

For example, I can have a pollution-reducing module (an "air filter") by making a new ModuleCategory and giving its members a negative pollution modifier. I can partially restrict it to certain crafting machines by only allowing the pollution effect on that machine. This prevents any of the vanilla modules from working in those machines - the only vanilla modules that have a pollution modifier are the productivity modules, and because they also have other effects, the module is prevented from being inserted. However, that's purely a coincidence and would not work with, say, machine speed, because the vanilla speed module has no other effects on it. There's also no way of stopping you from inserting the "air filter" into a beacon and have the beacon transmit a pollution-reducing field effect. You can also put the air filter into a lab even if the lab has zero pollution in the first place.

Proposed solution: all the machines that accept modules already have a ModuleSpecification property. This currently only defines the number of modules the machine can take, and some cosmetic parameters to do with the alt-info icons. The request is that ModuleSpecification gains an "allowed_module_categories" property, a table of ModuleCategory strings, which prevents specific classes of module from being used in specific machines. This would automatically include beacons and labs. The property would be ignored if not present/nil (i.e. all modules are accepted, barring those already disallowed by allowed_effects) for backwards compatibility.

Advantages: machine-specific modules, for better control of balance; prevent low-tech modules from being broadcast long range by beacons; being able to stop/allow specific labs from accepting specific modules.

[EnigmaticAussie]

I can see a lot of use cases for this change.

+1

[Boodals]

I have two concerns with this.
1. Lets say a modder wants to add a new machine that doesn't support the default production modules using this method, so they define it to only allow the base game's speed and efficiency modules. Then another mod adds new tiers of speed modules which have their own category for whatever reason. This mod would have to proactively search for all machines that use the base speed modules, and add their own modules to it, or the other way around, the machine-adding mod would have to search for all modules that have a speed effect, and hope that they don't have any unwanted scripted effects (eg. upgrades like alien loot economy).
2. This would make the rules for whether or not a module can be put in a machine notably more complex. I repeatedly find modders asking how to allow productivity modules for their recipes, as it's not obvious to look at the modules definitions. Adding a new variable to a new part of the prototype definitions will double the confusion.
IMO there should be a singular system which defines it all in one go. This would break backwards compatibility, so if it was ever done, it would be in a major version release (eg 0.18), but I think it would be overall beneficial. I find that modders don't mind fixing their mods as long as it also enables new cool shit they can do.

[Deadlock989]

Hi Boodals,

(1) above is a total non-issue for me personally. All mods are never going to be fully compatible with each other. The situation you describe is already the case - there's nothing to stop mod A from changing allowed_effects on crafting machines and creating its own crafting machines with wacky allowed_effects, or even changing the effects conferred by vanilla modules, which mod B might have to take heroic measures to change. That's just tough. We've allowed players to develop wildly unreasonable expectations about inter-mod compatibility, they need to get over it.

(2) is fair enough comment, but I don't think a rewrite is ever likely to happen, there's no vanilla use case for it. It's easy to say "it should always have been different". Adding allowed_module_categories would be far less work and far less disruptive.

[eradicator]

Have to agree that

0) I'd really enjoy being able to have modules that only work in machines i specify. (Particularly i'd like a certain machine to have a completely seperate set of modules while not being affected by beacons at all *sigh*.)

1) Cross-mod compatibility is already a nightmare. You can't make it much worse. "Find all X that do Y and apply changes" is already reality.

2) Totally agree that a unified system would be nicer. Also agree that i don't think that's ever gonna happen.

[Deadlock989]

Bumping this because I have today run into the same issues with mining drills.

You can disallow specific effects on drills, but you can't limit specific modules to drills because drills don't have recipes.

The ModuleCategory property remains completely unused anywhere in the game as far as I can tell.

[Rseding91]

Just FYI: module category is used when upgrading modules (ctrl + click modules into an entity and it will replace lower tier modules of the same category with higher tier modules - speed 1s with 2s or 3s for example).

[EnigmaticAussie]

As far as I can tell, that shouldn't interfere with the suggested changes.

[Deadlock989]

I think it was just an FYI, that the property is actually used by the game. It was certainly news to me. I didn't even know you could ctrl-click modules.

I've added that info to the wiki. https://wiki.factorio.com/Prototype/Module#category

[lovely_santa]

+1 (and a bump)

Angels mods is having similar issues (Arch666Angel/mods/#706): It has an agricultural module; basically it acts as a productivity module, but specific for agricultural recipes (bio related). It is however unwanted that this module can be inserted into labs and mining drills. For this reason it would be great to specify which module category can be used in which machine.

Our current workaround happens in the control stage (angelsbioprocessing/control.lua): When attempting to insert the module in an entity, the mod will verify if the module should be able to be inserted into the machine. If this is not possible, it extracts the module(s) again.

The current workaround only solves the problem of the modules potentially being used by the wrong machines. However, when hovering over a mining drill's module inventory, the tooltip still mentions that these modules could be used, misleading the players.

I hope this will be reconsidered sometime as this would be a great solution.

Kind regards,
lovely_santa

[kingarthur]

+1 (and a bump)

Angels mods is having similar issues (Arch666Angel/mods/#706): It has an agricultural module; basically it acts as a productivity module, but specific for agricultural recipes (bio related). It is however unwanted that this module can be inserted into labs and mining drills. For this reason it would be great to specify which module category can be used in which machine.

Our current workaround happens in the control stage (angelsbioprocessing/control.lua): When attempting to insert the module in an entity, the mod will verify if the module should be able to be inserted into the machine. If this is not possible, it extracts the module(s) again.

The current workaround only solves the problem of the modules potentially being used by the wrong machines. However, when hovering over a mining drill's module inventory, the tooltip still mentions that these modules could be used, misleading the players.

I hope this will be reconsidered sometime as this would be a great solution.

Kind regards,
lovely_santa

also +1

in pyanodons we are using them as speed modules and to fix this in py i resorted to adding a negative productivity effect and removing productivity effects from labs and drill to eliminate them from being used in those machines. while the method py uses does fix the problem caused by the method angels uses it does create its own issues with limiting productivity be used in the farms or drills or labs.

[lyvgbfh]

Another +1

There are cases where I want modules that are building specific, but right now I have to either:
A. Design said modules with use in labs, miners, and the desired building (if it even has a recipe) in mind
B. Restrict undesired building from using one of the effect types, and add an amount of that effect type to the custom module

Neither is desirable from a design standpoint.

[Honktown]

Clever use of already existing module information... Came to request an "allowed_on" type table/flags, but this is more consistent with how the API already works (module category already exists, and comparing crafting_categories, that is *categorical*, not a list of machines_that_can_craft in the recipe...)