faramir118

I'm going to try to cherry pick commits from master into mangos-one. I finished getting a 2.4.3 client, but I don't have the expansion to go with it. After a lot of git-blame, I think there's about 29 commits from master that need to be cherry-picked into one. This is of course for a full port of vmap v3. mmaps would only require maybe 10 of those, but I feel bad only going part way. Bad news is I will be on vacation next week with no Internet access.

ChargeMovementGenerator todo: need to review return values in Update function (I think they're backwards) should probably pass the original charge spell to the movement generator, then let the finalize function handle special behavior and yes, behavior can be dependant on actual distance to target at the end of charge Unsure of the best place/way to stop spell effects from being processed

Just noticed my diff didn't have the new movement generator. Updated with all of the code. vmaps v3 need to be ported first. Finding accurate documentation of old file and struct layouts is a challenge. If it would get us more testers, I guess I can start poking around in old MPQs for mangos zero/one.

http://www.wowpedia.org/Patch_mirrors is your best bet

Created ChargeMovementGenerator patch for make and VS2010. Handled everything except the delayed spell trigger - I'm not too sure how to approach that.

For charge effects, it looks like proper implementation is a long way off. Thinking aloud: Mangos currently uses Relocate, so server-side travel is instant. Judging from videos, charge is not instant - in fact, speed appears to be constant and independent of distance. A special charge movement generator would be more appropriate. The stun spell is triggered - if travel is not instant, the stun would happen too early. So the trigger spell effect should not be processed immediately, instead being handed off to the charge movement generator. When the destination is reached, the spell should be triggered. If the charger gets stunned or something, the charge movement generator should be interrupted. Also judging from videos, it appears that the destination is never updated during travel. We can do better though, just depends on how blizzlike people want it

Shouldn't be mmaps - they don't affect players except for charge effects.

I assume he cloned a fork of mangos and would like to update his local repo with mangos master. You only need a fork on github if you want to share what you're working on

You can fetch and merge with git pull. Just specify the remote and branch you want like so: git pull git://github.com/mangos/mangos.git master If everything applies cleanly, your local repo will gain all commits from the remote, plus one merge commit. You're done! But if there are conflicts, you need to fix them. After that's done, commit the remote changes, plus merge conflict fixes, like this: git commit -a

Even though my implementation doesn't seem to work, and current network IO implementation is not a bottleneck, I figure someone out there is interested in learning (at least I am). Did some digging, finally found the document I read a while back that explains some of the scalability benefits of asynchronous event demultiplexing (proactor pattern, or event based IO) vs synchronous event demultiplexing (reactor pattern): http://www.hpl.hp.com/techreports/2000/HPL-2000-174.pdf Keep in mind that their test environment is a) old and slow (400mhz) and b) uses a simple, accept based protocol that requires very little processing. I'm doing a bit of digging in ACE code to see exactly what the ACE_Reactor and ACE_Acceptor implementations do.

The config file offers a persistent setting, so you can work around known issues - maps with a crappy mesh, or where unimplemented features like spawned GOs cause problems. We need some runtime config option to handle other cases, like player abuse. Admittedly, I was lazy and used the mangos.conf + .reload conf to satisfy both needs How about this instead: add chat commands to disable pathfinding change the config settings so that they can't be reloaded change the config settings so that they actually prevent mmap data from loading

Since it seems like something is wrong with lighthouse payments, I figure it's a good opportunity to ask why we're not using github issues instead.

The mmap.enabled setting just controls whether or not pathfinding is performed. mmap data is always loaded We did it this way because if the setting is changed from off to on (with .reload conf), we have no good way to load the mmap data on every grid This should probably be explained in the config file.

bump Also, perhaps parts of https://github.com/faramir118/mangos/commit/e0837e5dea62806028fbe028b1393b7874a454a4 should be included - would give even more correct data.

wow model viewer has lots you could work with http://code.google.com/p/wowmodelviewer/

Seems like we need to do some memory profiling. If there are memory management issues, it would be nice to know before we send it to under review. And even if there aren't leaks, it seems like we should know the system requirements for running this code.

The ACE Reactor is an event dispatcher. You can create an event handler to receive network IO events, IO exceptions, timer expiration, and some other stuff. In order to get the Reactor to dispatch to your handler, you have to call register_handler - you can see this in WorldSocket::open When mangos closes a socket, it eventually calls delete on the WorldSocket object. This means the reference passed to register_handler is invalid - the next time the reactor tries to access that handler, it crashes. The call to remove_handler prevents this

Updated patch: pets will react when owner is attacked, but not via AssistDelayEvent pets can call for assistance, so owner will react

Ok, I found out why pets aren't added to assistants list - they are stored as world object instead of grid object. Rather than visit a whole other storage, is it better to trigger pet assist directly from the owner? PS Who wrote the Visitor-pattern and related code? With all of that functional-style code, I would have been 100% lost if I hadn't taken a class that covered Scheme during undergrad.

What do you think about fixing these kinds of spots with offmesh links? Could hardcode them in sources or new db table

I see it: https://github.com/mangos/mangos/blob/master/src/game/Creature.cpp#L1772 Not sure what you're looking at.

If you're on Windows, AD defaults to debug mode and the binary is called ad_debug.exe. Switch to release mode, or use the debug binary... Other than that, just make sure you copied the maps into the mangos data directory after you extracted them... Open your mangos data directory. Open the map directory. Open one of the .map files in a text editor. If it says MAPSv1.1 at the beginning, you're using the old maps. mmaps requires MAPSv1.2 Also, you don't need to re-extract or re-assemble vmaps - mangos master's vmaps are exactly the same.

Using UDB 395, you can tests these on and entries 1564 (Bloodsail Warlock) and 10928 (Succubus Minion, the pet) succubus doesn't despawn when warlock dies succubus doesn't fight, because StopCombat is called from Unit::Update warlock doesn't aggro when succubus is attacked succubus doesn't aggro when warlock is attacked (not as easy to see because of #2) As for the player-owned pets, it makes sense to allow them to call for assistance (for example, so city guards can assist) Player-owned pets probably should not assist others though... that's easy to add back in.

As long as you provide feedback in the future, there is no need to apologize.

You have to build AD from sources - my repo doesn't include a compiled binary