faramir118

Just to make sure... Say there is a map that is composed of one model (an instance, like StormwindJail). If the model has X vertices in tile A, and only 1 vertex spans into tile B, will there be a vmtile file for tile B? As long as this is the case, I guess we're in good shape. I can handle the NULL iModel pretty easily. edit: that map is not tiled, but for the sake of argument say it is

Seems that there is a lot of confusion regarding program arguments. I think I'll redo them so that they're more intuitive.

Sounds like you haven't got the x64 platform installed for Visual Studio 2010. If you're using the free version, I don't think you can install it. Are you able to open and compile mangosdVC100.sln?

I basically came to the same conclusion last night. Initially wasn't concerned about the continents so I didn't think much about memory use. I think the algorithm will change to: * build list of *.map tiles * build list of *.vmtile tiles * load all model data * build navmesh using composite tile count from *.map list and *.vmap list * bound the model data, and iterate through it tile by tile * load tile heightmap, combine with model data * build rcChunkyTriMesh* * follow tile building algorithm in buildMoveMap's nested loop * unload tile heightmap * remove tile from *.map list and *.vmap list * *.vmap list should be empty now * build any tiles that remain in *.map list The reason I'm going to stick with the rcChunkyTriMesh is it allows me to load all model data ahead of time, and then break it into tiles. I'm concerned that loading one vmap tile at a time might prevent [large models that span across tiles] from loading correctly.

If you do this, you're not using all of the mesh data. It takes three floats to define a vertex: vertCount = m_vertices.size() / 3; We reference m_vertices data with indices, which are stored in m_triangles. It takes three vertices to define a triangle. So: triCount = m_triangles.size() / 3;

Regarding the continents: I wasn't initially concerned with them, because I think pathfinding is most important in instances and PVP areas (because pets are stupid). There are other important things I want to work on resolving, but I'm going to give this my best effort until I think it's wasting time You are correct. If no path is found, creatures default to the old behavior. This is mainly an artifact from when this project was started, because: * paths were constrained to 1 tile, which was a severe limitation for large instances * using the old vmaps implementation created "holes" in some meshes, and inserted "walls" in others, which were problematic to say the least My implementation of pathfinding in mangos' core is a proof-of-concept, and it is by no means complete (or even efficient or stable). Even the generator is lacking at this point. Lava is a perfectly suitable surface to walk through, and I still have no idea how I'm going to break the heightmap mesh when a model protrudes from underground. Even so, I am still extremely satisfied every time I watch a monster walk around a wall. I think I need to get out more.

Well before some of my tinkering, it was taking 3-4 times that long. So you're welcome Could you give me some more details? Confirm this is what you're using... movemapgen --hiResHeightmaps false --skipContinents false --debugOutput false And tell me if you compiled for Win32 or x64. It's still a WIP, but I've reworked the memory allocation strategy. The G3D stuff wasn't cooperating, so I'm just using more intelligent code which can pre-allocate what is needed. The 'Creating ChunkyTriMesh...' part is really memory intensive, it quadruples the triangle storage while it works. I wouldn't be surprised if you can only do hiResHeightmaps continents on a 64bit architecture, but I'll do some math and see.

Hrm, looks like there's a bug in the G3D::MemoryManager implementation, which is used by G3D::Array (which I use to gather vertex and triangle data). Interestingly, the error occurs while trying to deallocate memory. Stop using hiRes heightmaps for now, the bug seems to only occur when the Array grows past a certain size. I'll see if there's an easy fix for this.

@vladex I moved some files around, all VC90 projects work now @willisoady Hopefully my moving files around fixed it also, but I'd like to see your changes regardless. When you run the generator with parameters, you have to specify values for everything: C:\\wowemu\\mangos>MoveMapGen.exe --skipContinents false --hiResHeightmaps true The only exception is specifying a map number, like when you want to build ONLY naxxramas: C:\\wowemu\\mangos>MoveMapGen.exe 533 And you can combine them like this: C:\\wowemu\\mangos>MoveMapGen.exe --hiResHeightmaps true --debugOutput true 533 If you specify a map number, it will build that map regardless of the --skip* settings or their defaults. A word of warning regarding debugOutput... This requires A LOT of hard disk space, and increases memory requirements.

I attempted to prevent that in http://github.com/faramir118/mangos/commit/7700c9820b001b62b4b6f80bb3d93c34ba5c5deb and http://github.com/faramir118/mangos/commit/afdf5dac480b352494539fb2b786f3ec78709e0a Basically, InputGeom.h/cpp, MeshLoaderObj.h/.cpp and ChunkyTriMesh.h/.cpp should be excluded from core. Maybe those files should be moved to contrib/mmap/src/ If you make it work, please post a patch! As you can tell, make build chain is my worst enemy.

