Comments (10)
This works for me. Are you on a private server?
The game sends you target information so that your client can render other characters looking at their targets (turning their heads). Do peoples turn their heads on your private server?
from lua.
Are you on a private server?
No, I am on live.
The code I am testing is part of a gearswap script, if that makes a difference.
Here is a quick lua to test:
function get_sets()
end
function self_command(command)
local po = windower.ffxi.get_player()
local pomob = windower.ffxi.get_mob_by_id(po.id)
print("player target: " .. pomob.target_index)
local pt = windower.ffxi.get_party()
for i=0,pt.party1_count-1 do
local member = pt["p"..i]
print("p"..i.." name: " .. member.name)
if (member.mob) then
print("p"..i.." target: " .. member.mob.target_index)
end
end
end
gs c test
player target: 0
p0 name: <name>
p0 target: 0
from lua.
If I run this not in a party, which I assume was the case for you, I get:
player target: 57
p0 name: <name>
p0 target: 57
However, you are correct that is wrong. That monster is on the other side of the zone from me.
I can replicate this outside of gearswap, so it's probably a problem with WindowerPlugin.
from lua.
I dug into it further and here's what's going on:
- Windower uses the client's mob array in memory to populate the
.mob
table. This is primarily populated by 0x00D (PC) and 0x00E (NPC) chunks. - The game doesn't send you 0x00D chunks about yourself, so it rarely ever updates that structure's target information for you. The client tells the server what you are looking at, so the server doesn't need to echo that back to the client. I only really see 0x00Ds for myself after interacting with NPCs
- p0 is your character, and your character doesn't get updated consistently, so the target_index for your character is inaccurate.
That's pretty much it. The solution would be to switch how that field is populated in the Mob call for the specific case where the monster being asked about is you.
As a workaround, you could use get_mob_by_target('t').index
or, confusingly, get_player().target_index
for yourself. That hits a different path, haha
from lua.
Hmm, interesting.
Related, and also partly while i filed this ticket, was I was noticing my trusts, while engaged, also reported a zero index, but im guessing those are not "PC's". Though, i would think the server would send what they are "looking at" to leverage.
Is this a different issue?
from lua.
The server is only sending target indices, as far as I can tell, so PC heads turn to look towards their targets. I would have assumed that trusts would also turn their heads, but I can't swear I've seen it. It's entirely possible that they don't.
I have basically been assuming that trusts are stateless actors (well, same state as npcs), so they probably don't have a concept of "current target."
from lua.
I don't know how it is for trusts, but at least it would make sense for that to be the case. For monsters specifically that value is never populated, because they don't turn their heads, instead their entire body rotates, and that is transmitted in a single byte field representing the rotation (which, incidentally, means that their rotation is limited to 255 discrete values, despite using a 4 byte float in memory).
Aside from that, Byrth's analysis is correct. While it would be convenient to fix this for the current player, we already discussed this once before and decided against it, instead we added the .target_index
property to the windower.ffxi.get_party
result. That was near the beginning of our Lua API, which was 10 years ago at this point, so I cannot remember the precise reasoning for it, but I wouldn't be surprised if it was for performance reason, because we'd have to execute the target distinguishing code on every get_mob_by_x
call. We also had more of a "keep it as it is in memory" mentality at that point, so maybe we just didn't want to mess with it and leave it to SE.
Anyway, not saying I'm not open to changing it, but the workaround for this already exists, and I'm not sure if the change would be worth it. But feel free to discuss it, if you think it's a good idea I can add it.
from lua.
If performance will be generally impacted, then no, it probably should remain as-is. Perhaps update the wiki with a note, and call it a day.
That said, if this field is already being updated using incoming chunks, then it would make sense that using the outgoing chunk, for the player specifically, wouldn't be a huge impact, since the client still informs the server what it is looking at, even though it is not echoed.
However, it is easy enough to just compare ids with the player id and route to get_mob_by_target instead.
from lua.
trusts and npcs dont "target" things... they just.. act. So I wouldn't expect to find the target field ever filled in for npcs
from lua.
Closing, since this is a non issue
from lua.
Related Issues (20)
- Allow Saving of BLU spell Sets when BlueMage is subjob HOT 3
- Strange Lua syntax in addons/libs/resources.lua HOT 4
- ROE addon exploit. HOT 5
- Battlemod: color codes should not breakup ability names (chatmon incompatibility) HOT 3
- [Barfiller] Able to set y position in xml but not x position. HOT 5
- Returning true from `keyboard` event does not block input
- PointWatch Suggestion
- [Addon] [DistancePlus] Lua runtime error: DistancePlus/DistancePlus.lua:337: attempt to index local 'command'
- [AddOn] [JobChange] //jc RDM/WHM not recognized because uppercase isn't allowed in dual-job operand
- scoreboard crashes game. HOT 2
- Where are the lua functions defined? HOT 4
- 🤷♂️
- [Addon][Gearswap] Faulty file_unload() function prevents unloading/changing profile. HOT 6
- Lua code HOT 1
- [Addon] [findAll] Server-specific files HOT 3
- [AddOn][BLUAlert] BLUAlert going off when it sees Drakesbane in the chat log. HOT 3
- [SpellCheck] needs to be updated to use the unlearnable spells resource flag instead of having it's own exceptions list
- Itemizer doesnt see all bags as enabled, but they are. (Private Server) HOT 2
- [Addon][Treasury] - Auto-Drop unintended consequences with Auto-Pass HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from lua.