Machiavelli

Actually problem is that we don't handle SMSG_MOVE_SET_COLLISION_HGT (0x516), CMSG_MOVE_SET_COLLISION_HGT_ACK (0x517) and MSG_MOVE_SET_COLLISION_HGT (0x518) packets.

SMSG_MOVE_SET_COLLISION_HGT is sent at mounting and dismounting (just before SMSG_DISMOUNT). Structure used in 12340: packed guid of player + dword packet counter + float collision height.

CMSG_MOVE_SET_COLLISION_HGT_ACK is sent by client as reply. Structure: packed guid of player + dword packet counter (same value as in SMSG) + MovementInfo + float collision height (same value too).

I have do idea what third packed is used for...

Collision height is dependent from race and gender. For dismounting it can be taken from CreatureModelData.dbc. For mounting we must calculate it somehow taking into account mount height also. I currently don't have exact formula, only approximation.

The correct formula can be found in the client code. When logging in, mounted, the client does not expect SMSG_MOVE_SET_COLLISION_HGT and calculates the collision height itself.

How the client calculates it boils down to this:

Player Scale * Mount's CreatureModelData.MountHeight (field after CollisionHeight) + Player's CreatureModelData.CollisionHeight * 0.5f;

These are the most likely scenario's why DELETE+INSERT would cause data loss.

1. Desynchronisation - the database layer causes the INSERT to be executed before the DELETE (causing a duplicate error, and eventually a deletion of the record)

2. Disconnection - the connection to the MySQL server severs after DELETE statement, the INSERT statement can not be executed/

Both can be prevented by proper transaction usage (for which the database layer respects serialization, so the DELETE is actually executed before the INSERT). - I'm not sure how this is done in MaNGOS.

As for why INSERT .. ON DUPLICATE KEY UPDATE is faster; the MySQL server will not waste time re-checking indexes for both INSERT and DELETE statements.

Actually REPLACE is no different than DELETE+INSERT in terms of performance. The ideal query would be INSERT... ON DUPLICATE KEY UPDATE.

Wrong section?

Thank you very much

Or set the command to security 0, and create a new row in the game_tele table that represents the required security level..

Then add ingame check when using the command for combat, if gmlevel > 0 he can port in combat, else he cannot.

The rest should speak for itself.

* Lets Patman128 know *

Thanks for your reaction, Paytheo.

Anyone else that can counter or validate this?

There has been an issue that came to my attention.

Rogues restealthing an aweful lot of times while duelling.

To my knowledge, this is possible when the rogue gets out of combat, either by time or by distance.

Seeing as how this restealthing has reached to a maximum in recent PVP occurances, I thought the problem lies by the 'threshold' as to when the timer or distance has been exceeded to knock the player out of combat.

Then someone with retail experience told me that in retail duels, combat never ends.

You accept the duel, combat is turned on, you fight, there is a winner, the duel ends, combat is over. - And nothing different.

Can anyone validate this, react on it, and what not?

This is an issue i'd like to see fixed for the sake of balance amongst player classes.

Thanks!

Machiavelli