It'd be great if this mod could include a remote.call() function that another mod could use to add/remove UV lamps that they create to your table of UV lamps so they could be functional.

Yeah, guess it'd indeed be nice to have, and relatively easy to add. Good idea.

is it possible to add https://mods.factorio.com/mod/i-speak-for-the-trees since the author is already inactive. sleeping biters inside Trees and Worms in Dead Trees

is it possible to add https://mods.factorio.com/mod/i-speak-for-the-trees since the author is already inactive. sleeping biters inside Trees and Worms in Dead Trees

I feel like something like that should stay as its own mod, but that’s up to mk-fg.

is it possible to add https://mods.factorio.com/mod/i-speak-for-the-trees since the author is already inactive.

I've had a look at the mod. It's quite simple, and it seems to be ideal for spicing up my Maps mod! This way, killing trees may not only result in occasional rewards, but also in punishment.

sleeping biters inside Trees and Worms in Dead Trees

Worms in dead trees -- that was never implemented because of problems with identifying living and dead trees from mods. Not sure yet what to do about it.

Worms in dead trees -- that was never implemented because of problems with identifying living and dead trees from mods. Not sure yet what to do about it.

Iirc it's totally possible by checking entity.tree_stage_index - "e.tree_stage_index == e.tree_stage_index_max" means that it's dead, or at least uses dead sprite.
These were indistinguishable from burnt-out trees because there was no way to get "black color" property last I checked, but for just dead ones, I think that's how you do it.

I feel like something like that should stay as its own mod, but that’s up to mk-fg.

Yeah, probably best to have as a separate mod, given how indeed simple it'd be.

Worms in dead trees -- that was never implemented because of problems with identifying living and dead trees from mods. Not sure yet what to do about it.

Iirc it's totally possible by checking entity.tree_stage_index - "e.tree_stage_index == e.tree_stage_index_max" means that it's dead, or at least uses dead sprite.

Thanks for the hint, that looks promising! I think I can use that for spawning the enemies. But there's another tree-problem I have with BioIndustries: You can plant trees there. Trees will grow through several stages, and when they have completed the last stage, they will be replaced with a random tree prototype. It always bothered me that sometimes, the tree that was spawned was not using the sprite standing up, but the sprite showing it lying on the ground. I wonder if setting tree_stage_index = 1 would prevent that. -- I'll check that out after work …

Yeah, if there's indeed a small chance of spawning closer-to-death stages.
But if it's a separate tree sprite variation looking like that, maybe you can check something like e.graphics_variation and replace the thing if it spawns as known-ugly tree :)

Added remote interfaces in 0.3.24, described in FAQ, which is linked in the main description somewhere.
Should hopefully make it easy to register any new repellant-lamp, or make some custom one via emit_once() call there, without the need to copy or duplicate internal logic.

Didn't actually test using those from other mods, so let me know there are any bugs, but given that these calls are fairly simple wrappers around same things that mod calls for normal lamps (and other things), hoping there aren't much room for those, and they should be immediately apparent when call is made.

Yeah, if there's indeed a small chance of spawning closer-to-death stages.
But if it's a separate tree sprite variation looking like that, maybe you can check something like e.graphics_variation and replace the thing if it spawns as known-ugly tree :)

The key is "known-ugly tree" -- I can't know what tree variation will be ugly because there may be hundreds of tree prototypes in the game: BI itself creates a different versions of each tree prototype, one for each growing stage; combine that with mods like "Alien Biomes" and the number of prototypes to check can be quite large. But checking if tree_stage_index >= tree_stage_index_max seems to work for my Maps mod. :-)

is it possible to add https://mods.factorio.com/mod/i-speak-for-the-trees since the author is already inactive. sleeping biters inside Trees and Worms in Dead Trees

I've just uploaded the new version of Maps. If a force with players destroys a tree, and if the tree doesn't leave a map as loot, there's a slight chance that a biter/spitter (living tree) or a worm (dead tree) will be spawned. The maximum size of the spawned biters/spitters depends on the pollution in a chunk, the maximum size of worms on the current evolution factor. If you have any mods that provide new biters/spitters or worms, these may be spawned as well as the vanilla entities.

Now biters literally grow on trees!

:-)

Hi!

Added remote interfaces in 0.3.24, described in FAQ, which is linked in the main description somewhere.

Didn't actually test using those from other mods, so let me know there are any bugs,

I'm currently working on adding additional UV lamps. The interface works for registering entities with your mod. However, you don't clean up global.uv_lights when entities become invalid. Using gvv to look at the table, I see:

uv_lights
--> [1] (destroyed lamp from your mod)
--> [2] (destroyed lamp from your mod)
--> [3] (destroyed lamp from my mod)
------> range = 12
------> en_hi = 0
------> en_lo = 0
--> [4] (valid lamp from your mod)
------> entity = LuaEntity

Is that intentional?

Hm, sounds like a bug, if it never actually cleans them up like that.

But I think it should, as "tracked" entities in all these sets are iterated over in steps (split between diff ticks) by the same run_on_object_set function, which should immediately drop an entity there if it's invalid.
They can persist in there for some time though, depending on intervals and work_steps values in the config.lua, which I think should be like 4 * 31 = 124 ticks for UV lamps, and nothing older than that.

I'll test it here, thanks for reporting.

Oh, sorry, my bad, it's not only those conditions.
On that 31st tick, mod also doesn't bother to run UV lamps' routines unless there are wisps on the map, which is likely not the case during daytime.
So I think you should see those leftover entitites gone once these lamps will be needed, or maybe do /c game.player.insert{name="wisp-yellow", count=50} and spawn those anytime to force it.

Guess this kind of lazy GC can be a potential problem with mods that create and destroy a lot of transient entities, like on every couple ticks or something.
Might be a good idea to document this somewhere that emit_once or explicit emit_stop might be a good idea for those use-cases.

Thanks for looking into this!

Oh, sorry, my bad, it's not only those conditions.
On that 31st tick, mod also doesn't bother to run UV lamps' routines unless there are wisps on the map, which is likely not the case during daytime.
So I think you should see those leftover entitites gone once these lamps will be needed, or maybe do /c game.player.insert{name="wisp-yellow", count=50} and spawn those anytime to force it.

Using Creative Mod, I disabled "Freeze daytime", set game speed to 20 and let the game run for some minutes (real time). That didn't help at all to get the invalid entries removed. (Alas, it was not a real game, I just cheated a power source and some UV lamps, so there was no real production and that may be the reason why no wisps were spawned.) After releasing one of the yellow wisps I got using your command, the records were gone.

Guess this kind of lazy GC can be a potential problem with mods that create and destroy a lot of transient entities, like on every couple ticks or something.

Actually, my mod just may just create some new prototypes (depending on settings). All I do in control.lua is calling emit_start when one of the build events is raised. I guess it really wouldn't make sense in my case to listen to removal events and call emit_stop as well.

Yeah, don't think it should be an issue at all, until there's maybe like a million of these empty tables piling up instead of 10-100 or something.

It has taken some time, but I've just uploaded a new version of Inlaid UV-lamps that will use your remote functions. :-)

I think you have extra spaces in the description there atm, which throws off markdown parser and makes links look weird.

Thanks, never noticed that! I wonder how the spaces got there -- it wasn't just a random typo, but consistently in every link. But it's fixed now…