In the current implementation of the /me command in qb-core/server/commands.lua within the QBCore framework, the 3D text generated by the command is visible to all players regardless of their assigned routing bucket. This behavior has raised an issue in specific use cases, such as the development of an apartment script.
The problem is that when players are assigned to specific routing buckets in scenarios like apartment scripts, players in different routing buckets who are in close proximity to each other can see the 3D text generated by players in different routing buckets. Even though these players cannot see the source player, the text appears as if it's originating from the player who is reading it. This unintended visibility and association can disrupt immersion and create confusion.
Ideal solution
To address this issue and enhance the QBCore framework's functionality, I propose the following modification to the /me command:
When a player uses the /me command, the generated 3D text should only be visible to target players who belong to the same routing bucket as the player issuing the command.
By implementing this modification, the /me text will be contained within its intended routing bucket, ensuring that it is only visible to players within the same routing bucket. This solution preserves immersion and prevents unintended visibility for players outside of the routing bucket, aligning with the expectations and requirements of various scenarios where routing buckets are used to manage player interactions and visibility.
Below is my fix/modification to the command:
QBCore.Commands.Add('me', Lang:t("command.me.help"), {{name = Lang:t("command.me.params.message.name"), help = Lang:t("command.me.params.message.help")}}, false, function(source, args)
if #args < 1 then
TriggerClientEvent('QBCore:Notify', source, Lang:t('error.missing_args2'), 'error')
return
end
local ped = GetPlayerPed(source)
local pCoords = GetEntityCoords(ped)
local msg = table.concat(args, ' '):gsub('[~<].-[>~]', '')
-- Find the routing bucket of the player executing the command
local routingBucket = GetPlayerRoutingBucket(source)
local Players = QBCore.Functions.GetPlayers()
for i=1, #Players do
local Player = Players[i]
local target = GetPlayerPed(Player)
local tCoords = GetEntityCoords(target)
-- Check routing bucket of the target player
local targetRoutingBucket = GetPlayerRoutingBucket(Player)
-- If the target's routing bucket matches the one executing the command, show the message
if targetRoutingBucket == routingBucket then
if target == ped or #(pCoords - tCoords) < 20 then
TriggerClientEvent('QBCore:Command:ShowMe3D', Player, source, msg)
end
end
end
end, 'user')
The problem
In the current implementation of the /me command in qb-core/server/commands.lua within the QBCore framework, the 3D text generated by the command is visible to all players regardless of their assigned routing bucket. This behavior has raised an issue in specific use cases, such as the development of an apartment script.
The problem is that when players are assigned to specific routing buckets in scenarios like apartment scripts, players in different routing buckets who are in close proximity to each other can see the 3D text generated by players in different routing buckets. Even though these players cannot see the source player, the text appears as if it's originating from the player who is reading it. This unintended visibility and association can disrupt immersion and create confusion.
Ideal solution
To address this issue and enhance the QBCore framework's functionality, I propose the following modification to the /me command:
When a player uses the /me command, the generated 3D text should only be visible to target players who belong to the same routing bucket as the player issuing the command. By implementing this modification, the /me text will be contained within its intended routing bucket, ensuring that it is only visible to players within the same routing bucket. This solution preserves immersion and prevents unintended visibility for players outside of the routing bucket, aligning with the expectations and requirements of various scenarios where routing buckets are used to manage player interactions and visibility.
Below is my fix/modification to the command:
Alternative solutions
No response
Additional context
No response