oc_redfox

Is is really <that> much easier...? And more colums > more DB usage (not much but still more)... Personaly i think its easy enough to select from the data-blob, if you keep track of the order... To simplify the DB to much will only alienate people who join to learn...

I think what he meant was that if this patch is applied everyone would have to re-write their web front ends / etc... Personaly i dont care, i just dont see how this would 'improve' anything, nor does it 'destroy' so could go either way...

Pretty good, but you forgot 2 of the biggest memory hogs.. Map 1 and Map 0

Then what flag would it be to enable a command for Gm1 + Gm4 + Gm7 (not any other gmlevel than those)

But let's say you have a gmlevel 4 or gmlevel 5 how would the securityflag look then? The ability to create / manage as many diffrent gmlevels you like would be nice... Maybe adding a line in the conf with the amount of gmlevels present so that mangos knows how to read securityflag from DB.. if you have 3 gmlevels (+standard 0 for non-gm) it would be securityflag=0111 but if you change in the config to allow up to 5gmlevels it would be securityflag=011111 (2 extra to read) There probably is better solutions to create new gmlevels and customize commands on them, so any feedback / ideas is welcome :-)

Both yes and no, woulden't having 'bitmasks' limit the GM-levels to a static amount? Lets say the standard is GM1 GM2 GM3.. If you use Bitmasks and only have those 3 it would be fine, but lets say you add up to GM8 or even higher... With diffrent "commands" assigned to them...

This has been vaugly suggested before, but wasent given much attention so i tought about opening a topic for it... The idea would be to change the way GM-levels work at the moment and make them more customizable... Right now you cannot set so a command is usable by GM 1+3 without GM2 also having it (if you see the dilema), so why not change so the commands are set by flags? and/or make it possible to add infinite (or atleast alot more) Gm levels with the desired commands to each of them... I am sorry if my description of the suggestion is off, will edit / change the post later to make more sense...

This has gone alittle off-topic, but what the hell its still all related ^^ I just tought it was weird that the server would use just as much memory with 100~testers as with 30~.. And yes, the client "load"-issue is also common ^^

Hex should have a CHANCE to break on damage, with this patch its not "chance to break".. But still better than not breaking... Thanks...

SSD drive ?

Major problem with Grid unloading? seems familiar ^^...

Is there a Valgrind version for win64* ^^?

The 'leaks' seems to come from arena/battleground.. Not sure tho, will need to do some more tests =/... Very annoying to have mangos use upp 99% memory no matter how many testers...

So could someone post their memory usage <vs> testers... 35 testers -> 1.2GB~ (seems 'kinda' normal) 160 testers -> 1.9GB~ back down to 50 testers -> 2.0GB~ GrindUnload = 1 Vmaps = Off (except instances) Any other variables to tweak with that affect memory usage? Like the unload times for grid / instances?

Looks like the Grids are not unloaded even though i have GridUnload = 1 in the config =/ ::Edit:: The server uses up 99% of the memory, but it dosent seem to 'crash' from lack of memory... How does nre Grids load if there is no memory to load them to?...

Am i the only one with this problem !?

nop, grindunload = 1 Vmaps is only on in instances...

Using revision; [7694] Anyhow, with around 250~testers i've got around 2Gb memory used, so i was surprised that the memory usage was still 2Gb when the amount of testers had droped to 35~.. So i would really like some pointers on how to track down memory leaks like this (using Windows Server 2008)..

Link is expired

is this discountinued !?

@Trazom Err... The 49708d thing is related to the DB table 'instance_reset' (just clean it and that goes away), But the problem im talking about is; Lets say you do a instance that should have 7 days reset, you get bound and everything looks normal.. You then do a instance with 1-day reset.. BOTH those instances will unbind after 1day then... And i have tried with both 0 and 7 in the reset_delay field...

Semi-Confirmed... Happens sometimes and sometimes it works ::Edit:: Maybe it happens when server unbinds the 1-day instances? Seems like it then unbinds all instances, even those with longer reset time...

