Inefficient LV Lights

[BuckarooBanzay]

The LV lights generate quite a lot of lag:

(LV Circuit with 8 thermal generators and 8 LV LED's/Lights)

I haven't looked at the code but i think some of the issues can be addressed with VManips and possible batching/async execution...

[OgelGames]

Even using find_nodes_in_area() here could help, 147 get_node() calls every update isn't very performant: https://github.com/mt-mods/technic/blob/abfee81091670ec20fe5ef2c59ab60e1f13683bd/technic/machines/LV/lamp.lua#L9-L26

EDIT: looking at the code a bit more, I see quite a lot of places for optimization and improvement for both LV lamps and LED's... 🤔

[S-S-X]

For LV lamps it would be interesting to see if invisible light emitting particles could replace nodes and how it would affect performance.

Light emitting entities would be near ideal solution because of accurate lifecycle control, no cleanup hacks (jumpdrive for example) and no area loading needed (if I some day manage to implement #148 proposal) but I think engine does not allow light emitting entities currently.

Problem with particles is that you need to respawn those very often because you cannot control (remove) particles after spawned so lifetime cannot be long. Basically to turn lights off one has to wait for particles to expire. Upside is near zero server side workload if particle spawners are used.

Both solutions would allow almost guaranteed bug free implementation without having to worry about cleanup ever. However with particles network lag can cause flickering and for good network connection lifetime has to be at least as long as network execution cycle.

edit. Basically that would mean completely rewriting lighting code, removal of lighting nodes and LBM to cleanup lighting nodes from world. Also #148 actually does not matter here because simply using nodetimers can get around that to only update active areas, however using nodetimers will also remove time used for lighting from lag metrics and therefore performance impact should be measured manually without multitool or generic technic lag monitoring.

[OgelGames]

I think engine does not allow light emitting entities currently.

Yep, only self-illuminated entities/particles.

removal of lighting nodes and LBM to cleanup lighting nodes from world

That would break (or rather darken) a lot of builds, I know at least myself and some others have built things using those as lighting.

[S-S-X]

Do particles emit "real" light? Environment (nodes around particle) will be illuminated but I think that is client side only and therefore wont allow real server side lighting that is required for example growing your veggies...

[OgelGames]

They don't emit any light at all, they only light their own texture(s), nodes are completely unaffected.

[S-S-X]

Peanut just reported same / very similar problem. This really needs some optimization for performance, I was watching network reports and 7 gen 16 lamp 1 battery reported around 230-270ms execution time while average for other 80 networks were around 0.5ms and worst large machine network was jumping between 10ms-20ms.

[S-S-X]

Random few seconds delay for each lamp to spread out load? That would be very simple and wont require nodetimers.

Just that alone however wont be able to restore missing lights, however after turning on/off in loaded areas it should be enough to do restoration only in active areas. So maybe still nodetimers unless there's some good way to check if area is active during technic_run.

[S-S-X]

Could also try to go with vm which is already used by networks. Get vm handle before network run loop, collect updates and execute all at once after network loop. That could then also be extended to other node swapping done for machines.