Well I have to say a big thankyou to Cagey for reducing my clipnodes. I hit the limit with the old tools last night and was able to get around it using the precise option. 1 problem occured however. I know get a big invisible wall right in the middle of one of my paths. Is there any way I can fix this without using a different compile option?
<!--QuoteBegin--Heist+Feb 25 2003, 06:10 AM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (Heist @ Feb 25 2003, 06:10 AM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> Well I have to say a big thankyou to Cagey for reducing my clipnodes. I hit the limit with the old tools last night and was able to get around it using the precise option. 1 problem occured however. I know get a big invisible wall right in the middle of one of my paths. Is there any way I can fix this without using a different compile option? <!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd--> If you're getting a new invisible wall using precise clipping, here's how to diagnose and correct the problem:
1) Try drawing a regular brush that is 32x32x36 (or 32x32x72 / 64x64x104 for standing marine / Onos problems) and placing it inside the hallway. If it doesn't fit without touching an edge, the path is too small using the new options. The denormalization of angled brush faces (see bugfix #2 in doc) pushes them outward from the vis hull until the extra edges that can form between brushes disappear, shrinking paths slightly and possibly cutting off narrow or low ones. To confirm that this is the problem, try compiling with the "-cliptype smallest" option, which turns off the extra beveling--if the wall is still there, you'll need to widen or heighten the passage a little to use precise... The old spec was about 32-33 units wide at any angle... Under the new code the minimum width is still 32 units for axial walls, up to ~45 units (32 units along each axis) for walls at a 45 degree angle.
EDIT: 45! 45 degrees, not 90! (/me slaps his forehead and gets more caffiene)
2) If the wall disappears using smallest, then the problem is likely due to an illegal brush shape if you're using VHE. To double check this, you can use Alt-P to list problems in the map--you'll need to fix any reports of invalid brushes to use precise, which is more sensitive to actual brush shapes than the old code. If VHE doesn't report any invalid brushes and you're still having a new invisible wall appear, you should probably take Wolv's advice and try using Quark to double-check the map since it has stricter checking of brush geometry.
If neither of the solutions above works, PM me and I'll work on the problem with you.
Well, since Monse, for whos exlcusive use I created those medals first, istn't that active anymore, I think I'll do it:
<i>I hereby give you, XP-Cagey, the <b>Gorge of the Week Award</b> for your merits in creating and further developing new tools that enhance and improve the overall gaming experience and help all HL-Mappers worldwide.
I have a potential bug to report, or at least bring it to everyone's attention so that others might be able to confirm it as a repeatable issue.
In a test map, I have one func_door which is behaving very strangely since I began using the new HLCSG. If I compile with no switches specified, the door opens (it's triggered by a trigger_multiple), but the 'opening' remains impassable, as if the door were still in the way. The door has a convex face, and I can tell that the 'obstruction' is the same shape as the door that was formerly there by moving against it. I even tried jumping, crouching, and crouch-jumping, and I can actually manage to get myself stuck in the air in front of the doorway. I am currently re-compiling with the old version of CSG to see what happens, but no changes have been made to the door during this whole problem.
**update: After recompiling using the old copy of HLCSG, everything works fine again. This tells me the problem lies somewhere within the way that the new HLCSG does things, but as I'm no programmer, I couldn't say what the specific problem could be.
Wait wait wait... Valve told me that the sticky corners was an engine problem inherited from the Quake 1 code and couldn't be fixed? Are you telling us it was just a compiling problem all along?
<!--QuoteBegin--BlackPanther+Feb 27 2003, 09:02 AM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (BlackPanther @ Feb 27 2003, 09:02 AM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> Wait wait wait... Valve told me that the sticky corners was an engine problem inherited from the Quake 1 code and couldn't be fixed? Are you telling us it was just a compiling problem all along? <!--QuoteEnd--> </td></tr></table><span class='postcolor'> <!--QuoteEEnd--> Yep.
Don't know who at Valve thought it was the engine... simple hand calculation of the geometry created by the old CSG showed what the compiler was doing to create the problems. Perhaps they felt that the normalization (cause of bug #2) was absolutely required and they didn't want to investigate removing it.
I've asked Relic for a map to reproduce the door bug -- once I have it in hand, I'll start the debug process.
Well Cagey, I think you should contact Valve-ERC and try to get them to post your tools. Maybe get yourself a website for all this stuff? So it could be an easy browsing libary - then theres no need for sticky threads. Good job.
<!--QuoteBegin--Revenant+Feb 27 2003, 11:44 AM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (Revenant @ Feb 27 2003, 11:44 AM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->Well Cagey, I think you should contact Valve-ERC and try to get them to post your tools. Maybe get yourself a website for all this stuff? So it could be an easy browsing libary - then theres no need for sticky threads. Good job.<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd--> Thanks Rev <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->
For improvements like the clipping fix, I've submitted source code to Merl for inclusion into his custom builds of Zoner's tools--that way there isn't any competition between two different sets of tools and the community gets the benefit of everybody's contributions to the code. Once the improvements I talk about in these threads are part of public releases of Merl's builds, I plan on pulling the local files and linking to his stuff instead.
I'm probably going to start a library for tools that aren't part of the main compile branch, like opt_plns (which may be put into HLRAD, but could also be kept separate if you want to do some point ent tweaking after final lighting). I usually have 3-4 projects on my to-do list, and I'm sure more of them will require permanent storage as well. I have a web host that is willing to post small (~ 50K) files for download, but doesn't want to run a large file sharing service. I was thinking about using FilePlanet to mirror non-standard tools, but I think I'll take your suggestion and see if ERC would be willing to add the project to Dev Dev. I'm debating with myself over using a service like sourceforge for code storage.
My professional background is actually in web based applications, so I ought to have a slightly more impressive <a href='http://xp-cagey.com' target='_blank'>home page</a> in the future <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->. I have a completed graphic design, and just need to get some of the automated services (news script and the like) finalized--I'm balancing that with working on my NS map and the tool projects, so it could be a while. I'm also keeping an eye on Invision Power Services (authors of this message board system) to see when they add SQL2000 support so I can formally track feature requests and bug reports.
Ive Downloaded and installed the CSG, I got a couple of errors about missing dlls but I gotten those from a pal of mine. Now it starts the CSG but then I get this: -------------------- 151 brushes (totalling 899 sides) discarded from clipping hulls CreateBrush: Warning: Recursive ThreadLock
Warning: Recursive ThreadLock
Warning: Recursive ThreadLock
Warning: Recursive ThreadLock
Warning: Recursive ThreadLock
And that goes on forever ----------------------
My pal suggested it might have something to do with the progarmming language you used. I run W2000 btw
This is my second attempt at coming back to map one for NS so Id really appreciate any help you can offer me
<!--QuoteBegin--3D_Mike+Mar 13 2003, 07:45 AM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (3D_Mike @ Mar 13 2003, 07:45 AM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> Warning: Recursive ThreadLock <!--QuoteEnd--> </td></tr></table><span class='postcolor'> <!--QuoteEEnd--> I've posted an update at the start of the thread that should fix the threadlock error -- it was happening because you were using more than one thread (multiprocessor machine?) and one thread was reusing the lock without releasing it so the other thread(s) weren't able to process properly. Thanks for pointing this out 3D_Mike <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->
I've also made the code more adaptable to concave brush shapes by changing the method used to detect offset direction (thanks to Gollum for the sample case), and added -cliptype normalized for people who want to use the beveling fix without having narrower hallways--it won't fix all clip errors, but will still be an improvement over the legacy code.
Ollj, I'm looking over your problem now--thanks for the file.
omg Cagey is my new personal god! <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->
<!--QuoteBegin--3D_Mike+Mar 13 2003, 08:44 AM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (3D_Mike @ Mar 13 2003, 08:44 AM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> Error: Portal file 'C:\compile\test.prt' does not exist, cannot vis the map
woops! <!--QuoteEnd--> </td></tr></table><span class='postcolor'> <!--QuoteEEnd--> double check that hlbsp ran--if it died without output or didn't run at all, hlvis will toss this error
I checked it. BSP crashed. Compiling works with the old CSG file though so it must be in the CSG. <!--QuoteEnd--> </td></tr></table><span class='postcolor'> <!--QuoteEEnd--> Found the problem -- CSG was creating a map with about 35K planes, which was crashing an older version of BSP (Merl's 1.6.1). 3D_Mike's now trying the other 1.7p4 tools which support 64K planes with the <a href='http://www.unknownworlds.com/forums/index.php?act=ST&f=4&t=21248&st=0' target='_blank'>optimizer</a>.
Out of interest, I also had to download two dll files to get this to work.
<b>msvcp70.dll</b> and <b>msvcr70.dll</b>
being a win98 user ... I guess <!--emo&???--><img src='http://www.unknownworlds.com/forums/html/emoticons/confused.gif' border='0' style='vertical-align:middle' alt='confused.gif'><!--endemo-->
Out of interest, I also had to download two dll files to get this to work.
<b>msvcp70.dll</b> and <b>msvcr70.dll</b>
being a win98 user ... I guess <!--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--> Those files are required because I compiled with MSVC++ 7.0 using its shared CRT module: <a href='http://support.microsoft.com/default.aspx?scid=kb;en-us;326922' target='_blank'>Microsoft Knowledge Base Article on msvcr70.dll</a>
I know it's a pain, and I apologize for the inconvience--I linked to both dlls in the first post of this thread the other day.
Be sure to sent Merl this stuff, its the best thing since the Null texture <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->
actually i told 3DMike about this planes project from Cagey, so that 3DMike and Mawibse could use if on a complex DoD airfield battle map they were working on, DoD_Stuka. they were having some clipnode problems.
AFAIK, 3DMike has not yet converted to NSism, he is still a DoDist now. but he has converted before from CS to DoD, so there is hope he will go NS one day!
<i>on the other hand his beautiful maps hit limits pretty hard, dunno how an NS map by him would play.....</i> <!--emo&:D--><img src='http://www.unknownworlds.com/forums/html/emoticons/biggrin.gif' border='0' style='vertical-align:middle' alt='biggrin.gif'><!--endemo-->
Course it would. Me maps might look heavy but look closer and youll find that none of m exceed the 600 wpoly or 1000 extra epoly limits <!--emo&;)--><img src='http://www.unknownworlds.com/forums/html/emoticons/wink.gif' border='0' style='vertical-align:middle' alt='wink.gif'><!--endemo-->
~We are sparse on sounds and texture MBs too, dod_stuka has the lowest lag-specs youve ever seen on a dod map. Honest
Comments
If you're getting a new invisible wall using precise clipping, here's how to diagnose and correct the problem:
1) Try drawing a regular brush that is 32x32x36 (or 32x32x72 / 64x64x104 for standing marine / Onos problems) and placing it inside the hallway. If it doesn't fit without touching an edge, the path is too small using the new options. The denormalization of angled brush faces (see bugfix #2 in doc) pushes them outward from the vis hull until the extra edges that can form between brushes disappear, shrinking paths slightly and possibly cutting off narrow or low ones. To confirm that this is the problem, try compiling with the "-cliptype smallest" option, which turns off the extra beveling--if the wall is still there, you'll need to widen or heighten the passage a little to use precise... The old spec was about 32-33 units wide at any angle... Under the new code the minimum width is still 32 units for axial walls, up to ~45 units (32 units along each axis) for walls at a 45 degree angle.
EDIT: 45! 45 degrees, not 90! (/me slaps his forehead and gets more caffiene)
2) If the wall disappears using smallest, then the problem is likely due to an illegal brush shape if you're using VHE. To double check this, you can use Alt-P to list problems in the map--you'll need to fix any reports of invalid brushes to use precise, which is more sensitive to actual brush shapes than the old code. If VHE doesn't report any invalid brushes and you're still having a new invisible wall appear, you should probably take Wolv's advice and try using Quark to double-check the map since it has stricter checking of brush geometry.
If neither of the solutions above works, PM me and I'll work on the problem with you.
<i>I hereby give you, XP-Cagey, the <b>Gorge of the Week Award</b> for your merits in creating and further developing new tools that enhance and improve the overall gaming experience and help all HL-Mappers worldwide.
Congratulations!</i>
<img src='http://www.joshbeeler.com/ramses/images/misc/gorgeoftheweek.gif' border='0' alt='user posted image'>
In a test map, I have one func_door which is behaving very strangely since I began using the new HLCSG. If I compile with no switches specified, the door opens (it's triggered by a trigger_multiple), but the 'opening' remains impassable, as if the door were still in the way. The door has a convex face, and I can tell that the 'obstruction' is the same shape as the door that was formerly there by moving against it. I even tried jumping, crouching, and crouch-jumping, and I can actually manage to get myself stuck in the air in front of the doorway. I am currently re-compiling with the old version of CSG to see what happens, but no changes have been made to the door during this whole problem.
**update: After recompiling using the old copy of HLCSG, everything works fine again. This tells me the problem lies somewhere within the way that the new HLCSG does things, but as I'm no programmer, I couldn't say what the specific problem could be.
Are you telling us it was just a compiling problem all along?
Are you telling us it was just a compiling problem all along? <!--QuoteEnd--> </td></tr></table><span class='postcolor'> <!--QuoteEEnd-->
Yep.
Don't know who at Valve thought it was the engine... simple hand calculation of the geometry created by the old CSG showed what the compiler was doing to create the problems. Perhaps they felt that the normalization (cause of bug #2) was absolutely required and they didn't want to investigate removing it.
I've asked Relic for a map to reproduce the door bug -- once I have it in hand, I'll start the debug process.
Thanks Rev <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->
For improvements like the clipping fix, I've submitted source code to Merl for inclusion into his custom builds of Zoner's tools--that way there isn't any competition between two different sets of tools and the community gets the benefit of everybody's contributions to the code. Once the improvements I talk about in these threads are part of public releases of Merl's builds, I plan on pulling the local files and linking to his stuff instead.
I'm probably going to start a library for tools that aren't part of the main compile branch, like opt_plns (which may be put into HLRAD, but could also be kept separate if you want to do some point ent tweaking after final lighting). I usually have 3-4 projects on my to-do list, and I'm sure more of them will require permanent storage as well. I have a web host that is willing to post small (~ 50K) files for download, but doesn't want to run a large file sharing service. I was thinking about using FilePlanet to mirror non-standard tools, but I think I'll take your suggestion and see if ERC would be willing to add the project to Dev Dev. I'm debating with myself over using a service like sourceforge for code storage.
My professional background is actually in web based applications, so I ought to have a slightly more impressive <a href='http://xp-cagey.com' target='_blank'>home page</a> in the future <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->. I have a completed graphic design, and just need to get some of the automated services (news script and the like) finalized--I'm balancing that with working on my NS map and the tool projects, so it could be a while. I'm also keeping an eye on Invision Power Services (authors of this message board system) to see when they add SQL2000 support so I can formally track feature requests and bug reports.
--------------------
151 brushes (totalling 899 sides) discarded from clipping hulls
CreateBrush:
Warning: Recursive ThreadLock
Warning: Recursive ThreadLock
Warning: Recursive ThreadLock
Warning: Recursive ThreadLock
Warning: Recursive ThreadLock
And that goes on forever
----------------------
My pal suggested it might have something to do with the progarmming language you used. I run W2000 btw
This is my second attempt at coming back to map one for NS so Id really appreciate any help you can offer me
check private message.
<!--QuoteEnd--> </td></tr></table><span class='postcolor'> <!--QuoteEEnd-->
I've posted an update at the start of the thread that should fix the threadlock error -- it was happening because you were using more than one thread (multiprocessor machine?) and one thread was reusing the lock without releasing it so the other thread(s) weren't able to process properly. Thanks for pointing this out 3D_Mike <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->
I've also made the code more adaptable to concave brush shapes by changing the method used to detect offset direction (thanks to Gollum for the sample case), and added -cliptype normalized for people who want to use the beveling fix without having narrower hallways--it won't fix all clip errors, but will still be an improvement over the legacy code.
Ollj, I'm looking over your problem now--thanks for the file.
woops!
woops! <!--QuoteEnd--> </td></tr></table><span class='postcolor'> <!--QuoteEEnd-->
double check that hlbsp ran--if it died without output or didn't run at all, hlvis will toss this error
If so, damn nice work..:E
I checked it. BSP crashed. Compiling works with the old CSG file though so it must be in the CSG.
I checked it. BSP crashed. Compiling works with the old CSG file though so it must be in the CSG. <!--QuoteEnd--> </td></tr></table><span class='postcolor'> <!--QuoteEEnd-->
Found the problem -- CSG was creating a map with about 35K planes, which was crashing an older version of BSP (Merl's 1.6.1). 3D_Mike's now trying the other 1.7p4 tools which support 64K planes with the <a href='http://www.unknownworlds.com/forums/index.php?act=ST&f=4&t=21248&st=0' target='_blank'>optimizer</a>.
Out of interest, I also had to download two dll files to get this to work.
<b>msvcp70.dll</b> and <b>msvcr70.dll</b>
being a win98 user ... I guess <!--emo&???--><img src='http://www.unknownworlds.com/forums/html/emoticons/confused.gif' border='0' style='vertical-align:middle' alt='confused.gif'><!--endemo-->
Out of interest, I also had to download two dll files to get this to work.
<b>msvcp70.dll</b> and <b>msvcr70.dll</b>
being a win98 user ... I guess <!--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-->
Those files are required because I compiled with MSVC++ 7.0 using its shared CRT module:
<a href='http://support.microsoft.com/default.aspx?scid=kb;en-us;326922' target='_blank'>Microsoft Knowledge Base Article on msvcr70.dll</a>
I know it's a pain, and I apologize for the inconvience--I linked to both dlls in the first post of this thread the other day.
Dude I cant wait to see what you bring to NS!
AFAIK, 3DMike has not yet converted to NSism, he is still a DoDist now. but he has converted before from CS to DoD, so there is hope he will go NS one day!
<i>on the other hand his beautiful maps hit limits pretty hard, dunno how an NS map by him would play.....</i> <!--emo&:D--><img src='http://www.unknownworlds.com/forums/html/emoticons/biggrin.gif' border='0' style='vertical-align:middle' alt='biggrin.gif'><!--endemo-->
~We are sparse on sounds and texture MBs too, dod_stuka has the lowest lag-specs youve ever seen on a dod map. Honest