Alex

Core changes do not touch most of the code this patch touches. I'm updating the patch now, and cleaning it up a bit (coding style). Will post updated patch after testing.

Error was introduced in "remove VC71" commit. Reverting helps

If it is, it can be easily added. Can anyone post some information on that?

I use GNU patch to apply, but create patches using GIT. Tried GIT apply with the latest one. Works ok. If it's not the case for you, well... maybe our GIT versions are mismatched or pastebin is fiddling with the patch somehow.

Update Latest (and probably last) version of the patch. More correctly select spells for autocast flag check using family ID. List of pet spells that are undergoing autocastable check (warlock pet spells selected by flags): http://pastebin.ca/1429765 List of pet spells that will not be autocastable is here (selected by new flag found): http://pastebin.ca/1429767 These lists are auto-generated based on flags used. The check function IsPetAutoCastableSpell may be easily extended to disable autocast for more pet spells in the same way. Overall changes list: 1. Constant SPELL_ATTR_EX_UNK17 is renamed SPELL_ATTR_EX_PET_NOT_AUTOCASTABLE 2. Function IsPetAutoCastableSpell(uint32 spellId) is added to SpellMgr.cpp 3. Added family selection masks SPELLFAMILYFLAG_WARLOCK_PET_SPELLS and SPELLFAMILYFLAG_WARLOCK_PET_SPELLS2 to SpellMgr.h 4. Checks in Pet.cpp are fixed to set not autocastable spells type to ACT_PASSIVE, it is the correct value to send to client to disable these 'corners' and autocast toggle feature 5. The same is done in Unit.cpp Get the patch code here: http://pastebin.ca/1429788 First post also updated. The patch is ready and will be updated only if some error is found.

I found a mechanism to properly detect warlock pet spells, currently analyzing what I have, then will update patch with a correct method of detecting all warlock spells and selecting (not-)autocastable from them. The patch is semantically correct, it may be applied even now. Only the IsPetAutoCastableSpell will be changing from now on. 2cyrex: what software are you using to apply the patch?

It is running on LAN server and have no complaints by now. I am working at narrowing spell list, though I don't know if it is really needed.

Version 3, suitable for [7859] Patch: http://pastebin.ca/1428824 SQL: http://pastebin.ca/1428821 The condition codes for EVENT_T_SPAWNED are stored in parameter 1. Codes are: 0: works always 1: works on map in parameter2 2: works on zone in parameter2 3: works on area in parameter2

Obsoleted by [7852]. I do not know how to check zone in SPAWNED type event using this condition code verification style, sorry. We have no player object in EVENT_T_SPAWNED. I will post third version of the patch soon that will extend SPAWNED with a map/zone check in another way.

Update: 4. Does not allow load or otherwise add passive/not autocastable spells with ACT_DISABLED/ACT_ENABLED states, replaces by ACT_PASSIVE Get it from http://pastebin.ca/1428750 First post updated, too.

Patch version 2: do not use new event type, extend existing EVENT_T_SPAWNED instead with conditions. Note: only CONDITION_NONE, CONDITION_ZONEID and CONDITION_ACTIVE_EVENT are valid for EVENT_T_SPAWNED, others will not fire because they require acting player. Patch here: http://pastebin.ca/1428720 SQL line here: http://pastebin.com/m32017bb8 Tested on [7851]

What does this patch do: 1. Fixes spells that must not be autocastable for pets, like Sacrifice. Maybe some others, do not know. 2. Also may fix the same for tamed/charmed creatures, but not sure because I do not know any spells that must be fixed. 3. Not autocastable spells are properly displayed in the client action bar: without yellow corner triangles. Autocast toggle is disabled by client too. 4. Does not allow load or otherwise add passive/not autocastable spells with ACT_DISABLED/ACT_ENABLED states, replaces by ACT_PASSIVE List of pet spells that are undergoing autocastable check (warlock pet spells selected by flags): http://pastebin.ca/1429765 List of pet spells that will not be autocastable is here (selected by new flag found): http://pastebin.ca/1429767 These lists are auto-generated based on flag used. What revision is it for: tested on [7940] Some background information: There is two warlock pet spells known to me that are not autocastable: Sacrifice and Consume Shadows (both are Voidwalker spells). Analyzing a set of spells from spell.dbc I have found a flag that is common for these spells and absent from another warlock pet spells. It is flag 17 (20000h) in AttributesEx. Combined with spell family and family flags, it yields excellent results. The check function IsPetAutoCastableSpell may be easily extended to disable autocast for more pet spells in the same way. Short about chages: 1. Constant SPELL_ATTR_EX_UNK17 is renamed SPELL_ATTR_EX_PET_NOT_AUTOCASTABLE 2. Function IsPetAutoCastableSpell(uint32 spellId) is added to SpellMgr.cpp 3. Added family selection masks SPELLFAMILYFLAG_WARLOCK_PET_SPELLS and SPELLFAMILYFLAG_WARLOCK_PET_SPELLS2 to SpellMgr.h 4. Checks in Pet.cpp are fixed to set not autocastable spells type to ACT_PASSIVE, it is the correct value to send to client to disable these 'corners' and autocast toggle feature 5. The same is done in Unit.cpp Patch (version 4): Get the patch code here: http://pastebin.ca/1444524

