v3.4.1

Requires msk_core 4.1.0

Uses the table forms that msk_core 4.1.0 introduced, so the deprecation warnings in the server console are gone. The notifications are sent as a table, which an older msk_core takes as the title. Update msk_core along with this script.

Added

• The msk_core version is checked on start. MSK.Check.Dependency('msk_core', '4.1.0', true) logs an error in the server console when msk_core is older, instead of leaving you to wonder why the notifications look wrong. (server/versionchecker.lua)

Changed

• Config.Notification passes a table to MSK.Notification. The form with title, message, type and duration is deprecated since msk_core 4.1.0 and logs a warning once per resource. If you keep your own config, change the two MSK.Notification lines the same way. Leaving them works too, the old form is still accepted for now. (config/static.lua)

• Config.openTextUI passes a table to MSK.TextUI.Show. The form with key, text and color is deprecated since msk_core 4.1.0. (config/static.lua)

Changed files

fxmanifest.lua
config/static.lua
server/versionchecker.lua

v3.4.0

Requires msk_core 4.0.0

Every framework call in this resource goes through the rewritten bridge. On
msk_core 3.x the player object arrives without its methods and nothing works.
Update msk_core along with this script.

Security

• Money could be created out of nothing when selling a vehicle. Both
  framework branches credited the seller before taking the money from the
  buyer. A deduction that failed for any reason left the seller paid and the
  buyer's balance untouched. The money is taken first now, and only a successful
  deduction credits the seller. RemoveMoney refuses on an insufficient balance
  and says so, so the deduction itself decides instead of the check in front of
  it.

Added

• Qbox support. Qbox uses the same player_vehicles and players layout as
  QBCore, verified against qbx_core.sql and qbx_vehicles/vehicles.sql.

Fixed

• Nothing was ever set up for a player on ESX. The keyring item and the
  conversion of the old storage method hung on esx:playerLoaded on the server
  and on the two QBCore client events. msk_core turns every framework's own load
  event into msk_core:playerLoaded, which is what the resource listens to now,
  on all three frameworks.

• The load and logout handlers were net events. Server side those events are
  local, and as net events any client could fire them with an arbitrary player
  id. They are AddEventHandler now.

• The job rank was read under two different names. grade_name on ESX,
  grade.name on QBCore, and neither existed on Qbox. It is gradeName
  everywhere now.

• GetPlayerVehicles returned an empty list, and offline players showed up as
  their raw identifier in the dashboard. Both branched on Config.Framework,
  which msk_core detects now, so the value stayed at 'AUTO' and every branch
  was skipped. They ask MSK.Bridge.Framework.Type instead and cover Qbox with
  the same path as QBCore. A vehicle row with unreadable property JSON no longer
  takes GetPlayerVehicles down either.

Changed

• Config.Framework in config/static.lua is no longer read. The line stays
  so an existing config does not break, but changing it has no effect. Pin the
  framework in msk_core's config.lua instead.

• Framework detection is gone from this resource. It sat at the top of
  client/main.lua and server/main.lua, knew only ESX and QBCore, and msk_core
  has already detected the framework when those files load. The tables are still
  resolved per framework, because that is what actually differs.

• The client no longer keeps its own copy of the player data.
  client/main.lua mirrored esx:setPlayerData, esx:setJob and
  QBCore:Player:SetPlayerData into a local table that nothing else in the
  resource read. msk_core keeps that copy itself, use MSK.GetPlayerData().

• Usable items are registered through MSK.RegisterItem, which covers ESX,
  QBCore and Qbox in one call.

• The player helpers (GetPlayerFromId, GetPlayerFromIdentifier,
  GetPlayerSource, GetPlayerIdentifier, GetPlayerJob) keep their names,
  because the rest of the resource calls them, but each is one line now instead
  of one branch per framework.

Changed files

fxmanifest.lua
config/static.lua
client/main.lua
client/encrypted.lua
server/main.lua
server/functions.lua
server/storage.lua
server/admin/api.lua
server/admin/permissions.lua

v3.3.3

Fixed

