<!--QuoteBegin--XP-Cagey+Jan 3 2004, 02:50 PM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (XP-Cagey @ Jan 3 2004, 02:50 PM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> 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--> Real life intervened <!--emo&???--><img src='http://www.unknownworlds.com/forums/html/emoticons/confused.gif' border='0' style='vertical-align:middle' alt='confused.gif'><!--endemo-->
I'm going to get p13 tested and ready for public use by the night of the 12th.
lol, I get the feeling that the editing you did was "it will be out by tonight, no tomrrow, no tomorrow night..... ok, well, we'll say night of the 12th"
i was trying to combat max patches, with out having to fall back on the less powerful sparse, as funk_seethrough gets rendered darker then on normal extra
so realy i have 1 bug - all p12 tools used funk_seethrough opaqce (typo) flag active
funk_seethrough gets rendered darker with sparse, over normal extra
I've been too lazy to search up, check out, and complain loudly... but now that you mention it, amckern, I have a problem that sounds like what you're describing:
When I set some brush entities as opaque, they end up looking extremely dark (the lightmap is essentially black.) This must be a bug in the ZHLT p-series...
So this is me asking what is up with that and complaining loudly... <!--emo&:p--><img src='http://www.unknownworlds.com/forums/html/emoticons/tounge.gif' border='0' style='vertical-align:middle' alt='tounge.gif'><!--endemo-->
<!--QuoteBegin--amckern+Jan 11 2004, 02:55 AM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (amckern @ Jan 11 2004, 02:55 AM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->lightdata - what is this flag used to combat?<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd--> From the readme file:
Feature Addition (RAD): added -lightdata <#> switch to allow user to set custom lightdata maximum value. Works like the -texdata switch. Default maximum light data amount bumped to 8MB.<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
p12 bumped the default lightdata max back to 6MB.
<!--QuoteBegin--Erias+Jan 11 2004, 03:14 AM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (Erias @ Jan 11 2004, 03:14 AM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->When I set some brush entities as opaque, they end up looking extremely dark (the lightmap is essentially black.) This must be a bug in the ZHLT p-series...<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
Does the same object light properly using Merl's 1.7 download? Can't think of any changes I've made since the original HLRAD speedups that might affect this, and I know those are now functioning identically to the original code (I reverted the second batch of HLRAD changes from p11 to p12).
If 1.7 does light it properly, I'll see what I can do for p14.
From the 2.5.3 docs (Yes, I found them--there was a french lycos site that hadn't updated its downloads section in years <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->. All of the docs will be bundled with p13.)
<!--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-->zhlt_lightflags Set optional lightflags. Can be applied to any brush based entity.
0 is default 1 is 'EmbeddedFix' 2 is the Opaque flag(blocks light) 3 is Opaque+EmbeddedFix 4 is 'ConcaveFix' (must be used with opaque, this setting is useless by itself) 6 is Opaque+ConcaveFix
For opaque brushes, it will be frequently necessary to place point lights inside the brush so that faces obscured by the brushes are properly lit (for example the trim adjacent to a func_door). Setting the opaque bit is useful for most func_walls, some func_illusionary's, the occasional func_door, and possibly others for some effect.
The 'EmbeddedFix' is for telling hlrad to not used the complex light bleed fix on the entity, as sometimes when creating a brush entity that sticks through a wall, it will be lit incorrectly from the other side of the wall due to the bleed correction.
The 'ConcaveFix' is needed for curved func_walls, notably arch shapes. When they are set to opaque, the inner curve (the concave porition) will frequently have black fringes at the joins where brushes touch up. Setting the ConcaveFix flag fixes the black seams in these cases, but then the entity cannot have the EmbeddedFix set.<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
Try setting the lightflags to 6 instead of 2 and see if that helps light your entity properly.
I don't think the flag will fix it, this wierdness has been happening with quite a few perfectly ordinary brush entities... and I didn't notice this problem at all back when I was using Merl's ZHLT...
I'll look into it. Maybe it's something on my end.
Oh yeah, XP-Cagey, I was going to e-mail or PM you or something about <a href='http://www.unknownworlds.com/forums/index.php?act=ST&f=4&t=57925' target='_blank'>this thread</a>, but I'll just post it here because I'm afflicted with chronic laziness. I've taken a look at the ZHLT source myself after posting that, and I see some of the details might not be quite correct, but I believe the essence of my idea is clear and intelligent. Please give it a lookie. <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->
This might seem kinda off topic and out of place (ie completely the wrong mod forums), but seeing as it's your version of the tools I'm using this'd be the only place...
Well anyways I've been using these tools to compile maps for other mods too, namely Sven-Coop, and I've found that info_nodes are making connections to info_nodes on the other side of func_monsterclip entities. I just recently heard that it was csg that was responsible for making the break in the node graph, which means there's a chance that it could be these tools causing this really tiny error. I tried asking the Sven Coop crowd first on what keeps making my monsters try to roam past func_monsterclips, but nobody answered... o_O
If you guys mean that the brush appears totally black, as if no lighting were "hitting" it. Try to "Tie to entity" again, and when you're asked about if you want to keep the entity say No (create a new one). The problem should go away.
<!--QuoteBegin--Erias+Jan 11 2004, 11:20 AM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (Erias @ Jan 11 2004, 11:20 AM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->Oh yeah, XP-Cagey, I was going to e-mail or PM you or something about <a href='http://www.unknownworlds.com/forums/index.php?act=ST&f=4&t=57925' target='_blank'>this thread</a>, but I'll just post it here because I'm afflicted with chronic laziness. I've taken a look at the ZHLT source myself after posting that, and I see some of the details might not be quite correct, but I believe the essence of my idea is clear and intelligent. Please give it a lookie. <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo--><!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd--> I'll read and comment.
<!--QuoteBegin--Revenge+Posted on Jan 11 2004, 04:18 PM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (Revenge @ Posted on Jan 11 2004, 04:18 PM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->I just recently heard that it was csg that was responsible for making the break in the node graph, which means there's a chance that it could be these tools causing this really tiny error.<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
CSG converts a list of brushes to a list of exposed faces; it doesn't have any knowledge of a structural heirarchy beyond brush groupings by entity number. If by 'node graph' you mean 'bsp tree', that's BSP's job. There isn't, however, any actual node graph for AI movement calculated at any point in the tools (unlike Q3's bot paths, which are precalculated). The Half-Life tools don't know what func_monsterclip or info_nodes entities are for. I'd look for more information on the limitations of func_monsterclip to see what sort placement is optimal for actually shutting mosters out of areas.
Oh it does effectively shut monsters out of these areas, any monsters with with the "monsterclip" spawnflag are blocked properly, it's just that they don't realise it.
The effect is that when you set your monsters to randomly wander around the node graph (as in the network of valid connections between all your info_node entities, ie waypoints), they'll try to walk through the func_monsterclip, twitch as they hit an invisible wall, go idle for half a second, and then attempt to pass through the func_monsterclip again. The eventual effect is a bunch of monsters lined up against a doorway twitching and jittering...
The current work arounds seem to be to either disable the monsterclipped monsters from being able to wander around freely, or to place the info_nodes in such a way that a connection would not form to info_nodes on the other side of the func_monsterclip even if there was none there (meaning that non-monsterclipped monsters such as player allies following players around might have difficulty following players through these sections).
<!--QuoteBegin--Revenge+Jan 12 2004, 10:11 AM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (Revenge @ Jan 12 2004, 10:11 AM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> The effect is that when you set your monsters to randomly wander around the node graph (as in the network of valid connections between all your info_node entities, ie waypoints), they'll try to walk through the func_monsterclip, twitch as they hit an invisible wall, go idle for half a second, and then attempt to pass through the func_monsterclip again. The eventual effect is a bunch of monsters lined up against a doorway twitching and jittering... <!--QuoteEnd--> </td></tr></table><span class='postcolor'> <!--QuoteEEnd--> Sounds more like a problem in the AI implementation than a compiler issue <!--emo&???--><img src='http://www.unknownworlds.com/forums/html/emoticons/confused.gif' border='0' style='vertical-align:middle' alt='confused.gif'><!--endemo--> .
I might not get p13 out the door tonight -- my hard drive is acting up on the partition I use to store all of my programming work, taking up to 2 minutes to read the root directory contents. I've backed everything up periodically (a good habit for mappers too, I might add) so I don't stand to lose anything if my HD dies completely, but the fact that the HD is hit-and-miss is definitely slowing me down.
I've run MS's built-in HD error checking, which didn't turn up any problems (logical or physical). I'm wondering if the issues I'm experiencing might be virus related, in which case the last thing I'm going to do is release an executable file to the public. I may decide to try a HD wipe and OS reinstall, which could mean a delay of several days. At this point, I can't garuntee a release date, although the majority of the work has been done.
The original delay, btw, was me getting over the flu.
Well yeah, but the thing is that when I brought up the node graph, I noticed the yellow indicator lines running right through the monsterclipped doorway (impulse 197 or 196 or something, can't remember off the top of my head), where as normally these lines should be stopped from going through...
The node graph is created locally the first time you run a map in HL, long after the compile is done... Which is exactly why I expected no connections to form... Perhaps it's got something to do with the way SC's mod team modified the AI to handle doors better (which also previously used to block node graph connections)...
Anyways here's what caused me to ask if there was anything in the compiler that could be causing this minor bug: <a href='http://spirit.valve-erc.com/guide/EntityGuide.html#func_monsterclip' target='_blank'>http://spirit.valve-erc.com/guide/EntityGu...unc_monsterclip</a> (which I'm now guessing is most likely incorrect)
<!--QuoteBegin--Revenge+Jan 13 2004, 12:02 AM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (Revenge @ Jan 13 2004, 12:02 AM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> Well yeah, but the thing is that when I brought up the node graph, I noticed the yellow indicator lines running right through the monsterclipped doorway (impulse 197 or 196 or something, can't remember off the top of my head), where as normally these lines should be stopped from going through...
The node graph is created locally the first time you run a map in HL, long after the compile is done... Which is exactly why I expected no connections to form... Perhaps it's got something to do with the way SC's mod team modified the AI to handle doors better (which also previously used to block node graph connections)...
Anyways here's what caused me to ask if there was anything in the compiler that could be causing this minor bug: <a href='http://spirit.valve-erc.com/guide/EntityGuide.html#func_monsterclip' target='_blank'>http://spirit.valve-erc.com/guide/EntityGu...unc_monsterclip</a> (which I'm now guessing is most likely incorrect)
Thanks anyway <!--QuoteEnd--> </td></tr></table><span class='postcolor'> <!--QuoteEEnd--> Yeah, the Spirit entity guide is wrong on that point. The func_monsterclip doesn't prevent a path being created between nodes; it just marks the path as impassable (because func_monsterclips can be toggled on/off). As far as I know, the node graph display doesn't take into account the impassable flag, as paths through func_doors are also marked impassable and display as well.
Would it be possible to add an entity that blocks light but aren't saved into the bsp file, XP-Cagey? <!--emo&:D--><img src='http://www.unknownworlds.com/forums/html/emoticons/biggrin.gif' border='0' style='vertical-align:middle' alt='biggrin.gif'><!--endemo--> Would like to add some ligt details but don't wanna spend any entities or world brushes on it (considering r_speeds)
<!--QuoteBegin--Andos+Jan 16 2004, 04:31 AM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (Andos @ Jan 16 2004, 04:31 AM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> Would it be possible to add an entity that blocks light but aren't saved into the bsp file, XP-Cagey? <!--emo&:D--><img src='http://www.unknownworlds.com/forums/html/emoticons/biggrin.gif' border='0' style='vertical-align:middle' alt='biggrin.gif'><!--endemo--> Would like to add some ligt details but don't wanna spend any entities or world brushes on it (considering r_speeds) <!--QuoteEnd--> </td></tr></table><span class='postcolor'> <!--QuoteEEnd--> You could remove the entity with ripents after you're done running hlrad--the faces, points, edges, etc. will still be in the map, but won't ever be drawn, so your two goals -- no entity count or r_speed contribution -- will be met.
Ah i hoped to avoid this <!--emo&???--><img src='http://www.unknownworlds.com/forums/html/emoticons/confused.gif' border='0' style='vertical-align:middle' alt='confused.gif'><!--endemo--> I'm gonna go read some tutorials on this now <!--emo&:p--><img src='http://www.unknownworlds.com/forums/html/emoticons/tounge.gif' border='0' style='vertical-align:middle' alt='tounge.gif'><!--endemo-->
Cagey, as I mentioned earlier, how about adding support for compiling to the slightly modified BlueShift format? This means that people playing BS without the BS patch which allows them to play standard BSP files would be able to play it fine. I guess it would also mean that the map would not be playable without BlueShift (though I'm not sure how Steam would affect that). Perhaps for p14?
Also, when is p13 going to make an appearance? <!--emo&???--><img src='http://www.unknownworlds.com/forums/html/emoticons/confused.gif' border='0' style='vertical-align:middle' alt='confused.gif'><!--endemo-->
<!--QuoteBegin--Reve+Jan 20 2004, 04:06 AM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (Reve @ Jan 20 2004, 04:06 AM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> Cagey, as I mentioned earlier, how about adding support for compiling to the slightly modified BlueShift format? This means that people playing BS without the BS patch which allows them to play standard BSP files would be able to play it fine. I guess it would also mean that the map would not be playable without BlueShift (though I'm not sure how Steam would affect that). Perhaps for p14? <!--QuoteEnd--> </td></tr></table><span class='postcolor'> <!--QuoteEEnd--> I'm downloading the Blue Shift SDK to see if they have any information on the modified map format. If it's not publicly available, I'm probably not going to reverse engineer the format (although I guess Zipster has done that already for BSPtwoMAP). I don't think this is a high priority since Blue Shift does have a patch to allow backward compatibility with the standard format.
<!--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-->Also, when is p13 going to make an appearance? <!--emo&???--><img src='http://www.unknownworlds.com/forums/html/emoticons/confused.gif' border='0' style='vertical-align:middle' alt='confused.gif'><!--endemo--><!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
p13 is feature complete -- I have some testing to do before I make a public release. "Soon" <!--emo&:(--><img src='http://www.unknownworlds.com/forums/html/emoticons/sad.gif' border='0' style='vertical-align:middle' alt='sad.gif'><!--endemo--> .
Take your time. I can wait... as long as it comes out faster than 3.0. <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->
Yeah no rush Cagey, the old ones work to and we want to have a nice working p13 to <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->
Cagey, I wouldn't mind writing the merged docs for your p-series. Obviously not to hold the release of p13 but perhaps in time for p14. I have the docs for ZHLT 2.5.3 and MHLT 1.7 - anyway, give me a shout if you'd be interested (everyone knows docs are the bane of coders lives <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo--> ).
Uh, and I don't know whether this is a question for XP-Cagey or hullu, but how much faster is the overall RAD process roughly with hullu's custom code added? Does it only speed up shadows where you get light shining through transparent brushes? Or is it more generally applicable?
<!--QuoteBegin-Reve+Jan 22 2004, 11:13 AM--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (Reve @ Jan 22 2004, 11:13 AM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> Uh, and I don't know whether this is a question for XP-Cagey or hullu, but how much faster is the overall RAD process roughly with hullu's custom code added? Does it only speed up shadows where you get light shining through transparent brushes? Or is it more generally applicable? <!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd--> faster when compiling map that uses custom shadows.
<!--QuoteBegin-tomteverkstan+Feb 3 2004, 11:38 PM--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (tomteverkstan @ Feb 3 2004, 11:38 PM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> well, im not using any other program to compile then hammer and i was wondering how i use the optimizer what do i write in the command thingi <!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd--> See the attached image.
<!--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-->if im going to compile in another way then original hammer, what should i do\get?<!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
I'd recommend Nem's batch compiler -- see <a href='http://www.unknownworlds.com/forums/index.php?showtopic=50171' target='_blank'>this</a> excellent thread for setup instructions -- download it from the link in the first post, install it according to the instructions in the second post.
<!--QuoteBegin-Reese+Feb 4 2004, 02:02 AM--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (Reese @ Feb 4 2004, 02:02 AM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->so, what's the status on the p13 series? Aside from leaving you alone to get some work done is there any way that we can help out with it?<!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd--> Not much to do now except <a href='http://www.xp-cagey.com/downloads/ZHLT_1.7p13.zip' target='_blank'>download</a> it <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html//emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif' /><!--endemo-->
I was holding up the works by not getting a better command reference out for features since Merl's last build; I've decided that I'll fix the documentation for p14 instead--people have had to use the readme since p3, so it's not a major regression.
The new version comes packed with new .dlls and documentation from Zoner and Merl -- I'd recommend completely deleting your current "p" series install (including the old required dlls) before installing this package.
The zip file weighs in at about 550K -- most of that bulk is the new .dlls required by MSVC 7.1. I'll be offering full and upgrade versions of the p14 install, which will require the same dlls as p13.
I toyed with the idea of using an installer, but I don't want to make things any more difficult for Linux users than they already are <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html//emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif' /><!--endemo-->.
Now for anyone who wants to use noclip and invisible options...
Drop the following into your FGD somewhere up the top preferably: <!--c1--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>CODE</b> </td></tr><tr><td id='CODE'><!--ec1--> @BaseClass = XPHLT // XP-Cagey's invisible and noclip options [ zhlt_invisible(choices) : "Invisible (XP-HLT)" : 0 = [ 0: "Off (0)" 1: "On (1)" ] zhlt_noclip(choices) : "No CLIP (XP-HLT)" : 0 = [ 0: "Off (0)" 1: "On (1)" ] ] <!--c2--></td></tr></table><div class='postcolor'><!--ec2-->
Then on any brush based entity add XPHLT to the list of properties. For example the func_wall: EDIT: These should appear on ONE line in your FGD file. Seems its getting wrapped on this page. Might be my screen res <!--emo&:)--><img src='http://www.natural-selection.org/forums/html//emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif' /><!--endemo--> <!--c1--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>CODE</b> </td></tr><tr><td id='CODE'><!--ec1--> @SolidClass base(Targetname, MoveWith, Appearflags, RenderFields, ZHLTLightKeys, SwitchTexLight, Global) = func_wall : "Wall" <!--c2--></td></tr></table><div class='postcolor'><!--ec2--> Would become: <!--c1--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>CODE</b> </td></tr><tr><td id='CODE'><!--ec1--> @SolidClass base(Targetname, MoveWith, Appearflags, RenderFields, ZHLTLightKeys, SwitchTexLight, Global, XPHLT) = func_wall : "Wall" <!--c2--></td></tr></table><div class='postcolor'><!--ec2-->
If anyone dosent like the "XPHLT" monkier you can, of course, change it. I just wanted something simple for the FGD. <!--emo&:)--><img src='http://www.natural-selection.org/forums/html//emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif' /><!--endemo-->
XP-Cagey: What SHOULD we call your modified tools? Putting "ZHLT 'P' series" into FGDs is rather silly methinks, however accurate it may be..
Comments
Real life intervened <!--emo&???--><img src='http://www.unknownworlds.com/forums/html/emoticons/confused.gif' border='0' style='vertical-align:middle' alt='confused.gif'><!--endemo-->
I'm going to get p13 tested and ready for public use by the night of the 12th.
lightdata - what is this flag used to combat?
i was trying to combat max patches, with out having to fall back on the less powerful sparse, as funk_seethrough gets rendered darker then on normal extra
so realy i have 1 bug - all p12 tools used
funk_seethrough opaqce (typo) flag active
funk_seethrough gets rendered darker with sparse, over normal extra
When I set some brush entities as opaque, they end up looking extremely dark (the lightmap is essentially black.) This must be a bug in the ZHLT p-series...
So this is me asking what is up with that and complaining loudly... <!--emo&:p--><img src='http://www.unknownworlds.com/forums/html/emoticons/tounge.gif' border='0' style='vertical-align:middle' alt='tounge.gif'><!--endemo-->
From the readme file:
<!--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-->1.7p11 -
Feature Addition (RAD): added -lightdata <#> switch to allow user to set custom
lightdata maximum value. Works like the -texdata switch. Default maximum light
data amount bumped to 8MB.<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
p12 bumped the default lightdata max back to 6MB.
<!--QuoteBegin--Erias+Jan 11 2004, 03:14 AM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (Erias @ Jan 11 2004, 03:14 AM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->When I set some brush entities as opaque, they end up looking extremely dark (the lightmap is essentially black.) This must be a bug in the ZHLT p-series...<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
Does the same object light properly using Merl's 1.7 download? Can't think of any changes I've made since the original HLRAD speedups that might affect this, and I know those are now functioning identically to the original code (I reverted the second batch of HLRAD changes from p11 to p12).
If 1.7 does light it properly, I'll see what I can do for p14.
From the 2.5.3 docs (Yes, I found them--there was a french lycos site that hadn't updated its downloads section in years <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->. All of the docs will be bundled with p13.)
<!--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-->zhlt_lightflags Set optional lightflags. Can be applied to any brush based entity.
0 is default
1 is 'EmbeddedFix'
2 is the Opaque flag(blocks light)
3 is Opaque+EmbeddedFix
4 is 'ConcaveFix' (must be used with opaque, this setting is useless by itself)
6 is Opaque+ConcaveFix
For opaque brushes, it will be frequently necessary to place point lights inside the brush so that faces obscured by the brushes are properly lit (for example the trim adjacent to a func_door). Setting the opaque bit is useful for most func_walls, some func_illusionary's, the occasional func_door, and possibly others for some effect.
The 'EmbeddedFix' is for telling hlrad to not used the complex light bleed fix on the entity, as sometimes when creating a brush entity that sticks through a wall, it will be lit incorrectly from the other side of the wall due to the bleed correction.
The 'ConcaveFix' is needed for curved func_walls, notably arch shapes. When they are set to opaque, the inner curve (the concave porition) will frequently have black fringes at the joins where brushes touch up. Setting the ConcaveFix flag fixes the black seams in these cases, but then the entity cannot have the EmbeddedFix set.<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
Try setting the lightflags to 6 instead of 2 and see if that helps light your entity properly.
I'll look into it. Maybe it's something on my end.
Oh yeah, XP-Cagey, I was going to e-mail or PM you or something about <a href='http://www.unknownworlds.com/forums/index.php?act=ST&f=4&t=57925' target='_blank'>this thread</a>, but I'll just post it here because I'm afflicted with chronic laziness. I've taken a look at the ZHLT source myself after posting that, and I see some of the details might not be quite correct, but I believe the essence of my idea is clear and intelligent. Please give it a lookie. <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->
amckern
Well anyways I've been using these tools to compile maps for other mods too, namely Sven-Coop, and I've found that info_nodes are making connections to info_nodes on the other side of func_monsterclip entities. I just recently heard that it was csg that was responsible for making the break in the node graph, which means there's a chance that it could be these tools causing this really tiny error. I tried asking the Sven Coop crowd first on what keeps making my monsters try to roam past func_monsterclips, but nobody answered... o_O
Any ideas?
I'll read and comment.
<!--QuoteBegin--Revenge+Posted on Jan 11 2004, 04:18 PM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (Revenge @ Posted on Jan 11 2004, 04:18 PM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->I just recently heard that it was csg that was responsible for making the break in the node graph, which means there's a chance that it could be these tools causing this really tiny error.<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
CSG converts a list of brushes to a list of exposed faces; it doesn't have any knowledge of a structural heirarchy beyond brush groupings by entity number. If by 'node graph' you mean 'bsp tree', that's BSP's job. There isn't, however, any actual node graph for AI movement calculated at any point in the tools (unlike Q3's bot paths, which are precalculated). The Half-Life tools don't know what func_monsterclip or info_nodes entities are for. I'd look for more information on the limitations of func_monsterclip to see what sort placement is optimal for actually shutting mosters out of areas.
The effect is that when you set your monsters to randomly wander around the node graph (as in the network of valid connections between all your info_node entities, ie waypoints), they'll try to walk through the func_monsterclip, twitch as they hit an invisible wall, go idle for half a second, and then attempt to pass through the func_monsterclip again. The eventual effect is a bunch of monsters lined up against a doorway twitching and jittering...
The current work arounds seem to be to either disable the monsterclipped monsters from being able to wander around freely, or to place the info_nodes in such a way that a connection would not form to info_nodes on the other side of the func_monsterclip even if there was none there (meaning that non-monsterclipped monsters such as player allies following players around might have difficulty following players through these sections).
Sounds more like a problem in the AI implementation than a compiler issue <!--emo&???--><img src='http://www.unknownworlds.com/forums/html/emoticons/confused.gif' border='0' style='vertical-align:middle' alt='confused.gif'><!--endemo--> .
I've run MS's built-in HD error checking, which didn't turn up any problems (logical or physical). I'm wondering if the issues I'm experiencing might be virus related, in which case the last thing I'm going to do is release an executable file to the public. I may decide to try a HD wipe and OS reinstall, which could mean a delay of several days. At this point, I can't garuntee a release date, although the majority of the work has been done.
The original delay, btw, was me getting over the flu.
The node graph is created locally the first time you run a map in HL, long after the compile is done... Which is exactly why I expected no connections to form... Perhaps it's got something to do with the way SC's mod team modified the AI to handle doors better (which also previously used to block node graph connections)...
Anyways here's what caused me to ask if there was anything in the compiler that could be causing this minor bug: <a href='http://spirit.valve-erc.com/guide/EntityGuide.html#func_monsterclip' target='_blank'>http://spirit.valve-erc.com/guide/EntityGu...unc_monsterclip</a> (which I'm now guessing is most likely incorrect)
Thanks anyway
The node graph is created locally the first time you run a map in HL, long after the compile is done... Which is exactly why I expected no connections to form... Perhaps it's got something to do with the way SC's mod team modified the AI to handle doors better (which also previously used to block node graph connections)...
Anyways here's what caused me to ask if there was anything in the compiler that could be causing this minor bug: <a href='http://spirit.valve-erc.com/guide/EntityGuide.html#func_monsterclip' target='_blank'>http://spirit.valve-erc.com/guide/EntityGu...unc_monsterclip</a> (which I'm now guessing is most likely incorrect)
Thanks anyway <!--QuoteEnd--> </td></tr></table><span class='postcolor'> <!--QuoteEEnd-->
Yeah, the Spirit entity guide is wrong on that point. The func_monsterclip doesn't prevent a path being created between nodes; it just marks the path as impassable (because func_monsterclips can be toggled on/off). As far as I know, the node graph display doesn't take into account the impassable flag, as paths through func_doors are also marked impassable and display as well.
Would like to add some ligt details but don't wanna spend any entities or world brushes on it (considering r_speeds)
Would like to add some ligt details but don't wanna spend any entities or world brushes on it (considering r_speeds) <!--QuoteEnd--> </td></tr></table><span class='postcolor'> <!--QuoteEEnd-->
You could remove the entity with ripents after you're done running hlrad--the faces, points, edges, etc. will still be in the map, but won't ever be drawn, so your two goals -- no entity count or r_speed contribution -- will be met.
I'm gonna go read some tutorials on this now <!--emo&:p--><img src='http://www.unknownworlds.com/forums/html/emoticons/tounge.gif' border='0' style='vertical-align:middle' alt='tounge.gif'><!--endemo-->
Also, when is p13 going to make an appearance? <!--emo&???--><img src='http://www.unknownworlds.com/forums/html/emoticons/confused.gif' border='0' style='vertical-align:middle' alt='confused.gif'><!--endemo-->
Reve
I'm downloading the Blue Shift SDK to see if they have any information on the modified map format. If it's not publicly available, I'm probably not going to reverse engineer the format (although I guess Zipster has done that already for BSPtwoMAP). I don't think this is a high priority since Blue Shift does have a patch to allow backward compatibility with the standard format.
<!--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-->Also, when is p13 going to make an appearance? <!--emo&???--><img src='http://www.unknownworlds.com/forums/html/emoticons/confused.gif' border='0' style='vertical-align:middle' alt='confused.gif'><!--endemo--><!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
p13 is feature complete -- I have some testing to do before I make a public release. "Soon" <!--emo&:(--><img src='http://www.unknownworlds.com/forums/html/emoticons/sad.gif' border='0' style='vertical-align:middle' alt='sad.gif'><!--endemo--> .
Uh, and I don't know whether this is a question for XP-Cagey or hullu, but how much faster is the overall RAD process roughly with hullu's custom code added? Does it only speed up shadows where you get light shining through transparent brushes? Or is it more generally applicable?
Thanks
Reve
<!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
faster when compiling map that uses custom shadows.
what do i write in the command thingi
<img src='http://www.tomteverkstan.no-ip.com/compile.jpg' border='0' alt='user posted image' />
i think maybe i should get me another compiler but anyhow, how do you do it?
if im going to compile in another way then original hammer, what should i do\get?
what do i write in the command thingi <!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
See the attached image.
<!--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-->if im going to compile in another way then original hammer, what should i do\get?<!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
I'd recommend Nem's batch compiler -- see <a href='http://www.unknownworlds.com/forums/index.php?showtopic=50171' target='_blank'>this</a> excellent thread for setup instructions -- download it from the link in the first post, install it according to the instructions in the second post.
Not much to do now except <a href='http://www.xp-cagey.com/downloads/ZHLT_1.7p13.zip' target='_blank'>download</a> it <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html//emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif' /><!--endemo-->
I was holding up the works by not getting a better command reference out for features since Merl's last build; I've decided that I'll fix the documentation for p14 instead--people have had to use the readme since p3, so it's not a major regression.
The new version comes packed with new .dlls and documentation from Zoner and Merl -- I'd recommend completely deleting your current "p" series install (including the old required dlls) before installing this package.
The zip file weighs in at about 550K -- most of that bulk is the new .dlls required by MSVC 7.1. I'll be offering full and upgrade versions of the p14 install, which will require the same dlls as p13.
I toyed with the idea of using an installer, but I don't want to make things any more difficult for Linux users than they already are <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html//emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif' /><!--endemo-->.
go cagey!
Once again great work XP-Cagey!
Now for anyone who wants to use noclip and invisible options...
Drop the following into your FGD somewhere up the top preferably:
<!--c1--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>CODE</b> </td></tr><tr><td id='CODE'><!--ec1-->
@BaseClass = XPHLT // XP-Cagey's invisible and noclip options
[
zhlt_invisible(choices) : "Invisible (XP-HLT)" : 0 =
[
0: "Off (0)"
1: "On (1)"
]
zhlt_noclip(choices) : "No CLIP (XP-HLT)" : 0 =
[
0: "Off (0)"
1: "On (1)"
]
]
<!--c2--></td></tr></table><div class='postcolor'><!--ec2-->
Then on any brush based entity add XPHLT to the list of properties.
For example the func_wall:
EDIT: These should appear on ONE line in your FGD file. Seems its getting wrapped on this page. Might be my screen res <!--emo&:)--><img src='http://www.natural-selection.org/forums/html//emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif' /><!--endemo-->
<!--c1--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>CODE</b> </td></tr><tr><td id='CODE'><!--ec1-->
@SolidClass base(Targetname, MoveWith, Appearflags, RenderFields, ZHLTLightKeys, SwitchTexLight, Global) = func_wall : "Wall"
<!--c2--></td></tr></table><div class='postcolor'><!--ec2-->
Would become:
<!--c1--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>CODE</b> </td></tr><tr><td id='CODE'><!--ec1-->
@SolidClass base(Targetname, MoveWith, Appearflags, RenderFields, ZHLTLightKeys, SwitchTexLight, Global, XPHLT) = func_wall : "Wall"
<!--c2--></td></tr></table><div class='postcolor'><!--ec2-->
If anyone dosent like the "XPHLT" monkier you can, of course, change it. I just wanted something simple for the FGD. <!--emo&:)--><img src='http://www.natural-selection.org/forums/html//emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif' /><!--endemo-->
XP-Cagey: What SHOULD we call your modified tools? Putting "ZHLT 'P' series" into FGDs is rather silly methinks, however accurate it may be..