Duplicate of viewtopic.php?t=128169

Events would be nice, but it sounds like you are skirting around asking for quality on plants instead of asking directly.

Helfima wrote: Tue Jul 15, 2025 2:37 pm this can be move in "Already exists" section

You mean "Implemented mod requests", since this request predates 2.0.56.

Cross surface teleport is riddled with issues on the C++ side as the game needs to invalidate all references to the entity - but not destroy configuration data - and then restore the entity on the other surface. This makes it extremely tedious to implement because it can't be done generically ...

Related: viewtopic.php?t=128297

And don't forget about pollution, which is also capped at 20%.

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.