Schmoozerd

In [11904]. Thank you

Thank you very much. Added in Revs 11901 to 11919

Also special thanks to qsa and all the other involved.

This is extremely great that mmaps are finally within MaNGOS, your work is very appreciated!

The patch from your post #15 I did not include, I think there will be some good input about *nix problems anyways, but it just is the time to get things rolling.

bump - before I forget about this.

Development sugestion: Check IsInEvadeMode while ticking - might be more natural instead of enabling the ooc-timer in OnAggro

Edit:

In [11901]. Thank you

The current system is about to secondize targets which have auras that would be removed by attacking.

This patch is about to ensure that a selected enemy is fixated.

This is required for some bosses - and possible blizz uses auras for this, but even auras would require an internal implementation

Reject this patch.

Spell 25648 is actually cast by the player, and not the npc, hence the GO is already summoned at the right position.

Thank you non-the-less

this would be a side effect of this patch (assuming it would be implemented proper)

currently in mangos it must be impossible to call used without user.

So if you fear there might be problems, check the calls

If in doubt a suggestion would be to use a MANGOS_ASSERT in this place

Reject this patch, as heavily outdated.

By now linked traps are expected to be spawned at same position as triggering GO, and hence will be found correctly when the triggering GO is triggered

Reject this for now. Thank you for the patch though!

All titles are obtained by quests or correspond achievements.

Hence I suggest to rather add a achievement condition (if not already present).

And ofc if a known example where this was required would be known, please share!

Pretty sure this is no more required, as of possibility to script these pets with SD2 ScriptedPetAI

Thank you for the patch!

Please repoke if I am mistaken

in [11898]. Thank you

Remark for all interested:

The changes must be continued, we need a way to prevent players to login into a different difficulty-mode

in [11897] Thank you

in [11896] Thank you guys

in [11895]. Thank you

A small special feature:

I think we should limit valid points for RandomMovement to consider the length of a created path.

Just noted on UDB that the images of bosses like 31584 have some pretty cool random movement in dalaran

yes - both of them are caused by a stupid copy/paste error, and are fixed in [11893].

Sorry for the inconvenience

ah, this would be a new feature from one of the last 3.x client patches?

I would guess before players were just teleported to graveyard

Thank you very much.

I still fail to compile vmap_extractor and assembler[Edit: Was told by Skirnir how to solve it], but the MMapGen is working now

But I fear this will be pretty complicated to fix, because the ace/config.h depends highly on the settings of how mangos is compiled, and hence might be around in different versions within different built-trees, but if no cmake genious will show up, I guess a small note in a readme.linux should do the trick.

(Generating mmaps on linux is fairly important I think, because this allows to recreate offmesh changes on-the-fly for a test-server)

in MaNGOS source you can look into DBCStructure.h (hope remember name right)

THere is the layout of the table spell.dbc listed.

and you can see if the collumn you are looking at can be negative or you viewed it wrongly

I rebased a little bit: https://github.com/Schmoozerd/mangos/commits/mmaps_rebase

(author information and commit messages are crap, but these are temporary commits)

I reextracted them on an older quad-core with 3 CPUs used for mmap-Gen, and it took about 2.5hours

So this is not too bad at all

For some tests you might go and just extract a few smaller maps in the beginning

In case anybody wants to do some last-minute tests ...

Edit: Maybe not so last minute:

On *nix I (and at least another person) cannot compile contrib/mmap. Fails with:

[  5%] Built target Detour
[ 12%] Built target Recast
[ 24%] Built target zlib
[ 91%] Built target g3dlite
[ 92%] Building CXX object CMakeFiles/vmap.dir/some/mangos/src/game/vmap/BIH.cpp.o
In file included from /some/mangos/contrib/mmap/../../dep/ACE_wrappers/ace/config-lite.h:24,
                from /some/mangos/contrib/mmap/../../dep/ACE_wrappers/ace/Basic_Types.h:46,
                from /some/mangos/contrib/mmap/../../src/framework/Platform/Define.h:24,
                from /some/mangos/src/game/vmap/BIH.h:26,
                from /some/mangos/src/game/vmap/BIH.cpp:19:
/some/mangos/contrib/mmap/../../dep/ACE_wrappers/ace/config-macros.h:28:26: error: ace/config.h: File or Directory not found
In file included from /some/mangos/contrib/mmap/../../dep/ACE_wrappers/ace/os_include/os_signal.h:217,
                from /some/mangos/contrib/mmap/../../dep/ACE_wrappers/ace/os_include/sys/os_wait.h:27,
                from /some/mangos/contrib/mmap/../../dep/ACE_wrappers/ace/os_include/os_stdlib.h:28,
                from /some/mangos/contrib/mmap/../../dep/ACE_wrappers/ace/Basic_Types.h:60,
                from /some/mangos/contrib/mmap/../../src/framework/Platform/Define.h:24,
                from /some/mangos/src/game/vmap/BIH.h:26,
                from /some/mangos/src/game/vmap/BIH.cpp:19:
/some/mangos/contrib/mmap/../../dep/ACE_wrappers/ace/os_include/os_ucontext.h:40: error: conflicting declaration 'typedef int ucontext_t'
/usr/include/sys/ucontext.h:244: error: 'ucontext_t' has a previous declaration as 'typedef struct ucontext ucontext_t'
make[2]: *** [CMakeFiles/vmap.dir/some/mangos/src/game/vmap/BIH.cpp.o] Fehler 1
make[1]: *** [CMakeFiles/vmap.dir/all] Error 2
make: *** [all] Error 2

I can only say that I know that udb project and sd2 project are very safe

Give Luda some time - december/ januaray are both "short" month for hobbies.

About udw forums: Yes it is a pity that they seem to have disapeared, however they were hosted by yehonal whom i haven't seen in ages

Also I am pretty sure that commit access related to zero github repos (that is a dev state) can be obtained after some time lag for anyone seriously interested.

I think you misunderstand me.

From my view you are looking on the wrong side of the problem.

I think the issue is _not_ the mob following a mob, but the mob who is followed.

Aside from this there will likely be some serious changes in movement-related stuff very soon.

I think this is not correct?

You remove the check that only the group-leader can reset the instance.

yeah - but I belong to the happy ppl who needs to delete them

Edit:

Please do not answer to the spam post.

If they create topics best just ignore them, and if they post into other topics, just report them

Crashs with commands are often caused by outdated translation packages