The_Game_Master

Cool, should work for current branch as well. With small changes.

How does the patch system works? Sorry for noobish question.

I would use this instead for Player.cpp --- a/src/game/Player.cpp +++ b/src/game/Player.cpp @@ -1502,6 +1502,10 @@ bool Player::BuildEnumData( QueryResult * result, WorldPacket * p_data ) *p_data << uint32(char_flags); // character flags // character customize flags *p_data << uint32(atLoginFlags & AT_LOGIN_CUSTOMIZE ? CHAR_CUSTOMIZE_FLAG_CUSTOMIZE : CHAR_CUSTOMIZE_FLAG_NONE); + // characters faction change flags + *p_data << uint32(atLoginFlags & AT_LOGIN_CHANGE_FACTION ? CHAR_CUSTOMIZE_FLAG_FACTION : CHAR_CUSTOMIZE_FLAG_NONE); + // characters race change flags + *p_data << uint32(atLoginFlags & AT_LOGIN_CHANGE_RACE ? CHAR_CUSTOMIZE_FLAG_RACE : CHAR_CUSTOMIZE_FLAG_NONE); // First login *p_data << uint8(atLoginFlags & AT_LOGIN_FIRST ? 1 : 0);

The patch is wrong, try to add the code in the specific AchievementMgr.cpp structure.

Rev: 9900+ Database: YTDB, rev 547 Bug description: Npc's spawn only for first difficulty (level 60) when level 80 players enter the battleground even if the npc's have all correct spawnmasks (15). This happended after 25 man HC instances were implemented. Can anybody confirm this? It dosen't appear to be a database problem.

Starting from patch 3.2.0 the restriction that prevents players from creating both Horde and Alliance characters on a PvP realms has been lifted. It's only fair to change AllowTwoSide.Accounts accordingly since the default realm type is set to 1 (PvP). Revision for wich this patch has been made for: 9900+ Patch author: me Source: http://www.wowwiki.com/Talk:Patch_3.2.0_%28undocumented_changes%29 (Can be confirmed you know where) diff --git a/src/mangosd/mangosd.conf.dist.in b/src/mangosd/mangosd.conf.dist.in index fbf9a21..9ef6bb0 100644 --- a/src/mangosd/mangosd.conf.dist.in +++ b/src/mangosd/mangosd.conf.dist.in @@ -772,7 +772,7 @@ Motd = "Welcome to the Massive Network Game Object Server." # ################################################################################################################### -AllowTwoSide.Accounts = 0 +AllowTwoSide.Accounts = 1 AllowTwoSide.Interaction.Chat = 0 AllowTwoSide.Interaction.Channel = 0 AllowTwoSide.Interaction.Group = 0

8661 fixes this talent, but adds a problem to it as well. Sanctified Wrath should NOT reduce resilience. In the present state resilience it's ignored by 50%.

You should add a TO DO list.

Rev: 9808 Description: This should be enough <screenshot link was here>

Still not working properly. 20k only from talents. Consider updating the spell for 3.3.2 as well. + // Save value of further damage + m_currentBasePoints[1] = damagetick * 2 / 3; + damage += damagetick * 3; - damage += damagetick * 4;

Confirmed! Appeared after http://github.com/mangos/mangos/commit/8d982dbf555a25c480c4dae7ec2c79c378d4ad3c

BUMP! Works fine.

Please move to rejected.

Try this. bool Map::loaded(const GridPair &p) const { // crash guard if x, y coordinates are outside grids if ((p.x_coord >= MAX_NUMBER_OF_GRIDS) || (p.y_coord >= MAX_NUMBER_OF_GRIDS)) { return false; // consider already loaded, skip } else { return ( getNGrid(p.x_coord, p.y_coord) && isGridObjectDataLoaded(p.x_coord, p.y_coord) ); } }

I think you applyed the patch in the wrong void. "void Map::MessageDistBroadcast(WorldObject *obj, WorldPacket *msg, float dist)" != "bool Map::loaded(const GridPair &p) const" "void Map::MessageBroadcast(WorldObject *obj, WorldPacket *msg)" allready has a grid check. Your crash it's at Map.cpp:527 not related to this one in my opinion.

Rev: 9765 Custom core, lots of patches but none that could influence this. http://pastebin.com/wVW0KghN Any ideea how the crash can be avoided at "if (!m_target->isAlive() && pCaster->IsNonMeleeSpellCasted(false))"? I want to mention that i didn't modify anything related to "case SPELL_AURA_PERIODIC_LEECH:"

One of your posts helped me yesterday fix a crash, so i'm making you this present. diff --git a/src/game/Map.cpp b/src/game/Map.cpp index 0f3c99b..1be6033 100644 --- a/src/game/Map.cpp +++ b/src/game/Map.cpp @@ -580,6 +580,10 @@ void Map::MessageDistBroadcast(WorldObject *obj, WorldPacket *msg, float dist) bool Map::loaded(const GridPair &p) const { + // crash guard if x, y coordinates are outside grids + if ( (p.x_coord >= MAX_NUMBER_OF_GRIDS) || (p.y_coord >= MAX_NUMBER_OF_GRIDS) ) + return false; // consider already loaded, skip + return ( getNGrid(p.x_coord, p.y_coord) && isGridObjectDataLoaded(p.x_coord, p.y_coord) ); } I know it's not the proper way to fix it. But it should work.

Please move this to accepted, it's allready in repo.

Rev: 9765 How it SHOULD work: Each side has atleast 5+ or 6+ inside battleground the game should go on How it DOES work: Every game will end in 5min (or configured time) if the Battleground is not filled with the maximum amount of ppl

Confirmed! Tested this today reseting the talent tree a few times and every time i used first rank i got 3 (Will of the Necropolis), 5 (Blood Gorged) aditional talent points. P.S. You need to have all trainer spells learned in order to make this work. I can't figure out what spells tough.

Bump! Please review this.

Delete this post. My bad.

What's wrong with the one from post #36?

It was this guy!

Revision: 9748 This crash appeared most likely in revision 9736. I got this every 10-45 minutes. http://pastebin.com/khDXRDLb http://pastebin.com/q4DSaQwC http://pastebin.com/gmWVwL5P http://pastebin.com/TWQAs8g2 Custom patches, that may influence this: diff --git a/src/shared/Errors.h b/src/shared/Errors.h index 701bda9..68b1a6a 100644 --- a/src/shared/Errors.h +++ b/src/shared/Errors.h @@ -71,7 +71,7 @@ if (!(CONDITION)) \\ #ifdef MANGOS_DEBUG # define ASSERT WPError #else -# define ASSERT WPError // Error even if in release mode. +# define ASSERT(X) do {} while(0) // Error even if in release mode. #endif #endif I noticed a ASSERT in the map system before applying that patch, so i guess after it jumped the assert the crash occured. The problem is, that this happens over and over again @-), preutty mutch the same thing if the ASSERT was there, only diffrent output. After a day of testing looks like i was right, reverting 9736 and 9738 increased stability by more then 500%.