Gotisch

assuming a maximal walkable angle of 90° would make the majority of the walls walkable. This defies the purpose of a wall and thus, to me, seems like a really bad idea.

why are you notifying everyone you are pm'ing neo? i don't get it

I am sorry but are those "moment in time" views not totally non informational? At least something like avg ammount of users per 1 hour and avg latency should be used, or at least some sort of load average / player average. how is the cpu use at one specific moment saying anything?

Wouldn't simple login in empty world with and without patch until it fails at patched version be enough to track down error? You could just compare both packet logs and check what the difference is. Since only change is in network code the logs should be totally equal.

From cpu usage images with before patch and after looks like cpu usage went up: before it was (avg) 1.24 then it was 1.78 everytime with ~ 1200 people online. But RAM usage went down from 28GB to 9GB; so not really sure what those images should tell us.

Will never happen. We cannot deal with the consequences of disabling some tiles on map. The logic of pathfinding between tile with and one without is ill defined. As for areas : same thing, but even harder, since area detection in mangos isn't too solid. You can always just do what caeruleaus suggested : delete tiles you don't want. You will have problems in the borders, but its upto you. There is always the possibility of disabling it in code. ie. check if areaid is in blocked list (setting) and then don't even try to generate path, but tbh. not sure why this would be helpfull

