Gotisch

You can also have a thread pool of 20 threads, or 10 or 50. Even with only 1 core. Imho if you have one thread per map, that is not a threadpool because a request for a specific map will always be handled by the same thread. And the threads will live for the whole duration of server runtime. from top of my head there are multiple ways to implement more "multithreadedness" into mangos: 1) Global Threadpool that handles everything: Packets, AI, Timers 2) Threads for specific tasks for example run chat on own thread or things like that 3) Threads per specific area (map, zone, grid) 4) mix of above

what are "multi threaded pools"? the pools in mangos i know are spawn related.

because this is the wrong forum?

i wish there was a "contrary of thanks" button.

the thing i was wondering about is if this tile limit is all tiles, or just tiles loaded into navmesh at some point. if its just the number of tiles that can be loaded at once, we can add more poligons per tile, just making sure we do not load to many tiles at once.

what you want to do is not possible. name is cached on clientside.

The recast docs say this is a very cpu intensive operation and that they should be buffered if possible: startPoly = navMesh->findNearestPoly(startPos, mPolyPickingExtents, mPathFilter, 0); endPoly = navMesh->findNearestPoly(endPos, mPolyPickingExtents, mPathFilter, 0); if we already use a path object maybe we can just save those two polygons in it too. if i can add to this todo list: * Navmesh: Check if its possible to use TileMesh. i.e. Can we use just one dtnavmesh object and make "533*533" tiles, from which for each path calculation we load 3 adjancent tiles into memory. tbh. i asked author of tool here about tilesize, but i dont really understand his answer: http://groups.google.com/group/recastnavigation/browse_thread/thread/14c338dd04285250 if its possible to have an unlimited number of tiles, but only a certain number of tiles loaded into the navmesh, maybe we should use tiled navmesh. problem is, how cpu intensive is loading tiles into the navmesh? Solving this will solve all cross-tile pathfinding problems. also i agree about moving to new thread.

the message needs to have at least 10 chars

Yes this looks nice i will try to implement something like this when i have some time, probably only after weekend though. maybe we need to make it even more generic since HomeMovementgenerator could work of it too. atm i hacked around in it http://github.com/gc/mangos/commit/88343b8983920a7c9c4a953fe7782ac0b4945d83 so if there was baseclass to handle all movement along navmesh would probably work better. About seeing it in action, i have public testserver running with navmeshs enabled, if you are interested you can pm me. Well i can only get water from the gridmap. Vmap don't save any water information sadly i see i the source its on a sort of todolist. and for the gridmap im doing sort of a bruteforce approach querying height/waterlevel every 2 meters. but marking triangles should be possible.

Yes i wouldnt know where to implement this though, should it go in creature AI? movementhandler? problem here remains to find those connections, although probably can just check all nodes in navmesh if they touch the border or something like that Also here remains problem how to automatically find out where such a connection should be? I have also checked mailingliste of detour a bit more and maybe it would be better to just create one big Tiled_NavMesh then those connection between 533*533 zones would be handled automatically i think. I think autor of detour released new version just few days ago that allows easier loading of tiled meshes, so might be worth looking into. Well i dunno the map is 99% static it seems waste of cpu to generate a navigationmesh on the fly. edit: Also i found way around those insideout object like trees. I shall call it double buffering! Instead of Triangle t = Triangle(toconvert[0],toconvert[1],toconvert[2]); globalTriangleArray.append(t); or Triangle t = Triangle(toconvert[2],toconvert[1],toconvert[0]); globalTriangleArray.append(t); Which lets one half or the other work, i do Triangle t = Triangle(toconvert[2],toconvert[1],toconvert[0]); Triangle t1 = Triangle(toconvert[0],toconvert[1],toconvert[2]); globalTriangleArray.append(t,t1); Which creates the doulbe of triangles. but since those are only created for navmesh generation and that only in the first step i think the impact is negligible. (or am i wrong?) Also i added removal of all tiles in gridmap that are below water (gonna work on vmap under water now) now navmesh looks like this http://rapidshare.com/files/368138336/recastmmaps.tar.gz in above tar.gz are 2 files, one is recastdemo modded to load mmaps files if present in meshes folder second more interesting is movemaps project i edited to create generator for .obj and .mmap. all code is nearly inside viewer folder, i dont even know if the rest compiles. to generate the mmaps too you have to comment out the return true; after debugGenerateObjFile(); and you can comment out debug blabla if you just want to generate the mmap files.

