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?

From what i understand fluxbb mods need you to edit fluxbb source code itself. maintenance with code edit inside code itself seems to be really hard to do. everytime there is a fluxbb update you will have to merge your code changes with main code changes hoping that nothing will break. to me it seems fluxbb does not have a real template system, at least they write in their todo for next major version "implement real template system and rewrite core". Features are what make a forum software great though. the "thanks" feature for example allows easy differianciation between user and dev, etc. Since fluxbb doesnt have these features you will have to reimplement them yourself or live with less features. Also from the errors i got here on forum major problem seems to be database. which hasnt that much to do with forum, does it? with old system i got error message could not connect to database, and now sometimes i get same error message. what is your argumentation for fluxbb having good maintenance? i looked at it but didnt see any advantage over other board software that for example uses some sort of module system for extensions (fluxbb only has this in admin area) what was the real performance hog with old forum software? so that fluxbb works better in that reguard?

Well from what i gather with 2 min google, something like this should work too, no? vector<string> text; string line; ifstream textstream ("config.txt"); while (getline(textstream, line)) { text.push_back(line); } textstream.close(); for (int i=0; i < text.size(); i++) parseline(text[i]);

imho you should read file in one go anyway, reading line by line is slower then reading everything at once iirc

I have two problems with this code: 1. Using multiple threads to read single lines from a file seems to be totally inefficient. 2. Using regular expressions to parse seems to be totally inefficient. then again if its just for learning it totally fine \\o/ (if the parsing of one line would really take so long that it would be worth creating multiple thread correct design patter is as few locks as possible imo. so you would insert into configMap only once per thread, at the end.) how did you measure that? Also what would be interesting is usage statistics of each thread, are threads used the same? (each thread does 25% of the config file with 4 threads) Or is one thread doing most of the work while the rest sleep away. How does this class compare to the same without multithreading? ie. no linebuffer but calling the regexp (if you really want to use that which is really overkill, since initialization probably costs more then parsing the file) from while(std::getline(this->fileStream, line)) { parselinehere(line); }

sorry for editing my post makes yours seem a bit out of context . but to see if a enemy is reachable, the function calls isInAccessablePlaceFor() which at the moment only does: if(IsInWater()) return c->canSwim(); else return c->canWalk() || c->canFly(); here it should check if there is a path from creature to target.

Based on what i see in current code the actuall path checking should be done in isInAccessablePlaceFor no? there probably first check would be if node can be found in navmesh, and then the path

Why does the Aggro logic have to select a Path? If by Aggro Logic you mean the AI, its job is: to decide which Target to attack, if Target is in range attack him, if not set goal for movementgenerator to the Target (and lots of other high level stuff). Job of Movementgenerator is to decide how to get form current location to location of target and do the actual movement, or not?

just so that we don't do the work twice, i started documenting map system a bit. http://gist.github.com/562933

no. vmaps dont contain ground information outside of worldobjects

i think right way to implement this is some flag on creature that forbids usage by player, no? best would be to get some packet log showing what happens when one guard is talked to. I think if no flag or such is set then we should think about saving guids