VladimirMangos

We already dom loops at any skill change and etc for spell learn unlearn, so maybe as alternative we can pre-build multimap <skill -> entries> as we do for spell listed in this dbc.

Skill have in dbc all possible classes that can learn skill. I will modify check to use this. [added]Implemented in more generic way in [8581]. Thank you for original version

Thanks for pointing to problem. Patch similar suggested by you has been applied as hotfix ( [8464] ) to master also in time apply related backported patches but not catched as need t backporting . Now [8464] also backported.

Fixed in [8567]. Thank you

This will be lot spam... and how this help? You can easy found all unsupported cases in spell.dbc data

And git_id tool do many more that jst add number to notes. 1) It also generate revison header for project itself 2) with special option can propertly rename and register in project sql updates with related makefile/.sql files update and generate another header for DB version data for loading check + add sql update order guards in sql update to prevent wrong apply order.

i use last msysgit 1.6.4 at win7 and not have like problem with update referecned branches Check that path to repo dir is not too long, not have spaces and non-latin characters.

I test and work for me: .npc changelevel #level and you wuill se diff size for diff level

If db version not have any problem then ofc betetr have it in db spell_bonus. If you want you can prepare another generic patch to move all referenced cases to db[added]Patch itself in [8514]. Thank you

It's not easy, but at least network/database code can be good help at start development some game support. Other partsl also but dependent from game type and expected game server work and required server side objects.

As i test this fixed already. In fact this problems has not be related to discussed spell

if this normal cast spell then maybe better use normla spell event proc triggering functionality. [added]Ok, i see problem with like way. So return to look at suggested by you version misc == 23 is wrong check. Exist many spells that have same (auratype=4,misc=23) combionation. [added2]With this fix added in [8512]. Thank you

In [8511]. Thank you

Patch not fully correct in check only 7997 misc. Infact 2 talent have dummy aura with this misc value. Also you have problem with break placement. Other priest healing spell will fall to paldin code with unexpected results. [added] With this fixes and some other changes in [8510]. Thank you

In [8509]. Thank you

In [8504]. Thank you

Must be fixed in [8503]

I worry or another spells that start receive bonus, as i understand this possible item spells... (i not look at list fro other side yet). [added] 374 spells including normal and items... Maybe we need allow apply only for spells with spellfamily for player clases (ignore 0 and potion family): 54 spells

1) where send call itself for prepared packet. 2) this good ask other to wide test, but originally better test by self maybe...

In stricted meaning protocol as set of packets with structure is well described by source code: For example client->server packet: /*0x10E*/ { "CMSG_SPLIT_ITEM", STATUS_LOGGEDIN, &WorldSession::HandleSplitItemOpcode }, Look in WorldSession::HandleSplitItemOpcode: void WorldSession::HandleSplitItemOpcode( WorldPacket & recv_data ) { //sLog.outDebug("WORLD: CMSG_SPLIT_ITEM"); uint8 srcbag, srcslot, dstbag, dstslot; uint32 count; recv_data >> srcbag >> srcslot >> dstbag >> dstslot >> count; So recieved packet include 5 fields and have (1+1+1+1+4 = 8 bytes size. Meaning of fields described by its names and later code that use its. In same function we see function calles for item operation errors reporting to client: _player->SendEquipError( EQUIP_ERR_ITEM_NOT_FOUND, NULL, NULL ); WorldPacket data( SMSG_INVENTORY_CHANGE_FAILURE, (msg == EQUIP_ERR_CANT_EQUIP_LEVEL_I ? 22 : 18) ); data << uint8(msg); if(msg) { data << uint64(pItem ? pItem->GetGUID() : 0); data << uint64(pItem2 ? pItem2->GetGUID() : 0); data << uint8(0); // not 0 there... if(msg == EQUIP_ERR_CANT_EQUIP_LEVEL_I) { uint32 level = 0; if(pItem) if(ItemPrototype const* proto = pItem->GetProto()) level = proto->RequiredLevel; data << uint32(level); // new 2.4.0 } } GetSession()->SendPacket(&data); We can see that server->client packet SMSG_INVENTORY_CHANGE_FAILURE have 1 byte field `msg` with error type and additional fields if not ok case and additional fields if not ok case ( EQUIP_ERR_OK = 0, 2 possible affected item guids, then _unknown_ 1 byte field and morefields for EQUIP_ERR_CANT_EQUIP_LEVEL_I case

Many problems fixed in [8497]. This problem affect any self heal. Not fixed yet. [added]With aura 57975... you sure that this must be affected? Currently this is prevented by: Maybe instead must be not applied only possitive cases...

We not follow it and it mostly useless for C++ from my point. You can read http://wiki.github.com/mangos/mangos/codingstandards

I confirm existance some problems but mostly result more generic problems with area auras, specailly with hostile area auras that similar expected way work with discussed talent (not applied to caster (beacon)). Not finish yet resolve its... [added]I resolve first problem that strongly connected with 2 icon show and problwms with apply hostily area auras to enemy with casted own same hostily area aura. But i now see that in original patch has been more correct set dummy aura caster to original caster. Without this at some player will not apply 2 auras from2 near beacons. I will fix this first and retest my fixes to (1) problem.

0.12 branch isn't like normal software stable branch, it more like branch for old OS version after switch main development to new OS version support. It continue developement in terams backporting fetures. If some not client specific feature implemented why not add its support to another client supporting version? In general most stable version for mangos is mangos release that mostly done before support switch to another client. Just update only from release to release. But i know, you want more working features no, not half year later But what you expect in like case? Also just fixes apply, but for example spell crash at cast can required backporting some new writed framwork for some spell types that it self ofc have chance adding another bugs... Providing as examples normal desctop application incorrect: online game server work is event driven mostly - some event triggering code that can set another triggers (like auras, object in world, etc) that can triggred with some delay with infinity possible combinations. And this event dependent from code but also from DBC/DB data that we not control fully and impossible checks at 100% at loading. We have many checks for avoid problems but most crashes related to infinity event trigering sequences or triggering events from object list processing with in result modify this list by inderect called another event code... this impossible solve in generic (at least without make code really slow).

And where authors listed? I must note that this _very_ unacceptable way not explicitly list real authors of patch. In any case suggested patch not fully correct as i think Correct spell work as i think: for 3.1.3 53563 casted at target and this is single target spell. This spell cast 60 yards wide area cast 53651 to around group members with apply dummy aura 53651 (with caster = beacon target). When friendly unit get healed it search this dummy at self and prepare heal caster of 53651 (beacon target) Before cast heal 53654 it check that target have 53563 aura and caster of 53563 is original healer for 3.2.0 Instead dummy 53563 spell is periodic (2 sec) triggering aura and not required dummy part. Other not changed With this changes add to [8492].