Unknown Worlds Entertainment

Latest download: ZHLT 1.7p15
Earlier versions: ZHLT 1.7p13
Cagey's full source code: ZHLT 17p15.5 source Note: when using the source code, you should refer to my notes on page 33 of this topic.

For those who aren't aware, this is an update of Merl's 1.7 Custom Build of Zoner's tools. All of the features that Merl and Zoner added are still available in this distribution.

See the red notes below for important information on the latest build.

When you posted there wasn't, but I've gotten Merl's permission to post modified copies of version 1.7 with MAX_MAP_PLANES set to 65535. Replace your build tools with these versions and you'll be able to compile bsps with over 32767 planes. Then use my optimizer (included in the zip files) to make them safe for the game again. I'm putting them into two zip files since they're over the 122880 byte max file limit in a single download.

To use my optimizer, you can drag and drop your bsp file over it. The program overwrites the original file, so make a backup if you want to preserve the unoptimized copy. **Note -- since this program shrinks the map, it will checksum differently -- if a server is running the unoptimized copy and you have the optimized, it might not let you connect **.

Once the map is optimized, HLCSG -onlyents and HLRAD will break (make the optimization the final step when you're compiling), but it will run fine in the game.

EDIT: If you get a 'file not found' error when running the tools, look at Ollj's post below, he has a solution to the problem. You can get the DLL he talks about here. If you still can't get the tools to run, two people have reported needing a second DLL you can grab from here, but others seem to be OK without it.

EDIT 2/4/03: updated opt_plns to version 1.2, fixing the crash on bsp file not found and fixing a rare case of corrupted data for the first plane on the map.

EDIT 2/5/03: updated opt_plns (in first download) again to version 1.3, fixing a crash bug above 32K planes and adding an option (-nopause) to skip the keypress prompt at the end of execution. The updated opt_plns is available as a separate program on the 4th page of this thread. Unless another bug is found, this should be the last update for a while.

EDIT 2/8/03: well that was dumb of me . I posted the opt_plns zip instead of the modified tools 1 zip that includes the new opt_plns here -- thanks to [builder]hicks for helping me catch the problem.

EDIT 2/11/03: updated opt_plns again to version 1.4, removing internal limits on texdata, visdata, and lightdata. Also added a -logfile <filename> switch and made input filename parsing more forgiving.

EDIT 2/21/03: updated the tools to release 1.7p3, which speeds up HLCSG and fixes several clipping bugs as detailed here. There is a thread talking about the HLCSG changes here. You'll want to download the second attachment again if you have grabbed these files before.

EDIT 3/13/03: updated the tools to release 1.7p4, which contains a threadlock bugfix, code that is more friendly to concave brushes, and a new -cliptype normalized option. More details are available here.

EDIT 4/09/03: updated the tools to release 1.7p5, which added some new features and made some optimizations. More details are available here.

EDIT 4/10/03: the 1.7p5 zipfiles contained the wrong version of the tools yesterday--my apologies to the 11 people who downloaded those files -- the links are now correct.

EDIT 4/10/03: quick turnaround to version 1.7p6 to fix a show stopping bug related to the new BEVEL texture code in HLCSG.

EDIT 4/13/03: released 1.7p7 added texlight support back into the tools and fixed problem of "too many direct lightstyle" message spam (you now will see the message once instead of every time the problem occurs). This is a stable release.

EDIT 4/17/03: some people have had problems with the new lighting code, so I've added a switch, -oldmath, to RAD that allows using the older basic math functions. The new release has been tagged 1.7p8.

EDIT 5/4/03: the -oldmath tag has been deprecated since I found the source of the problem. Also added support for the SDK 2.2 hull file format. Released as 1.7p9.

EDIT 5/8/03: fixed a bug in opaque entity handling, released as 1.7p10.

EDIT 8/15/03: maintenance release -- throw fatal error on buffer overflows that used to be silent, added location information to "too many lightsamples" error, using -verbose on HLRAD now displays ALL of those errors (there can be thousands in a single map). Added "-lightdata #" command so that people can add extra lightdata to their maps--doing this, like adding texdata, will require you to test your map on low-end machines to make sure that people can play your map. Released as 1.7p11

EDIT 8/22/03: Rolling back publicly available release to p10 due to lighting bug report. Will release p11 again once the bug has been resolved.

EDIT 10/3/03: Resolved the issue in p11, commented out spamming would-be developer message from HLRAD, reset default lightdata limit back to 6MB. Thanks to Kage and WolfWings for testing the release cantidates.

EDIT 2/3/04: p13: Fixed bug in creation of objects without clip hulls, fixed bug in info_compile_parameters entity handler, changed usage of zhlt_noclip and zhlt_invisible to allow inclusion of those properties in .fgd files. Added Hullu's latest lighting enhancements.

EDIT 6/1/04: p14: Fixed bug that caused errors building under default steam installs. Added switch to turn off light bounces for dynamic lights. Built optimizer into HLBSP. Raised internal plane limit to 256K. Added Reve's overhauled documentation.

EDIT 6/3/04: p15: Fixed filehandler crash bug. Fixed face index crash bug. Added switch to turn off plane optimization. Fixed SolidBSP display times. Fixed bug with opaque entity lighting. Changed chart output to display planes percentage based on Half-Life plane limit.

EDIT 8/15/04: source release: I've released my latest source a few days ago since I've been hired by a game company and won't be working on ZHLT any more. Notes about the release are in the original posting on page 33 of this topic; I forgot to post a first-page update when I uploaded the source, but it's here now.

Enjoy!

Latest download: ZHLT 1.7p15

ok i just did a test with my map (not maxplanes reachd zet tough) but reducing planes. it went (according to the tool) from 6622 to 2047 and ran without any problem. XP-Cagey, i just can say WOAH! i hope i don´t run into any problems with this later on. but currently it seems to be absolutely amazing and gives me MUCH more room to build what i want. still nodes and such to keep an eye on but hell, this really is GREAT! Now i need to build a shrine.. you want red white or black candles?

Keep it up, this is one of the best additions to zoners! lets hope it gets official with the next release of ZHLT. You .

Im now compiling with the 1.7p toops

my OS has missing the file
MSVCR70.DLL
too bad that the hammer-compiler does not tell me that, it just says "file not found".
Just another batch compiler told be about the missing dll, so I asked google about it...

QUOTE

This DLL is needed by applications compiled to use the Microsoft Foundation Classes (MFC) as a DLL, and compiled on a machine that has the Microsoft .NET SDK installed on it.  This is no different than older MFC runtime DLL requirements; it's just that this is a very new runtime DLL and most folks don't have it.  The system running this application (mapserver, compiled this way) also must have Microsoft Internet Explorer 4.0 or higher installed on it, since the runtime uses components from IE as well.

You can get this file anywere on the internet.
Copy it in your main system directory or in system32 .

well,
the compiling succeded:

QUOTE

Object names  Objects/Maxobjs  Memory / Maxmem  Fullness ------------  ---------------  ---------------  -------- models            196/400        12544/25600    (49.0%) planes          31086/65535     621720/1310700  (47.4%) vertexes         4765/65535      57180/786420   ( 7.3%) nodes            2504/32767      60096/786408   ( 7.6%) texinfos         6504/32767     260160/1310680  (19.8%) faces            3681/65535      73620/1310700  ( 5.6%) clipnodes       12193/32767      97544/262136   (37.2%) leaves           1771/8192       49588/229376   (21.6%) marksurfaces     3926/65535       7852/131070   ( 6.0%) surfedges       16234/512000     64936/2048000  ( 3.2%) edges            8181/256000     32724/1024000  ( 3.2%) texdata          [variable]       2380/4194304  ( 0.1%) lightdata        [variable]          0/4194304  ( 0.0%) visdata          [variable]          0/2097152  ( 0.0%) entdata          [variable]      17394/524288   ( 3.3%) 54 textures referenced === Total BSP file data space used: 1357738 bytes === 119.95 seconds elapsed [1m 59s]

the map is half-completed (raw hallways) and already touches the 90% limit, because its BIG.
now its 50% and I hope the compression tool cuts enough planes from the void.

This post has been edited by Ollj: Jan 27 2003, 01:07 AM

You **** genius! GENIUS!

This is absolutely superb. I love you.

Makes you wonder what the official maps would have been like if they hadn't hit the plane limit...

Now we may find out.

I was quite sure there was more to it than changing a preprocessor directive in the compiler source, since Merl had so much trouble working with it. Oh well.

So far it seems to work. A test map shrunk from 2080 planes to 484, and seems to run fine in-game.

QUOTE (Yamazaki @ Jan 26 2003, 03:31 PM)

I was quite sure there was more to it than changing a preprocessor directive in the compiler source, since Merl had so much trouble working with it. Oh well.

Merl had bumped up the defined amount before, then knocked it back down when it caused in-game problems. This is a source comment embedded at the point of the directive:

CODE

#define MAX_MAP_PLANES      32767 // (from email): I have been building a rather complicated map, and using your latest // tools (1.61) it seemed to compile fine.  However, in game, the engine was dropping // a lot of faces from almost every FUNC_WALL, and also caused a strange texture // phenomenon in software mode (see attached screen shot).  When I compiled with v1.41, // I noticed that it hit the MAX_MAP_PLANES limit of 32k.  After deleting some brushes // I was able to bring the map under the limit, and all of the previous errors went away.

The problem has always been game engine based rather than something with the compiler. I suspect that the half-life engine uses a 32K sized static array for storing the loaded planes, and loses information when this is exceeded. There isn't anything magic about the 32K plane limit (it's not a hardware concern like the 4MB texture limit, for instance), and I'm willing to bet it was a semi-arbitrary size placed by the programmers when 400 was considered a high r_speeds value (akin to "nobody will ever need over 640K of memory" ).

