FragFrog

Doxygen extracts comments directly from the code Toinan67, which is partially the reason for its widespread use. But without structure and organisation in the code itself, doxygen (or any other automated documentation generation process) will not help much - it can build a list of callstacks and class hierarchies, but that by itself is not very usefull, at least, not in my experience. To make the code easier accesable to new developers it should undergo major refactoring, which seeing the size of the codebase is nearly impossible at this point.

I am with Vladimir on this one to be honest. Yes, comments are good and should be used where misunderstandings might arise, but creating a doxygen page really won't help you that much. Just look at the 'game' project directory - it contains (on my version) 257 files, the top of which is over 18.000 lines long - I have no idea whether this is considered normal for C / C++ projects, but if anyone on my old team of webdevelopers tried making a classfile longer than 200 lines he'd better have a damn good explanation during code review time, and that is including comments. There simply is very, very little factorisation making it next to impossible for a new developer to know just what changing a line might do - it could have no effect, or it could effect any of a thousend, a tenthousand other lines in that class / file. Perhaps seasoned C/C++ developers find it all easy and clear, but to someone used to a clear factorisation in small related groups it looks horrible. Since ScriptDev2 handles its script much better in this regard (a few dozen files per directory max, most sources under three, fourhundred lines of code) I am inclined to believe somewhere far in the past of Mangos development it all went wrong, or maybe the developers simply just like it this way. Either way, document all you want but I fear it is not going to make the source any clearer. Not meant as an insult to current developers by the way - you guys do an awesome job and I greatly admire how you all always seem to know just where to find a problem and fix it. I just think it's a maintainability nightmare

Have you checked the sticky at the top of this section to increase mangos stability? Using some of the tips in there we've gone from ~ 6 hours of uptime to more than a week with several hundred players online, using otherwise the same revision For the record, that is the 0.12 version of 8719 + TBCDB 0.0.2.2 + SD2 1476. Most important change is the increased stack size patch.

Possibly performance degraded with newer releases? We still use the 0.12 version of 8719 (tweaked for stability, see sticky in this section) in combination with MySQL5.1 community edition on windows server 2003 R2. Dual xeons and 4Gb of ram, though as said, we're rarely above ~15% CPU load and with grid unload active usually between 1Gb and 2Gb of total memory usage.

With about ~250 users online on our windows server we generally see no lag or "delay" issues and server load is usually at about 10% ~ 15% CPU usage, so no, can't say this sounds familiar. There's a few lagspikes just after startup, not sure what causes them, but after half an hour or so they usually go away and we generally don't restart more than once a week anyway, so it's not a problem for us.

That's still a join Just do a describe, you'll see it still refs both tables.

Update Added a whole lot of features and bugfixes since the last post here, see startpost for updated info I've tested the client, and it works on Ubuntu now (had to make a few changes to the code, but I expect it'll run on pretty much anything). Few graphical issues, mostly fonts, but nothing to worry about. Have not tested the server yet, but I expect it will work with no problems as long as you have an up-to-date Java VM installed.

I totally agree, hence my remark they are best avoided. TS seemed to want to select just the mail-items without doing a join on the mail table though, at least if I understood him correctly, only way to do that is with a subquery (or with a seperate query for each mail).

You could use a subquery to select the mail items seperately - something like SELECT `mail_item`.`id` FROM `mail_item` WHERE `mail_item`.`mail_id` IN ( SELECT `id` FROM `mail` WHERE `mail`.`account` = %s) And link them to the mail's themselfs manually in code. A lot faster than performing a seperate query for each mail, but probably still slower than just doing an outer left join as balrok suggested (not to mention subqueries are generally best avoided). What you must realise is that MySQL (to my knowledge anyway) cannot return multidimensional resultsets, at least not with more than two dimensions. You will never be able to get a list of mail's with a seperate array of mail-items' as part of the resultset.

I run Mangos on a 64 bit windows 2003 machine and it uses 3.5Gb without grid unloading. The document you link merely talks about 32bit windows, and yes, 32 bit windows can by default not address more than ~3.2Gb of memory, of which some reserved for the OS - though there are applications to address more memory. Simple fact of the matter is that with an integer you cannot go higher than an index somewhere in the four billion, or 2^32 - which is why there is 64 bit windows. Any 64 bit windows version can address just about limitless amounts of ram, even for a single process. Please, always make sure you link correct and up-to-date information (your article is 4 years old ): this is the correct overview, as you can see with the right compiler options on a windows server edition you can address roughly 8Tb of memory - that's about 8000Gb of memory. Actual resource usage by the OS is minimal compared to what is available from hardware anyway - I very much doubt you will see any difference whatsoever in performance between linux or windows (server) in this matter. In fact, seeing how often we find mangos updates along the lines of 'fixed *nix build' I am guessing Vladimir uses windows to test and develop, wouldn't surprise me if it actually ran better on windows.

Most of Mangos' memory usage is simply game data - maps, creatures, etcetera. Doesn't make one bit of difference if you load it into a windows or a linux machine, nor does it particularly matter how many users there are online (at least, not untill you get several thousand users on). Servers with 8Gb or even 16Gb are quite common these days, I doubt memory will ever be a problem. CPU speed, now that is a different matter. With no stable multithreading support I doubt you can go much higher than 3k ~ 4k users without getting loads of lag.

Wondered about this as well, but in the code it's 'load' - simply a typo in the comment, nothing to worry about. You could have just checked the commit yourself as well you know?

There are two different versions here: 1. The Mangos version - controlled by the Mangos team, this increases with each update. The last TBC Mangos was 7988, though an off-branch for TBC still exists here. 2. The client version - controlled by Blizzard. Client version 3.1.3 (Wrath of the Lich King) is just a name they give out to players. Internally, this version is referenced by the client revision number - 9947.

