crashuncle

Well its sadly totally incompatible with the latest 0.12 branch (Check #241) and other members here report that the newer versions are unstable. Some help would be appreciated cause I want to understand also why some code parts aren't compiling suddenly, its understandable if you want any rewards in exchange. Would love to see at least basic multi-threading in Mangos again

Bump (Guess its ok after a month)

Seems that one of the most important patches for Mangos is simply incompatible

Nobody had luck yet to fix that?

Someone tested it with 0.12 yet? Else I have a look at it.

There were in the past already quite good "Anti-Cheat" systems for MAngos at least against Fly/Jump/Teleport hacks. The chance to get a false alarm is very low if you use a few brain cells to write the code. I mean when the Z axis has for example a diff of like 1000% in a second then it can't be a lag or something else. Only a solution against Speedhacks can be quite difficult, still the "Real fast" ones can be also easily detected with a very low chance of false alarms.

Could you post it anyway? It is currently better then no patch at a ll.

Anyone tested it yet? A small reply would be helpful.

Looks good Caeruleaus, but is it also working with the 0.12 branch?

Will there be also a 0.12 based rep. sometime?

Sounds awesome FragFrog, do you use any patches like the MTMaps one?

Thanks for the info, I use only the TBC branch. Just wasn't sure if its still stable after the latest GUID management related changes.

Anyone knows how I can solve my patch problems which I wrote in my previous post or got a 0.12 compatible version?

Good question, the question is if any of these patches posted here is still required at all? Someone is up to date?

So If I get it correct then the best way is to use Infinity's patch with WoWeur's lock for spell update if I want to get the best stability with the 0.12 branch? I don't need the ACE pragma then? I also got a few conflicts and can't solve two of them one the latest 0.12 branch (397cc2ab0081ef115b27fe5a7b31c3ee2b82e562): ObjectAccessor.h: diff a/src/game/ObjectAccessor.h b/src/game/ObjectAccessor.h (rejected hunks) @@ -126,14 +131,16 @@ class MANGOS_DLL_DECL ObjectAccessor : public MaNGOS::Singleton<ObjectAccessor, void RemoveObject(Player *object) { HashMapHolder<Player>::Remove(object); } // TODO: This methods will need lock in MT environment - static void LinkMap(Map* map) { i_mapList.push_back(map); } - static void DelinkMap(Map* map) { i_mapList.remove(map); } + static void LinkMap(Map* map) { ACE_Guard<ACE_Thread_Mutex> guard(m_Lock); i_mapList.push_back(map); } + static void DelinkMap(Map* map) { ACE_Guard<ACE_Thread_Mutex> guard(m_Lock); i_mapList.remove(map); } private: + static ACE_Thread_Mutex m_Lock; // TODO: This methods will need lock in MT environment // Theoreticaly multiple threads can enter and search in this method but // in that case linking/delinking other map should be guarded template <class OBJECT> static OBJECT* FindHelper(uint64 guid) { + ACE_Guard<ACE_Thread_Mutex> guard(m_Lock); for (std::list<Map*>::const_iterator i = i_mapList.begin() ; i != i_mapList.end(); ++i) { if (OBJECT* ret = (*i)->GetObjectsStore().find(guid, (OBJECT*)NULL)) I can't find the related code in the ObjectAccessor.h at all. Spell.cpp: // Lookup target in already in list - c + for(tbb::concurrent_vector<TargetInfo>::iterator ihit = m_UniqueTargetInfo.begin(); ihit != m_UniqueTargetInfo.end(); ++ihit) I guess this is also a mistake in the patch and it should be: // Lookup target in already in list - for(std::list<TargetInfo>::iterator ihit = m_UniqueTargetInfo.begin(); ihit != m_UniqueTargetInfo.end(); ++ihit) + for(tbb::concurrent_vector<TargetInfo>::iterator ihit = m_UniqueTargetInfo.begin(); ihit != m_UniqueTargetInfo.end(); ++ihit) @@ -3377,7 +3441,7 @@ void Spell::WriteSpellGoTargets( WorldPacket * data ) // m_needAliveTargetMask req for stop channeling if one target die uint32 hit = m_UniqueGOTargetInfo.size(); // Always hits on GO uint32 miss = 0; - for(std::list<TargetInfo>::iterator ihit = m_UniqueTargetInfo.begin(); ihit != m_UniqueTargetInfo.end(); ++ihit) + for(tbb::concurrent_vector<TargetInfo>::iterator ihit = m_UniqueTargetInfo.begin(); ihit != m_UniqueTargetInfo.end(); ++ihit) { if ((*ihit).effectMask == 0) // No effect apply - all immuned add state { I found the function "WriteSpellGoTargets" but it doesn't fits there at all. @@ -327,7 +327,7 @@ void Spell::EffectSchoolDMG(SpellEffectIndex effect_idx) case 72624: case 72625: // Ooze Eruption { uint32 count = 0; - for(std::list<TargetInfo>::iterator ihit= m_UniqueTargetInfo.begin();ihit != m_UniqueTargetInfo.end();++ihit) + for(tbb::concurrent_vector<TargetInfo>::iterator ihit= m_UniqueTargetInfo.begin();ihit != m_UniqueTargetInfo.end();++ihit) if(ihit->effectMask & (1<<effect_idx)) ++count; Only for the Wotlk spell, so quite useless for 0.12 I guess.

May add more informations? Like the compiler log?

Can someone explain this part of the code? Especially the "strange code" part makes no real sense to me. I personally would like to lock zones / maps generally and log players who try to enter them. The question is if this way isn't a bit too hacky.

Bad written, delete me.

It worked fine, I wonder why Mangos doesn't support it yet. I can talk to Burlex if you want

"maje -j xx" only defines how much CPU cores will be used to compile the core, it will not affect the performance of Mangos itself. As Kero99 said, you must use the multithreading patch. It is still not really good working but it decreases at least the load on the primary thread a bit. So If you own a Quadcore server then use -j 4 to get the core compiled quickly, use something like -j 2 if you have a 2nd realm running while you compile. Take care with the priorities (nice), else the 2nd realm might lag while you compile.

I think a patch with the related changes mentioned by Infinity would help here.

I wonder how the latest revisions of the 0.12 branch are working, I saw massive changes like the CellLock remove. Anyone got experience with it already?

I really hope that multithreading gets better soon, some of the patches and ideas here were good but the development always stopped. Without multithreading are a bout 1000 players on a decent machine at least no problem.

Any updates about this patch? I saw quite a few changes in the 0.12 GIT which seemed to affect multithreading. Someone knows what is the best Mangos revision for openMP or the best MT patch for the latest revision?

Looks fine for me?