False.Genesis

then they have slow update speed for mobs and faster update speed for players probably. just a thought,but i think the update interval for stealthed players must be pretty fast. imagine a rogue behind you showing up after 2-3 secs.. lol.

post it here...? i dont understand russian, checked mangos.ru, found the topic and used online translator to get some idea about it, but whatever... as long as your/SilverIce's patch isnt ready, this one can be used. i got -30% load with 280 testers on, this is at least something for now. cant wait to see the "real" patch btw

@JordanMckeag: mangos rev: 8371 +SD2 +a LOT of custom stuff uptime: 1d 2h 40m (avg.: 0d 6h 19m) right now. max 300 testers online, and anyways there is no crash possibility in this patch. about ram usage: this patch adds 4 bytes additional ram for every logged in player (8kb ram for 2000 players). nothing basically EDIT: okay, will update the patch tomorrow to use conf values.

this seems to be a nice patch indeed, but please remove the advertising, its not liked to be seen on this forum. saying just this before a mod does.

first of all i did some benchmarking with Visibility.Distance.Continents = 160 Visibility.Distance.Instances = 160 Visibility.Distance.BGArenas = 220 CELLS_PER_GRID = 8 - sorry, forgot to change it to all 160 - and it seemed to use slightly less cpu, mostly 90-102%, avg 97%, with ~250 testers. interesting was that some testers complained about a much higher latency and sometimes core stucks of 5-10 secs. i checked the console window, that was never stuck, so it was probably a cpu load problem. no other patches applied in the meantime that could affect cpu usage as much as this one. however before the patch all was fine and core did never get "stuck" as after the patch. after that i found out something interesting on my win32/xp localhost testserver (no testers on except me): i was coding some custom boss (that *highly* stresses the grid search, because masssive spawns casting a *lot* of small-range AOE spells (5 yd) -- Ambal, if you want the code, i will share it with you, if it may help you to optimize the patch further!) anyways, always when mass-spawning my boss caused mangos to use 1 cpu core completely, that lasted for 2-3 secs. then i reverted the patch, set the cells per grid back to 4 (mangos default) and repeated testing the boss. and while spawning it used less cpu then before, something around 15-20% !! i dont understand that, i think i must have made a mistake in testing... anyways, i will post more detailed benchmarks tomorrow, with the old grid search algorithm again. if you have some idea what else can be done let me know, as i will re-apply the patch and test more soon. EDIT: visibility settings on testserver are irrelevent, all tests were done in an unspawned zone and limited to a small area, 40 yd radius or so. no influence on cpu usage from other sources. w32/Debug build.

before i applied the patch my core used 4 cells per grid (see here) i am not going to remove the patch again unless i have to revert it for an updated version, but i can tell you that before mangos switched to 3.1, when there were 8 grids per cell, mangos didnt use more then 40% cpu if i remember correctly (i may be wrong tho). before the patch the visibility was as high as possible with 4 cells (166 didnt work for some reason, so i used 160), so its not really a change compared to what i have now. one more test at late night: Visibility.Distance.Continents = 160 Visibility.Distance.Instances = 160 Visibility.Distance.BGArenas = 220 right now 68 testers online, causing an average load of 50-70% cpu. will do some tests with different cell sizes when i can.

