i noticed if i have multiple options with the same event that it only sends over 1 option to the ui. im using an event and passing different variables through the options. but only 1 option pops up out of like 8. this was with addTargetModel
for k, v in pairs(options) do
if not v.distance or v.distance > distance then v.distance = distance end
Models[model][v.event] = v
end
im guessing its because its indexed using the event name, but im unsure of a solution to this rn.
where as this didnt happen with the bt-target, just for reference. i definitely prefer this resource, but just had that small issue
I set it up to index by the event for the sake of being able to add and remove options. I supposed I could (should) use label instead?
Bone target, work with any ESX version?
The entire resource is dependant on ESX Legacy. Support for older versions is easy, but there’s no reason to provide it; progress and all that.
I got a modded esx 1.1 base, for me it’s hard to update that, to do that i need to remake a whole server
That’s what happens when you build off of 1.1 and essentialmode
Config.Peds = {
'mp_m_freemode_01',
'mp_f_freemode_01'
}
Is it right for example?
I mean i want to use it on another player
Can your project be submitted for work as well qb-core ?
Converting this script to QBCore isn’t difficult, just have to find the right equivalents.
Since it’s now less of a hassle to maintain updates between the public and private versions of the code, I’ve removed the dependencies on intervals and ESX.
Setting Config.Standalone = true will remove the job and item checks, among other things, and makes it easier for you to modify the code for whatever framework you want.
when using addTargetModel it will sometimes get stuck in a loop of checking entity because it will keep getting through the checkrange. this happens reliably when using addTargetModel on NPCs it seems and then every so often on objects. i did get around it by just using the addped and then checking model in the canInteract function, but i thought maybe it was worth mentioning since i had it happen with objects as well. also am using the latest release
CheckEntity = function(hit, data, entity, distance)
local send_options = {}
local send_distance = {}
for o, data in pairs(data) do
if M.CheckOptions(data, entity, distance) then
local slot = #send_options + 1
send_options[slot] = data
send_options[slot].entity = entity
send_distance[data.distance] = true
else
send_distance[data.distance] = false
end
end
sendData = send_options
if next(send_options) then
success = true
SendNUIMessage({response = "validTarget", data = M.CloneTable(sendData)})
while targetActive do
local playerCoords = GetEntityCoords(playerPed)
local _, coords, entity2 = RaycastCamera(hit)
local distance = #(playerCoords - coords)
if entity ~= entity2 then
if hasFocus then DisableNUI() end
break
elseif not hasFocus and IsDisabledControlPressed(0, 24) then
EnableNUI()
elseif CheckRange(send_distance, distance) then
--GETS THROUGH HERE AND LOOPS ITSELF
--CAUSES HOVER COLOR TO FLICKER WHEN HOVERING AN OPTION
CheckEntity(hit, data, entity, distance)
end
Wait(5)
end
success = false
SendNUIMessage({response = "leftTarget"})
end
end
AddTargetModel({`mp_m_shopkeep_01`}, {
options = {
{
event = "store:openStore",
icon = "fas fa-shopping-basket",
label = "What are you buying?",
},
},
distance = 2.5
})
EDIT: was still happening with using the exports.qtarget:ped
EDIT2: i was able to solve this by adding " and not success" after the checkRange function above, not sure if this will have any negative impact
whats the export for intercact with other players?
Under player tab
Is it the CheckRange function causing the issue, or is it once it gets to the recursive CheckEntity function? The idea is for options to show up or hide depending on your distance to the target.
Strange it would work for the generic target functions and not specific models. I’ll look into it.
its the recursive checkEntity I think. when i was using the addtargetmodel on peds it would get through the check range with true being returned and then it would hit the checkentity again which would just loop it back through. im not too sure, but as soon as I added the “and not success” all of the issues were solved for me seemingly. so it would stop looping there once i had a success. although i havent tested enough to really know that it doesnt break anything else by adding that there
CheckEntity = function(hit, data, entity, distance)
local send_options = {}
local send_distance = {}
for o, data in pairs(data) do
if M.CheckOptions(data, entity, distance) then
local slot = #send_options + 1
send_options[slot] = data
send_options[slot].entity = entity
send_distance[data.distance] = true
else send_distance[data.distance] = false end
end
sendData = send_options
if next(send_options) then
success = true
SendNUIMessage({response = "validTarget", data = M.CloneTable(sendData)})
while targetActive do
local playerCoords = GetEntityCoords(playerPed)
local _, coords, entity2 = RaycastCamera(hit)
local distance = #(playerCoords - coords)
if entity ~= entity2 then
if hasFocus then DisableNUI() end
break
elseif not hasFocus and IsDisabledControlPressed(0, 24) then
EnableNUI()
else
for k, v in pairs(send_distance) do
if (v == false and distance < k) or v == true and distance > k then
return CheckEntity(hit, data, entity, distance)
end
end
end
Wait(5)
end
success = false
SendNUIMessage({response = "leftTarget"})
end
end
Any better?
Thanks i already tried that and works, but the problem is that will allow the player to use target in npcs too
When i try to handcuff the player with the target using the Ped export i handcuff myself