Okay, I will rewrite this and also move condition code to separate function. The patch will be available today (if nothing else happens). Thanks.

This small patch allows to easily add creatures such as Defias Prisoner that i.e. must be hostile at one map and friendly at another. Or that must have different looks/stats/etc. on different maps but must have same template ID. Patch version 3: do not use new event type, extend existing EVENT_T_SPAWNED instead with its own conditions. Patch: http://pastebin.ca/1428824 SQL: http://pastebin.ca/1428821 The condition codes for EVENT_T_SPAWNED are stored in parameter 1. Codes are: 0: works always 1: works on map in parameter2 2: works on zone in parameter2 3: works on area in parameter2 Tested on [7859]

Nice innovation. Works fine, though I still do not understand how it avoid so much critical sections in threads, must be OpenMP magic somewhere Oops. It does not avoid anything except explicitly specified random generator functions. This is potential source for a lot of problems with two threads writing the same data.

[7294] crash is probably fixed [cut old link] in [7300], please delete the post, I'm a bit late

Patch for rev: about rev.7294 this crash was discovered Simple single-line fix for buggy check. --- BattleGroundMgr.cpp 2009-02-16 23:19:15.000000000 +0300 +++ BattleGroundMgr.cpp 2009-02-18 23:25:59.000000000 +0300 @@ -260,7 +260,7 @@ } // couldn't find the player in bg queue, return - if(itr == m_QueuedPlayers[queue_id].end()) + if(queue_id < 0) { sLog.outError("Battleground: couldn't find player to remove."); return; --- The check will go wrong here, because after for (queue_id = MAX_BATTLEGROUND_QUEUES-1; queue_id >= 0; queue_id--) { itr = m_QueuedPlayers[queue_id].find(guid); if(itr != m_QueuedPlayers[queue_id].end()) break; } if no player is found, it will have -1 in queue_id, so m_QueuedPlayers[queue_id] has no sense.

If someone has no backup from 2.4.3, he may try: UPDATE `item_instance` SET `data` = CONCAT( SUBSTRING_INDEX(SUBSTRING_INDEX(`data`,' ',31),' ',-31), ' ', SUBSTRING_INDEX(SUBSTRING_INDEX(`data`,' ',56),' ',-56+34), ' 0 0 0 ', SUBSTRING_INDEX(SUBSTRING_INDEX(`data`,' ',64),' ',-64+56), ' ') WHERE SUBSTRING_INDEX(data,' ',64) = data AND SUBSTRING_INDEX(data,' ',64-1) <> data; UPDATE `item_instance` SET `data` = CONCAT( SUBSTRING_INDEX(SUBSTRING_INDEX(`data`,' ',31),' ',-31), ' ', SUBSTRING_INDEX(SUBSTRING_INDEX(`data`,' ',56),' ',-56+34), ' 0 0 0 ', SUBSTRING_INDEX(SUBSTRING_INDEX(`data`,' ',138),' ',-138+56), ' ') WHERE SUBSTRING_INDEX(data,' ',138) = data AND SUBSTRING_INDEX(data,' ',138-1) <> data; This will destroy existing socket #2 contents though (replacing them with old socket #2 contents that are in socket #3 wrongly) and may do some damage to enchant #12. Backup before testing, worked for me.

Config: # vmap.ignoreSpellIds # These spells are ignored for LoS calculation # List of ids with delimiter ','

Don't really think it'll help much if MySQL server is connected directly (i.e. via Unix socket). MySQL row cache does its job well. If MySQL server is connected via network though, it's another story.

There are almost no issues with LAA apps, there can be some issues with kernel/hardware, though they are rare to be seen. One of them is VSS issue on W2K3 servers.

There is one major issue though... multithreading cannot be split between physical servers

Yes, I will preferably back out from discussing another name for way of optimizing IPC from sockets to shm inside one application ('collocated servants', for short term). Coding paradigms need to be changed for CORBA, and rewriting all application from scratch seems unnecessary in MaNGOS case (we already have all processing we need implemented, and can split it without too many consequences). We can mitigate single-server drawbacks using packet handler fucntions and/or some OS-specific IPC (ACE framework can probably help us there a bit) for single-server thread/daughter process communication, because packets pass 'proxy' unchanged. Only some system commands may be inserted into stream, nothing more. I agree that there may be multiple 'supervisors'. But they can severely conflict on database level and will need broadcast communication and tight syncing implementation of can easily overcome all benefits. It's (IMO again) better to create fast packet distribution pipe that can handle great load (multithreading proxy is a way to go, too, we don't need to multiprocess proxy) which distributes packets to resource-hungry map servers that are now and will be the main bottleneck. Explaining simply: network operation is not the primary bottleneck, we can live with only multithreading here. As far as I know (may be mistaken), bl*zz realm servers use one IP for client income, and multiple map servers thereafter. Why not do it the same way? It's a pity I did not have time enough to work on the subject and still have no results to present for comparison.

First, short lines about AWE/PAE/3GB discussion. a) PAE enables system to address more than 4Gb of physical memory using CPU VMM page table extensions. It does not enable single processes to address more than 4Gb of RAM easily because pointers stay 32-bit. But multiple processes can, because each process has 'its own' 4Gb address space. b) 2GB ms limitation is because they split 4Gb process address space into 'process' 2Gb and 'system' 2Gb where kernel/drivers/hardware address spaces reside. /3GB key changes that split into 3Gb+1Gb, allowing more 'process' address space (3Gb) but shrinking system address space which in conjunction with ms resource bloatness can potentially cause a number of problems. Linux has 3Gb/1Gb split by default and more efficient system resources management. c) AWE is like EMM for DOS. You define paging address space and then 'page' additional memory into that address space in your software. Good for large granular blocks of data, but totally useless with random allocation. MaNGOS uses second. The only real uses for AWE I see are multimedia applications operating with huge granular blocks and SQL servers operating with huge granular tables/indexes. Nothing else. --- Then, about multithreading/multiprocessing. Multithreading is on the way (mtmaps), and multiprocessing was considered some times but stalled at the concept level. Personally, I opt-in for multiprocessing+multithreading. Let me elaborate: a) There are NO real reasons not to combine. MTMaps are on the way and this IS multithreading. There is no reason to stop developing MTMaps because we can then utilize it even in multiprocess server. b) Multiprocess server will offer more scalability and stability. As mentioned, when one map process dies, others keep working. We can even make core process to make users wait until died process restarts without disconnecting, only messaging them about the case and then teleport them to the DB-stored location when process restarts, just like they've entered world again. c) I see multiprocessing at the map level. One supervisor process maintains all user connections, chats and group/guild interactions (and some more inter-process things), passing this connections to the final map servers along with some internal commands (like: give me state for the player X for storing; or: load this player data and create him on the map). All character DB interaction must be kept in this supervisor process to avoid conflicts. Spawn tables and some other map-dependent tables will have to be split to map-based tables as well to avoid process conflicts. d) One map server can handle MORE than one map. This is where multithreading will have its way to go. On a single system, you can (as example) create three continent map servers, where first is multithreading az*roth with its instances, second multithread k*limdor with its instances and third multithread outl*nd/northr*nd and their instances. Or even single server multithreading all of that if you want the 'old' scheme. This is the combined multiprocessing/multithreading I mentioned. e) IMO, with the aforementioned way, no standard solutions (I presume) like CORBA/TAO can currently be used in MaNGOS multiprocessing. They will require a completely different framework and rewrite of the entire system. I see multiprocessing at the network level, where player sockets end on the supervisor and then are proxied to map servers being extended with system commands. We will need to extend server protocol a bit, adding some system commands which exist only between supervisor and map servers. f) The protocol way is (not complete but gives understanding of my point of view): f1) Supervisor server receives i.e. guild entrance or chat command. Parses command data. Executes it. Answers all affected players with the result packets. There is nothing to be done at map server. f2) Supervisor server receives i.e. movement command. Parses command header. Passes it completely to the map server of the player in action. There is nothing specific to be done at supervisor. Map server answers player with all needed data. f3) Supervisor server receives i.e. group join command. Parses command data. Executes group operation. Sends player group data. Passes the command to the map server, because player locations (players see each other in group) must be sent too. Map server announces players with location data. f4) Supervisor detects player join. It loads a player, answers him with the initial state and teleport data. Then it creates a map server connection and passes map server a special system command of loading player along with the data (map server does not interact with chardb). Map server creates player on the map and passes him a location data (creatures, objects etc.). f5) Supervisor detects player leave. Performs group operations (possibly instructing map server to process some data too). Requests map server for a volatile save data for the player leaving. Saves into DB. Then commands map server to remove player from a map. f6) Supervisor wants to save player. Requests volatile data from map server. Saves into DB. f7) Map-to-map transition. Map server detects map-to-map transition and commands supervisor to transport character. Supervisor saves character, instructs source map server to remove player. Instructs target server to load player, the the target server sends all teleport/state commands needed. ... and so on. g) I still don't know if we want to have multiple connections per-player to map server, multiple connections per-thread to map server or a single connection. Single connection is probably not an option, because it will not allow for multithreading. Connection-per-network-thread is better, but will require severe supervisor-to-map-server protocol changes. Connections per player will allow to use client protocol with some tiny extensions, and is easier to code. I would opt for a per-player connections between supervisor and map servers at first and change it later if per-player becomes a bottleneck on the socket level. h) The drawback is clear: supervisor will have to be rock-solid stable, including all group/chat/guild/load-save/etc. operations, or else it will ruin all the connections. But these operations are not so complex in comparison with the grid/object/spell/aura management systems. We also can have a two-level supervisor. One is a mere proxy (connection supervisor) which simply stalls all the connections if the general supervisor is down and then passes all the connections to the newly-born general supervisor when it goes up. But with that scheme, the general supervisor will have to have some state-gather system to collect data from all the map servers in case it crashes.

Delete this post please, I'm late Thanks for fixing it BTW. It's a pity I'm still a newbie in the MaNGOS internals though