Skip to main content
No. Every exports.ox_target:* and exports['qb-target']:* call from your existing resources works unmodified - options, condition checks, and events all behave as your scripts expect. The only requirement is start order: ensure lation_interact after your framework core, and before every resource that registers targets.
In order:
  • Conditions - an anchor whose options are all gated off (job, item, canInteract) is completely invisible to that player. Test with a character that passes the gates.
  • Suppression - the layer sleeps while the player is dead, cuffed, in the pause menu, or while another UI (inventory, phone) is open.
  • Reveal mode - bridged ox_target / qb-target content renders nothing until you look directly at it. Moving vehicles can’t be focused until they slow down.
  • Start order - lation_interact must start after your framework core and before the resource that registered the target.
  • In a vehicle - from a seat, anchors on other vehicles, peds and objects hide by default (Config.InVehicle).
  • Still stuck? Add debug = true to the registration to draw its interaction shape in-world and confirm it’s where you think it is.
Before 1.1.0 a zone bridged from ox_target only went live with the player inside it - impossible for a zone wrapped around a desk or a marker on the floor. Zones now reach from Config.Stages.reach (2.4m) outside their surface, so update and set reach back to its default if you raised it while troubleshooting.
Yes: passive mode. Config.Passive = true makes the whole server hold-to-see on the interact control (Left Alt), Config.PassiveResources = { 'qb-drugs' } does it for what those scripts register only - escrowed scripts included - and passive = true does it for a single registration. Hidden passive interactions have no grain, no label, and no input. See passive mode.
The layer sleeps while a progress bar runs (ox_lib’s or qb progressbar’s, through their exports), so a key tapped on a chip can’t re-fire the action it just started - Config.Suppress.progress. An instant action with no progress bar is the script’s own concern, exactly as with a target; a script that wants the layer quiet during something custom calls exports.lation_interact:suppress('mytag') and release('mytag').
Config.ConfirmKey (default 'E') is the universal confirm key, and individual options bind their own with key = '...' - any keyboard key by name ('E', 'T', '5', 'F2', 'SPACE'). Config.InteractControl (default 19, Left Alt) is the target-style control: hold it and left click to get the cursor on a stack, right click to hand the camera back; set it to false to disable. See Configuration.
Yes. Anchors, zones, focus, input, and events need no framework at all. A framework (ESX, QBCore, Qbox, or ox_core - detected automatically) is only consulted for job/gang gates, item gates, and the dead/cuffed checks. Without one, gated options simply stay hidden and everything else works normally. Custom setups can adapt the checks in bridge/client.lua - it’s open code, made to be edited.
Auto-detected: ox_inventory, qb-inventory, qs-inventory, origen_inventory, codem-inventory, core_inventory, tgiann-inventory, and jaksam_inventory. If none is running, item checks fall back to the framework’s player data. Anything else can be wired in by editing HasItem in bridge/client.lua.
Idle sits around 0.00-0.01ms - nothing runs until something interactable is actually near, so thousands of registered points cost nothing by themselves. Cost scales only with what’s on screen, and slow third-party code (like a heavy canInteract from another script) can never stutter the UI or your input.
Do a full server restart. Scripts register their targets when they start, so restarting lation_interact alone leaves every other script’s targets unregistered.
Sorry about that! Please reach out to us on Discord or via email at support@lationscripts.com regarding your issue.