Another batch of updates. Please look at contrib/mmap/readme. Generator Updates: * finished add runtime settings (config file or command line parameters) * finished prevent potential tile index inconsistencies * new finished use all mesh data in output (fix those 'imperfect' maps) * navmesh parameter tweaks, map generation is much much faster now Generator Todo: * find a way to 'poke holes' in the heighmap mesh where there should be entrances (caves, stairs leading underground, etc) * use liquid info when building mmaps No map downloads this time, at least for a little while. I'd like people to try out the generator. edit: I should mention that I had to change the core's makefiles again, so I wouldn't be surprised if it broke

I actually did this, but the forum ate my edit Will redo as soon as I finish this set of changes. edit: done First of all, thanks for doing this! You can resolve your errors with preprocessor define MMAP_GENERATOR (compiler option -D MMAP_GENERATOR or something?)

Well, it's not so easy. Something is going wrong on in the generator which messes up the navmesh creation for portions of tiles, leaving sections of tiles without navdata. I'm working on fixing it, but I have no idea what exactly is happening at the moment. The core should be stable though. When monsters are in these areas, their behavior will return to the old way of running through objects.

New generator doesn't need any parameters. Just put it in the same directory as the 'maps' and 'vmaps' folders, and it will do the rest. I made it ignore maps 0, 1, 530, 571, and some others. You'll have to edit the MapBuilder::shouldSkipMap method if you want to change that behavior (or wait for me to make them configurable at runtime) no, you're doing it right. 2 bugs: * debug commands don't do reference checking * I stated earlier there's a tile coord mismatch error caused by generator. This is it (I think) I'll fix the first problem, should be easy. The second one might not be as clear as I'm hoping, we'll see. But it will require new mmaps.

There's a lingering memory leak, but I'm working on it. May experience some server crashes edit: pushed a fix that seemed to work.

I recommend adding a progress indicator in extractor and assembler, it seems a lot of people get impatient and think something is broken when stdout is silent.

The new vmap extractor/assembler aren't very good at letting you know they're working. I would just give it some time, it should be done after a bit. I'll ask Lynx to add a progress indicator of some sort. As for the 'size 0' warnings, that's normal and not an error.

Ok, finally satisfied that its ready to be put to larger-scale testing and critique. mmap generator re-written: * using Lynx3d's vmap_rewrite * using tiled navMeshes The generator is stable, but I haven't tested all of the maps. I know that some of them are imperfect, but I was generally happy with the results. I generated 1271 map tiles, and it took about 13 hours at 2.4 ghz, one thread only. Core updated * also using Lynx3d's vmap_rewrite * dynamic navmesh tile loading/unloading * updated version of recastnavigation API * several bug fixes * no more console flood added RecastDemo Helped a lot with debugging my code, including it for those that are interested. It will be more useful once I add a way to modify the generator settings at runtime. Generator Todo: * add runtime settings (config file or command line parameters) * use liquid info when building mmaps * prevent potential tile index inconsistencies * find a way to 'poke holes' in the heighmap mesh where there should be entrances (caves, stairs leading underground, etc) Core Todo: * load navmesh only into the parent map of instances * other stuff listed on my first post in this thread Again, this is still a development thread. Please post only bug reports, feedback, and suggestions. Please checkout the code from the mmaps_rewrite branch of git://github.com/faramir118/mangos.git or browse at github You can look at the list of maps here, and download them all here. These are little-endian binary data files. They go in the mmaps directory in your mangos binary directory. I can't test all of them on my own, so I offer no guarantees that they all work well. I will update my initial post to reflect these changes.

The http header says that the file is 38MB long, but my browser completes the download after only 20MB. I would say try git clone git://github.com/mangos/mangos.git If that fails, I guess github should be notified?

I think creating a key from IP and port would be better, there should never be a reason to enter the same values in a new record.

Yes, but another user posted a problem with this kind of setup. You might not be able to have two realmlist records point to the same realm because the first column is a primary key. This will work for some routers, but not all.

Perhaps the realmd.realmlist.id is the issue, since that is configured in mangosd.conf as well.

Lynx made a comment about this somewhere. In short, this isn't a problem with vmap_rewrite. vmap_rewrite just made WMO slime data available, so now wmo slime is being handled in the generic way that mangos handles all slime. mangos core doesn't know that some slime is harmless.

It wasn't the editor, it was git

Maybe something to do with unitflag PLAYER_DUEL_TEAM?