faramir118

Fully, it will create the missing tiles.

Another error in generator, fixed. It affected maps with 'wdt has wmo' = TRUE in this list. But it also exposed a bug in core - if there is no tile loaded but there is a navmesh, it seems like mobs always evade. I appologize to everybody who is struggling with... ...bugs ...re-re-re-generating mmaps all the time ...understanding what the hell is going on We're making progress, so thank you for everybody that is helping test!

To fix maxTileCount problem quickly: Apply this patch, then run movemapgen like you did before. It will 'patch' all your .mmap files. You can revert the patch change afterwards. As for using 1024 or 2048, sooner or later we're going to have tilecount go up by few factors. Seems like the only really good way to eliminate those long, thin triangles. It won't be soon, but we'll at least see how well it works.

Doh... fixed. If you build 1 tile from each map, it should rewrite the .mmap file with the correct info. Sorry, I'm bad at math.

From what I could tell, they were all simply widening the dtPolyRef type. That is something I am interested in though, regardless if it fixes a problem or not. It would alleviate some concerns about too many tiles... I only changed one part of recast, the rcSpan height members' widths.

Just maps, dbc, and mmaps.

I didn't spend time looking for a location to test this I agree that it's a rare corner case. Even when I edit the recast source so that maxEdgeLen affects all contours (not just tile and area boundaries), the navmesh still has a lot of long, thin polygons. Changing maxVertsPerPoly doesn't seem to solve this either, just creates different number of tessellated shapes in the same general patern. rcBuildRegions seems to have the bigest impact - it places a large region which must later be broken into smaller subregions in order to create convex polygons. Unfortunately, there isn't a way to limit region size directly. This isn't working well for us, so I'm going to reduce the size of tiles - then recast will always create reasonably size regions. It may affect performance (more polygons), but the visual result that we have now is unacceptable. The file format for mmtile will be incompatible with the current implementation, also. I have a x64 win box I can compare against, but all of my dev so far is x86 win. Mikko recently posted some very interesting things on his blog. I think we should see if anything from this post or this post are applicable to our environment. They both deal with path-corridor patching, similar to what we want to achieve with the suffix optimization.

These are caused by long, thin triangles in the navmesh. I will work on a solution. I have a feeling it will be a major change to the .mmtile file format...

Liquid data is needed for preserving inhabitType If creature can't swim, we shouldn't build a path that takes it through water. If creature can't walk, we shouldn't build a path that takes it on land. @qsa With underwater pathfinding code you pushed, how can we prevent swimming-only creatures from leaving the water? Flying sharks are cool, but it can be overdone edit: I should clarify... how do we prevent swimming-only creatures from going from pool1 to pool2: |-------| g |-------| | | r | | | pool1 | o | pool2 | | | u | | |-------| n |-------| d

There are a few places that are known issues, like underwater and spiral stairs. For now, all we can do is disable pathfinding for these problems. If they tell you specific bugged locations, please let us know so that we can fix them

This is actually the intended use. Our units travel so close to the wall because some doorways and other small openings are only 1-2 voxels wide. More filtering would totally remove the doorway. To make sure this doesn't happen, I used as small a radius as I could. With config we can disable pathfinding without restarting server, even when players are still on a map that has loaded mmtiles. What major tasks are left? investigate invisible models dynamic GO (dev work on vmap needed) multiple navmeshes for multiple size mobs (depends on completeness of database creature data) update recast (need to merge into current changes) evade timer

Added config options to mangosd.conf. Should help test if your problems are due to mmaps.

First intuition was correct, fixed Changing the cell height might have worked, but I think there are other places in the world where this problem would have surfaced (like the mountain with Temple of Storms) Had to change the size of a struct - if you use recast demo, you need to delete all of the .hf files in the meshes directory or it will probably crash when you load old debug output. You only have to rebuild the affected tiles, and you can use debug mmap tileloc to find out which tile it is. For example, 6033230.mmtile is MoveMapGen 630 --tile 32,30

