Fix client/server ped dead-state inconsistency

[Necktrox]

Description

Fixes #487

This tiny pull request fixes the inconsistency between client and server code to match the current 'dead' state of a ped.

Issue: #9496: Client 'isPedDead' returns 'false' when not yet spawned
Client: mods/deathmatch/logic/CClientPed.cpp

Notes

Your player ped is spawned and not dead after the initial connect, but the server code doesn't represent this state pre-PR. (see here)

[qaisjp]

Your player ped is spawned and not dead after the initial connect

Isn't the player ped actually not spawned on connect, and hence should be classed as dead?

[Necktrox]

On connect, the player manager creates the CPlayer instance and waits until the player finishes starting his game. In this state, the player element shouldn't be accessable in any script, because the element is not attached to the root element, thus not visible to the element tree (getPlayerFromName needs a patch, because it doesn't account for ->IsJoined() - not sure if that's intended, feedback please).

The client creates the local player in CClientGame::Event_OnIngame, which happens after the game started and the player ped is not dead at this point.

[qaisjp]

Should we perhaps "prekill" the player in Event_OnIngame then?

In my mind the player should be considered dead until the first spawnPlayer. I'm not sure though...

[Necktrox]

Killing the player after the game started might cause unforeseen side-effects.

[patrikjuvonen]

Seems fine in my opinion.

[Citizen01]

(getPlayerFromName needs a patch, because it doesn't account for ->IsJoined() - not sure if that's intended, feedback please)

So calling getPlayerFromName in onPlayerConnect should return false you say ?

addEventHandler( "onPlayerConnect", root, function ( playerNick )
    local p1 = getPlayerFromName( playerNick )
    -- p1 should equal false here ?
end)

I'm 50/50 about that, I would expect to get a valid player element, but also, I can't see a scenario where one would want a player element in onPlayerConnect and can not wait for onPlayerJoin.

[botder]

The getPlayerFromName issue has been resolved by allowing it. Using any "player-data modifying" function (e.g. setElementData) will show a warning, if used with a non-joined player.

[patrikjuvonen]

@Citizen01 There is an issue open which to me sounds fair enough. I think adding the ability to have soft "reserved slots" would be nice.

https://bugs.mtasa.com/view.php?id=6473

[Citizen01]

@patrikjuvonen This PR won't resolve the issue you linked. Or am I missing something ?

[patrikjuvonen]

@Citizen01 Yes, it won't, but that was related to your comment:

I can't see a scenario where one would want a player element in onPlayerConnect and can not wait for onPlayerJoin.

Sorry for being unclear.

[Citizen01]

Ah yeah ok I see, but even that scenario doesn't require the player element connecting as you already can use its nickname and/or serial.

[patrikjuvonen]

Ah, you're right! Completely forgot that. That issue should probably be closed then.

[Citizen01]

Hmmm no ? The issue is for the even onClientConnect not being triggerd at all if the server is full.
We won't discuss about it in here anyway.

[qaisjp]

My argument is that after a player dies you need to use spawnPlayer, and so when you join you should be classed as "dead" because you have to use spawnPlayer.

[botder]

mtasa-blue/Server/mods/deathmatch/logic/CGame.cpp

Lines 3920 to 3921 in b061dfd

	// The player is spawned when he's connected, just the Camera is not faded in/not targetting
	pPlayer->SetSpawned(true);

[qaisjp]

If that comment is correct and the player is already spawned when connected, there shouldn't be a requirement to use spawnPlayer

[botder]

You don't have to use spawnPlayer.

[qaisjp]

Hmm, I thought spawnPlayer's documentation said you do need to. But setElementPosition seems to imply you only need spawnPlayer after the player is killed

[qaisjp]

btw if that is the case (you don't need spawnPlayer when you first join) then all my comments here are wrong, and this PR can be merged

[qaisjp]

(an excellent 2 year misunderstanding, lol)