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!

* What bug does the patch fix? What features does the patch add? Right now, the entries to use in an instance at a given difficulty are scanned in ascending order, and the highest one found is taken. This is wrong. Example: 39747 has 39823 as difficulty_entry_1, the others are 0. 10 man and 25 man normal work as they should, but 10 man heroic and 25 man heroic both use the 25 man normal entry, because it is the last found one. This patch corrects this behavior as follows: - if 10 man heroic is 0, it uses 10 man normal - if 25 man heroic is 0, it uses 25 man normal - if the selected entry is still 0, it uses the normal entry (this already works and is not changed) * For which repository revision was the patch created? rev. 10337 * Is there a thread in the bug report section or at lighthouse? If yes, please add a link to the thread. none that i know of. * Who has been writing this patch? Please include either forum user names or email addresses. me, False.Genesis diff --git a/src/game/Creature.cpp b/src/game/Creature.cpp index 6780181..1577b0c 100644 --- a/src/game/Creature.cpp +++ b/src/game/Creature.cpp @@ -199,25 +199,55 @@ bool Creature::InitEntry(uint32 Entry, uint32 team, const CreatureData *data ) } // get difficulty 1 mode entry - uint32 actualEntry = Entry; CreatureInfo const *cinfo = normalInfo; // TODO correctly implement spawnmodes for non-bg maps - for (uint32 diff = 0; diff < MAX_DIFFICULTY - 1; ++diff) - { - if (normalInfo->DifficultyEntry[diff]) + + // difficulty selection works like this: + // - dungeon normal / 10 man normal = entry + // - dungeon heroic / 25 man normal = difficulty_entry_1 + // - 10 man heroic = difficulty_entry_2 + // - 25 man heroic = difficulty_entry_3 + // in raids it should work like: if difficulty_entry_2 not exists then use -> entry + // if difficulty_entry_3 not exists then use -> difficulty_entry_1 + uint32 diff = GetMap()->GetSpawnMode(); + if (diff) + { + --diff; // the difficulty used as array index must be 1 lower then what the map returns + do { - // we already have valid Map pointer for current creature! - if (GetMap()->GetSpawnMode() > diff) + cinfo = NULL; + if (normalInfo->DifficultyEntry[diff]) { cinfo = ObjectMgr::GetCreatureTemplate(normalInfo->DifficultyEntry[diff]); if (!cinfo) { // maybe check such things already at startup - sLog.outErrorDb("Creature::UpdateEntry creature difficulty %u entry %u does not exist.", diff + 1, actualEntry); + sLog.outErrorDb("Creature::UpdateEntry creature difficulty %u entry %u does not exist.", diff + 1, Entry); return false; } + break; + } + else + { + // if 0 in db -> select alt. entry + switch (diff) + { + case 0: // difficutly_entry_1 + case 1: // difficutly_entry_2 + cinfo = normalInfo; // not found, leave the loop with default entry + break; + + case 2: // difficutly_entry_3 + diff = 0; + break; + + default: + sLog.outError("Creature::UpdateEntry creature difficulty %u entry %u unhandled", diff + 1, Entry); + cinfo = normalInfo; + } } } + while (!cinfo); } SetEntry(Entry); // normal entry always Commit in my repo: http://github.com/fgenesis/mangos/commit/ba4376aaf202b2711f33128b8a5f333102aa6540

i know, i thought this may be useful for those not using iptables or other proxy solutions. some "mangos native" stuff basically. side note: windows users don't have iptables

This patch allows to specify multiple ports to listen on in config, like this: WorldServerPort = 8079,8085,8099 Commit in my repo: http://github.com/fgenesis/mangos/commit/3132449395514f64b28dfd5eaa5c0e3a36c56cba Later Fix for GCC: http://github.com/fgenesis/mangos/commit/d5b96ccafdf9c9097a33c82a80d5cf3919e12d7d No idea who may actually need it, but i had the urge to write this to circumvent some firewall/blocked port issues a few friends had. This is rather a quick hack, but the code is tested with a few clients on each port, and works. In case someone is interested in it i may clean this up a bit more -- i'd apprieciate to have a few test results/confirmations if it works as intended. Note: I am still not quite sure if this is maybe causing some hiden race conditions or other multithread problems, because i am using only one network thread right now. Feedback on this matter is also appreciated!

innodb_flush_log_at_trx_commit=2 is a lot faster than 1 and safer than 0. I use it since a loooong time and have no problems with it, and my mysql is at least 3 times faster and allows heavier load without getting sluggish (Not using a SSD). For SSDs it should not make a big difference, but for traditional HDDs it does.

directory scan? maybe something like http://paste2.org/p/872531 is useful? (found this somewhere in my snippet collection)

this can happen for example if you test on a slow and not properly configured localhost mysql installation. if mysql doesnt have enough ram simple update queries can take 100ms or more to execute, and such ones... long. if this happens again try giving mysql a bit more ram (edit conf) and check for innodb datafiles fragmentation. (had this problem on my notebook and got it solved like this)

For server-side solutions, there is always a quite high risk of a false alarm, because of latency, de-synchronisation, etc. That makes it very difficult, if not impossible, to implement a reliable anticheat.

from what i know, mysqldump locks the tables it is currently dumping, and for large tables (like character_achievement_progress) that can take minutes. not sure if there is a way to prevent the locking (and i doubt it would be wise to do that)

a common problem i had was using ' or " (quote characters) in strings in the config file, for example in the motd. check if you have quotes in strings, and remove them (except real quotes enclosing a string).

i can confirm this too, (still) using rev. 9508