Schmoozerd

In 11850. THank you

nope - zps solution is correct

~SELECT_FLAG_IN_MELEE is something different than SELECT_FLAG_NOT_IN_MELEE

why cleaning?

This was a suggested feature - no patch that could be rejected or accepted - hence it is still valid, and might be interesting.

From current view this generic NOT support did not come through, mainly because for many conditons a NOT would be "stupid" - and for others direct not-x conditons where already added since this patch was created.

So - in continuouity of this style - it is likely to add individual non-x conditions if required.

Pretty sure this was fixed in 11818

[11818] update creature's unit part(update spell events, auras, movem…

…ent) while in death. thanks to rsa for making tests

this allows us update creature's death persistent auras, fall died creatures in natural, non hacky way

also fix the bug that creature starts waypoint movement not from begining at respawning. thanks to Grz3s for reporting

Thank you anyways

Edit: Just saw that there are two spell fixes also in your patch, can you give some comments about them please?

It is not perfectly clear if the tested 25% are as a result of testing with skill-level 400 against bosses (would be exactly the 25% with formula), or if these 25% are a real cap, also obtained with lower skill.

hey, angeleyes - as you seem to have access to retail, can you check how many glancing blows you get if you use a weapon with skill << 400 (say 300-350 at most)?

Such information is required as proof of a generic cap at 25% or at 40%

probably combined with some mangos addon.

His observation "crash on login" cannot be explained by invalid chat commands - even if the crash log points to chat commands.

Revert to master.

Though I just noticed that in master we still have the cap to 40%, not sure if this should not be decreased to 25%..

actually no.

The patch located in ScriptDev2/patches is only important for cmake configurations.

ScriptDev2 for TBC is maintained at an own repository these days: github.com/mangos-one/scriptdev2.git

Hmm, indeed nice that this topic came up

Looks like the patch from griffonheart (ofc needs some tuning) is far superior to the stuff made after.

Ofc need to look into details, and check a few things, but this looks very promising.

Thank you very much sart for confirming this!

you can take a look at

https://github.com/wow4you/mangos/commit/4311dc670b045ec52e92da1642c0d29d10e1f955 (authors go over a bunch of people, I don't know the trace of this patch to the version I used for custom purpose, likely history can be found in the old eye of acherus thread.)

There are a bunch of changes related to the eye of acherus (main motivation).

At least should tell you which places for spell 51852, Effect SUMMON, SummonProperties 65

Your analysis of the situation infact is correct

Now to the problems about this patch:

- research problem: "switch(prop_id)" Why aren't all SUMMON_PROP_GROUP_CONTROLLABLE handled with similar things?

- implementation problems:

* summon->LockAI(true); <-- this is kind of a hack, infact what we require is that sometimes a controlled npc "keeps" his own AI, and usually it won't

This requires both research and better ideas of implementation

* m_caster->CastSpell(summon, 530, true); <-- this is a clear hack, the spell 530 is not used related to eye of acherus;

However it might still be possible to do so, as it might be more convenient to handle all the MC stuff with one spell, than to do the required steps manually

Also alternate ways of implementation are always interesting

Edit:

Quality of this patch: It doesn't work proper and it is not written proper.

(a final check would be if you are able to fly the eye, or need to jump before able to fly)

I guess sart refered to

00441ED9 00000000 ??4BarGoLink@@QAEAAV0@ABV0@@Z+2089

009DF599 00000000 ?SetOutputState@BarGoLink@@SAX_N@Z+C29

Which yields an error in BarGoLink (how could there be?).

Afaik BarGoLink (the loading bars on startup) are only invoked when starting the server or reloading a table.

No idea how a crash dump after days of uptime could have this crash-log.

Probably nothing to worry about and just some overflow related to console, mysql or some ram requirements or similar related to the long uptime.

maybe problems related to writing rights in the used directories, not really sure.

Just tested myself on VC90 ReleaseWin32 and I had no problems.

sure, ofc blizz uses auras, the question only is which auras.

Just to understand you, you are refering to npc 37697 ?

And spells 70457, 70447, 70459?

Hi all,

this is a small suggestion about a possibility for mobts to fixate a target.

Any opinions are welcome.

Examples where this might be needed are:

AQ40:: Battleguard Saturia

BT: Supremus

Likely there exists a bunch of other cases as well, where an npc should focos on one enemy for some spell duration, maybe Zul'Jin - Claw Rage

These cases also throw the question, if we need an automated system to remove a fixation after some time

From 83881cf2bc1b5a67ce7979909f6fb5139f4338d6 Mon Sep 17 00:00:00 2001
From: Schmoozerd <[email protected]>
Date: Sat, 12 Nov 2011 23:00:36 +0100
Subject: [PATCH] Add Unit::FixateTarget

