Hello, nice mod!

For this mod to be compatible with Multiple Unit Train Control, Renai Transportation, and others, you will need to add handling for the events "script_raised_built" and "script_raised_destroy" to detect when the scripts create and delete locomotive entities. For it to work with MUTC, there will also need to be a way for it to recognize "battery-locomotive-mu", "battery-locomotive-mk2-mu", and "battery-locomotive-mk3-mu" as battery locomotives. Let me know if you are interested in working on this!

Or I can add a blacklist entry so my mod does not disable your locomotives accidentally, which is what happens at the moment.

Cheers,
robot256

Thank you for your advice.

I didn't know these events. I will add handling for the events "script_raised_built" and "script_raised_destroy".

I want to release this change as the next version. https://github.com/KoharaKazuya/BatteryLocomotive/commit/a67c5373b1e692643faea5f9c4b3aa00f4484672
Sorry, I don't know the details for MUTC. Do you need other changes of my mod?

Your "is_battery_locomotive()" function needs to return "true" for the new entities that MUTC creates. Those entities will be called "battery-locomotive-mu", "battery-locomotive-mk2-mu", and "battery-locomotive-mk3-mu", so you could just hard-code them in your list of valid locomotives.

Or you could make the list dynamic and add a remote interface, so that other mods can add as many "battery locomotive" types as they want. There are a couple other ways to do that as well.

Thanks for the kind explanation.

https://github.com/KoharaKazuya/BatteryLocomotive/commit/3a0f8894e69ea4e4078853bb8ee487ab83e83d48
I will release the next version after some tests.

I learned of a new event myself this week, "on_entity_cloned". You will need to handle it and treat the "destination" entity as a newly built entity. That way i will be compatible with Space Exploration.

I would also suggest a better Lua structure for your global. You can store each entry using "global.locomotive_types[name]=true" and then check if a name is in the list by saying "if global.locomotive_types[name] then". (Lua technically does not have arrays, only dictionary tables where the key can be any value, not just a number. If a key does not exist in the table, asking for it returns "nil" which evaluates to false.)

Hmm, another event I didn't know.
commit: https://github.com/KoharaKazuya/BatteryLocomotive/commit/859b57d0d225811025b297df9324cb0119c3ee35

The data structure looks good and conventional on Lua.
https://www.lua.org/pil/11.5.html
I will change.
commit: https://github.com/KoharaKazuya/BatteryLocomotive/commit/ae460769bd540b060ef65b4e81e364f6d44f364a

If you have any other concerns, please let me know.

Note (for me):
I tested by these commands.

/c game.surfaces[1].find_entities_filtered{name="battery-locomotive"}[1].clone({position={0,0}})
/c game.surfaces[1].clone_area{source_area={{32,0},{64,32}},destination_area={{64,0},{96,32}}}

Looks good!

As far as other comments, I noticed you have a "garbage collection" running every 3 seconds to check for hidden receiver entities that don't have a locomotive anymore. Especially important, "find_entities_filtered" on the entire map takes a LOT of CPU time so you shouldn't run it any more than necessary. Is there a reason why you are doing this? It looks like receivers will always be deleted because of the event when their locomotive is destroyed, so normally there should be no "orphans" left on the map.

In my mods I do still have a garbage collection searching the entire map for invalid entities, but I only run it in on_configuration_changed. That is because when other mods change, entities can disappear from the map without any other event being called. But in this case the performance is okay because it only executes once when the map is reloaded. Helpful side effect is that the map will be "cleaned" every time a mod is installed or updated.

It is a safeguard in case an uncontrolled receiver entity is created due to unexpected behavior. For example, LuaSurface's clone_area may duplicate the receiver entity.

I don't want to consume CPU time, so I made sure to check when the event occurs. Thanks!
commit: https://github.com/KoharaKazuya/BatteryLocomotive/commit/3dfc365da2ca9bdfe283d4bf65f14df3c8fb8f15

Cool. Don't forget to add the full search to on_configuration_changed. It will catch the case where, for example, my mod creates a new Battery Locomotive and your mod creates a receiver for it, then my mod is uninstalled and the loco vanished.

Oops, I hadn't thought of that case. Fixed it.

A new version (v1.2.0) has been released.
This release was made possible by many contributions from robot256. Thanks!

Hey there, I finally got around to testing this mod interface. (I see it is copied into electric-shuttle-train as well).

It doesn't work at all right now, I believe because the remote interface does not add a "locomotive_fuel_map" entry for the newly added locomotive. For MU locomotives, I would need to copy the fuel type of the non-MU locomotive.

The solution is to add a second remote interface function so I can retrieve what fuel is assigned to each locomotive. Then add a second argument to the "register_locomotive_type" function to set what fuel the new loco should use. I think this will require making "local locomotive_fuel_map" into a global table alongside "global.locomotive_type_names".