Factorio Forums

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

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

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

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

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

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 wrote:Is on_player_created always after on_load and on_init but before the first on_tick?

Klonan wrote:

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

ssilk wrote: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 wrote:on_player_created was guaranteed to always be called before a player experiences a tick

Nexela wrote:

Optera wrote: 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)

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

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