[BUG]: Stuck at default class selection screen

[RichanoG]

Description

Hello, I seem to be having some problems with class selection. I'm getting stuck at the default SA:MP class selection screen (see screenshot), after suiciding while I've pressed F4. This is happening after I have updated to build 6 (with the crash fixes). I'm using a slightly modified version of weapon-config.

So far, I have discovered that moving back to build 5 or just removing weapon-config has fixed the bug. I do not know what exactly seems to be the problem yet.

How to re-produce this bug

EDIT: Added code example

#include <a_samp>
#include <omp>
#include <Pawn.RakNet>
#include <crashdetect>
#include <YSI-Includes\YSI_Data\y_iterate>
#include <zcmd>

#if !defined WC_DEATH_WORLD
	#define WC_DEATH_WORLD 0x00DEAD00
#endif

forward DeathRespawn(playerid);

CMD:kill(playerid, params[])
{
	ApplyAnimation(playerid, "PED", "KO_skid_back", 4.1, 0, 0, 0, 1, 0, 1);
	SetTimerEx("DeathRespawn", 3000, false, "d", playerid);
	return 1;
}

public DeathRespawn(playerid)
{
	SetPlayerVirtualWorld(playerid, WC_DEATH_WORLD);
	//SetFakeFacingAngle(playerid, _);
	TogglePlayerSpectating(playerid, true);
	TogglePlayerSpectating(playerid, false);
	SendClientMessage(playerid, -1, "debug 3");

	ForceClassSelection(playerid);
	SetPlayerHealth(playerid, 0.0);
	SetPlayerVirtualWorld(playerid, WC_DEATH_WORLD);
	return 1;
}

public OnPlayerSpawn(playerid)
{
	SetPlayerVirtualWorld(playerid, 0);
	return 1;
}

High ping seems to make the bug appear more often (almost always).

1. Join the server and spawn
2. Press F4 and suicide somehow

Relevant log output

open.mp server version

open.mp server public beta build 6 (with crash fixes)

Operating system or distribution

Debian 11

Contact information

Richano#9220 [email protected]

Additional information

[NexiusTailer]

I'm using a slightly modified version of weapon-config.

What exactly was modified there or you're just about its latest commits which add Pawn.RakNet support?

[RichanoG]

I'm using a slightly modified version of weapon-config.

What exactly was modified there or you're just about its latest commits which add Pawn.RakNet support?

I'm using the version which includes Pawn.RakNet. But, accidentally, I mentioned the main weapon-config repo. I however was using this version of weapon-config, forked by Zbyss. I've changed some healthbar textdraws to playertextdraws which were global textdraws before (customization), removed check in WC_SetSpawnInfo (force setspawninfo) and I've commented some functions like, SetPlayerPos, SetSpawnInfo etc in OnPlayerSpawn.

[NexiusTailer]

So, probably some of your changes could lead to any of that. Check non-modified latest Zbyss's or original oscar-broman's version to be sure they also reproduce listed issues.

[RichanoG]

So, probably some of your changes could lead to any of that. Check non-modified latest Zbyss's or original oscar-broman's version to be sure they also reproduce listed issues.

I have tested it on Zbyss's latest version of weapon-config and it still happens. I believed it should've been clear already out of what I said about it not happening on build 5, that it isn't my own doing.

[NexiusTailer]

I believed it should've been clear already out of what I said about it not happening on build 5, that it isn't my own doing.

Ah, okay, this actually makes this clear enough, I just probably missed this.

[ksenonadv]

Fixed next build.

[RichanoG]

Hello, this issue seems to be still present in build8. I've tested it with the code example above (with high ping).

[mixedthoughts]

weapon config with pawnraknet = it skips your class selection and you spawn as CJ - without setplayergang, color, other settings.

[NexiusTailer]

I cannot reproduce the "stuck" in class selection itself, because <<, >> and Spawn buttons are still working (at least on the latest build 10), but I've noticed other problem when using the MCVE provided in the first post: Every time "debug 3" prints in the chat, next OnPlayerStateChange will always be called with corrupted oldstate argument value (0), while in samp there will be valid previous state used by this player before callback is called.

Used logging code from my side (besides the provided example):

public OnPlayerStateChange(playerid, newstate, oldstate)
{
	new string[145];
	format(string, sizeof string, "OnPlayerStateChange(playerid %d, newstate %d, oldstate %d) GPState: %d", playerid, newstate, oldstate, GetPlayerState(playerid));
	SendClientMessage(playerid, -1, string);
	return 1;
}

[RichanoG]

I cannot reproduce the "stuck" in class selection itself, because <<, >> and Spawn buttons are still working (at least on the latest build 10), but I've noticed other problem when using the MCVE provided in the first post: Every time "debug 3" prints in the chat, next OnPlayerStateChange will always be called with corrupted oldstate argument value (0), while in samp there will be valid previous state used by this player before callback is called.

