VladimirMangos

Fixed in [10682] in proper way. For correct work required DB support in fill 'item_convert` by correct data.

As zergtmn clarify by irc: different items show when character fit to reputation reqs and when not fit. So if character can't buy item then show reputation case, and when can buy then we see item without reputaion requirement. Reverted in [10678]

Anywhere or at BG how he reference?

But then http://www.wowhead.com/item=50335 have faction requirements and this directly not work for client if item used by another account character without faction reputation. So client _do_ faction_ check for BoA items for any characters. Then unclear how this can work without replace item by another in time transfer to another account character at least.

You meaning that original item must replaced at mail send by this? Or really sell this item? but show original in vendor list? I can redo fix in replace item way if someone clarify this part. This also can be useful for resu send items / character converion to diff faction characters at same account.

if server can't parse first packet with build number then it will can't report about version mismatch.

"Where is my error in reasoning?" as i retest reputation checked by client, server only re-check against cheating. So my fix not work in fact. And any fix with same item will not work. Read my next post with questions....

You meaning that original item must replaced at mail send by this? Or really sell this item? but show original in vendor list?

fix only related use "bind to account items" in part ignore reputation req at use. But you still need required level for use.

Added with additional changes for exclude use real diff for movegens case in [10677]. Thank you

It fixed in [10676]

I think i know what problem code part, possible will fix soon as test show that fixed.

fixed in [10675]. Thank you for reporting.

This is wrong. It just made selection more unexpected spells as trigger source.

So base at new data patch expected to be update?

http://gist.github.com/659141 version compatible with master code with small changes. From testing see only one porblem: at teleport to poin near some waypoint/random walking creature it in run mode attempt resync own position for real diff time from last update. So run to next point instead walk... but _normal_ run with expected run speed... no as some extra speed object... At normal enter to area by player run/walk no described picture because visibility radius > real visible area and mob have small time for resync in grey zone Because teleporting in to no-player-around places possible only for GM in most cases then this mostly GM view problem. I not sure that this can be real stopper from adding patch to repo because it solve many other real porblems with mob/object state

move to rejected as outdated version

move to rejected as outdated version

Just for note: pVictim->GetOwner() != this not good way check in like cases. GetOwner, GetPet, Get* etc _search_ object pointer in guids map, so useless lost time when you can compare pVictim->GetOwnerGuid() != GetObjectGuid() With this fix and move repeating code to new function in [10672]. Thank you I will backport to 0.12 in my next backporting run...

What stable at debian can be just not work at other system because missing patches. You can always use non built-in ACE version in mangos by your choice... Ofc, better have as built-in version that work good at most systems, but for example for FreeBSD this near to impossible.

we need anyway in many cases realdiff. So i only meaning expire time cases that better have as exactly value and then will not calculation errors added at each increase. But i agree that in most cases we need for any objects realdiff. If do it then do for all worldobjects case maybe as generic sollution (item get realdiff from owner anyway) So if do generic solution for worldobject then we can use expire timer in current way. This will independent small problem what better timer or final time.

Need know original author. This is main what stop me from review start. As i read mercury have similar full history repo and then possible find commit when related lines added (git blame in git case) and then referenced author in commit notes. Ofc, authors of patch addoption changes to mangos also will credit in final commit. I also not like some lines in patch but its can be easy rewrited. For example i clearly not like modify loaded dbc content.

In [10669]. Thank you

I backport in [s0369] lines form current master sources. Its different from sugested patch in return result. I think this better for consistence. [added]oh, i fix isInLineOfSight case, that why result diff. Will apply to original case function also [added2]In [s0370].

Changes can be acceptable as official way work but 1) need preserve current GM option work way 2) possible add config setting for control current custom way work and default official way. In both cases possible instead modify string need add new short version. /ignore for permanent ignore some characters, current way work /dnd is temporary ignore anyone.