Jump to content

Vmap Assembler Output Not Deterministic?


Recommended Posts

Hey all,

although it works nice and does its job, I always found the vmap assembler step rather time consuming when switching client versions - yes I'm a very impatient person ;)

So I decided to investigate why it was taking so long and I noticed a few ways to seriously improve its speed, so I'm working on a patch. After changing it, I tested it and checked the results against vmaps created with the original version. The results were different, so I thought I broke something - not good!

Now, after some more checking, it seems that even the original version isn't able to generate deterministic output! Starting from the very same 'buildings' folder created by the vmap extractor, and with the very same executable, I ran the assembler three times, with a different target directory of course. The .vmap files are different in each run and I wonder why? The funny thing is that the '000_27_*.vmap' files are NOT different, and I don't think it is a coincidence that these are generated first (for each map, 000 in this case, x and y go from 0 to 66 and 27 seems the first x value to 'hit something' for map 000).

My question to the devs/experts is simple: should the vmap assembler output be deterministic? If not, why not? What makes it "time" (what else?) dependant?

In case it matters: I'm still using rev 5819 (but as long as vmap code isn't changed in later revisions you can use those too) on a Linux system using wine 0.9.47 to run the vmap assembler. Running things as follows from my WoW dir:

mkdir vmaps_test && time wine vmap_assembler.exe buildings vmaps_test

Link to comment
Share on other sites

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. Privacy Policy Terms of Use