Factorio Forums

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

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

I think he did: (last 2 events)

Rseding91 wrote: - 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

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

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 ?

Rseding91 wrote: 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.

Rseding91 wrote:- 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.

Simcra wrote:

Rseding91 wrote:- 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

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

binbinhfr wrote: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.

Rseding91 wrote:- 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?

sparr wrote: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.

DaveMcW wrote:

sparr wrote: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.

sparr wrote:

DaveMcW wrote:

sparr wrote: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.

Rseding91 wrote: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.

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.

sparr wrote:

Rseding91 wrote: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"

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

Rseding91 wrote:

sparr wrote:

DaveMcW wrote:

sparr wrote: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

Choumiko wrote: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.

I can't comprehend these:

Rseding91 wrote: - 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 []?