faramir118

Schmoozerd is correct on both points: Chase and Follow are the exact same, update and position selection are implemented by TargetedMovementGenerator (TMG). Also, TMG is set up on a 50ms update timer (this is the same as the world update tick delay, so setting lower won't make it better) The issues UnkleNuke talks about are only likely to be a problem if you are a) travelling very fast or b) you have high latency.

[ code=diff ] tags work (see above) [ code ] tags are broken (linebreaks are removed)

maybe you also try to use callgrind, one of valgrind's tools (I haven't used valgrind before, so I won't be able to help much) http://valgrind.org/docs/manual/cl-manual.html

Try this: https://gist.github.com/1604896 then (feel free to add other parameters) cmake /path/to/mangos/src -DPREFIX=/path/to/install/dir -DDEBUG=1 then make; make install Unfortunately, it seems that gprof doesn't work on Intel Macs... I was able to verify that the profiling output is created when mangosd exits, but gprof shows no data. If I have time later, I can maybe build a virtual linux box and give it a try.

While it's possible to just dive in, I think success is more likely if you first learn about some of these things you're likely to have never used before. pointers - you must know this stuff, since C++ uses explicit memory management classes - the bread and butter for inheritance and polymorphism mangos uses these these object oriented concepts heavily templates - you may never write template classes or functions, but you should be able to read and understand them mangos uses lots of templates, including some template meta programming

can you compile for profiling and run gprof, and post the results? A very simplistic example of how is here: http://cplusplusworld.com/gnugprof.html

spells and aggro through walls = vmaps monsters' bodies through walls = mmaps

You guessed correctly, <<<<<<< marks the start of the merge conflict, ======= separates the two conflicting pieces of code, and >>>>>>> marks the end of the conflict (this is the same way SVN and others mark conflicts) Resolving merge conflicts in code you are unfamiliar with can be very challenging, but there are some useful tools that can help: git blame annotates each line of a file with information that describes when that line was last edited alternatively, use git gui blame in a graphical environment gitk (graphical environments only) gives easy access to history graph, commit diffs, staged changes, unstaged changes (including merge conflicts) experiment with right click in gitk - there are a lot of shortcuts to other useful features Once you have resolved the merge conflicts, use git add to mark them resolved before git commit, which completes the merge (I also recommend compiling before you commit, because it is easy to miss/skip conflicts) PS: for the conflict you posted, you want to keep the HEAD version (see 8ca6876fef015833fa50949adca0c442861f9501)

I leave fixing the merge conflicts as an exercise for the reader, as well as learning what those commands do (eg, man git-reset or git help reset) This should get you in working shape.

My repository is very outdated. TheLuda and Salja have updated mmaps' zero version and are hosting it in the official zero repository in the feature/movemaps branch. Usually, the git protocol (git://) is faster than git-over-http (http:// or https://). It only affects fetch (pull) and push commands, so it's not a big deal which you use. I highly recommend following UnkleNuke's advice about using a special 'integration' branch where you merge all of the interesting forks/branches to do your compiling. And maybe you (and others) can get some use out of this cheat-sheet I made for my coworkers.

We can't help unless we know the problem. paste some of the errors, then link them here.

When it first came out, VS2010 was a bit slower when compiling. I don't know if that still holds true - it's certainly not slow enough that I ever wanted to switch back. I've not had actual problems... give it a try, UnkleNuke

Patches are garbage, use git features like merge or cherry-pick instead.

Reordering the initialization list probably isn't the "proper" fix in all cases, since members are actually initialized in the order they are declared: class c { type a; type* b; c(type* b_in) : b(b_in), a(b) { } // a(b) actually happens first, when b is uninitialized! }; The above could cause crashes. If mangos has this problem, reordering the initialization list will hide the probelm. Something to just be aware of... edit: evilatwow kind of beat me to it

I don't think you need to think of Sectors as a way to divide players into groups. They're just an arbitrary region of space, and the boundaries between them don't need to have any meaning to the combat/movement engine. An example relating it to terms many people are familiar with: In WoW, each map is split into zones. Zones affect the game design in a big way - each is themed (jungle vs desert etc), each has a level range, each has several quest hubs , etc. But to the server core, a zone means nothing - it has no impact on combat or movement, isn't used to group players, etc. I think your Sectors are roughly equivalent to WoW's zones - arbitrary regions of space which are useful to players, but nothing more. You will have to figure out how to transfer a player from one bubble to another on the fly - maybe Patman's suggestion of a proxy would work, but it will bring its own challenges (there are a lot of architectures, each has good and bad aspects) Also, maybe try asking/looking at other communities (like gamedev.net) - it won't hurt to get ideas from a broader audience than just us

EVE Online has a good solution for this problem. Player A at planet 1 has no way of interacting with a player B at planet 2 - they are much too far apart. Thus, they are placed in separate 'bubbles', a and b respectively. A warps to within interaction distance of B, and A is removed from a added to b. Now that they are in the same bubble, they can interact (within the limits of sensor/weapon range) Your only issue with this system will be the real-time control aspect. In EVE Online, players can only warp to landmarks (planets, stations, other established structures) or players. In this way, they limit the possible number of bubbles. For your purposes, I'm sure you can come up with a good way to allow a player to 'peel away' from a large bubble as they get further from it. In EVE Online, multiple bubbles run on one server. For larger fights (hundreds of players), a single bubble is placed by itself on a better/bigger server. In fact, CCP encourages players to inform CCP of their large-scale attack plans so that hardware can be allocated to the proper time/place in advance. Overall, it's a simple and flexible space-partitioning scheme.

Hrm, I don't think you'll find anything perfectly clear. Best I can find is Rawr, here is a link to the last pre-cata release I can find: http://rawr.codeplex.com/SourceControl/changeset/view/53851#294974 They have a comment saying that no stat modifies glancing blow. It is possible that it was based on player weapon skill vs mob defense in wrath, but since weapon skill was removed in cata we can't test it on retail anymore. edit: This EJ post indicates that 1) glancing chance in wrath was 24% and 2) it didn't change in cata.

http://www.wowwiki.com/Glancing_blow - not good enough?

Sorry, I've grown lazy after 1200+ posts in the other thread... The code is located in the mmaps_rewrite branch in my github repository And because I'm lazy, I also like to let git do all the work... You can get my branch like this: git remote add -f faramir118 git://github.com/faramir118/mangos.git After that, you can look at the mmaps-only changes (pipe this command to a file to generate a patch): git diff $(git merge-base faramir118/mmaps_rewrite master) faramir118/mmaps_rewrite offmesh connections Yes, rebuilding the mmap files just for offmesh connections is very time consuming (especially since not much work is actually done). It can be lessened with a really good how-to on the use of the mmap generator, but not very user friendly. aggro system This part needs some work, regardless of how it involves mmaps. I will read your changes once I am home. IIRC, testing for mmaps on retail showed that unreachable targets were dropped from the threat list. evade That would make things simpler. However, I believe that there are some cases where evasion isn't on a timer - don't bosses reset much faster than regular mobs?

In my repository, mmaps_rewrite is the newest version. The backport branches are outdated quite a bit (relative to mmaps_rewrite AND to their respective mangos versions) mangos one is in a good position for a complete backport of mmaps - the spline movement has been backported, which was the major roadblock before mangos zero still doesn't have the spline movement backport, so it can't be a complete backport. However, TheLuda was working on the feature/movemaps branch but he seems very busy lately.

Hrm, I see what you mean now. It looks like it really only is doing a merge. The simplest work around would be to cherry pick your commit into a new branch based on master: git checkout -b pull-request origin/master && git cherry-pick [commit hash] Then push the new branch to github, and open pull request for it.

http://help.github.com/send-pull-requests/ Read the Changing The Commit Range and Destination Repository section.

bump

try this from bash (the command line shell that comes with msysgit) git clone -v --progress git://github.com/mangos/mangos.git It may provide more details.

I recommend you use git, it's really very easy to do what you want. After you've cloned the repository, just do this: git checkout -b new-branch-name ef793da5b Otherwise, you can follow these steps to get your zip: navigate to the commit (ie https://github.com/mangos/mangos/commit/ef793da5b) click the 'browse code' button in the top-right corner of the commit message click the 'zip' button' below the repo description, left side of the repo-url bar