Schmoozerd

And there are a lot of FAQ threads around here in the forum

if you are worrying about broken spells for the chess event, this here is the right place to ask. if you are worriying about the script details, you should go to scriptdev2.com Btw, I don't think that anyone yet has a good script for it, the needed camera system is quite new, and the task rather complex - and what is more important, rather without examples - so good luck scripting it.

Vladimir was so kind to include new binaries with rev 10191

you always can compile the extractor files yourself with your VC version, then it should work at all

I read the shortened Topic [fix] Documentation .. And was so hoping that this would mean an actual docu fix for source

yes, cannot reproduce this bug any more - thanks Laise also the strange things about aggro of the MCed mob are gone, looks very good to me

well, I think whether SD2 script or EventAI script is easier to read this is really just the question how much one is used to it. But coding the ~4000-5000 mobs that are done with Acid in SD2 - good luck for readability and maintaining these scripts

sounds reasonable, but perhaps you should think about directly providing support for conditions, and not only m/f There are enough free fields, but perhaps it would be more convenient to move momentarily datalong2 (src-target flag) to dataflags and use datalong2, 3 and 4 for condition entries - taken from source/target depending on flags, or with hardcoded: try target before source or similar

I just tested MindControl with Rev 10155 (just before the aura changes) and couldn't reproduce the crash. I also tested with Rev 10156 and it crashed (logs like already in the thread here)

you are very welcome (at least I suspect you are the first who really did test this code) And in my next version your linux-compile notes will be inside, so I think this was worth it - atm the remaining problem is to know what is really needed... And after this is done, remove the GO hacks and review for all the things I don't understand of C++

Rev 10188 even with your patch, it crashes on MC-expire, crash-log like before Edit: Just tested with Debug_NoPCH, same crash Just noted: with .gm on I just got http://paste2.org/p/913636 as crash (slightly different)

yes, seems that VC is sloppy there, thank you; - then it compiles fine on linux? (also with the commented parts?)

