LordJZ

These aren't opcodes but rather their client handlers. And AFAIR this is TOM_RUS's form of handler names so ...

If you add tag parsing into [code], some things like this will break: some_array[i] = 123; (can be solved by creating another tag like [pre])

No' date=' I don't want to use a (not localized) development version. I've disabled js and all FF addons, still lags the same.I've got my own IPB forum, so I've opened the most overloaded page of 30kb compressed (400kb uncompressed) html, and when I scroll rapidly through it trying to blow up my mouse I can only get FF to 15% CPU usage. A small scroll of the current page makes FF consume 25% CPU (1 core) and it lags. Really lags. IDK why. Probably an engine issue? Thanks for the feedback. Edit: I've also tested other browsers on the same machine, scrolling through the current topic: Opera 10.62 — almost no lags Safari 5.02 — almost no lags Google Chrome 6.0.472.63 — lags IE 7 — no lags at all (what?) I tested with: Opera 10.70 build 9053 - works fine Google Chrome 6.0.472.63 - lags IE 8 - works fine So I guess it's problem with Google Chrome, not forum engine. Test with FF.

Well the footer is so small and makes my eyes bleed. I guess that's my personal issue. I've disabled js and all FF addons, still lags the same.I've got my own IPB forum, so I've opened the most overloaded page of 30kb compressed (400kb uncompressed) html, and when I scroll rapidly through it trying to blow up my mouse I can only get FF to 15% CPU usage. A small scroll of the current page makes FF consume 25% CPU (1 core) and it lags. Really lags. IDK why. Probably an engine issue? Thanks for the feedback. Edit: I've also tested other browsers on the same machine, scrolling through the current topic: Opera 10.62 — almost no lags Safari 5.02 — almost no lags Google Chrome 6.0.472.63 — lags IE 7 — no lags at all (what?)

Good: a little more convenient interface Good: a little more faster (but still takes a second to load a page, probably not server issue) Good: military time, yeah, thank you so much! It would be even better if you can switch between "Today 14:17:04" and "30 minutes ago". Good: redirects are now faster, yay! Bad: no tooltips for partial topic names (go to index, see «Congratulations for this new b...» topic under «Forum Feedback & Help») Bad: footer really sucks, I'm writing this post with my eyes at the bottom of my monitor. I have 1680x1050 fullscreen. (If nothing changes I'll create a custom CSS rule to add a 200px pad at the bottom.) Bad: scrolling lags in FF 3.6.10. I'm running Intel Quad Core each 2.5 Ghz and 4 GB memory. Thank you.

lol 1) mangos already uses them 2) 99% compiler makes more proper inlines then user

Client sends both.

I wonder how do you know their speed is reduced to 100%. Probably they are already affected by JoJ from a paladin or by Focused Assault.Also, it looks like the 'no-fleeing' aura handler is terribly outdated — the 'fleeing' mechanic has been reworked iirc in bc.

Glyph of Rake — Your Rake ability prevents targets from fleeing. 'Fleeing' is a process of a mob calling for assistance from other mobs, it has nothing to do with Aura::HandleAuraModIncreaseSpeed. (or prove me wrong)

What? Do you know what 'fleeing' means?

see ChatHandler::HandleTicketCommand // ticket respond if (strncmp(px, "respond", 8) == 0) { std::string plName = ExtractPlayerNameFromLink(&args); if (plName.empty()) { SendSysMessage(LANG_CMD_SYNTAX); SetSentErrorMessage(true); return false; } uint64 guid = sObjectMgr.GetPlayerGUIDByName(plName); if (!guid) { SendSysMessage(LANG_PLAYER_NOT_FOUND); SetSentErrorMessage(true); return false; } GMTicket* ticket = sTicketMgr.GetGMTicket(GUID_LOPART(guid)); if (!ticket) { PSendSysMessage(LANG_COMMAND_TICKETNOTEXIST, GUID_LOPART(guid)); SetSentErrorMessage(true); return false; } if (!*args) { SendSysMessage(LANG_CMD_SYNTAX); SetSentErrorMessage(true); return false; } [b][color=red] ticket->SetResponseText(args);[/color][/b] if (Player* pl = sObjectMgr.GetPlayer(guid)) pl->GetSession()->SendGMResponse(ticket); return true; } see void GMTicket::SetResponseText and HasResponseText void SetResponseText(const char* text) { m_responseText = text ? text : ""; m_lastUpdate = time(NULL); std::string escapedString = m_responseText; CharacterDatabase.escape_string(escapedString); CharacterDatabase.PExecute("UPDATE character_ticket SET response_text = '%s' WHERE guid = '%u'", escapedString.c_str(), m_guid); } bool HasResponse() { return !m_responseText.empty(); } So your patch is incorrect.

Confirm, first found after 10156

Are you sure you have no custom patches installed?

zergtmn: Hmm I guess I explained my thoughts a little bad. I meant that function GetSpellProto actually CAN return NULL if an Aura object was somehow deleted improperly. Crash dumps posted here at forums prove that. P.S. kamikazetg: hate to say that, but you previous post is a fail. You _have_ mentioned spellauraholder problem in CoS description. You haven't submitted any content in this thread. You haven't given an adequate answer to zergtmn's 1st post in this topic.

zergtmn, at least the OP is right about spellproto being null for some aura holders...

