faramir118

12>game.lib(Chat.obj) : error LNK2001: symbole externe non résolu "protected: bool __thiscall ChatHandler::HandleUnFreezeCommand(char *)" (?HandleUnFreezeCommand@ChatHandler@@IAE_NPAD@Z)

12>game.lib(SpellEffects.obj) : error LNK2001: symbole externe non résolu "public: void __thiscall Unit::MonsterJump(float,float,float,float,unsigned int,unsigned int)" (?MonsterJump@Unit@@QAEXMMMMII@Z)

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

navigation in Booty Bay:

Looks like there are consequences to such small voxel sizes... small, insignificant gaps become problems.

I'm really surprised to see this...

Badlands, strange corner

http://filebeam.com/c324dcf793f8816ec1e … 39fb42.jpg

X: -6566.770508 Y: -3291.101074 Z: 242.517136 Map: 0

strange curves in path

http://filebeam.com/9e2036876a9e01618ae … 4f21b2.jpg - straight line

http://filebeam.com/8454939e69fd9df38f7 … 1c8005.jpg - curve

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.

Jek'lik's movement is part of the scripted event. He jumps/flies down to a static point before attacking the target.

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

I'm going to commit this patch tomorrow

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.

If I remember right, someone was about to make bash+batch script for us. Something nice, which detects number of CPUs and balances load of extraction accordingly.

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

I think you should use uint32, uint16, int32... everywhere like in the core.

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

I also added check, to prevent generating maps without any actual geometry, those flat tiles.

Saves some disc space. Their chances to be loaded on runtime are slim, but still.

I didn't see this part in diff

So, my next though, following same logic, was removing hiResHeight option altogether.

Any objections?

At the very least, it should be the default. No problems removing lowRes

One more though: Noticed that in some portions of the extractor code we use "int" and in others+core "uint32". Can't it cause problems? Lets say, on 64bit system int is 8 bytes, while uint32 is still 4. Can this sort of thning happen with ACE defines? it sure looks so. Do we really care?

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/

EDIT: I did noticed something strange, something I never seen before.

...

Has no affect on pathfinding, but still annoying.

Any ideas?

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?

what did i do wrong?

I pushed something that should fix 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.

hundreds of trailing whitespace errors had to be fixed

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!

libmpq was double didn't want it that way

Can't believe that went unnoticed for so long

on terrain like scaldig pool mobs fall under the map a little when aggroed

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

pMap = (GridMap *) 0x0 - it's ok?

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

and another crash, but not caused by leak now http://paste2.org/p/1098620

Any idea what map? If not I'll find it myself eventually

Well, actually maybe new does throw something, but system may handle it differently

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?