Here is a new tip for the thread.
I originally saw @Laurea doing this in his script here : http://pastebin.com/siQHVciK
I suggest you check it out as well.
Anyways. The idea is that Player and Unit and so on are tables that hold the methods for lua.
Update: Eluna is now supported, and some general optimizations have been performed. The value backup feature for Eluna isn't implemented yet, but working on it.
This script allows you to easily attach variables to players, creatures, gameobjects, maps and instances (Eluna also supports items, groups and guilds) without using a table and the tostring method.
The purpose is to make collision-free scripting easier, especially for beginners, and keep more advanced code clean.
This means that you can add in your own methods :)
And variables and so on .. just like a normal table pretty much.
When making a method, you use : like in this example code. This enables you to use the function as a method to the player and use "self" variable for the player object using it:
local function OnChat(event, player, msg, lang, typ, misc)
if (msg == "test") then
While this is true, you can still use an existing saved player pointer.
-- Eluna Function:: Returns nil when the player is changing maps.
In this code you commented that GetPlayerByGUID (or by name) returns nil on map change. While it does that, player:GetName() will still return valid name.
guid = player:GetGUID()
CreateLuaEvent(function(a,b,c) player:SendBroadcastMessage("TestPointer") print(player:GetName(), GetPlayerByGUID(guid)) end, 500, 0)
Also the BroadcastMessage will succeed after changing maps (obviously the player cant see the message when loading a new map)
A code like this should be enough to control players:
It of course doesnt do what your script does, but this is what I had in mind when you said about saving the player to var and setting to nil on logout.
ps. Pretty much the only difference between getting a player with GetPlayerByGUID vs using a system like that are that player isnt available when changing maps.
This is why if you need to do this, I suggest using GetPlayerByGUID instead. You may need a system if you have special needs like player stats while he is off, like skittles might have had.
The above system only describes a simple example of storing data for player (or the player). It can be extended to save various information about player.