i added cmakefiles to build it on linux and it works fine ( i think ): if i put it into directory of MoveMapGen and generate with debugOutput i can launch it select debug as Sample and <mapid>.obj as input mesh. Problem is it seems to load every tile in map, wich reduces usage possibilites (i.e: my pc can't handle it ). you said there is way to only display one tile at a time? i couldnt find anything relating to that in debug.cpp code, or did i just miss it? For debugging purposes optimal would probably be the display of the current tile and if wanted the 4 adjacend tiles, no?

is the source for the modified recast the one in dep? your last commit fixed problem with stock recast thanks

the debug .obj generated with generator looks weird to me (loaded into recastdemo) http://img405.imageshack.us/img405/3962/screenshot14l.png maybe someone can check it too? maybe its just me, or there is problem with .obj generation or even vmap usage ./MoveMapGen --tile 35,46 --debugOutput true 0 edit: seems to be just my source for recastdemo. shame on me for getting it from github and not googlecode

You'll have to add parameters. I'd make the custom recast parameters optional for the --tile option You'll probably hate the parameter parsing code - it's a hack From a first look it shouldn't be to hard to add, the hacky code, i at least find nice to read. Relevant config settings are done in MapBuilder::buildMoveMapTile() from what i can see. The settings are: float cellSize = .5f; // larger number => less voxels => faster build time // too large, and tight spaces won't be pathable. float agentHeight = 1.5f; float agentRadius = .1f; float agentMaxClimb = 1.65f; or are there any more somewhere else? It should be no problem to add them as parameters (--cellSize, --agentHeight, --agentRadius, --agentMaxClimb). That way generators can play around with them. From what i understood from code, tiles with different settings will work together. Anyway, these are just guessed settings, no? or taken from recast demo. Maybe there is a good set of settings that works well for all tiles. If not, one solution is to have different settings for special tiles, no? [edit: my english is getting really way to bad]

you should be able to to generate the mesh with different arguments. I'm not sure how new generator is set up, but it may be possible to generate mesh with different parameters per grid (?). So the only problem would be to find a correct setting configuration that works well per grid, ie. that isnt to strict so that stairs cause problems but that isnt to lax either, so that mobs walk "over" fences. If you can only choose one set of parameters for all the navmesh would make things a bit more limited, but in the end its all about the settings. I'll try take a look at generator at weekend.

well if you can go to outland or northrend and land on a roof and then attack a mob that can't reach you and tell us what happens that would probably clear things up. - does the mob not react at all? - does the mob try to attack you and then give up? then if you have pet, try to get on top of aggro list and then get out of reach of mob, he will attack your pet. when you get back into reachable grounds does he stop attacking pet and attack you again, or does he continue attacking pet?

Let's put it into perspective, Creature AI ticks every 100ms (yes?) So with 10 players qsa modular way would take maximum of 1 second to find reachable target, assuming that only 1 player is reachable. While at every tick only generating 1 path. faramirs way would take 100ms but generate 10 paths in that time. Still same example with 10 players. you will generate 10 paths every tick (at least that is what your pseudo code suggests). Exactly the same applies to 2nd solution too. In most cases first target we select will also be the last. The same is true for my suggested way. We generate the path, it is valid, so save it somewhere where the MovementGenerator can use it. Do i see infinite "this is true for my way too!!" loop here? Here are pseudi codes as i understood them Creature::Update() Unit::Update() process events (might die here, damage aura or something) MotionMaster::UpdateMotion() active MovementGenerator::Update() (IF there is no valid path for current target) !generate one new path! (IF (not evading)) UpdateAI() Unit::SelectHostileTarget() (IF current path is INCOMPLETE) mark target as unreachable (IF possible other target) switch to next possible target (ELSE) evade Path generation is limited to MovementGenerator. Target selection is limited to CreatureAI. Faramir proposes to rewrite Unit logic Creature::Update() (IF (not evading)) UpdateAI() path Unit::SelectHostileTarget() Try to find valid target by checking everything in taunt/threat list normally and with path Unit::isInAccessiblePlaceFor() !generate one new path! (IF generated path is INCOMPLETE) drop it (ELSE) save it (But probably not from isinaccessibleplace but in AI?) Unit::Update() process events (might die here, damage aura or something) MotionMaster::UpdateMotion() active MovementGenerator::Update() !Access Saved Path from AI! or !generate same path! Path generation is limited to AI/Unit (or if path not saved movementgenerator generates path too) Target selection is limited to AI What are the differences between faramirs way and qsa's? faramirs way * might generate more then one path per iteration * needs "shared" memory to save path to * needs one iteration (100ms) to decide if it should evade * breaks modular coding way by mixing pathfinding into AI qsa's way * path is only generated by Movementgenerator * needs more then one iteration to decide if it should evade (worst case sizeof(threatlist)) What are the real differences? faramir would need some field for saved path and rewrite of unit logic qsa needs some way to save if unit is accessible or not From what i understand (and remember) from official. Official mobs will run as far as possible to unreachable target and then evade if they can't reach it. With your way that won't happen. With qsa's way this won't happen either. Way to make it happen imo is to make isinaccessibleplace only return true, if generated path was incomplete and mob is already at last node of path for at least a few ticks. If Mob has to follow invalid path anyway, i don't see advantage of "not wasting updates" because to be official mob should not do anything else. Wasting also only happens in case of invalid path. Creature::Update() already takes care of threat/taunt/death cases. qsa way also garantees that mob will evade only if there are 0 reachable targets, so i don't see how this is advantage So to me main difference between the two methods is the mentallity where to generate path.

I am not trying to say you made the changes with light heart, i was just following up on your post i wanted more details cause i find it interesting how did you compare the database loads? Seems to me that it is very hard to simulate people posting to a forum. simply requesting the pages multiple times would just favour forum software with good caching systems. I can't really follow your argument about tables, because having a big database isnt a bad thing in itself and 500mb isn't that huge nowadays. What sort of hardware does the webserver run on that you would need dedicated db server for 500mb database? From what i understand the current mysql database isnt on same server as forum anyway is it? What tricks do you use to reduce the number of queries?

well going with new ticket system i think database structure should be something like this id parent player map x y z category gm (?) status ticket responce(1-4) for completly new tickets parent is 0 else it is the id of the previous ticket. WorldPacket data( SMSG_GMTICKET_GETTICKET, (4+len+1+4+2+4+4) ); data << uint32(status); // standard 0x0A, 0x06 if text present if (status == 6) { data << uint32(123); // unk data << (ticket ? ticket->GetText() : ""); // ticket text data << uint8(0x7); // ticket category data << float(0); // tickets in queue? data << float(0); // if > "tickets in queue" then "We are currently experiencing a high volume of petitions." data << float(0); // 0 - "Your ticket will be serviced soon", 1 - "Wait time currently unavailable" data << uint8(0); // if == 2 and next field == 1 then "Your ticket has been escalated" data << uint8(0); // const } i think in packet first could be ticket id. and second to last status. WorldPacket data(SMSG_GMRESPONSE_RECEIVED, 4+4+len+1+1+1); data << uint32(123); data << uint32(456); data << ticket->GetText(); // issue text data << ticket->GetResponse(); // response text 1 data << uint8(0); // response text 2 data << uint8(0); // response text 3 data << uint8(0); // response text 4 recv_data >> map >> x >> y >> z; // last check 2.4.3 recv_data >> ticketText; recv_data.read_skip<uint32>(); // unk1, 11 - talk to gm, 1 - report problem recv_data >> isFollowup; // unk2, 1 - followup ticket recv_data.read_skip<uint32>(); // unk3, 0 recv_data.read_skip<uint32>(); // unk4, 0 first read_skip would be category, no?