Oh i almost forgot, could this get a STICKY maybe? pretty please?

sticky good. - so edited

This post has been edited by Ollj: Jan 27 2003, 04:49 AM

thanks for the tools, ive started to add alot more detail in now. theyre so helpful, where the hell did u learn to code on that sort of level!? youd think valve would know how to do this, personally i reckon you should send the link to planethalflife.com - im sure they would get out the word about the download as it helps all the community!

Its a great set of tools, helped me out a bunch! Brings my map from 4k to 1k planes

that is quite amazing, not to mention incredibly useful.

i can even detail my map further now... god i wub j00

I'm not at home right now so I can't try this out, but has anyone tried this on a map which has already exceeded the max planes (which is why it's there, obviously)?

In my experience, if the map has too many planes in it then you can't fully compile the map anyway. If you've removed this 'lock', then kudos to you and congratulations on producing such a useful tool. But, if you still can't compile maps which originally have too many planes (before the optimisation), then that makes this kinda useless.

QUOTE (Merkaba @ Jan 27 2003, 10:31 AM)

If you've removed this 'lock', then kudos to you and congratulations on producing such a useful tool.

Yep, it's been moved up to about double what it was before (65535 now). If that's still not high enough, another recompile can shift it upwards again... the only limitation for the compiler tools (I'm not talking about running the game itself here) is the amount of memory required to store the information while it's being processed.

EDIT: shifting the limit upward again will require storing the information outside of the bsp during the compile because the bsp face structure's plane number field can only hold 16 bits.

This post has been edited by XP-Cagey: Mar 13 2003, 09:41 PM

Amazing, congrats! This may lead to a whole new level of complex levels

Give us Big Hera. Now. Please?

QUOTE (Merkaba @ Jan 27 2003, 10:17 PM)

Amazing, congrats! This may lead to a whole new level of complex levels

Damn straight!

http://www.cyscape.com/download/msvcr70.dll

Theres an URL to the .DLL if you can't find it or want it instantly.

QUOTE (Revenant @ Jan 27 2003, 10:19 PM)

http://www.cyscape.com/download/msvcr70.dll Theres an URL to the .DLL if you can't find it or want it instantly.

Thanks for tracking that down Rev -- added a copy of the link to the first post so people will see it