Thunder

[NiLSPACE]

Anyone know why cWorld:GetNumPlayers is commented out? It could be used to make thunder work correctly.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26

int NumPlayers = GetNumPlayers();   class cThunderCaster : public cPlayerListCallback {     int m_PlayerToCastThunderAt;     int m_CurrentPlayer;           virtual bool Item(cPlayer * a_Player)     {         if (m_CurrentPlayer != m_PlayerToCastThunderAt)         {             return false;         }                   // Cast thunder somewhere around the player         return true;     }           public:         cThunderCaster(int a_PlayerToCastThunderAt) :             m_PlayerToCastThunderAt(a_PlayerToCastThunderAt),             m_CurrentPlayer(0)         {} } ThunderCaster(GetTickRandomNumber(NumPlayers));   ForEachPlayer(ThunderCaster);

[worktycho]

Its commented out because it encourages dangerous code. For example the code given has a chance of not casting any thunder at all.

[xoft]

It's mostly due to multithreading - it was causing deadlocks when used, and once you got your answer you still wouldn't know any better, because players may have disconnected from another thread in the meantime.

How about adding cWorld:DoWithRandomPlayer(a_Callback)?

[worktycho]

That's two specific, How about DoWithPlayerList?

[xoft]

Good enough, except for the name. It's not a list. How about simple DoWithPlayers() ?

[worktycho]

Too similar to DoWithPlayer. And its a list of things, even if it's not a linked list, c++ is about the only language where list automatically means linked list.

[Shadowraix]

These kind of issues where a player disconnecting causing issues is confusing to me. In the environment I worked in we usually had methods that would search for a player so something like

Code:

local Player = game.Players:FindPlayer("Player")

Then the Player variable would store the player object then I can simply do

Code:

if Player then
--code
end

Is this not feasible with your API? This method of things seems a lot better instead of worrying about player disconnecting. Player will just become nil when the player disconnects. That if statement can handle the player disconnecting easily.

[xoft]

Due to multithreading it cannot be so simple - the "player disconnecting" will be processed by a different thread running in parallel to your plugin, so the Player object can become invalid right after the IF has checked it to be valid, but before the --code executes:

1 2 3 4 5 6

-- Player is currently connected, PlayerObj is a valid object if (PlayerObj) then   -- Player disconnects right here   -- PlayerObj becomes invalid   PlayerObj:SendMessage("...")  -- fails - PlayerObj invalid, despite the condition end

This is the price we pay for being multithreaded - we do need to use the DoWith and ForEach calls. Those guarantee that the object is valid as long as the callback is executing (but, again, you cannot store the object to be used later after the call).

[Shadowraix]

Due to multithreading it cannot be so simple - the "player disconnecting" will be processed by a different thread running in parallel to your plugin, so the Player object can become invalid right after the IF has checked it to be valid, but before the --code executes:

1 2 3 4 5 6

-- Player is currently connected, PlayerObj is a valid object if (PlayerObj) then   -- Player disconnects right here   -- PlayerObj becomes invalid   PlayerObj:SendMessage("...")  -- fails - PlayerObj invalid, despite the condition end

This is the price we pay for being multithreaded - we do need to use the DoWith and ForEach calls. Those guarantee that the object is valid as long as the callback is executing (but, again, you cannot store the object to be used later after the call).

I see, what about using pcall? This way your code won't break the whole script and if it errors out anywhere in it, it can be handled? If used rarely then I can see it working fine. I know pcall is relatively slow compared to regular function calls.

[xoft]

The problem is that the PlayerObj is invalid, but not nil, so accessing it will hard-crash the server. The underlying C++ cPlayer object is gone, but the Lua object is still pointing to the memory it used to occupy.