Mod changes in 0.13

[binbinhfr]

Nice news that I missed.

But can you confirm that there will be a on_player_connected event ?
I start a thread here, not to pollute this general thread :
viewtopic.php?f=33&t=25484

[Choumiko]

But can you confirm that there will be a on_player_connected event ?

I think he did: (last 2 events)

- Added several player related events: on_player_cursor_stack_changed, on_player_main_inventory_changed, on_player_quickbar_inventory_changed,
on_player_tool_inventory_changed, on_player_armor_inventory_changed, on_player_ammo_inventory_changed, on_player_gun_inventory_changed,
on_player_placed_equipment, on_player_removed_equipment, on_pre_player_died, on_player_died, on_player_respawned, on_player_joined_game, on_player_left_game

[binbinhfr]

Yes, bob told me. As we say in France, I must have some shit in my eyes

[seronis]

Changes and Additions look great. One question though:

Removed game.regenerate_tiles().

I believe some of the mods like Train Outposts or RSO use this. Is there an alternative that they should have been using ?

[Adil]

And just so you're not discouraged by those breaking changes this is the list of additions/new things coming in 0.13 related to the mod API:

I'm more horrified by the vast possibility space opened by the second list.

[Simcra]

- Added LuaGame::delete_surface. Deletes the surface passed in if the surface is deletable.
- Added LuaSurface::deconstruct_area() - deconstructs an area as if the player did it.
- Added LuaSurface::cancel_deconstruct_area() - cancels deconstruction over an area as if the player did it.
- Added events for tile building: on_player_built_tile, on_player_mined_tile, on_robot_built_tile, on_robot_mined_tile
- Added LuaEntity::player, returns the player connected to the character entity.
- Added LuaTilePrototype accessible from LuaTile::prototype and LuaGameScript::tile_prototypes.

Awesome, I will greatly benefit from these! Are we going to get more access to surface generation in future? It's impractical and inefficient to use the on_chunk_generated event to remove entities and replace tiles. It would make more sense to be able to define world generation in greater detail with MapGenSettings.

[DedlySpyder]

- Added LuaGame::delete_surface. Deletes the surface passed in if the surface is deletable.
- Added LuaSurface::deconstruct_area() - deconstructs an area as if the player did it.
- Added LuaSurface::cancel_deconstruct_area() - cancels deconstruction over an area as if the player did it.
- Added events for tile building: on_player_built_tile, on_player_mined_tile, on_robot_built_tile, on_robot_mined_tile
- Added LuaEntity::player, returns the player connected to the character entity.
- Added LuaTilePrototype accessible from LuaTile::prototype and LuaGameScript::tile_prototypes.

Awesome, I will greatly benefit from these! Are we going to get more access to surface generation in future? It's impractical and inefficient to use the on_chunk_generated event to remove entities and replace tiles. It would make more sense to be able to define world generation in greater detail with MapGenSettings.

Can't you already do that? (I never have, but the api suggests it's possible)

http://lua-api.factorio.com/0.12.34/Lua ... te_surface

[binbinhfr]

oh yes you can.
see this mod :
viewtopic.php?f=97&t=19178

[Simcra]

oh yes you can.
see this mod :
viewtopic.php?f=97&t=19178

TL;DR: It's not possible to specify terrain segmentation none, therefore you cannot create empty surfaces.

[sparr]

- Changed "defines" so they're available by default and removed the defines.lua file.

Why not leave an empty defines.lua, so that mods for which this is the only breaking change won't be broken?

[DaveMcW]

Why not leave an empty defines.lua, so that mods for which this is the only breaking change won't be broken?

Because they care more about having a clean file system than supporting old mods.

[sparr]

Why not leave an empty defines.lua, so that mods for which this is the only breaking change won't be broken?

Because they care more about having a clean file system than supporting old mods.