What bug does the patch fix? Moderators are unable to change a channel password unless they are already on it For which repository revision was the patch created? 8719, 0.12 backport Is there a thread in the bug report section or at lighthouse? Not that I am aware of. Who has been writing this patch? Me, FragFrog We come upon an interesting problem a few days ago. On our server it is custom to have two channels always available to users (for general chat and GM support). Since a moderator is not always online, sometimes these channels automatically change owner to a normal user. One of these users decided to then put a password protection on those channels, so effectively nobody could join them anymore. Moderators who were all not on those channels at the time were then unable to join them and the /password [channel] [newpassword] command does not work if you are not on a channel - as a result we had to restart to server to get access to those channels again. This patch is very simple: it always allows moderators to change a channels password, even if they are not actually on that channel. Written for the 0.12 backport but since the channel code is little changed I expect it is applicable for master as well. --- src/game/Channel.cpp | 6 +++++- 1 files changed, 5 insertions(+), 1 deletions(-) diff --git a/src/game/Channel.cpp b/src/game/Channel.cpp index e0fca88..fd430ed 100644 --- a/src/game/Channel.cpp +++ b/src/game/Channel.cpp @@ -274,7 +274,11 @@ void Channel::Password(uint64 p, const char *pass) if(plr) sec = plr->GetSession()->GetSecurity(); - if(!IsOn(p)) + // Always allow GM's to change a channels password - even if they are not on it. + if (sec >= SEC_GAMEMASTER) + m_password = pass; + + if(!IsOn(p)) { WorldPacket data; MakeNotMember(&data); --

I am affraid you have misunderstood Xarly. The patch already works as you propose, only with 2 logfiles (logfile 1 is full - start logfile 2. Logfile 2 is full, start with logfile 1 again). Have been using it for the past few weeks now without trouble, it's an awesome feature

Just tried to edit my post using Chrome to add the problems mostly arise in IE, only to find I cannot edit my post in Chrome either - just shows a loading animation on the 'Edit Post' button and that's it. Can we please have something working back? //edit With scripts disabled both editing as well as viewing works again for me in IE. Looks like a JS problem.

Keep in mind there are a lot of factors influencing the amount of bandwidth. For example, I used 1kb/s in my explanation because it yields nice round numbers, but if you use a higher level of compression this might easily become a lot less. Likewise, if you lower visibility distance not as many players will be able to see eachother and the bandwidth used is a lot lower as well. If bandwidth is a problem, there are plenty of ways to solve it

Quite simple: because it increases cubicly with number of players that can see eachother. Elaboration: consider 1 player sends 1kb of data per second to everyone in view - it is a rough estimation, but in my experience a fair one. If there are 2 players, this means 1kb + 1kb. For 3 players, this becomes: 1kb + 1kb (data for player 1 send to player 2 and 3) 1kb + 1kb (data for player 2 send to player 1 and 3) 1kb + 1kb (data for player 3 to players 1 and 2) = 6kb, or to put it differently, 3^2. Consider the following numbers: 10 players: 10^2 = 100kb 15 players: 15^2 = 225kb 20 players: 20^2 = 400kb 25 players: 25^2 = 625kb With two raids of 25 users each you're already looking at 1300kb/s bandwidth - while if you would have 10 raids of 5 people each the number of people is the same but the amount of bandwith would only be 250kb/s! So yes, large concentrations of players will (dramatically) increase the amount of bandwidth needed.