Hmm, I can't see a place in the code where m_deletedAuras used without removing Aura from m_modAuras. See for yourself: void Unit::RemoveSpellAuraHolder(SpellAuraHolder *holder, AuraRemoveMode mode) { // Statue unsummoned at holder remove SpellEntry const* AurSpellInfo = holder->GetSpellProto(); Totem* statue = NULL; Unit* caster = holder->GetCaster(); if(IsChanneledSpell(AurSpellInfo) && caster) if(caster->GetTypeId()==TYPEID_UNIT && ((Creature*)caster)->isTotem() && ((Totem*)caster)->GetTotemType()==TOTEM_STATUE) statue = ((Totem*)caster); if (m_spellAuraHoldersUpdateIterator != m_spellAuraHolders.end() && m_spellAuraHoldersUpdateIterator->second == holder) ++m_spellAuraHoldersUpdateIterator; SpellAuraHolderBounds bounds = GetSpellAuraHolderBounds(holder->GetId()); for (SpellAuraHolderMap::iterator itr = bounds.first; itr != bounds.second; ++itr) { if (itr->second == holder) { m_spellAuraHolders.erase(itr); break; } } holder->SetRemoveMode(mode); holder->UnregisterSingleCastHolder(); for (int32 i = 0; i < MAX_EFFECT_INDEX; ++i) { Aura *aura = holder->m_auras[i]; if (aura) [b][color=red] RemoveAura(aura, mode);[/color][/b] } holder->_RemoveSpellAuraHolder(); if (mode != AURA_REMOVE_BY_DELETE) holder->HandleSpellSpecificBoosts(false); if(statue) statue->UnSummon(); // If holder in use (removed from code that plan access to it data after return) // store it in holder list with delayed deletion if (holder->IsInUse()) [b][color=red] m_deletedHolders.push_back(holder);[/color][/b] else delete holder; if (mode != AURA_REMOVE_BY_EXPIRE && IsChanneledSpell(AurSpellInfo) && !IsAreaOfEffectSpell(AurSpellInfo) && caster && caster->GetGUID() != GetGUID()) caster->InterruptSpell(CURRENT_CHANNELED_SPELL); } void Unit::RemoveAura(Aura *Aur, AuraRemoveMode mode) { SpellEntry const* AurSpellInfo = Aur->GetSpellProto(); // remove from list before mods removing (prevent cyclic calls, mods added before including to aura list - use reverse order) if (Aur->GetModifier()->m_auraname < TOTAL_AURAS) [b][color=red] m_modAuras[Aur->GetModifier()->m_auraname].remove(Aur);[/color][/b] else sLog.outError("Found aura with Id > TOTAL_AURAS: %u", Aur->GetModifier()->m_auraname); // Set remove mode Aur->SetRemoveMode(mode); // some ShapeshiftBoosts at remove trigger removing other auras including parent Shapeshift aura // remove aura from list before to prevent deleting it before ///m_Auras.erase(i); DEBUG_FILTER_LOG(LOG_FILTER_SPELL_CAST, "Aura %u now is remove mode %d",Aur->GetModifier()->m_auraname, mode); // aura _MUST_ be remove from holder before unapply. // un-apply code expected that aura not find by diff searches // in another case it can be double removed for example, if target die/etc in un-apply process. Aur->GetHolder()->RemoveAura(Aur->GetEffIndex()); // some auras also need to apply modifier (on caster) on remove if (mode == AURA_REMOVE_BY_DELETE) { switch (Aur->GetModifier()->m_auraname) { // need properly undo any auras with player-caster mover set (or will crash at next caster move packet) case SPELL_AURA_MOD_POSSESS: case SPELL_AURA_MOD_POSSESS_PET: case SPELL_AURA_CONTROL_VEHICLE: Aur->ApplyModifier(false,true); break; default: break; } } else Aur->ApplyModifier(false,true); // If aura in use (removed from code that plan access to it data after return) // store it in aura list with delayed deletion if (Aur->IsInUse()) [b][color=red] m_deletedAuras.push_back(Aur);[/color][/b] else delete Aur; } P.S. Glad at least someone tried to dig deep enough into Laise's aura code

Yes they are hacky, and I don't think they will ever be added to master mangos

I can confirm. The bug is because Blizz added a new, rather wide, areatrigger around FR, so the tiny one — flag standpoint — is hidden. Client only sends the opcode of the large areatrigger. Also, IIRC there was a fix to FR in some repo at github. Try looking at gc/mangos, or zergtmn/mangos.

Yeah so my question was — why the hell aren't they doing it? Anyway, let's keep the discussion on topic

No Skirnir you haven't understood me. I have repeated it in 30 minutes on my localhost with only one player — me. My question was about server owners, whose thousands of players suffer from constant server crashing (as I understand the level of the resolved problem)

Well that discussion of Laise's commits' revert possibility was making none sense at all so I just confirmed the crashes... Anyway, thanks for looking into the problem. And BTW, why the hell am I the one who managed to describe the crash repeat steps after just running mangos at localhost for 30 minutes, and thouse who have servers with gigantique online only slacked and whined about crashes here at forums? ....

VladimirMangos: I said it a few times before that mangos crashes with Eyes of the Beast. My steps: level to 80, tame a pet with some dot auras (probably some of these abilities), use Eyes of the Beast and run really far away from you character, then find a mob, apply some auras from pet's abilities so that they expire a bit after you have Eyes of the Beast expired. Probably you'd need to play with debuff & EotB expire a little more. Before that Laise's revert I managed to crash mangos at Windows x86, and linux x64. Tbh I did this because I was testing mtmaps patch, but the crash occured with only 1 map update thread too.

After [10232] this topic is deprecated and should be locked

Confirm, also http://www.wowhead.com/spell=57345 (DM: Greateness)

As pasdVn pointed out, Unit::HasAuraAndMechanicEffectMask is also bugged, so the patch is updated: http://paste2.org/p/921034