Hi! While looking at your code to check for compatibility with Autodrive, I've noticed some things that could be improved:

• You've stumbled into the same trap as I did. In control.lua, function entityToTable, lines 97-104, you have:

  local from = car.get_inventory(id)
  if from ~= nil then
      local to = game.create_inventory(#from)
      for i in range(1, #from) do
          to[i].swap_stack(from[i])
      end
      inventory[id] = to
  end
  

Did you ever try to log the value of variable 'from'? It seems that cars always have all car-related inventories (ammo, fuel, trunk, and burnt_result) -- even if they don't require ammo or fuel. Therefore, the condition from ~= nil will always be true. What you're really interested in isn't whether the inventory exists, but how many slots it has (inventories with 0 slots will be hidden but still exist): if #from > 0 then. If you want to play it safe, you could extend this to if from and #from > 0 then, but I don't think that's really necessary.

• Some lines below that, you've this comment:

  -- math.atan2 is deprecated, since math.atan should provide the same result,
  -- but at least in factorio, it doesn't!
  -- Actually, taking a closer look, it looks like factorio might use an older version
  -- of lua

Your assumption is correct: According to the Factorio API Docs, "[m]ods are written in Lua 5.2". This certainly is quite an old Lua version, but keeping that version prevents that mods break due to changes in the language.

• Your handler for defines.events.on_entity_damaged contains this line:

  if event.cause ~= nil and event.entity.name == "auto-carrier" and event.cause.train == nil and event.entity.force.is_friend(event.cause.force) then

The check for event.entity.name == "auto-carrier"is not necessary if you use the LuaEntityDamagedEventFilter:

script.on_event(defines.events.on_entity_damaged, function(event) 
  … 
  end,  { 
    {filter = "name", name = "auto-carrier"}, 
  }
)

Using event filters is also more efficient because filtering is done directly by the game (which is faster than in Lua).

• Still in on_entity_damaged, you have

  event.entity.health = event.final_health + event.final_damage_amount

I assume you want to restore entity.health to exactly the same amount as it had before taking damage. However, this doesn't work as expected because entity.health will always be limited to 0 <= entity.health <= entity.prototype.max_health. Therefore, if event.final_damage_amount > event.entity.health, adding event.final_damage_amount again would give the vehicle more health than it had before the event.

• In your handler for "auto-carrier-deploy", you have

  local entities = player.surface.find_entities({
  {player.position.x - 5, player.position.y - 5},
  {player.position.x + 5, player.position.y + 5},
  })
  for _, e in ipairs(entities) do
  if e.name == "auto-carrier" then
  …
  end
  end

As you're interested only in "auto-carrier" entities, you could improve this by using a filtered search:

  local entities = player.surface.find_entities_filtered({
    area = {
      {player.position.x - 5, player.position.y - 5},
      {player.position.x + 5, player.position.y + 5},
    },
    name = "auto-carrier",
  })
  for _, e in ipairs(entities) do
      …
  end

Now, about compatibility: I'm actually concerned not only about Autodrive, but also about GCKI. I need to know when a vehicle controlled by any of my mods disappears, or shows up again. When a vehicle is loaded onto your carrier, I'd like to preserve some data needed by my mods, and when it's unloaded again, I'd like to read back these data.

Also, Autodrive expects all vehicles to have a grid (it will extend existing grids that are too small, or add a grid if the prototype doesn't have one). You really should make sure to save/restore grids as well as inventories! Also, while vanilla vehicle do not have a burnt_results inventory, some modded vehicles do (check out IR3, for example). So you should add this to the inventories you copy.

Do you know Vehicle Wagon by any chance? It's similar to your mod, just a bit more complex. :-) I've worked together with robot256 (the current maintainer), adding remote functions on both ends that we can respond to. With some slight adjustments, they should be reusable.

If you'd like to cooperate on making our mods compatible, please reply here or send me a private message on the forum!