Mangos: 8719 - 0.12 backport Seems to have something to do with a battlemaster respawn? Revision: * * 8569 * Date 3:1:2010. Time 9:52 //===================================================== *** Hardware *** Processor: Intel(R) Core(TM)2 CPU E8400 @ 3.00GHz Number Of Processors: 2 Physical Memory: 4181744 KB (Available: 369184 KB) Commit Charge Limit: 4194303 KB *** Operation System *** Microsoft Windows Server 2003 Standard Edition Service Pack 2 (Version 5.2, Build 3790) //===================================================== Exception code: C0000005 ACCESS_VIOLATION Fault address: 005EB6E8 01:001EA6E8 C:\\MaNGOS\\mangosd.exe Registers: EAX:00050006 EBX:11900B88 ECX:EEFF0000 EDX:00050006 ESI:00000040 EDI:008003D0 CS:EIP:001B:005EB6E8 SS:ESP:0023:0D59965C EBP:0D5998CC DS:0023 ES:0023 FS:003B GS:0000 Flags:00010202 Call stack: Address Frame Function SourceFile 005EB6E8 00000000 ??0CreatureEventAI@@QAE@ABV0@@Z+25DF8 007A317D 00000000 ?HandleBattlemasterJoinOpcode@WorldSession@@QAEXAAVWorldPacket@@@Z+BBD 005B094F 00000000 ?Update@WorldSession@@QAE_NI@Z+18F 005CF74E 00000000 ??0CreatureEventAI@@QAE@ABV0@@Z+9E5E 005CBA45 00000000 ??0CreatureEventAI@@QAE@ABV0@@Z+6155 0042ECDE 00000000 ?getSource@?$Reference@V?$GridRefManager@VCorpse@@@@VCorpse@@@@QBEPAVCorpse@@XZ+178EE 008003E9 00000000 ?GetFloatDefault@Config@@QAEMPBDM@Z+DC9 00291B84 00000000 ?invoke@ACE_OS_Thread_Adapter@@UAEKXZ+74 78543433 00000000 _endthreadex+44 785434C7 00000000 _endthreadex+D8 77E6482F 00000000 GetModuleHandleA+DF Call stack: Address Frame Function SourceFile 7C82860C 00000000 KiFastSystemCallRet+0 7D1F5EDB 00000000 LookupPrivilegeValueW+114 7D1F5F82 00000000 LookupPrivilegeValueW+1BB 7D2477B7 00000000 StartServiceCtrlDispatcherA+93 007FFB7C 00000000 ?GetFloatDefault@Config@@QAEMPBDM@Z+55C 00429A1B 00000000 ?getSource@?$Reference@V?$GridRefManager@VCorpse@@@@VCorpse@@@@QBEPAVCorpse@@XZ+1262B 0042F42B 00000000 ?getSource@?$Reference@V?$GridRefManager@VCorpse@@@@VCorpse@@@@QBEPAVCorpse@@XZ+1803B 77E6F23B 00000000 ProcessIdToSessionId+209 Call stack: Address Frame Function SourceFile 7C82860C 00000000 KiFastSystemCallRet+0 77E61C8D 00000000 WaitForSingleObject+12 Call stack: Address Frame Function SourceFile 7C82860C 00000000 KiFastSystemCallRet+0 77E424FD 00000000 Sleep+F 00800610 00000000 ?GetFloatDefault@Config@@QAEMPBDM@Z+FF0 00806790 00000000 ?step@barGoLink@@QAEXXZ+1E30 008003E9 00000000 ?GetFloatDefault@Config@@QAEMPBDM@Z+DC9 00291B84 00000000 ?invoke@ACE_OS_Thread_Adapter@@UAEKXZ+74 78543433 00000000 _endthreadex+44 785434C7 00000000 _endthreadex+D8 77E6482F 00000000 GetModuleHandleA+DF Call stack: Address Frame Function SourceFile 7C82860C 00000000 KiFastSystemCallRet+0 77E424FD 00000000 Sleep+F 00800610 00000000 ?GetFloatDefault@Config@@QAEMPBDM@Z+FF0 00806790 00000000 ?step@barGoLink@@QAEXXZ+1E30 008003E9 00000000 ?GetFloatDefault@Config@@QAEMPBDM@Z+DC9 00291B84 00000000 ?invoke@ACE_OS_Thread_Adapter@@UAEKXZ+74 78543433 00000000 _endthreadex+44 785434C7 00000000 _endthreadex+D8 77E6482F 00000000 GetModuleHandleA+DF Call stack: Address Frame Function SourceFile 7C82860C 00000000 KiFastSystemCallRet+0 77E424FD 00000000 Sleep+F 00800610 00000000 ?GetFloatDefault@Config@@QAEMPBDM@Z+FF0 00806790 00000000 ?step@barGoLink@@QAEXXZ+1E30 008003E9 00000000 ?GetFloatDefault@Config@@QAEMPBDM@Z+DC9 00291B84 00000000 ?invoke@ACE_OS_Thread_Adapter@@UAEKXZ+74 78543433 00000000 _endthreadex+44 785434C7 00000000 _endthreadex+D8 77E6482F 00000000 GetModuleHandleA+DF Call stack: Address Frame Function SourceFile 7C82860C 00000000 KiFastSystemCallRet+0 0D5986B4 00000000 0000:00000000 FF50D845 FFFFFFFF 0000:00000000 0CC4880B 00000000 ?SetName@WorldObject@@QAEXABV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@Z+335B Call stack: Address Frame Function SourceFile 7C82860C 00000000 KiFastSystemCallRet+0 71B21A03 00000000 0001:00000A03 C:\\WINDOWS\\system32\\MSWSOCK.dll 71C0283C 00000000 select+A1 0083A959 00000000 ?at_exit@MaNGOS@@YAXP6AXXZ@Z+31F9 0083A216 00000000 ?at_exit@MaNGOS@@YAXP6AXXZ@Z+2AB6 0042A9AF 00000000 ?getSource@?$Reference@V?$GridRefManager@VCorpse@@@@VCorpse@@@@QBEPAVCorpse@@XZ+135BF 008003E9 00000000 ?GetFloatDefault@Config@@QAEMPBDM@Z+DC9 00291B84 00000000 ?invoke@ACE_OS_Thread_Adapter@@UAEKXZ+74 78543433 00000000 _endthreadex+44 785434C7 00000000 _endthreadex+D8 77E6482F 00000000 GetModuleHandleA+DF

True freghar, but that means running an extra application - I think many would prefer an all-in-one solution. There is something to be said for an external monitoring / logging program though, maybe something like the RA console but just for logs. People can then write their own applications to connect to the logging port and do with the logs what they want. Would be a bit more effort than the current posted solution. On that note: I have been testing the patch by lp-vamp on our life platform for the past three days, so far without a single crash. It seems definately stable, and I would suggest adding it to the trunk - more people can benefit from it, especially since it can also be turned off by default.

The question you have to ask yourself here is: in what situation will dropping sha_pass_hash be usefull? Someone with access to the sha_pass_hash will in almost all cases have direct (read) access to the database. This person will already be able to see just about everything and most likely also modify fields - after all, not many people create seperate read-only accounts for their applications, and there are even less cases when an application can suffice with read-only access. Even a webpage used for account signup will have an account capable of insert operations, and if that is the case, the user can already insert an admin account for himself. So the question becomes: what can we prevent by dropping sha_pass_hash? We can't prevent someone from logging in since he can easily insert an admin account for himself. Finding out a users password is still very unlikely - after all, rainbow tables generally only list common words, or random words up to 8 ~ 12 characters, the username: password concatanation is usually longer. Really the only thing it prevents is someone logging in as someone else after he got a copy of the realm database somehow without having access to the database, but with enough knowledge to modify a client. That is a very, very small risk. On the other hand, a dozen applications make use of the field - just about all of those will stop working. Not everyone has full control over their webserver either, so the additional PHP library might just be impossible to install for some people (our server for example has a seperate webserver for account related functions, to which I only have very restricted access). Additionally, there will have to come scripts / applications for both windows as well as linux to update those accounts without a v / s value - applications administrators will have to trust not to contain virii or malware. An all this is considering those applications work flawlessly - what if they contain a small bug that only occurs once every thousand accounts? And will there be well written examples for all used languages - in my case, this means JAVA - will someone write a good library for that? How about the Perl scripters out there? Or the C++ developers? If your security is so far compromised that the database contents can be read by someone with bad intend, you have already lost. Dropping sha_pass_hash will almost never stop that person from gaining even more access to your server. It is the tiniest fraction of security that will cause a load of trouble for application developers and server admins everywhere. So no, as both an admin as well as developer I say please, don't drop it

