crashuncle

patch proposed by Infinity in #208 + mutex on unit and spellevent update despite that it looks ugly in some places still works fine for me.

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.

I tested on the lastest 0.12 mangos (with scriptdev and relaxed anticheat patch), you need to modify some parts of the patch to have it works.

I posted my diff to caerulueaus because I'm not sure of the quality and the rightness of my code.

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

attempt at mtmaps for 0.12

tell me if theres any problems

http://paste2.org/p/765918

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?

Most changes are no longer necesary it seems. Can't speak for the WotLK branch, but the TBC branch now runs by default pretty stable already, getting 2 ~ 3 days of uptime here with a core without stability patches, around ~250 users online.

Unless someone has additional patches / hacks to increase stability I'd say that, at least for now, this topic is no longer necesary

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?

is it still needed after http://github.com/mangos/mangos/commit/72f7a7ee56c63672faa7786b1d162a7a3b9ab406 ?

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?

--- a/src/game/MiscHandler.cpp

+++ b/src/game/MiscHandler.cpp

@@ -377,6 +377,26 @@ void WorldSession::HandleZoneUpdateOpcode( WorldPacket & recv_data )

uint32 newzone, newarea;

GetPlayer()->GetZoneAndAreaId(newzone, newarea);

GetPlayer()->UpdateZone(newzone, newarea);

+

+ /* This im still not sure on but seems to be working whitout.

+

+ if(newZone != _player->GetZoneId())

+ GetPlayer()->SendInitWorldStates(); // only if really enters to new zone, not just area change, works strange...*/

+

+ // ImpConfig: AntiCheat.GMIsland - Teleport to homebind if new zone is GM island

+ if(sWorld.getConfig(CONFIG_KICK_FROM_GMISLAND))

+ {

+ if(newZone == 876 && GetPlayer()->GetSession()->GetSecurity() == SEC_PLAYER)

+ {

+ _player->TeleportTo(

+ _player->m_homebindMapId,

+ _player->m_homebindX,

+ _player->m_homebindY,

+ _player->m_homebindZ, 0);

+ }

+ }

+

+ GetPlayer()->UpdateZone(newZone, newarea);

}

void WorldSession::HandleSetTargetOpcode( WorldPacket & recv_data )

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.

Voice chat isn't implemented. I don't think it's worth spedning time but if you insist then take a loot at old ascent's source code(rev 45xx I believe) and it's VC written by burlex(dunno if it ever worked, besides its pretty old) and mumble voip application.

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.

Hello there!

What is the effect of

make -j xx

does it make mangos multi processed really or not ?

and i will soon have a x4 processor, and i usually run two realms, one for "production" and another for tests, have i got to "make -j 4" both or can i "make -j 2" each to share processor cores ?

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?