Here's a link about <a href='http://www.melax.com/csg/' target='_blank'>CSG operations with BSPs</a> that came out shortly after the original Red Faction was released. The same site has some very nifty (though relatively obvious in hindsight) tidbits that are actually surprisingly close to how I understand Q3A handles <a href='http://www.melax.com/bsp/index.html' target='_blank'>arbitrary-sized hull collisions against a single BSP</a>.
<!--QuoteBegin--WolfWings+Oct 2 2003, 12:13 PM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (WolfWings @ Oct 2 2003, 12:13 PM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->Just in case either are useful. :-)<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd--> I think the article by Bruce Naylor et. al. from the SIGGRAPH '90 Proceedings (first link mentions it, thanks for passing it along) might be what I need... I'm contemplating membership in ACM or SIGGRAPH to access the article.
EDIT : found the basic algorithm from that paper on my bookshelf -- guess I didn't look throughly enough the first time <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->. I'm also suscribing to <a href='http://lists.sourceforge.net/lists/listinfo/gdalgorithms-list' target='_blank'>GDAlgorithms-list</a> on SourceForge.
p12 is out! The major difference between this and p11 is a fix for the bug that Kage reported. I've also commented out the useless SDF::4 message that some people were seeing during HLRAD.
Thanks to both Kage and WolfWings for reporting problems with p11 and testing the p12 release cantidates.
Just downloaded the file from the first post and while I unpacked them over my existing version WinRAR showed me these 'overwrite' dialogs and all files seem to be the same size, is that right?
EDIT: Well, at least it says it is version p12, that's enough for me <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->
This might or might not be a bug-report for the tools, but it's a voodoo-what-the-heck bug report, that's for sure.
I was tinkering with Extreme Mapping (open up this file, you'll see, 19 entities for one door, albeit a VERY nice door with pretty lighting, which I honestly think could be done in 5 entities with proper support) and have suddenly started running into an interesting problem.
If I set <span style='color:yellow'>zhlt_noclip 1</span> on brush-based entities, suddenly these uber-huge clipping boxes 'spring up' in-game apparently. I thought zhlt_noclip was supposed to remove all clipping information from a brush-based entity?
So, um... is this a bug in your tools, Cagey? It's not Natural-Selection specific, as loading all the textures into the BSP and running it under Valve and TFC both exhibits identical behavior.
And yes, anyone is free to pull this apart, but right now until Cagey tells me what I did wrong, it's not very useful to most folks. :-)
<!--QuoteBegin--WolfWings+Oct 10 2003, 03:38 PM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (WolfWings @ Oct 10 2003, 03:38 PM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> This might or might not be a bug-report for the tools, but it's a voodoo-what-the-heck bug report, that's for sure.
I was tinkering with Extreme Mapping (open up this file, you'll see, 19 entities for one door, albeit a VERY nice door with pretty lighting, which I honestly think could be done in 5 entities with proper support) and have suddenly started running into an interesting problem.
If I set <span style='color:yellow'>zhlt_noclip 1</span> on brush-based entities, suddenly these uber-huge clipping boxes 'spring up' in-game apparently. I thought zhlt_noclip was supposed to remove all clipping information from a brush-based entity?
So, um... is this a bug in your tools, Cagey? It's not Natural-Selection specific, as loading all the textures into the BSP and running it under Valve and TFC both exhibits identical behavior.
And yes, anyone is free to pull this apart, but right now until Cagey tells me what I did wrong, it's not very useful to most folks. :-) <!--QuoteEnd--> </td></tr></table><span class='postcolor'> <!--QuoteEEnd--> Sounds like it's a bug, possibly in the hull index used for the noclip items' clip hulls. Added to my to-do list.
<!--QuoteBegin--XP-Cagey+Oct 10 2003, 03:48 PM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (XP-Cagey @ Oct 10 2003, 03:48 PM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> Sounds like it's a bug, possibly in the hull index used for the noclip items' clip hulls. Added to my to-do list. <!--QuoteEnd--> </td></tr></table><span class='postcolor'> <!--QuoteEEnd--> Okay... knowing what to look for, I used some BSP Tools I have to pull apart the BSP partially, and looked through the hull-indexes.
The zhlt_noclip entities got assigned the same headnode for hulls 1-3 as hull 1 of the first non-zhlt_noclip entity <b>after</b> them, curiously enough.
This apparently wouldn't be an issue for non-moving entities, and may be how zhlt_noclip works by design, but if so it wasn't mentioned anywhere that I know of.
And in case anyone is interested, updated the .ZIP file with the non-zhlt_noclip version of the map, so everything works and anyone can rip the .map apart if they want to use that door fragment in their own maps.
Basically, it's one of the doors from NS2.wad, horizontal, splits in half, with irregular windows in both halves which are properly 'windows' in-game as well. The button controlling it is a rather complicated piece of work that emits light that's adjusted to match the texture when you open and close the door.
Current, the button (placed on both sides of the door with one entity) and the lighting around it are redish when the door is closed, and greenish when the door is open. The actual 'button' on the button entity depresses momentarilly when used, and the door itself auto-disables whenever someone is standing in the doorway. So no, no crushing oni in this door. :-)
The door itself actually 'cheats' by using a func_wall_toggle as the actual door, the door panels are flagged as non-solid, and there are proper 'carvings' into the doorframe for the door panels to slide into.
Yes, this was an experiment in maximum immersion, but NOT at the cost of r_speeds, which are a svelt 50ish for the door if you re-use it in your own level.
Sadly, due to the limitations of the entities in Half-Life, it <b>was</b> rather costly in entity-count. The entire contraption comes in at 19 entities, though over half of them are point entities or part of a pair of 'switched entities' to give full control over the texture-lighting and texturing of the button itself.
Specifically:
6 func_door (4 for the central door itself, 2 more for the 'depressed button' in the visual button) 5 func_wall_toggle (1 for the actual door, 2 for the 'redish' texturing and glow on the button, 2 for the 'greenish' texturing and glow on the button) 2 'targetted' light (1 for the redish lighting, 1 for the greenish lighting) 1 trigger_presence (to make the door 'crushproof') 2 env_global (1 to 'enable' the button, 1 to 'disable' the button, crushproofing and re-use-delaying) 1 multisource (provides the linkage between the env_globals and the actual button to enable/disable it) 1 multi_manager (to trigger the texturing and lighting changes, along with disabling the button for 1 second each time it's used)
Of those, what could be reduced?
The 6 func_doors couldn't be reduced any further, though 2 could be deleted if you made the 'button' non-moving. The 5 func_walls could be reduced to 3 in-game if HLRad supported deleting an entity after it provided switchable texlight, a 'throw this out after it provides it's share of light' flag. The 2 lights are something we're stuck with, unless Flayra hijacks the code from Spirit of Half-Life, which he probably should. :-) The 1 trigger_presence couldn't be removed unless it could be 'merged' with the func_wall that provides the actual 'solid' door. A similair situation exists for the 2 env_globals, the multisource, and the multi_manager. If NS supported actual scripting, akin to Hexen, where you could specify a set of commands to process in order, most of these entities could be removed. Perhaps a scripting language similair to this Pseudo-C:
<!--QuoteBegin--WolfWings+Oct 10 2003, 05:14 PM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (WolfWings @ Oct 10 2003, 05:14 PM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> The zhlt_noclip entities got assigned the same headnode for hulls 1-3 as hull 1 of the first non-zhlt_noclip entity <b>after</b> them, curiously enough. <!--QuoteEnd--> </td></tr></table><span class='postcolor'> <!--QuoteEEnd--> I actually reused Zoner's code for func_illusionary clip hull replacement -- what I need to do is define a minimally defined single hull with no solid areas, and use that single extra hull for all the cases of zhlt_noclip and all of the entities that Zoner had already set to noclip. I have a pretty full to-do list at the moment (I've actually kept some people waiting), but I'll work this out when I have a chance.
<b>Edit: Just realised that this will most likely destroy your "lights reflect the state of the door", as you could trick the lights into displaying the wrong colour for the wrong door state...</b>
I've been trying to nut this out on paper for a while now, and if I get anything that produces the same results with fewer entities I'll post it, but for now I'd imagine you could save your self the func_wall_toggle, multisource and 2 env_global by a little bit of tricky brush work.
I don't know how it works in Radient, but if it works along the same lines of "create brushes, convert them to entities", then this should work.
Ok, firstly the bottom door. The door itself is fine, but instead of cutting the glass to exact shape of the hole, give it atleast 1 or 2 units overlap into the door itself, this is so you wont see any gaps if the glass and door misaligns momentarily.
Now create a separate, thin, brush (part of the glass entity however), and place it 1 unit under the lip of the door. The effect is that if the door collides with a player, then glass is only 1 unit behind the door and will hit the player almost as soon as the door does. This should stop the strange effect where the player blocks the door and the glass moves on for a couple of dozen units before finally hitting something. Repeat the whole lot for the top door.
Now that it wont look weird, you can safely tell the door to do little damage, and so the door will attempt to close, hit a player and slowly start squeezing the player to death (well sometimes... I have accidentally created func_doors that simply keep crushing until the player doors, but when others have tried to recreate that effect have found that their doors simply return to the open position normally).
I already trimmed entities from the mix, actually.
I was able to get rid of one of the func_wall_toggles, and convert another to a simple func_wall.
Second, your method would indeed allow the lights to get out of sync with the rest of the door-system, which is why I'm not using that method.
Third, as I said before, the overall server load from this system is relatively trivial, but unfortunately it NUMERICALLY uses many entities. In all honesty, this is a very low server-load construction, but NS doesn't make distinctions between 'light' and 'heavy' entities, such as the 'glue' entities I'm using, compared to complicated entities that other constructions use, or complicated solid geometry which makes the server work harder to handle intersection calculations.
Good point about the actual server strained caused by the entities. I remember reading that ollj once created a map will thousands of simple entities (for teleporting) and it didn't cause any problems...
iam mapping for cstrike and i have the max_map_planes error when i compile my map <!--emo&:(--><img src='http://www.unknownworlds.com/forums/html/emoticons/sad.gif' border='0' style='vertical-align:middle' alt='sad.gif'><!--endemo--> i have search with google to fix this problem without reducing brushes, so i found this topic <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo--> i have download the zklt-max_map_planes_fix.zip and used this compilers in hlcc i have copied the msvcp70.dll and the msvcr70.dll in my windows/system folder (win98)
when i start hlcc and press "compile" to compile my map i get this error: <a href='http://c.scharhag.bei.t-online.de/error.gif' target='_blank'>http://c.scharhag.bei.t-online.de/error.gif</a> (sry, for german )
You have downloaded two different versions of the dlls. The new versions don't have this exported function any longer so your old MSVCP70.dll tries to load the function __iob_func that no longer exists in MSVCR70.dll. Simply redownload MSVCP70.dll and the problem should be gone.
The first stage of my planned facelift for <a href='http://xp-cagey.com' target='_blank'>XP-Cagey.com</a> has finally gone public; the home of the tools is less homely. I'll be opening up the forums to the public once I'm sure that the underlying code is stable, at which point this thread can die gracefully <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->.
<!--QuoteBegin--Reve+Nov 10 2003, 07:16 AM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (Reve @ Nov 10 2003, 07:16 AM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> Cagey - what are the currently expected release notes/highlights for p13?
Reve <!--QuoteEnd--> </td></tr></table><span class='postcolor'> <!--QuoteEEnd--> p13 - Bugfix for zhlt_noclip - create 1 empty clip hull and share it for all noclip brush entities' 3 clip hulls instead of using the clip hulls of the next entity
I'm looking for the source of some holes that people are reporting in worldspawn clipping after BSP is finished -- the problem appears after CSG exports the face list to file and before the final output of BSP is written out; no garuntees that p13 will be the build where I catch it, though, since it's difficult to duplicate and it's not specific to any code that I've added.
Aside from those known bugs, I'm not working on anything new at the moment for the "p" series; I'm trying to make the release builds of ZHLT as stable as possible at the moment while I work on the alternative tools. Most of the innovations I've come up with in the last few months are being targeted for the HLCSG & HLBSP replacements I'm currently writing since they'd require overhauls to the static data structures that the ZHLT series relies on.
If there's a particular feature that I've mentioned in the past and forgotten, feel free to remind me about it--I don't want to put anything in that will be difficult to debug, but minor changes probably wouldn't be a problem.
<!--QuoteBegin--amckern+Nov 10 2003, 04:33 PM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (amckern @ Nov 10 2003, 04:33 PM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> so is the p12 the rad build that replaces the "blue" light rad code?
amckern <!--QuoteEnd--> </td></tr></table><span class='postcolor'> <!--QuoteEEnd--> I'm not sure what you mean by blue light, but there was a known bug in p11 RAD that p12 fixed. Light attenuation with distance wasn't calculated correctly by p11 for some combinations of light settings, causing rooms to be lit far too brightly.
<!--QuoteBegin--Orgazmo+Nov 15 2003, 11:14 AM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (Orgazmo @ Nov 15 2003, 11:14 AM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->Can you post a link to the source? I want to run your version on linux.
Plz dont take this post ats an insult or somthing I am not sure about the licence of ZHLT but I would like to compile native linux binaries<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd--> IIRC Merl dropped linux support in ZHLT a while back -- CSG in particular probes the windows registry for the half-life install directory in wadcfg.cpp, and I'm not sure what the status of the linux build is for the equivalent functionality.
ZHLT is open source, but I haven't posted a public download for the p series source since it's ~800K and I'd rather not see my bandwidth destroyed by curious people who aren't going to actually compile the tools.
I'll get a source distribution of my current working build set up late tonight -- if you PM me an email address and I'll send you the link. Ditto for anybody else who'd like a copy of the source.
If you'd like to test Merl's public source for compatability in the meantime, the build I started with is available <a href='http://collective.valve-erc.com/index.php?go=mhlt' target='_blank'>here</a>.
Just out of curiosity how easy would it be to implement face-based versions of the max light and direct light parameters for hlrad? I have yet to play with direct light, and don't truly understand the difference there, but I can easily see it for max light. Would it be possible to specify a texture list that is used to apply max light only to select faces? This would be a fairly crude method of solving the fullbright texture problem at compile time. Although it would add some bulk to hlrad I don't know if it would really mess things up to go back after the light values are applied, parse a texture list, and adjust the light values of those faces accordingly. Granted this assumption is based of relatively limited programming experience, and next to no game programming experience, but I think it would be a useful feature. I Also wonder if it would look correct to simply re-apply the light value of the texture as specified in the .rad file. As in would lights appear to have the appropriate level of brightness for their surroundings.
I guess there might be more to this than it seems to me. If there is, and you have the time, I wouldn't mind a link to some information explaining why for my own edification, if nothing more. If not I think this would be a valuable addition, especially since it would reduce the need for overlays.
<!--QuoteBegin--Reese+Nov 18 2003, 12:33 AM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (Reese @ Nov 18 2003, 12:33 AM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> Just out of curiosity how easy would it be to implement face-based versions of the max light and direct light parameters for hlrad? I have yet to play with direct light, and don't truly understand the difference there, but I can easily see it for max light. Would it be possible to specify a texture list that is used to apply max light only to select faces? This would be a fairly crude method of solving the fullbright texture problem at compile time. Although it would add some bulk to hlrad I don't know if it would really mess things up to go back after the light values are applied, parse a texture list, and adjust the light values of those faces accordingly. Granted this assumption is based of relatively limited programming experience, and next to no game programming experience, but I think it would be a useful feature. I Also wonder if it would look correct to simply re-apply the light value of the texture as specified in the .rad file. As in would lights appear to have the appropriate level of brightness for their surroundings.
I guess there might be more to this than it seems to me. If there is, and you have the time, I wouldn't mind a link to some information explaining why for my own edification, if nothing more. If not I think this would be a valuable addition, especially since it would reduce the need for overlays. <!--QuoteEnd--> </td></tr></table><span class='postcolor'> <!--QuoteEEnd--> I think it probably could be hacked into ZHLT without any major issues--direct light values are something you'd want to adjust after the first (direct) lighting pass and before bounce calculation since it's a scaling process across all of the light patches, but the max light value could be applied in a post lighting step.
You might end up with awkward looking patches if your max value is significantly lower than the surrounding area; this would be especially true if light bouncing from the adjusted patch was the primary light in the room--it would no longer have an apparent source. I think that solving the problem from the opposite direction and specifying a minimum light value for underlit patches would provide a more natural looking result.
I don't plan on implementing this in ZHLT--it isn't conceptually difficult to do, but the current .rad format doesn't supply the necessary information, leaving a choice between modifying .rad files or creating yet another file type, and at the moment I'd rather not do either. If there is a popular demand for immediate post-radiosity fine tuning of patch values I might change my tune, but for the moment my main goal with ZHLT is stability. As I mentioned above, the source is available--PM me if you'd like a copy.
I'm going to be implementing XML property files that among other things will allow users to specify features like minimum and maximum light values on a per-texture basis in the new tools, so there will be a natural place for this functionality to be specified by the user. Post-radiosity light value filters (adjusting hue, brightness, saturation, or gamma, performing blurs, mapping to a new color space) are also part of the new tool design.
The new tools will be out "when they're done", but I'm getting close to an internal test build for CSG & BSP replacements, so it shouldn't be too much longer a wait.
heh, I guess i'll wait then for the better way to accomplish things to make it's way here. <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->
Thx for the email I have gotten your version to compile, I do have some problems left but will resolve those and post a patch to your source next week.
my main problems are: 1) your Faster Math code in hlrad does not want to link cleanly for some reason 2) need to make some windows specific things windows specific again 3) need to verify windows compatibility
Maybe we could set up a subsersion or CVS server to let people access the source
<!--QuoteBegin--Reve+Nov 28 2003, 07:19 AM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (Reve @ Nov 28 2003, 07:19 AM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> Cagey, am I right in thinking that these tools are built with .NET compile tools?
Any change of them working for Linux using <a href='http://www.go-mono.com/' target='_blank'>Mono</a>?
Reve <!--QuoteEnd--> </td></tr></table><span class='postcolor'> <!--QuoteEEnd--> Mono is duplicating .Net-specific technologies (C#, ASP.Net) and the tools are actually written in C++. I build the tools using .Net, but they have traditionally been built using Intel's C++ compiler, which is what Merl uses.
I'm not sure what the problem with the FASTMATH code is at this point, but the majority of the initial problem was C++ Win32 API calls being made directly in the code instead of being #defined with a Linux alternative. Thanks for the link, but in this case Mono isn't necessary to get the Linux version running again. <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->
Ok i got the faster math code to work. I have a copy of them build
I am not a good mapper and need somekind of benchmark map to debug it further
also to make the fastmath code work i had to comment out the inline statements will try to resolve this [edit]not to easy: <a href='http://www.gnu.org/software/gcc/c99status.html' target='_blank'>http://www.gnu.org/software/gcc/c99status.html</a> seems compiler thing[/edit] and to move windows specific behavior to #ifdef SYSTEM_WIN32 and cook up some linux alternative
P.S. all maps send to help improve the tools will be treated with respect and confidentiality
Comments
Just in case either are useful. :-)
I think the article by Bruce Naylor et. al. from the SIGGRAPH '90 Proceedings (first link mentions it, thanks for passing it along) might be what I need... I'm contemplating membership in ACM or SIGGRAPH to access the article.
EDIT : found the basic algorithm from that paper on my bookshelf -- guess I didn't look throughly enough the first time <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->. I'm also suscribing to <a href='http://lists.sourceforge.net/lists/listinfo/gdalgorithms-list' target='_blank'>GDAlgorithms-list</a> on SourceForge.
Thanks to both Kage and WolfWings for reporting problems with p11 and testing the p12 release cantidates.
EDIT: Well, at least it says it is version p12, that's enough for me <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->
I was tinkering with Extreme Mapping (open up this file, you'll see, 19 entities for one door, albeit a VERY nice door with pretty lighting, which I honestly think could be done in 5 entities with proper support) and have suddenly started running into an interesting problem.
If I set <span style='color:yellow'>zhlt_noclip 1</span> on brush-based entities, suddenly these uber-huge clipping boxes 'spring up' in-game apparently. I thought zhlt_noclip was supposed to remove all clipping information from a brush-based entity?
So, um... is this a bug in your tools, Cagey? It's not Natural-Selection specific, as loading all the textures into the BSP and running it under Valve and TFC both exhibits identical behavior.
And yes, anyone is free to pull this apart, but right now until Cagey tells me what I did wrong, it's not very useful to most folks. :-)
I was tinkering with Extreme Mapping (open up this file, you'll see, 19 entities for one door, albeit a VERY nice door with pretty lighting, which I honestly think could be done in 5 entities with proper support) and have suddenly started running into an interesting problem.
If I set <span style='color:yellow'>zhlt_noclip 1</span> on brush-based entities, suddenly these uber-huge clipping boxes 'spring up' in-game apparently. I thought zhlt_noclip was supposed to remove all clipping information from a brush-based entity?
So, um... is this a bug in your tools, Cagey? It's not Natural-Selection specific, as loading all the textures into the BSP and running it under Valve and TFC both exhibits identical behavior.
And yes, anyone is free to pull this apart, but right now until Cagey tells me what I did wrong, it's not very useful to most folks. :-) <!--QuoteEnd--> </td></tr></table><span class='postcolor'> <!--QuoteEEnd-->
Sounds like it's a bug, possibly in the hull index used for the noclip items' clip hulls. Added to my to-do list.
Okay... knowing what to look for, I used some BSP Tools I have to pull apart the BSP partially, and looked through the hull-indexes.
The zhlt_noclip entities got assigned the same headnode for hulls 1-3 as hull 1 of the first non-zhlt_noclip entity <b>after</b> them, curiously enough.
This apparently wouldn't be an issue for non-moving entities, and may be how zhlt_noclip works by design, but if so it wasn't mentioned anywhere that I know of.
Basically, it's one of the doors from NS2.wad, horizontal, splits in half, with irregular windows in both halves which are properly 'windows' in-game as well. The button controlling it is a rather complicated piece of work that emits light that's adjusted to match the texture when you open and close the door.
Current, the button (placed on both sides of the door with one entity) and the lighting around it are redish when the door is closed, and greenish when the door is open. The actual 'button' on the button entity depresses momentarilly when used, and the door itself auto-disables whenever someone is standing in the doorway. So no, no crushing oni in this door. :-)
The door itself actually 'cheats' by using a func_wall_toggle as the actual door, the door panels are flagged as non-solid, and there are proper 'carvings' into the doorframe for the door panels to slide into.
Yes, this was an experiment in maximum immersion, but NOT at the cost of r_speeds, which are a svelt 50ish for the door if you re-use it in your own level.
Sadly, due to the limitations of the entities in Half-Life, it <b>was</b> rather costly in entity-count. The entire contraption comes in at 19 entities, though over half of them are point entities or part of a pair of 'switched entities' to give full control over the texture-lighting and texturing of the button itself.
Specifically:
6 func_door (4 for the central door itself, 2 more for the 'depressed button' in the visual button)
5 func_wall_toggle (1 for the actual door, 2 for the 'redish' texturing and glow on the button, 2 for the 'greenish' texturing and glow on the button)
2 'targetted' light (1 for the redish lighting, 1 for the greenish lighting)
1 trigger_presence (to make the door 'crushproof')
2 env_global (1 to 'enable' the button, 1 to 'disable' the button, crushproofing and re-use-delaying)
1 multisource (provides the linkage between the env_globals and the actual button to enable/disable it)
1 multi_manager (to trigger the texturing and lighting changes, along with disabling the button for 1 second each time it's used)
Of those, what could be reduced?
The 6 func_doors couldn't be reduced any further, though 2 could be deleted if you made the 'button' non-moving.
The 5 func_walls could be reduced to 3 in-game if HLRad supported deleting an entity after it provided switchable texlight, a 'throw this out after it provides it's share of light' flag.
The 2 lights are something we're stuck with, unless Flayra hijacks the code from Spirit of Half-Life, which he probably should. :-)
The 1 trigger_presence couldn't be removed unless it could be 'merged' with the func_wall that provides the actual 'solid' door.
A similair situation exists for the 2 env_globals, the multisource, and the multi_manager. If NS supported actual scripting, akin to Hexen, where you could specify a set of commands to process in order, most of these entities could be removed. Perhaps a scripting language similair to this Pseudo-C:
<!--c1--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>CODE</b> </td></tr><tr><td id='CODE'><!--ec1-->
void Door1ButtonPressed(ent this) {
if (presence("Door1Wall")) {
PlaySound(this, this.LockedSound);
return;
}
if (GlobalFlag("Door1Button") == DISABLED) {
return;
}
PlaySound(this, this.UnlockedSound);
SetGlobalFlag("Door1Button", DISABLED);
TriggerTarget("Door1LightsRed");
TriggerTarget("Door1LightsGreen");
TriggerTarget("Door1Wall");
Sleep(3);
SetGlobalFlag("Door1Button", ENABLED);
}
<!--c2--></td></tr></table><span class='postcolor'><!--ec2-->
Ah... that we could have scripting in our maps again. Especially with this viscious 200-entity limit on maps now, things like this would be a godsend.
I actually reused Zoner's code for func_illusionary clip hull replacement -- what I need to do is define a minimally defined single hull with no solid areas, and use that single extra hull for all the cases of zhlt_noclip and all of the entities that Zoner had already set to noclip. I have a pretty full to-do list at the moment (I've actually kept some people waiting), but I'll work this out when I have a chance.
I've been trying to nut this out on paper for a while now, and if I get anything that produces the same results with fewer entities I'll post it, but for now I'd imagine you could save your self the func_wall_toggle, multisource and 2 env_global by a little bit of tricky brush work.
I don't know how it works in Radient, but if it works along the same lines of "create brushes, convert them to entities", then this should work.
Ok, firstly the bottom door. The door itself is fine, but instead of cutting the glass to exact shape of the hole, give it atleast 1 or 2 units overlap into the door itself, this is so you wont see any gaps if the glass and door misaligns momentarily.
Now create a separate, thin, brush (part of the glass entity however), and place it 1 unit under the lip of the door. The effect is that if the door collides with a player, then glass is only 1 unit behind the door and will hit the player almost as soon as the door does. This should stop the strange effect where the player blocks the door and the glass moves on for a couple of dozen units before finally hitting something. Repeat the whole lot for the top door.
Now that it wont look weird, you can safely tell the door to do little damage, and so the door will attempt to close, hit a player and slowly start squeezing the player to death (well sometimes... I have accidentally created func_doors that simply keep crushing until the player doors, but when others have tried to recreate that effect have found that their doors simply return to the open position normally).
I was able to get rid of one of the func_wall_toggles, and convert another to a simple func_wall.
Second, your method would indeed allow the lights to get out of sync with the rest of the door-system, which is why I'm not using that method.
Third, as I said before, the overall server load from this system is relatively trivial, but unfortunately it NUMERICALLY uses many entities. In all honesty, this is a very low server-load construction, but NS doesn't make distinctions between 'light' and 'heavy' entities, such as the 'glue' entities I'm using, compared to complicated entities that other constructions use, or complicated solid geometry which makes the server work harder to handle intersection calculations.
iam mapping for cstrike and i have the max_map_planes error when i compile my map <!--emo&:(--><img src='http://www.unknownworlds.com/forums/html/emoticons/sad.gif' border='0' style='vertical-align:middle' alt='sad.gif'><!--endemo-->
i have search with google to fix this problem without reducing brushes, so i found this topic <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->
i have download the zklt-max_map_planes_fix.zip and used this compilers in hlcc
i have copied the msvcp70.dll and the msvcr70.dll in my windows/system folder (win98)
when i start hlcc and press "compile" to compile my map i get this error:
<a href='http://c.scharhag.bei.t-online.de/error.gif' target='_blank'>http://c.scharhag.bei.t-online.de/error.gif</a>
(sry, for german )
need help..
sorry for bad english *g
Simply redownload MSVCP70.dll and the problem should be gone.
Reve
Reve <!--QuoteEnd--> </td></tr></table><span class='postcolor'> <!--QuoteEEnd-->
p13 -
Bugfix for zhlt_noclip - create 1 empty clip hull and share it for all noclip brush entities' 3 clip hulls instead of using the clip hulls of the next entity
I'm looking for the source of some holes that people are reporting in worldspawn clipping after BSP is finished -- the problem appears after CSG exports the face list to file and before the final output of BSP is written out; no garuntees that p13 will be the build where I catch it, though, since it's difficult to duplicate and it's not specific to any code that I've added.
Aside from those known bugs, I'm not working on anything new at the moment for the "p" series; I'm trying to make the release builds of ZHLT as stable as possible at the moment while I work on the alternative tools. Most of the innovations I've come up with in the last few months are being targeted for the HLCSG & HLBSP replacements I'm currently writing since they'd require overhauls to the static data structures that the ZHLT series relies on.
If there's a particular feature that I've mentioned in the past and forgotten, feel free to remind me about it--I don't want to put anything in that will be difficult to debug, but minor changes probably wouldn't be a problem.
amckern
amckern <!--QuoteEnd--> </td></tr></table><span class='postcolor'> <!--QuoteEEnd-->
I'm not sure what you mean by blue light, but there was a known bug in p11 RAD that p12 fixed. Light attenuation with distance wasn't calculated correctly by p11 for some combinations of light settings, causing rooms to be lit far too brightly.
tks man
amckerm
Plz dont take this post ats an insult or somthing I am not sure about the licence of ZHLT but I would like to compile native linux binaries
Plz dont take this post ats an insult or somthing I am not sure about the licence of ZHLT but I would like to compile native linux binaries<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
IIRC Merl dropped linux support in ZHLT a while back -- CSG in particular probes the windows registry for the half-life install directory in wadcfg.cpp, and I'm not sure what the status of the linux build is for the equivalent functionality.
ZHLT is open source, but I haven't posted a public download for the p series source since it's ~800K and I'd rather not see my bandwidth destroyed by curious people who aren't going to actually compile the tools.
I'll get a source distribution of my current working build set up late tonight -- if you PM me an email address and I'll send you the link. Ditto for anybody else who'd like a copy of the source.
If you'd like to test Merl's public source for compatability in the meantime, the build I started with is available <a href='http://collective.valve-erc.com/index.php?go=mhlt' target='_blank'>here</a>.
I guess there might be more to this than it seems to me. If there is, and you have the time, I wouldn't mind a link to some information explaining why for my own edification, if nothing more. If not I think this would be a valuable addition, especially since it would reduce the need for overlays.
I guess there might be more to this than it seems to me. If there is, and you have the time, I wouldn't mind a link to some information explaining why for my own edification, if nothing more. If not I think this would be a valuable addition, especially since it would reduce the need for overlays. <!--QuoteEnd--> </td></tr></table><span class='postcolor'> <!--QuoteEEnd-->
I think it probably could be hacked into ZHLT without any major issues--direct light values are something you'd want to adjust after the first (direct) lighting pass and before bounce calculation since it's a scaling process across all of the light patches, but the max light value could be applied in a post lighting step.
You might end up with awkward looking patches if your max value is significantly lower than the surrounding area; this would be especially true if light bouncing from the adjusted patch was the primary light in the room--it would no longer have an apparent source. I think that solving the problem from the opposite direction and specifying a minimum light value for underlit patches would provide a more natural looking result.
I don't plan on implementing this in ZHLT--it isn't conceptually difficult to do, but the current .rad format doesn't supply the necessary information, leaving a choice between modifying .rad files or creating yet another file type, and at the moment I'd rather not do either. If there is a popular demand for immediate post-radiosity fine tuning of patch values I might change my tune, but for the moment my main goal with ZHLT is stability. As I mentioned above, the source is available--PM me if you'd like a copy.
I'm going to be implementing XML property files that among other things will allow users to specify features like minimum and maximum light values on a per-texture basis in the new tools, so there will be a natural place for this functionality to be specified by the user. Post-radiosity light value filters (adjusting hue, brightness, saturation, or gamma, performing blurs, mapping to a new color space) are also part of the new tool design.
The new tools will be out "when they're done", but I'm getting close to an internal test build for CSG & BSP replacements, so it shouldn't be too much longer a wait.
my main problems are:
1) your Faster Math code in hlrad does not want to link cleanly for some reason
2) need to make some windows specific things windows specific again
3) need to verify windows compatibility
Maybe we could set up a subsersion or CVS server to let people access the source
Any change of them working for Linux using <a href='http://www.go-mono.com/' target='_blank'>Mono</a>?
Reve
Any change of them working for Linux using <a href='http://www.go-mono.com/' target='_blank'>Mono</a>?
Reve <!--QuoteEnd--> </td></tr></table><span class='postcolor'> <!--QuoteEEnd-->
Mono is duplicating .Net-specific technologies (C#, ASP.Net) and the tools are actually written in C++. I build the tools using .Net, but they have traditionally been built using Intel's C++ compiler, which is what Merl uses.
I'm not sure what the problem with the FASTMATH code is at this point, but the majority of the initial problem was C++ Win32 API calls being made directly in the code instead of being #defined with a Linux alternative. Thanks for the link, but in this case Mono isn't necessary to get the Linux version running again. <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->
I am not a good mapper and need somekind of benchmark map to debug it further
also to make the fastmath code work i had to comment out the inline statements
will try to resolve this
[edit]not to easy: <a href='http://www.gnu.org/software/gcc/c99status.html' target='_blank'>http://www.gnu.org/software/gcc/c99status.html</a> seems compiler thing[/edit]
and to move windows specific behavior to #ifdef SYSTEM_WIN32
and cook up some linux alternative
P.S. all maps send to help improve the tools will be treated with respect and confidentiality