Update on the NPC when you hover over it

[virusav]

After https://github.com/cmangos/issues/issues/428: "Cursor is drawn at boot NPC in the world, and when the conditions for spellclick not redrawn".

Duplicate the topic from the forum cmangos (http://cmangos.net/thread-6540.html): cmangos_335a_12674_sd2_3021 Tested on NPC 35803. I went into the game, standing near the NPC, direct on over and see the "sword" (NPC attack). Quest and receive an item desired, direct on NPC, but nothing changes.

If you kill the NPC and resurrect, the cursor changes to a "gear". Throw out an item and refuse the quest, but the cursor does not change.

05.02.2011 I wrote a patch for spell 1462, which should be transmitted flag only to caster. I changed void Aura::HandleAuraEmpathy(bool apply, bool /* Real */) and prescribed treatment in the Object::BuildValuesUpdate.

In the end, everything worked as it should. With spellclick problem, so interested, because could rewrite the work Object::BuildValuesUpdate since.

At what point is a sending data to the client when the cursor on the NPC?

[xfurry]

This is confirmed.

I think that the update packet is not sent at the right moment. https://github.com/cmangos/mangos-wotlk/blob/master/src/game/Object.cpp#L473

This also happened before, for the vehicles which have click conditions in SD2. For example this condition: https://github.com/scriptdev2/scriptdev2/blob/master/scripts/northrend/ulduar/ulduar/instance_ulduar.cpp#L952

[virusav]

During debugging to line "if (!Target->canSeeSpellClickOn((Creature*)this))" is not even reached. Entrance to this line was when the server boots, so I declined to specify where is going to send the package to the client when the cursor on the NPC. If you kill the NPC and revive, the flag will come.

Perhaps the problem is not in check, and that the method Object::BuildValuesUpdate just not called at the right time. A feeling that the Object::BuildValuesUpdate were called when loading the game object in the scope of the player.

[xfurry]

Perhaps the problem is not in check, and that the method Object::BuildValuesUpdate just not called at the right time. A feeling that the Object::BuildValuesUpdate were called when loading the game object in the scope of the player.

Exactly. That's why the flag changes when you get out of sight or do a log out, but it doesn't change if the condition is met while the creature is still in visible range.

[Schmoozerd]

This is a designed problem with the condition system. When the state of a condition changes, there is currently no "marker" to inform all uses of the changed condition about the change. Hence there is no UpdateValue packages created in this case of a change.

[virusav]

Once you know where the problem is, you have to edit. :) Or tell the problem areas in code.

[Schmoozerd]

Well. The old system for npc-spellclick spells depending on ie quest-id fields in the tables had been no problem. When a quest-status was updated, changes for spellcklick status was checked and dependendly made public to player. (This behaviour will also happen for conditions i think)

However generic conditions are more complicated to "pass on" - as a change in them might be triggered by almost anything. So even if we would mark npcs that rely on conditions in some places, and check their status relative to some players on timer basis or event-dispatching like, there will always be complicated issues at hand.

I could not think of a concept to make this possible with conditions that are checked instead of condition-changes that are pushed around.

[virusav]

Checking relevance.

[BenDol]

@virusav how's the check going?

[virusav]

I don't have a server right now, so I can't check.

[killerwife]

Okay, this is an ongoing issue. We now have an option for rebroadcasting updateflags, specifically dynamic updateflags. This has to be done at case by case basis, there is no magical fix. The rebroadcast is doable with UF_FLAG_DYNAMIC and an example is inside HandleAuraEmpathy