Player-related vars should go into /datum/mind

[CIB]

.. And not into /mob. So far, this includes:

• mob.lastKnownIP
• mob.computer_id
• mob.UI

[sunfall]

Absolutely agreed. These aren't things that are tied to the mob itself, but to the player controlling that mob. This also goes hand-in-hand-slash-supplants Issue 22.

[ghost]

There already exists a datum/preferences datum, although it's only really used for new_players at the moment (despite it being attached to other mobs in a slightly haphazard way). You could tidy that up into a global list like var/list/preference = list("ckey"=preferencedatum;) then assign it to clients at client/New() so that preferences remain persistent for clients (like UI preferences).

As for minds, I will be helping Cael of Baystation to port my mind/datum fixes from TG to Baystation if it's of any interest? It's basically just a means of syncing minds with mobs and clients using the Login Logout and mind.transfer_to(mob) procs to ensure that objectives don't get messed up, clients don't get kicked, etc. If a mind has a current 'body' and that body has a key, the mind is synced with that key. Otherwise it is unsynced.

The mind can be transferred around easily even if the client is not in-game. If the mind is currently synced with a key it will bring the key with it into the mob it is transferred to. If it is unsynced it transfers only the mind (although it keeps a reference of the last key it was synced to).

Any client can 'claim' an unsynced mind simply by logging into its associated mob.

All of this means that minds are tied to players but players aren't necessarily restricted to a single mind. Which is helpful considering the amount of ckey-editing/respawning/events that often go on.

Although, I never even considered adding last known IP/ID to minds. I'll look into that one.

I'll drop a link here when the port is finished if you'd like (save you all a little work)?

[sunfall]

We are never averse to seeing how people tackle interesting problems. :)