False.Genesis

Well, when i made the patch i needed a little hack for a boss script i made, that would turn NPCs looking like friendly without actually changing faction. ^^ Can't remember the exact details (was too long ago), but it can be removed. *hides in shame* Btw, nice to see this patch is still in use, after such a long time.

Will never happen. what about WINE? how are chances that it will work with it?

@Toinan67: yes, this is some live data recorded, code is in the following commits (code by me): https://github.com/fgenesis/mangos/commit/b753c8b8fb6c20acea351984ebbc53e0a08421ff https://github.com/fgenesis/mangos/commit/c5a6be53cee4e3f12732dae12943ad3bd4729e6e https://github.com/fgenesis/mangos/commit/86f1eb080f0d1132d3d6e9b782ba7037a9086f97 and also https://github.com/fgenesis/mangos/commit/6db47c9af2ff4998913072ab0673895720bbc8f3 for the network_usage_* table format. dont have a clean patch and no time to work on any mangos related things, sorry [/offtopic] i plan to test this patch without any mtmaps stuff whenever i have the time. and i have a question, which parts of the spell system can possibly be multithreaded (or, is it of any use to do so)? because i have observed this eating the most bandwidth, but i dont know how much CPU it uses, compared to the map/movement/visibility stuff. the thought is that *most* spells affect only 1 map .. (but not, for example, a player with a buff from another player enters another map, or a teleport/summon spell). EDIT: i mean outgoing bandwidth here, but nevertheless i imagine the spell system could do better if response packets are built in different threads... because a LOT of them are sent.

@Ambal: you may find this useful: http://filebeam.com/e5a485ebb4bf7b9c6f7130169dd5c978 contains some network data recorded for ~2 months, with online# counts from 30 - 150 average. hope this helps

had the same problem 2 years ago. back then, i wrote a PHP script that dumped every character to a pdump, and then loaded all back in the new DB, but flagged for rename. those that were conflicting were changed by the script, like, append an underscore to the name or so. Had to be renamed anyways. Back then the whole thing worked via telnet/RA & PHP sockets,which was highly unreliable for that purpose (it lost about 20-30 chars, possibly more; i had to fix them manually), but now with SOAP that should work pretty well.

@Laise: my hackfix didnt help , 2 more crashlogs of newer rev 10504: http://paste2.org/p/996459 http://paste2.org/p/996460

two crashdumps for rev. 10408: http://paste2.org/p/994295 and http://paste2.org/p/994298 after this, i hackfixed the crash with this: http://github.com/fgenesis/mangos/commit/d2787038182733d9bab9a60e0c1988e8e9d267bc so i don't have it anymore. i am sure this is wrong, anyways. i have some more dumps, in case you need, but not for a newer rev. testing with this commit on localhost i also got this crash (but no dump, sorry), so this didn't help.

Users of the vehicle patch may be interested in this: http://github.com/fgenesis/mangos/commit/3529e2d248ff3f79f5cdcbb5738527fa16aebe72 -- this fixes a crash related to vehicles in vehicles. (to reproduce: spawn 33060, enter, exit, enter turret, exit, enter, exit, enter turret, exit, then .npc follow on vehicle) http://github.com/fgenesis/mangos/commit/f7bed1b6280d6dbaa76db7a071f2034e50239e77 -- allow logout in vehicle http://github.com/fgenesis/mangos/commit/529836f5af32398a9a8409c03133c401b22363ff -- very sneaky crash, happens often, but randomly http://github.com/fgenesis/mangos/commit/5e1989eb241ffdbbca045b0870d8be7ca2062c1a -- another vehicle mount crash. (to reproduce, let A summon chopper, B enter its side wagon, A logout, B will be locked in place, then teleport or summon B away.)

enough offtopic barfing, now trying to reproduce the crashes after 6259b78a82b will edit this post with results. EDIT: crashes are still there. however, seems i managed to get rid of them with this commit: http://github.com/fgenesis/mangos/commit/d2787038182733d9bab9a60e0c1988e8e9d267bc -- yes, i DO wonder about this. A LOT.

just managed to reproduce this in VS debugger (casting 47820 at custom boss in heavy spawn phase). the strange thing here is that Unit::m_spellAuraHolders was empty when the crash occured, so an iterator invalidation is unlikely imho. going to experiment further with this.

got the same crash here: http://paste2.org/p/986878 (rev 10408) -- have this one a lot, but yet no idea how to reproduce

interesting, i guess it must be on Mac only. On windows and linux it shuts down pretty fast, 10 secs max. In debug mode it can take up to 4 mins on my machine, tho.

Or just press Ctrl-C, if you are using the console directly.

This patch fixes wrong code from 3 years ago (Rev. 4158). How it does work right now: All spells that have a speed set are given a minimum distance of 5, even if these are self-targeting spells. This creates extremely high spell delays sometimes, especially with 17607 (Portal Effect: Ironforge, used by dalaran portal) and 47568 (Empower Rune Weapon). Both spells have a delay of 5 seconds, because their speed is 1 (for unknown reason). It should work like: The spells should be handled instantly. There is (imho) no reason to enforce a minimum distance just to delay things. Thx to nos4r2zod for pointing out these lines. diff --git a/src/game/Spell.cpp b/src/game/Spell.cpp index 5e1e430..a9cc227 100644 --- a/src/game/Spell.cpp +++ b/src/game/Spell.cpp @@ -829,7 +829,6 @@ void Spell::AddUnitTarget(Unit* pVictim, SpellEffectIndex effIndex) { // calculate spell incoming interval float dist = m_caster->GetDistance(pVictim->GetPositionX(), pVictim->GetPositionY(), pVictim->GetPositionZ()); - if (dist < 5.0f) dist = 5.0f; target.timeDelay = (uint64) floor(dist / m_spellInfo->speed * 1000.0f); // Calculate minimum incoming time @@ -894,8 +893,6 @@ void Spell::AddGOTarget(GameObject* pVictim, SpellEffectIndex effIndex) { // calculate spell incoming interval float dist = m_caster->GetDistance(pVictim->GetPositionX(), pVictim->GetPositionY(), pVictim->GetPositionZ()); - if (dist < 5.0f) - dist = 5.0f; target.timeDelay = (uint64) floor(dist / m_spellInfo->speed * 1000.0f); if (m_delayMoment == 0 || m_delayMoment > target.timeDelay) m_delayMoment = target.timeDelay;

just dropping a quick note that i tested this updated patch and it works fine. thanks a lot!