It's a table where you can select rows like in a listbox. Example can be found in the multiplayer game browser window. This kind of table being available will be a massive improvement for mods. Right now any mod that wants even slightly nontrivial functionality from a listbox is forced to roll out i...

Sorry, didn't notice that. Yes, it should be in the event description, since it's the property of the event and not merely how it was raised. You can operate on the stack directly to change it and that also raises the event (and isn't mentioned anywhere, AFAICT).

Properties marked as can be nil when they can not. Type-specific properties are not marked by the customary "Can only be used if this is <type name>" or lack any note whatsoever.

IDK when it is raised, but it should be pointed out in the docs that it's not immediately.

I am sure it's not just me who finds player.selected an invaluable tool for quickly inspecting entities. But when I work on GUI, time and again I find myself missing this ease of access. If I could simply point at an element and access it in code, that would be extremely convenient.

FFF 388 announced engine support for ticks up to 2^64, but only Lua support for ticks up to 2^52. We can work around the Lua limit by breaking up the tick into two 32-bit numbers. The upper 32 bits are easy to calculate from LuaGameScript.tick. But we need a new property that contains the lower 32 ...

Excluding "productivity" from allowed_effects just controls productivity modules. We already have it set to reject those. This doesn't stop the entity being affected by mining productivity research. That seems like a bug to me. Mining productivity bonus is a productivity effect, I think i...

What if you made the miner reject the productivity effect? It's not like productivity makes any sense in an offshore pump. Would it ignore the mining bonus then?

Did something happen to player.opened?

If this is implemented, it should be as an option.

FYI, it doesn't understand negative numbers either.

Right now the type of the parameter is listed as string whereas in fact it's one of the respective string literals (and the game will error if you try to pass any other string). This affects all instances of the method (including ghost_has_flag).

It says that for fluid prototype, but with item the docs leave you to guess.

edit: Or, hm, an item isn't burnable without a fuel category (unlike fluids, which don't have fuel categories), so maybe this is a pointless distinction.

The reason I think it might be missed is because it's very easy to underestimate the extent having to react to mods changing things. This is something that took me a while to fully realize. I of course knew about it, but the full extend of it took me a while to appreciate. And in this instance even...

Completely agree with Rseding, the name is self-evident.

edit: As for the linked bug, people aren't perfect infallible beings. Notnotmelon might have simply overlooked that event or the possibility that scripted action is something they need to be concerned about. No need to overreact.

That's great news, thank you.

Description missing in both data and runtime docs.

I don't see the connection. A "not-beaconable" flag doesn't make it harder or easier to detect beacon effects (which you can already do by detecting changes to a beacon's modules the same way you described for other entities and find_entities_filtered to look for exisitng beacons), it just...

I see. Thank you for telling me. Workaround time, I guess.

To reproduce: 1. Make the following locale entry: n-items=__1__ __plural_for_parameter_1_{1=item|rest=items}__ 2. Launch the game and run the following command: /c game.print{'n-items', 0.5} 3. Observe the following output: 0.5 1 Expected behavior: The "rest" form gets used, producing the ...