you need to have generated a navigation mesh for the zone you are in of course here is one for for grid 49 32 on map 0 its near the field where first defias bandits i think are in human startarea http://rapidshare.com/files/368050038/0004932.mmap.tar.gz location one is border of the field where defias are in human startarea, you can test nicely with the fences. location 2 is a house near lake basically first house on left if you take path out from human startarea

first: sorry for doublepost second sorry for the huge images tinypic doesnt support reencoding apparently On Topic: I have now completed my first draft of a movemap implementation. Though i went another way then the initial posters of this topic: i just let detour generate the navigation mesh. For this i used the already present Tile spationing of the gridmap and just passed data according to that to detour and let it generate the mesh. Depending on the ammount of data there is for a tile, size varies between 16kb / 1mb per tile. You can find the code in this commit and the following 3 or 4: http://github.com/gc/mangos/commit/7941a0c0590ca9e4902b0b13e8b04c0d75a676ab please don't post questions asking how to install things in comments on that github repo. this is development forum after all not "download and use this i will provide support" form. This is a tile with content and size up to 1mb: This is a tile without content and size only 16kb (and probably will never get loaded): The general implementation is such that on loading vmaps and maps i just load the NavMesh too. And i added a method Position getNextPositionOnPathToLocation(const float startx, const float starty, const float startz, const float endx, const float endy, const float endz); to the Map class that will allow to get the next point to walk to in a straight line to reach the end point from the start point on the shortest correct path. Then i added code inside TargetedMovementGeneratorMedium<T,D>::_setTargetLocation(T &owner) To not walk to the target directly but the generated point (from pathfinding) I know this is suboptimal solution, because it will generate the path from the beginning at every node on the way, wether the goal location changed or not. On the other hand if the target (player) moves a lot paths have to be generated anew anyway. ( i also added to settargetlocation a check wether there is currently movement and if so dont change goal, so that the path will only be generated once a node is reached. settargetlocation gets called _alot_ apparently in mangos (even if player doesnt move at all). Anyway that is basically current setup. Here are two movies a made while testing it: http://www.youtube.com/watch?v=XNQOTJpLuuA (dunno if i am allowed to post movies to ingame content, if not please remove). Now there are multiple problems i am facing: * Pathfinding across grids: Is not implemented at all. The current system has fallback, that if no path is found it just goes back to standard mangos way: straight to target. This is really suboptimal since its realy ugly, but unless there is valid way to generate path accross grids is the only practical way, else people could flee from mobs by just crossing from one grid to another. Any ideas on this? One thing i can think of is to increase the actual grid size further then 533² while still keeping that number for grid calculation, this would result in overlapping navmeshes, and so the problem would maybe become negligible. Also lets stay focussed here that things like long path generation in the world are very... uncommon most of the time the path to be generated will have 3-4 nodes max! Just around a corner or such. The path generated in the screenshot is imo very unrealistic, since no player will aggro a mob from that distance (outside of instance). * Gameobjects have holes: This is a problem maybe someone with more knowledge about how vmaps work can help me with. you can see it well on following image: This is naxxramas instance (the instance is actually floating in the air above an unused map) and maybe for instances only 1 navmesh should be generated, containing the main wmo. But it shows the problem, each room seems to be present in the vmap but somehow the corridors between them are missing. I have same problem with all big wmos, stormwind for example each "zone" is cut of from the other. Is there a way to get these corridor information from vmap, if yes how? * Some gameobjects are inside out. Mostly threes but as you can see on image above mushrooms too. Does anyone know how to identify those models in the .vmap data, so that i can reverse them? * Other problem you can see on that image above is huge waste of memory for generation of paths on space that is not used by anybody.Question is when should navmesh not be generated or saved? initial project checked for NPC's at that location, but imho we need to think of pets too, they shouldnt walk wrongly just because we didnt want to generate paths where npcs aren't spawned. Anyone any ideas on that? * Thread safety. From what i read on recast mailing list, the pathfinding itself is not thread save. Since each map in mangos is used only by 1 thread at a time this is not a problem (or is it?). only problem i can think of is instances. Currently each instance gets its own navmesh, to save memory this could be changed. On other hand, since there are doors in instances for example and one could mark door area as non walkable on navmesh while door is closed, maybe own navmesh per instance is even wanted? * Speed: I did some speed tests on a per grid basis: [21:55:46]Joined Channel: [1. General - Shattrath City] [21:55:46]Joined Channel: [2. Trade - City] [21:55:46]Joined Channel: [3. LocalDefense - Shattrath City] [21:55:46]Joined Channel: [4. GuildRecruitment - City] [21:55:56]Generating MoveMap Path for all creatures around player In range:10000.00 [21:55:56]Found 386 Creatures. [21:55:56]Generated 386 pathes in 0 seconds 60835 µs [21:56:30]Generating MoveMap Path for all creatures around player In range:1000000.00 [21:56:30]Found 386 Creatures. [21:56:30]Generated 386 pathes in 0 seconds 62467 µs This is generation for all creatures inside a grid to player position so also pathes of different length. (range dont matter it just gets all creatures in grid that way) Is this good/bad? i feel that 400 pathes in 60ms is acceptable for at least small servers ~500 players or such since not everyone will aggro and run away from mob at same time. So if anyone could help me with ideas or code suggestions for those problems it would be greatly appreceated

