game.print in on_init?

[Optera]

I'm a bit confused as to why game.print doesn't work in on_init.
Checking active mods with game.active_mods works fine, but posting a message about found mods wont.

[Choumiko]

i think on_init() is run before any player is created.
Doing

Code: Select all

for i, p in pairs(game.players) log(i) end

in on_init() should confirm it (or not)

[Optera]

Seems like players are not created in on_init.
Probably game.print can write to nil since it doesn't throw an error. I was kind of hoping it'd buffer messages and post them once players are created.

[Nexela]

Seems like players are not created in on_init.

There are no players in on_init in a new map. Game.print should work on an existing world that already has players during on_init because:

Probably game.print can write to nil since it doesn't throw an error. I was kind of hoping it'd buffer messages and post them once players are created.

Game.print is probably doing something equivalent to this

Code: Select all

for _, player in pairs(game.players) do
print message
end

So if there are no players the loop won't run. since no one is in the forest they don't hear the tree fall

[Rseding91]

Game.print is probably doing something equivalent to this

Code: Select all

for _, player in pairs(game.players) do
print message
end

So if there are no players the loop won't run. since no one is in the forest they don't hear the tree fall

Correct. It's a simple shortcut so you don't have to do the loop yourself. It's the same with http://lua-api.factorio.com/latest/LuaF ... orce.print

[ssilk]

Hm. In theory the way to implement such a print would be to look, if any player is connected to the game. If not it remembers the to printed string in a global variable and initialize some event handler that prints this in the moment when all players are (re)connected.

[Optera]

Hm. In theory the way to implement such a print would be to look, if any player is connected to the game. If not it remembers the to printed string in a global variable and initialize some event handler that prints this in the moment when all players are (re)connected.

Basically what we have to do right now is store the strings, trigger a run_once part of on_tick, print all strings.
With that effort we can just as well move most of on_init and on_load into that run_once.

There should be an event on_load/init_complete that runs once when the Bootstrap phase is complete.

[Klonan]

Hm. In theory the way to implement such a print would be to look, if any player is connected to the game. If not it remembers the to printed string in a global variable and initialize some event handler that prints this in the moment when all players are (re)connected.

Basically what we have to do right now is store the strings, trigger a run_once part of on_tick, print all strings.
With that effort we can just as well move most of on_init and on_load into that run_once.

It wouldn't be too hard to do:

Code: Select all

function on_init()
  string = "This is what i want to print"
  string = string.." - This is some more info and what not"
  global.string = string
end

function on_player_created()
  if global.string then
    game.print(global.string)
    global.string = nil
  end
end

[Optera]

Is on_player_created always after on_load and on_init but before the first on_tick?

[Klonan]

Is on_player_created always after on_load and on_init but before the first on_tick?

On player created is after both on_init and on_load (you shouldn't need to use on_load for anything simple like this)

Im not sure, but i think it is before the first tick, the first player is created at tick 0, such that no tick has happened,
But i might be wrong

[Optera]

Is on_player_created always after on_load and on_init but before the first on_tick?

On player created is after both on_init and on_load (you shouldn't need to use on_load for anything simple like this)

Im not sure, but i think it is before the first tick, the first player is created at tick 0, such that no tick has happened,
But i might be wrong

Well it won't matter for my intent of simply informing players when RailTanker was found. Using on_player_created shaves one check off from on_tick so I'll use it to display the messages in console.
If on_player_created was guaranteed to always be called before a player experiences a tick I could also move the actual check for other mods there from on_init and on_configuration_Changed.

[Nexela]

If on_player_created was guaranteed to always be called before a player experiences a tick I could also move the actual check for other mods there from on_init and on_configuration_Changed.

Some things Keep in mind
on_player_created is only run once for each player (when the player is created) so adding your mod to an existing world this wouldn't run.
on_configuration_changed is run anytime any mod is added, removed, or version num changes (including "base")
on_init is run ONCE per world when it is first created. I.E in a new MP world New players joining won't get this, (same with on_config_changed I believe)

Hm. In theory the way to implement such a print would be to look, if any player is connected to the game. If not it remembers the to printed string in a global variable and initialize some event handler that prints this in the moment when all players are (re)connected.

Stdlib handles this by logging the tick. If game.tick is not available then tick is 0. then on any subsequent calls to the logger it flushes everything in the buffer if tick>last_tick.

on_player_created was guaranteed to always be called before a player experiences a tick

A player that isn't created won't have a tick

[Rseding91]

If on_player_created was guaranteed to always be called before a player experiences a tick I could also move the actual check for other mods there from on_init and on_configuration_Changed.

Some things Keep in mind
on_player_created is only run once for each player (when the player is created) so adding your mod to an existing world this wouldn't run.
on_configuration_changed is run anytime any mod is added, removed, or version num changes (including "base")
on_init is run ONCE per world when it is first created. I.E in a new MP world New players joining won't get this, (same with on_config_changed I believe)

Hm. In theory the way to implement such a print would be to look, if any player is connected to the game. If not it remembers the to printed string in a global variable and initialize some event handler that prints this in the moment when all players are (re)connected.

Stdlib handles this by logging the tick. If game.tick is not available then tick is 0. then on any subsequent calls to the logger it flushes everything in the buffer if tick>last_tick.

on_player_created was guaranteed to always be called before a player experiences a tick

A player that isn't created won't have a tick

http://lua-api.factorio.com/latest/LuaB ... ap.on_init
http://lua-api.factorio.com/latest/Data-Lifecycle.html