Somehthing going wrong in generator - the navmesh is below the terrain mesh, and is completely flat at a certain height. Might have to do with span height limits (only 13 bits to represent this) - there is a tall WMO there that might be ruining that tile. Also could be a bounding box issue... I'll work on it.

Just so you and your testers know, pathfinding and swimming needs work. In most cases, swimming characters/pets are 'unreachable' right now, so they won't be able to fight underwater. One corner case is in instances. I wasn't able to cull the ground mesh below the liquid mesh, so there are two separate 'floors' - one for the submerged ground, and one of the liquid surface. Pathfinding works, but it is a case where pathfinding shouldn't be used.

Probably safer to summon the waypoint creature and set it's inhabit type, then use it to calculate path. Also, we should probably check for water walking in PathInfo::createFilter. Unlikely to be used, but necessary for completeness...

Maybe something like: while(moreParams) { if (nextParam == "ground") filter |= ground; elif (nextParam == "water") filter |= water; elif (nextParam == "lava" || nextParam == "magma") filter |= magma; elif (nextParam == "slime") filter |= slime; } } That way it's a little more user friendly - order of params doesn't matter, you can specify only the ones you want, etc. First char of each word would work too. Fastforward to lateset master is fine with me, and would probably make others happy

Those files are usually having issues with line endings. You can try the whitespace options of git apply

I added support for vmap liquids. It's not that easy to test. Should we rework the debug commands so that the pathfind filter is also configurable?

Only certain spells are included in nonstacking categories of buffs/debuffs. The challenge is identifying which spells are in which categories (and then applying only the greatest buff/debuff in that category). Spells that aren't in a category stack like normal. See raidcomp tool.

Only the non-stacking effects should be handled, right? For example, effect 3 of Vigilance shouldn't stack with effect 1 of Sanctuary. The other effects, 2 from Vigilance and 2 from Sanctuary, must be applied though. edit: someone really needs to run a WotLK-only site... all of these spells are changing!

In these snipets, I use little-endian hex - lshifts actually move numbers right, and vise versa. Also, we read from the left side of the buffer. 8 bits (previous read) | 16 bits (current read, lshifted 8 bits) => bit_buf (32 or 64 bit variable, depending on which source you have): pp 00 00 00 | (cc cc 00 00 << 8) => pp cc cc 00 Here is a more drawn-out example... Initial contents: in_buf 43 7F 20 89 4C 11 2D FF bit_buf 00 00 00 00 bits 0 First call to get_8bit: // after extract from in_buf in_buf 20 89 4C 11 2D FF bit_buf 43 7F 00 00 bits 16 // after extract from bit_buf in_buf 20 89 4C 11 2D FF bit_buf 7F 00 00 00 bits 8 one_byte 43 Second call to get_8bit: // after extract from in_buf in_buf 4C 11 2D FF bit_buf 7F 20 89 00 bits 24 // after extract from bit_buf in_buf 4C 11 2D FF bit_buf 20 89 00 00 bits 16 one_byte 7F Third call to get_8bit: // don't need to extract from in_buf // after extract from bit_buf in_buf 4C 11 2D FF bit_buf 89 00 00 00 bits 8 one_byte 20

@Patman128 Basically, the shifts only operate on int32 and uint32 types. This means the bits are only lost if you assign the result into a type that is too narrow to store it. You can read the details in the C99 standard, sections 6.3.1.1 (for integer promotion) and 6.5.7 (for bitwise-shift semantics)

You mixed up step 2 and 3 - cast to ushort*, then dereference Basically, it gets the next ushort from in_buf and stores it next to the existing value in bit_buf PS - libmpq is pure C. It's also a 3rd party lib (from libmpq.org), and won't help you understand mangos code. You should look in the src/game/ directory instead.

He's using mangos .12, so not using vmap v3. Lynx3d's fix for the same problem in the new vmap version is here. For safety, you should also add similar check to is MapTree::isInLineOfSight to prevent crash there as well.