Is there a TLO/member for whether a mob is encounter locked and if so to who for servers with encounter locking? I didn't find anything in the docs.
-
Hail, we're RedGuides. We want you to play six (yes, 6!) EverQuest characters at once. We have scripts and a friendly community to help, please join our playstyle and say hello! 👋
Question - Encounter lock detection
- Thread starter mirkendargen
- Start date
The code for EL is already exposed in the source.
eqlb/game/playerclient.h line 464.
It has just never been connected to a useable TLO in the base source.
eqlb/game/playerclient.h line 464.
It has just never been connected to a useable TLO in the base source.
FYI, i exposed the data and this is what becomes available for referencing:
0 = Not encounter locked
1 = Encounter locked
2 = Encounter “unlocked” (after using /yell)
The name of the individual that the npc is locked to is not made available. I am sure there is a way to pull it, but i haven’t unearthed it yet.
0 = Not encounter locked
1 = Encounter locked
2 = Encounter “unlocked” (after using /yell)
The name of the individual that the npc is locked to is not made available. I am sure there is a way to pull it, but i haven’t unearthed it yet.
Did this ever end up getting added? 
noDid this ever end up getting added?
I think I might have gotten this working, still doing some testing
Success, the states are like @evianwater said. These examples are in order:
Unengaged mob, locked to no one, attackable by me
Engaged, locked to xxxxxxe, not attackable by me
Engaged but /yelled, this seems to clear the lock target, attackable by me
Engaged, locked to xxxxxxo (me), attackable by me
Engaged, locked to xxxxxxe (but grouped with me), attackable by me
I submitted the 2 PRs for FTE. thanks to @Debauche for the code and brain for helping me clean it up
Add FTE (Target Locking) information by Sicprofundus · Pull Request #4 · RedGuides/eqlib
Added EncounterLockState (0, 1, 2) 0 = open; 1 = locked (only you, group members, raidmembers), 2 = /yelled, anyone EncounterLocked (Bool) EncounterLockOwner (returns name or you ...
github.com
Add FTE (Encounter Locking) information by Sicprofundus · Pull Request #1044 · macroquest/macroquest
Added EncounterLockState (0, 1, 2) 0 = open; 1 = locked (only you, group members, raidmembers), 2 = /yelled, anyone EncounterLocked (Bool) EncounterLockOwner (returns name or you ...
github.com
The implementation of EncounterLocked is a little wonky and I'm not sure what you'd ever actually use it for. I implemented that idea as "isAttackable" and treated not locked, locked to me/my group/my raid, and /yelled as true. The implementation here would make you have to check multiple things in order to determine if something is attackable. 0 || 1 && owner == me || 1 && owner == a group member || 1 && owner == a raid member || 2
yeah you would indeed make a additional functions for those other things for your script, that's what I did for the cwtn class plugins when I put that in the place holders waiting for the fte code.
this is what i went with - I decided to try and be more modular rather than smashing everything into one function should these pieces of this get used later by dbg, i wouldn't have to part them out later
IsSpawnIDInGroup(const int iSpawnID)
IsSpawnIDInRaid(const int iSpawnID)
AmIWithEncounterLockOwner(const int iSpawnID) (this checks to see if you're the owner and if not then checks group and then raid
and then
IsSpawnLockedFromMe(const int iSpawnID)
check if it is locked at all, get their owner, then return if i'm with them
which sounds like your "isattackable"
my (mine/cwtns) "is this attackable" function is much more than just for FTE and obviously we're not using TLOs
but we are using GetEncounterLockOwner and we are checking if their encounterlocked state is not 1 which is the equivalent of "EncounterLocked" because if the spawn isn't locked at all (0 or 2) then we don't need to check the other stuff, which is the idea behind the aforementioned EncounterLocked tlo member