FragFrog

February 7, 2010

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.

February 4, 2010

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

January 30, 2010

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.

January 29, 2010

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.

January 28, 2010

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.

January 26, 2010

uhm... no o_O
just take my above query and remove the mail_id from the select:

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

January 26, 2010

Update

Added a whole lot of features and bugfixes since the last post here, see startpost for updated info

Work under *NIX?

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.

January 26, 2010

sub-selects are pretty bad for the performance

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

January 26, 2010

Basically if I do a normal left join I'd get something like
Mail - ID: 1 - Mail Item 1
            - Mail Item 2
            - Mail Item 3
Mail - ID: 2 - Mail Item 4
            - Mail Item 5
            - Mail Item 6
However I wonder how I could loop over the mail items then, adding them to the mail template ain't a problem.

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.

January 25, 2010

About nix vs win. There is some trouble with memory usage in windows. So, eg win2k3 64bit noway use process more than 3Gb at once (in this case OS would be try to limit memory for 'leak' process and dump it to HDD). In sum it could be much more. (as far as I know enterprise support about 32Gb). But at all - it's sad.

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.

January 25, 2010

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.

January 20, 2010

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?

January 20, 2010

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.

January 14, 2010

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);
--

January 14, 2010

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

January 8, 2010

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.

January 7, 2010

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

January 6, 2010

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.

January 3, 2010

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

December 26, 2009

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.

December 22, 2009

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

December 17, 2009

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.

December 17, 2009

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.

December 16, 2009

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

December 15, 2009

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:

Sign In

Profiles

Bug Tracker

Wiki

Release Notes

Forums

Downloads

Blogs

Events

Posts posted by FragFrog

Contact Us

Repositories

Important Information