I agree. You can already enforce specific playstyles by checking in runtime stage (as, for example, Space Exploration does), so it won't make things worse. But validation makes more sense during game startup, along with the similar native checks.

Duplicate of viewtopic.php?f=221&t=53615

At this rate you are just better off making a custom command with a custom permission exclusively for banning.

There are multiple properties in the API called "range". This needs a description for what it affects.

Ideally, each quality version of the affected prototypes should be adjustable separately. The above idea of supporting expressions would be a good start.

range_multiplier

Range of what? Artillery turret? Regular turret? Radar? Rail support? Agricultural tower? Lightning attractor? Capsule? Ammo ...

create_entity already has most of those, if not all. The only things it doesn't do are automagically use the player's cursor's direction (which you can get) and (IIRC) decrement item count in the stack.

Oh, so every entity's module profile is limited to its own modules? Beacons don't affect it?

There are permissions for editor, though.

And what of the modules in beacons? Do they count? Does the count get multiplied by the beacon's effect multiplier, resulting in a fractional number? How are you going to define a profile then?

Oh, right. I always forget that the cheat command also researches all technologies. Then a permission (or some way) to control it is vital.

Irrelevant to the request, but if they can't be trusted with not cheating, then surely they can't be trusted with not abusing ban powers.

I assume you mean when visible_when_disabled is set to false. Surely it's valid to want to deliberately block a part of tech tree (e.g. for mutually exclusive branches).

Ideally, this should be its own separate property altogether, required_when_disabled.

Same for on_init, but you don't seem to have a problem with that.

I assumed that it was a legacy artifact, but after looking into it I've found both broken status and custom status (and default status for containers) have appeared in 2.0.7. Really makes no sense.

This is how the recipe/product merging should have been done from the start, not via mystic relation between prototype names (which only causes problems).

I think, there were plans to split the LuaEntity class entirely? Or maybe that was for LuaEntityPrototype.

Rseding91 wrote: Sun May 25, 2025 2:17 am It should be https://lua-api.factorio.com/latest/cla ... tom_status

That doesn't make any sense either. You can't specify one of the predefined states with that.

Change type and name. Then why remove the old property now? This breaking change can be postponed till 2.1. It's just a regular feature request aside from that.

Honktown wrote: Sat May 24, 2025 12:46 am 2) ' If you want to change it to a localized string, it can't be called a key anymore. '
I don't understand this statement. Yes. Changing the type permitted changes the type permitted.

Can't be called a key. Because it's not a key. And right now it's called a key.

It receives a parameter from the outside. How do you suppose that should be passed to a fully specified localized string?

Hence also the word "key" in the name of the property. The key being the name of the locale string it uses to look it up. If you want to change it to a localized string, it can ...