This allows to fixate a target (as long as it is valid) independend from threat or taunt auras.
If required maybe adding a time argument to automatically remove the fixation can be reasonable.

Signed-off-by: Schmoozerd <[email protected]>
---
src/game/Unit.cpp |   31 +++++++++++++++++++++++++++----
src/game/Unit.h   |    3 +++
2 files changed, 30 insertions(+), 4 deletions(-)

diff --git a/src/game/Unit.cpp b/src/game/Unit.cpp
index 71e5685..b732469 100644
--- a/src/game/Unit.cpp
+++ b/src/game/Unit.cpp
@@ -8570,6 +8570,8 @@ void Unit::TauntFadeOut(Unit *taunter)

    if (m_ThreatManager.isThreatListEmpty())
    {
+        m_fixateTargetGuid.Clear();
+
        if (((Creature*)this)->AI())
            ((Creature*)this)->AI()->EnterEvadeMode();

@@ -8595,6 +8597,19 @@ void Unit::TauntFadeOut(Unit *taunter)
}

//======================================================================
+/// if pVictim is given, the npc will fixate onto pVictim, if NULL it will remove current fixation
+void Unit::FixateTarget(Unit* pVictim)
+{
+    if (!pVictim)                                           // Remove Fixation
+        m_fixateTargetGuid = ObjectGuid();
+    else if (pVictim->isTargetableForAttack())              // Apply Fixation
+        m_fixateTargetGuid = pVictim->GetObjectGuid();
+
+    // Start attacking the fixated target or the next proper one
+    SelectHostileTarget();
+}
+
+//======================================================================

bool Unit::IsSecondChoiceTarget(Unit* pTarget, bool checkThreatArea)
{
@@ -8626,10 +8641,17 @@ bool Unit::SelectHostileTarget()
    Unit* target = NULL;
    Unit* oldTarget = getVictim();

-    // First checking if we have some taunt on us
-    const AuraList& tauntAuras = GetAurasByType(SPELL_AURA_MOD_TAUNT);
-    if (!tauntAuras.empty())
+    // first check if we should fixate a target
+    if (m_fixateTargetGuid)
+    {
+        Unit* pFixateTarget = GetMap()->GetUnit(m_fixateTargetGuid);
+        if (pFixateTarget && pFixateTarget->isAlive() && !IsSecondChoiceTarget(pFixateTarget, true))
+            target = pFixateTarget;
+    }
+    // then checking if we have some taunt on us
+    if (!target)
    {
+        const AuraList& tauntAuras = GetAurasByType(SPELL_AURA_MOD_TAUNT);
        Unit* caster;

        // Find first available taunter target
@@ -8646,7 +8668,7 @@ bool Unit::SelectHostileTarget()
        }
    }

-    // No taunt aura or taunt aura caster is dead, standard target selection
+    // No valid fixate target, taunt aura or taunt aura caster is dead, standard target selection
    if (!target && !m_ThreatManager.isThreatListEmpty())
        target = m_ThreatManager.getHostileTarget();

@@ -8679,6 +8701,7 @@ bool Unit::SelectHostileTarget()
    }

    // enter in evade mode in other case
+    m_fixateTargetGuid.Clear();
    ((Creature*)this)->AI()->EnterEvadeMode();

    if (InstanceData* mapInstance = GetInstanceData())
diff --git a/src/game/Unit.h b/src/game/Unit.h
index 7e742e8..2d6a0b7 100644
--- a/src/game/Unit.h
+++ b/src/game/Unit.h
@@ -1673,6 +1673,7 @@ class MANGOS_DLL_SPEC Unit : public WorldObject
        bool SelectHostileTarget();
        void TauntApply(Unit* pVictim);
        void TauntFadeOut(Unit *taunter);
+        void FixateTarget(Unit* pVictim);
        ThreatManager& getThreatManager() { return m_ThreatManager; }
        ThreatManager const& getThreatManager() const { return m_ThreatManager; }
        void addHatedBy(HostileReference* pHostileReference) { m_HostileRefManager.insertFirst(pHostileReference); };
@@ -1996,6 +1997,8 @@ class MANGOS_DLL_SPEC Unit : public WorldObject

        ObjectGuid m_TotemSlot[MAX_TOTEM_SLOT];

+        ObjectGuid m_fixateTargetGuid;                      //< Stores the Guid of a fixated target
+
    private:                                                // Error traps for some wrong args using
        // this will catch and prevent build for any cases when all optional args skipped and instead triggered used non boolean type
        // no bodies expected for this declarations
-- 
1.7.6.msysgit.0

More thoughts:

RElated to discussion http://udb.no-ip.org/index.php/topic,12817.0.html we crossed this patch again.

Main reason why I still don't like this way the same as in my first note: it tends to break style.

