Maybe a very simple .metadata field which could contain a string or a number (but not tables, as that would open can of worms should other mods try and read a table that contains references to original mod). I tried the approach of using non-visible GUI elements but found this to be undesirable, in ...

@Sirenfal see if this code is any help - I was mainly interested in when an item was dropped rather than picked up, but it could be refactored to work the other way, ie. when something is picked up.

viewtopic.php?p=213673#p213673

+1 Would love this feature. Currently we have to do a bit of crazy stuff, primarily checking every few ticks to see if player has opened an entity or selected one, and even then we can't remove the default UI for our custom entities. An alternate is to define custom-input and when triggered check to...

+1 In particular, it should be possible to do this in a way that retains backwards compatibility - simply add the new event names to data.defines.events with the same numeric ID as the existing events. This way existing mods won't break (the docs could state that the old names are deprecated but ult...

Such an event would facilitate custom waypoints / patrols, eg. for AI automated vehicles.

Rseding91 wrote:My question is: is that still useful?

Yes

Full of awesome win! As always!!

Did you ever find solution to your problem? I have similar issue when using underground pipes for wooden bridges - I was unable to get the pipe end to be on the bottom (ground) layer.

You can detect when an entity is opened via http://lua-api.factorio.com/latest/LuaControl.html#LuaControl.opened But there's no way to get a handle to the GUI or change it's contents. Some "workarounds" exist. For example, you can mod an item that doesn't have a GUI and then use .selected ...

This would be really useful for techs that are used purely to trigger updates in mod internal state rather than giving new recipies etc.

Just adding to the point made in some posts above about the tables not being normal Lua tables - this affects all aspects of the LuaCustomTable concept, including #, pairs, etc. The values in the table are only converted from C to Lua at time of access, and as far as I know aren't cached. So whereve...

Currently you have to use a table if you want multiple return values (put them in a table as named or numerically indexed values).

As others have said, some sort of enum setting for drop-downs would be superb. On-screen text would be localised enum keys.

Options could be defined as numeric array: { "opt1", "opt2", ... }

Default selection would be first item in array.

It's not currently possible to have invisible wires, or add new types of wire, etc.

As far as I can tell there's no way to do it - to either open or close an entity.

Yes, it's definitely a property of the player. There are multiple sprite sheet definitions in the player prototype, and you can associate specific sprite sheet with one or more armours. That way, when player equips one of those armours, a different sprite sheet is used for the player entity.

Also there was talk of merging damaged items in inventory (to reduce number of slots taken) which would break the factorissimo approach.

Only other thing I can think of is to experiment with "item with label" and see if that might work?

You mean something like this mod? https://mods.factorio.com/mods/binbinhfr/Megamind

Maybe there's a default non-zero fade_in duration?

Did you use "M" or "SHIFT + M" ?

Also, check that you event handler is using the correct name as defined in the custom-input prototype.