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