If the filesystem itself is the concern, then the definition of require() could be changed to discard attempts to require "defines". This change could be removed in 0.14. Deprecating API features before removing them is common practice, it gives API users time to change their code without things breaking.

[Rseding91]

Why not leave an empty defines.lua, so that mods for which this is the only breaking change won't be broken?

Because they care more about having a clean file system than supporting old mods.

If the filesystem itself is the concern, then the definition of require() could be changed to discard attempts to require "defines". This change could be removed in 0.14. Deprecating API features before removing them is common practice, it gives API users time to change their code without things breaking.

I've never seen that work. Everyone just keeps using the deprecated things until they're eventually removed and they're forced to fix it. It's a simple line deletion - even a "find and replace" will do.

[sparr]

Everyone just keeps using the deprecated things until they're eventually removed and they're forced to fix it. It's a simple line deletion - even a "find and replace" will do.

Not everyone. Just some. Responsible/active mod devs will make the change. By giving one version for the deprecation, you let responsible devs have mods that don't break. If a dev ignores the deprecation period then it's their fault when their mod breaks a version later. If you remove things with no deprecation period then any time players can't play because their mods are broken is your fault.

Even though I know the change is coming, I can't publish a fix right now because people would download it and get a broken-in-0.12 mod. So I've got to hope I'm awake with 0.13 releases and coordinate a release. That's silly.

[DaveMcW]

They do give you several months between the .0 release and stable. But then they spend a year hyping the next .0 release so everyone upgrades instantly.

[DaCyclops]

Everyone just keeps using the deprecated things until they're eventually removed and they're forced to fix it. It's a simple line deletion - even a "find and replace" will do.

Not everyone. Just some. Responsible/active mod devs will make the change. By giving one version for the deprecation, you let responsible devs have mods that don't break. If a dev ignores the deprecation period then it's their fault when their mod breaks a version later. If you remove things with no deprecation period then any time players can't play because their mods are broken is your fault.

Even though I know the change is coming, I can't publish a fix right now because people would download it and get a broken-in-0.12 mod. So I've got to hope I'm awake with 0.13 releases and coordinate a release. That's silly.

But you will still need to be awake, because you are going to need to sign into the mod portal and create your mod in there.

Considering the number of large-scale changes they are making (next major release, introduction of Modportal, refactoring of legacy itemnames, removal of legacy functions, introduction of specialised functions) it doesnt seem like something that major. And if you use a CVS like Github, just have the release sitting there as a pre-release ready to set "live" the moment you get to it.

And worst case scenario, you could just do some code to say "If 0.13-only API code returns Null, get defines.LUA because its 0.12"

[Choumiko]

I simply added

Code: Select all

if not defines then
  require "defines"
  defines.trainstate = defines.train_state
end

(and applied the renaming changes in the code.)
That should at least make them load with 0.13 and 0.12

[ratchetfreak]

Why not leave an empty defines.lua, so that mods for which this is the only breaking change won't be broken?

Because they care more about having a clean file system than supporting old mods.

If the filesystem itself is the concern, then the definition of require() could be changed to discard attempts to require "defines". This change could be removed in 0.14. Deprecating API features before removing them is common practice, it gives API users time to change their code without things breaking.

I've never seen that work. Everyone just keeps using the deprecated things until they're eventually removed and they're forced to fix it. It's a simple line deletion - even a "find and replace" will do.

Add a nag log entry (aka warning) for each use of require("defines") or include("defines")

That tends to help in the change over

[sparr]

I simply added

Code: Select all

if not defines then
  require "defines"
  defines.trainstate = defines.train_state
end

(and applied the renaming changes in the code.)
That should at least make them load with 0.13 and 0.12

Great solution.

[Adil]

I can't comprehend these:

- Changed game.players, game.surfaces, game.entity_prototypes, game.item_prototypes, game.fluid_prototypes, force.recipes, force,technologies
to use custom access + iterator objects for improved performance.

Weren't game.entity_prototypes and such already indexable by []?