You'll pretty much have to use grid_unload, without it we're generally pushing 3Gb of RAM used More info can be found in this excelent thread on performance tweaks. Keep in mind that most VPS's don't actually give you 100% availability of the listed CPU's - so your performance might be lower than expected. As for multithreading patch: I meant this one. By default, mangos can only ever use 1 core at the time, so if you have 4 CPU cores this means 3 of'm will be doing nothing. The MTMaps patch fixes that to some extend.

My opinion would be that you have wasted your money on a quadcore that could have been better spend on extra RAM. Unless you use the multithreading patch your server will only be able to use 25% of the available CPU power, yet on the other hand, 2Gb ram is not enough to run a server without grid_unload. Good performance is a matter of finding bottlenecks and adequate resources for the task. I could use a supercomputer to run WoW yet get less performance than a netbook, or run a server with 16Gb RAM, a 4Ghz CPU and a PATA hard disk and it'd still take half a year to start. And even with all the hardware details there could still be a lot of other issues: older MySQL versions for example used to run terrible slow on a SUN Fire X series server. By far the best way to know how much your server can support is to simply use it and see. Mangos does quite well on normal hardware, anything under a 1000 users should run just fine on whatever regular machine you throw at it.

8719 - 0.12 backport. Revision: * * 8569 560bb633e125a3ab2ad226e6c01e5c1394ec821a Date 16:12:2009. Time 14:2 //===================================================== *** Hardware *** Processor: Intel(R) Core(TM)2 CPU E8400 @ 3.00GHz Number Of Processors: 2 Physical Memory: 4181744 KB (Available: 992188 KB) Commit Charge Limit: 4194303 KB *** Operation System *** Microsoft Windows Server 2003 Standard Edition Service Pack 2 (Version 5.2, Build 3790) //===================================================== Exception code: C00000FD STACK_OVERFLOW Fault address: 0042EE37 01:0002DE37 C:\\MaNGOS\\mangosd.exe Registers: EAX:0EAA2000 EBX:0BBCBE50 ECX:0EAA05CC EDX:0EAA866C ESI:00000000 EDI:00800140 CS:EIP:001B:0042EE37 SS:ESP:0023:0EAA8648 EBP:0EAA865C DS:0023 ES:0023 FS:003B GS:0000 Flags:00010206 Call stack: Address Frame Function SourceFile 0042EE37 00000000 ?getSource@?$Reference@V?$GridRefManager@VCorpse@@@@VCorpse@@@@QBEPAVCorpse@@XZ+17A47 00496F09 00000000 ?GetGrid@Map@@AAEPAVGridMap@@MM@Z+59 0049714F 00000000 ?GetAreaFlag@Map@@QBEGMMM@Z+1F 0043669F 00000000 ?GetZoneAndAreaId@WorldObject@@QBEXAAI0@Z+5F 006952DE 00000000 ?SendCastResult@Spell@@SAXPAVPlayer@@PBUSpellEntry@@EW4SpellCastResult@@@Z+31FE 0069029E 00000000 ?Update@?$ConfusedMovementGenerator@VPlayer@@@@QAE_NAAVPlayer@@ABI@Z+2708E 004565F5 00000000 ?CastSpell@Unit@@QAEXPAV1@PBUSpellEntry@@_NPAVItem@@PAVAura@@_K@Z+1B5 00456438 00000000 ?CastSpell@Unit@@QAEXPAV1@I_NPAVItem@@PAVAura@@_K@Z+118 004672B7 00000000 ?HandleProcTriggerSpell@Unit@@AAE_NPAV1@IPAVAura@@PBUSpellEntry@@IW4WeaponAttackType@@I@Z+1997 004740FF 00000000 ?ProcDamageAndSpellFor@Unit@@AAEX_NPAV1@IABV?$set@W4AuraType@@U?$less@W4AuraType@@@std@@V?$allocator@W4AuraType@@@3@@std@@W4WeaponAttackType@@PBUSpellEntry@@IW4SpellSchoolMask@@@Z+3AF 004626EB 00000000 ?ProcDamageAndSpell@Unit@@QAEXPAV1@IIIW4SpellSchoolMask@@PBUSpellEntry@@_NW4WeaponAttackType@@@Z+22B 00457CC3 00000000 ?SpellNonMeleeDamageLog@Unit@@QAEIPAV1@II_N1@Z+313 007AEB48 00000000 ?HandleRepairItemOpcode@WorldSession@@QAEXAAVWorldPacket@@@Z+22B8 0069467E 00000000 ?SendCastResult@Spell@@SAXPAVPlayer@@PBUSpellEntry@@EW4SpellCastResult@@@Z+259E 0068BA45 00000000 ?Update@?$ConfusedMovementGenerator@VPlayer@@@@QAE_NAAVPlayer@@ABI@Z+22835 0068B1F6 00000000 ?Update@?$ConfusedMovementGenerator@VPlayer@@@@QAE_NAAVPlayer@@ABI@Z+21FE6 00690E5B 00000000 ?Update@?$ConfusedMovementGenerator@VPlayer@@@@QAE_NAAVPlayer@@ABI@Z+27C4B 00690CD6 00000000 ?Update@?$ConfusedMovementGenerator@VPlayer@@@@QAE_NAAVPlayer@@ABI@Z+27AC6 0069039A 00000000 ?Update@?$ConfusedMovementGenerator@VPlayer@@@@QAE_NAAVPlayer@@ABI@Z+2718A 004565F5 00000000 ?CastSpell@Unit@@QAEXPAV1@PBUSpellEntry@@_NPAVItem@@PAVAura@@_K@Z+1B5 00456438 00000000 ?CastSpell@Unit@@QAEXPAV1@I_NPAVItem@@PAVAura@@_K@Z+118 004672B7 00000000 ?HandleProcTriggerSpell@Unit@@AAE_NPAV1@IPAVAura@@PBUSpellEntry@@IW4WeaponAttackType@@I@Z+1997 004740FF 00000000 ?ProcDamageAndSpellFor@Unit@@AAEX_NPAV1@IABV?$set@W4AuraType@@U?$less@W4AuraType@@@std@@V?$allocator@W4AuraType@@@3@@std@@W4WeaponAttackType@@PBUSpellEntry@@IW4SpellSchoolMask@@@Z+3AF 004626EB 00000000 ?ProcDamageAndSpell@Unit@@QAEXPAV1@IIIW4SpellSchoolMask@@PBUSpellEntry@@_NW4WeaponAttackType@@@Z+22B 00457CC3 00000000 ?SpellNonMeleeDamageLog@Unit@@QAEIPAV1@II_N1@Z+313 007AEB48 00000000 ?HandleRepairItemOpcode@WorldSession@@QAEXAAVWorldPacket@@@Z+22B8 0069467E 00000000 ?SendCastResult@Spell@@SAXPAVPlayer@@PBUSpellEntry@@EW4SpellCastResult@@@Z+259E 0068BA45 00000000 ?Update@?$ConfusedMovementGenerator@VPlayer@@@@QAE_NAAVPlayer@@ABI@Z+22835 0068B1F6 00000000 ?Update@?$ConfusedMovementGenerator@VPlayer@@@@QAE_NAAVPlayer@@ABI@Z+21FE6 00690E5B 00000000 ?Update@?$ConfusedMovementGenerator@VPlayer@@@@QAE_NAAVPlayer@@ABI@Z+27C4B 00690CD6 00000000 ?Update@?$ConfusedMovementGenerator@VPlayer@@@@QAE_NAAVPlayer@@ABI@Z+27AC6 0069039A 00000000 ?Update@?$ConfusedMovementGenerator@VPlayer@@@@QAE_NAAVPlayer@@ABI@Z+2718A 004565F5 00000000 ?CastSpell@Unit@@QAEXPAV1@PBUSpellEntry@@_NPAVItem@@PAVAura@@_K@Z+1B5 00456438 00000000 ?CastSpell@Unit@@QAEXPAV1@I_NPAVItem@@PAVAura@@_K@Z+118 004672B7 00000000 ?HandleProcTriggerSpell@Unit@@AAE_NPAV1@IPAVAura@@PBUSpellEntry@@IW4WeaponAttackType@@I@Z+1997 004740FF 00000000 ?ProcDamageAndSpellFor@Unit@@AAEX_NPAV1@IABV?$set@W4AuraType@@U?$less@W4AuraType@@@std@@V?$allocator@W4AuraType@@@3@@std@@W4WeaponAttackType@@PBUSpellEntry@@IW4SpellSchoolMask@@@Z+3AF 004626EB 00000000 ?ProcDamageAndSpell@Unit@@QAEXPAV1@IIIW4SpellSchoolMask@@PBUSpellEntry@@_NW4WeaponAttackType@@@Z+22B 00457CC3 00000000 ?SpellNonMeleeDamageLog@Unit@@QAEIPAV1@II_N1@Z+313 007AEB48 00000000 ?HandleRepairItemOpcode@WorldSession@@QAEXAAVWorldPacket@@@Z+22B8 0069467E 00000000 ?SendCastResult@Spell@@SAXPAVPlayer@@PBUSpellEntry@@EW4SpellCastResult@@@Z+259E 0068BA45 00000000 ?Update@?$ConfusedMovementGenerator@VPlayer@@@@QAE_NAAVPlayer@@ABI@Z+22835 0068B1F6 00000000 ?Update@?$ConfusedMovementGenerator@VPlayer@@@@QAE_NAAVPlayer@@ABI@Z+21FE6 00690E5B 00000000 ?Update@?$ConfusedMovementGenerator@VPlayer@@@@QAE_NAAVPlayer@@ABI@Z+27C4B 00690CD6 00000000 ?Update@?$ConfusedMovementGenerator@VPlayer@@@@QAE_NAAVPlayer@@ABI@Z+27AC6 0069039A 00000000 ?Update@?$ConfusedMovementGenerator@VPlayer@@@@QAE_NAAVPlayer@@ABI@Z+2718A 004565F5 00000000 ?CastSpell@Unit@@QAEXPAV1@PBUSpellEntry@@_NPAVItem@@PAVAura@@_K@Z+1B5 00456438 00000000 ?CastSpell@Unit@@QAEXPAV1@I_NPAVItem@@PAVAura@@_K@Z+118 004672B7 00000000 ?HandleProcTriggerSpell@Unit@@AAE_NPAV1@IPAVAura@@PBUSpellEntry@@IW4WeaponAttackType@@I@Z+1997 004740FF 00000000 ?ProcDamageAndSpellFor@Unit@@AAEX_NPAV1@IABV?$set@W4AuraType@@U?$less@W4AuraType@@@std@@V?$allocator@W4AuraType@@@3@@std@@W4WeaponAttackType@@PBUSpellEntry@@IW4SpellSchoolMask@@@Z+3AF 004626EB 00000000 ?ProcDamageAndSpell@Unit@@QAEXPAV1@IIIW4SpellSchoolMask@@PBUSpellEntry@@_NW4WeaponAttackType@@@Z+22B 00457CC3 00000000 ?SpellNonMeleeDamageLog@Unit@@QAEIPAV1@II_N1@Z+313 007AEB48 00000000 ?HandleRepairItemOpcode@WorldSession@@QAEXAAVWorldPacket@@@Z+22B8 0069467E 00000000 ?SendCastResult@Spell@@SAXPAVPlayer@@PBUSpellEntry@@EW4SpellCastResult@@@Z+259E 0068BA45 00000000 ?Update@?$ConfusedMovementGenerator@VPlayer@@@@QAE_NAAVPlayer@@ABI@Z+22835 0068B1F6 00000000 ?Update@?$ConfusedMovementGenerator@VPlayer@@@@QAE_NAAVPlayer@@ABI@Z+21FE6 00690E5B 00000000 ?Update@?$ConfusedMovementGenerator@VPlayer@@@@QAE_NAAVPlayer@@ABI@Z+27C4B 00690CD6 00000000 ?Update@?$ConfusedMovementGenerator@VPlayer@@@@QAE_NAAVPlayer@@ABI@Z+27AC6 0069039A 00000000 ?Update@?$ConfusedMovementGenerator@VPlayer@@@@QAE_NAAVPlayer@@ABI@Z+2718A 004565F5 00000000 ?CastSpell@Unit@@QAEXPAV1@PBUSpellEntry@@_NPAVItem@@PAVAura@@_K@Z+1B5 00456438 00000000 ?CastSpell@Unit@@QAEXPAV1@I_NPAVItem@@PAVAura@@_K@Z+118 004672B7 00000000 ?HandleProcTriggerSpell@Unit@@AAE_NPAV1@IPAVAura@@PBUSpellEntry@@IW4WeaponAttackType@@I@Z+1997 004740FF 00000000 ?ProcDamageAndSpellFor@Unit@@AAEX_NPAV1@IABV?$set@W4AuraType@@U?$less@W4AuraType@@@std@@V?$allocator@W4AuraType@@@3@@std@@W4WeaponAttackType@@PBUSpellEntry@@IW4SpellSchoolMask@@@Z+3AF 004626EB 00000000 ?ProcDamageAndSpell@Unit@@QAEXPAV1@IIIW4SpellSchoolMask@@PBUSpellEntry@@_NW4WeaponAttackType@@@Z+22B 00457CC3 00000000 ?SpellNonMeleeDamageLog@Unit@@QAEIPAV1@II_N1@Z+313 007AEB48 00000000 ?HandleRepairItemOpcode@WorldSession@@QAEXAAVWorldPacket@@@Z+22B8 0069467E 00000000 ?SendCastResult@Spell@@SAXPAVPlayer@@PBUSpellEntry@@EW4SpellCastResult@@@Z+259E 0068BA45 00000000 ?Update@?$ConfusedMovementGenerator@VPlayer@@@@QAE_NAAVPlayer@@ABI@Z+22835 0068B1F6 00000000 ?Update@?$ConfusedMovementGenerator@VPlayer@@@@QAE_NAAVPlayer@@ABI@Z+21FE6 00690E5B 00000000 ?Update@?$ConfusedMovementGenerator@VPlayer@@@@QAE_NAAVPlayer@@ABI@Z+27C4B 00690CD6 00000000 ?Update@?$ConfusedMovementGenerator@VPlayer@@@@QAE_NAAVPlayer@@ABI@Z+27AC6 0069039A 00000000 ?Update@?$ConfusedMovementGenerator@VPlayer@@@@QAE_NAAVPlayer@@ABI@Z+2718A 004565F5 00000000 ?CastSpell@Unit@@QAEXPAV1@PBUSpellEntry@@_NPAVItem@@PAVAura@@_K@Z+1B5 00456438 00000000 ?CastSpell@Unit@@QAEXPAV1@I_NPAVItem@@PAVAura@@_K@Z+118 004672B7 00000000 ?HandleProcTriggerSpell@Unit@@AAE_NPAV1@IPAVAura@@PBUSpellEntry@@IW4WeaponAttackType@@I@Z+1997 004740FF 00000000 ?ProcDamageAndSpellFor@Unit@@AAEX_NPAV1@IABV?$set@W4AuraType@@U?$less@W4AuraType@@@std@@V?$allocator@W4AuraType@@@3@@std@@W4WeaponAttackType@@PBUSpellEntry@@IW4SpellSchoolMask@@@Z+3AF 004626EB 00000000 ?ProcDamageAndSpell@Unit@@QAEXPAV1@IIIW4SpellSchoolMask@@PBUSpellEntry@@_NW4WeaponAttackType@@@Z+22B 00457CC3 00000000 ?SpellNonMeleeDamageLog@Unit@@QAEIPAV1@II_N1@Z+313 007AEB48 00000000 ?HandleRepairItemOpcode@WorldSession@@QAEXAAVWorldPacket@@@Z+22B8 0069467E 00000000 ?SendCastResult@Spell@@SAXPAVPlayer@@PBUSpellEntry@@EW4SpellCastResult@@@Z+259E 0068BA45 00000000 ?Update@?$ConfusedMovementGenerator@VPlayer@@@@QAE_NAAVPlayer@@ABI@Z+22835 0068B1F6 00000000 ?Update@?$ConfusedMovementGenerator@VPlayer@@@@QAE_NAAVPlayer@@ABI@Z+21FE6 00690FB5 00000000 ?Update@?$ConfusedMovementGenerator@VPlayer@@@@QAE_NAAVPlayer@@ABI@Z+27DA5 0069BB0B 00000000 ?SendCastResult@Spell@@SAXPAVPlayer@@PBUSpellEntry@@EW4SpellCastResult@@@Z+9A2B 008376DC 00000000 ?at_exit@MaNGOS@@YAXP6AXXZ@Z+20C 004538F8 00000000 ?Update@Unit@@UAEXI@Z+28 00625BB1 00000000 ?Update@Creature@@UAEXI@Z+5E1 004AE01F 00000000 ?next@?$GridReference@V?$NGrid@$0BA@VPlayer@@U?$TypeList@VPlayer@@U?$TypeList@VCreature@@U?$TypeList@VCorpse@@VTypeNull@@@@@@@@U?$TypeList@VGameObject@@U?$TypeList@VCreature@@U?$TypeList@VDynamicObject@@U?$TypeList@VCorpse@@VTypeNull@@@@@@@@@@V?$SingleThreaded@VPlayer@@@MaNGOS@@@@@@QAEPAV1@XZ+1037F 004ADFA2 00000000 ?next@?$GridReference@V?$NGrid@$0BA@VPlayer@@U?$TypeList@VPlayer@@U?$TypeList@VCreature@@U?$TypeList@VCorpse@@VTypeNull@@@@@@@@U?$TypeList@VGameObject@@U?$TypeList@VCreature@@U?$TypeList@VDynamicObject@@U?$TypeList@VCorpse@@VTypeNull@@@@@@@@@@V?$SingleThreaded@VPlayer@@@MaNGOS@@@@@@QAEPAV1@XZ+10302 004AD730 00000000 ?next@?$GridReference@V?$NGrid@$0BA@VPlayer@@U?$TypeList@VPlayer@@U?$TypeList@VCreature@@U?$TypeList@VCorpse@@VTypeNull@@@@@@@@U?$TypeList@VGameObject@@U?$TypeList@VCreature@@U?$TypeList@VDynamicObject@@U?$TypeList@VCorpse@@VTypeNull@@@@@@@@@@V?$SingleThreaded@VPlayer@@@MaNGOS@@@@@@QAEPAV1@XZ+FA90 004AD243 00000000 ?next@?$GridReference@V?$NGrid@$0BA@VPlayer@@U?$TypeList@VPlayer@@U?$TypeList@VCreature@@U?$TypeList@VCorpse@@VTypeNull@@@@@@@@U?$TypeList@VGameObject@@U?$TypeList@VCreature@@U?$TypeList@VDynamicObject@@U?$TypeList@VCorpse@@VTypeNull@@@@@@@@@@V?$SingleThreaded@VPlayer@@@MaNGOS@@@@@@QAEPAV1@XZ+F5A3 004ACCD0 00000000 ?next@?$GridReference@V?$NGrid@$0BA@VPlayer@@U?$TypeList@VPlayer@@U?$TypeList@VCreature@@U?$TypeList@VCorpse@@VTypeNull@@@@@@@@U?$TypeList@VGameObject@@U?$TypeList@VCreature@@U?$TypeList@VDynamicObject@@U?$TypeList@VCorpse@@VTypeNull@@@@@@@@@@V?$SingleThreaded@VPlayer@@@MaNGOS@@@@@@QAEPAV1@XZ+F030 004A93AF 00000000 ?next@?$GridReference@V?$NGrid@$0BA@VPlayer@@U?$TypeList@VPlayer@@U?$TypeList@VCreature@@U?$TypeList@VCorpse@@VTypeNull@@@@@@@@U?$TypeList@VGameObject@@U?$TypeList@VCreature@@U?$TypeList@VDynamicObject@@U?$TypeList@VCorpse@@VTypeNull@@@@@@@@@@V?$SingleThreaded@VPlayer@@@MaNGOS@@@@@@QAEPAV1@XZ+B70F 004A3C76 00000000 ?next@?$GridReference@V?$NGrid@$0BA@VPlayer@@U?$TypeList@VPlayer@@U?$TypeList@VCreature@@U?$TypeList@VCorpse@@VTypeNull@@@@@@@@U?$TypeList@VGameObject@@U?$TypeList@VCreature@@U?$TypeList@VDynamicObject@@U?$TypeList@VCorpse@@VTypeNull@@@@@@@@@@V?$SingleThreaded@VPlayer@@@MaNGOS@@@@@@QAEPAV1@XZ+5FD6 0049452D 00000000 ?Update@Map@@UAEXABI@Z+35D 005E5B58 00000000 ??0CreatureEventAI@@QAE@ABV0@@Z+20288 005CBE3B 00000000 ??0CreatureEventAI@@QAE@ABV0@@Z+656B 0042ECBE 00000000 ?getSource@?$Reference@V?$GridRefManager@VCorpse@@@@VCorpse@@@@QBEPAVCorpse@@XZ+178CE 00800159 00000000 ?GetFloatDefault@Config@@QAEMPBDM@Z+DC9 00A01B84 00000000 ?invoke@ACE_OS_Thread_Adapter@@UAEKXZ+74 78543433 00000000 _endthreadex+44 785434C7 00000000 _endthreadex+D8 77E6482F 00000000 GetModuleHandleA+DF

