Schmoozerd

nope, bug still [11499] exists, just checked with my stated "Way to reproduce"

Updated to V5 (fix issues - add prevent respawning) Changes: - Fix logic bug (somehow in one of my rebases I moved the adding of npcs to my holder to some invalid place) - Fix some minor issue with not used cache variable * Add support for preventing respawning depening on boss Alive or boss Dead * Retested stuff So in my view, the state is: - Finished in the sense that all I thought of is implemented - Following is unfinished to the notes above (but could be completely removed ofc) - Some issues like checking for static spawndata with multiple DB-queries might be to be improved, dunno currently how to handle this best

/mg/src/bindings/ScriptDev2/ScriptMgr.cpp:379 I assume this line is "Script *tmpscript = m_scripts[pItem->GetProto()->ScriptId];" ? but actually I cannot see why this could crash at all.

"git log" is the easiest way to obtain your revision of your source-tree and SD2 is at rev 2111 and on Git, see SD2 forums about this. Some of these old guides here in the forum are simply outdated. btw, it might have been helpfull to actually look into the svn log of the latest commit:

no, the guide is outdated, as stated in first post, you should look into the wiki guide: http://getmangos.eu/wiki/Compile_MaNGOS_On_Linux Example: Youe SD2 is > 100 revisions behind

no, actually this sounds like you didn't install ScriptDev2 or didn't install it proper vehicles are not working which is obviously a known "Not Yet Implemented" feature. For the rest, only report detailed and individual bugs, if core bug at core forum, if DB bug at DB forum, and if scripting bug at scripting forum

it is impossible to reconstruct 3d coordinates from a 2d projection of them; assume you have some terrain where you have different possible hight-levels for spawning, for such cases it is impossible to know which hight-level to select for the third coordinate

