Mtasa-blue: onClientPlayerVoiceStart/Stop have inconsistent triggering

[Lu-1SF3-3L1P29]

I have put and activated the voice chat on my server, however there is an error or a bug. since when you press the button to activate the voice, the player's voice icon appears, but when you stop pressing the button to deactivate it, the icon does not disappear. What should I do?

[Unde-R]

this is not a bug from the game, you just didnt code it well

[Lu-1SF3-3L1P29]

but I am using the resource that comes by default, I have not modified it
at all, it should work correctly

[Woovie]

It looks like a race condition. Stop is arriving before start.

crun addEventHandler("onClientPlayerVoiceStart", root, function() outputDebugString("voice start "..os.time()) end)
crun addEventHandler("onClientPlayerVoiceStop", root, function() outputDebugString("voice stop "..os.time()) end)

You can see stop/start arrived at the same time. Perhaps stop should not trigger until a start has been triggered?

To clarify, the resource itself is fine, this is an event issue. I also do not know if voice actually remains active.

[Pirulax]

Arent the event packets supposed to come in order?

[Lpsd]

Seems like the event is being called due to some bad logic here (the way m_bVoiceActive is being used) https://github.com/multitheftauto/mtasa-blue/blob/e11685cab4beb7958ab202261f9c9d9b4ce71e58/Client/mods/deathmatch/logic/CClientPlayerVoice.cpp#L132

and it's clashing with the push to talk handler method here
https://github.com/multitheftauto/mtasa-blue/blob/927509565ab3a8d48df006440654c38e0942aa89/Client/mods/deathmatch/CVoiceRecorder.cpp#L193

I'll look at this tomorrow and submit a PR.

[Lu-1SF3-3L1P29]

Since I don't know much about programming the lua I started to check the resource above and I managed to repair the problem without thier when the icon appeared double and bug then I decided to reload the resource from a backup copy and returned to the same mistake, if someone knows this topic, who can explain it to me, I would love it with all my heart

[Woovie]

The resource isn't at fault, MTA at its core is. Yes, you could repair it using just the resource, but I wouldn't recommend it.

Should we block 1.5.8 with this?

[Lpsd]

We're working on this, it's not something you can resolve in your resource - it appears to be an MTA issue. Please don't bump the issue thread.

[Lpsd]

Please stop replying to the issue - we already know what the issue is and we're working on it. More updates will be posted here later today.

[qaisjp]

Should we block 1.5.8 with this?

If it's a new bug, yes.

If it's an old bug, no.

[Lpsd]

We need to check if either #1697 or #1551 introduced this issue.

[Woovie]

It's not #1697 nor #1551, tested older builds and the issue persisted. Going to test an even older build, around 1.5.6, and attempt replication.

[Woovie]

Issue still exists in version 1.5.6, this is a long term issue, we can ignore this for 1.5.8 and fix it in 1.5.9.

[Lu-1SF3-3L1P29]

Necesitamos verificar si el # 1697 o el # 1551 introdujeron este problema.

I introduced the problem

[Lu-1SF3-3L1P29]

El problema aún existe en la versión 1.5.6, este es un problema a largo plazo, podemos ignorarlo para 1.5.8 y solucionarlo en 1.5.9.

And what would happen if I use an older version than 1.5.6?