<!--QuoteBegin--XP-Cagey+Dec 21 2003, 08:34 PM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (XP-Cagey @ Dec 21 2003, 08:34 PM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> I do plan on integrating Hullu's updated custom shadows (thanks for the thread link Reve) once I get permission to do so and after the holidays. <!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd--> Ofcourse you get permission <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->
--edit-- Oh yeah.. If you need help with porting to linux.. try me <!--emo&;)--><img src='http://www.unknownworlds.com/forums/html/emoticons/wink.gif' border='0' style='vertical-align:middle' alt='wink.gif'><!--endemo--> I even managed to port MHLT 1.7 for SunOS.
<!--QuoteBegin--FragBait0+Dec 22 2003, 06:04 PM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (FragBait0 @ Dec 22 2003, 06:04 PM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> Anyone looked at the zhlt_invisible and zhlt_noclip options? They work great for me particuarly in some SoHL maps-- func_shine dosent need clipnodes.
Why Im really posting is to ask if those options could/should be made like on/off? EDIT: settable to 0 or 1. Rather than just putting something in the box? (I added them to my FGDs <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo--> ) I reckon it would make more sense like that as they are on/off settings...
Oh btw XP-Cagey: these tools are quite fantastic. mad props. <!--QuoteEnd--> </td></tr></table><span class='postcolor'> <!--QuoteEEnd--> I've done this for p13 - a string of "0" is now equivalent to removing the attribute; any other string will turn the effect on.
I've also fixed a HLBSP bug that causes entities with empty clip information (the head node set to CONTENTS_EMPTY and no children) to use the clip hull of the next entity on the map--zhlt_noclip will work as intended in all cases for p13.
oh cool cagey. I just thought it makes more sense like that <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->
so ones reach the point, where the MAXPATCHES error appears. using the newest compiling tools wouldnt help it... cause they dont work like exspected. I usd the p10 (I think its the p10) quite a while and its working fine. but when I want to change to the p12, there is allways he same line in the compiler window: executing hlXXX.exe
and nothing more there is not a bit of compiling.
have the new compile tools to be set up in a different way?
<!--QuoteBegin--Lt.Gravity+Jan 2 2004, 03:36 AM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (Lt.Gravity @ Jan 2 2004, 03:36 AM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> so ones reach the point, where the MAXPATCHES error appears. using the newest compiling tools wouldnt help it... cause they dont work like exspected. I usd the p10 (I think its the p10) quite a while and its working fine. but when I want to change to the p12, there is allways he same line in the compiler window: executing hlXXX.exe
and nothing more there is not a bit of compiling.
have the new compile tools to be set up in a different way? <!--QuoteEnd--> </td></tr></table><span class='postcolor'> <!--QuoteEEnd--> When you updated, did you keep the 2 dlls required for the tools to work? If you didn't, you can either download the full install from my site or grab the dlls from the first post in this thread.
ok now I understand it. thx. will test the compile with the new tools. he problem is the huge number of patches in hl rad. hopefully it comes to a happy end ^^
Cagey, as requested in the MHLT thread on VERC, could you include the ZHLT docs (and the docs from MHLT) - preferably all merged into one nice set of coherent readme docs - in p13? I know it's hosted on VERC, but it makes so much sense to have them all in one place and with the newest tools themselves, and your tools are really the only ones in active development that I'm aware of.
Any idea when p13 will be out? You said hullus custom shadow code is going into that release am I right? Or was it only going to appear in the 'new' tools (when they come out).
<!--QuoteBegin--Reve+Jan 3 2004, 11:54 AM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (Reve @ Jan 3 2004, 11:54 AM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->Cagey, as requested in the MHLT thread on VERC, could you include the ZHLT docs (and the docs from MHLT) - preferably all merged into one nice set of coherent readme docs - in p13? I know it's hosted on VERC, but it makes so much sense to have them all in one place and with the newest tools themselves, and your tools are really the only ones in active development that I'm aware of.
Any idea when p13 will be out? You said hullus custom shadow code is going into that release am I right? Or was it only going to appear in the 'new' tools (when they come out).
Keep up the good work!
Reve<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd--> I'm adding Hullu's code to p13. I've already added and tested some bug fixes (EDIT: <i>bugs in MY code, not Hullu's!</i>), and my TO-DO list looks like this:
<ul><li>Add Hullu's new lighting code to RAD (possibly merging my fast math code with his build rather than moving his stuff into my build if that's easier)<li>Add support for overriding inclusion of common textures like AAATRIGGER, CLIP, HINT, SKIP, SKY, ORIGIN, etc. directly into maps. NULL was originally on this list, but I've removed it because NULL isn't distributed by Valve. I suspect that embedding the textures into the map is causing issues with custom handling for AAATRIGGER and SKY, a theory that I'm testing with the change.<li>Compile documentation for all of the tool versions into a single location, probably as a series of links to each version's documentation initially. I'll probably write a comprehensive feature guide (command line features and custom entity extensions) eventually, but not for p13 because it's a big job and I don't want to delay the release. The next section of my website will be a "projects" section that will include a FAQ on ZHLT and the updated documentation, which I'll also distribute with the downloads (slated for p14+).</ul>I upgraded my development environment from Visual Studio.Net (7.0) to Visual Studio .Net 2003 (7.1) after I released p12, which means that the required DLLs for p13 are going to change (pain in the butt, I know, but I'll be releasing the next version bundled with the DLLs in place so people don't have to go hunting. The new DLLs will be MSVCP71.DLL and MSVCR71.DLL, which are the runtimes for .Net 2003 C and .Net 2003 C++ extensions like the C++ standard library.
I don't like committing to release dates because Real Life often intervenes, but I feel relatively safe saying that p13 will be out by the 10th.
<!--QuoteBegin--XP-Cagey+Jan 3 2004, 05:50 PM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (XP-Cagey @ Jan 3 2004, 05:50 PM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> <!--QuoteBegin--Reve+Jan 3 2004, 11:54 AM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (Reve @ Jan 3 2004, 11:54 AM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->Cagey, as requested in the MHLT thread on VERC, could you include the ZHLT docs (and the docs from MHLT) - preferably all merged into one nice set of coherent readme docs - in p13? I know it's hosted on VERC, but it makes so much sense to have them all in one place and with the newest tools themselves, and your tools are really the only ones in active development that I'm aware of.
Any idea when p13 will be out? You said hullus custom shadow code is going into that release am I right? Or was it only going to appear in the 'new' tools (when they come out).
Keep up the good work!
Reve<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd--> I'm adding Hullu's code to p13. I've already added and tested some bug fixes (EDIT: <i>bugs in MY code, not Hullu's!</i>), and my TO-DO list looks like this:
<ul><li>Add Hullu's new lighting code to RAD (possibly merging my fast math code with his build rather than moving his stuff into my build if that's easier)<li>Add support for overriding inclusion of common textures like AAATRIGGER, CLIP, HINT, SKIP, SKY, ORIGIN, etc. directly into maps. NULL was originally on this list, but I've removed it because NULL isn't distributed by Valve. I suspect that embedding the textures into the map is causing issues with custom handling for AAATRIGGER and SKY, a theory that I'm testing with the change.<li>Compile documentation for all of the tool versions into a single location, probably as a series of links to each version's documentation initially. I'll probably write a comprehensive feature guide (command line features and custom entity extensions) eventually, but not for p13 because it's a big job and I don't want to delay the release. The next section of my website will be a "projects" section that will include a FAQ on ZHLT and the updated documentation, which I'll also distribute with the downloads (slated for p14+).</ul>I upgraded my development environment from Visual Studio.Net (7.0) to Visual Studio .Net 2003 (7.1) after I released p12, which means that the required DLLs for p13 are going to change (pain in the butt, I know, but I'll be releasing the next version bundled with the DLLs in place so people don't have to go hunting. The new DLLs will be MSVCP71.DLL and MSVCR71.DLL, which are the runtimes for .Net 2003 C and .Net 2003 C++ extensions like the C++ standard library.
I don't like committing to release dates because Real Life often intervenes, but I feel relatively safe saying that p13 will be out by the 10th. <!--QuoteEnd--> </td></tr></table><span class='postcolor'> <!--QuoteEEnd--> Will that require the .net framework Xp-Cagey?
<!--QuoteBegin--Thursday-+Jan 3 2004, 03:51 PM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (Thursday- @ Jan 3 2004, 03:51 PM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> Will that require the .net framework Xp-Cagey? <!--QuoteEnd--> </td></tr></table><span class='postcolor'> <!--QuoteEEnd--> No, just the two MS runtime DLLs I mentioned above.
Just out of curiosity is there any way we can see a teaser feature list for the new tools? (not the p series, but the new new ones) Also is there anything that can be done to help improve/expedite this whole deal?
<!--QuoteBegin--Reese+Jan 3 2004, 09:41 PM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (Reese @ Jan 3 2004, 09:41 PM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->Just out of curiosity is there any way we can see a teaser feature list for the new tools? (not the p series, but the new new ones) Also is there anything that can be done to help improve/expedite this whole deal?<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
I think a teaser list would probably just frustrate mappers <!--emo&:(--><img src='http://www.unknownworlds.com/forums/html/emoticons/sad.gif' border='0' style='vertical-align:middle' alt='sad.gif'><!--endemo-->.
I haven't talked much about the rewrite because I don't want a situation like the Nancy project where people are feeling jumpy about getting the project out the door. I'm less than halfway done with the actual coding of the tools, although I've got much more than that architected and ready for implementation. I'm currently working with the NS team on a few projects that are also taking some of my time. For now I can only say, "the tools will be out when they're done".
This isn't a list of features from an end-user standpoint, but here are the main reasons why I bothered rewriting the tools in the first place:<ul><li><i>major</i> speed improvements over ZHLT, even on a single CPU<li>internal process management system supports distributed computing with remote procedure calling<li>swappable component libraries for specialized code implementations (extended CPU instruction sets, 64 bit architectures)<li>well-defined object oriented framework for easier debugging and unit testing<li>plugin interface (which I'm using to implement the core functionality of the tools: the equivalent of CSG, BSP, VIS, and RAD)<li>reference counted map resources mean never having unused filler again (no more opt_plns)<li>not game specific (core is generic enough to compile for multiple engines; importer, exporter, and resource translation library interfaces make that practical)</ul>You'll like the tools when you can finally use them <!--emo&;)--><img src='http://www.unknownworlds.com/forums/html/emoticons/wink.gif' border='0' style='vertical-align:middle' alt='wink.gif'><!--endemo-->.
<!--QuoteBegin--XP-Cagey+Jan 4 2004, 03:47 AM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (XP-Cagey @ Jan 4 2004, 03:47 AM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> <ul><li>not game specific (core is generic enough to compile for multiple engines; importer, exporter, and resource translation library interfaces make that practical)</ul>You'll like the tools when you can finally use them <!--emo&;)--><img src='http://www.unknownworlds.com/forums/html/emoticons/wink.gif' border='0' style='vertical-align:middle' alt='wink.gif'><!--endemo-->. <!--QuoteEnd--> </td></tr></table><span class='postcolor'> <!--QuoteEEnd--> So are you saying this could potentially be hl2 compile tools as well? (also q3, and basically any other bsp based engine, but most people will want to know about hl2) If so then I think that's awesome. Lots of good work in there.......... Now if only it could make me a better mapper <!--emo&;)--><img src='http://www.unknownworlds.com/forums/html/emoticons/wink.gif' border='0' style='vertical-align:middle' alt='wink.gif'><!--endemo-->
<!--QuoteBegin--Reese+Jan 4 2004, 05:34 PM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (Reese @ Jan 4 2004, 05:34 PM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--><!--QuoteBegin--XP-Cagey+Jan 4 2004, 03:47 AM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (XP-Cagey @ Jan 4 2004, 03:47 AM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> <ul><li>not game specific (core is generic enough to compile for multiple engines; importer, exporter, and resource translation library interfaces make that practical)</ul>You'll like the tools when you can finally use them <!--emo&;)--><img src='http://www.unknownworlds.com/forums/html/emoticons/wink.gif' border='0' style='vertical-align:middle' alt='wink.gif'><!--endemo-->. <!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd--> So are you saying this could potentially be hl2 compile tools as well? (also q3, and basically any other bsp based engine, but most people will want to know about hl2) If so then I think that's awesome. Lots of good work in there.......... Now if only it could make me a better mapper <!--emo&;)--><img src='http://www.unknownworlds.com/forums/html/emoticons/wink.gif' border='0' style='vertical-align:middle' alt='wink.gif'><!--endemo--><!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd--> Yeah -- I want to target a superset of multiple engines' features and then let exporters handle engine specific conversions (like attempts to put a Q3 style patch in a Half-Life map). Since data storage requirements differ between engines (especially when defining clip information or visual bells and whistles like patches or detail brushes), the internal format probably won't match any specific game's requirements. It will be up to the exporters to fill any gaps between what's presented by the compiler and what the file format expects.
One early example of this problem is the generation of Half-Life's three clip hulls. Many modern engines use a single hull and shift its planes at runtime to accomodate arbitrary player sizes. I'll probably have the compiler generate a single unshifted hull and make the HL exporter generate the three actual hulls using the unshifted input from the compiler as a reference... generating a properly beveled unshifted hull and converting the shifted planes back into a well-formed BSP tree without any spacial overlapping are computational geometry problems I'm still solving (looking for published solutions and attempting to solve them my own through case studies, which is what I ended up doing for the precise clip algorithm). I have some ideas, but nothing final--I know this problem has been solved before <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->.
I don't know how much time the HL(1) engine has left, but I really wouldn't want to invest hundreds of hours into a new compiler system that won't be used in a few years <!--emo&;)--><img src='http://www.unknownworlds.com/forums/html/emoticons/wink.gif' border='0' style='vertical-align:middle' alt='wink.gif'><!--endemo-->.
Of course. HL1 is almost too old to create new systems for if they can't be used with HL2. I don't think you could get much info out of valve but you could try asking for some engine related questions so you could prepare the compilers for HL2. I do hope that valvle releases the new HL2 compilers as open source so you can take a look at them <!--emo&:D--><img src='http://www.unknownworlds.com/forums/html/emoticons/biggrin.gif' border='0' style='vertical-align:middle' alt='biggrin.gif'><!--endemo-->
Now this is a point where I would also like to take a look at the source. I'm very much interested in the new model format to get it into QuArK as soon as possible, because I don't have much time to code in the next months and the QuArK users will all go to Hammer for their maps because the devs just don't know the bsp, texture and model formats. Admit Cagey, that you already have some leaked .bsps on your hard disk <!--emo&;)--><img src='http://www.unknownworlds.com/forums/html/emoticons/wink.gif' border='0' style='vertical-align:middle' alt='wink.gif'><!--endemo--> (On a side note: I just wrote a 9 pages long description of the Half-Life 1 model format... don't want to know what the new engine brings <!--emo&:(--><img src='http://www.unknownworlds.com/forums/html/emoticons/sad.gif' border='0' style='vertical-align:middle' alt='sad.gif'><!--endemo--> - if anyone has a question about Half-Life models feel free to PM me) Er...Cagey...while you are at it - would it be possible to create a short version of this hull creator just to convert ns-maps with wrong hulls to the 2.0 format? At least the code base will exist in the final tools, so that would be quite useful for all the stupid clans that convert CS maps to NS, too <!--emo&;)--><img src='http://www.unknownworlds.com/forums/html/emoticons/wink.gif' border='0' style='vertical-align:middle' alt='wink.gif'><!--endemo-->
Or make it fix maps like ns_nancy <!--emo&;)--><img src='http://www.unknownworlds.com/forums/html/emoticons/wink.gif' border='0' style='vertical-align:middle' alt='wink.gif'><!--endemo-->
Cagey is the new hero of HL Mapping <!--emo&:D--><img src='http://www.unknownworlds.com/forums/html/emoticons/biggrin.gif' border='0' style='vertical-align:middle' alt='biggrin.gif'><!--endemo-->
That is just what I meant, Andos, but they already built a new Nancy and I don't want to make Lazer, DarkATI, WolfWings and last not least the guy that created the new decompiler feel like their work becomes useless. But yeah, all we need is a BSP importer - that XP-Cagey might already include with the first or second release, a newly coded 'filter' to rearrange the hulls (or delete the old ones and let the tools recreate them) and use the bsp exporter that is included. Simply amazing XP-Cagey! But that is another story. If someone REALLY have a well thought feature request then it should be posted somewhere, but the new tool set is still far away. Only coders already have to be very excited about it <!--emo&;)--><img src='http://www.unknownworlds.com/forums/html/emoticons/wink.gif' border='0' style='vertical-align:middle' alt='wink.gif'><!--endemo-->
You mean something like this Nerd ... <a href='http://collective.valve-erc.com/index.php?news=1072935576-17869900' target='_blank'>Valve-Erc</a>.
Btw Cagey I love the work you did with the tools. Keep up the good work <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo--> I am keeping part of the DoD community up to par with your new stuff also.
no...I mean Cagey will have to write some sort of BSP decompiler to XP-Cagey-format. If all works well no 'real' decompiler would be needed, just some new clipping hulls...hopefully. But I'm not too familiar with the bsp format.
Yeah! I can't find those docs <i>anywhere</i>. Google failed me. <!--emo&:(--><img src='http://www.unknownworlds.com/forums/html/emoticons/sad.gif' border='0' style='vertical-align:middle' alt='sad.gif'><!--endemo-->
amckern: Zoners docs are _not_ included in MHLT 1.7 - they are hosted on VERC but are not in the zip. Read the MHLT 1.7 thread for more info. This p series doesn't include either, and simply having the two sets of docs would be handy especially for mappers finding their way here for the first time and people who have lost the files and don't want to go to three places to get all the tools and docs they need for compiling (and as MHLT isn't being updated it won't have the ZHLT docs put in there).
Cagey - do any of the compile tools variations (ZHLT, MHLT, p series) support compiling Blue Shift maps? The thought only came up after reading the thread about the new decompiler, BSPTwoMap. In particular, this post:
<!--QuoteBegin--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> </td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->It can't handle Blue Shift maps. From my questionable memory, I seem to recall someone posting a few times that he discovered how to edit Blue Shift bsps to make them viewable/decompilable/editable. I think he said that the first two sets of 8 byte chunks in the bsp file were switched specifically to prevent decompilation. I tried switching them back (without really knowing what I was doing) and could not get winbspc to work on it.<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
The guy who wrote the decompiler has enabled it to now decompile Blue Shift maps. I was thinking, if the current compile tools don't support creating maps in that format, could it be added, perhaps by adding an argument -blueshift which would just swap round the stuff in the final map as required.
Also, has anyone tried using opt_plns on blue shift maps (yes I know you can't play an opt_plns map with a someone with the non optimised map version) but out of interest, does it work? If not, perhaps opt_plns could be updated? I think it seems pretty easy from what has been said in the decompilation thread.
I guess if no-one has tried doing any of this, it's because no-one really plays Blue Shift, but having it in the compile tools would have a nice 'kitchen sink' feeling about it <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->
<!--QuoteBegin--NerdIII+Jan 5 2004, 03:57 PM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (NerdIII @ Jan 5 2004, 03:57 PM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> no...I mean Cagey will have to write some sort of BSP decompiler to XP-Cagey-format™. If all works well no 'real' decompiler would be needed, just some new clipping hulls...hopefully. But I'm not too familiar with the bsp format. <!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd--> Ryan Gregg (Nemesis) most famous for his batch compiler has made a program called BSP View. I'm assuming this works by opening up the BSP and creating a temporary .map of the level to be in the view with the BSP. I figured this out as it allows you to view all the basic areas of the map such as the 'AAATrigger' setting on a CS Bomb area, although it does not create any lighting. I am not so sure if a .map could be saved from it that it would be so stable, although everything from the original map would be correct.
<a href='http://www.planetquake.com/quark' target='_blank'>QuArK</a> has had viewing of BSP files to an extent for ages. Creating a .map from a .bsp is not as simple as just being able to view a BSP.
BSP View can see ligting as well but it isn't good at it. Especially not for NS maps because we can't see the gamma effect on it and some textures can't be made transparent.
Comments
Ofcourse you get permission <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->
--edit--
Oh yeah.. If you need help with porting to linux.. try me <!--emo&;)--><img src='http://www.unknownworlds.com/forums/html/emoticons/wink.gif' border='0' style='vertical-align:middle' alt='wink.gif'><!--endemo-->
I even managed to port MHLT 1.7 for SunOS.
They work great for me particuarly in some SoHL maps-- func_shine dosent need clipnodes.
Why Im really posting is to ask if those options could/should be made like on/off? EDIT: settable to 0 or 1.
Rather than just putting something in the box? (I added them to my FGDs <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo--> )
I reckon it would make more sense like that as they are on/off settings...
Oh btw XP-Cagey: these tools are quite fantastic. mad props. <!--QuoteEnd--> </td></tr></table><span class='postcolor'> <!--QuoteEEnd-->
I've done this for p13 - a string of "0" is now equivalent to removing the attribute; any other string will turn the effect on.
I've also fixed a HLBSP bug that causes entities with empty clip information (the head node set to CONTENTS_EMPTY and no children) to use the clip hull of the next entity on the map--zhlt_noclip will work as intended in all cases for p13.
using the newest compiling tools wouldnt help it... cause they dont work like exspected.
I usd the p10 (I think its the p10) quite a while and its working fine. but when I want to change to the p12, there is allways he same line in the compiler window:
executing hlXXX.exe
and nothing more
there is not a bit of compiling.
have the new compile tools to be set up in a different way?
using the newest compiling tools wouldnt help it... cause they dont work like exspected.
I usd the p10 (I think its the p10) quite a while and its working fine. but when I want to change to the p12, there is allways he same line in the compiler window:
executing hlXXX.exe
and nothing more
there is not a bit of compiling.
have the new compile tools to be set up in a different way? <!--QuoteEnd--> </td></tr></table><span class='postcolor'> <!--QuoteEEnd-->
When you updated, did you keep the 2 dlls required for the tools to work? If you didn't, you can either download the full install from my site or grab the dlls from the first post in this thread.
he problem is the huge number of patches in hl rad. hopefully it comes to a happy end ^^
Any idea when p13 will be out? You said hullus custom shadow code is going into that release am I right? Or was it only going to appear in the 'new' tools (when they come out).
Keep up the good work!
Reve
Any idea when p13 will be out? You said hullus custom shadow code is going into that release am I right? Or was it only going to appear in the 'new' tools (when they come out).
Keep up the good work!
Reve<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
I'm adding Hullu's code to p13. I've already added and tested some bug fixes (EDIT: <i>bugs in MY code, not Hullu's!</i>), and my TO-DO list looks like this:
<ul><li>Add Hullu's new lighting code to RAD (possibly merging my fast math code with his build rather than moving his stuff into my build if that's easier)<li>Add support for overriding inclusion of common textures like AAATRIGGER, CLIP, HINT, SKIP, SKY, ORIGIN, etc. directly into maps. NULL was originally on this list, but I've removed it because NULL isn't distributed by Valve. I suspect that embedding the textures into the map is causing issues with custom handling for AAATRIGGER and SKY, a theory that I'm testing with the change.<li>Compile documentation for all of the tool versions into a single location, probably as a series of links to each version's documentation initially. I'll probably write a comprehensive feature guide (command line features and custom entity extensions) eventually, but not for p13 because it's a big job and I don't want to delay the release. The next section of my website will be a "projects" section that will include a FAQ on ZHLT and the updated documentation, which I'll also distribute with the downloads (slated for p14+).</ul>I upgraded my development environment from Visual Studio.Net (7.0) to Visual Studio .Net 2003 (7.1) after I released p12, which means that the required DLLs for p13 are going to change (pain in the butt, I know, but I'll be releasing the next version bundled with the DLLs in place so people don't have to go hunting. The new DLLs will be MSVCP71.DLL and MSVCR71.DLL, which are the runtimes for .Net 2003 C and .Net 2003 C++ extensions like the C++ standard library.
I don't like committing to release dates because Real Life often intervenes, but I feel relatively safe saying that p13 will be out by the 10th.
Any idea when p13 will be out? You said hullus custom shadow code is going into that release am I right? Or was it only going to appear in the 'new' tools (when they come out).
Keep up the good work!
Reve<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
I'm adding Hullu's code to p13. I've already added and tested some bug fixes (EDIT: <i>bugs in MY code, not Hullu's!</i>), and my TO-DO list looks like this:
<ul><li>Add Hullu's new lighting code to RAD (possibly merging my fast math code with his build rather than moving his stuff into my build if that's easier)<li>Add support for overriding inclusion of common textures like AAATRIGGER, CLIP, HINT, SKIP, SKY, ORIGIN, etc. directly into maps. NULL was originally on this list, but I've removed it because NULL isn't distributed by Valve. I suspect that embedding the textures into the map is causing issues with custom handling for AAATRIGGER and SKY, a theory that I'm testing with the change.<li>Compile documentation for all of the tool versions into a single location, probably as a series of links to each version's documentation initially. I'll probably write a comprehensive feature guide (command line features and custom entity extensions) eventually, but not for p13 because it's a big job and I don't want to delay the release. The next section of my website will be a "projects" section that will include a FAQ on ZHLT and the updated documentation, which I'll also distribute with the downloads (slated for p14+).</ul>I upgraded my development environment from Visual Studio.Net (7.0) to Visual Studio .Net 2003 (7.1) after I released p12, which means that the required DLLs for p13 are going to change (pain in the butt, I know, but I'll be releasing the next version bundled with the DLLs in place so people don't have to go hunting. The new DLLs will be MSVCP71.DLL and MSVCR71.DLL, which are the runtimes for .Net 2003 C and .Net 2003 C++ extensions like the C++ standard library.
I don't like committing to release dates because Real Life often intervenes, but I feel relatively safe saying that p13 will be out by the 10th. <!--QuoteEnd--> </td></tr></table><span class='postcolor'> <!--QuoteEEnd-->
Will that require the .net framework Xp-Cagey?
No, just the two MS runtime DLLs I mentioned above.
I think a teaser list would probably just frustrate mappers <!--emo&:(--><img src='http://www.unknownworlds.com/forums/html/emoticons/sad.gif' border='0' style='vertical-align:middle' alt='sad.gif'><!--endemo-->.
I haven't talked much about the rewrite because I don't want a situation like the Nancy project where people are feeling jumpy about getting the project out the door. I'm less than halfway done with the actual coding of the tools, although I've got much more than that architected and ready for implementation. I'm currently working with the NS team on a few projects that are also taking some of my time. For now I can only say, "the tools will be out when they're done".
This isn't a list of features from an end-user standpoint, but here are the main reasons why I bothered rewriting the tools in the first place:<ul><li><i>major</i> speed improvements over ZHLT, even on a single CPU<li>internal process management system supports distributed computing with remote procedure calling<li>swappable component libraries for specialized code implementations (extended CPU instruction sets, 64 bit architectures)<li>well-defined object oriented framework for easier debugging and unit testing<li>plugin interface (which I'm using to implement the core functionality of the tools: the equivalent of CSG, BSP, VIS, and RAD)<li>reference counted map resources mean never having unused filler again (no more opt_plns)<li>not game specific (core is generic enough to compile for multiple engines; importer, exporter, and resource translation library interfaces make that practical)</ul>You'll like the tools when you can finally use them <!--emo&;)--><img src='http://www.unknownworlds.com/forums/html/emoticons/wink.gif' border='0' style='vertical-align:middle' alt='wink.gif'><!--endemo-->.
<ul><li>not game specific (core is generic enough to compile for multiple engines; importer, exporter, and resource translation library interfaces make that practical)</ul>You'll like the tools when you can finally use them <!--emo&;)--><img src='http://www.unknownworlds.com/forums/html/emoticons/wink.gif' border='0' style='vertical-align:middle' alt='wink.gif'><!--endemo-->.
<!--QuoteEnd--> </td></tr></table><span class='postcolor'> <!--QuoteEEnd-->
So are you saying this could potentially be hl2 compile tools as well? (also q3, and basically any other bsp based engine, but most people will want to know about hl2) If so then I think that's awesome. Lots of good work in there.......... Now if only it could make me a better mapper <!--emo&;)--><img src='http://www.unknownworlds.com/forums/html/emoticons/wink.gif' border='0' style='vertical-align:middle' alt='wink.gif'><!--endemo-->
<ul><li>not game specific (core is generic enough to compile for multiple engines; importer, exporter, and resource translation library interfaces make that practical)</ul>You'll like the tools when you can finally use them <!--emo&;)--><img src='http://www.unknownworlds.com/forums/html/emoticons/wink.gif' border='0' style='vertical-align:middle' alt='wink.gif'><!--endemo-->.
<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
So are you saying this could potentially be hl2 compile tools as well? (also q3, and basically any other bsp based engine, but most people will want to know about hl2) If so then I think that's awesome. Lots of good work in there.......... Now if only it could make me a better mapper <!--emo&;)--><img src='http://www.unknownworlds.com/forums/html/emoticons/wink.gif' border='0' style='vertical-align:middle' alt='wink.gif'><!--endemo--><!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
Yeah -- I want to target a superset of multiple engines' features and then let exporters handle engine specific conversions (like attempts to put a Q3 style patch in a Half-Life map). Since data storage requirements differ between engines (especially when defining clip information or visual bells and whistles like patches or detail brushes), the internal format probably won't match any specific game's requirements. It will be up to the exporters to fill any gaps between what's presented by the compiler and what the file format expects.
One early example of this problem is the generation of Half-Life's three clip hulls. Many modern engines use a single hull and shift its planes at runtime to accomodate arbitrary player sizes. I'll probably have the compiler generate a single unshifted hull and make the HL exporter generate the three actual hulls using the unshifted input from the compiler as a reference... generating a properly beveled unshifted hull and converting the shifted planes back into a well-formed BSP tree without any spacial overlapping are computational geometry problems I'm still solving (looking for published solutions and attempting to solve them my own through case studies, which is what I ended up doing for the precise clip algorithm). I have some ideas, but nothing final--I know this problem has been solved before <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->.
I don't know how much time the HL(1) engine has left, but I really wouldn't want to invest hundreds of hours into a new compiler system that won't be used in a few years <!--emo&;)--><img src='http://www.unknownworlds.com/forums/html/emoticons/wink.gif' border='0' style='vertical-align:middle' alt='wink.gif'><!--endemo-->.
HL1 is almost too old to create new systems for if they can't be used with HL2.
I don't think you could get much info out of valve but you could try asking for some engine related questions so you could prepare the compilers for HL2. I do hope that valvle releases the new HL2 compilers as open source so you can take a look at them <!--emo&:D--><img src='http://www.unknownworlds.com/forums/html/emoticons/biggrin.gif' border='0' style='vertical-align:middle' alt='biggrin.gif'><!--endemo-->
(On a side note: I just wrote a 9 pages long description of the Half-Life 1 model format... don't want to know what the new engine brings <!--emo&:(--><img src='http://www.unknownworlds.com/forums/html/emoticons/sad.gif' border='0' style='vertical-align:middle' alt='sad.gif'><!--endemo--> - if anyone has a question about Half-Life models feel free to PM me)
Er...Cagey...while you are at it - would it be possible to create a short version of this hull creator just to convert ns-maps with wrong hulls to the 2.0 format? At least the code base will exist in the final tools, so that would be quite useful for all the stupid clans that convert CS maps to NS, too <!--emo&;)--><img src='http://www.unknownworlds.com/forums/html/emoticons/wink.gif' border='0' style='vertical-align:middle' alt='wink.gif'><!--endemo-->
But yeah, all we need is a BSP importer - that XP-Cagey might already include with the first or second release, a newly coded 'filter' to rearrange the hulls (or delete the old ones and let the tools recreate them) and use the bsp exporter that is included. Simply amazing XP-Cagey! But that is another story. If someone REALLY have a well thought feature request then it should be posted somewhere, but the new tool set is still far away. Only coders already have to be very excited about it <!--emo&;)--><img src='http://www.unknownworlds.com/forums/html/emoticons/wink.gif' border='0' style='vertical-align:middle' alt='wink.gif'><!--endemo-->
Btw Cagey I love the work you did with the tools. Keep up the good work <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->
I am keeping part of the DoD community up to par with your new stuff also.
Oh, Cagey, how about you just include the docs from ZLHT 2.5.3 and MHLT 1.7 in two zips in the main zip for now?
Reve
merls are in difrent versions, though spirit has an extinsive documentation
amckern
Reve
<!--QuoteBegin--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> </td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->It can't handle Blue Shift maps. From my questionable memory, I seem to recall someone posting a few times that he discovered how to edit Blue Shift bsps to make them viewable/decompilable/editable. I think he said that the first two sets of 8 byte chunks in the bsp file were switched specifically to prevent decompilation. I tried switching them back (without really knowing what I was doing) and could not get winbspc to work on it.<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
The guy who wrote the decompiler has enabled it to now decompile Blue Shift maps. I was thinking, if the current compile tools don't support creating maps in that format, could it be added, perhaps by adding an argument -blueshift which would just swap round the stuff in the final map as required.
Also, has anyone tried using opt_plns on blue shift maps (yes I know you can't play an opt_plns map with a someone with the non optimised map version) but out of interest, does it work? If not, perhaps opt_plns could be updated? I think it seems pretty easy from what has been said in the decompilation thread.
I guess if no-one has tried doing any of this, it's because no-one really plays Blue Shift, but having it in the compile tools would have a nice 'kitchen sink' feeling about it <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->
Reve
Ryan Gregg (Nemesis) most famous for his batch compiler has made a program called BSP View. I'm assuming this works by opening up the BSP and creating a temporary .map of the level to be in the view with the BSP. I figured this out as it allows you to view all the basic areas of the map such as the 'AAATrigger' setting on a CS Bomb area, although it does not create any lighting. I am not so sure if a .map could be saved from it that it would be so stable, although everything from the original map would be correct.
Reve