faramir118

3.3.3: http://www.wowhead.com/guide=3.3&models#shaman-totems I don't think you're going to get this to work without changing the core and database. There is only model info for horde male, horde female, alliance male, and alliance female. The new models are all based on race. You could maybe get away with just modifying the core - hardcode specific creature info for the totem based on caster race in Totem::Summon()? Then add all totems to DB as new creatures in creature_template Either way, need to get the displayID from CreatureDisplayInfo.dbc - I don't know the structure of that file though.

I think that may have been a typo in some makefiles - did you try with my last commit?

Our branches are merged. Windows users have to build libmpq, extractor, and assembler - do not have access to VC90 right now, so I didn't push binaries. Let me know if anybody has build errors on windows. I'll play around with redoing contrib/extractor/ so that it uses the same libmpq as contrib/vmap_extractor/

G3D now compiles on Win64. I built the assembler and MaNGOS, but I only ran the assembler. If you run MaNGOS on Win64, please pull from my repo and test it! @Lynx I think we can now merge our branches. I'll do a fresh pull of your branch, add all of the windows compatibility fixes, then run a diff and post a patch. Then you can apply it to your src to make sure it doesn't break *nix edit: my repo is at http://github.com/faramir118/mangos/commits/vmap_rewrite edit2: I pushed binaries built with VC90, so there shouldn't be an error for msvcp100.dll

pushed changes to my repo. I'm back up to 103 vmtree files. G3D x64 is closer, but still not compiling. One error I can't seem to wrap my head around.

I found the bug that was causing me to lose a lot of maps. It's something that I had added to fix a memory leak in ExtractWmo(), so it's only on my branch. I can revert the change, but I'd like to understand why it's happening. I did a lot of static analysis and debugging to try to figure out what maps should actually produce vmaps. There's only one thing left to check, hoping it might explain the three missing maps. https://spreadsheets.google.com/ccc?key=0ArW9lyUUdHChdHZTZnotQ2E3M1BIdmp6QmxndTJ3Wnc&hl=en I'll fix the x64 compile errors. I hadn't even touched the config for them yet.

My repo creates 8553 files in vmaps dir for me. I only pushed the source last night, so if you didn't do a Rebuild in VS you were probably using old code. I just pushed new binaries, you can pull and use mine. Sorry for the confusion.

Something is wrong. We aren't generating enough maps. Legend: * wdt is length 0 (all but one of these is a Transport map) ^ The name suggests that this is a test/dev map ? Not sure why this map isn't generated, need more research List of maps not being generated by my repo (commit 21021579ea9c4a63eee093e4cadd0c506959dcf1) 013 ^? test.wdt 025 ^? ScottTest.wdt 029 ^? Test.wdt 034 ? StormwindJail.wdt 035 ? StormwindPrison.wdt 042 ^? Collin.wdt 043 ? WailingCaverns.wdt 044 ? Monastery.wdt 048 ? Blackfathom.wdt 070 ? Uldaman.wdt 090 ? GnomeragonInstance.wdt 109 ? SunkenTemple.wdt 129 ? RazorfenDowns.wdt 189 ? MonasteryInstances.wdt 229 ? BlackRockSpire.wdt 349 ? Mauradon.wdt 369 ? DeeprunTram.wdt 389 ? OrgrimmarInstance.wdt 409 ? MoltenCore.wdt 429 ? DireMaul.wdt 449 ? AlliancePVPBarracks.wdt 451 *^ development.wdt 573 ^? ExteriorTest.wdt 582 * Transport176244.wdt 584 * Transport176231.wdt 586 * Transport181645.wdt 587 * Transport177233.wdt 588 * Transport176310.wdt 589 * Transport175080.wdt 590 * Transport176495.wdt 591 * Transport164871.wdt 592 * Transport186238.wdt 593 * Transport20808.wdt 594 * Transport187038.wdt 596 * Transport187263.wdt 597 ^? CraigTest.wdt 605 ^? development_nonweighted.wdt 606 ^? QA_DVD.wdt 610 * Transport_Tirisfal _Vengeance_Landing.wdt 612 * Transport_Menethil_Valgarde.wdt 613 * Transport_Orgrimmar_Warsong_Hold.wdt 614 * Transport_Stormwind_Valiance_Keep.wdt 620 * Transport_Moa'ki_Unu'pe.wdt 621 * Transport_Moa'ki_Kamagua.wdt 622 * Transport192241.wdt 623 * Transport192242.wdt 641 * Transport_AllianceAirshipBG.wdt 642 * Transport_HordeAirshipBG.wdt 647 * Transport_Orgrimmar_to_Thunderbluff.wdt 672 * Transport197347.wdt 673 * Transport197348.wdt 712 * Transport197349.wdt 713 * Transport197350.wdt 718 * Transport201834.wdt Are people seeing the same thing? Especially would like to know what vmaps are being created on linux.

You can change STRONG_MAX_LEVEL in DBCEnums.h This will set the limit for the .levelup command

I'm stupid, both you and hunuza told me exactly what I needed to hear, I just totally missed it somehow. Sorry! Reverted that change and pushed it to my repo.

Ok, then my change should be fine. It uses first file with size > 0 faramir118 = windows Lynx3d's = *nix @KAPATEJIb All of that output is just debugging. Will change it from printf to sLog.outDebug. Probably have to move all output to Map class, because assembler doesn't have sLog I am getting the message Error reading ModelSpawn! also, but haven't looked into it yet. Is it only during server shutdown? vmap.indoorCheckInterval in mangos.conf You can edit mangos.conf and then .reload config and the setting will take effect. No need to restart. Weird problem, first time I started the server I was unable to walk through some doorways. I restarted server (but didn't restart client, just disconnected) and it works fine now. I can't seem to reproduce it. Anyone else have this problem? Also, I added a .debug vmap command to my branch. It might come in handy.

