CreateJob wrote the caller's skin table straight into ESX.Jobs while the row
got the encoded string. setJob then ran json.decode over a table and died with
"bad argument #1 to 'json.decode' (string expected, got table)". A restart
appeared to repair the job, because the grade came back from the database as a
string. Cache the same value that goes into the row.
A grade that already exists in the database is skipped for the insert, but it
was still written to ESX.Jobs. A second CreateJob call therefore replaced the
stored name, label and salary in memory while the row itself kept the old
values, and the two only agreed again after a restart. CreateJob now caches
just the grades it inserted.
Label and type of an existing job come from the database for the same reason.
The grade lookup compares strings, so passing grade "1" for an existing grade 1
no longer inserts a second row.
The jobs row was inserted unconditionally, so adding a grade to an existing
job hit a duplicate primary key and rolled the whole transaction back. The
guard above it only caught the case where there was nothing to add, and it
read ESX.Jobs, which does not list jobs that have no grades yet.
The column is varchar(22), which is a leftover from Steam identifiers.
esx_vehicleshop writes a player identifier into it, and on a
multicharacter server those are 46 characters long, so renting a vehicle
out fails.
The stock vehicle is deleted from cardealer_vehicles before the insert
runs, so the dealer loses the car and the customer never gets a rental
contract. Neither side is told anything, because the handler dies on the
insert.
esx_vehicleshop's own esx_vehicleshop.sql already declares varchar(60).
The column is varchar(40) but esx_billing writes an identifier into it, and
those are 46 characters once multicharacter is on, so the insert fails with
1406 and the handler dies before notifying either player. The other two
identifier columns in the same table are already varchar(60).
Setting an item to the count it already has sent a zero difference to
removeInventoryItem, which treats zero as an error and calls error(). That
unwinds out of the caller, so anything after the call was skipped.
Placeholder results go straight into gsub as the replacement string, so a %
in a player name either throws and kills the presence thread or silently
mangles the output. The "Unknown" fallback above it was unreachable because
the error() on the previous line always propagates.
RegisterCommand hands the callback xPlayer or false, so group, refreshitems
and fix threw from the server console instead of doing their work. The same
three lines still used the old showNotification argument list, which put a
number into title and made esx_notify throw, so players got no confirmation
either.
setPlate re-keys Core.vehicles but never updates self.plate, so the object
it was called on keeps pointing at the removed key. isValid() fails from
then on and every later call on that handle is a no-op, including delete(),
which leaves the vehicle spawned and owned_vehicles.stored at false.
Adjustments:Load() runs from the esx:playerLoaded handler, so it runs again on
every character switch. AmmoAndVehicleRewards, Multipliers and DiscordPresence
each start a `while true` thread that never exits, and SeatShuffle and
DisableRadio register another esx:enteredVehicle handler. Nothing tears any of it
down, so a player who switches characters a few times ends up with several
per-frame threads all writing the same values, and client performance degrades
until they reconnect.
The loops now run `while ESX.PlayerLoaded`, the same way StartServerSyncLoops and
Actions:SlowLoop already do, so they end on logout and a fresh one starts on the
next load. The two event handlers are registered once. Actions:Init already
documents this exact concern in a comment; Adjustments never got the same
treatment.
Measured in game on artifact 25770 by counting thread ticks per frame:
before: 2.01 -> 3.01 -> 4.02 across two relogs
after: 1.00 -> 1.00 -> 1.00
TranslateCap returned the result of gsub directly, and gsub returns the string
plus the number of substitutions. Whenever TranslateCap is the last argument of
a call, that count is passed along as an extra argument.
The common case is showNotification(msg, notifyType, ...), which is called with
just the message in about 49 places in the core. Those all pass notifyType = 1
instead of nil, so the notification is rendered with a numeric type rather than
the intended default. 71 call sites in total have TranslateCap in trailing
position.
Wrapping the call in parentheses truncates it to one value. The string itself is
unchanged, and nothing reads the second value.
Deleting a character runs one DELETE per table that has an identifier/owner
column, all in a single transaction. Only users.identifier is indexed; the other
core tables (billing, owned_vehicles, user_licenses, society_moneywash,
addon_account_data, addon_inventory_items, datastore_data) have no usable index on
the delete column, so each DELETE is a full table scan and they all hold locks at
once.
Measured on 200k rows per table (MariaDB 12.3.2): the transaction went from about
1573 ms to about 22 ms once the seven columns are indexed, EXPLAIN going from
type=ALL scanning ~200k rows to a single-row index lookup per table. The addon and
datastore tables were the worst because their composite indexes do not lead with
the delete column, so they cannot serve WHERE owner = ?.
Adds the indexes to legacy.sql for fresh installs and a migration for existing
databases. The migration checks INFORMATION_SCHEMA for an index that leads with the
column (SEQ_IN_INDEX = 1) and only creates one where it is missing, so it is a no-op
on databases that already have it and re-running is guarded by the migration key.
Core.SavePlayer already refuses to save a player whose spawned flag is not set,
because an unspawned player has no server-side ped and getCoords/health return
0,0,0 / 0. Core.SavePlayers, the bulk autosave that runs every few minutes and on
restart/shutdown, had no such guard and saved every player in ESX.Players.
A player still in the load or character-selection window when the autosave fires
gets their row overwritten with position 0,0,0 and health 0. On the next load the
default-spawn fallback does not kick in, since a decoded {"x":0.0,...} is truthy,
so they spawn at the world origin, and with SaveDeathStatus on, dead.
Guard the loop with the same spawned check, and skip the query entirely when no
spawned player remains.
Tested on artifact 25770: forced a connected player to spawned=false and ran
saveall. Before, the player's row was overwritten (the save ran); after, the row
was left untouched and no save was issued.
The pickup loop calls ESX.Game.GetClosestPlayer at the top of every iteration, but
closestDistance is only read inside the nested check that runs when the player presses
the pickup control right next to a drop. As soon as any pickup is within five metres
the loop sets Sleep to 0, so the lookup runs every frame while standing near a drop.
GetClosestPlayer builds two tables and calls GetPlayers plus GetPlayerPed,
DoesEntityExist and GetEntityCoords per player, so the cost grows with the number of
players in scope - worst exactly when the server is busy.
Measured in game on artifact 25770 with a single player standing on a dropped pickup,
reading es_extended in the resource monitor over about 20 seconds each:
before: 0.16 - 0.18 ms, sitting around 0.17
after: 0.13 - 0.15 ms, sitting around 0.14
The two ranges do not overlap. Idle, with no pickup within five metres, is 0.04 ms in
both cases, as expected, since the loop sleeps 1500 ms then.
One player is the smallest saving this can ever show, because GetClosestPlayer scales
with the number of players in scope. The larger saving on a populated server follows
from that per player work and was not measured, testing it would need several clients.
Behaviour is unchanged, the value is computed in the same frame it is used.
ESX.IsValidLocaleString only checks that the argument is a string, but a Lua
string is a byte array and need not be valid utf8. utf8.codes raises on a
malformed sequence rather than stopping, so the function throws where its
annotation promises a boolean.
esx_identity feeds raw client input into it through checkNameFormat, so a
modified client sending a lone 0xFF byte as a first name aborts the
registerIdentity callback before cb() runs. The client is left waiting on a
promise that never resolves and cannot get past the identity screen, and it
can be repeated at will.
utf8.len returns nil instead of raising, so it is enough to reject the string
up front.
Verified on artifact 25770: "Jo\255hn" used to raise "invalid UTF-8 code" and
now returns false. "John" still returns true, "Jo!hn" still returns false, and
"Jo3hn" with allowDigits still returns true.
promise.state is a number, not a string - the runtime defines PENDING as 0 and
Citizen.Await tests against 0 as well. Comparing it to "pending" is therefore
always false and the documented 15 second timeout never rejects anything. When
the other side never answers, Citizen.Await blocks the calling coroutine for
good.
Measured on artifact 25770 with the real 15 second delay:
never answers, current guard -> state 0, not rejected, await never returns
never answers, fixed guard -> state 0, rejected, await returns the timeout
answers after 1s, fixed guard-> state 3, untouched, await returns normally
Nothing inside esx_core calls AwaitServerCallback or AwaitClientCallback, so
no core behaviour changes.
_Not_