-
Notifications
You must be signed in to change notification settings - Fork 40
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
fix: RemoveKeys feat: admin command hooks #49
fix: RemoveKeys feat: admin command hooks #49
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure it makes sense for admin menu to own vehicle key commands. Those feel like they should stay in vehicle keys, no?
Based on the following information, I understood that moving the commands to qbx_adminmenu would be a good solution I don't see the difference between the command for thirst level and giving keys. |
Thirst level is built into the core whereas vehiclekeys is an optional resource |
So qbx_smallresurces should be treated as part of qbx_core? |
What about |
eebd943
to
707e419
Compare
I have a philosophical concept of ownership. Each resource is modular, so may or may not be present on a server. While a resource can depend on other resources, dependencies limit the independence of a resource, and so should be minimized. We tend to use dependencies for cross-resource libraries and centralized handling of certain things. So if one were to disable or remove qbx_vehiclekeys, it makes sense that the admin commands are also disabled. On a practical level, maintaining the admin functionality for a resource is easy to do inside the resource itself. admin menu is a weird resource with a bit of an ownership problem. Similar to a resource like radial menu, ideally it would own nothing except the UI. So to add to the UI, other resources would call exports, creating a plugin like environment. In reality, resource owned functionality can be found in these UI type resources. Admin menu is extra tricky, as it currently contains some admin functionality in addition to its UI purpose. There's a good argument such functionality should be moved into core or separated out into other resources. Most of it should be able to be owned by txAdmin. |
I fully agree with the independence between modules. That's why I originally preferred to put the food-related commands into qbx_smallresources. How about applying the observer pattern? |
You mean use events? In what way are you thinking? I believe hunger/thirst data would be owned by core, so it would be appropriate to move the commands there. |
Co-authored-by: Manason <clanerp@gmail.com>
Co-authored-by: Manason <clanerp@gmail.com>
I had in mind a list of events or exports in the qbx_adminmenu, but maybe a simple factory in qbx_adminmenu called by resources would be a better solution. |
…tations unification
Ok. I think I understand you are talking about different ways to interface with adminmenu. Here are the two options on the top of my mind:
|
The first option seems more flexible. Some callback would have to be given there on the admin side. |
* fix: small issues - Added getVehicleByPlate function - Adjusted main client loop to check for player ownership when parked - Added plate to givekey - Fixed commands not grabbing name from locale - Made vehicleList be populated by the database on start * fix: distance check and mysql import * fix(server/commands): args inconsistenties * fix(server): invalid players * fix(client): speed up event to prevent driving without keys * fix: add notifications to commands * fix(server/main): add back extra callback * feat(locales): new entry * tweak(server/commands): add error notification types * tweak(client/main): flip ternary operator * fix(server/main): only load spawned vehicles * style(client/main): return if statement to multiline * fix(client/main): check ownership through state
…code/qbx_vehiclekeys into hedge-code-feat-admin-commands-hooks
…yLista state on server fix: lock of packend vehicles refactor: move server function to separate file
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's a lot more complexity with keys as items, recommending splitting that into its own subsequent PR
if not vehicle then return end | ||
if not isBlacklistedVehicle(vehicle) then | ||
if hasKeys(qbx.getVehiclePlate(vehicle)) or areKeysJobShared(vehicle) then | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
blank space can go
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Improves readability by separating animation from the rest of the context
client/main.lua
Outdated
ClearPedTasks(cache.ped) | ||
local lockstate | ||
if state then | ||
lockstate = state == true and 2 or 1 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The == true
part can be removed, it will function the same
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The == true
improves readability
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That is how we write all of our ternary operators
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I found what the problem was
function public.removeKeys(source, plate) | ||
local citizenid = getCitizenId(source) | ||
|
||
if not citizenid then return end | ||
|
||
local keys = Player(source).state.keysList or {} | ||
|
||
if not keys[plate] then return end | ||
keys[plate] = nil | ||
|
||
Player(source).state:set('keysList', keys, true) | ||
|
||
exports.qbx_core:Notify(source, locale('notify.keys_removed')) | ||
|
||
return true | ||
end | ||
|
||
function public.hasKeys(source, plate) | ||
return Player(source).state.keysList[plate] | ||
end | ||
|
||
---Gives the user the keys to the vehicle | ||
---@param source number ID of the player | ||
---@param plate string The plate number of the vehicle. | ||
function public.giveKeys(source, plate) | ||
local citizenid = getCitizenId(source) | ||
|
||
if not citizenid then return end | ||
|
||
local keys = Player(source).state.keysList or {} | ||
|
||
if keys[plate] then return end | ||
keys[plate] = true | ||
|
||
Player(source).state:set('keysList', keys, true) | ||
|
||
exports.qbx_core:Notify(source, locale('notify.keys_taken')) | ||
|
||
return true | ||
end |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These should also update the keys lists
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These shouldn't.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this keeps the state of the keys only log off characters
Description
Admin commands moved to qbx_adminmenu.
fixed RemoveKeys function
Distance to vehicle based on maxDistance in lockpickDoor
Checklist