hey Ambal, i have successfully applied v1.13 of the patch to [8235] after some manual resolving, with the following settings: Visibility.Distance.Creature = 160 Visibility.Distance.Player = 160 Visibility.Distance.Object = 160 Visibility.Distance.InFlight = 160 Visibility.Distance.Grey.Unit = 1 Visibility.Distance.Grey.Object = 10 --after patch replaced the first 2 lines with -- Visibility.Distance.Continents = 100 Visibility.Distance.Instances = 160 Visibility.Distance.BGArenas = 300 now the benchmark part: using ubuntu 7.1 and a dual-opteron 2.5 ghz machine i got (using top, refresh delay 1.0s): before patch: 90-108 % cpu usage, sometimes a little less but in the next second its high again after patch: 96-105% cpu usage, now quite constant at 98-101% changing Visibility.Distance.Continents to 220 and after a reload conf, i got also mostly around 99% cpu usage. using 60 (same setting) i got 91-97% cpu usage. it didnt change much with high visibility distances, thats good, but i hoped this patch would bring down cpu usage a litttle more for lower distances. some more info: 16 cells, 255 testers online while testing, system has 8 gb ram, vmaps in continents disabled, in instances/BGs enabled, no multicore patches applied, DetectPosCollision=1, but more custom/additional stuff that should not really affect cpu usage (i expect anticheat to use up most -- this repo: http://github.com/fgenesis/mangos/commits/master ) hope that was enough detailed info, if you need more, just shout. EDIT: did some more testing with VERY low settings: Visibility.Distance.Continents = 40 Visibility.Distance.Instances = 60 Visibility.Distance.BGArenas = 80 resulted in 70-95% cpu usage, quite fluctuating, sometimes going down to 60 for a sec

and even if the data field is completely removed, its always possible to add an own table for your website or whatever that stores exactly the values you need. never beeing read, but always written on character save. (1 query more in whole saving process) this will also save work when data field offsets change.

not yet. give the devs some time

well there is 1 more minor problem: vellums dont get used up, means 1 vellum can be used over and over again. enchanters are happy about it, but would be nice to see this fixed someday.

because deeprun tram vmaps are crapped up or not generated, dunno. you should keep it excluded.

no, in my addition the timer is updated before the alive check. i considered the case you told and i can assure that the timers are beeing updated correctly (also tested this specific case to be sure)

please test if this change [ http://github.com/fgenesis/mangos/commit/2b2aa62676c13ba15396fad1585a3564fcf7ae62 ] fixes the dead players regenrating problems. imo this sould be fine since Player::RegenerateHealth() is called only once, in Player::RegenerateAll(). and probably the other powers should not be regenerated either when dead.

found it: the scroll produced is not yet in my database :lol: spell fails due to Player::CanStoreNewItem() returning EQUIP_ERR_ITEM_NOT_FOUND. forget about my useless "bug" report, patch works great. didnt experience crashes so far (with Dark-D's suggestion)

with the Dark-D's suggestion the patch seems to work really well. found 1 spell that is not possible to enchant a vellum with: http://www.wowhead.com/?spell=62257 fails with "item not found".. any idea?

pushed to my repo: http://github.com/fgenesis/mangos/commit/ff15565f53d945fbf8bdc991f6c06d8ee1a44c02

tested, works fine. thx a lot.

fixed in my repo: http://github.com/fgenesis/mangos/commit/515255f0dacea467b36a96be41d9430803257151 i consider this patch as a hack so i didnt post it

bump .

probably you are using tabs instead of 4 spaces, paste2 displays a tab as 8 spaces anyway, going to test this, thx EDIT: code with cleaned up tabs in my repo: http://github.com/fgenesis/mangos/commit/3dc46f59d19a6235b1fa812af0d6823b1e066081

ok let me explain it from the client's view: normal case: - client requests channel join + puts channel name in internal pending list - few msec later server answers with channel joined packet - client is happy, removes channel from pending list, and displays "joined channel blabla" in chatbox hack case: - server sends channel join opcode and flags client as joined in channel - client doesnt have that channel in pending list, thinks "WTF?!", and drops the opcode - server thinkgs client is on channel, sends channel chat to client - client says "i am not on this channel" and drops the chat messages - also user cant type into channel because same "i am not on this channel" hope you understand it now. basically its the same like trade: what the client doesnt expect is dropped.

i have tried this too and i can only repeat what vladimir said: it is NOT possible to force the client to join a channel.

what is this piece of code supposed to do?

read the code, UNIT_FIELD_BYTES_1 is stored before save, and set back to the stored value after. its fine to set it to 0 there.

- this fixes "blue" and unattackable NPC pets: only player pets should have the flag UNIT_FLAG_PVP_ATTACKABLE set. - for rev 6944 - as far as i know there was no bug report yet - patch be me (False.Genesis / ProjectEden) diff --git a/src/game/SpellEffects.cpp b/src/game/SpellEffects.cpp index 56d86dc..03eaf5f 100644 --- a/src/game/SpellEffects.cpp +++ b/src/game/SpellEffects.cpp @@ -4184,7 +4184,10 @@ void Spell::EffectSummonPet(uint32 i) // this enables pet details window (Shift+P) // this enables popup window (pet dismiss, cancel), hunter pet additional flags set later - NewSummon->SetUInt32Value(UNIT_FIELD_FLAGS,UNIT_FLAG_PVP_ATTACKABLE); + if(m_caster->GetTypeId() == TYPEID_PLAYER) + { + NewSummon->SetUInt32Value(UNIT_FIELD_FLAGS,UNIT_FLAG_PVP_ATTACKABLE); + } NewSummon->InitStatsForLevel(petlevel); NewSummon->InitPetCreateSpells();