faramir118

In this text, reach means travel to. Retail monsters will aggro, but then evade immediately if they can't reach the target. Mangos monsters aggro only if they can reach the target. No aggro means they can't even make ranged attacks. In order to make it more like retail, I think it would take some rewriting. Selecting it, reaching it, and attacking it should all be separate steps. Then, if the selected target can't be reached you have to fall back to something else.

Yes. It works, but needs some performance testing.

Did you look at the crash logs? Sometimes they can point you in the right direction, even if they aren't all that useful.

They aren't being duped, they're being paid.

This patch does two things: * corrects spelling of accessible * adds a check for flying to Unit::isInAccessiblePlaceFor. This makes creatures not chase players (and other creatures) that are flying. for [10407]: http://gist.github.com/548726 Three issues, need feedback: * since this is called so often, does the pure virtual function call impact performance? * should there be a config option to use vmaps for the GetHeight call? * ranged attacks should still be used, but aren't (this seems more like a problem in SelectHostileTarget)

Or some people just start camping corpses of those who just want to play, ruining the server. This should be something that is only active in battle grounds or arena.

There are a lot of tasks that are very easy to handle in those extra threads, such as 'seamless' environment loading/unloading, network and disk IO, playing audio, etc. They should be easy to single out.

That's not a bug, I just haven't put pathfinding into HomeMovementGenerator. This update fixes the some things in recast, most notably the crash that occurred when building Kalimdor with liquids enabled. Current state: * Terrain types work * If a complete path is found, creature will follow path * If a complete path is not found, default to old movement behavior (run through things) Otherwise, the creature would just stand there instead of switch targets or evade. Pathfinding during aggro/threat logic will fix this. * Deleted some simple optimization attempts which, upon further study, could possibly make invalid or unoptimal paths. * VC90 update will be here in the next couple days, just need to get my work computer up to date. * Probably need someone to help with automake stuff, since I have no way to test it You don't need to re-extract maps. Liquids work now, but because of #3 above they don't work in all cases.

Ok, new stuff is pushed. Changes to the core again. Still need to update VC90 and automake build files.

Just good housekeeping in the case continue; is hit before its cleared. edit: the break; in that same loop should be a continue;

Think of any faction, like Bloodsail Buccaneers: If you are neutral with them (and haven't checked the 'at war' checkbox), both functions will return false. I think IsFriendlyTo is supposed to determine if you are allowed to heal/buff a target. The client has its own checks for this, so you won't see perfect behavior (such as when you turn on cross-faction grouping, but can't heal each other).

Inadvertently accumulating some mesh data... sorry! Insert the following code at MapBuilder.cpp line 201 (inside the for loop): allVerts.fastClear(); allTris.fastClear(); The shameful part is, I'm not using the array that keeps growing and growing. I would push it to the repo, but I'm in the middle of testing a huge commit. If it weren't for these pesky database updates... edit: Kalimdor with hi res heightmaps and liquids now averages around 40MB working set, peaks at about 77MB. A long time ago, it used to take over 2GB to do low res with no liquids

Unfortunately I generate and delete my mmaps a lot, so I can't say for sure. 242 sounds reasonable for the default generator settings (instance and arena maps).

I assume the Orb of Deception falls under the category of 'other uses'

Yes, that's normal. I should ask Lynx3d to change that to a debug message

It sounds like something that should be stored per player, not per map. Can players be made scriptable?

I'm updating recast navigation. There were some API changes which implemented features I had hacked into recast earlier. Undoing my hacky modifications and figuring out the new way is fun. (not really) Also moving a lot of code around. Should make future updates easier, and match mangos standards better. Unfortunately it's nothing new or fun, which I suppose is the main reason I'm taking so long to do it.

I recommend Navicat Lite

The models are in the client data, but I think race-specific totems are for Cataclysm. Maybe we'll be ahead of retail?

WoW reached a critical mass at some point, and I think it is too successful for even its creators to realistically compete with, with or without those people. I like Torchlight - it was developed by ex-Blizzard (and then ex-Flagship Studios) employees. It's not a super popular game, but it was a success in its own way. Was Dr Frankenstein killed by his monster?

Ok, so the problem isn't too much data. More data just increases the chance that the bug surfaces! Unfortunately there's no workaround, but I reported it and will try to assist Mikko in resolving. Also found another problem with navmesh generation for regions that overlap itself - see http://img801.imageshack.us/gal.php?g=spiral.png

A lot of the original designers quit and form a new company called Flagship Studios. If they were the ones behind most of the original game ideas, I'm not sure new IP will be as good.

edit: Nevermind, I wasn't using my brain.

Any thought given to totem model depending on race? http://www.wowhead.com/guide=3.3&models#shaman-totems

I did you one better. Liquids are off by default, just use it like you would normally. If you DO want liquids, look at the new command line switch. Core-side implementation still isn't complete (depends on aggro and threat logic), so I don't suggest you use them. Plus some other fixes.