You'll get the same behavior if any mod simply calls destroy() on anything, or if someone enters a simple command such as:

for _,v in pairs(game.player.surface.find_entities_filtered{}) do
v.destroy()
end


A good hint - I hadn't noticed that yet. Thx for the clarification 👍

P.S.: Such nasty ...

Sorry - my fault. Didn't double check the usability of registering the surface itself with https://lua-api.factorio.com/latest/classes/LuaBootstrap.html#register_on_object_destroyed for my problem. I had overlooked that using "remove all entities" in editor mode doesn't delete the surface at all ...

Ah - didn't see at first that it is possible to register the surface itself with https://lua-api.factorio.com/latest/cla ... _destroyed - and that is what I need

Yes. You can use https://lua-api.factorio.com/latest/classes/LuaBootstrap.html#register_on_object_destroyed


Hmm - sounds a bit weird - and quite cumbersome ;) - for me to register a lot of distinct entities and to raise a corresponding number of events instead of a single one, but it is what it ...

Hi altogether,

when I use "remove all entities" in editor mode, it seems so that there is no event triggered for that.

Although it's obvious that there can't / shouldn't be an event for each entity removed from a surface, i would expect that at least one event is triggered for this action to have ...

Hi altogether,

I've fumbled a little bit with editor mode and found two astonishing behaviours:

• "Remove all enties" does not rise any event
• Using "Import save" to import a platform from a save file does not import the hub

Is this intended?

@boskid Thx for your quick reponse

As save files for which the migration already has been applied didn't trigger the fault (and have the desired state), IMO there
only a need for running the corrected version for save files for which it hasn't been applied yet, ecspecially there's
no need for ...

In one of my mods I have a faulty (lua) migration script that triggers in some rare cases a nil access and I would like to fix that,
but I am not completely sure what's the correct way to do that.

As far as I understood, migration files are only run once for a certain save file (if that migration ...

Is there a timeline when this will be corrected?

Oh - it's quite easy to become confused while searching for a mistake and trying to narrow down it by adding some additional logs
which only show the (non unique) numbers and not the (more or less - at least for insiders ;)) self-explanatory identifiers.

And if you're looking during search for ...

Hi boskid,

thank you for the really quick answer. Ok - that looks like some apparently desired redundancy, but shouldn't this be reflected in the json-docu at https://lua-api.factorio.com/stable/runtime-api.json, too? Otherwise it's a little bit misleading

I've just stumbled upon a strange behavior concerning the values of defines.wire_connector_id.*

When using these defines I had some strange phenomenons. For digging a little bit deeper I wrote this tiny "mod"


for _, f in pairs(defines.wire_connector_id) do
log(f)
end


and expected to see the ...

Nowadays the page with the documentation is located here: https://lua-api.factorio.com/latest/typ ... gType.html

Thx for your efforts and I am excited about the solution

Hmm, can you try setting it after creation?

local sp = container.add {
type = "scroll-pane",
style = "rldman_small_slot_table_scroll_pane",
name = "scrollpane"
}
sp.horizontal_scroll_policy = "dont-show-but-allow-scrolling"


Of course :D

Code now is

local sp = container.add {
type ...

Oh yeah, you're right - that is wrong

Unfortunately there is no change in behavior after correcting this (I've checked whether the policy is now set correctly by logging the content of the field)

Hi Klonan,

thx for your quick response.

This is the relevant part of the code, where the scroll pane sp is created:


function testtab.update(refs, data)
local container = refs.testtab_tab

-- ugly - clear all children and create new ones
container.clear()

local sp = container.add {
type ...

Is it possible to have a scroll pane without scrollbars which is still scrollable (with mouse wheel)?

I've already tried the *_scroll_policies with "dont-show-but-allow-scrolling", but unfortunatelly scrollbars are still shown and I can't see any difference in behaviour to "auto".

Thx in advance

OP, did you finish connecting the green wire to a target?
Because in that setup (a belt right next to a combinator) it may look like the wire is connecting to the combinator, but it's indeed connecting to the belt.
Connecting a wire to the combinator looks a little bit differently:
GreenWireOnBelt ...

Tried to connect a belt with green wire, instead of the chosen transportation belt the adjacent combinator was connected.

The behavior is easy reproducible:
choose green wire
try to connect belt and click it
instead of the belt the combinator is connected

Both arithmetic and decider ...