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.
With the callback checking whether a menu is still open, cancelling the
previous timers by id is no longer needed.
The table it kept them in was never emptied, so every open iterated over
every id ever created and called ClearTimeout on all of them. That is
quadratic, and clearTimeout only marks an id in xLib's CancelledTimeouts,
which is cleared when the timer fires. Ids that had already fired stayed
in there for good, in a table shared by every resource.
Both default skins spell the chin width key chin_13. skinchanger only
knows chin_1 through chin_4, so the value never reaches the ped and the
key is stored as junk in users.skin.
It also breaks the ped. SetFace reads every feature through
Normalise(weight, 10), which divides, so a missing chin_3 raises
"attempt to perform arithmetic on a nil value" at feature index 17.
Everything after that in ApplySkin is skipped: the remaining features,
the eye colour, the head overlays, the components and the props.
table.dump called its own table argument as a function, so it threw
"attempt to call a table value" for every table that had at least one
entry. An empty table returned "{ } " and a non-table returned tostring,
which is why it looks fine until you actually dump something.
table.contains was defined twice in the same file. Lua keeps the second
one, so the annotated version further up was unreachable. Removed the
unreachable one; behaviour is unchanged.
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.
math.type only returns 'integer', 'float' or nil, so the 'uint' branch
comparing against 'int' never matched and threw whenever throw_error was set.
pressedInteractions was written on every interaction and read nowhere, so it
grew for the whole session and kept removed interactions reachable.
OnTime always built scheduledTimestamp from the date of the current tick, so
a tick that skipped the 23:59 minute compared it against 23:59 of the next
day. The run was dropped without a trace. Fall back to the previous day when
the scheduled time lands in the future.
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.
setVehicleProperties passes props.color1 straight into SetVehicleColours when the
secondary colour comes from the palette. If the primary is a custom RGB colour,
the getter stored it as a table, so a table reaches a native that wants a paint
index and the call does nothing. The secondary colour is silently lost.
Any car sprayed with a custom primary and a palette secondary comes back from
storage with the wrong secondary colour.
Fall back to the vehicle's current primary when props.color1 is not a paint index.
The custom primary was already applied by the block above, so nothing is lost.
Measured in game on artifact 25770, reading properties off a car with a custom red
primary and palette secondary 12, then applying them to a second car:
before: color2 came back 0
after: color2 came back 12
The custom primary survives either way, mods and wheels are untouched.
startLoop is called from the esx:playerLoaded handler in es_extended, which fires
again on every character switch, and the loop it creates runs `while true` with no
exit. Each relog therefore leaves another points thread running: they all scan the
same table, fire the same enter and leave callbacks, and none of them ever stop.
A guard makes a second call a no-op. The loop is meant to live for the resource
lifetime, so starting it twice is never right.
Measured in game on artifact 25770, counting scans over four seconds:
before: 1.0 -> 2.0 -> 3.0 loops across two relogs
after: 1.0 -> 1.0 -> 1.0
Points keep working, the surviving loop is unaffected.
Note this touches the same file as #1831, which guards the callbacks inside the
loop. The two changes are in different places and independent of each other.
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
The processing thread counted the remaining time down in 1000 ms steps and read
the global CurrentProgress on every wake, which caused two problems.
Any duration that is not a whole number of seconds finished late, since the
thread only checked after another full second. The NUI bar runs on wall clock
time, so the bar completed and the player then stood frozen waiting for onFinish.
Cancelling did not stop the thread either. CancelProgressbar clears
CurrentProgress, but the sleeping thread only notices up to a second later, and if
a new bar was started in that window it saw a non-nil CurrentProgress and kept
decrementing the new one alongside its own thread. The new bar then finished at
roughly half its length, firing onFinish early.
The run now carries an id, so a thread stops as soon as its run is no longer the
current one, and the end is an absolute timestamp rather than a countdown.
Measured in game on artifact 25770, requested versus actual onFinish:
before: 500 -> 1011, 4200 -> 5042, cancel then 3000 -> 1427
after: 500 -> 519, 4200 -> 4222, cancel then 3000 -> 3058
Opening a menu schedules SetNuiFocus(true, true) 200 ms later so the NUI has time
to render. Closing sets the focus off but does not cancel that timer, so a menu
closed within those 200 ms leaves the timer to fire afterwards and turn the focus
back on with nothing open: the player gets a cursor and loses movement and input
until another menu is opened and closed. esx_menu_list never stored the timer id
at all, so it could not be cancelled in any case.
Checking inside the callback whether a menu is still open fixes both, and also
covers a quick open-close-open where cancelling by id would drop a focus that is
still wanted. esx_menu_default is unaffected, it has no timer.
Tested on artifact 25770 with a dialog closed 50 ms after opening: before,
IsNuiFocused() was still true 600 ms later; after, it stays false.
Registered jobs are third party callbacks and were invoked bare. An error inside
one propagates out of OnTime into Tick, so Tick never reaches its
SetTimeout(60000, Tick) at the end and nothing ever reschedules it. From that
moment cron is dead for every resource on the server - paychecks, cleanups,
anything registered through cron:runAt - until a restart. The operator sees one
stack trace and then silence.
Wrapping the callback keeps the loop and the reschedule intact, and names the job
that failed.
Simulated the scheduler chain in standalone Lua with three jobs where the first
raises: before, the tick died before SetTimeout and the two later jobs never ran
again; after, the failure is reported and both later jobs fire.
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.
_Not_