oc_redfox

One from main reasons (in final state): this will illiminate need to create character `data` convertion at client switches. Instead normal fields add/deleted will be used.

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

You want a list of mapid's for only bgs with almost all instanced areas? try this dude

vmap.ignoremapids = "530,571,169,37,369,451,13,30"

this is pure performance!!!

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)

it would be nice to set the security settings by flags.

so instead of saying gmlevel=3 for a command you say then securityflag=0111 to give it to the first 3 gmlevels and e.g. securityflag=0100 to give it ONLY to gmlevel3.

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

He's runnin' on Windows, it's called paging file there.

Yeah that's why you've got your servers running despite the fact that physical memory is full. System is forced to use virtual memory, which is damn slow (HDD << RAM at speeds), and CPU-cycles-consuming.

SSD drive ?

There were already commits fixing problems from your previous logs. I think about 2 crashes and memory leaks, don't remember exactly. They also helped confirm another major problem with grid unloading though the fix for that is yet to be written.

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?