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...