leak

More windows compile errors:

2>..\\..\\src\\game\\World.cpp(1461) : error C3001: 'task' : expected an OpenMP directive name
2>..\\..\\src\\game\\World.cpp(1518) : error C3001: 'task' : expected an OpenMP directive name
2>..\\..\\src\\game\\World.cpp(1550) : error C3001: 'task' : expected an OpenMP directive name

On mangos 8110 0.12 VC90 that is.

Could you test what happens if vmaps are enabled in instances only?

vmap.ignoreMapIds = "369, 0, 1, 530"

Why is that 2700 so hard to believe and why does a multithreading maps patch _suddenly_ balance load over all cores while the very same patch never did before? Question over questions..

Ah yea before i forget. How about vmaps? A server without vmaps at least in instances -> fail.

Added v3 of the core patch in the 1st post. (Fixed some mem leak [yea haha i know] and a typo)

You wouldn't save that much traffic by setting compression level to '9'. Use '1', mangos will definitely find use for free CPU resources

Unfortunately it doesn't, it just starts increasing ingame lag at some point..

Mind enabling your forum pm stuff so we can get a little deeper into this?

Is there any particular reason why VS files (*.vcproj) are formatted with unix style (LF) lineendings?

Everytime you make a small change to the project and save it so those files are overwritten they are converted to CRLF by VS.

If you try to checkin those changes into your repository git recognizses all those changed line endings and commits the whole file rather than just the small changes.

Ofc there is the autocrlf setting which can be set to "input" but this doesn't change the fact that VS is saving its project files with CRLF (If there is a way to change this feel free to tell).

So question is, would it hurt to have those VS related files with CRLF in the mangos repos?

What are your timings at loading?

16:14:22 Loading Guilds...
16:14:44 >> Loaded 832 guild definitions

16:14:44 Loading ArenaTeams...
16:14:46 >> Loaded 3899 arenateam definitions

Don't have any problems with arena team loading so far.

@freghar

Good to know my weirdness detector worked

I'm usually not a shell hater but GitExtensions really made me stop using git by shell.

Also works fine under winxp x64 now.

http://code.google.com/p/gitextensions/

Gonna take a peek at tgit again.

Possible, that leaves the two statement problem.

I had that before but it suffers from two major problems:

[HIGHLIGHT=SQL]

@count := 1;

UPDATE tabelle

SET nummer = @count := @count + 1

WHERE type = "foo"

ORDER BY nummer;

[/HIGHLIGHT]

It can't deal with duplicate key entries, so it just breaks there and it is also a two statement query (initializing the variable) and i don't think mangos can deal with that.

**edit

v2: http://pastebin.com/f8c42714

This should keep code compatibly with postgres.

What bug does the patch fix? What features does the patch add?

It improves Guild::RenumBankLogs() and Guild::RenumGuildEventlog() which are used during guild loading at startup. The currently used SQL doesn't renumber the LogGuids in guild_eventlog and guild_bank_eventlog tables properly. The patch fixes that.

The SQL part adds a missing index (by adding primary keys) to guild_eventlog which will speed up guild loading on big databases heavily.

(Got the guild loading part of mine with 50k log entries and 850 guilds from 102secs down to ~23sec)

For which repository revision was the patch created?

8088 0.12 branch

I think this can be "upported" to master branch too.

Is there a thread in the bug report section or at lighthouse? If yes, please add a link to the thread.

Nope

Who has been writing this patch? Please include either forum user names or email addresses.

That would be me.

For some reason the code highlighter fucks up []...

v4: http://pastebin.com/f6e656ff9

SQL part:

[HIGHLIGHT=SQL]

-- Applying the primary keys

ALTER TABLE `guild_eventlog`

ADD PRIMARY KEY (`guildid`, `LogGuid`);

-- Drop useless index

ALTER TABLE `guild_bank_eventlog`

DROP INDEX `guildid_key`;

[/HIGHLIGHT]

Applying primary keys to that table might not be that simple. I had the problem of duplicated primary keys on live data from my server, so i created a workaround.

If mangos devs decide to use this stuff you might also want to provide the following code in a sql rollup patch.

It cleans up the table with the same SQL statement used in the patch above and applies the primary key afterwards. This is only required as rollup, on a fresh database use the sql above.

[HIGHLIGHT=SQL]USE characters;

-- Add temporary index to guild_eventlog to speed up the following renumbering

ALTER TABLE `guild_eventlog`

ADD INDEX `guildid_key` (`guildid`);

-- Renumbering LogGuid of guild_eventlog manually in preperation of apply the primary key

DELIMITER $$

DROP PROCEDURE IF EXISTS `guild_eventlog_cleanup`$$

CREATE PROCEDURE `guild_eventlog_cleanup`()

BEGIN

DECLARE no_more_rows BOOLEAN;

DECLARE var INT(11) UNSIGNED;

DECLARE cur CURSOR FOR SELECT guildid FROM guild;

DECLARE CONTINUE HANDLER FOR NOT FOUND SET no_more_rows = TRUE;

OPEN cur;

loop_cur_res: LOOP

FETCH cur INTO var;

IF no_more_rows THEN

CLOSE cur;

LEAVE loop_cur_res;

END IF;

UPDATE guild_eventlog AS target INNER JOIN (SELECT guildid, logguid, (SELECT @COUNT := -1) FROM guild_eventlog WHERE guildid = var ORDER BY logguid ASC)

AS source ON source.logguid = target.logguid AND source.guildid = target.guildid SET target.logguid = (@COUNT := @COUNT + 1);

END LOOP loop_cur_res;

END$$

DELIMITER ;

CALL guild_eventlog_cleanup;

DROP PROCEDURE guild_eventlog_cleanup;

-- Applying the primary keys

ALTER TABLE `guild_eventlog`

ADD PRIMARY KEY (`guildid`, `LogGuid`);

-- Dropping the temporary index (uneeded since the primary key indices do the trick now)

ALTER TABLE `guild_eventlog`

DROP INDEX `guildid_key`;

-- Same issue for guild_bank_eventlog

ALTER TABLE `guild_bank_eventlog`

DROP INDEX `guildid_key`;[/HIGHLIGHT]

Thanks for reading.

mmmmm congratulations! hope it would be ported to -0.12

Indeed, don't forget us.

@waza123

No offense, but do you sometimes read what others keep telling?

Arthus asked for the server.log output that came together with the GetInstance() crash.

Also like i told you before and dereka did again: Posting FreezeDetectorRunnable::run crashes makes absolutly no sense without the rest of the crash dump.

That's not meant to be smartass like, just observations..

What now..?

How come not a single one of your 4 posts makes any sense to me?

Can this fix be backported to 0.12 branch?

10characters

Does this patch also affect the human skill perception? (since it is for 0.12)

Can this fix be backported to 0.12 branch?

Currently I use 7969 rev with no conflicts. Will update it to 7986 a bit later today.

You are talking about 3.x branch here, right?

Tried merging it with 0.12 branch but there are quite alot of conflicts. Solved the most but there are still quite a few left that need a little deeper insight.

Can someone provide a 0.12 version?

I think that with 1500 characters online, definitely is without LoS

Or partial LoS and at least 250ms spell lag. But ofc i'm up for testing too. It's been bugging me for ages that the mainthread is hanging around 80% and ingame lags get bigger and bigger, so anything to fix this...

Could someone backport it please?

Can someone backport that patch to mangos 0.12?

EffectMomentMove function looks quite different there and differentiation between creature and player teleport isn't there on the 3.x master branch anymore.

There you go

vmap.ignoreMapIds = "369, 0, 1, 530"

Leaves vmaps enabled in instanced areas only. If you wanna disable it in more instances you need to add all their map IDs.

I assume this patch doesn't work with the mtmaps patches flying around here?