Ambal

Any test results for the patch from branch 1?

With modifications applied in [10865]. Cheers

Can you reproduce this crash on clean core? Your server crashed in Map::SendObjectUpdates() function, but thing is that Map::Update() was called from third-party code ( DelayExecutor and MapUpdateRequest are not standard mangos classes ). P.S. You can also open Opcodes.cpp file, change all occurrences of PROCESS_THREADSAFE to PROCESS_THREADUNSAFE and check if you'll have the same crash.

Yes, this is possible. Use similar code in teleport command handler: caster->CastSpell(caster,your_spell_id, false);

Hi, everyone. I want to try and fix our timer system so we can keep track time intervals between Update() calls for specific object and update spells/corpse/regen and many other timers accordingly. This should resolve issues we have with mob respawn on inactive grids, some spells like F@r S1ght etc. Vladimir and ciphercom made several patches, the last commit was [10688], but unfortunately all of them have failed for several reasons: 1) sometimes, especially in earliest versions of patches, you can get HUGE diff time by unknown reasons... Well, the real problem was connected to the way we obtain timestamps to initialize time/timers. Here is an explanation why even [10688] has failed: ... World::Update() { world_time = A; <= you start your world update at time A } ... World::UpdateSessions() { Map::create_time = B; <= during packet processing you create a player and add him to the map. Map decides that it was created at time B, where in 99% of cases B > A } ... Map::Update() { real_diff = getMSTimeDiff(create_time, world_time); where create_time = B, world_time = A and B > A <- this is where you get HUGE update } To resolve this issue we should save and use time when current WORLD update tick started to execute. This way you will NEVER get any issues with time tracking since your time interval is fixed now until next World::Update 2) there was a problem with diffs handled by grids. For example, you add an object to inactive grid, then wait for 7 mins and step into that grid making it active -> BANG, you get 7 mins DIFF time for your object! We will use a separate timer for each WorldObject to measure intervals between actual updates. With such approach situation described above is not possible at all. I've used some parts of Vladimir and ciphercom's code to make a patch since code inside Unit/Player/Creature/***/::Update() functions is correct. Please, test, post comments and report any issues you find. Cheers P.S. Give this patch a try - if it has any of previous issues, lets forget about real diffs in mangos My repo is: https://github.com/Ambal/mangos

Applied in [10848]. Thank you for all your feedback Lets go and fix timer issues for grid inactive objects

I'm going to commit this patch tomorrow in case noone will bring some bad news about bugs/crashes/glitches or performance degradation Cheers

Yes, but problem is that player was teleported and then your aura code decided to do something with player's pet -> call GetMap() -> get assert. Something is reeeeeeeealy bad in patches you use or someone has broken delayed far teleports.

This assert happened because player was removed from the map (far-teleported) BUT code in AreaAura::Update() was not able to handle this situation correctly aka didn't check if player is in world which lead to failed assertion in WorldObject::GetMap() function call. Do you use third-party patches or this happened on clean mangos core? UPDATE: faulty code is in Pet* Unit::GetPet() const { ObjectGuid pet_guid = GetPetGuid(); if (!pet_guid.IsEmpty()) { if(Pet* pet = GetMap()->GetPet(pet_guid)) return pet; sLog.outError("Unit::GetPet: %s not exist.", pet_guid.GetString().c_str()); const_cast<Unit*>(this)->SetPet(0); } return NULL; }

Nice results, kero99, thank you very much Is patch in branch 1 can be applied for tests? We just want to see the difference in CPU usage between these two to decide what parts might be improved. Cheers

Any test results on this patch? Anyone? Guys, this piece of code is very important for us and will bring massive bonuses to core performance, why noone interested in submitting feedback?

Fixed RemoveQueuedSession() call in World::UpdateSessions() function. Also CMSG_NAME_QUERY processing set as PROCESS_THREADUNSAFE. Lets consider this patch as final in case you won't report bugs anymore

IMHO - we need messaging subsystem in Mangos Core (aka based on current Callback mechanism implemented in event system) in any way - this will solve open problems with thread-unsafe method calls like: 1) Far teleports 2) Player/object removal from map 3) Apply damage/calculate rewards for mobs affected by spell on different map etc Also, "signal-slot" idiom implemented by different GridVisitors might help with some spell scripting :rolleyes:

Thanks to everyone for tests. Error with 'RemoveQueuedPlayer' I suppose I did when tried to merge patch with newest mangos revisions. It should definitely be 'RemoveQueuedSession'. As of CMSG_NAME_QUERY - thanks for hint, I'll see what is causing weird behavior you've described, lukaasm. Cheers

please, provide mangos rev you are using as well as DB version and coords of loot chests you have problem with.

Are you sure you are testing the latest patch from my branch? There are changes for spell packet processing which I want to be sure are really thread-safe.

In real WOW if you can't be teleported to another map, you should get appropriate error message on your screen. So your code is a bit hackish, but if none of the devs would complain, we can add it. Real solution will be possible only when we will implement some sort of "message pipeline" to deal with concurrency issues by not calling thread-unsafe functions directly but scheduling their execution in a single thread.

We'll review these changes and if appropriate to current core - will apply them Thanks.

Ok, another portion of packet processing optimizations are submitted based on stats provided by False.Genesis. You can download profiling info from here http://filebeam.com/bf0b0683255ba557c88df7d366429bb7 - - rename to 'opcode_profiling.html'. If someone wishes to participate, please, install patch in the previous post made by False.Genesis and collect some useful networking data for us :rolleyes: Opcodes CMSG_INSPECT and CMSG_MESSAGECHAT are not that easy to make thread-safe at the moment WARNING: spell opcodes CMSG_CAST_SPELL were parallelized so pay attention on server stability and report any appearing issues!

Ohho, this is AWESOME! You've saved alot of my time, False.Genesis I'll analyze your findings and post results here as soon as I find some free time, I promise

Well, pythod scripts will require you to have Pythod env installed, while console binary can run on any supported platform since runtime is already there Yeah, pythod is great but we are here to learn something, aren't we :rolleyes:

Yeah, current way of applying SQL updates for mangos is PITA. If I'll find time, I'll write a small executable which will do all this painful work for you ...Because I already tired doing everything manually

Ok, thank you, divisorxx I was busy so didn't had a chance to write code which will gather some statistics for us... I hope to do it today, but who knows Anyway, you should threat current patch as final version until taught otherwise

Patch updated: now all taxi packet handlers are processed in Map::Update(). Check newest changes as if everything will be OK - this should be the last patch version before submit. Thanks to everyone making tests and/or posting their feedback UPDATE: I think we should try and collect some statistics about amount of each opcode received to see what packet handlers might need to be parallelized in order to improve performance... I'll submit a small patch which will write output file with all info we need. Stay tuned

Yes, it seems so. There are alot of packet handlers which might be already thread-safe, but lets finish with movement handling first. My biggest concern is taxi packet handler which is using TeleportTo() function call - I'm not sure if we have taxies teleporting to other maps (or this packet is for transports too?). We can review the rest of packet handlers one-by-one and submit smaller patches once we are sure packet handlers are safe to call from Map::Update()