Factorio 2.0 update

[RedRafe]

Updated code to Factorio 2.0 API

Relevant changes

• [2.0] Updated .luackeckr with new classes, defines, and methods. game may be a bit out-of-date due to the very long list of methods it still holds
• [2.0] Type of LuaObjects is now "userdata" instead of "table". Removed __self from the LuaObjects. Intended way of checking if an object is a lua object is to check type is userdata.
• [2.0] Added new controller type (remote), which is to build space platforms, so it allows ghost building but not any physical manipulation. Added LuaPlayer::physical_surface, physical_surface_index, physical_vehicle and physical_position read. Accessing LuaPlayer::position will return player's remote position, if available. Need to keep an eye on .position checks. Suggest to use LuaPlayer::character::position for future works to disambiguate any doubt about wanting to access player's "virtual" position or "physical" position.
• [2.0] Changed logistic networks to use LuaLogisticPoint. Added util logistic_point_util.lua
• [2.0] Changed on_cutscene_waypoint_reached event's parameter "waypoint_index" to not be zero indexed. Need to test the ported Cutscene module.
• [2.0] Added LuaRenderObject. All LuaRendering methods for manipulating object selected by id were moved to LuaRenderObject.
• [2.0] LuaBootstrap::raise_event()'s and LuaBootstrap::on_event()'s "event" now also accepts event names as string as alternative to their numerical IDs.
• [2.0] Removed the "flying-text" entity type. Use LuaPlayer::create_local_flying_text or LuaRendering::draw_text instead. utila.game.lua has been updated to replace all instances of it.
• [space-age] Removed satellite item & recipe.
• [space-age] Quality may break many inventory/item manipulations with additional param .quality added to old LuaItemStack. It's generally safe to use ItemStacks in vanilla, as quality = normal will be set as default.

[RedRafe]

I managed to fix the test suite which was broken in the new API (@grilledham you'll have to take a look at utils.test.discovery.lua because I just plugged in whatever worked but I understand very little of it).

Now we can run tests and 50% of tests are broken. However, all the utils/gui tests pass while the features dont. I think it may be cause by this function used to setup the tests:

function Public.modify_lua_object(context, object, key, value)
    local old_value = object[key]
    rawset(object, key, value)

    context:add_teardown(function()
        rawset(object, key, old_value)
    end)
end

rawset may not work with new LuaObjects of type userdata.

[grilledham]

I managed to fix the test suite which was broken in the new API (@grilledham you'll have to take a look at utils.test.discovery.lua because I just plugged in whatever worked but I understand very little of it).

Now we can run tests and 50% of tests are broken. However, all the utils/gui tests pass while the features dont. I think it may be cause by this function used to setup the tests:

function Public.modify_lua_object(context, object, key, value)
    local old_value = object[key]
    rawset(object, key, value)

    context:add_teardown(function()
        rawset(object, key, old_value)
    end)
end

rawset may not work with new LuaObjects of type userdata.

I'll look at it later. I think for now it's fine for the tests to not be passing.

[grilledham]

This is amazing work, thanks for taking the time to do this, very much appreciated.

I can't really test this until after SA launches, but the changes look fine to me.

You have my approval to merge this after we update the server to 2.0/SA.

[grilledham]

Regarding your comments in the other PR, this one:

There are some of our features that are built-in in 2.0, i.e.
lanfill remover: landfill tiles act like other tiles and can be deconstructed after placed with default decon planner (+ there's super-force-build and undo mechanics that already mess with player actions so I'd just keep new base game and deprecate ours)
spidertron control: now possible to drag and select spidetrons to remote control without the remote item (deprecate module as well)
disable loaders?

Do you want to delete the landfill remover, spidertron control and loader code as part of this PR?

[RedRafe]

Regarding your comments in the other PR, this one:

There are some of our features that are built-in in 2.0, i.e.
lanfill remover: landfill tiles act like other tiles and can be deconstructed after placed with default decon planner (+ there's super-force-build and undo mechanics that already mess with player actions so I'd just keep new base game and deprecate ours)
spidertron control: now possible to drag and select spidetrons to remote control without the remote item (deprecate module as well)
disable loaders?

Do you want to delete the landfill remover, spidertron control and loader code as part of this PR?

Honestly I didnt test this part at all. I'm fine keeping it for now (modules may be disabled by default) and come back to check when testing the scenarios to see why it was needed and if new behavior can substitute it or just the entire feature as QoL

[grilledham]

Regarding your comments in the other PR, this one:

There are some of our features that are built-in in 2.0, i.e.
lanfill remover: landfill tiles act like other tiles and can be deconstructed after placed with default decon planner (+ there's super-force-build and undo mechanics that already mess with player actions so I'd just keep new base game and deprecate ours)
spidertron control: now possible to drag and select spidetrons to remote control without the remote item (deprecate module as well)
disable loaders?

Do you want to delete the landfill remover, spidertron control and loader code as part of this PR?

Honestly I didnt test this part at all. I'm fine keeping it for now (modules may be disabled by default) and come back to check when testing the scenarios to see why it was needed and if new behavior can substitute it or just the entire feature as QoL

Ok, so do we want to just disable these modules by default in the minimal scenario I made? I can do that if you would prefer?

[RedRafe]

Regarding your comments in the other PR, this one:

There are some of our features that are built-in in 2.0, i.e.
lanfill remover: landfill tiles act like other tiles and can be deconstructed after placed with default decon planner (+ there's super-force-build and undo mechanics that already mess with player actions so I'd just keep new base game and deprecate ours)
spidertron control: now possible to drag and select spidetrons to remote control without the remote item (deprecate module as well)
disable loaders?

Do you want to delete the landfill remover, spidertron control and loader code as part of this PR?

Honestly I didnt test this part at all. I'm fine keeping it for now (modules may be disabled by default) and come back to check when testing the scenarios to see why it was needed and if new behavior can substitute it or just the entire feature as QoL

Ok, so do we want to just disable these modules by default in the minimal scenario I made? I can do that if you would prefer?

I wouldn't remove them without testing. Having them still in 2.0 will not cause any issue, just redundancy if built-in feature will cover 100% of the cases we use them for. Let's just say it'll be a good "first issue" to port or remove code in 2.0 if checking with the scenarios reveals those modules are not needed anymore

Edit. There'll be probably many other modules and tasks that havent been updated in years even in recent version of 1.0-1.1 that I didn't catch with the eye at first glance but could now be optimized or removed in 2.0 other than these 2 examples I believe