-
-
Notifications
You must be signed in to change notification settings - Fork 745
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
bug(ex_extended): fails to set skin if health set to 0 on login #1272
Comments
Hi! @iSentrie I don't really understand how a native would affect the clothing, it could be that ped is changed at death and it wouldn't be handled in the skin. But it can't be that either as it must be a ped that is checked off at /skin. |
well it's because of death obviously... if i delay killing the ped, clothing applies just fine. if metadata.health then
SetEntityHealth(ESX.PlayerData.ped, metadata.health)
end i believe this brings issues with other scripts too, like ambulancejob, players are not recognized as dead by that script sometimes |
Ohh so on first login the skin doesn't work i thought that if you are dead the player afterwards review afterwards the skin command doesn't work, so i see we will investigate and fix |
@iSentrie Hi! Do you use multicharacter? I now testing and works very well. |
hey, no I don't use multichar, tested only without it. |
@iSentrie Can you make some video because I don't understand what your problem is, I couldn't reproduce it without multichar. |
honestly, i was digging since then and I might have found problem which was in my esx_identity, i had outdated one, since i mostly update framework only, looks like this one was crucial too. after updating this, this doesn't happen anymore, so far. however, it seems that for killing the ped responsible was esx_ambulancejob now in conclusion it means that PlayerPedId() have changed upon applying it, script waits for so tried this theory practically
while ESX.PlayerData.ped == nil do Wait(20) end
print('before 3s wait', ESX.PlayerData.ped)
Wait(3000)
print('after 3s wait', ESX.PlayerData.ped) output was: so how many features could it affect more? |
Hm there is already a 3000 delay if multichar is applied, you will probably need it to avoid such errors, but I'll look into it more tomorrow. But I recommend you to upgrade to the full core because there are other bugs, and unfortunately if you don't use multichar it can break the system, because there are some events that only work correctly if you have multichar (don't ask why, probably because of backwards compatibility it was not fixed.) That's why it is recommended to use multichar limited to 1 character at most. |
Ooof... Okay. It's worth mentioning that 3s. delay gives players enough time to exploit the system, which leads to reviving yourself. Repro
It's not that hard to do, tried this myself (without multichar, but seems like it does the same and with multichar and it should be even easier because of logout function). But this can be prevented with |
@iSentrie Hi! Yes here when the metadata is set you need to check if the player is dead based on the database and if he is dead set him to 0 so the metadata will automatically sync to 0 and he will not be able to use it.
|
@Arctos2win Hi! Can you fix it here? #1288 |
@iSentrie Hi! Yes the problem is exactly that the character is not killed by the system because the DeathStatus logic is not turned on and if you exit at the right time then yes the save cycle will set 200 HP. I am still thinking about how to fix this. But anyway, I don't know if you had this but if you do it with multicharacter then your coordinate will be at the character creator. |
@iSentrie Fixed this is now available in 1.10.3. |
This brought new issue, ped gets killed and player is not recognized as dead and cannot be revived by medics. |
From my tests if you reconnect while dead, clothing fails to be applied to ped.
(While this happens for me all the time, it might need confirmation from others)
esx_core/[core]/es_extended/client/main.lua
Lines 63 to 65 in bcc1e87
The text was updated successfully, but these errors were encountered: