Schmoozerd

yes indeed. But not time yet - but will adress this; Actually I do think this is very valuable contribution

Part without cleaaup in [11860]. Thank you (One backport will come soonish I think) @Stfx please move to accepted when backported (as originally intended for one I think this is proper)

If you want to learn about Git, there is here a subforum dedicated to source-code-management. Also at SD2 forums there are a couple of guides related to the use of git. Also as part of the icc learning project I wrote some introduction to git.

I know that the data blobs from the characters table were removed some time ago - commit d65cf5b9f99 As far as I know loading a blob field from the database is also faster than loading many fields. So I think removing the blob from item can be reasonable if you manage to drop some of the fields

both databases have their good and not so good sides. Both contain acid in recent version. Take one, some other day test another, make up your mind yourself

@michalpolko I think not, ModThreat(victim, -100) sets aggro to 0, does not remove from threat-list. yes, DoResetThreat resets threat for all enemies to 0, does not clear the threat list - and it is part of ScriptedAI

acid is incluced with UDB. scriptdev2 requires an own database, and will be required for bosses to work proper (like text-ids, waypoints and similar)

I suggest to use the UDB 0.12 full release from https://unifieddb.svn.sourceforge.net/svnroot/unifieddb/trunk/Full_DB/ and then install the corepatches and updatepack from udb _403_ from https://unifieddb.svn.sourceforge.net/svnroot/unifieddb/trunk/Updates/0.12.2_additions/ then install the remaining few mangos core updates When an error happens, stop, and post

ensure that the directory in which you placed mangos (and ScriptDev2 in <mangos>/src/bindings/ScriptDev2 ) has entirely asci pathname. No accents, no spaces, nothing fancy there - don't ask me if this a problem of us, or MS, but weird pathnames often tend to not work.

you should look for gmdb http://www.gmdb-forum.de/

Try to use DELETE .. WHERE id=..; INSERT INTO .. (..) VALUES (..); might be related that there is no key to this table - no idea else.

Must be fixed in [11857]. If further problems remain, I would suggest to refer to database providers

I just tested my recent patch version: http://paste2.org/p/1811385 and I didn't notice problems on priests, warlocks, druids

no UnkleNuke - these two patches are of entirely different things. This patch is about spawning npcs depending on dynamic data (like player team). Xfurry's patch is about informing the instance script when a mob is summoned. The main problem I have with this patch is, that this would require some agreements on custom event-Ids between database and scripting project. The big advantage of world-database depending spawning is that it would be possible to add waypoints by guid, auras by guid, and maybe some even more fancy stuff that database can do. For discussion purposes, I had as idea to implement a neat summoning framework on sd2 side: A table with npc_entry, id, point_id, postion which could be used to summon npcs - and with some core support to pass over waypoint movement from this table (point_id > 0) to the summoned npc. Team-Dependend summoning would then just mean that the npc-entry will be overwritten by some alternate entry.

first would be to look into unit-flags, type-flags and similar of official information that is shipped with creature_template. If this all fails, you could implement a new flag_extra.

diff --git a/src/game/NPCHandler.cpp b/src/game/NPCHandler.cpp index db7b035..d2b9a0c 100644 --- a/src/game/NPCHandler.cpp +++ b/src/game/NPCHandler.cpp @@ -131,7 +131,7 @@ static void SendTrainerSpellHelper(WorldPacket& data, TrainerSpell const* tSpell data << uint32(primary_prof_first_rank && can_learn_primary_prof ? 1 : 0); // primary prof. learn confirmation dialog data << uint32(primary_prof_first_rank ? 1 : 0); // must be equal prev. field to have learn button in enabled state - data << uint8(skillReqLevel ? skillReqLevel : tSpell->reqLevel); + data << uint8(std::max(skillReqLevel, tSpell->reqLevel)); data << uint32(tSpell->reqSkill); data << uint32(tSpell->reqSkillValue); data << uint32(!tSpell->IsCastable() && chain_node ? (chain_node->prev ? chain_node->prev : chain_node->req) : 0); Seems to be an improvement for druid trainers. Not yet checked for other cases.

There is probably some core problem related, the problem is that I only know that druids can be used for mounts or other hairy desires. So: Can you please give spell-ids of spells that are taught on wrong level, and which requirements they should have, and how they should be obtained (for proper testing)

well, dummy effects that hit creatures can be scripted with SD2 (if they would depend on more complicated states, like instance data) ScriptEffect spells can be added to database scripting (which doesn't always work, because they often have random effects, or some conditions) But regardless of where dummy/script effects should be implemented (database, sd2, core, new-scripting-system), the main problem that is really slowing down, is to know _what_ must be implemented. Hence I see no big reason to create a new system to implement them easier, when the only problem is to know what to implement. Creating some additional hooks for SD2 to be able to "script" target-selection, effects, and similar is indeed open to discussion. However an easy interface to implement unique things might slow down the process of figuring generic solutions

I think with the functionality provided in [11785] this patch is no more required. So move to rejected. Thanks you!

It didn't feel good I don't know the general spell casting code too well, hence I cannot exclude that there are better ways to do what must be done. Hence I hesitate.

in 11855. Thank you

should be identical in backported I think.

I finished my tests, and I would be ready to push this version: http://paste2.org/p/1802589 Would be nice if you could say if you see this as sufficient from your needs as DB guy Edit: Pushed my version to [11852], thank you for bringing up this topic!

Part except the spell casting on invisibility aura removal in [11851], Thank you!

well - this one was pretty clear that would be added fast - zps researched a strong case where he needed it - and the code is very clear. It is just annoying to have simple and reasonable patches waiting for a long time.