Used logging code from my side (besides the provided example):

public OnPlayerStateChange(playerid, newstate, oldstate)
{
	new string[145];
	format(string, sizeof string, "OnPlayerStateChange(playerid %d, newstate %d, oldstate %d) GPState: %d", playerid, newstate, oldstate, GetPlayerState(playerid));
	SendClientMessage(playerid, -1, string);
	return 1;
}

I see that I haven't notified correctly that you should be on very high ping (300 ish). Could you try that and see if it still happens? This still happens to me with that kind of ping. It is harder to reproduce on low ping, but it does still happen on low ping.

[RichanoG]

FYI, I've tested @NexiusTailer's example combined with mine, and this is the result when the << >> spawn buttons do not react anymore:

I do believe this might have something to do with issue https://github.com/openmultiplayer/server-beta/issues/88, but I'm not exactly sure, so just throwing this out here.

---

The code below is what I've used during this screenshot. Removing only the 2 TogglePlayerSpectating functions fixed the problem for me where the buttons didn't react.

#include <a_samp>
#define STRCPY(%0,%1,%2) 				strcat((%0[0] = '\0', %0), %1, %2)
#include <omp>
#include <crashdetect>
#include <YSI-Includes\YSI_Data\y_iterate>
#include <zcmd>

#if !defined WC_DEATH_WORLD
	#define WC_DEATH_WORLD 0x00DEAD00
#endif

forward DeathRespawn(playerid);

CMD:kill(playerid, params[])
{
	new string[128];
	ApplyAnimation(playerid, "PED", "KO_skid_back", 4.1, 0, 0, 0, 1, 0, 1);
	SetTimerEx("DeathRespawn", 3000, false, "d", playerid);
	return 1;
}

public OnPlayerStateChange(playerid, newstate, oldstate)
{
	new string[145];
	format(string, sizeof string, "OnPlayerStateChange(playerid %d, newstate %d, oldstate %d) GPState: %d", playerid, newstate, oldstate, GetPlayerState(playerid));
	SendClientMessage(playerid, -1, string);
	return 1;
}

public DeathRespawn(playerid)
{
	new string[128];
	SetPlayerVirtualWorld(playerid, WC_DEATH_WORLD);
	//SetFakeFacingAngle(playerid, _);
	TogglePlayerSpectating(playerid, true);
	format(string, sizeof(string), "debug (1): state = %d", GetPlayerState(playerid));
	SendClientMessage(playerid, -1, string);
	TogglePlayerSpectating(playerid, false);
	format(string, sizeof(string), "debug (2): state = %d", GetPlayerState(playerid));
	SendClientMessage(playerid, -1, string);

	ForceClassSelection(playerid);
	SetPlayerHealth(playerid, 0.0);
	SetPlayerVirtualWorld(playerid, WC_DEATH_WORLD);
	format(string, sizeof(string), "debug (3): state = %d", GetPlayerState(playerid));
	SendClientMessage(playerid, -1, string);
	return 1;
}

public OnPlayerSpawn(playerid)
{
	SetPlayerVirtualWorld(playerid, 0);
	return 1;
}

[AmyrAhmady]

Can you confirm this issue still exists?

[RichanoG]

It still exists in the latest release. I've taken the initiative and fixed it myself, in a fork (https://github.com/ls-rcr/open.mp/compare/master...ls-rcr:open.mp:RC2-remove-requestclass-rpc-drop). The reason I did not create a pull request is that the fix consists of disabling some security checks.

[Y-Less]

I'm testing this on the latest build, but can't reproduce the stated effects. It is a bit weird with going to class selection twice after death, so I'll look in to that, but in both instances the arrows and spawn button work.

[Alasnkz]

I actually think the arrows/spawn buttons not working is a client bug. I experienced this with gmx sometimes on SA:MP server.

[Y-Less]

I also just double-checked on the SA:MP server and got exactly the same double selection behaviour. I'm happy to try and find a way to fix that, if people want it, I'm just concerned that doing so might break other things like weapon-config and the various skip class selection hacks - this is already a very broken area!

[RichanoG]

I also just double-checked on the SA:MP server and got exactly the same double selection behaviour. I'm happy to try and find a way to fix that, if people want it, I'm just concerned that doing so might break other things like weapon-config and the various skip class selection hacks - this is already a very broken area!

You can't test this on your own environment, unless you manage to find a way to increase the ping time to the server. This problem is almost common for people with around 200-300 ping on a server I develop for.

I'm testing this on the latest build, but can't reproduce the stated effects. It is a bit weird with going to class selection twice after death, so I'll look in to that, but in both instances the arrows and spawn button work.

I normally don't go to the class selection twice, but this makes the problem occur faster for testing.

[AmyrAhmady]

@RichanoG @Alasnkz can you confirm whether this is a client bug or not?