<!--QuoteBegin--Orgazmo+Nov 29 2003, 08:35 AM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (Orgazmo @ Nov 29 2003, 08:35 AM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> P.S. all maps send to help improve the tools will be treated with respect and confidentiality <!--QuoteEnd--> </td></tr></table><span class='postcolor'> <!--QuoteEEnd--> For an easy starter map, check out the NS World sample map here: <a href='http://nsworld.ns-central.co.uk/mappingguide/appendix7.htm' target='_blank'>http://nsworld.ns-central.co.uk/mappinggui...e/appendix7.htm</a>. The map file link is up near the top of the page.
Cagey, this isn't really related to the tools, but the formatting of the front page. I've noticed on a few occasions that people are forgetting to grab the extra .dll's when they get the compile tools. You mentioned in one such post that you'd make it "bright blinking neon" or something if you could.
<span style='color:yellow'>I suggest the colour yellow</span> as it seems to be the next best alternative. It seems to contrast very well on the dark background (discovered when I made the Nancy FAQ).
Anyway, keep up the good work! <!--emo&:D--><img src='http://www.unknownworlds.com/forums/html/emoticons/biggrin.gif' border='0' style='vertical-align:middle' alt='biggrin.gif'><!--endemo-->
<!--QuoteBegin--BigDXLT+Nov 30 2003, 12:48 AM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (BigDXLT @ Nov 30 2003, 12:48 AM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> <span style='color:yellow'>I suggest the colour yellow</span> as it seems to be the next best alternative. It seems to contrast very well on the dark background (discovered when I made the Nancy FAQ). <!--QuoteEnd--> </td></tr></table><span class='postcolor'> <!--QuoteEEnd--> Thanks for the advice -- made the change <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->
I am using p10 at the moment, as mixing p10 with p12 rad is not wise
ok, the issue
i am using larage amounts of null in my map (the map would be a good 30% null), when i complied it with p10 the null was not striped in 1 part of the map, and i had the aaatrigger flash light effect through out the map
i duno if u want more info on this if u do, pm me, or email amckern@yahoo.com
I am using p10 at the moment, as mixing p10 with p12 rad is not wise
ok, the issue
i am using larage amounts of null in my map (the map would be a good 30% null), when i complied it with p10 the null was not striped in 1 part of the map, and i had the aaatrigger flash light effect through out the map
i duno if u want more info on this if u do, pm me, or email amckern@yahoo.com
amckern <!--QuoteEnd--> </td></tr></table><span class='postcolor'> <!--QuoteEEnd--> If you reproduce it in p12 (using only p12 for all stages), I'll try to figure out what's going on... I'm only going to support the latest version of the tools, especially since I'm only fixing bugs between versions at this point.
I can't think of a reason why only some of the NULL textures in a level would be removed--there isn't any internal counter or looping process that would limit the quantity of faces being ignored on export.
pSyk0mAnNerdish by NatureGermanyJoin Date: 2003-08-07Member: 19166Members, NS2 Playtester, Squad Five Silver, NS2 Community Developer
Hi Cagey
Your modified tools are great. Big thanks !
But i'm wondering if you could higher the limit of "-maxnodesize #" in hlbsp without any extra coding !? The actual limit is 4096, 8192 would be nice, so that there aren't any extra cuts through the whole map. I am mapping terrain-maps with a special method and immense hint-brush usage Your modified hull-generation is great to eleminate most sticky corners...but the extra cuts and leaf-errors caused by the maxnodesize-cut(s) are annoying !
<!--QuoteBegin--p$yk0m@n+Dec 4 2003, 07:40 AM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (p$yk0m@n @ Dec 4 2003, 07:40 AM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> Hi Cagey
Your modified tools are great. Big thanks !
But i'm wondering if you could higher the limit of "-maxnodesize #" in hlbsp without any extra coding !? The actual limit is 4096, 8192 would be nice, so that there aren't any extra cuts through the whole map. I am mapping terrain-maps with a special method and immense hint-brush usage Your modified hull-generation is great to eleminate most sticky corners...but the extra cuts and leaf-errors caused by the maxnodesize-cut(s) are annoying ! <!--QuoteEnd--> </td></tr></table><span class='postcolor'> <!--QuoteEEnd--> I'll have to investigate if there are any side effects in the engine when this number is higher than 4096 before I release a code change -- I'll add it to my to-do list.
Is it possible to add an extra switch to rad such as -noscaledown which will make it only scale up the patches and never scale down <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->?
<!--QuoteBegin--[watch.me.die]+Dec 4 2003, 03:26 PM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> ([watch.me.die] @ Dec 4 2003, 03:26 PM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> Is it possible to add an extra switch to rad such as -noscaledown which will make it only scale up the patches and never scale down <!--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--> Pretty sure it's possible, but I'll be looking at it for the new tools rather than implementing it in ZHLT. It would be nice to have an adaptive patch scale routine that automatically scaled up the effective patch size if the lighting was constant or near-constant across the face, too.
Again Cagey I'm sure you here this all the time, your tools are fantastic (regular zoners stopped compiling my map ages ago). But I'm still hitting the max planes 65535. Is there any way too increase the max planes?
Take a look at this pic and you'll understand how max planes are being reached : <a href='http://www.keithfromneath.btinternet.co.uk/hammer.jpg' target='_blank'>de_gower hammer view</a> The map itself : <a href='http://www.keithfromneath.btinternet.co.uk/gower/de_gower12.jpg' target='_blank'>clicky for picky</a>
AFAIK the max planes is a half-life issues, not a compile tool one. There is a planes optimizer (should be on the first page of this thread) that may help you squeak past it. If not that then try and rearrange things so that more faces line up with each other (this is where the planes comes in) For instance putting two seperate areas of the map at the same z-height for a flat portion will make that section share a plane, saving you a little on it. It's too bad you're hitting that problem... looks like a cool map.
Ye I've been reducing planes by that method for as long as I can remember now. It's just stupidly difficult sometimes when you have triangles intersecting from different axis and what not. Ugh /gets back to killing planes
<!--QuoteBegin--zil+Dec 17 2003, 09:48 AM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (zil @ Dec 17 2003, 09:48 AM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->I've tried adding the two dlls (well ones a exe and ones a dll) into the folder of the tools but i still get a file no found error, any ideas?<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd--> Is it telling you the name of the file that's missing?
Both dlls should actually be dlls... msvcr70.dll and msvcp70.dll. One's the MS runtime for C support in .Net, the other is the MS runtime for C++ support in .Net including the MS version of the standard library.
<!--QuoteBegin--clay_9+Dec 16 2003, 04:28 PM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (clay_9 @ Dec 16 2003, 04:28 PM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->Again Cagey I'm sure you here this all the time, your tools are fantastic (regular zoners stopped compiling my map ages ago). But I'm still hitting the max planes 65535. Is there any way too increase the max planes?<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd--> Increasing max planes on a temporary basis before OPT_PLNS runs is possible, but requires a change in the way HLCSG exports data and the way HLBSP retrieves it. Planes are currently being stored in the BSP file between programs, and it's not possible for me to increase the limit without using a different storage system since the BSP format refers to planes using a 16 bit number.
I'm not going to raise the limit in ZHLT again since I'm working on debugging and stability issues only for p13, but the replacement tools (which are still a ways off) have no internal limit on the number of planes you use as long as the optimized number is under 32K to match the Half-Life engine's limit.
I see, well that all makes sense. So I'm pretty much screwed, I just need to manually conserve some more planes then. Thanks for the tools anyway, gower wouldn't be as sexy as it is right now if it wasn't for them.
<!--QuoteBegin--XP-Cagey+Dec 17 2003, 05:05 PM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (XP-Cagey @ Dec 17 2003, 05:05 PM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> <!--QuoteBegin--zil+Dec 17 2003, 09:48 AM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (zil @ Dec 17 2003, 09:48 AM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->I've tried adding the two dlls (well ones a exe and ones a dll) into the folder of the tools but i still get a file no found error, any ideas?<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd--> Is it telling you the name of the file that's missing?
Both dlls should actually be dlls... msvcr70.dll and msvcp70.dll. One's the MS runtime for C support in .Net, the other is the MS runtime for C++ support in .Net including the MS version of the standard library. <!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd--> ah well theres the problem - one of ur d/l links actually points to a exe with the same name as one of the dlls needed. I just googled the dll and d/l it and got the tools working fine.
I just had an awesome idea: The texture lights could be improved if this was added: Pixel dependant light colour and strength. As it is right now with texture lights, the entire texture only gives off one colour (the one from the lights.rad file) But it would be cool if it could use the pixel colour of the texture as the light. It could be added in the rad file after the texture name like this: light_strip3 -pixel 2.5
If you don't want the texture to have this texture rgb light then you could just make the rad file the normal way. It would just use the texture RGB value as the light. The value after -pixel is the multiply value. When compiling it makes a grayscale value out of the RBG value and uses this as the light strength. Then the multiply value just raises this so i can adjust the brigtness/strengh
This could be making good lighted levels easier to make. As i said before it should not replace the old texture lights only add more options to the texture lights.
This has probably been asked before but well, can you increase the amount of light patches in the RAD to compile Xp-Cagey? Or in some way tweak RAD so less patches will be used?
<!--QuoteBegin--Andos+Dec 19 2003, 02:28 PM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (Andos @ Dec 19 2003, 02:28 PM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> I just had an awesome idea: The texture lights could be improved if this was added: Pixel dependant light colour and strength. As it is right now with texture lights, the entire texture only gives off one colour (the one from the lights.rad file) But it would be cool if it could use the pixel colour of the texture as the light. It could be added in the rad file after the texture name like this: light_strip3 -pixel 2.5
If you don't want the texture to have this texture rgb light then you could just make the rad file the normal way. It would just use the texture RGB value as the light. The value after -pixel is the multiply value. When compiling it makes a grayscale value out of the RBG value and uses this as the light strength. Then the multiply value just raises this so i can adjust the brigtness/strengh
This could be making good lighted levels easier to make. As i said before it should not replace the old texture lights only add more options to the texture lights. <!--QuoteEnd--> </td></tr></table><span class='postcolor'> <!--QuoteEEnd--> (sorry for double post) Andos, I do not think it is possible for the HL Engine. Not only programming the pixels and the colours to the pixels but trying to create all that different coloured lighting and so much lighting in one area would probably max out the engine and create a few compiling errors. It is a very nice idea, hopefully someone can adapt to it.
well, if not that, a specific color range of pixels would emit a certain color, eliminating the need for overlays in most circumstances.
let's pretend you want light_strip3 to emit a nice blue tone. (I don't remember what light_strip3 looks like, so I'm making it up)
you would put
light_strip3 10 10 200 500 -spc 10 10 200 10
the first part is like normal, and the -spc (specific color) gives a range of colors to emit that color light.
So, if there's a pixel that's "10 15 195" it would emit "10 10 200 500 " and same for "15 5 205" the last # in the sequence "-spc 10 10 200 10" tells rad that there can be a range of 10 color points to be off for that to emit the one color, which is 10 10 200 with 500 as the strength.
the other problem is that rad has no capability to examine textures to determine the colors in them. Both integrating that and performing the pixel-by-pixel analysis would be time consuming tasks that really may not be much worth the effect. It would be cool to see it done though.
If you make an empty room with only one lamp with a texture from your rad file (so it gives of light) you will notice when you compile it will say something like "50 direct lights" or around (dependant on the texture size) This makes me think that RAD actually just places alot of smaller brightness direct ligts just next to the texture surface. If this is truen then it would be no problem for RAD to open the wad and get the pixel colour of the texture. Worldcraft can open up wads insanely fast and since there are mostly not that many lights in your rad file there would be no issues here i think. Correct me if i'm wrong.
Btw did you guys see the rad light hack thread? It could do some trix with the lighting. If my idea doesn't work then this trick could maybe be used to work the same way? I don't know <!--emo&:p--><img src='http://www.unknownworlds.com/forums/html/emoticons/tounge.gif' border='0' style='vertical-align:middle' alt='tounge.gif'><!--endemo-->
Andos, it would mean a lot of coding. You would have to have light sizes of certain types to work with the ideas your proposing, you would also need to account for "left" "middle" "right" and so forth flags, its too complicated, it will make many errors and is just not worth bothering with for the HL Engine IMO.
Oh my god, Cagey. So many questions to answer. And all that before christmas. <!--emo&:D--><img src='http://www.unknownworlds.com/forums/html/emoticons/biggrin.gif' border='0' style='vertical-align:middle' alt='biggrin.gif'><!--endemo--> To help a bit: Defining pixels that emit light and ones that don't is not an option, because the light patches cover several pixels at once. Overlay textures are the very best you can do. If you don't want to waste entities you can still try point lights directly in front of the light source. Usually this looks quite cool. (Don't flame me before you tried, thx <!--emo&;)--><img src='http://www.unknownworlds.com/forums/html/emoticons/wink.gif' border='0' style='vertical-align:middle' alt='wink.gif'><!--endemo--> )
One last post before I head out of town until the 29th:
<!--QuoteBegin--Thursday-+Dec 20 2003, 04:03 PM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (Thursday- @ Dec 20 2003, 04:03 PM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->This has probably been asked before but well, can you increase the amount of light patches in the RAD to compile Xp-Cagey? Or in some way tweak RAD so less patches will be used?<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
Check out the -chop and -texchop options <a href='http://www.valve-erc.com/content/resources/zhlt/ZHLTReference.html' target='_blank'>here</a>. The number of patches will be inversely proportional to the patch area specified. You can increase the number of samples taken without increasing the final number of patches using -extra.
<!--QuoteBegin--Andos+Dec 21 2003, 06:40 AM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (Andos @ Dec 21 2003, 06:40 AM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->This makes me think that RAD actually just places alot of smaller brightness direct ligts just next to the texture surface. <!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
That's correct -- the current code assigns one light per patch on the face of the texture that's emitting the light. Each light emits at up to 90 degrees from the surface of the texture.
<!--QuoteBegin--Fluffybunny+Dec 21 2003, 01:10 AM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (Fluffybunny @ Dec 21 2003, 01:10 AM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> well, if not that, a specific color range of pixels would emit a certain color, eliminating the need for overlays in most circumstances.
let's pretend you want light_strip3 to emit a nice blue tone. (I don't remember what light_strip3 looks like, so I'm making it up)
you would put
light_strip3 10 10 200 500 -spc 10 10 200 10
the first part is like normal, and the -spc (specific color) gives a range of colors to emit that color light.<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
Ideally I'd like to support both light specifications and direct texture sampling, but I'm not going to be coding any major additions to ZHLT right now. I do plan on integrating Hullu's updated custom shadows (thanks for the thread link Reve) once I get permission to do so and after the holidays.
I think I'm probably sounding like a broken record on this point, but the new tools will have a much more flexible lighting model (and texture handling, and blah blah blah <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->).
Ty Cagey. You truely are the most helpful <!--emo&::nerdy::--><img src='http://www.unknownworlds.com/forums/html/emoticons/nerd.gif' border='0' style='vertical-align:middle' alt='nerd.gif'><!--endemo--> of us all <!--emo&:D--><img src='http://www.unknownworlds.com/forums/html/emoticons/biggrin.gif' border='0' style='vertical-align:middle' alt='biggrin.gif'><!--endemo-->
Yeah Cagey! You da best!!!!!!!!!!!!!!!!!11oneoneeleven <!--emo&:D--><img src='http://www.unknownworlds.com/forums/html/emoticons/biggrin.gif' border='0' style='vertical-align:middle' alt='biggrin.gif'><!--endemo-->
Anyone looked at the zhlt_invisible and zhlt_noclip options? They work great for me particuarly in some SoHL maps-- func_shine dosent need clipnodes.
Why Im really posting is to ask if those options could/should be made like on/off? EDIT: settable to 0 or 1. Rather than just putting something in the box? (I added them to my FGDs <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo--> ) I reckon it would make more sense like that as they are on/off settings...
Oh btw XP-Cagey: these tools are quite fantastic. mad props.
Comments
For an easy starter map, check out the NS World sample map here: <a href='http://nsworld.ns-central.co.uk/mappingguide/appendix7.htm' target='_blank'>http://nsworld.ns-central.co.uk/mappinggui...e/appendix7.htm</a>. The map file link is up near the top of the page.
<span style='color:yellow'>I suggest the colour yellow</span> as it seems to be the next best alternative. It seems to contrast very well on the dark background (discovered when I made the Nancy FAQ).
Anyway, keep up the good work! <!--emo&:D--><img src='http://www.unknownworlds.com/forums/html/emoticons/biggrin.gif' border='0' style='vertical-align:middle' alt='biggrin.gif'><!--endemo-->
<!--QuoteEnd--> </td></tr></table><span class='postcolor'> <!--QuoteEEnd-->
Thanks for the advice -- made the change <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->
bug bug!
I am using p10 at the moment, as mixing p10 with p12 rad is not wise
ok, the issue
i am using larage amounts of null in my map (the map would be a good 30% null), when i complied it with p10 the null was not striped in 1 part of the map, and i had the aaatrigger flash light effect through out the map
i duno if u want more info on this if u do, pm me, or email amckern@yahoo.com
amckern
bug bug!
I am using p10 at the moment, as mixing p10 with p12 rad is not wise
ok, the issue
i am using larage amounts of null in my map (the map would be a good 30% null), when i complied it with p10 the null was not striped in 1 part of the map, and i had the aaatrigger flash light effect through out the map
i duno if u want more info on this if u do, pm me, or email amckern@yahoo.com
amckern <!--QuoteEnd--> </td></tr></table><span class='postcolor'> <!--QuoteEEnd-->
If you reproduce it in p12 (using only p12 for all stages), I'll try to figure out what's going on... I'm only going to support the latest version of the tools, especially since I'm only fixing bugs between versions at this point.
I can't think of a reason why only some of the NULL textures in a level would be removed--there isn't any internal counter or looping process that would limit the quantity of faces being ignored on export.
Your modified tools are great. Big thanks !
But i'm wondering if you could higher the limit of "-maxnodesize #" in hlbsp without any extra coding !?
The actual limit is 4096, 8192 would be nice, so that there aren't any extra cuts through the whole map.
I am mapping terrain-maps with a special method and immense hint-brush usage
Your modified hull-generation is great to eleminate most sticky corners...but the extra cuts and leaf-errors caused by the maxnodesize-cut(s) are annoying !
Your modified tools are great. Big thanks !
But i'm wondering if you could higher the limit of "-maxnodesize #" in hlbsp without any extra coding !?
The actual limit is 4096, 8192 would be nice, so that there aren't any extra cuts through the whole map.
I am mapping terrain-maps with a special method and immense hint-brush usage
Your modified hull-generation is great to eleminate most sticky corners...but the extra cuts and leaf-errors caused by the maxnodesize-cut(s) are annoying ! <!--QuoteEnd--> </td></tr></table><span class='postcolor'> <!--QuoteEEnd-->
I'll have to investigate if there are any side effects in the engine when this number is higher than 4096 before I release a code change -- I'll add it to my to-do list.
Pretty sure it's possible, but I'll be looking at it for the new tools rather than implementing it in ZHLT. It would be nice to have an adaptive patch scale routine that automatically scaled up the effective patch size if the lighting was constant or near-constant across the face, too.
Take a look at this pic and you'll understand how max planes are being reached : <a href='http://www.keithfromneath.btinternet.co.uk/hammer.jpg' target='_blank'>de_gower hammer view</a>
The map itself : <a href='http://www.keithfromneath.btinternet.co.uk/gower/de_gower12.jpg' target='_blank'>clicky for picky</a>
Any advice / help would be appreciated.
Is it telling you the name of the file that's missing?
Both dlls should actually be dlls... msvcr70.dll and msvcp70.dll. One's the MS runtime for C support in .Net, the other is the MS runtime for C++ support in .Net including the MS version of the standard library.
<!--QuoteBegin--clay_9+Dec 16 2003, 04:28 PM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (clay_9 @ Dec 16 2003, 04:28 PM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->Again Cagey I'm sure you here this all the time, your tools are fantastic (regular zoners stopped compiling my map ages ago). But I'm still hitting the max planes 65535. Is there any way too increase the max planes?<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
Increasing max planes on a temporary basis before OPT_PLNS runs is possible, but requires a change in the way HLCSG exports data and the way HLBSP retrieves it. Planes are currently being stored in the BSP file between programs, and it's not possible for me to increase the limit without using a different storage system since the BSP format refers to planes using a 16 bit number.
I'm not going to raise the limit in ZHLT again since I'm working on debugging and stability issues only for p13, but the replacement tools (which are still a ways off) have no internal limit on the number of planes you use as long as the optimized number is under 32K to match the Half-Life engine's limit.
Thanks for the tools anyway, gower wouldn't be as sexy as it is right now if it wasn't for them.
Is it telling you the name of the file that's missing?
Both dlls should actually be dlls... msvcr70.dll and msvcp70.dll. One's the MS runtime for C support in .Net, the other is the MS runtime for C++ support in .Net including the MS version of the standard library. <!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
ah well theres the problem - one of ur d/l links actually points to a exe with the same name as one of the dlls needed. I just googled the dll and d/l it and got the tools working fine.
The texture lights could be improved if this was added: Pixel dependant light colour and strength.
As it is right now with texture lights, the entire texture only gives off one colour (the one from the lights.rad file) But it would be cool if it could use the pixel colour of the texture as the light. It could be added in the rad file after the texture name like this:
light_strip3 -pixel 2.5
If you don't want the texture to have this texture rgb light then you could just make the rad file the normal way.
It would just use the texture RGB value as the light. The value after -pixel is the multiply value. When compiling it makes a grayscale value out of the RBG value and uses this as the light strength. Then the multiply value just raises this so i can adjust the brigtness/strengh
This could be making good lighted levels easier to make. As i said before it should not replace the old texture lights only add more options to the texture lights.
The texture lights could be improved if this was added: Pixel dependant light colour and strength.
As it is right now with texture lights, the entire texture only gives off one colour (the one from the lights.rad file) But it would be cool if it could use the pixel colour of the texture as the light. It could be added in the rad file after the texture name like this:
light_strip3 -pixel 2.5
If you don't want the texture to have this texture rgb light then you could just make the rad file the normal way.
It would just use the texture RGB value as the light. The value after -pixel is the multiply value. When compiling it makes a grayscale value out of the RBG value and uses this as the light strength. Then the multiply value just raises this so i can adjust the brigtness/strengh
This could be making good lighted levels easier to make. As i said before it should not replace the old texture lights only add more options to the texture lights. <!--QuoteEnd--> </td></tr></table><span class='postcolor'> <!--QuoteEEnd-->
(sorry for double post)
Andos, I do not think it is possible for the HL Engine. Not only programming the pixels and the colours to the pixels but trying to create all that different coloured lighting and so much lighting in one area would probably max out the engine and create a few compiling errors. It is a very nice idea, hopefully someone can adapt to it.
let's pretend you want light_strip3 to emit a nice blue tone. (I don't remember what light_strip3 looks like, so I'm making it up)
you would put
light_strip3 10 10 200 500 -spc 10 10 200 10
the first part is like normal, and the -spc (specific color) gives a range of colors to emit that color light.
So, if there's a pixel that's "10 15 195" it would emit "10 10 200 500 " and same for "15 5 205" the last # in the sequence "-spc 10 10 200 10" tells rad that there can be a range of 10 color points to be off for that to emit the one color, which is 10 10 200 with 500 as the strength.
This makes me think that RAD actually just places alot of smaller brightness direct ligts just next to the texture surface. If this is truen then it would be no problem for RAD to open the wad and get the pixel colour of the texture. Worldcraft can open up wads insanely fast and since there are mostly not that many lights in your rad file there would be no issues here i think. Correct me if i'm wrong.
Btw did you guys see the rad light hack thread? It could do some trix with the lighting. If my idea doesn't work then this trick could maybe be used to work the same way? I don't know <!--emo&:p--><img src='http://www.unknownworlds.com/forums/html/emoticons/tounge.gif' border='0' style='vertical-align:middle' alt='tounge.gif'><!--endemo-->
<a href='http://collective.valve-erc.com/index.php?doc=1034150354-69206000&page=2#32' target='_blank'>http://collective.valve-erc.com/index.php?...06000&page=2#32</a>
Reve
To help a bit: Defining pixels that emit light and ones that don't is not an option, because the light patches cover several pixels at once. Overlay textures are the very best you can do. If you don't want to waste entities you can still try point lights directly in front of the light source. Usually this looks quite cool. (Don't flame me before you tried, thx <!--emo&;)--><img src='http://www.unknownworlds.com/forums/html/emoticons/wink.gif' border='0' style='vertical-align:middle' alt='wink.gif'><!--endemo--> )
<!--QuoteBegin--Thursday-+Dec 20 2003, 04:03 PM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (Thursday- @ Dec 20 2003, 04:03 PM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->This has probably been asked before but well, can you increase the amount of light patches in the RAD to compile Xp-Cagey? Or in some way tweak RAD so less patches will be used?<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
Check out the -chop and -texchop options <a href='http://www.valve-erc.com/content/resources/zhlt/ZHLTReference.html' target='_blank'>here</a>. The number of patches will be inversely proportional to the patch area specified. You can increase the number of samples taken without increasing the final number of patches using -extra.
<!--QuoteBegin--Andos+Dec 21 2003, 06:40 AM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (Andos @ Dec 21 2003, 06:40 AM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->This makes me think that RAD actually just places alot of smaller brightness direct ligts just next to the texture surface. <!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
That's correct -- the current code assigns one light per patch on the face of the texture that's emitting the light. Each light emits at up to 90 degrees from the surface of the texture.
<!--QuoteBegin--Fluffybunny+Dec 21 2003, 01:10 AM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (Fluffybunny @ Dec 21 2003, 01:10 AM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> well, if not that, a specific color range of pixels would emit a certain color, eliminating the need for overlays in most circumstances.
let's pretend you want light_strip3 to emit a nice blue tone. (I don't remember what light_strip3 looks like, so I'm making it up)
you would put
light_strip3 10 10 200 500 -spc 10 10 200 10
the first part is like normal, and the -spc (specific color) gives a range of colors to emit that color light.<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
Ideally I'd like to support both light specifications and direct texture sampling, but I'm not going to be coding any major additions to ZHLT right now. I do plan on integrating Hullu's updated custom shadows (thanks for the thread link Reve) once I get permission to do so and after the holidays.
I think I'm probably sounding like a broken record on this point, but the new tools will have a much more flexible lighting model (and texture handling, and blah blah blah <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->).
They work great for me particuarly in some SoHL maps-- func_shine dosent need clipnodes.
Why Im really posting is to ask if those options could/should be made like on/off? EDIT: settable to 0 or 1.
Rather than just putting something in the box? (I added them to my FGDs <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo--> )
I reckon it would make more sense like that as they are on/off settings...
Oh btw XP-Cagey: these tools are quite fantastic. mad props.