Also there is another reason: currently the options are parsable from sniff (ofc not script ids and conditions), so with this option there would be a new cathegory of custom entries in a place with official entries.

crackm had the idea to change the sql-key fo `gossip_menu` so that multiple scriptIDs could be added to gossip_menu (if required) - with different conditions.

This looks more logical to me, but I am not yet sure of best ways to extend this key -- opinions would be appreciated

Edit: Some untested code - http://paste2.org/p/1776398 (sql-changes missing)

No, the old GetGUID value is the uint64 value, and corresponds to GetObjectGuid().GetRaw()

But I think it is better to replace the uint64 values used in the custom patch with ObjectGuid values.

In [11845] Thank you

in [11844]. Thank you.

1>..\\ScriptMgr.cpp(103): error C2065: 'barGoLink' : undeclared identifier

1>..\\ScriptMgr.cpp(103): error C2146: syntax error : missing ';' before identifier 'bar'

1>..\\ScriptMgr.cpp(103): error C3861: 'bar': identifier not found

1>..\\ScriptMgr.cpp(104): error C2065: 'bar' : undeclared identifier

1>..\\ScriptMgr.cpp(104): error C2228: left of '.step' must have class/struct/union

1> type is ''unknown-type''

hmm, these are very very old compile errors, do you still use SVN to get SD2?

If so, probably I missed a guide when updating them.

SD2 installation instructions can be seen on SD2 forums; the git address is git://github.com/scriptdev2/scriptdev2.git

hmm

* compile mangos before compile scriptdev2

* compile BOTH on the same configuration, ie Win32 Release

* Start the VC GUIs proper:

Use a doubleclik onto mangosdVC100.sln located in the subdir "win"

Use a doubleclick onto scriptVC100.sln located in the main SD2-directory: "ScriptDev2"

Thank you very much for this summary post.

You didn't add any installation/ "where is the patch" instructuctions, I think a post to post1 of the mmaps redux thread will be fine

As I can see the patch is about 150k lines, I won't read this till tomorrow

So, infact I directly jumped to the step for 'future work'

* Offmesh connections

Well, this is stuff no project (db, core, scripting) handles yet, so without any other good points I guess we can keep this as part of the mangos project directly, with the goal that reasonable 'custom' corrections can be "reviewed", and maybe shipped with a default_offmesh.txt file. (Probably at least in the beginning you and qsa will have biggest word on mainting this file's content)

Do I understand correctly? If it is changed it will require some time-consuming rebuilding?

In this case I would agree that some more dynamic approach for this would be nice to have, but still candy.

* Aggro system

I think I will push something like http://paste2.org/p/1400454 (take just as basis) 'soon', most interesting might be the function currently named IsSecondChoiceTarget - dunno if not maybe this should be moved to unit class, and also be used for taunters.

Would then likely also be a place where we could add the reachable-path-exists check.

Opinion would be appreciated.

This also might remove the pressure to remove the unreachable units from the threat list, but would simply order them to lower priority

* Evade

Well, it seems from many sources that our current implementation (evade on range) should be replaced with (evade after timelimit without action) anyways, so this might then be a huge simplification anyways.

- Removed link to client picture, they are not allowed here.

- @Topic: This is (by now) a database problem, crackm mentioned on udb forums that he has proper dataz which will be included in next udb update pack.

I suggest patience until this one will be released

This thread should give a small overview, which major points are to be implemented in the near and not so near future.

If a feature is listed here, this does not mean, that it can be expected that it will be implemented anytime soon.

This should just be a rough roadmap, to collect the following:

- Some larger scale development goals

- Hints of cool features which are in development

- Important things that don't get the attention they deserve

==== Features for next milestone ====

* Dungeon Finder

==== Features in development ====

* Mmaps - was added to core

* Warden system

* Rewrite MovementHandling, especially due to limitations of MotionMaster

* Outdoor objective-based PvP

==== Wanted Features ====

* Vehicles (some patch development by community exists)

* NPCs on transports

* Aura stacking rewrite

* Better Pet Support

* Missing BGs, missing Arenas

* Add gameobject support to vmaps

==== Features open to discussion ====

* Hooks for Scripting Library for spells

Points that can be discussed

Ofc, things that are important and are missing here

Maybe we want to add User who show serious development interest to the topics they work with, maybe add links to development threads - which opinions do you have.

This thread is NOT to complain about missing spells, or crying about a single class and similar, for such things form _proper_ bug report for every _single_ bug in the appropriate forum

you _must_ use the guid format that is expected to be sent by the client.

If you chose the wrong one, the client will either crash (most likely) or produce total crap..

Edit: To be clear: This is a choice that was made by blizzard developers, and if you want to talk to the client, you must use the 'language' the client understands. This is nothing where you can chose.