Cross-server unique IDs for players

[ojrask]

Note: I have not created or attempted to create any mods for Factorio as of now, but it seems the following is missing:

Persistent cross-server/game session account identifiers for players (e.g. how Steam IDs work).

Main usages: moddable hacker/griefer/idiot prevention, external stats systems for communities, server whitelists/blacklists in external services, and so on.

Can the game expose a unique value of a player account (per game license) in the Lua API? Currently, the only one that somewhat relates to this is the player name, which can be changed it seems.

You can compare player uniqueness during a single session, but if the server is restarted or a player moves to another server then that solution leads nowhere when considering persistence across sessions and servers.

[aubergine18]

If I'm not mistaken, servers can already be set up to use factorio.com account?

[ojrask]

If I'm not mistaken, servers can already be set up to use factorio.com account?

I'm not sure what you mean. If a server is set up to use a factorio.com account, will some unique identifier be available to the Lua interface? If not, then the official API description does not state that. If you mean that the server accepts only players that have a factorio.com account, that does not solve the issue stated in the original post (what if I would like to create a service outside factorio.com that lists player stats and so on?).

Semi-off-topic: I also heard that the Lua API does not allow network connections, which makes some of the use cases I listed in the original post less feasible unless the Lua API talks to the file system and an external file system polling service reads and forwards data via networks elsewhere. Not a deal-breaker but does complicate things a bit.

[daniel34]

If I'm not mistaken, servers can already be set up to use factorio.com account?

I'm not sure what you mean. If a server is set up to use a factorio.com account, will some unique identifier be available to the Lua interface? If not, then the official API description does not state that. If you mean that the server accepts only players that have a factorio.com account, that does not solve the issue stated in the original post (what if I would like to create a service outside factorio.com that lists player stats and so on?).

If the server is set up to verify user identity then you can use the player name as unique identifier, as they will only be able to use the username they are registered as and to change that they would have to email support. If you disable this verification then anyone with a Factorio build can connect to your server with any username and there's no way for Factorio to know if it's the same player.

Semi-off-topic: I also heard that the Lua API does not allow network connections, which makes some of the use cases I listed in the original post less feasible unless the Lua API talks to the file system and an external file system polling service reads and forwards data via networks elsewhere. Not a deal-breaker but does complicate things a bit.

The API doesn't support network connections (or reading files from disk) for the obvious reason that it would desync the game very fast. The easy way to get data out of a running save is to write them to disk and periodically read it with an external tool. The other way is to have Factorio communicate with an external process using RCON, which lets you run commands silently and is also able to ban/kick/mute/promote other players.
Factorio also has a banlist file (banlist.json) which is automatically used for all maps on that particular server.

[ojrask]

snip

snip

If the server is set up to verify user identity then you can use the player name as unique identifier, as they will only be able to use the username they are registered as and to change that they would have to email support. If you disable this verification then anyone with a Factorio build can connect to your server with any username and there's no way for Factorio to know if it's the same player.

snip

The API doesn't support network connections (or reading files from disk) for the obvious reason that it would desync the game very fast. The easy way to get data out of a running save is to write them to disk and periodically read it with an external tool. The other way is to have Factorio communicate with an external process using RCON, which lets you run commands silently and is also able to ban/kick/mute/promote other players.
Factorio also has a banlist file (banlist.json) which is automatically used for all maps on that particular server.

So the username actually is a unique identifier when server joins are restricted to factorio.com accounts? That simplifies things a bit.

The Lua API cannot read but can write, or did I misunderstand something? Mods have a global state, but where is that state saved, and can it be saved manually or does it need a server reboot to persist?

Many open issues for this. banlist.json solves some problems when it comes to global ban lists and griefer prevention, but collecting stats and other data for players in an external service this seems a bit complicated.

Need to checkout RCON if that could be of any assistance, thanks for the pointer.

[daniel34]

The Lua API cannot read but can write, or did I misunderstand something?

That's correct. The reason for this is that writing to disk doesn't change the gamestate at all and doesn't have any consequences, but if you read from disk and a client reads different data this can/will lead to a desync.

Mods have a global state, but where is that state saved, and can it be saved manually or does it need a server reboot to persist?

Mods can store persistent data in the global table. Every mod has its own global table (mods can't see each others globals) and it is only valid for that particular save. Everything in that table gets automatically saved to the save.zip and loaded again when loading that save, without the mod author having to do anything. It is persistent for the whole lifetime of the savegame (unless you remove that mod) and not affected by server reboots.