faramir118

Again, not a problem with mmaps - you probably have merge errors.

Looks like there are consequences to such small voxel sizes... small, insignificant gaps become problems. I'm really surprised to see this... These are due to A* heuristic, and the fix is rather CPU expensive. Due to player range limits, it's hard to make a bad detour like this in-game.

boss_jeklik.cpp doesn't have anything like this, I think it just falls back to typical MoveChase We should create an 'mmap compatible' version of SD2. There are probably other corner cases like this one... it would be nice to have them fixed ahead of the time mmaps gets accepted. You know, years from now after all the testing

Can't wait to see what you come up with next

UnkleNuke, your sig kind of ruins that awesome speech

He starts in a place where there isn't a path to players. Technically, he turns into a bat so he should fly somehow... Brings up a point (one mentioned before) that some mobs probably should cheat, like bosses and guards.

I tried a Java thing, just a couple dozen lines, but there was some really weird issue. MoveMapGen would hang at some point, so I tried to attach the VS debugger. All I got was an error: windbg also had problems, it won't load symbols for the hung process

That is problematic, because Recast and Detour would need a lot of modifications

I didn't see this part in diff At the very least, it should be the default. No problems removing lowRes It shouldn't impact anything. All of the things we write to file in the extractor is read using the same type in the core (assuming extractor is run on the same arch and os as core ). If I missed something, we should fix it.

Some of the doors on map 34 look like they are only 1 voxel: http://img689.imageshack.us/i/tight.png/ It's the detail mesh - it won't affect pathing, but it will affect movement with findSmoothPath. You can fix it be decreasing maxSimplificationError. Experiment with that number a bit... 1.9 seems ok

https://gist.github.com/726329 Same thing as above, but with a bit of cleanup and some of our more recent features. edit: that cellSize comes really close to making doors impassable on the maps I've tried. Wouldn't be surprised if some are blocked.

Found this while looking into the new detours: http://img140.imageshack.us/gal.php?g=demob.png How did our code generate a different poly path? I pushed something that should fix that.

[10562] should prevent that.

Well we have a relation ship between two values... But how do you calculate one of those if you don't have the other yet? I assume time or speed will be calculated from dbc data, but can't figure anything that relates dbc data to packet captures' time or speedz. Does anyone have packets from other spells with trajectory splineflag?

Mikko uses SVN on google code We could correct the whitespace in git, but future merges with recast SVN would be more trouble.

Mikko didn't want my whitespace patch... apparently Xcode will just mess everything up again. If you have a script or something he can run before each commit to clean whitespace, great! Can't believe that went unnoticed for so long Can you give me mapid and xyz coordinates?

More complete list available here: http://raidcomp.mmo-champion.com/

Pushed changes to the mmtile file format. Requires all maps to be extracted. 16x16 dtTiles per mmtile. Fixes some detours caused by crappy tessellation There will be some new detours as a result, due to A* heuristic... tons better than before though. And we can probably compensate with some of the optimizations from Mikko (visibility stuff from CrowdManager.cpp). the generator now skips tiles which have the proper format and version information If you want to rebuild a tile, you should use the --tile parameter or delete the corresponding mmtile file. There are some TODO items related to this push: adding debug/error logging to mmap load/unload review mmtile load/unload There is potential for leaks: when tiles don't unload correctly, their data will linger in memory after a grid has been unloaded by TerrainInfo Larger padding border, will make tile connections better in some places Also, merged with [10793] and fixed conflicts and broken generator build files.

13x13 doesn't work either Why did they have to pick a number that can't be represented in base 2? Going to play around with the calculations a bit to see if I can make it work more reliably. edit: fractions work much better, and this seems to work with any number of subtiles #define TILE_SIZE (16 * 100) / (3 * TILES_PER_MMTILE) However, rounding/truncation creates a small gap between mmtiles. This can be minimized by using a multiple of 3. edit2: findNearestPoly fails if you're in the aforementioned gap... back to the drawing board.

After Nov 23 update, the new posts link on forums (eg Core Modifications [ New posts ]) shows new posts in all forums. Is that by design And thanks!

Having an issue with multiple dtTiles per mmtile... White lines indicate tile connection. Heavy blue lines indicate a tile edge that is unconnected. 2x2 4x4 8x8 16x16 32x32 64x64 In 2x2, 8x8, 32x32, all of the tiles are unconnected. I think it's a float precision problem, but it's hard to tell since higher tile counts work normally. This leaves us with 4x4 or 16x16, unless I manage to correct the problem (64x64 was just for giggles ). Haven't done the math (too lazy) but I don't think it 16x16 is too much for 64bit refs. However, it does create some stupid detours (that visibility optimization trick would fix it) edit: also noticed that with smaller dtTiles, there are extra sections of navmesh on those mountains. edit2: changes here

For simple commit messages use git commit -a -m "Type your commit message here." If you want linebreaks and such, you need to learn more about VIM, git, or git gui

http://www.virtualbox.org/ I guess use this as workaround until someone can provide real help

That just means it hadn't been loaded yet. The next frame on the stack (#5) is where it gets loaded: at GridMap.cpp:1124 map = (GridMap *) 0x95a9b5c0 Any idea what map? If not I'll find it myself eventually Probably better to use this: return (void*)new (std::nothrow) unsigned char[size]; When allocation fails, nothrow returns null instead of throwing an exception And I think that your sizeof(char) is redundant - there is implicit sizeof(unsigned char). And the standard says it's supposed to be 1 anyway

Buildings directory is output of extractor, and can be deleted after running the assembler. Did you run vmap assembler?