Cool, I had meant to do some more encapsulation. I think that the crash is from something more complicated though. Can you describe more about it? I'll try to reproduce it and see what's making it happen.

Also available in contrib/vmap_extract_assebler_bin/ from http://github.com/faramir118/mangos/tree/vmap_rewrite

That file is over 600KB, and it is in patch.mpq and common-2.mpq. Problem was that there was a 0-size file in another mpq. I don't know which mpq is proper to pick data from, so do we just get one that has usable data? That's what my fix does. Here is my count, using my repo's code, starting with empty Buildings and vmaps directory. Buildings/ 4531 m2 6840kB 1985 wmo 252926kB 1 dir_bin 41916kB 6517 301682kB vmaps/ 6080 vmo 497744kB 2700 vmtile 53055kB 103 vmtree 10895kB 8883 561696kB

I was having a problem with 30 errors like the following: warning: file World\\Maps\\Kalimdor\\Kalimdor_45_12.adt has size 0; cannot read. I pushed a fix to my repo, and I get more vmap tiles files than before. I'm not sure if it's proper though.

I'm up and running with 3.3.3 maps. edit: 8783 files (5980 .vmo, 2701 .vmtile, 102 .vmtree), 541 MB This extractor+assembler seems much faster than the previous one! Can pull from my branch to get it running on windows. Build Instructions (make sure you change the build config to Release) * compile libmpq (located in contrib/libmpq/win) * compile extractor (located in contrib/vmap_extractor_v2/win) * compile assembler (located in contrib/vmap_assembler) * compile mangos Run Instructions: * copy contents of contrib/vmap_extract_assembler_bin to WoW directory * run makevmaps_SIMPLE.bat * copy vmaps directory from WoW directory to mangos directory I think we're ready to merge mine and yours, Lynx. There are only a few conflicts, and mine has a few additions. edit2: These two diffs are just code changes. The full diff also includes source for bzip2, zlib, and VS Solution/Project files libmpq: http://paste2.org/p/796276 extractor: http://paste2.org/p/796277

About 'invalid start or end polygon': A search box is centered on the start position. The polygon which is nearest to the start position and inside this search box is the start polygon. Same for end position and end polygon. If either the start or the end poly search box contains no polygons, then pathfinding fails. * In a lot of cases, this won't be an actual error. Flying monsters and players won't be near the navmesh, so they will generate this error. I will eventually handle this as a special case. Falling players are the same way, but I'm unsure how to find out if a player is falling. * In some cases, there is a hole in the navmesh due to incomplete data in the maps and vmaps. This is a genuine error, and for now the problem is solved by using the old mangos behavior (just go from start position to end position in a straight line, ignore obstacles) I need some assistance with map and vmap in order to correct the problem, fill in the holes in the mmap.

For [9796] Add missing file and missing include directory: http://paste2.org/p/795801

Yup, 40manarmygeneral.wmo actually reads one groupmodel, then crashes on the second because it has 0 vertices. PS - Thanks for that tip about push_front earlier, fixed my problem. I need to keep track of what I change better

ceruleaus was very close! The crash is at WorldModel.cpp:129, GroupModel::writeToFile() if (result && fwrite(&vertices[0], sizeof(Vector3), count, wf) != count) result = false; error is vector subscript out of range Will have to find out which is the problem: * Vertex info not getting written to disk? (in extractor) * Vertex info not getting read? (in assembler convert) * Some models don't have vertex info?

Ah damn, my bad. The reason why I did that is because at one point I had changed gOpenArchives to a vector instead of a deque - I was trying to fix the crash at if(gOpenArchives.front() != archive) but eventually switched to checking the error code. Nothing else seemed to work for me. Anyway, I'll change it and test again. And I'll try to debug the assembler in VS to see what the deal is. My dev machine went down yesterday though, and I'm just now getting the OS running. It will be a little bit before I can get back into the swing of things.

My dev machine bit the dust yesterday and I just finished reinstalling the OS. Data is still intact, no worries. Should be able to make some progress now. Generating the mmaps is most likely a waste. BUT... There may be a chance I can merge multiple navmeshes into a tiled navmesh, but I haven't really gotten nearly fall enough to tell. Can't really say at this point.

I've done a little bit of work towards using a tiled navmesh, but not much. I've been busy with work, and most of my mangos coding at the moment are going towards vmap rewrite - figured that because mmaps relies on vmap data, I'd better see what's changing and expedite that if I could

I made some changes so that the extractor would run correctly on windows. Problems I'm having: * some maps aren't getting loaded I noticed that Map.dbc is stored in multiple mpq archives. Is Map.dbc split across multiple mpqs, or something? (sorry, I'm clueless about this sort of thing) * Having an error with WMO group ND_Forsaken_Apothecary.wmo * assembler crashes while converting wmo files I uploaded the output from extractor + assembler: http://paste2.org/p/790489 Look at lines 29, 34, 200, 211, and the last few lines. And of course, the map count is only 118

Hrm, I hadn't tried to compile my changes into the extractor. I'll work on it and push the changes to my repo. I fixed an overflow bug in libmpq that was making it error on files toward the end of large mpqs. Very weird issue... typedef long off_t; typedef __int64 libmpq__off_t; typedef __int64 longlong; off_t = uint32 + longlong + uint32 // overflow, ends up being negative libmpq__off_t = uint32 + longlong + uint32 // fixes error