Wow, awesome work lp-vamp! I've just applied and compiled your patch and it seems to be working flawlessly! Had to apply parts of it manually to make it work with 0.12 branch (revision 8719), patch for that: From 8704557095df5f389144774447a1611bf82a00c8 Mon Sep 17 00:00:00 2001 From: unknown <[email protected]> Date: Tue, 15 Dec 2009 02:33:36 +0100 Subject: [PATCH] Limit log filesize --- src/mangosd/mangosd.conf.dist.in | 8 ++++++- src/shared/Log.cpp | 42 ++++++++++++++++++++++++++++++++++++++ src/shared/Log.h | 7 ++++++ 3 files changed, 56 insertions(+), 1 deletions(-) diff --git a/src/mangosd/mangosd.conf.dist.in b/src/mangosd/mangosd.conf.dist.in index 522bc16..ffc1232 100644 --- a/src/mangosd/mangosd.conf.dist.in +++ b/src/mangosd/mangosd.conf.dist.in @@ -1,4 +1,4 @@ -##################################### +##################################### # MaNGOS Configuration file # ##################################### ConfVersion=2008080101 @@ -223,6 +223,11 @@ AddonChannel = 1 # 0 = Minimum; 1 = Error; 2 = Detail; 3 = Full/Debug # Default: 0 # +# LogFileSize +# Server logging file size +# 0 = disabled +# Default: 0 +# # LogFilter_TransportMoves # LogFilter_CreatureMoves # LogFilter_VisibilityChanges @@ -292,6 +297,7 @@ LogTime = 0 LogFile = "Server.log" LogTimestamp = 0 LogFileLevel = 0 +LogFileSize = 0 LogFilter_TransportMoves = 1 LogFilter_CreatureMoves = 1 LogFilter_VisibilityChanges = 1 diff --git a/src/shared/Log.cpp b/src/shared/Log.cpp index 72544d4..8a983ca 100644 --- a/src/shared/Log.cpp +++ b/src/shared/Log.cpp @@ -246,6 +246,10 @@ void Log::Initialize() // Char log settings m_charLog_Dump = sConfig.GetBoolDefault("CharLogDump", false); + + // Log File size + m_count_lines = 0; + m_file_size_limit = sConfig.GetIntDefault("LogFileSize", 0); } FILE* Log::openLogFile(char const* configFileName,char const* configTimeStampFlag, char const* mode) @@ -262,6 +266,10 @@ FILE* Log::openLogFile(char const* configFileName,char const* configTimeStampFla else logfn += m_logsTimestamp; } + if(strcmp(configFileName,"LogFile") == 0 && log_filename.empty()) + { + log_filename=log_filename.append(m_logsDir+logfn); + } return fopen((m_logsDir+logfn).c_str(), mode); } @@ -337,6 +345,7 @@ void Log::outTitle( const char * str) fprintf(logfile, str); fprintf(logfile, "\\n" ); fflush(logfile); + swapLogFile(); } fflush(stdout); @@ -352,6 +361,7 @@ void Log::outString() outTimestamp(logfile); fprintf(logfile, "\\n" ); fflush(logfile); + swapLogFile(); } fflush(stdout); } @@ -387,6 +397,7 @@ void Log::outString( const char * str, ... ) va_end(ap); fflush(logfile); + swapLogFile(); } fflush(stdout); } @@ -423,6 +434,7 @@ void Log::outError( const char * err, ... ) fprintf(logfile, "\\n" ); fflush(logfile); + swapLogFile(); } fflush(stderr); } @@ -460,6 +472,7 @@ void Log::outErrorDb( const char * err, ... ) fprintf(logfile, "\\n" ); fflush(logfile); + swapLogFile(); } if(dberLogfile) @@ -510,6 +523,7 @@ void Log::outBasic( const char * str, ... ) fprintf(logfile, "\\n" ); va_end(ap); fflush(logfile); + swapLogFile(); } fflush(stdout); } @@ -549,6 +563,7 @@ void Log::outDetail( const char * str, ... ) fprintf(logfile, "\\n" ); fflush(logfile); + swapLogFile(); } fflush(stdout); @@ -613,6 +628,7 @@ void Log::outDebug( const char * str, ... ) fprintf(logfile, "\\n" ); fflush(logfile); + swapLogFile(); } fflush(stdout); } @@ -649,6 +665,7 @@ void Log::outCommand( uint32 account, const char * str, ... ) fprintf(logfile, "\\n" ); va_end(ap); fflush(logfile); + swapLogFile(); } if (m_gmlog_per_account) @@ -733,6 +750,7 @@ void Log::outMenu( const char * str, ... ) fprintf(logfile, "\\n" ); fflush(logfile); + swapLogFile(); } fflush(stdout); } @@ -754,6 +772,30 @@ void Log::outRALog( const char * str, ... ) fflush(stdout); } +void Log::swapLogFile() +{ + if (logfile && m_file_size_limit>0) // there is a logfile and a size limit + { + if(m_count_lines >= m_file_size_limit) + { + m_count_lines=0; + if(log_size_limit_filename.empty()) // generate backup file name if empty + { + size_t dot_pos = log_filename.find_last_of("."); + log_size_limit_filename.append(log_filename); + log_size_limit_filename.insert(dot_pos,"_part"); + } + // close the logfile, remove, rename, open new logfile .. TODO Error Handling + fclose(logfile); + remove(log_size_limit_filename.c_str()); + rename(log_filename.c_str(),log_size_limit_filename.c_str()); + logfile=fopen(log_filename.c_str(), "w"); + } + else {m_count_lines++;} + } +} + + void outstring_log(const char * str, ...) { if( !str ) diff --git a/src/shared/Log.h b/src/shared/Log.h index 27be84f..f62579e 100644 --- a/src/shared/Log.h +++ b/src/shared/Log.h @@ -146,6 +146,13 @@ class Log : public MaNGOS::Singleton<Log, MaNGOS::ClassLevelLockable<Log, ACE_Th // gm log control bool m_gmlog_per_account; std::string m_gmlog_filename_format; + + // log file size limit + uint32 m_file_size_limit; // limit size <= 0 deaktivate + uint32 m_count_lines; // count the lines in the log file + std::string log_filename; + std::string log_size_limit_filename; + void swapLogFile(); }; #define sLog MaNGOS::Singleton<Log>::Instance() -- 1.6.1.9.g97c34 Maybe not the most elegant solution possible, but it does exactly what I want it to do - might need a bit more testing, but I don't see why this should not get added to official repository! :lol: