Lynx3d

Problem 1: Can't make it crash here, but Mind Control does act strange for me. But i'd say that's more likely related to the camera system, just tested with last commit before new vmaps, same result. Someone posted about extreme lag spikes possibly related to camera system, if you have freeze detection enabled, this might be your crash, but you didn't gave any useful hints really. like if your last compile already included camera system or a call stack etc... Problem 2: Enable vmaps, i'd say...

The error message indicates he isn't using 10156+ yet, otherwise the second error would be different. The first error also indicates he is using outdated map files, which is independent of vmap changes. It also clearly tells what to do

Redid branch, new solution files for extractor from vladimir, now you don't have to build libmpq solution manually first anymore. Plus some minor cleanups, see vmap_rewrite branch for details. Probably need to 'reset --hard <remote_name>/vmap_final' after fetch. Unless someone finds a serious problem, don't expect any further code changes. Of course there will always be ways to make things more automatic and fool-proof, but i have to draw a line somewhere now. The tools simply are not meant to be run from explorer by double-clicking, so i don't think adding more (pseudo-)interactivity is the way to go. You can add that to scripts etc...

If you gave at least *some* details about what doesn't work where in which environment, i *might* have a chance to look into it... The contrib folder looks just like always... Note that "vmap_extract_assembler_bin" will be updated as very final step when i am sure everything compiles as intended. Reminds me, i should remove the vmap_debugger, it doesn't work anymore, and I don't know a person that ever was able to use it anyway...

Could you guys and gals do me a favour and test this branch? (it's not really different from vmap_rewrite, just rebased) http://github.com/Lynx3d/mangos/commits/vmap_final You'll need to do the whole works, compile core+tools, extract&assemble vmaps, [update config], run core (at least a bit), pretty much like on a client switch (yea, again already, great timing, huh? ) Report anything unusual you encounter, from things you didn't understand from commit log and the pointed READMEs, errors, ugly log output, regressions... If you feel too lazy now, don't worry, i think i can guarantee that you will do the full thing anyway, just with less opportunities to ask smart questions then

Uhm...did you ever look at the option ins mangosd.conf?

Although already explained many times here... a hash function is a one-way function, you cannot decrypt it because it is not encrypted.

At least it doesn't break build on Ubuntu 10.04...

Mkay, using WotLK vmaps for 0.12...well, if you don't mind an invisible Stormwind Harbour and a few zeppelin towers around the world... Anyway, yes the M2 format changed with 3.x so extractor will not work without proper backporting.

ouch...that's one big bug... I blindly implemented the description from wow.dev wiki "(...) If that is set, it will take 0, (...)" without realizing that there exists no entry zero in LiquidType.dbc...i guess the first entry was meant, index zero with ID=1...which is just "water"... Actually, i'm guessing a lot there anyway

The commit on master has nothing to do with this, was just a random catch while looking through code... Also, the problem is not in how ACE is built, the problem is that the assembler is not even linked against ACE. And since i don't really want it for now, i changed code a bit to exclude core-related diagnostic functions (also want to be able to use log output and similar later, to not just dump errors to console) Hope it works like that...

Hm temporary solution: remove MapTree.cpp (and possibly VMapManager2.cpp) from project. Eventually i'll have to think about separating assembling and core functions better...the CMake setup just sort of auto-fixes this. However, there must be some inconsistency regarding incremental linking...but i doubt that this is the cause.

Yea it might be the lava in Blackrock etc. are actually additional objects, and not just WMO liquid. Actually from the shape and look of its texturing, i already wondered how it can work with just a uniform liquid grid...apparently, it doesn't If someone knows more, let me know...

Yea possibly the old vmap code does not freeze on such values, due to totally different data structure/algorithms, but those values are clearly waaaay beyond any valid map coords... just look at 'bool IsValidMapCoord(float c)' in GridDefines.h, i don't really see the point in checking values *again* because someone else might have forgotten his validity checks... I think i'll add an assert() actually, this will give clear indication that someone screwed up earlier...

lol... *cough* I mean, have you looked at the values? Question: Where do you think you could get when you walk -err- travel 1.3*10^29 meters in one direction? (hint: the max dimensions of a WoW map is ~3.4*10^4, one lightyear has 9.461*10^15 m)

even though that's among the top5 questions asked: It means your working copy is modified with respect to HEAD. If you don't want to keep the changes: git checkout -f git pull origin master or if you want to get rid of any merged commits from other branches too: git fetch origin git reset --hard origin/master

I think you could've done the file filtering much easier with the POSIX function fnmatch() Haven't looked at the rest yet...

http://www.kernel.org/pub/software/scm/git/docs/git-push.html

@Iowahc: vmaps never have been used for navigation, what do you think why the movemaps project was started...? Maybe it should finally be renamed to collision system or something similar...it's neither V nor maps really... Anyway, i just updated libmpq with latest SVN changes that should make it more windows friedly "out of box", someone might check if it still builds/works. Would mean some custom code less...

Hehe, let's just take Naxxramas instead...the instance object "touches" 9 tiles, and hence is referenced in all of them and will be loaded as soon as you request loading of any of them. But thinking of it, only requesting the currently processed tile may cause it to load and unload multiple times which causes some overhead too...also that chunkymesh could even help to sort out non-overlapping parts more efficiently for such big objects, but on the other hand building its spatial structure takes time too... I guess whatever you do, no miracle in performance will happen from that

Hm i see, the vmap code doesn't have any easy way to lookup models from a specific tile, that kind of information is only required at loading/unloading and hence not kept in memory. You would need to check each ModelInstance for iModel != 0. Models that span map tiles are referenced in each tile though, they have a uinique ID to prevent multiple loading/processing (in contrast to od vmap code...it only had a hack for very high poly-count models such as major cities). So there is no need to load adjacent tiles, but i guess the fully tesselated terrain is the lion's share...

Hehe yea best fix ever..."just scrap some of the data" Anyway, I don't think I understand why you need to load the whole map and use rcChunkyTriMesh anyway, to me it looks like you could just load, rasterize and unload each tile independently...

Yes i managed to infiltrate the evil developer place and joined the laugh about evil jokes...wait, you must not know that part Anyway, merging has been discussed, hence my last remark, you can either test it voluntarily, or the way Trin... *cough* I mean, the way some other project(s) makes you test it (which i have absolutely nothing to do with, btw.)

Sure...any specific reason for bumping? Just to clarify, it's basically me that is waiting for you guys... but you can also beta-test it the hard way, if you insist

Well if that kind of nit-picking is your only concern, i consider this project finished for now... There's nothing to make more efficient or correct about initializing a const float with a const expression, the MS compiler just wants to be a smart ass here IMHO... The other warning was more useful Btw. if you didn't read the commit log, you need to update you mangosd.conf, indoor check is now a bool variable. Looking forward to more feedback, now is the time to report any setup/usage problems. Oh and i think you don't need to be afraid to enable VMaps everywhere. I don't have scientifically precise numbers, but it became pretty much a moot question after the first comparison attempts, the engineer would say "it's about one order of magnitude faster"...