raczman

What the hell. Zor: I asked you on IRC to NOT include it in your copycat "project", and you said "ok". Being a relatively calm man ill just wont comment on that, but next time remember that patch author has right to say where the patch goes - and i wanted it to be mangos/tc exclusive, since i ONLY want to support those projects that are GPL compliant. And if youre gonna tell me that it's GPL - your "project" broke GPL, files from wyk3d's prepared statement patch have YOUR copyrights - wheres mangos' credit? Hell, every file is marked as if you were original author. every commit from mangos is taken 1:1 and commited without including name of original author, giving false sense of you doing all the work. Keeping a thanks file is not enough. As for #pragma omp task - i added them in TC version for people who might happen to have omp3.0 compliant compiler, but on earlier versions they wont work as supposed - function will block waiting for the task block to finish, it doesnt matter if it is nowait claused. So basically it's useless as of now, we need to wait for omp3.0 to hit both linux and windows.

No, since both patches do things differently, its an alternative.

Well, lests start with describing what Openmp is. Openmps is a standard that defines API for shared-memory multiprocessing. Standard is defined by OpenMP folk, and then compiler folk implement the standard. gomp is GNU openmp implementation that gcc uses, MSVC90++ has its own implementation too. -fopenmp is the magic switch that makes #pragma omp directives do its magic work.

Enabled - didnt knew pms were disabled by default after forum move. EDIT: http://sprunge.us/YJTC diff for mangos.

Oi, i forgot to clean my pms. Cleaned. Also, im on rizon, quakenet and freenode IRC networks if ya need me.

Thanks for interest painejake. I've run into several issues with my threading approach - so far im pinpointing each of them trying to prevent problems, but it's still far from being tested enough. Im delighted with it really bringing a speedup - my last project, CORBA vmap cluster failed miserably... Kind of a situation that puts your skill in question, trust me. As for DB: i used only mySQL, which proved to have enough performance for me. If you have a spare machine in LAN with your MaNGOS server, i recommend you to move SQL there, even if the machine is slightly worse than MaNGOS one. Also, i found out that VC90++ includes own implementation of openmp, you need to compile with /openmp switch, whatever that means, im not a windows guy myself.

So i am beyond understanding I used to hold 2k on MaNGOS it was a Q6600 and 8 gigs ram, around the time when ACE netcode was still a patch. Mainly it was database configuration issue for me. Even today i still think that DB access is the biggest bottleneck in MaNGOS/TC as of now, i remember Derex wanting to do something about it, but it seems he abandoned that idea. It's a standalone - linux only patch. I wrote it for TC1, which is a MaNGOS derivative and closely resembles MaNGOS (im a realist, and i know that 70% of TC is MaNGOS ) - if you can do automake fixes i specified you're free to test it.

Im not adding any library, gomp is a part of gcc, and if your compiler is up-to-date everything will work correctly. If that patch needed any external library id tell so. Also i know that i am taking completely different approach than Derex - but writing it 100% same method as him would be waste of time, dont you think? Derex uses sophiscated system of requests to add maps to update queue, which is then executed. I on the other hand break apart for() loop into chunks that threads do parallely. Though we use different methods, outcome is more or less same: map::update() is called in own thread. I read Derex's patch many times looking for eventual pitfalls, or data access problems, and found none such thing. Or maybe i have old patch in my repo, who knows. This started mainly as a way to disprove my friend that core with openmp forked loop for map updates will even work - i lost the bet but i do not regret it that much. Ill be as much happy to encounter and fix any bugs that my approach will bring - for me its all about learning

I've written a small patch for TC that provides similiar features as mtmaps by Derex. It works by splitting workload of MapManager::Update() loop across several threads. It's been tested on TC with good results (60ms update time with 600 players at peak) and id like to share (and test ) this patch with MaNGOS community. Differences are so few that it will be easy to merge. For it to compile you need: linux gcc 4.X (for openmp support) add -fomp to compile flags link mangos-worldd with gomp library since TC uses cmakes i cannot provide automake patch to allow it to build, but i know youll be able to do it with no problem - if you will have trouble with it though, i can do it too. Diff is at: http://bitbucket.org/raczman/trinitycore-patches/src/tip/mtmaps2

It seems that blizz servers do not use .dbc's exclusively... Maybe there are some spells which are not in DBC but are handled manually in their core? Maybe they have an exception for example 45396 spell which checks for players location (isle or 2 new instances) and only if they are there the aura is applied. It's pure speculation, but it's the best i can think of.

The second enchant has a non-existing spell in DBC too o_O weird.

DELETE FROM spell_proc_event WHERE entry IN(45401,45403); INSERT INTO `spell_proc_event` VALUES (45401,0,0,0,0,0x0000000000000000,0x00481001,1.24,45), (45403,0,0,0,0,0x0000000000000000,0x00004000,1.24,45); Is it ok now?

Or write a script that looks like this: #!/bin/bash make install cp -r /path/to/etc/backup /path/to/servers/etc/directory And you're all good. Linux gives you powerful scripting possibilities, try to use them to make your life easier (at least faster).

DONT USE REPACKS. THEY SUCK BALLS OF STEEL. Also: get rid of vista, install linux, preferably ubuntu for ease of use. compiling mangos and setting it up on linux is considerably easier, and it will be faster and stabler than on windows.