its ok actually i think i was to asleep when i wrote that code, i just rewrote the whole coordinate conversion and now they match.

Hey, i'm having trouble to get the correct coordinates for the map/vmap data to generate the navmesh for example position in x=-9454.2724, y=72.769554,z=56,717453 is in my extracted vmaps/maps x[43.54] y[-9459.35] z[56.96]. that y and x are echanged isnt really a problem but there is still big discrepancy i mean 72 vs. 43.54 \\o/ to convert the vmap data i am currently using Vector3 vertex = tbarray[i].vertex(j).getVector3() + pSm.getBasePosition(); convertedvertex = Vector3(-((64*533.333333333/2 + vertex.z) - 64*533.333333333), -((64*533.333333333/2 + vertex.x) - 64*533.333333333), vertex.y); and the map data i dont convert at all just x/y/z does anyone have any info on this? im not even sure where i found that conversion for vmaps anymoer

yes you are right, i guess wowwiki isnt specific enough on their wiki page. Well i guess can just use your function. about database changes i would think udb forums, since mangos always say they have nothing to do with content.

you can just edit the dbc.. there are lots of dbc editors around. But then you need to reedit it after each wow version change. Other way would be in core to have method that is called after each dbc load where you can overwrite values. I think wcell does it this way ( http://wiki.wcell.org/index.php/API:Spells#How_to_fix_Spell_and_Aura_behavior ) but they do it way more OO if you ask me; so in mangos case dunno what philosophy would be, maybe just hardcoded core fixes.

how about your post what you have done so far, so someone doesnt have to do everything from the beginning again?

Yes you are right, there is however a even more simple fix int32 chance = SkillValue <= 75 ? 1000 : 25000/(SkillValue-75); That way you will have 100% chance to levelup up to (including) 75 skill points and from 76 onwards the formula would apply. This does match with wowwiki description. Also i found more information: see http://www.elsanglin.com/3_1_changes.html from what i see the easiest option for this would be to make something like this diff --git a/src/game/GameObject.cpp b/src/game/GameObject.cpp index 0bfb0b9..243680a 100644 --- a/src/game/GameObject.cpp +++ b/src/game/GameObject.cpp @@ -491,17 +491,24 @@ void GameObject::Delete() AddObjectToRemoveList(); } -void GameObject::getFishLoot(Loot *fishloot, Player* loot_owner) +void GameObject::getFishLoot(Loot *fishloot, Player* loot_owner, bool success) { fishloot->clear(); + if (success) + { + uint32 zone, subzone; + GetZoneAndAreaId(zone,subzone); - uint32 zone, subzone; - GetZoneAndAreaId(zone,subzone); - - // if subzone loot exist use it - if (!fishloot->FillLoot(subzone, LootTemplates_Fishing, loot_owner, true, true)) - // else use zone loot (must exist in like case) - fishloot->FillLoot(zone, LootTemplates_Fishing, loot_owner,true); + // if subzone loot exist use it + if (!fishloot->FillLoot(subzone, LootTemplates_Fishing, loot_owner, true, true)) + // else use zone loot (must exist in like case) + fishloot->FillLoot(zone, LootTemplates_Fishing, loot_owner,true); + } + else + { + // We caught junk, this is single loottable + fishloot->FillLoot(0,LootTemplates_Fishing,loot_owner,true); + } } void GameObject::SaveToDB() @@ -1131,35 +1138,27 @@ void GameObject::Use(Unit* user) int32 roll = irand(1,100); DEBUG_LOG("Fishing check (skill: %i zone min skill: %i chance %i roll: %i",skill,zone_skill,chance,roll); - - if (skill >= zone_skill && chance >= roll) - { - // prevent removing GO at spell cancel - player->RemoveGameObject(this,false); - SetOwnerGUID(player->GetGUID()); - - //fish catched - player->UpdateFishingSkill(); - - //TODO: find reasonable value for fishing hole search - GameObject* ok = LookupFishingHoleAround(20.0f + CONTACT_DISTANCE); - if (ok) - { - player->SendLoot(ok->GetGUID(),LOOT_FISHINGHOLE); - player->UpdateAchievementCriteria(ACHIEVEMENT_CRITERIA_TYPE_FISH_IN_GAMEOBJECT, ok->GetGOInfo()->id); - SetLootState(GO_JUST_DEACTIVATED); - } - else - player->SendLoot(GetGUID(),LOOT_FISHING); - } - else - { - // fish escaped, can be deleted now - SetLootState(GO_JUST_DEACTIVATED); - - WorldPacket data(SMSG_FISH_ESCAPED, 0); - player->GetSession()->SendPacket(&data); - } + // You can fish everywhere with every skill now. + player->RemoveGameObject(this,false); + SetOwnerGUID(player->GetGUID()); + player->UpdateFishingSkill(); + // If we fish in a FishingHole we always catch something. + GameObject* ok = LookupFishingHoleAround(20.0f + CONTACT_DISTANCE); + if (ok) + { + // We are fishing in a fishing hole, we always catch something. + player->SendLoot(ok->GetGUID(),LOOT_FISHINGHOLE); + player->UpdateAchievementCriteria(ACHIEVEMENT_CRITERIA_TYPE_FISH_IN_GAMEOBJECT, ok->GetGOInfo()->id); + SetLootState(GO_JUST_DEACTIVATED); + } + else + { + // We are fishing in open Water, what we catch depends on our skill. + if (chance >= roll) + player->SendLoot(GetGUID(),LOOT_FISHING); + else + player->SendLoot(GetGUID(),LOOT_FISHINGJUNK); + } break; } case GO_JUST_DEACTIVATED: // nothing to do, will be deleted at next update diff --git a/src/game/LootMgr.h b/src/game/LootMgr.h index 0b7914d..b4fa62d 100644 --- a/src/game/LootMgr.h +++ b/src/game/LootMgr.h @@ -71,7 +71,8 @@ enum LootType LOOT_MILLING = 8, LOOT_FISHINGHOLE = 20, // unsupported by client, sending LOOT_FISHING instead - LOOT_INSIGNIA = 21 // unsupported by client, sending LOOT_CORPSE instead + LOOT_INSIGNIA = 21, // unsupported by client, sending LOOT_CORPSE instead + LOOT_FISHINGJUNK = 22 // unsupported by client, sending LOOT_FISHING instead }; class Player; diff --git a/src/game/Player.cpp b/src/game/Player.cpp index fe9fddf..79d813d 100644 --- a/src/game/Player.cpp +++ b/src/game/Player.cpp @@ -7583,7 +7583,9 @@ void Player::SendLoot(uint64 guid, LootType loot_type) } if (loot_type == LOOT_FISHING) - go->getFishLoot(loot,this); + go->getFishLoot(loot,this,true); + if (loot_type == LOOT_FISHINGJUNK) + go->getFishLoot(loot,this,false); go->SetLootState(GO_ACTIVATED); } @@ -7775,7 +7777,8 @@ void Player::SendLoot(uint64 guid, LootType loot_type) switch(loot_type) { case LOOT_INSIGNIA: loot_type = LOOT_SKINNING; break; - case LOOT_FISHINGHOLE: loot_type = LOOT_FISHING; break; + case LOOT_FISHINGHOLE: + case LOOT_FISHINGJUNK: loot_type = LOOT_FISHING; break; default: break; } i used zoneid = 0 as template for junk loot since its same everywhere. The entry it database seems also fairly simple since there are only 10 items, but udb syntax escapes me atm. and this isnt right forum for it anyway.

ah really? i though it was written somewhere how to generate, anyway there is file CreaturesToCoords.py just put it in a folder and a folder called StartCoords then edit configureation (database info) and run file it wil generate StartCoords from your database here i uploaded the ones i generated you should be able to use them: http://rapidshare.com/files/362545930/StartCoords.tar.gz

you need startingpoints... did you even read the readme? there is a python file to generate them

The sad thing about the giant ammount of repos is that it makes it impossible to find good repos where people actually post stuff. Which kinda defies the whole "for learning purposes" because its impossible to learn something from those 0 commit repose ^^

Oh thats true didnt think of that thread was started in 2008

sorry for bringing up thiy really really old thread, but did someone manage to get it working with cmake?

so, i played around a bit with recast and here are results: I don't find those so bad? I don't really understand why we have to rewrite everything from the ground up, if we have a rebust navmesh generation and pathfinding library at our hands? its writte by a proffessional game developer and its open source \\o/ maybe we can't use .obj files because there compression rate sux . I added here my ugly hack ( i really really suck at c++) to generate .obj file for recast: http://pastebin.ca/1832908 to generate it you just oben some vmap with the viewer (from jolans repo + fixes said above) the generated .obj file (way to big because its a txt file) is here: http://rapidshare.com/files/361741912/map.obj.tar.gz.html recast/ detour can be found here: http://code.google.com/p/recastnavigation/ nice explanation also can be found here: http://critterai.org/nmgen So isnt using this library an alternative? or am i missing something here?

well you might want to look at #2 Object::BuildUpdateDataForPlayer (this=0xa9fed58, pl=0xa0567390, update_players=...) at ../../../src/game/Object.cpp:1059 Tbh. i dont know enough about c++ what segmentation fault in context of Program terminated with signal 11, Segmentation fault. #0 std::tr1::_Hashtable<Player*, std::Pair<Player* const, UpdateData>, std::allocator<std::Pair<Player* const, UpdateData> >, std::_Select1st<std::Pair<Player* const, UpdateData> >, std::equal_to<Player*>, std::tr1::hash<Player*>, std::tr1::__detail::_Mod_range_hashing, std::tr1::__detail::_Default_ranged_hash, std::tr1::__detail::_Prime_rehash_policy, false, false, true>::_M_find_node ( this=0xa9fed58, pl=0xa0567390, update_players=...) at /usr/include/c++/4.3/tr1_impl/hashtable:896 But irrc segmentation fault means you try to access memory that you are not allowed to access.