Hi, I found that this mod is overwriting certain events, which breaks all listeners on other mods. (Or so is my suspicion)
While trying to patch Concreep to work with Better Bots I came to this conclusion and I had to modify the control.lua of this mod instead.
I created a github repo with my patch for version 1.3.5 that works with Concreep on v0.18.16. I think it would be nice to include the different event handling in a future patch so it does not interfere with other mods. On a sidenote: All event triggers are now listed in a separate section on the bottom, which helps the overview :)
https://github.com/Vikko/better-bots-technologies

Hi!

Thanks for the input. This is really odd, as far as I know a mod shouldn't be able to override other mods event listeners. I'm using a large variety of event handlers in the mod and surely it would have broken down a lot of things by now.

I've looked into your patched version and spotted a bug. You are defining the on_tick function twice in line 187 and 270.

Line 187 is the correct on_nth_tick listener, line 270 is an on_tick listener which should then be set with:

script.on_event(defines.events.on_tick, on_tick, ... )

at the bottom of the script.

Also Factorio 0.18.18 changed roboports control behavior definition, so there's another fix to make it compatible with the latest version of the game (this is also the only change I made in 1.3.6)

Line 507 and 623 instead of:

local previous_control_behavior = {
mode_of_operations = c_be.mode_of_operations,
available_logistic_output_signal = c_be.available_logistic_output_signal,
total_logistic_output_signal = c_be.total_logistic_output_signal,
available_construction_output_signal = c_be.available_construction_output_signal,
total_construction_output_signal = c_be.total_construction_output_signal,
}

should be:

local previous_control_behavior = {
read_logistics = c_be.read_logistics,
read_robot_stats = c_be.read_robot_stats,
available_logistic_output_signal = c_be.available_logistic_output_signal,
total_logistic_output_signal = c_be.total_logistic_output_signal,
available_construction_output_signal = c_be.available_construction_output_signal,
total_construction_output_signal = c_be.total_construction_output_signal,
}

I'll be looking further into this issue to see what is causing it, I'm suspecting the usage of the stdlib maybe messing with something somehow?

Thanks

I've spotted another bug:

Line 371 is

fuction add_robotport(event)

there's an extra t (roboTport instead of roboport), so the function is never being registered as a listener and thus is never called. I have a strong suspicion that this is why the patched version was actually working, because it was never calling the upgrade_roboport_entity() function, practically excluding any mod functionality.
If I'm correct, you should be able to reproduce all the issues after researching a new tier of the Advanced Roboport technology while there are roboports on the map (this will force an upgrade_roboport on each existing roboport)

Tbh, my feeling is that this issue is not related to events, but rather to how my mod handles entities. I'm making a lot of entity swapping behind the scenes, because it's impossible to change the number of charging pads of an existing roboport entity (it's defined during prototype stage), so I have new roboport prototypes with slightly different properties that I silently swap whenever a new roboport is built or a new tier of the Advanced Roboport tech is researched.

To make things manageable, I'm not dealing with new roboport Items. The roboport Item is always a vanilla roboport, which means that anytime a roboport is built, a vanilla roboport is actually created and placed on the map, but this newly created roboport entity gets destroyed and replaced with the correct betterbots-roboport entity right away during the on_built_entity and on_robot_built_entity event handler.

My idea is that your mod listens to those events too and does its work based on the "soon to be obsolete" roboport entity, which causes all the trouble we are seeing.

Unfortunately I have no other way to do what the mod is supposed to do (having a technology that "unlocks" new charging pads for all roboports), they must be handled this way.

A solution that comes to mind would be raising those events again after my mod swaps the entity, so that any mod listening to those events may have a chance to deal with the real entity that is going to persist on the map. This may cause performance issues on maps with a very large amount of roboports.

Another approach could be using the script_raised_built event
https://lua-api.factorio.com/latest/events.html#script_raised_built
to notify that a new entity was placed by the mod, but that requires all other mods to be listening to this rather unusual event. This would be the most "canonically" correct way, I could include a reference to the destroyed roboport in the event parameters letting other mods handle the swap, but would require each mod to make itself compatible with mine which is very undesirable.

I'm going to be looking into this. Let me know if you keep testing or if you have any other input on the subject.

Thanks!

Hi, I think this is related to something I've discovered with Better Bots not triggering concreep anymore. It used to work, but now it doesn't? Capt Jack discovered that if you place roboports yourself, concreep doesn't work, but if you get the construction robots to do it, by placing a BP of a roboport, concreep works as expected.
Thanks!

Hello! It has been a while.. I've done some digging again and found the issue:
While Concreep works with manage_port() it does not with upgrade_roboport_entity().
The big difference there is the original port that is being destroyed when the new one is placed, so I tried disabling that..
And Concreep works again!
Placing ports with blueprints also triggers the manage_port function instead, so that matches with this insight.
Maybe by creating the entity on the same position and removing it again, its removed from the table or something.
I'm going to see if I can store its properties in variables, destroy it first and then create a new one. Lets see what happens :)

This is what did the trick:

https://github.com/Vikko/better-bots-technologies/blob/master/control.lua#L568

The new entities that are created did not fire any events! Fixed with a simple setting..