Please make defines.events.on_player_created more predictable

[Yehn]

defines.events.on_player_created

This event either does not fire when freeplay starts now, or it fires before the character/their inventory is valid. This means that previous functionality that relied on defines.events.on_player_created to spawn stuff for a player at the start of the game must now rely on defines.events.on_cutscene_cancelled.

I do not like using defines.events.on_cutscene_cancelled as a workaround as this will create issues if a mod (or perhaps future vanilla content!) uses cutscenes outside of the game's start.

I would like for defines.events.on_player_created to consistently fire when a player is created, even if cutscenes are involved, so I can be completely sure that a given code block runs once and only once for that player.

[Deadlock989]

If this is about TinyStart - you can use remote calls to the freeplay scenario script to set up starting and respawn inventories and even disable the initial cutscene completely if it is causing other issues somehow. In my experience those work reliably regardless of whether the game start cutscene is activated or not.

[Yehn]

If this is about TinyStart - you can use remote calls to the freeplay scenario script to set up starting and respawn inventories and even disable the initial cutscene completely if it is causing other issues somehow. In my experience those work reliably regardless of whether the game start cutscene is activated or not.

I've been told in the Factorio discord that the remote calls do not work for complex items (eg power armor). Disabling the cutscene is in consideration as it interferes with more than just TinyStart but... I'd really like to avoid that kind of impact on end users.

Still the workarounds for getting around the freeplay setup/cutscene script look so weird (basically moving a lot of stuff out of on_init() and on_player_created() into somewhat-alike functions?) that it may ultimately be the best option, particularly since remote interface doesn't cover stuff that would allow for compatibility with Clockwork, for example. But, again, I want to avoid that kind of end user impact if possible...

[Deadlock989]

I've been told in the Factorio discord that the remote calls do not work for complex items (eg power armor). Disabling the cutscene is in consideration as it interferes with more than just TinyStart but... I'd really like to avoid that kind of impact on end users.

I'm not sure what you mean exactly - there may be some detail here that I'm not appreciating - but you can use the remote calls to give the player armour that has an equipment grid just fine, I do it - the first armour given is automatically equipped. I guess you would have issues if you wanted to manipulate the armour's grid only after it was given (e.g. at the end of the cutscene when the character is valid). In my mind the choice there would be simple - either (a) just give them the equipment and let them set it up themselves or (b) kill off the cutscene. Option (c) would be to make your own cutscene that has your own hooks to do what you want to do with armour, based on freeplay's or otherwise, but that sounds like a lot of work for a little reward. I went for (a)+(b).

I'm not speaking against your interface request by the way but I can see that there was previous discussion on the forum around it already and not much came of it rather than "use freeplay or cancel it and perhaps make your own", so was just suggesting alternatives.

[Yehn]

I've been told in the Factorio discord that the remote calls do not work for complex items (eg power armor). Disabling the cutscene is in consideration as it interferes with more than just TinyStart but... I'd really like to avoid that kind of impact on end users.

I'm not sure what you mean exactly - there may be some detail here that I'm not appreciating - but you can use the remote calls to give the player armour that has an equipment grid just fine, I do it - the first armour given is automatically equipped. I guess you would have issues if you wanted to manipulate the armour's grid only after it was given (e.g. at the end of the cutscene when the character is valid). In my mind the choice there would be simple - either (a) just give them the equipment and let them set it up themselves or (b) kill off the cutscene. Option (c) would be to make your own cutscene that has your own hooks to do what you want to do with armour, based on freeplay's or otherwise, but that sounds like a lot of work for a little reward. I went for (a)+(b).

I'm not speaking against your interface request by the way but I can see that there was previous discussion on the forum around it already and not much came of it rather than "use freeplay or cancel it and perhaps make your own", so was just suggesting alternatives.

I do appreciate the suggestions. I am looking at all the different options for the messes this cutscene business has created across my different mods...

[Rseding91]

I would like for defines.events.on_player_created to consistently fire when a player is created, even if cutscenes are involved, so I can be completely sure that a given code block runs once and only once for that player.

That is exactly what happens now.

Except the freeplay scenario immediatly in on_player_created does start-cutscene which disconnects the character from the player and puts them into the cutscene.

This is something any mod can do at any time; irrelevant of the freeplay scenario.

What you want is a way to get a reference to the character entity while in a cutscene. And then for every quick-start mod out there to properly deal with the different controller types a player may be using.

[Yehn]

What you want is a way to get a reference to the character entity while in a cutscene. And then for every quick-start mod out there to properly deal with the different controller types a player may be using.

This does sound like the most reliable way to deal with it. Any time a player's character might be referenced even beyond the game start, should others start making use of cutscenes...