Skip to content

fix(es_extended/server/main): skip unknown weapons when loading a loadout - #1816

Closed
seltonmt012 wants to merge 1 commit into
esx-framework:devfrom
seltonmt012:fix/loadout-unknown-weapon
Closed

fix(es_extended/server/main): skip unknown weapons when loading a loadout#1816
seltonmt012 wants to merge 1 commit into
esx-framework:devfrom
seltonmt012:fix/loadout-unknown-weapon

Conversation

@seltonmt012

Copy link
Copy Markdown

A player whose saved loadout contains a weapon that is not in Config.Weapons can never log in again.

loadESXPlayer walks the stored loadout like this:

local label = ESX.GetWeaponLabel(name)

if label then

ESX.GetWeaponLabel asserts when the name is unknown, so it never returns a falsy value and the if label then check can never skip anything. The assert propagates out of loadESXPlayer, so CreateExtendedPlayer is never reached, ESX.Players[playerId] stays empty and esx:playerLoaded never fires. The player sits on the loading screen and hits the same error on every reconnect, with no way out other than editing the database.

This is reachable whenever the weapon list changes underneath saved data — changing sv_enforceGameBuild, removing or renaming an entry in shared/weapons.lua, or removing a resource that had added weapons to the config.

Wrapping the lookup leaves ESX.GetWeaponLabel untouched and lets the existing check do what it was written for.

Tested locally on artifact 25770 with MariaDB by storing {"WEAPON_NOTAREALGUN":{"ammo":50}} in a character's loadout column:

  • before: the client hangs after character selection, server logs Invalid weapon name! with a stack trace through GetWeaponLabel and loadESXPlayer

  • after: the character loads normally, the unknown weapon is skipped and no error is logged

  • My commit messages and PR title follow the Conventional Commits standard.

  • My changes have been tested locally and function as expected.

  • My PR does not introduce any breaking changes.

  • I have provided a clear explanation of what my PR does, including the reasoning behind the changes and any relevant context.

…dout

ESX.GetWeaponLabel asserts on a name that is not in Config.Weapons, so it
never returns a falsy value and the `if label then` check below it can never
skip anything. The assert propagates out of loadESXPlayer, which means the
player object is never created and esx:playerLoaded never fires - the player
is stuck on the loading screen and hits the same error on every reconnect.

This happens whenever a saved loadout holds a weapon the config no longer
knows, for example after changing sv_enforceGameBuild or after removing a
weapon from shared/weapons.lua.

Wrapping the lookup keeps GetWeaponLabel itself untouched and lets the
existing check do what it was written for.
@seltonmt012

Copy link
Copy Markdown
Author

Got an answer on Discord: contributions should target the branch that becomes the next release, so v1.14.1 instead of dev. Redoing this one on top of v1.14.1, closing here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant