faramir118

Updated to the most recent master revision. Please test the core. Generator will still crash on Orgrimmar.

I think if blizzard wanted to, they could just have the next client patch remove realmlist.wtf completely, since it's obviously not necessary for enUS client and probably others. This would make it related to mangos, because we can't connect to mangos without realmlist.wtf. And sorry about the image

Hrm, then clients are different in different regions. Here is my enUS client login screen: [vladimir: image removed. Want go to some weeks ban?] If I put in the email address for my Battle.net account, even when realmlist.wtf is pointed at mangos, it logs me into retail. Is it * hardcoded Battle.net address in client * stored in registry like old Battle.net * some file other than realmlist.wtf * something else entirely?

At least for me: * realmlist.wtf has set realmlist localhost * Sign in with my old retail account's Battle.net email address * prompt for me to pick one of my expired WoW accounts * picking one says you have used up your prepaid time for this account So it appears that the client automatically assumes that any email address should be authenticated through Battle.net.

I'm still here. Just busy with school: * writing AI to play Scrabble * writing MSIL disassembler/decompiler - not an actual assignment, a class I'm taking on viruses spurred my interest * stupid papers I promise this project hasn't died!

Run vmapExtractor3.exe first, it will extract models and parse map data. Then run vmap_assembler.exe from the same directory.

I've actually been back for a few days now, but I'm still catching up on school/work stuff I missed, and preparing for a final exam. Bleh. I'll get back into the swing of things soon. First will be updating to latest mangos rev, then fixing my most recent bungling of the generator.

Player p = NULL; if(unit->GetType() == TYPEID_PLAYER) p = (Player*)unit;

Looks like vmap_assembler's VS2008 (VC90) project doesn't have an x64 configuration, so it doesn't have the proper preprocessor defines Compile for Win32 And don't even bother with VC80, I didn't touch those files.

I figured it would be a problem best handled heuristically. If someone does use the code I posted, please let me know if you find cases where it is getting false positives or negatives. I can try to improve it. Read this and this.

http://gist.github.com/463304 should be what you want.

http://www.kernel.org/pub/software/scm/git/docs/git-reset.html The last 3.3.3 commit is f01d43d97839719112201e7ac084f04c8dd6b445

Hrm, it crashes on Orgrimmar with liquids. It's the same bug that has happened several times in the past where there is apparently too much mesh data for recast. I leave in 2 hours, so I suggest you stick with the pre-liquid build. Commit 883c660697483c0edb874cc35382b71eaae78f55 is the last 'safe' one. I do have ideas on how to go about fixing the problem, but I'm sure not exploring them will be torture for the next week.

The extractor omits a row and column of liquid height data: http://github.com/faramir118/mangos/commit/883c660697483c0edb874cc35382b71eaae78f55 Not a huge bug, but it was a problem for my movemap project.

I pushed the liquid changes. * Liquid is NOT handled for WMOs, so buildings and most instances haven't changed * I haven't implemented pathfinding into the aggro/target selection algorithm. This means that monsters still default to the old way if there is no complete path to the target. However, monsters will go around lava, deep water, and the like if there is a path. * There seems to be a memory leak in the generator. Not a critical problem, but I would like to spend some time fixing it. * I changed the map extractor again (tiny bug fix), so you need to recompile and rerun if you have some spare CPU cycles please test the generator with different parameters. I didn't have time recently to do exhaustive testing. Thanks in advance for any bug reports. Going to be on vacation for a week, but I'll check in.

http://www.penny-arcade.com/comic/2004/03/19/

@EARTHWALKER Sorry, those directions are from an old build. On Windows, you need to do this: * build contrib/vmap_extractor_v2 in Release configuration * copy contrib/vmap_extractor_v2/bin/Win32_Release/vmapExtractor3.exe into your wow client directory * build contrib/vmap_assembler in Release configuration * copy contrib/vmap_assembler/bin/Win32_Release/vmap_assembler.exe into your wow client directory * make sure there is a vmaps folder in your wow client directory * open command prompt, cd to wow client directory * run vmapExtractor3.exe * run vmap_assembler.exe Buildings vmaps * delete the Buildings directory from your wow client directory * delete the old vmaps from your mangos data directory * copy the vmaps directory into your mangos data directory * recompile mangos core * update mangos.conf

You only need to change the two settings at the top of the Configuration Manager:

# Network.Threads # Number of threads for network, recommend 1 thread per 1000 connections. # Default: 1 Windows max is 4096 sockets per thread Unix/Linux max is most likely 1024 sockets per thread, it's system dependent Because performance gets crappier the more sockets there are in one thread (even when there is no network traffic), you'll want to follow the conf suggested ratio. Of course, if you don't have enough processor cores you won't really gain performance by increasing the number of threads.

Did you mean: server && (user friendly || ~performance) If so, I disagree! I can run a fancy gui on a remote computer and not impact performance at all.

MaNGOS doesn't use any managed code. You probably need to get the MSVCRT installed. If that fails, do like Patman suggests and compile it on the same computer you want to run it on.

You need to edit realmd.realmlist.address in your database. It should be set to your server's Hamachi IP address or alias.

You probably need to initialize i_path to a null pointer. Look at TargetedMovementGenerator.h, line 43 I think the core implementation is going to get comparatively complicated... * need to handle the different terrain and movement types need to check whether or not the creature is swimming/flying (and find the navmesh above/below it), ensure correct behavior if a mob is moved forcefully into terrain it can't move in, etc * path calculation should be added to the threat/aggro and target selection code From inside a MovementGenerator, there is no way to produce the correct behavior * requires PathInfo to be moved to somewhere else, either to the Unit itself or a dedicated PathManager class * upon initial aggro, a group of mobs should each get their own copy of the first path generated * need a smarter path following algorithm than current PathInfo::updateNextPosition() currently, steep slopes cause monsters to walk through the air or ground * point selection (based on distance and angle to target) should be done after calculating the path prevent cases where the monsters path takes them through the player

It's only for debugging the navmesh in RecastDemo, but he said he was using the debugOutput parameter - maybe a better answer would have been 'stop using debugOutput'. It's something that only I will ever need to use. Agreed. That may be a whole project unto itself.

It works, but if you don't have a Meshes directory it crashes (unless you apply this fix) Yes, I had thought about using convex volumes for liquids - unfortunately, it would have to be written from scratch. Interesting that they maintain aggro, I assumed they they just started fleeing. Although now that I think about it, mobs on retail don't truly 'reset' until they have reached their spawn/home. What happens when a character that is swimming is on top of the threat list? Does the mob ignore that player, but still keep track of thread? Yes, I just haven't looked into that portion of the code.