XTZGZoReX

Posted v2 of patch. Mostly cosmetic stuff.

The enum is the exact data that's used on retail. It is found in similar way.

What it does: * Sends SMSG_PET_TAME_FAILED with PETTAME_* which is client-side constant. * Replaces some returned SPELL_FAILED_* constants in SPELL_EFFECT_TAMECREATURE handling with SPELL_FAILED_DONT_REPORT, as result should be handled by SMSG_PET_TAME_FAILED packet. Patch: http://paste2.org/p/471580 PATCH v2: http://paste2.org/p/471832 Final patch v3: http://paste2.org/p/473061 Please test and report any "weirdnesses" when taming pets.

What I meant was that with the current implementation, a barbershop purchase sometimes (at least people say so) crash the client. Do you think not sending skin tone can be cause of this?

This can maybe be source of client crash sometimes?

Well, if we were to clean it up totally, we should've included it in main sources (instead of contrib) and use defines already in those sources (i.e. ACE_UINT32 -> uint32, etc).

Nice work - but I swear, autotools are crazy .

It was moved after I posted, but no one posted in thread .

I might just pull this locally and do the corpse management patch now, since I have the day off .

Someone please move this to Accepted .

New patch posted - fixes shutdown crash. Thanks to balrok for suggestion.

Fixed in [8563] - not related to this patch . Thanks for reporting, though.

This happens both with and without this patch or only with this patch?

I don't get what you mean and/or how it relates . Can you explain better?

Exactly. Our entire BG system is kinda badly designed, and would take ages to rewrite (to make map exist as soon as BG exists). So for now, this is all we can do.I can try adding the assert, since balrok is right - the map should definitely be valid at the areas it's being used. EDIT: Oh, and balrok, similar code can be done for outdoor PvP patch if you still maintain it. Currently outdoor PvP patch uses HashMapHolder way too much. I'll poke you on IRC. EDIT2: Updated patch in original post.

Here's the info you requested. Everything else that's known is already in MaNGOS' source.

PATCH: http://paste2.org/p/442584 PATCH v2: http://paste2.org/p/443389 PATCH v3: http://paste2.org/p/443624 What this does: It makes BattleGround objects use the same method of map lookups as Ambal made WorldObject objects do. This way, we can avoid MapManager and HashMapHolder lookups, which is both safer and faster for map multi-threading. Note that I chose to let BattleGround objects still have a map ID, because it's needed in some special cases (this is mostly because we use BattleGround objects as templates, which is bad, but I don't want to rewrite it all ). When you test this, look for: * Do BGs start and end correctly? * Do BG creatures/gameobjects spawn/despawn correctly? * Do BG flag pickup/drop events work correctly? * Do BGs crash (if so, include backtrace!)? Who has been writing this: Me, with help from balrok and kolomati. Thanks to everyone who tests this, also.

Last I checked, scripts were loaded right after the CreatureAIRegistry (or before, don't recall). Either way, theoretically, there wouldn't be any issues.

I'll poke Ralek and get back to you ASAP regarding that.

I was personally thinking of doing this, as Ralek gave me some nice info on the DBC, but seems I'm too slow. Either way, good job! About time we stop using those damned hardcoded values. EDIT: Wait - you gotta do the creature->isPet() check, since allowing scripting pets probably is a bad idea.

Looks good to me.

Good job - looks sane to me.

Nono, I'm not talking of opcodes either. I mean: case GOSSIP_OPTION_SPIRITGUIDE: case GOSSIP_GUARD_SPELLTRAINER: case GOSSIP_GUARD_SKILLTRAINER: prepareGossipMenu( player,gossip->Id ); sendPreparedGossip( player ); break; In Creature::OnGossipSelect. Stuff like this.

I believe this is a rather hacky fix, even though it may work as intended.

I mean the handling of GOSSIP_TYPE_SPIRITGUIDE or whatever the npc_option constant was.