qsa

Can you please try : In PathFinder.cpp : PathFinder::calculate() change "if (!m_navMesh || !m_navMeshQuery || !HaveTiles(dest) ||" to "if (!m_navMesh || !m_navMeshQuery || !HaveTiles(dest) || !HaveTiles(start) ||" Thanks in advance.

I think I nkow what it is about. Anyone know if creatures trigger grid loading? I think not. If so, this crash happens when random movement generator makes npc to wonder to unloaded grid. If thats the case, I'll fix it soon.

That is indeed the source of this problem, causing our terrain generator to ignore polygons near bottom-right borders. I think I can fix it without storing any extra data tho, just different logic while generating polygons. [del]I'll test it once I get back home.[/del] EDIT: On the repository; testing needed. @aming51: From what I remember, this issue is actually caused by GetClosePoint() in TargetedMovementGeneratorMedium returning destination point on the lower ground that the target is. So, it is not directly related to mmaps. Can anyone confirm this? EDIT2: I'll confirm to myself. Same issues w/o mmaps. It is problem in WorldObject::GetNearPoint(). Most cases should be fixed by https://github.com/faramir118/mangos/commit/e43031b928ca2036fe90215936064d9a0c57d869 Testing needed. Since it is general mangos problem, feel free posting it in "review" section. Cheers

The reason I'm so impatient is since I think its about the time this thread move to "under review" section. Without proper test results, I cannot do it with clear conscience. The reason I want it done, is not that I think its bug-free or perfect. The reason is to speed up development. Proper threading model can be nice, since mmaps do scale well - but it is not "a must". Unrelated: There's tinny issue with terrain I noticed couple of days ago: In some places the liquid ends just before the shore line- as seen in the picture: http://i51.tinypic.com/dpiu4x.jpg This causes really bad mesh generation in that area, since that shoreline is unpassable. Was looking around both in map extractor and in our code - wasn't able to find logical error. It might be problem with the actual provided terrain. But then we'll have to complicate for it somehow. Anyone noticed this king of issues before? faramir118? Best regards.

Most models do not have pitch/roll values at all, or they are set to low values. PS: some testing needed.

Should be fixed in latest commit. All maps must be re-extracted fresh (delete mmap dir's content at the extractor, otherwise it will just skip those). Thanks for report. This should fix fair pile of issues. @Undergarun: how's that report is going? We're getting old

The mmaps generated are accurate, according to input mesh - look at it, the bridges are little bit misplaced. There's error in our TerrainBuilder::loadVMap() logic, or maybe model data (or entire map angle)? It looks like pitch angle is off by ~3-5deg.

Well, if that keeps happening, we'll have to add some asserts. Otherwise, without catching it under debugger there's no chance I can solve it. You have no idea how to reproduce, do you? Had to ask ... If you have more of those, please post them all, even if the trace looks the same. On, not so related note: Below is little modification turning our A* into weighted A*. Two simple modification: 1) Weight up the heuristic function: in our case most of the time distance plays the role of perfect heuristics, thus expending 'only' nodes directly on the path to target - we can't go wrong here. 2) Do not return nodes from closed set back to open. Both of the changes will do the following two things: 1) Expend less nodes. In other words, make path generator take less time and memory - should be about 30% less - no idea to now much overall it translates. 2) Provide non optimal results. While A* ensures optimal result (optimal by our metric - distance), this variant, while still ensuring completeness, will provide suboptimal solutions. I'd love to see the performance difference under load. (thanks in advance) diff --git a/dep/recastnavigation/Detour/Source/DetourNavMeshQuery.cpp b/dep/recastnavigation/Detour/Source/DetourNavMeshQuery.cpp index 44aafe2..be66667 100644 --- a/dep/recastnavigation/Detour/Source/DetourNavMeshQuery.cpp +++ b/dep/recastnavigation/Detour/Source/DetourNavMeshQuery.cpp @@ -68,7 +68,7 @@ inline float dtQueryFilter::getCost(const float* pa, const float* pb, } #endif -static const float H_SCALE = 0.999f; // Search heuristic scale. +static const float H_SCALE = 2.0f; // Search heuristic scale. dtNavMeshQuery* dtAllocNavMeshQuery() @@ -695,7 +695,7 @@ dtStatus dtNavMeshQuery::findPath(dtPolyRef startRef, dtPolyRef endRef, if ((neighbourNode->flags & DT_NODE_OPEN) && total >= neighbourNode->total) continue; // The node is already visited and process, and the new result is worse, skip. - if ((neighbourNode->flags & DT_NODE_CLOSED) && total >= neighbourNode->total) + if ((neighbourNode->flags & DT_NODE_CLOSED)/* && total >= neighbourNode->total*/) continue; // Add or update the node. Best regards

Merged with master. Added mmaps to RandomMovementGenerator. All movement code remade fresh, pile of changes all over the place. Keep your eyes open for new issues. @Undergarun: Waiting for your side of the deal I didn't manage to remove mmap integration from movement generators completely, but it sure became simpler in some places, trivial in others. I also had to make couple tinny modification to your spline code. Feel free to comment on general design. Cheers.

The common case will do for us, thanks. Due to recent changes (spline movement) it will take me bit longer to fulfill my side of the agreement. All movement logic will have to be made from scratch. The good news are that the result, as I see it, will be more centralized, clear code.

I'm using mmaps with more than 3000+ ppl online since some months ago without problems. Also i have mtmaps (4 Threads) and 48 GB DDR3 ECC with MySQL in other server. Waiting for merge with mangos due to changes made by SilverIce. That's pretty good news. How about we make a deal? I will merge with leatest mangos and all its changes, and you in return, will make a detailed report about mmap memory/cpu consumption as function of number of players. With mmaps and without. How does that sound?

