Re-identifying entities

[Wuzzy]

Challenge: Let's suppose I want to implement a mod that adds a health regeneration effect for players. Let's say there is a health potion that regenerates 1 HP per second, for a total of 60 seconds. Now this is a fairly long time, so it must be persisted between server restarts. The challenge is to come up with a way to persist the regeneration effect. So when the server restarts, the player still has regeneration.

The solution is fairly-straight forward: When server shuts down, or the player leaves, the effect data can be serialized and be saved either in player attribute or a file or some other storage. The player name will used as an identifier, so when a player re-joins, the server knows exactly which effects to apply.

Now I will alter the challenge only slightly.
What if I want to do that not for players, but for non-player entities? They have health, too.
The problem I see is that there is nothing to uniquely identify the entities.
The only thing I have is the entity handler, but this will be invalidated when the entity unloads or the server restarts. The entity handler is useless for serialization.

So, to uniquely identify a player, I have the player name.
For non-player entities, I have … nothing, apparently.

I think solving the problem with non-player entities is impossible without access to some kind of globally unique entity ID. Or am I mistaken? Maybe I have overlooked a solution. Please enlighten me.

[GreenXenith]

staticdata
You can carry self values over unloads. Make an on_activate function track value of self.healing or whatever. You don't necessarily need to control the entity definition, either. If you are applying this effect to some unknown entity, you can give the entity the function and data when you apply the effect.

[ShadMOrdre]

Wuzzy,

I would assume, as you do with doc, that you could add an self._entity_id or some variable like this to uniquely identify each entity.

[Skulls]

An in-game entity is a collection of states (health being one of them, position another), controller logic, and a 3d representation. The only thing you need to persist is the state. You don't really need to give the entity a unique ID that will persist through server restarts unless you want a way to link it to something else like a pointer.

You can just write things out and then create things in as they are read. All you really care about is that there is an entity of type X at position Y with health Z and boom, create that entity, set those values, boom, play on.

[neoh4x0r]

So, to uniquely identify a player, I have the player name.

Unfortunately, the player's name is not a unique identifier.

Consider what would happen if a player named xyz had your effect applied.
Later, another player joins and their name was xyz (unless there was a check that the name was in-use), then
the effect would be applied to a different player and not the intended one.

I know that the various methods take the player name as a parameter, but that is technically only unique per game session, to have a truly unique id that persisted between sessions a guid or uuid would be necessary.

PS: to quote the wiki: https://wiki.minetest.net/Server
"Player names need to be unique on a per-sever basis."

Which means that the name being unique entirely depends on the server setup (and shouldn't be relied upon)

[wziard]

No. A player name is unique on a given server. Unless some admin or mod actively deletes the account.

> Which means that the name being unique entirely depends on the server setup (and shouldn't be relied upon)
But that's not what it means. And not what it sais???

[texmex]

If I'm not mistaken this is exactly the problem LATE mod solves as it works equal on players and non-player entities alike.

[Pyrollo]

Hi Wuzzy,

Have a look at LATE, it's purpose was to treat mobs and players the same way (as far as possible). If I remember correctly, mechanisms for effect persistance for mobs are not yet implemented but conception has been made to make it possible.

I have less time to work on it these times but the bases are build. I'm very open to any contribution. I started to work on LATE because I think we really miss something to manage effects on players and mobs.

[neoh4x0r]

No. A player name is unique on a given server. Unless some admin or mod actively deletes the account.

> Which means that the name being unique entirely depends on the server setup (and shouldn't be relied upon)
But that's not what it means. And not what it sais???

I bed to differ with that....

"You also need to choose a player name.
Player names need to be unique on a per-sever basis.
You can choose a password but this can be empty on some servers."

What that means is that if the server allows users to register accounts without passwords, then another person could use the same username without having to enter a password.

So it does very much depend on the server setup for whether or not a username means one and only one player.

Creating a useraccount and leaving the password blank creates a situation where that account is not unique, since anyone that logins with that username would be granted access (they don't need to know the password).

[GreenXenith]

No. A player name is unique on a given server. Unless some admin or mod actively deletes the account.

> Which means that the name being unique entirely depends on the server setup (and shouldn't be relied upon)
But that's not what it means. And not what it sais???

I bed to differ with that....

"You also need to choose a player name.
Player names need to be unique on a per-sever basis.
You can choose a password but this can be empty on some servers."

What that means is that if the server allows users to register accounts without passwords, then another person could use the same username without having to enter a password.

So it does very much depend on the server setup for whether or not a username means one and only one player.

Creating a useraccount and leaving the password blank creates a situation where that account is not unique, since anyone that logins with that username would be granted access (they don't need to know the password).

If a user logs in to an already created account then they will play as the character already created by the original user. A new account isn't created. Names are 100% unique identifiers, there is no two ways around it, sorry.

[neoh4x0r]

If a user logs in to an already created account then they will play as the character already created by the original user. A new account isn't created. Names are 100% unique identifiers, there is no two ways around it, sorry.

It is unique to an account but not to individual users.

If more than one person uses an account, then it requires something more than just the username to differentiate between them (this could be done with a per-user sid that is sent to the server per-session that would uniquely identify each player attached to a single account).

This is what I meant by it not being unique: when multiple users are masquerading behind a single account.
As such it would become more difficult to know whether an effect should be applied--to the current user of the account --or not.

[GreenXenith]

It is unique to an account but not to individual users.
<snip>
In the case, it becomes more difficult to know whether an effect applies to the current user of the account or not.

We don't care about the identity behind the account. The player is the player and that is that. Wuzzy has the name as the identifier; he is correct. You are making this way more complex than it needs to be.

[Wuzzy]

That's what I meant about it not being unique -- it doesn't distinguish between individual users using the same account (account masquerading); to handle a situation like this would require another identifier besides the username to represent a specific user.

Gosh. I should be more specific: Same name = same player object. This really is an 1:1 relationship. This is good enough for me. Yes, I meant the player object, not the real world player.

It's true that this identity is not neccessarily true for real worlds players (=whoever sits at the computer screen).
If 2 players end up using the same player name, they share the same player object anyway. There's not really much you can do about it and I don't think it's even that big of a deal. If a player doesn't use a password: Their fault. If 2 players agreed to share a player name: Well, they agreed to, so also no big deal.

I am against in introducing yet another “identifier” on top of the player name, it's not needed. The player name alone is definitely enough to identify the player character, which is the only thing I really care about.






As for all the solutions presented to me so far: Thank you so far, but I'm afraid none of them were very convincing to me. Or I didn't understand it really. Maybe it would help to show minimal real-world examples?
LATE is a mob API as far I know, so sadly not generic enough.

But I think that entities in Minetest are just really horrible. They are kind of a more generic version of players that reminds me a bit of OOP, but there are also many, many annoying differences between players and entities.
Players have features that entities haven't although said features would be benefitial for both entities and players. Many callback functions are player-only, although they would make sense for both players AND entities. And, of course, player objects can be uniquely identified while entities (apparently) can't.

[texmex]

LATE is a mob API as far I know

What? Its effects may be applied to non-player entities as well as player ones. Have you checked out the demo?

[ShadMOrdre]

Wuzzy,

Since an entity is not necessarily a mob, take a look at how orwell retains entity knowledge between restarts in advtrains. The trains are moving entities, with routing info, owner and driver info, and they persist beyond restarts. This might be a more appropriate way to look at the problem you've specified, instead of only considering player or mob based solutions.

For that matter, pipeworks might also be a worthy consideration, in that the entities that are moved through the pipes, and are also persisted between restarts.

Shad