Probably the same 'crash' as the above but still... Revision: 2009-04-08 17:07:03 7636 a7bf7d4bf99c42b63a64152219df9cd291329c3d Date 9:4:2009. Time 8:39 //===================================================== Exception code: C0000005 ACCESS_VIOLATION Fault address: 00466330 01:00065330 D:\\MANGOS\\MANGOSD.EXE Registers: EAX:00000000 EBX:10DF9FA8 ECX:15838060 EDX:00000000 ESI:00000000 EDI:00000000 CS:EIP:0023:00466330 SS:ESP:002B:0409F798 EBP:0409F7C0 DS:002B ES:002B FS:0053 GS:002B Flags:00010202 Call stack: Address Frame Function SourceFile 00466330 00000000 Unit::InterruptNonMeleeSpells+170 0047B020 00000000 Unit::setDeathState+50 004C7C8D 00000000 Player::setDeathState+FD 004D3D50 00000000 Player::KillPlayer+40 006080BF 00000000 WorldSession::LogoutPlayer+35F 00607D30 00000000 WorldSession::Update+380 00633834 00000000 World::UpdateSessions+154 0062F965 00000000 World::Update+365 00438B1E 00000000 WorldRunnable::run+8E 008EC6F5 00000000 ZThread::ThreadImpl::Dispatch+1D5 008ECB53 00000000 ZThread::`anonymous namespace'::Launcher::run+33 008F0C07 00000000 ZThread::ThreadOps::_dispatch+17 750A3433 00000000 _endthreadex+44 750A34C7 00000000 _endthreadex+D8 75FBE3F3 00000000 BaseThreadInitThunk+E 77B8CFED 00000000 RtlCreateUserProcess+8C 77B8D1FF 00000000 RtlCreateProcessParameters+4E ======================== Local Variables And Parameters Call stack: Address Frame Function SourceFile 00466330 00000000 Unit::InterruptNonMeleeSpells+170 Local <user defined> 'this' punting on symbol withDelayed punting on symbol spell_id 0047B020 00000000 Unit::setDeathState+50 Local <user defined> 'this' Local <user defined> 's' 004C7C8D 00000000 Player::setDeathState+FD Local <user defined> 'this' Local <user defined> 's' punting on symbol cur punting on symbol ressSpellId 004D3D50 00000000 Player::KillPlayer+40 Local <user defined> 'this' 006080BF 00000000 WorldSession::LogoutPlayer+35F Local <user defined> 'itr' Local <user defined> 'aset' Local <user defined> 'data' Local <user defined> 'guild' Local <user defined> 'this' punting on symbol Save 00607D30 00000000 WorldSession::Update+380 Local <user defined> 'this' punting on symbol __formal punting on symbol currTime 00633834 00000000 World::UpdateSessions+154 Local <user defined> 'next' Local <user defined> 'itr' Local <user defined> 'this' punting on symbol diff 0062F965 00000000 World::Update+365 punting on symbol i Local <user defined> 'this' punting on symbol diff 00438B1E 00000000 WorldRunnable::run+8E punting on symbol diff Local <user defined> 'this' punting on symbol realCurrTime punting on symbol realPrevTime punting on symbol prevSleepTime 008EC6F5 00000000 ZThread::ThreadImpl::Dispatch+1D5 Local <user defined> 'g' Local <user defined> 'i' Local <user defined> 'parent' Local <user defined> 'impl' Local <user defined> 'task' 008ECB53 00000000 ZThread::`anonymous namespace'::Launcher::run+33 Local <user defined> 'this' 008F0C07 00000000 ZThread::ThreadOps::_dispatch+17 punting on symbol arg Local <user defined> 'task' 750A3433 00000000 _endthreadex+44 750A34C7 00000000 _endthreadex+D8 75FBE3F3 00000000 BaseThreadInitThunk+E 77B8CFED 00000000 RtlCreateUserProcess+8C 77B8D1FF 00000000 RtlCreateProcessParameters+4E ======================== Global Variables

Tested it but reverted, causes to many crashes...

Any news on this?