When you release p14, why not announce it on the VERC forums like Merl did. Might end up becoming the official version of the compile tools (as it rightly should).
<!--QuoteBegin-amckern+Mar 20 2004, 12:53 AM--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (amckern @ Mar 20 2004, 12:53 AM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> Just a progress q cagey
how is the leek problem going that i brought up a few pages ago
i cant get any more of the sc_avp mission set done, untill i done map 10, and thats where i need p14
thanks
amckern <!--QuoteEnd--> </td></tr></table><div class='postcolor'> <!--QuoteEEnd--> Zazi volunteered to look at that problem for me; I need to check in and see where he's at with it.
<!--QuoteBegin-Reve+--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (Reve)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> When you release p14, why not announce it on the VERC forums like Merl did. Might end up becoming the official version of the compile tools (as it rightly should).<!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
I hadn't done that in the past because I've been waiting for Merl to make another release. As that seems increasingly unlikely, I'll probably go ahead and begin self-promoting in earnest with the next few releases. The fix to the file handler in particular is something that'll be very important once Valve drops WON support and more mappers are using Steam for editing.
Hi this is my first post on this forum <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html//emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif' /><!--endemo--> and my english is not very good.
I've just found these new zhlt tools and tried to read most of the replies on this thread but there is simply too much information on 25 pages for me to read in one shot <!--emo&:(--><img src='http://www.unknownworlds.com/forums/html//emoticons/sad.gif' border='0' style='vertical-align:middle' alt='sad.gif' /><!--endemo-->. Anyway I'm pretty sure that I'm going to use this tools to compile my maps.
But before doing so, I would like to ask these two questions <!--emo&;)--><img src='http://www.unknownworlds.com/forums/html//emoticons/wink.gif' border='0' style='vertical-align:middle' alt='wink.gif' /><!--endemo-->:
(1.) I've noticed somewhere in the thread that XP-Cagey is working on some totaly new version of this tools which are rewritten from scratch, am I right (if I am, when this tools will be released and what will be the difference)?
(2.) This second question might be off topic, it is concerning HLRAD. I was thinking that it possible to enhance map visual detail by using models from MDL files instead of brush models. For engine it less time-consuming to render epolys than wpolys and models can be very detailed and even contain animations. It can also reduce plane count. I used combination of custom model inserted using monster_furniture in conjunction with box brush textured by CLIP texture to create "blocking model object". It works, but there are two problems:
1. model based entities use vertex lightning so they don't have lightmaps. This can be bypassed by decent lightning. Anyvay this is just a minor visual problem.
2. such entity does not cast shadows on the BSP world. This is an quite big visual bug.
So I'm asking if it is possible to alter HLRAD so these models will cast shadows onto the bsp world?
Models casting shadows is quite a bit of extra work, because before calculating the shadows from the polygons the shape of a model has to be determined. In Half-Life there are already quite a few values modifying position, animation state and sub-models. For the next year at least it is better to simply create a brush in the desired shape. Maybe then someone codes a plug-in for ... well whatever.
<!--QuoteBegin-etko+Mar 23 2004, 07:01 PM--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (etko @ Mar 23 2004, 07:01 PM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> Hi this is my first post on this forum <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html//emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif' /><!--endemo--> and my english is not very good.
I've just found these new zhlt tools and tried to read most of the replies on this thread but there is simply too much information on 25 pages for me to read in one shot <!--emo&:(--><img src='http://www.unknownworlds.com/forums/html//emoticons/sad.gif' border='0' style='vertical-align:middle' alt='sad.gif' /><!--endemo-->. Anyway I'm pretty sure that I'm going to use this tools to compile my maps.
But before doing so, I would like to ask these two questions:
(1.) I've noticed somewhere in the thread that XP-Cagey is working on some totaly new version of this tools which are rewritten from scratch, am I right (if I am, when this tools will be released and what will be the difference)?
(2.) This second question might be off topic, it is concerning HLRAD. I was thinking that it possible to enhance map visual detail by using models from MDL files instead of brush models. For engine it less time-consuming to render epolys than wpolys and models can be very detailed and even contain animations. It can also reduce plane count. I used combination of custom model inserted using monster_furniture in conjunction with box brush textured by CLIP texture to create "blocking model object". It works, but there are two problems:
1. model based entities use vertex lightning so they don't have lightmaps. This can be bypassed by decent lightning. Anyvay this is just a minor visual problem.
2. such entity does not cast shadows on the BSP world. This is an quite big visual bug.
So I'm asking if it is possible to alter HLRAD so these models will cast shadows onto the bsp world? <!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd--> (1) It will still be a long time before the new tools are ready for a public release. I may release an alpha version of just the BSP building segments (equivalent to HLCSG and HLBSP) to help the debugging procress, but even that's not likely to appear soon.
I listed my reasons for doing the rewrite in <a href='http://www.unknownworlds.com/forums/index.php?showtopic=21248&st=282' target='_blank'>this post</a> up on page 19; I'm probably not going to add anything before the new tools are ready for a test release--I hate vaporware, and don't want to hype something that may not be released for another 12 months.
(2) HLRAD can be modified to make models cast shadows, but it would require a lot of work--the tools don't currently know how to read model information, and the SDK model viewer code doesn't have shadow projection, so those routines would need to be written from scratch. It's possible, but not on my ZHLT to-do list at the moment.
You can get simple shadows by using a simple NULL-textured wpoly entity in a shape similar to the model, and then removing the func_wall with Ripents (legitimate uses of Ripents like this shadow trick are the reason why I still support it, btw). It's more work and adds nodes to the final map, but at the moment it's the best solution.
EDIT: doH! beaten to it <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html//emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif' /><!--endemo-->
<!--QuoteBegin-Reve+Apr 8 2004, 09:52 AM--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (Reve @ Apr 8 2004, 09:52 AM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> Any news on p14? Are you having problems other than that '.' character bug?
Reve <!--QuoteEnd--> </td></tr></table><div class='postcolor'> <!--QuoteEEnd--> I've been in a holding pattern with ZHLT over the last few weeks--as the natural-selection.org news page mentions, I'm working NS itself at the moment. I really need to make a push to get the latest build of ZHLT finished.
<span style='color:white'>What's planned</span>
Changing over the docs to the excellent version you've compiled -- thanks for that <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html//emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif' /><!--endemo-->
I'm going to be releasing HLCSG and HLBSP with double precision internal math from now on to help combat floating point error. This should theoretically help with the remaining clip problems and "Leaf portal saw into leaf" errors. For memory requirement reasons, HLVIS and HLRAD will continue using single floats.
I need to finish debugging it, but the replacement file handler to fix the '.' bug is written.
Zazi believes he's found and fixed amckern's bug described above; I need to grab the changes from him and test them.
Scan entity strings and throw a new warning if an illegal character is detected -- HL crashes on map start if strings contain characters other than a narrow subset I'm trying to find an exact definition for.
Add command line switch to turn off light bounce for all dynamic lights at global level; prevents lightdata bloat and helps combat "Too many lightstyles" error
Add new field to lights that allows mapper to selectively turn off bounce for individual lights
Investigate and fix crash reported when using HLVIS's -maxdistance switch (may be due to same issue that's causing amkern's bug)
I've been asked to add the ability to light items as if the brush model was rotated to a different position; I'm currently thinking over exactly how I'd want to do this.
Yeah sorry I read the news on the NS front page after posting <!--emo&:D--><img src='http://www.unknownworlds.com/forums/html//emoticons/biggrin.gif' border='0' style='vertical-align:middle' alt='biggrin.gif' /><!--endemo-->
<a href='http://www.xp-cagey.com/?article=1000' target='_blank'>http://www.xp-cagey.com/?article=1000</a> < is this referning to opt_plnz.exe or a flag in the tools? i am geting the sticky edges, and trying to work out what i can do to fix them - if its a tools flag, please tell me what one
<!--QuoteBegin-amckern+Apr 23 2004, 05:38 AM--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (amckern @ Apr 23 2004, 05:38 AM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->if its a tools flag, please tell me what one<!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd--> -cliptype in CSG
Check out <a href='http://www.unknownworlds.com/forums/index.php?showtopic=24137&st=0&#entry291111' target='_blank'>this post</a> for more information on the options.
In testing, it turns out that smallest doesn't necessarily produce the smallest clip hull on every map -- precise and simple can often use fewer nodes.
I just used the p13 build of zhlt, and I seem to get a brush outside world error when I compile. This error doesn't show up when I use merl's zhlt <!--emo&???--><img src='http://www.unknownworlds.com/forums/html//emoticons/confused.gif' border='0' style='vertical-align:middle' alt='confused.gif' /><!--endemo--> Is it supposed to be like this or is this an error I seem to be getting? I am sorry if this has been brought up in the thread before but I checked the first 3 pages and the last 2 and there was nothing on it and I don't feel like reading all 25 pages <!--emo&;)--><img src='http://www.unknownworlds.com/forums/html//emoticons/wink.gif' border='0' style='vertical-align:middle' alt='wink.gif' /><!--endemo--> .
I just used the p13 build of zhlt, and I seem to get a brush outside world error when I compile. This error doesn't show up when I use merl's zhlt <!--emo&???--><img src='http://www.unknownworlds.com/forums/html//emoticons/confused.gif' border='0' style='vertical-align:middle' alt='confused.gif' /><!--endemo--> Is it supposed to be like this or is this an error I seem to be getting? I am sorry if this has been brought up in the thread before but I checked the first 3 pages and the last 2 and there was nothing on it and I don't feel like reading all 25 pages <!--emo&;)--><img src='http://www.unknownworlds.com/forums/html//emoticons/wink.gif' border='0' style='vertical-align:middle' alt='wink.gif' /><!--endemo--> .
-Corn <!--QuoteEnd--> </td></tr></table><div class='postcolor'> <!--QuoteEEnd--> PM me the full build log and I'll try to figure out what's going on.
I don't know if this has been mentioned before, and if so, I'm sorry I'm telling/asking you this right now.
BUT: is it possible to let the compiler check for correct paths? I mean, if you CHOOSE a model, instead of typing in models/xxx.mdl, you'll get an error after the compile when running the game (the mod badsum error or something), that's because if you choose it it'll say c:/HL/NS/models/xxx.mdl (example). If you can check it, could it also be possible the compiler will automatically rename the paths? Let's say in this situation the compiler sees this: c:/HL/NS/models/xxx.mdl and automatically turns it into this: models/xxx.mdl
Why? Because it's rather a pain in the arse if you compile a long time and that error shows up in the game and thus can't test your map.
-EDIT-
With this I also mean for sounds, sprites, anything else...
It is probably possible and relativly easy to add this feature to the compile tools. Even better you can wait for a few hours and see if i add it to a certain perl script im maintaining. As it happens im doing a release soon, hopefully tonight (tonight in australia <!--emo&:p--><img src='http://www.unknownworlds.com/forums/html//emoticons/tounge.gif' border='0' style='vertical-align:middle' alt='tounge.gif' /><!--endemo-->). Linkage: <a href='http://www.chatbear.com/board.plm?a=viewthread&t=52,1080647136,18491&b=590&id=644889&v=flatold&s=0' target='_blank'>http://www.chatbear.com/board.plm?a=viewth...9&v=flatold&s=0</a>
Probably i won't be checking the file exists but simply replacing something like c:/HL/NS/models/xxx.mdl with models/xxx.mdl
EDIT: I have posted the new version of the perl script, which does fix up those paths. Dosent check the files exist so be sure you get that right <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html//emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif' /><!--endemo-->
I think that an external tool like this perl script is a better solution to property validation than embedding entity specific information into ZHLT for two reasons:
First, entity requirements vary by mod, and while I don't think there is a lot of variance in where model information would be stored, I don't want any mod-specific or entity-specific code anywhere in the tools, which should be able to build a map while knowing as little as possible about specific entities.
The compiler-specific fields are meant to be generic for any brush-based entity so that I don't have special cases, and lights (unfortunately) must be understood by HLRAD, but it's a bad practice to make decisions based on hardcoded entity information--the clip economy code is an example of code that attempts to second-guess mod definitions of entity classnames and flags, and I doubt it's accurate for anything other than vanilla Half-Life.
Second, I don't want to have to build a new release each time a mod update changes the potential rules I need to check against. I'm sure most users don't want to download updates just for entity ruleset changes, either.
It's possible to circumvent both problems by making any property value checker generic enough to handle a wide variety of cases--the <a href='http://www.unknownworlds.com/forums/index.php?showtopic=21248&st=278' target='_blank'>new tools</a> embed a regular expression engine and manipulate entities and textures according to definition files using regex and range matching of entity and texture properties; that sort of generic solution has much more appeal than anything hardcoded because I can pass the responsibility for maintenance and accuracy to mod authors instead of taking it on myself. That same flexibility will allow individual mappers to write their own compiler enhanced versions of entities to perform tricks like casting shadows without being in the final BSP--it's a very powerful solution.
I won't be implementing a generic scripting language like that for ZHLT -- in spite of my continuing bugfix and minor enhancement work on ZHLT, I still look forward to the day when I never have to work with it again. Putting a layer like what I described above over ZHLT would be an exercise in frustration, and I'm going to avoid the headaches it would cause.
<!--QuoteBegin-Reese+May 3 2004, 12:44 AM--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (Reese @ May 3 2004, 12:44 AM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> I love how every time cagey starts talking about his new tools my level of excitement ends up just as high as my level of confusion. <!--QuoteEnd--> </td></tr></table><div class='postcolor'> <!--QuoteEEnd--> Quite sadly, the same happens to me. But I did understand he would NOT implent it <!--emo&:p--><img src='http://www.unknownworlds.com/forums/html//emoticons/tounge.gif' border='0' style='vertical-align:middle' alt='tounge.gif' /><!--endemo--> .
It was just a thought <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html//emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif' /><!--endemo--> !
Just wanted to tell you how much faster compiling is with these tools compared to original zoner's. My compile times have been reduced atleast 75%. Too bad I didn't update earlier :/
Yeah gotta agree with all of that guys. The improvment in speeds of CSG and RAD in particular are quite sweet. Without mentioning what kinda sparked this: the CSG sticky corners fixes <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html//emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif' /><!--endemo-->
Just in case anyone really cares that tool is actually totally *not* mod specific in any way. Its all done with regular expressions and the like. Sweet. Im getting 42% reduction on a SoHL DM and my planes (thnx XP-Cagey!) are normally VERY close on 2/3. Overall these leave my maps about 100k smaller and thats only good.
From one map: Planes in map: 13680 Planes actually used: 3759
XP-Cagey: Any point making opt_plns show a *percentage* AFTER its optimised?... the info at the top seems to be before optimisation..
<!--QuoteBegin-FragBait0+May 4 2004, 05:34 AM--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (FragBait0 @ May 4 2004, 05:34 AM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> Any point making opt_plns show a *percentage* AFTER its optimised?... the info at the top seems to be before optimisation.. <!--QuoteEnd--> </td></tr></table><div class='postcolor'> <!--QuoteEEnd--> I'll get this in for p15.
<!--QuoteBegin--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> </td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->Will the written-from-scratch tools have all the functionality and improvements of zhlt-based tools (in whatever form they are at that point)?<!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
I plan to include the full feature set of whatever iteration of ZHLT I'm on at the point of release (p15)? into the first non-testing release, at which time I'm going to completely stop working on ZHLT. Initial testing releases probably will be missing features while I make sure the basic functionality is solid.
Many of the improvements on the zhlt-based tools aren't going to apply any more--the end BSP will be similar (though probably smaller since it won't have any unused data entries), but the method to get there is going to be very different.
Speed improvements in particular won't apply anymore. Changing from brute force (ZHLT) to optimized algorithms has already made the new tools much faster across the board.
The short version: Did you increase max vertices to above what the HL engine can handle when you load up the map for some reason?
<span style='font-size:2pt;line-height:100%'>*sigh, I'm a bit annoyed right now so I'm going to add a bunch of parenthesis's and not close them and see if that helps any... ((((((((((((((((</span>
edit: no this does not appear to be it, however I did notice something interesting, func_illusionary's eat leaves like no tomorrow... Why is that? Could this problem be optimized away in the compile tools?
Can a map be too complex to run(alloc:block full) but compile perfectly fine and be under all limits? I'm close but not over several limits, mostly clip nodes and leaves(!, thank you func_illusionary's).
<!--QuoteBegin-Soylent green+May 10 2004, 11:45 AM--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (Soylent green @ May 10 2004, 11:45 AM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> Can a map be too complex to run(alloc:block full) but compile perfectly fine and be under all limits? <!--QuoteEnd--> </td></tr></table><div class='postcolor'> <!--QuoteEEnd--> Yeah, unfortunately -- the error you're seeing is a complaint that Half-Life is out of memory, which isn't possible to predict from the tools because of all of the items (model information in particular) that Half-Life stores in addition to map information.
I can't give any advice except to begin finding ways to use less memory--if you're using map models, remove some of them. If not, try using fewer textures. If that's not possible, you'll have to begin making your map simpler--hate to say that, but adjusting the memory settings of your copy of Half-Life won't help other people play it, and in my opinion it's better to adapt the map than force command-line arguements to keep HL from crashing.
Thanks Cagey. (no custom models to strip unfortunetly, striping ALL func_walls and func_illusionary is not enough either. I'm using only half the allowed texture memory and even if I don't run RAD I get alloc:block full)
I sure am glad that the map has a modular design and it should be a bang up job to strip unnecessarilly complex stuff and I haven't sunk soo much time into the map either.
<!--QuoteBegin-amckern+May 20 2004, 04:11 PM--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (amckern @ May 20 2004, 04:11 PM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> Cagey, can you please help me out
Its at countermap, but looks like people dont use XHLTP13 In CS Yet
amckern <!--QuoteEnd--> </td></tr></table><div class='postcolor'> <!--QuoteEEnd--> Use "-cliptype precise" -- there shouldn't be a space between "-" and "cliptype".
<!--QuoteBegin-Mendasp+May 21 2004, 11:45 PM--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (Mendasp @ May 21 2004, 11:45 PM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> Since noone seemed to notice... opt_plns still reports the "old" 4 mbs default limit on lightdata, when HLRAD has 6 mbs.
opt_plns still works as intended anyways... it's minor, heh. <!--QuoteEnd--> </td></tr></table><div class='postcolor'> <!--QuoteEEnd--> D'oh! <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html//emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif' /><!--endemo-->
It'll only affect the display, because opt_plns actually dynamically loads the correct amount of lightdata when it reads in the map -- it'll allow more than 4MB without a problem.
I'm really close to releasing p14, and I built the opt_plns routines directly into HLBSP yesterday, so from p14 onward the optimization will happen without the need to have the extra program floating around <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html//emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif' /><!--endemo-->.
Comments
Reve
how is the leek problem going that i brought up a few pages ago
i cant get any more of the sc_avp mission set done, untill i done map 10, and thats where i need p14
thanks
amckern
how is the leek problem going that i brought up a few pages ago
i cant get any more of the sc_avp mission set done, untill i done map 10, and thats where i need p14
thanks
amckern <!--QuoteEnd--> </td></tr></table><div class='postcolor'> <!--QuoteEEnd-->
Zazi volunteered to look at that problem for me; I need to check in and see where he's at with it.
<!--QuoteBegin-Reve+--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (Reve)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> When you release p14, why not announce it on the VERC forums like Merl did. Might end up becoming the official version of the compile tools (as it rightly should).<!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
I hadn't done that in the past because I've been waiting for Merl to make another release. As that seems increasingly unlikely, I'll probably go ahead and begin self-promoting in earnest with the next few releases. The fix to the file handler in particular is something that'll be very important once Valve drops WON support and more mappers are using Steam for editing.
I've just found these new zhlt tools and tried to read most of the replies on this thread but there is simply too much information on 25 pages for me to read in one shot <!--emo&:(--><img src='http://www.unknownworlds.com/forums/html//emoticons/sad.gif' border='0' style='vertical-align:middle' alt='sad.gif' /><!--endemo-->. Anyway I'm pretty sure that I'm going to use this tools to compile my maps.
But before doing so, I would like to ask these two questions <!--emo&;)--><img src='http://www.unknownworlds.com/forums/html//emoticons/wink.gif' border='0' style='vertical-align:middle' alt='wink.gif' /><!--endemo-->:
(1.) I've noticed somewhere in the thread that XP-Cagey is working on some totaly new version of this tools which are rewritten from scratch, am I right (if I am, when this tools will be released and what will be the difference)?
(2.) This second question might be off topic, it is concerning HLRAD. I was thinking
that it possible to enhance map visual detail by using models from MDL files instead of brush models. For engine it less time-consuming to render epolys than wpolys and models can be very detailed and even contain animations. It can also reduce plane count. I used combination of custom model inserted using monster_furniture in conjunction with box brush textured by CLIP texture to create "blocking model object". It works, but there are two problems:
1. model based entities use vertex lightning so they don't have lightmaps. This can be bypassed by decent lightning. Anyvay this is just a minor visual problem.
2. such entity does not cast shadows on the BSP world. This is an quite big visual bug.
So I'm asking if it is possible to alter HLRAD so these models will cast shadows onto the bsp world?
I've just found these new zhlt tools and tried to read most of the replies on this thread but there is simply too much information on 25 pages for me to read in one shot <!--emo&:(--><img src='http://www.unknownworlds.com/forums/html//emoticons/sad.gif' border='0' style='vertical-align:middle' alt='sad.gif' /><!--endemo-->. Anyway I'm pretty sure that I'm going to use this tools to compile my maps.
But before doing so, I would like to ask these two questions:
(1.) I've noticed somewhere in the thread that XP-Cagey is working on some totaly new version of this tools which are rewritten from scratch, am I right (if I am, when this tools will be released and what will be the difference)?
(2.) This second question might be off topic, it is concerning HLRAD. I was thinking
that it possible to enhance map visual detail by using models from MDL files instead of brush models. For engine it less time-consuming to render epolys than wpolys and models can be very detailed and even contain animations. It can also reduce plane count. I used combination of custom model inserted using monster_furniture in conjunction with box brush textured by CLIP texture to create "blocking model object". It works, but there are two problems:
1. model based entities use vertex lightning so they don't have lightmaps. This can be bypassed by decent lightning. Anyvay this is just a minor visual problem.
2. such entity does not cast shadows on the BSP world. This is an quite big visual bug.
So I'm asking if it is possible to alter HLRAD so these models will cast shadows onto the bsp world? <!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
(1) It will still be a long time before the new tools are ready for a public release. I may release an alpha version of just the BSP building segments (equivalent to HLCSG and HLBSP) to help the debugging procress, but even that's not likely to appear soon.
I listed my reasons for doing the rewrite in <a href='http://www.unknownworlds.com/forums/index.php?showtopic=21248&st=282' target='_blank'>this post</a> up on page 19; I'm probably not going to add anything before the new tools are ready for a test release--I hate vaporware, and don't want to hype something that may not be released for another 12 months.
(2) HLRAD can be modified to make models cast shadows, but it would require a lot of work--the tools don't currently know how to read model information, and the SDK model viewer code doesn't have shadow projection, so those routines would need to be written from scratch. It's possible, but not on my ZHLT to-do list at the moment.
You can get simple shadows by using a simple NULL-textured wpoly entity in a shape similar to the model, and then removing the func_wall with Ripents (legitimate uses of Ripents like this shadow trick are the reason why I still support it, btw). It's more work and adds nodes to the final map, but at the moment it's the best solution.
EDIT: doH! beaten to it <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html//emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif' /><!--endemo-->
Reve
Reve <!--QuoteEnd--> </td></tr></table><div class='postcolor'> <!--QuoteEEnd-->
I've been in a holding pattern with ZHLT over the last few weeks--as the natural-selection.org news page mentions, I'm working NS itself at the moment. I really need to make a push to get the latest build of ZHLT finished.
<span style='color:white'>What's planned</span>
Changing over the docs to the excellent version you've compiled -- thanks for that <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html//emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif' /><!--endemo-->
I'm going to be releasing HLCSG and HLBSP with double precision internal math from now on to help combat floating point error. This should theoretically help with the remaining clip problems and "Leaf portal saw into leaf" errors. For memory requirement reasons, HLVIS and HLRAD will continue using single floats.
I need to finish debugging it, but the replacement file handler to fix the '.' bug is written.
Zazi believes he's found and fixed amckern's bug described above; I need to grab the changes from him and test them.
<span style='color:white'>Tenative</span> (possibly p14, maybe p15):
Scan entity strings and throw a new warning if an illegal character is detected -- HL crashes on map start if strings contain characters other than a narrow subset I'm trying to find an exact definition for.
Add command line switch to turn off light bounce for all dynamic lights at global level; prevents lightdata bloat and helps combat "Too many lightstyles" error
Add new field to lights that allows mapper to selectively turn off bounce for individual lights
Investigate and fix crash reported when using HLVIS's -maxdistance switch (may be due to same issue that's causing amkern's bug)
<span style='color:white'>The misty future</span> (p15+):
I've been asked to add the ability to light items as if the brush model was rotated to a different position; I'm currently thinking over exactly how I'd want to do this.
Reve
amckern
-cliptype in CSG
Check out <a href='http://www.unknownworlds.com/forums/index.php?showtopic=24137&st=0&#entry291111' target='_blank'>this post</a> for more information on the options.
In testing, it turns out that smallest doesn't necessarily produce the smallest clip hull on every map -- precise and simple can often use fewer nodes.
I just used the p13 build of zhlt, and I seem to get a brush outside world error when I compile. This error doesn't show up when I use merl's zhlt <!--emo&???--><img src='http://www.unknownworlds.com/forums/html//emoticons/confused.gif' border='0' style='vertical-align:middle' alt='confused.gif' /><!--endemo--> Is it supposed to be like this or is this an error I seem to be getting? I am sorry if this has been brought up in the thread before but I checked the first 3 pages and the last 2 and there was nothing on it and I don't feel like reading all 25 pages <!--emo&;)--><img src='http://www.unknownworlds.com/forums/html//emoticons/wink.gif' border='0' style='vertical-align:middle' alt='wink.gif' /><!--endemo--> .
-Corn
I just used the p13 build of zhlt, and I seem to get a brush outside world error when I compile. This error doesn't show up when I use merl's zhlt <!--emo&???--><img src='http://www.unknownworlds.com/forums/html//emoticons/confused.gif' border='0' style='vertical-align:middle' alt='confused.gif' /><!--endemo--> Is it supposed to be like this or is this an error I seem to be getting? I am sorry if this has been brought up in the thread before but I checked the first 3 pages and the last 2 and there was nothing on it and I don't feel like reading all 25 pages <!--emo&;)--><img src='http://www.unknownworlds.com/forums/html//emoticons/wink.gif' border='0' style='vertical-align:middle' alt='wink.gif' /><!--endemo--> .
-Corn <!--QuoteEnd--> </td></tr></table><div class='postcolor'> <!--QuoteEEnd-->
PM me the full build log and I'll try to figure out what's going on.
BUT: is it possible to let the compiler check for correct paths?
I mean, if you CHOOSE a model, instead of typing in models/xxx.mdl, you'll get an error after the compile when running the game (the mod badsum error or something), that's because if you choose it it'll say c:/HL/NS/models/xxx.mdl (example).
If you can check it, could it also be possible the compiler will automatically rename the paths? Let's say in this situation the compiler sees this: c:/HL/NS/models/xxx.mdl and automatically turns it into this: models/xxx.mdl
Why? Because it's rather a pain in the arse if you compile a long time and that error shows up in the game and thus can't test your map.
-EDIT-
With this I also mean for sounds, sprites, anything else...
Even better you can wait for a few hours and see if i add it to a certain perl script im maintaining. As it happens im doing a release soon, hopefully tonight (tonight in australia <!--emo&:p--><img src='http://www.unknownworlds.com/forums/html//emoticons/tounge.gif' border='0' style='vertical-align:middle' alt='tounge.gif' /><!--endemo-->).
Linkage: <a href='http://www.chatbear.com/board.plm?a=viewthread&t=52,1080647136,18491&b=590&id=644889&v=flatold&s=0' target='_blank'>http://www.chatbear.com/board.plm?a=viewth...9&v=flatold&s=0</a>
Probably i won't be checking the file exists but simply replacing something like c:/HL/NS/models/xxx.mdl with models/xxx.mdl
EDIT: I have posted the new version of the perl script, which does fix up those paths. Dosent check the files exist so be sure you get that right <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html//emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif' /><!--endemo-->
First, entity requirements vary by mod, and while I don't think there is a lot of variance in where model information would be stored, I don't want any mod-specific or entity-specific code anywhere in the tools, which should be able to build a map while knowing as little as possible about specific entities.
The compiler-specific fields are meant to be generic for any brush-based entity so that I don't have special cases, and lights (unfortunately) must be understood by HLRAD, but it's a bad practice to make decisions based on hardcoded entity information--the clip economy code is an example of code that attempts to second-guess mod definitions of entity classnames and flags, and I doubt it's accurate for anything other than vanilla Half-Life.
Second, I don't want to have to build a new release each time a mod update changes the potential rules I need to check against. I'm sure most users don't want to download updates just for entity ruleset changes, either.
It's possible to circumvent both problems by making any property value checker generic enough to handle a wide variety of cases--the <a href='http://www.unknownworlds.com/forums/index.php?showtopic=21248&st=278' target='_blank'>new tools</a> embed a regular expression engine and manipulate entities and textures according to definition files using regex and range matching of entity and texture properties; that sort of generic solution has much more appeal than anything hardcoded because I can pass the responsibility for maintenance and accuracy to mod authors instead of taking it on myself. That same flexibility will allow individual mappers to write their own compiler enhanced versions of entities to perform tricks like casting shadows without being in the final BSP--it's a very powerful solution.
I won't be implementing a generic scripting language like that for ZHLT -- in spite of my continuing bugfix and minor enhancement work on ZHLT, I still look forward to the day when I never have to work with it again. Putting a layer like what I described above over ZHLT would be an exercise in frustration, and I'm going to avoid the headaches it would cause.
Quite sadly, the same happens to me. But I did understand he would NOT implent it <!--emo&:p--><img src='http://www.unknownworlds.com/forums/html//emoticons/tounge.gif' border='0' style='vertical-align:middle' alt='tounge.gif' /><!--endemo--> .
It was just a thought <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html//emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif' /><!--endemo--> !
Just in case anyone really cares that tool is actually totally *not* mod specific in any way. Its all done with regular expressions and the like. Sweet. Im getting 42% reduction on a SoHL DM and my planes (thnx XP-Cagey!) are normally VERY close on 2/3. Overall these leave my maps about 100k smaller and thats only good.
From one map:
Planes in map: 13680
Planes actually used: 3759
XP-Cagey: Any point making opt_plns show a *percentage* AFTER its optimised?... the info at the top seems to be before optimisation..
I'll get this in for p15.
<!--QuoteBegin--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> </td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->Will the written-from-scratch tools have all the functionality and improvements of zhlt-based tools (in whatever form they are at that point)?<!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
I plan to include the full feature set of whatever iteration of ZHLT I'm on at the point of release (p15)? into the first non-testing release, at which time I'm going to completely stop working on ZHLT. Initial testing releases probably will be missing features while I make sure the basic functionality is solid.
Many of the improvements on the zhlt-based tools aren't going to apply any more--the end BSP will be similar (though probably smaller since it won't have any unused data entries), but the method to get there is going to be very different.
Speed improvements in particular won't apply anymore. Changing from brute force (ZHLT) to optimized algorithms has already made the new tools much faster across the board.
<span style='font-size:2pt;line-height:100%'>*sigh, I'm a bit annoyed right now so I'm going to add a bunch of parenthesis's and not close them and see if that helps any... ((((((((((((((((</span>
edit: no this does not appear to be it, however I did notice something interesting, func_illusionary's eat leaves like no tomorrow... Why is that? Could this problem be optimized away in the compile tools?
Can a map be too complex to run(alloc:block full) but compile perfectly fine and be under all limits? I'm close but not over several limits, mostly clip nodes and leaves(!, thank you func_illusionary's).
Yeah, unfortunately -- the error you're seeing is a complaint that Half-Life is out of memory, which isn't possible to predict from the tools because of all of the items (model information in particular) that Half-Life stores in addition to map information.
I can't give any advice except to begin finding ways to use less memory--if you're using map models, remove some of them. If not, try using fewer textures. If that's not possible, you'll have to begin making your map simpler--hate to say that, but adjusting the memory settings of your copy of Half-Life won't help other people play it, and in my opinion it's better to adapt the map than force command-line arguements to keep HL from crashing.
I sure am glad that the map has a modular design and it should be a bang up job to strip unnecessarilly complex stuff and I haven't sunk soo much time into the map either.
<a href='http://countermap.counter-strike.net/ubb/Forum4/HTML/015233.html' target='_blank'>http://countermap.counter-strike.net/ubb/F...TML/015233.html</a>
Its at countermap, but looks like people dont use XHLTP13 In CS Yet
amckern
<a href='http://countermap.counter-strike.net/ubb/Forum4/HTML/015233.html' target='_blank'>http://countermap.counter-strike.net/ubb/F...TML/015233.html</a>
Its at countermap, but looks like people dont use XHLTP13 In CS Yet
amckern <!--QuoteEnd--> </td></tr></table><div class='postcolor'> <!--QuoteEEnd-->
Use "-cliptype precise" -- there shouldn't be a space between "-" and "cliptype".
opt_plns still works as intended anyways... it's minor, heh.
opt_plns still works as intended anyways... it's minor, heh. <!--QuoteEnd--> </td></tr></table><div class='postcolor'> <!--QuoteEEnd-->
D'oh! <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html//emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif' /><!--endemo-->
It'll only affect the display, because opt_plns actually dynamically loads the correct amount of lightdata when it reads in the map -- it'll allow more than 4MB without a problem.
I'm really close to releasing p14, and I built the opt_plns routines directly into HLBSP yesterday, so from p14 onward the optimization will happen without the need to have the extra program floating around <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html//emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif' /><!--endemo-->.
:0 :0 :0
p14, will pwn some what, lets hope you have some ther code in there as well :D
amckern