sorry, took a little bit longer than exptected ;( Had to rearrange a few more (tiny) things; New (full) Version: http://paste2.org/p/913476 (perhaps you need for linux to uncomment the last two lines in SpawnSpecialManager.cpp, but I don't think so (as these explicit forms are called be the explicit Holders) Edit: might be faster for you: http://paste2.org/p/913489

uh oh, it is getting complicated, your way might compile, but won't work ingame (no specialization there for GetIdFlagGUIDMap, just give me 5min

hmm, I am not good with these templates, so I am not very sure of the right solution Possibility 1: Added to makefile? (perhaps stupid question..) Possibility 2: Add these 2 lines add end of SpawnSpecialManager.cpp. template void sSpawnSpecialGroup::AddToGroup<Creature>(uint32 DBGuid, uint32 Entry, uint64 GUID, uint16 flag); template void sSpawnSpecialGroup::AddToGroup<GameObject>(uint32 DBGuid, uint32 Entry, uint64 GUID, uint16 flag); If these then work, I will repost a freshly rebased version

because SD2 is used as a library, and hence the functions used by SD2 have to be exported MANGOS_DLL_DECL or similar (jsut compare class Creature with class Aura) however there should be no need to use the Aura class SD2

yes and no perhaps it was better to use some DB-based engine like rsa/sart does for SD2 scripts, and (re)simplify EventAI, but complex bosses will need C++ in 'any' way, so the least we can do is put some parts of the SD2 scripts into the DB, but never the whole script

Crash due MindControl Aura (of spell 605) on expire still present in _clean_ M Rev 10185 log http://paste2.org/p/912485 related function: // remove expired auras for (SpellAuraHolderMap::iterator iter = m_spellAuraHolders.begin(); iter != m_spellAuraHolders.end() { SpellAuraHolder *holder = iter->second; if (holder) { if (!(holder->IsPermanent() || holder->IsPassive()) ) { bool removedAura = false; for (int32 i = 0; i < MAX_EFFECT_INDEX; ++i) { if (Aura *aura = holder->GetAuraByEffectIndex(SpellEffectIndex(i))) { [color="Red"]if (!aura->GetAuraDuration())[/color] { RemoveSingleAuraFromSpellAuraHolder(holder, aura->GetEffIndex(), AURA_REMOVE_BY_EXPIRE); removedAura = true; } } } if (!removedAura) ++iter; else iter = m_spellAuraHolders.begin(); } else ++iter; } else ++iter; } that calls [color=RED] int32 GetAuraDuration() const { return m_duration; }[/color]

I think the most common case would be: in Los && inSpellRange and this would (I think) be needed for nearly all calls of SelectAttackingTarget. so it would be natural, to define this functor as a member of Creature. "CanTargetablWithSpell" but If someone then needs an additional Player Check, he has to define a new functor containing CanTargetablWithSpell && isPlayer(); this is more overhead than to just add the Player flag. Also the concept of flags is more natural if you think of EventAI - perhaps one or another Flag makes it into EventAI::CastFlags - if we have access by flags, it is 'just' passing the flags on, if we use (only) functor, we have to translate the CastFlags to functors before using them. As I said already: A functor-approach could be a valid enhancement for the Flags, (that is the flags using internally pre-defined functors), but I don't know if it was the right thing, to provide such a generic solution for something that will be only used a few times.

I don't think, that using a functor way is easier to read but you are right, it is more powerfull. perhaps this could be both be used (iE the SELECT_FLAGS defining a functor) but with the more powerfull possibility to directly say which targets shall be selected, you will open the doors to "hack", iE hardcoding MELEE_RANGE instead of using the spell-property

bump this, I did a bit research about timed Achievements, and I found out a few things: //uint32 unk1; // 28 Alway appears with timed events // for timed spells it is spell id for // timed kills it is creature id This description is not correct, there are _some_ achievements which have an entry in unk1 which has no relation to the killed Creature, any spell, item or quest I can think of, example: criteriaID, referredAchievement, requiredType, Field3, Field4, Field5, Filed6, Field7, Field8, name, nameFlags, completionFlag, groupFlag, CreatureOrSpellOrUnk, timeLimit, showOrder 12567, 4405, 0, 10184, 1, 0, 0, 0, 0, 'Onyxia', 16712190, 10, 1, 6601, 300, 1 That is unk1 = 6601 - if anybody has an idea. So, there are these types of timed criterias: Kill Creature, CreatureID -- unk1= creatureID BeSpellTarget, spellID -- unk1= SpellId UseItem, itemId -- unk1= ItemId CastSpell2, <likely spellId>, -- unk1 = Spell ID I think all these achievement types should _not_ reset (and would be 'fixed' if the code was changed) Quest, questId -- unk1 = QuestId These are three bomb-quests, I think this will need a new function to start this achievements progress on QuestAccept. and then there are achievements, which differ between CreatureOrSpellOR... and unk1. for these I only can think that they would be handled best with also an StartAchievementProgress function, which would for them be called on BG starting, on Creature-Aggro, on Creature Kill, etc.. at easiest with this unk1-data as param. However also for these achievements, I don't see any reason at all to reset the timers every Achievement Criteria +1 Update

ah, sr, wrong link: https://mangos.lighthouseapp.com/projects/18208/sending-patches Hm, I think I ll try to write down my usual workflow: <Start in a clean clone, branch master> git checkout -b NameOfTheGreatFeature <now I am on branch NameOfTheGreatFeature> <Hack in some Code> git status <show what I did> git add changedFile1 git add changedFile2 ... <or use commit -a to commit all changed (but not new) files> git commit [-a] -m "A short msg what I did" <Hack in even more Code> .. git status git add .. git commit [-a] -m "I did more!" ... <Oh, I missed some whitespace or a typo in my last commit> <change it> git add gile git commit --amend <Hm, there is a cool new feature submitted to origin, I want this!> git checkout master git pull git checkout NameOfTheGreatFeature <There are now two main ways to 'merge' my changes and master, merge and rebase> <rebase rewrites history, which might be good, if you haven't published your changes> <merge merges, which doesn't look so good, but keeps the history intact> git rebase [-i] master <or> git merge master <Edit conflicts> <Now you have your branch with recent src-base, and your feature, including your own history>

No, this system is not a substitution for scripts - and every in-combat action is to be scripted. I thought about perhaps a leader of a patrol respawning forcing his patrol adds respawning, or a elites who always have a few adds which respawn with them, etc

for me https://mangos.lighthouseapp.com/projects/18208/contributing-made-easy was very helpfull, and there are the nice vids and texts and http://book.git-scm.com/index.html Also something about the philosophy and why git is cool: there is a google tech talk by linus torvalds, which is worth a look (linked here in one of the git stickies)

I wouldn't merge the development branch into master, but rather keep master clean, and use a main custom branch for all the local changes. in this way, you can update your master always with "git pull" - without conflicts, and you have your custom code nicely separated. Updating your local branch is git checkout <local branch> git merge master or git rebase [-i] master (will put your patches on top, but might give more merge problems) if you do it interactive [-i] then you could also skip some of your old patches, what might be extremely usefull, if you know a corresponding solution was implemented to master but unfortunately there is no way to avoid merging problems ;(