Implementing: Implied Targets

[John Adams]

Implied targets are - your targets target.

Ie., Scatman has a sapswill invader targeted, John walks up and targets Scatman and sees Scat as his target, but in his "Implied Target" window, sees also the sapswill invader.

Code: Select all

/toggleimpliedtargetwindow

Turns on the visibility of this UI, but it is still hidden until you hit F10 to see all windows because currently there is no data.


Xinux: If you are up for collecting a packet, or have you already done this one? I'd like to see the packet for this, since I don't think we even have an opcode for it yet. So we'll need a struct, too. Whatever right-click commands are available on this UI, too, though I think Tag and Tell are the only ones of note, and those probably work regardless.

Zcoretri/Jabantiz, any chance of whipping up a struct for this? If you can get the data to the UI (via /test command even), I can attempt to build the C++ for my target's target. Or, if you want to implement the whole thing, go for it.


Just one of the things on the 0.7.1 TODO list. Getting a little quiet around here, time to crack the whip

[xinux]

There doesn't seem to be a opcode associated with it from my collect i just did. It may just be client side since it uses the same information that is already being sent also have to remember that the implied target window will not show up if you are the implied target.

[John Adams]

I was hoping it was client-side, but it is not. I targeted a spawn, then targeted my char with another, and nothing shows up in the Implied Target dialog.

Try it for yourself. That's why I asked

[xinux]

humm it only seemed to pop up for me on live when i would targeted a mob that was attacking someone else and i would get the target the mob was attacking. So much log spam it's hard to see what packets exactly are being sent at that time. I'll give it a few more tries.

[Zcoretri]

I don't seem to remember seeing any opcodes associated with implied targets...this could be a tricky one to figure out

[xinux]

Couple of thing's i've noticed so far.

1. when you are not grouped implied target only works on mobs attacking other players or other players attacking mobs.

2. When grouped works on everything except if the implied target is yourself or themselves.

[xinux]

Ok update this is from using 3 characters in a house so i could actually see what was going on.

Code: Select all

-- OP_ClientCmdMsg::OP_EqUpdateGhostCmd --
3/6/2012 21:22:04
69.174.200.45 -> 192.168.1.198
0000:	00 09 01 9F 00 3A 16 00 00 00 FF 42 02 16 6D 9B .....:.....B..m.
0010:	EB 0C 04 7F 79 8F FF FF 06 5D 7F 7F 7F 5C 00 00 ....y....]...\..

What is the 04 inbetween OC and 7F ? That would change to 04 if i was able to get a implied target and 02 if i wasn't as long as 1 person was out of the group but as soon as all 3 were grouped it went 02 and stayed there. Still need more testing if someone else wants to give it ago. I tried doing this outside of a house and the log spam was to much.

[John Adams]

Good research, Xinux. This is why I dangled the carrot at you, I knew you'd do your due diligence

I will need to re-test on Emu with the EQ2TC db, see if any way you mentioned shows the data in implied target in the UI (at all). I always thought it would be another packet, because everything else is :/

What I am trying to implement isn't the display of the Implied Target as much as the melee/cast through of the targeted team mate when in or out of combat. Ie., friendly spells land on your target (Scatman, above) and detrimental spells land on Scatman's target. I don't think that will be too difficult to do in code, but I got all wrapped around the axel about the stupid UI and hit a wall lol

Thoughts or suggestions welcome.

[John Adams]

okay, well doing all the things Xinux said on emu, Implied Target box does not get updated at all. Constantly blank. grouped, ungrouped, NPC attacking or not, etc. So, pretty sure this is in the packet as you may have discovered by the changing byte.

I also see no structs whatsoever for anything EqUpdateGhostCmd or otherwise. The only place that specific opcode is referenced in our entire code is in Spawn.cpp, in spawn_update_packet and player_position_update_packet:

Code: Select all

int16 opcode_val = EQOpcodeManager[version]->EmuToEQ(OP_EqUpdateGhostCmd);

This will require the Mastah of Covert Opcodez, Zcoretri

[John Adams]

Trying to figure out the best approach to updating implied targets for those who have (me) targeted.

a) should it be pushed to those who have me targeted IF my target changes?
b) should those targeting me always be scanning for my target on the loop? (lots of function calls to GetImpliedTarget() then?)
c) some mystical, magical C++ thing I am unaware of that will keep this updated once set?

The switch (client.cpp) to handle ME targeting something --

