I've just seen your statement "Does NOT work in multiplayer". Fixing this is a bit more work than the other two bugs as you'll have to check your complete control.lua for correct use of variables.

As I've been testing some of my own mods, the Lua API global Variable Viewer (gvv) was active and I added these lines to the top of your control file:

if script.active_mods["gvv"] then
  require("__gvv__.gvv")()
  log("Enabled support for gvv!")
end

While inspecting your mod's data (start the game and enter /gvv at the console to open its GUI), I noticed that you have initialized the following tables:

• global.ball_list
• global.velocity_list
• global.shadow_entity_association
• global.map_tags
• global.flag_list
• global.hit_counts
• global.walking_players

When I put down a flag and two balls, both global.ball_list and global.flag_list remained empty. However, I noticed that all of the tables under global are duplicated as global variables in your mod's environment, and the missing entities are stored in global ball_list and global flag_list.

In Factorio, there is a clear distinction between global variables and the mod's table global. You definitely should read the explanation of global in the API-Docs!

Why is this distintion important? Well, everything that is stored in the table global will be stored when the game is saved. The worst thing that can happen in single player if you don't store things in table global is that your data will be lost when you save and reload a game. However, in multiplayer mode it is of crucial importance that all players have the same game state. If a player tries to connect to a running game, the player's computer is trying to synchronize the mod data (stored in the mod's table global) with the server. If you run code depending on data stored in global, everything is OK (it's the same for all players); if you depend on a local or global variable that is not the table global, there's a good chance that the value of that variable is different for different players -- so your mod will cause desyncs.

So if you want to avoid desyncs, make sure that everything that should go into one of the subtables of your table global really is stored there, and not in a transient table in your environment!