Updated to V4 (use ObjectGuid and remove hungarian notation) About following I am not sure if possible not remove this in total (at least for now), as it seems to hard to figure a neat way of generic behaviour. So I guess I will try to pick myself some time this weekend, to implement the depending (re)spawning (preventing, allowing), and then try to discuss this patch with any core devs who volonteers (that is, doesn't hide fast enough)

add if (...) pet->Unsummon(...); else m_guardianPets.erase(m_guardianPets.begin()); should be the easiest

yes, really, adding MANGOS_DLL_EXPORT in front of a class you for some reason need is really way too much effort There are legal reasons why scripting library is not included in mangos (as well as a content db) There are working reasons why scripting is not included in mangos (different team-members - different knowledge) There is no reason to change a fine(1) working system for something entirely useless. (1) actually I am sure there can be made improvements in "syntax" or "style", but like most progress, it is about improving existing things, and not replacing..

have you tried to cast the spell by spore with original caster loatheb?

this won't happen. If you need new hooks, you can add them now as good as with any system currently out-there in use

remark that numbers are numbers, so 793 (decimal) == 1100011001 (dual) == 319(hex) [ 0x319] == 13.13 (babylonian) == 2.12.11 (17) so possible you will see in dbcs only decimal values, then you need to translate them for yourself to whatever format you need

yes, then I think I probably did understand you wrong, and you actually suggested, what I already put some thoughts to Though there are very serious problems how to handle hunter or caster mobs (likely they just ignore being rooted) - and this is a problem for many many mobs, and yet no good idea for this..

I hope I finally got around the target selection correctly.. This patch I think is quite good at the actual needed changes to support prefering melee-targets, however this patch is extremely week regarding _which_ mobs should do so. This needs more ideas and more work to get it done nicely Edit: Fresh version http://paste2.org/p/1400454 Notes about this patch: * IsCombatStationary() equals "should prefer melee targets" -- IsCombatStationary is just a basic check, but should be alright for nearly all cases I think -- There are serious problems with such a simple function, currently I don't know how to handle this best. * Unit::SelectHostileTarget -- Remove special handling for first taunter, but perhaps I didn't understand the reason for it, in this case this part needs to reverted, and the first taunter needs the additional check ... caster->isAlive() && !IsCombatStationary() || CanReachWithMeleeAttack(caster) ) -- Add range check in case the mob needs it * ThreatContainer::selectNextVictim -- Fix a bug that in case the previous target is second-choice target and last in threat list - in this case it was not removed from threat comparision -- Fix a bug preventing to select valid targets due to the 1.3 and 1.1 threat rules but previous target is now invalid -- Fix a bug discarding valid targets due to threat rules, but previous target is invalid (and has lower threat) -- Hopefully improve code readability (especially the ifs with many || or && -- If we need to prefer melee Targets, every ranged target is a second-choice target in the selection, this way - if possible any melee target will be preferred; Remark that there is no order of second-choice target, so a ranged target is equally second choice for a stationary mob as an ie immune target, I think this is good enough for all real cases Edit: Hmm, you are saying that: normal moving mobs _should_ attack enemies in melee range, without switching whom they are chasing?

then probably the spell you are talking about must use unMaxTargets in spell.cpp

I don't really understand which textes you suggest to actually translate - error/ debug output log shouldn't be translated in my view, because everyone needs to easily understand it, and output to client is handled by DB-localization already

double check without any addons, some of them influence target-selection

small note I crossed when thinking about the sd2-changes: Should this spell have impact onto pets?

yes, and as I am aware of this, I added the needed framework in my post, feel free to use the round ball with phunny ears floating around a bit higher than your chest - this is usally the best way to get something done. ofc it is possible that there are other and better ways than the one I thought of, but I think I understood enough of the aura-trigger spell problem, to suggest reasonable changes that will be helpfull for many cases. well, the spell-triggering aura should know onto whom to cast the missiles, hence we need to get the target for arcane missiles, this has nothing to do with simple/ complicated, but this is the purpose of the spell (sending missiles from caster onto target of arcane missiles) - ofc if you don't want to care about this .. Btw, you could edit your subject, because this is a bug of mangos master, too, and you can take the spell-ids I posted, to give a proper bug-report Edit: Just looked at arcane missile spell again, and from the spell (42846) I think we must use some unexpected code somewhere already..

no, in my opinion entirely wrong way.. in player's case the spell for arcane missile (42846 - triggered spell = 42845) in void Aura::TriggerSpell() the triggered spell is cast with triggerTarget->CastSpell(triggerTarget, triggeredSpellInfo, true, NULL, this, casterGUID); which needs to be replaced in this case. So, way to go here I think will be: i) Make Aura::TriggerSpell a bit more clear to support "triggeredCaster->CastSpell(triggeredTarget .." ii) Add a way to handle all player arcane missiles into one place (possible one of these (for me) mysterious spell masks iii) support the dummy aura to add "lastArcaneMissileTarget" to Player on apply and clear on remove iv) use triggeredCaster = aura.caster and triggeredTarget = aura.caster.GetArcaneMissileTarget();

If memory servers, there are two types of arcane missile targeting systems: 1) For player cast arcane missiles: Dummy Aura on Target, Channeled spell on player then the channeled spell must cast his arcane missiles every channeled-tick onto his target with dummy aura 2) for npc cast arcane missiles - example http://www.wowhead.com/spell=15790 Periodic Tick Aura on Target, this periodic tick must cast the spells from caster onto target (and not like usual periodic tick from target onto target)

Fresh version http://paste2.org/p/1376086 <- added some ideas of NoFantasy - made some code similar to PLAY_MOVIE Untested

actually the best way of learnign is to do things yourself afaik mmaps work with nealry the same code on one and zero, as the vmaps are (now) the same structure, and mmaps are desinges good enough! About original topic: Well, we all want the devs to give final answers about questions/ patches; and so these answers take ofc quite some time. So I think everybody must set his priorities: does he prefer a good answer over a fast answer or nor..

delete WDB cache ah yes, and most fun changes need a core restart!