With a waypoint remote on hand, with the exception of the first waypoint, every other waypoint for a given spidertron freeze (for +/- 1s) my game when my hand (with the remote) hover over any entity!
When the remote was placing the first waypoint, everything works fine! The lag only happens when trying to place the second, third, etc...

Thanks.

Very strange. I don't know why the re-rendering takes so long when you only have a couple of waypoints to draw...

Presumably the same freeze occurs whilst holding the patrol remote if you enter a vehicle? (without the selected entity changing)

I don't know if you understand the problem. The lag occurs every time my mouse with the remote selected hover above any entity in the game (belt, assembler machine, pipe, etc). But only after I placed the first waypoint!

In my tests, I was on foot, next to my spidertron... The lag occurs in normal mode and in map view (if zoomed enough for the game render the entities).

Thanks.

I think I do understand. Whenever the player's cursor stack changes, driving state changes, or selected entity changes, the mod deletes all path renders and recreates the correct ones based on the current player state (it draws paths for any spidertron that is connected to a remote in your hand, that you are driving, that you have a GUI open, or you are selecting).

This isn't super efficient, but I've never had any performance problems with it before. Even with 60 waypoints, it is only causing spikes of 5ms (which is much less than 1 frame / 16ms). My only guess is that you have another mod which listens to on_chart_tag_added and does some expensive processing there.

Can you send a screenshot after the freeze, with debug options show-time-usage and hide-mod-gui enabled please?

I'm done a quick search for my mods that use the string "on_chart_tag_added" and I found two:

https://mods.factorio.com/mod/Teleporters
https://mods.factorio.com/mod/TagBook

I will try to make the tests you suggest and post here later.

I think TagBook is the likely culprit. It looks like processing added tags is at least a O(N^2) operation in that mod, which when many tags are added simultaneously could be very slow. It should be modified to ignore tags named "signal-waypoint" and "signal-orange-dot".

The tests I made:

https://imgur.com/a/0x1JFgJ

I took 2 screenshots: One before the freeze and another after the freeze.

Thanks.

Maybe it is just the mobile imgur website playing up, the those images are too blurry to read the text.
Can you try disabling tag book and seeing if the same issue happens?

I tested removing the mod "TagBook" and the slow down / freeze stopped. I will report this bug to the maintainer of that mod! I will also link this thread to the author.
Do you have any suggestions for him?

Thanks.

Good good - primarily Tag Book should just ignore the map tags called "signal-waypoint" and "signal-orange-dot".
And if he wants to investigate performance further, check out the VSCode factorio mod debugger which has an inbuilt profiler.

I hope that maintainer have a look on this. And sorry for the wrong report!

Thanks.

Well it isn’t (as far as I can tell) Tag Book’s fault particularly. It’s just an unfortunate collision between me creating lots of tags simultaneously and Tag Book (presumably) having to do expensive processing for each one.

Good good - primarily Tag Book should just ignore the map tags called "signal-waypoint" and "signal-orange-dot".
And if he wants to investigate performance further, check out the VSCode factorio mod debugger which has an inbuilt profiler.

Hi!
I am the author of the tagbook.
I will add ignoring your tags in the next update.
Thanks for the report!
I am aware of the performance issue when adding a large number of tags. At the moment I am developing a new concept of updating.

I think I do understand. Whenever the player's cursor stack changes, driving state changes, or selected entity changes, the mod deletes all path renders and recreates the correct ones based on the current player state (it draws paths for any spidertron that is connected to a remote in your hand, that you are driving, that you have a GUI open, or you are selecting).

This isn't super efficient, but I've never had any performance problems with it before. Even with 60 waypoints, it is only causing spikes of 5ms (which is much less than 1 frame / 16ms). My only guess is that you have another mod which listens to on_chart_tag_added and does some expensive processing there.

Can you send a screenshot after the freeze, with debug options show-time-usage and hide-mod-gui enabled please?

This method is very expensive for any listener method for this event.
I would suggest reworking this method.
For example, use custom events instead of tags.
For my part, the problem with updating tags will be fixed soon.
EDIT:
Looking at the concept of your mod. I would suggest moving away from tags. Create custom events with the right information for your mod that will place the sprite you want on the ground and run the logic of your spidertron mod.

I think TagBook is the likely culprit. It looks like processing added tags is at least a O(N^2) operation in that mod, which when many tags are added simultaneously could be very slow. It should be modified to ignore tags named "signal-waypoint" and "signal-orange-dot".

Did I understand correctly that this is the text of the tag?
tag.text = "signal-waypoint" or tag.text = "signal-orange-dot"
Right?

Well it isn’t (as far as I can tell) Tag Book’s fault particularly. It’s just an unfortunate collision between me creating lots of tags simultaneously and Tag Book (presumably) having to do expensive processing for each one.

The problem is that my mod sorts and searches for tags according to the user's settings.
This is an expensive operation in its concept.

I think TagBook is the likely culprit. It looks like processing added tags is at least a O(N^2) operation in that mod, which when many tags are added simultaneously could be very slow. It should be modified to ignore tags named "signal-waypoint" and "signal-orange-dot".

Did I understand correctly that this is the text of the tag?
tag.text = "signal-waypoint" or tag.text = "signal-orange-dot"
Right?

You need to check for the icon:

if check_icon and check_icon.type == "virtual" and (check_icon.name == "signal-waypoint" or check_icon.name == "signal-orange-dot") then
return true
end

I made a temporary fix locally:

https://textdoc.co/C5MrkL6zP90GZnbI

Thanks

Looking at the concept of your mod. I would suggest moving away from tags. Create custom events with the right information for your mod that will place the sprite you want on the ground and run the logic of your spidertron mod.

I'm not deliberately raising on_chart_tag_added, in fact, if I could I wouldn't raise it at all. But I need to create the chart tags so that the paths and waypoints are visible on the map.

if check_icon and check_icon.type == "virtual" and (check_icon.name == "signal-waypoint" or check_icon.name == "signal-orange-dot") then
return true
end

This looks about right.

Thanks for the quick update, DiRten. Hopefully this is now fixed :)

Thanks for the quick update, DiRten. Hopefully this is now fixed :)

My pleasure. :D
While a temporary measure.
Later I will recode the logic so that there are no problems with any other mod.