Can't confirm it using the revision in mmap master. Tested with flying creatures with inhabit air and ground, or only one of them set.

I can't see any mmap related code at any thread stacks, yet you got exactly the same vehicle calls all over. If I were you, I'd look for too large vector allocation somewhere around Player::VehicleSpellInitialize -> WorldPacket opcode=377 -> ByteBuffer -> reserve If you say, allocate 2giga there... with mmaps you may not have that kind of memory - fail, while you may have 2 giga free w/o. In any case, chances this issue related to mmaps are rather slim. Besides, nothing changed in mmap code in a while now. Cheers.

Nothing to do with mmaps from what I see. std::bad_alloc -> new failed (possibly out of memory?) Looking at the stack I'd guess something to do with vehicles (Player::VehicleSpellInitialize) ?

I'm looking forward for results Thanks. Memory/cpu diff given online count (/w /wo multithreading) can sure be valuable info. The one point provided is just syntax example I do agree that we need some sort of database, even basic one. Don't be shy people, post those. Don't forget to mention for which version those are generated (master, one, zero) since map vary.

I'm asking the same question for quiet some time now Take the initiative and gather this data. It will sure help the development. bump? nay news for this great feature testing? Sorry guys for not being too active recently, just bit busy lately. Generally speaking, there aren't too much things that can be done without code review or bug reports, new ideas etc. PS: I know there are some pretty esoteric problems wit some tiles on mangos zero, but I have no means debugging those at the moment. So.. to sum it up: 1) We need some developer to review the code, general idea etc. 2) More tests and reports. Both positive and negative. 3) New idea can come in handy plus people who are willing to contribute to development process. Without mentioned below, its just a matter of time till it dies out. Best regards.

Look inside dep\\recastnavigation\\RecastDemo folder. Basically, its a tool that allows you to see the actual input geometry and generated mesh.

mmtile: http://filebeam.com/886c88901ab8b910f8983678bf84b86f reextracted several times (with offmesh) & game serv & at my serv. & not work inside instance. Well, the mesh looks ok to me, beside some single poly that out of order - but that shouldn't affect much. But I cannot match it to the geometry of old maps. That's since 335s 32,32 tile on that map is totally different. Furthermore, I cannot test it ingame. You can always try and extract with debug flag and upload geometry too. Or better, see for yourself using the recast demo.

Should be solved in latest (mmaps_rewrite branch).

KuraiNeko: I don't think Intimidating Shout has anything to do with my changes. See spell 5246, its first triggered effect is stun, which is used for the glyph. It is what prevents you from running You can clearly see it by using ".aura 5246" on self. It is extracted just fine for me (on 3.3.5). Look for file named 4293232.mmtile - if it isn't there, re-extract the map. About those issues with fear and confusion : well, obviously they need some more work I'll push few more changes that should solve atleast some of the problematic cases soon enough. Thanks for the testing and input.

This sure sounds like the behavior of fear on maps/tiles with no mmaps loaded. Make sure those do work there. Added little safety check for z value, just in case - but it really shouldn't change too much for proper mesh data. I'll check ZG tomorrow, but on 335 client, don't have earlier versions. As one of the above posts said : you can easily see the mesh generated. PS: please include exact coordinates next time ... searing gore isn't small place.

Those coordinates on map 0 sent me to Westfall , I guess there's minus missing at Y coord. Anyhow, there's indeed strange issue there. For some strange reason, when you stand there and at couple more locations, the closest polygon selected in the one from the basement just beneath and not the ground. No idea why it happens only there. This will need a closer look little bit later. Haven't had the time to look at that location (nor I can on zero client only 3.3x), but, generally speaking ... You (as general "you", not particular) can debug alot of the problems all by yourself. For instance, you can generate mmaps for that map using the --outputDebug flag, then open it in recast viewer and the the actual mesh generated. As for mangos one/zero - it can be nice if someone maintained those branches, someone who actually use those ... wink, wink ... Short, simple answer would be "yes". I mean, sure, way(s) always do exist. A little bit longer answer: Does current code support it - no. Why? Since none implemented it. Why? Since VMAPs do not support those and we rely on them to generate our input meshes. Why don't "we" implement it? go ahead, I think we already had someone working on those. As for mmaps, I think we already spoke about ways to make it happen on mmaps without modifying meshes on runtime.

Had some time on my hands yesterday, so I finally decided to try and add pathinding to ConfusedMovementGenerator and to FleeingMovementGenerator. Pushed the changes into git yesterday. FleeingMovementGenerator had to be totally remade, including all its logic. The good, is that it is much simpler now. The bad, is that it will work really poorly on maps with no MMAP enabled (fearing off cliffs, etc ..) Changes to ConfusedMovementGenerator were less extensive, the logic left the same, just the paths generated by pathfinding system and some minor logic changes, like not generating all points in advance, etc... As always, lots of testing is needed. On the subject : unfortunately, I see no correlation between the number of people using our little system, and the number of reports/feedback we are getting. Thats a shame. There are at least 6 (I know of) hugely popular sub/projects/branches using mmaps, yet we have even less feedback from the times we started. I know I sound like a broken record, same "bla, bla bla", but it would be shame, if this initiative will die out after all work invested in it. If you find a bug, please make sure it is not a known issue (stuff like dynamic GOs, etc), then report it here. Include exact coordinates and way to reproduce it + system info. Thanks in advance.

Where is this coming from? Charge do not use point movement generator, or any movement generator at all. Charge calls MonsterMoveByPath() directly, which in tern forces the destination.

I did read your reply, unfortunately, this was not mutual. Just to rephrase it in simpler manner : charging walls has nothing to do with walkable angles.