[0.14] player.connected behavior changed. Intended?

[credomane]

In 0.13.x player.connected was true if the player was currently in the game world and false otherwise. Single-player or multi-player. It didn't matter.
In 0.14.x player.connected is always false in single player and only true for connected players in multi-player.
[edit]
Slight change. When adding a mod to an existing save in single-player mode player.connected is false inside that mods on_init and on_configuration_changed handlers. After that is properly set to true for the player in the single-player game.
However in a multiplayer game adding a mod to an existing save player.connected is true inside that mods on_init and on_configuration_changed handler.
[/edit]

Is this change intended? That slight change has been causing me a slight headache.

[edit2]
The on_configuration_changed is affected in the same was as on_init

[Klonan]

Thanks for the report,

If i understand correctly, the player.connected is false on script.on_init and script.on_configuration changed?

[kovarex]

There are some differences in the way players are connected/disconnected in singleplayer/multiplayer. You should not rely on these properties in on_configuration_changed, just take what is there and handle properly player joined/left properly as we might always change the behaviour later on.

[credomane]

There are some differences in the way players are connected/disconnected in singleplayer/multiplayer. You should not rely on these properties in on_configuration_changed, just take what is there and handle properly player joined/left properly as we might always change the behaviour later on.

Yeah I changed my mod. In 0.13 there weren't any differences but in 0.14 there were. So I wasn't sure if that was intended or not.

Seeing as this is moved to "Not a Bug" guess it is intended. Until it is changed again I can detect if the game is single player or multi-player with one player.

[azaghal]

Sorry for resurrecting this thread, but I was curious to know if anything has changed compared to the time this was reported (currently using 0.18.36).

I was trying to debug an error related to one of the mods I'm using, and ended-up looking into behaviour of the LuaPlayer::connected property.

I have observed two different results for the property depending on how the player got disconnected from the server. This was observed with one minimalist mod that merely logs the property in its LuaBootstrap::on_configuration_changed handler, and another empty mod (no scripts or prototypes) used to trigger the LuaBootstrap::on_configuration_changed (by enabling/disabling it in the mod list).

Variant A:

1. Server starts.
2. Player connects.
3. Player disconnects.
4. Server stops using /quit command.
5. Server adds a mod.
6. Server starts.
7. player.connected is false during LuaBootstrap::on_configuration_changed.

Variant B:

1. Server starts.
2. Player connects.
3. Server stops using /quit command.
4. Server adds a mod.
5. Server starts.
6. player.connected is true during LuaBootstrap::on_configuration_changed.

I found it a bit strange that player connected status differs based on how the disconnect has occurred, but then ran into this thread, and figured it's better to get clarification here than opening a new bug report.

Is this still the expected behaviour? Should the LuaPlayer::connected still be treated as being non-deterministic by the LuaBootstrap::on_configuration_changed handlers? If so, would it be possible to add a small warning in API documentation for the LuaPlayer::connected and LuaGameScript::connected_players properties about this?

[Klonan]

Sorry for resurrecting this thread, but I was curious to know if anything has changed compared to the time this was reported (currently using 0.18.36).

I was trying to debug an error related to one of the mods I'm using, and ended-up looking into behaviour of the LuaPlayer::connected property.

I have observed two different results for the property depending on how the player got disconnected from the server. This was observed with one minimalist mod that merely logs the property in its LuaBootstrap::on_configuration_changed handler, and another empty mod (no scripts or prototypes) used to trigger the LuaBootstrap::on_configuration_changed (by enabling/disabling it in the mod list).

Variant A:

1. Server starts.
2. Player connects.
3. Player disconnects.
4. Server stops using /quit command.
5. Server adds a mod.
6. Server starts.
7. player.connected is false during LuaBootstrap::on_configuration_changed.

Variant B:

1. Server starts.
2. Player connects.
3. Server stops using /quit command.
4. Server adds a mod.
5. Server starts.
6. player.connected is true during LuaBootstrap::on_configuration_changed.

I found it a bit strange that player connected status differs based on how the disconnect has occurred, but then ran into this thread, and figured it's better to get clarification here than opening a new bug report.

Is this still the expected behaviour? Should the LuaPlayer::connected still be treated as being non-deterministic by the LuaBootstrap::on_configuration_changed handlers? If so, would it be possible to add a small warning in API documentation for the LuaPlayer::connected and LuaGameScript::connected_players properties about this?

You should make a post on modding help if you have and problems with this

We aren't going to change how it works

[Rseding91]

Is this still the expected behaviour? Should the LuaPlayer::connected still be treated as being non-deterministic by the LuaBootstrap::on_configuration_changed handlers? If so, would it be possible to add a small warning in API documentation for the LuaPlayer::connected and LuaGameScript::connected_players properties about this?

That is the expected behavior and it is deterministic. When the save was created the player was connected. Until you load the save and it records the player as no longer being connected the value is true. One the save loads the disconnect action is recorded and it sets the value to false. All of that is deterministic.

If it wasn't, multiplayer and replays would not work - and they do.