Quote:
|
Originally Posted by KhaN
Also, you cannot convert a post luclin zone to a map file, so you would fix only LOS for "old world".
|
What is the reasoning behind this statement? Just because there are no programs allready to do it?
Here are my reasons for going from an intermediate file:
1. Somebody else allready wrote the LOS code... this has been proven to me to be wrong, since it dosent work very well.
2. It takes CONSIDERABLY longer to parse a .WLD file than reading in these map dudes... even though my map files are ending up larger. And there are a few places that I could make .map reading even faster.
3. It saves the quadtree directly, you dont have to calculate it. This is a very expensive operation. On big zones it takes up to 30 seconds for my machine to read a wld file and produce the quadtree. That wont work for zone bootups at all.
4. It increases the long term longevity of the conversion program. If the w3d/wld files change, somebody dosent need to touch the emu or conversion program, they can just change the util to extract the world object. Theres a lot more zone reading utils than any other 3rd party programs.
I also have not been able to find any C++ which will get a .wld out of a zone directly, without using the windows specific eqinside.dll. So there would be that step anyways on a zone update.
My original plan was to load directly from .wld and produce a quadtree, but something is majorly wrong with the old .wld reading code I have, because the bounding box of the zone is completely wrong (much larger)... so I am currently working off .obj files spit up from DZoneConverter. I havent been able to figure out how DZC is different than my own reading code, I looked it over pretty well.
Threaded Mode