• QBCore and Qbox: your staff could not open the admin dashboard, even though the permissions in your server.cfg were correct. The frameworks do not agree on how a group principal is named. ESX and Qbox use group.admin, QBCore uses qbcore.admin, and that is not a detail you can configure away: /addpermission and QBCore.Functions.AddPermission write exactly that. QBCore also only ever links qbcore.god to group.admin, so anyone below god level was a member of no group.* principal at all and the dashboard check came back empty for them. On ESX this stayed invisible, because there the group from the users table caught it, and that fallback does not exist on QBCore. The script now registers its own ace object per group and points both spellings at it, so add_principal identifier.license:xxx group.mod and /addpermission 1 mod both get you in. Nothing changes for ESX servers.
• /adlock was dead on QBCore for the same reason. The command was only granted to group.<name>, which a QBCore admin never holds. Both spellings are granted now.
• Access denied for command add_ace spam on every server start. FiveM checks add_ace against the resource that runs it, and no resource holds that right by default. So the ace objects introduced in v3.3.2 were never actually created, every attempt was refused and only printed an error. On ESX this went unnoticed because the framework group caught it. The aces are now registered through msk_core, which is the one resource your server.cfg already grants that right, and the script checks up front whether it is allowed instead of spamming the console.

Requires msk_core 3.3.0

This release uses MSK.AddRawAce and MSK.CanAddAce, both added in msk_core 3.3.0. Update msk_core along with this script.

Your server.cfg needs the msk_core ace lines, which are the ones the msk_core documentation has always listed:

add_ace resource.msk_core command.add_ace allow
add_ace resource.msk_core command.remove_ace allow
add_ace resource.msk_core command.add_principal allow
add_ace resource.msk_core command.remove_principal allow

Those are what let the script create its ace objects, which is what makes a plain add_principal ... group.mod work without you writing any further ace lines by hand. One set of lines covers every MSK script.

If they are missing nothing breaks, the script says so on start and group access falls back to your framework group (ESX users table, QBCore permission list) and luxu_admin.

There is nothing to rebuild and no database change. Replace the resource files and restart it.

Changed files

• fxmanifest.lua (version bump)
• server/admin/permissions.lua (own ace object per group, both principal spellings, QBCore permission fallback, extended debug output)
• server/main.lua (grants the adlock command to both spellings)
• server/admin/boot.lua (corrected the command name in the startup message)
• server/admin/command.lua (corrected the fallback command name, only ever used when Config.adminCommand is missing)
• config/settings.lua (note on how the frameworks name their groups)
• web/src/admin/devMock.ts (browser dev mock only, not part of the build)

v3.3.2

Fixed

• Admins with group.admin could not open the dashboard. FiveM keeps principals and ace objects apart. A line like add_principal identifier.license:xxx group.admin in your server.cfg only makes that player a member of the group, it does not give them the ace object of the same name. The dashboard checked for that ace object, so unless someone had also written add_ace group.admin group.admin allow by hand, the check came back empty and the player was turned away. It worked on some servers by accident, because there the ESX or QBCore group in the users table happened to be admin as well and the framework fallback caught it. The script now creates those ace objects itself on start, for admin, for every group in Config.dashboardGroups and for every group in the permission matrix. So a plain add_principal in your server.cfg is enough, exactly like you would expect. New groups you add from the Permissions tab are covered right away, no restart needed.
• Checking a group name in the Permissions tab reported "not found" for brand new groups. The check ran before the group existed as an ace object, so it could never find anyone in it. The group is registered first now.

There is nothing to rebuild and no database change. Replace the resource files and restart it.

If you cannot update right now, this one line in your server.cfg has the same effect for group.admin:

add_ace group.admin group.admin allow

Changed files

• fxmanifest.lua (version bump)
• server/admin/permissions.lua (registers the group.<name> ace objects, plus a debug output that tells you why a player was denied when Config.Debug is on)
• server/admin/boot.lua (registers the ace objects on start)
• server/admin/api.lua (covers groups added or changed while the server is running)
• server/admin/command.lua (comment only)
• config/settings.lua (note about add_principal being enough)

v3.3.1

Fixed

• The dashboard fell back to German for any language it did not have its own translation for. Picking a language in the Settings tab that only exists in translation.lua (Hungarian) s...