stfx

How about making a php page? This way it doesn't depend on the OS

Link works for me even with http - what browser are you using?

In the log m_mapId = 4294967295 which is -1 represented in unsigned. Where exactly are you? Are your players allowed in non retail like areas?

Great, it would be very useful if you can log whenever a packet is being sent with the new version but would not with the old one

I was just wondering if I could finally get this working for the main branch yet or if I have to drop to ONE just to get my OutdoorPVP?

This modification/branch is being developed on master but Salja is actively backporting it to One. So yea, it works on the main branch as well as on One. Checkout Xfurry's link to get the newest version

master as well as TC have m_CombatTimer = 5000 ... just saying.

This has been discussed several times, especially as of recently. The Luda has explained some issues with improving security (not that I believe he is against it any way, just a daunting task)

Most of the spam I see comes from individual accounts that are created and used only once (maybe they get banned quickly?) I would recommend making new accounts as a Pending user group that must post a minimum number of posts in a special thread, that way the spam that does happen can be centralized in one area and prevent them from getting to other threads. Legitimate users would just have to post something coherent that's obviously not spam and then they would be allowed to post to the rest of the forums. The reason for suggesting this way is that it wouldn't require any new plugins/modules to the forums software.

Then a new moderator could be assigned to this "spam catcher" thread and ban spammers and occasionally purge the thread

No, please dont. I really hate those forums where you need to get permission to post or something like that. Simply add a few random custom questions on register - this catches all spambots

that if (markSpellId == 0 || debuffSpellId == 0) check kinda seems useless. How could they ever be zero? If the compile complains use case default: in stead of case 37125:

Hopefully fixed after https://github.com/xfurry/mangos/commit/e3dea09af89fff7502834f18eac9e63606a3d148

WoWWiki is wrong, maybe it was like that in vanilla but I am 100% sure that this patch is correct for TBC or higher

Yeah nothing changed so far. This is getting ridiculous

Thanks for the contributions, pushed those and a few other changes. This hopefully fixes compile for gcc / cmake

@amaru

@ BG_TEAMS_COUNT

depends on the meaning what this is required for - from normal view there should be no need to include this to shared define (it is used for oPvp, not BG) - so maybe a new define would be better choice

If you would look at the comment in gameobject.h you would see that it says that we should define a generic enum for both cases as they have practically the same use for BG and OPvP. Btw I did not know that the current implementation would cause compile issues with some platforms

The variable m_isunderwater was removed and replaced by m_MirrorTimerFlags (and kinda by m_MirrorTimerFlagsLast) in the new map format commit: https://github.com/mangos/mangos/commit/485cb0cd34d47b68b098574060ce48379e6608e0

diff --git a/src/game/Player.h b/src/game/Player.h
index 836baf2..6fc9d58 100644
--- a/src/game/Player.h
+++ b/src/game/Player.h
@@ -68,7 +68,7 @@ enum SpellModType
    SPELLMOD_PCT          = 108                             // SPELL_AURA_ADD_PCT_MODIFIER
};

-// 2^n values, Player::m_isunderwater is a bitmask. These are mangos internal values, they are never send to any client
+// 2^n internal values, they are never sent to the client
enum PlayerUnderwaterState
{
    UNDERWATER_NONE                     = 0x00,

Actually the yell range depends on the grid system which its by default 120 yards in the instances as defined in the config file by Visibility.Distance.Instances = 120. The thing is on retail the yell range is about 300yards as written on http://www.wowwiki.com/Chat - atleast for players that is...

Fixed in [s1451]. Thanks

Fixed in [s1448]

Rejected as it will be backported someday

Stuff like this should definately be patched against master because its in no way only One related as they have the same related code. And therefore should be reviewed by master devs

Thanks.

I took the liberty of applying your patch to mangos master without any code cleanups to make code review easier. While code cleanups are usually nice there is a lot more to be changed there like removing whitespaces within brackets, using camelCase, using type* varName instead of type * varName, and so on which can be done by a dev easily...

http://pastebin.com/AUXq544M

Pushed to One in [s1431]. Still waiting for https://gist.github.com/1301721 to be added to master

yes, a normal guid is always 8bytes while a packed one is between 1 and 9 (I think?). Meaning that it can break the whole packet if you use the wrong one

Alternative patch to fix the problem was added in [11641]. Thanks contributing

Should be fixed as of [10046]. Can anyone confirm?

Alternative patch was added in [11039] which fixed this problem. Thanks nonetheless