Code: Select all

		case OP_UpdateTargetMsg:{
			LogWrite(OPCODE__DEBUG, "Opcode", "Opcode %04X (%i): OP_UpdateTargetMsg", opcode, opcode);
			int16 index = 0;
			memcpy(&index, app->pBuffer, sizeof(int16));
			GetPlayer()->SetTarget(GetPlayer()->GetSpawnByIndex(index));
			if(GetPlayer()->GetTarget())
				GetCurrentZone()->CallSpawnScript(GetPlayer()->GetTarget(), SPAWN_SCRIPT_TARGETED, GetPlayer());
			//player->SetTarget((int16*)app->pBuffer);
			break;

so option a) would be a signal in this case to update those who have me targeted currently. Wonder of World/Zone already maintains a list of every entity that has >me< targeted? Anyone know?

The other place I see SetTarget() getting called is in "OP_EntityVerbsVerbMsg" in the same switch. Assuming these are spawns that have some an entity_command set, so not sure if we'd have to track it in here, too? I'm almost assuming that Implied Target does not work on non-attackable entities (guessing?)


Since Xinux has shown Implied Target does not require a group, we cannot simply scan the group list for members targeting Me. Does this mean we'd have to check every player in a given zone in the zone Loop to see if they have any other PC targeted in order to update this box? Seems a bit much.

Last idea, have it be kinda like a feedback pulse (I love Star Trek)... starting where I target an NPC and the NPC initiates a check on me, and anyone who has Me targeted at that time, thus triggering the update.


Am I over-engineering it? Please say yes.

SCAT!!!!!!!!!!!!!

[Scatman]

I say we just map a separate map<character id, character id> of targets. That way we don't have to lock the entire player list when traversing. It'll simply keep track of who has who targeted and we can just lock that list instead.

But yes, I believe we'll need to do some sort of list traversing since 30 people could have you targeted when you change your target.

[alfa]

I'm almost assuming that Implied Target does not work on non-attackable entities (guessing?)

Target work all time along you do not target yourself, it works when you target a NPC who have a target too. And (if you don't know) there is a in game command for that: /assist Player

[John Adams]

What I am trying to implement isn't the display of the Implied Target as much as the melee/cast through of the targeted team mate when in or out of combat. Ie., friendly spells land on your target (Scatman, above) and detrimental spells land on Scatman's target.

Okay, I got this working somewhat tonight on a basic level, and now I have a question.

Does the "cast through target" work also if you have a MOB targeted and cast something (enemy), it lands on the MOB, but if you cast (friendly) it passes through the MOB and lands on whomever the MOB has targeted?

Or is cast-through only viable for targeting other Player Characters?

Thanks

[John Adams]

Jotting down a few notes to myself;

• Current implementation crashes if target does not have a target. I think this can be resolved (and make other things easier) if we add a new property to Spawn target->HasTarget(). HasTarget() will get set whenever a player (or spawn) targets someone or some thing. My current brutish check for if( target->GetTarget() ) crashes, because if my target has no target, "GetTarget()" isn't there. Right? Little confused, but I think that's what's going on. FIXED
  
  target->HasTarget() returns true if target has himself targeted Don't nuke your friends!
  
  Next, maybe inside ProcessSpell() is not the best place to calc this out... but before, and pass targets_target as a new param. Reason being is that FaceTarget for players casting through, seems to face the Player they have targeted and not the NPC. Pretty sure that's not correct.
  
  Have to add some additional checks for in/out of group, because I think things act differently depending on this.
  
  Last, because we have no "Friendly" spell definition, all spells are of type "Enemy" (which is a rude way of saying anything attackable that isn't self), so Heals are considered "Enemy->IsFriendly"... not sure this is the best implementation of this, but changing it would require a major re-write of spells I am not willing to undertake in 0.7.1.

This is not committed yet, I'll work on it some more tomorrow. I'm leaving my JA's Test Server up with this code in place, in case you want to try it out.

Any advice is welcome.

[alfa]

Does the "cast through target" work also if you have a MOB targeted and cast something (enemy), it lands on the MOB, but if you cast (friendly) it passes through the MOB and lands on whomever the MOB has targeted?

Or is cast-through only viable for targeting other Player Characters?

Thanks

Yes, when you target a mob all benefics spells come on mob target. Also if you target a player, all benefics spells go to your target, all dfamage spell go on mob