"It is recommended that maps seeking official status use ns.wad for texturing to maintain a common look to the textures. You may be asked to retexture a submission that uses custom textures before it is accepted as an official map."
Would that only apply to textures that are just obviously not NS related (like castle walls and suchlike)? I wonder what the dev team deems to be reasons for a request to re-texture. If one make a map of mostly custom textures, but it had an obvious "spacey" or "futuristic lab" type feel, would that be asked to re-texture. Basically I'm wondering how strict this request to use the NS wad is and what you can get away with.
<!--QuoteBegin--Guspaz+Apr 14 2003, 03:38 PM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (Guspaz @ Apr 14 2003, 03:38 PM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> Forgive me, but what's with the 4MB texture limit? Surely in this day and age of 128MB cards, with 256MB cards on the way, NS should at the very least be able to take advantage of the space on ancient 16MB cards like the older TNTs or VooDoo 3!
I don't think any modern card sold today by the major companies even has less than 64MB... What's with the bias towards 8MB cards? Isn't Half-Life's horrible texture support bad enough without setting extremely low limits on getting around those low-res low-depth textures by using a greater variety? <!--QuoteEnd--> </td></tr></table><span class='postcolor'> <!--QuoteEEnd--> Bcos it's the engine that has the limit hard-coded, and the engine was written a looooooong time ago, and (until they release the source-code for HL), we can't edit it in any way
<!--QuoteBegin--Calantus+Apr 15 2003, 12:07 AM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (Calantus @ Apr 15 2003, 12:07 AM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> Since Flayra originally wanted to support software mode, I doubt he would want to upp the requirements of NS to 16 or 32MB cards we use nowdays. Half-life has lots of people playing it on ancient machine because, well, helf-life <i>itself</i> is ancient. I can't see why anyone would code a mod for half-life without its community being a factor. Since much of that community have ancient machines, I don't see why you'd want to cut them out of a mod. If you wanted to make your mod for the high-end cards of today, why not make a mod based off of Quake 3? Or NOLF2? Or Unreal 2003? Or even the Serious engine... now that's a sweet little engine for a 1/2 priced game.
EDIT: Less than 400 entities... <!--emo&:(--><img src='http://www.unknownworlds.com/forums/html/emoticons/sad.gif' border='0' style='vertical-align:middle' alt='sad.gif'><!--endemo--> Ok then. <!--QuoteEnd--> </td></tr></table><span class='postcolor'> <!--QuoteEEnd--> 32MB cards might be pushing it, but I don't think a 16MB card would be out of the question; it covers every integrated video chipset there is today, and all videocards back to the Voodoo 3 or TNT.
Software mode? Is there any limit to the max memory used by textures in software mode?
And, I'd assume that people make mods for NS for a share of the massive userbase, which is due to CS more than the requirements.
If flayra is putting these limits on NS to maintain compatibility with software mode, I must dissagree with his decision. Though, perhaps a poll on the forums to see how many people use software mode would be useful. I think it's time to move beyond the days of DooM.
predatory_kangaroo: If there is a hard 4MB limit in HL preventing it from loading more than that many textures, why is the limit in the NS mapping guide stated as an approximate limit, as in, ~4MB? How come some CS maps have way more than 4MB of textures (I think)?
<!--QuoteBegin--predatory_kangaroo+Apr 16 2003, 02:06 PM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (predatory_kangaroo @ Apr 16 2003, 02:06 PM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> <!--QuoteBegin--Guspaz+Apr 14 2003, 03:38 PM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (Guspaz @ Apr 14 2003, 03:38 PM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> Forgive me, but what's with the 4MB texture limit? Surely in this day and age of 128MB cards, with 256MB cards on the way, NS should at the very least be able to take advantage of the space on ancient 16MB cards like the older TNTs or VooDoo 3!
I don't think any modern card sold today by the major companies even has less than 64MB... What's with the bias towards 8MB cards? Isn't Half-Life's horrible texture support bad enough without setting extremely low limits on getting around those low-res low-depth textures by using a greater variety? <!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd--> Bcos it's the engine that has the limit hard-coded, and the engine was written a looooooong time ago, and (until they release the source-code for HL), we can't edit it in any way <!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd--> With ZHLT we can raise the limit, it's a simple command (sorry if that's not the correct term, but my english skills are not very good when I'm tired...):
Under "The Text Readme" in "Required Support Files":<!--QuoteBegin--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> </td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->For consistency, the file must be named <your bsp name>_readme.txt, and must be located in the maps directory with your BSP file. <!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
I don't think the "_readme" should be there. Unless, this new naming convention is appearing in NS 1v1. Standard naming conventions in HL have the TXT file the same name as the BSP file, except for the extentions.
Another thing not mentioned, was .RES files. Mappers should be required to include this with their map if they have any other files needed besides the standard NS files or their BSP file. Heck, might as well just make it standard all together. The contents of this file would be similar to your example under "File Naming Standards".
<!--QuoteBegin--HoundDawg+Apr 16 2003, 09:40 AM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (HoundDawg @ Apr 16 2003, 09:40 AM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->Under "The Text Readme" in "Required Support Files":<!--QuoteBegin--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> </td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->For consistency, the file must be named <your bsp name>_readme.txt, and must be located in the maps directory with your BSP file. <!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
I don't think the "_readme" should be there. Unless, this new naming convention is appearing in NS 1v1. Standard naming conventions in HL have the TXT file the same name as the BSP file, except for the extentions.
Another thing not mentioned, was .RES files. Mappers should be required to include this with their map if they have any other files needed besides the standard NS files or their BSP file. Heck, might as well just make it standard all together. The contents of this file would be similar to your example under "File Naming Standards".<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd--> I'll make the change to the filename to keep it consistant with HL naming conventions -- I recieved an email about .RES files yesterday, and I'll be putting in a new section on them under Required Files for the next revision of the doc.
<!--QuoteBegin--Calantus+Apr 15 2003, 09:23 AM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (Calantus @ Apr 15 2003, 09:23 AM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> I have a question about the comment on textures:
"It is recommended that maps seeking official status use ns.wad for texturing to maintain a common look to the textures. You may be asked to retexture a submission that uses custom textures before it is accepted as an official map."
Would that only apply to textures that are just obviously not NS related (like castle walls and suchlike)? I wonder what the dev team deems to be reasons for a request to re-texture. If one make a map of mostly custom textures, but it had an obvious "spacey" or "futuristic lab" type feel, would that be asked to re-texture. Basically I'm wondering how strict this request to use the NS wad is and what you can get away with.<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
I'm not on the dev team, but I think the best approach might be to create a test room with your new textures, post it to the Artwork forum, and get the opinion of Fam and some of the other developers to see whether it fits the theme closely enough before creating a full level using it. IMO there's still a lot of possible atmospheric variation within the sci-fi genre (if you compare Alien to episodes of the original Star Trek series, you'll see what I mean). I suspect that there is some leeway here since there is some atmospheric variation in the 1.0 maps, but the restriction is subjective and the final decisions aren't mine to make, so I can't supply concrete guidelines <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->.
If I remember correctly, there are additional textures for the 1.1 maps that will become part of the official set when the next client update is released. One item that's a definate no-no is the use of derivative textures from other projects or games that are copyrighted--that's off the topic you asked about, but it still could use repeating in any discussion of adding textures to NS <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->.
Check out that poll right there. I belive I was once told or read that the decision to keep Software-mode and the 4-meg texturelimit is based partly on that poll. Many things have been said on that poll to try and dismiss it's numbers.. still, it's the result of over 800.000 users.. must count for something?
Oh and please, could we not talk like the 4 megabytes texturelimit is directly related to having 16 megabytes on the videocard, or 32, 128, or whatever? There <i>are</i> other things that needs loading.. The framebuffers takes up plenty of space for one, as does the textures of the playermodels, buildings, weapons, etc. That's just off the top of my head, someone in the know might be able to mention more.
At the end of the day I'm not against raising the limits myself, but I don't know what it'd break.. I assume the developers has reasons for it being set to the classic 4 megabytes. Personally I've gone and taken the "shut up and accept you get to play a fun mod" approch on that issue <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->
1st : GG GJ Cagey ; 2nd : I beg my pardon but as im right now translating this guide in my language, i read it line by line and i m pointing out a small mistake in the "File Naming Standards" paragraph.
It is not to find the little thing ; i just want it to be absolutely PER-FECT and avoid confusions <!--emo&:D--><img src='http://www.unknownworlds.com/forums/html/emoticons/biggrin.gif' border='0' style='vertical-align:middle' alt='biggrin.gif'><!--endemo-->
<!--QuoteBegin--oOTOo+Apr 17 2003, 07:15 AM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (oOTOo @ Apr 17 2003, 07:15 AM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> Shouldn't it be .spr and .mp3 ?
It is not to find the little thing ; i just want it to be absolutely PER-FECT and avoid confusions <!--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 catching the mistake -- it'll be fixed in the next version <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->
Check out that poll right there. I belive I was once told or read that the decision to keep Software-mode and the 4-meg texturelimit is based partly on that poll. Many things have been said on that poll to try and dismiss it's numbers.. still, it's the result of over 800.000 users.. must count for something?
Oh and please, could we not talk like the 4 megabytes texturelimit is directly related to having 16 megabytes on the videocard, or 32, 128, or whatever? There <i>are</i> other things that needs loading.. The framebuffers takes up plenty of space for one, as does the textures of the playermodels, buildings, weapons, etc. That's just off the top of my head, someone in the know might be able to mention more.
At the end of the day I'm not against raising the limits myself, but I don't know what it'd break.. I assume the developers has reasons for it being set to the classic 4 megabytes. Personally I've gone and taken the "shut up and accept you get to play a fun mod" approch on that issue <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo--> <!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd--> I know why the number of software users is so high. Software is the default setting. That poll is done from a patch. Many people install the patch right after installing HL. Therefore, the poll is done BEFORE people set their HL video settings! No wonder 44% "use" software mode <!--emo&:p--><img src='http://www.unknownworlds.com/forums/html/emoticons/tounge.gif' border='0' style='vertical-align:middle' alt='tounge.gif'><!--endemo--> Besides, Of all the people I know who play CS, and there are dozens of them, only one uses software mode because his computer only has a 2MB Cirrus video chipset <!--emo&:p--><img src='http://www.unknownworlds.com/forums/html/emoticons/tounge.gif' border='0' style='vertical-align:middle' alt='tounge.gif'><!--endemo-->
No, it is true there are other things. But at 800x600x16bit, the framebuffer is under 1MB. I admit, 4MB is a good limit for 8MB cards. But, when's the last time you saw an 8MB card? On that poll you send, 68.3% of the users had cards that I know for 100% certain have _32MB_ or more memory on them! When you add in all the 16MB cards on that list, plus the cards that have 16 or 32, but I don't know that, I'm sure you have well over 80%. Probably well over 90%. I'm pretty sure that the actual number of people that use hardware accelerated mode and have an 8MB card are a VERY small minority.
So, I think the minimum should be raised to 8 or 12MB. Nothing rediculous at the moment.
As for shut up and play, I think it's already happening, I'm sure I'd spend way more time complaining if I wasn't so damned busy playing <!--emo&:p--><img src='http://www.unknownworlds.com/forums/html/emoticons/tounge.gif' border='0' style='vertical-align:middle' alt='tounge.gif'><!--endemo--> While I fully enjoy the mod, and in fact think NS is the best FPS out there bar none, NONE, I think it would be a huge bonus if it looked better, and more textures can do just that <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->
I've heard rumors about software... i do not know if they are true... but i read that software mods has less "restrictions" then opengl and D3D have in some areas, like lighting.
Could you maybe elaborate on that BlackPanther? I mean.. yeah, from Valve's point of view their software-renderer would be the most versatile one, there's nothing in it they don't have complete control over. Lighting as you mention is one of the areas OGL and D3D likes to handle their way, in the sense that you don't neccessairly get a lot of control over how it's done. I think it's likely you can do some fancy things in software that might not be possible in OGL or D3D. That goes for landscapes as well, there are neat clever ways to optimize rendering a landscape, but at the end of the day they all rely on the CPU so much that I belive it's actually faster to just take all the **** polygons and throwing them at the graphicscard. I think that's how UT2003 does it, screw optimizing the dataset too much, modern graphicscards can handle the polygons faster.
Anyway, the drawback with software-mode is that it is indeed software, so it's incredibly slow compared to OGL or D3D. At the end of the day software mode may theoretically offer everything, but the slowness outweighs it all.. I belive Valve mentioned in interviews or some article that it was the software-renderer that was the most work keeping functional.. with their support for OGL, D3D <i>and</i> software that's roughly three times the work other games goes through that only has one supported mode. At least as far as I know almost everything involving drawing to the graphicscard has to be specialized to each renderer.. not so much fun.
..uh.. sorry for going so off-topic <!--emo&???--><img src='http://www.unknownworlds.com/forums/html/emoticons/confused.gif' border='0' style='vertical-align:middle' alt='confused.gif'><!--endemo-->
Me again. As im still translating each line of the new mapping guidelines, i noticed that the "Notes" paragraph is the same in Trigger_presence and Trigger_random descriptions :
" <i>Notes: This entity is designed to track whenever 1 or more entities of a given type are within its bounds. Activation target is fired when the count goes from 0 to 1+, and Deactivation Target fires when the count drops back to 0.</i>"
It shouldn't be, i suppose, cause the Trigger_random is not activated in the same way as Trigger_presence. Is it ? <!--emo&???--><img src='http://www.unknownworlds.com/forums/html/emoticons/confused.gif' border='0' style='vertical-align:middle' alt='confused.gif'><!--endemo-->
RE: info_location <!--QuoteBegin--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> </td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->Uses X and Y bounds instead of brush shape to determine boundaries. Z information is disregarded, so making the brush "short" can reduce the map's size without hurting the effect.<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd--> I don't think this applies to pre-1.1 maps. I tested this by having an info_location 8 units high below a hive and it didn't name the hives. Nor did it work in any of the rooms the way this text says. The only way to get it to work is to use the Z axis and fill the area with the brush size that you want the info to be used. <!--QuoteBegin--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> </td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->Use of the NULL texture on this entity can reduce the amount of light data in your map, especially if the brush is large.<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd--> So, using NULL rather than AATRIGGER really makes a difference on these types of brush entities? Should the same apply to other brush entities like func_ladder or trigger_presence? <!--QuoteBegin--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> </td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->info_locations should NEVER overlap in XY.<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd--> I haven't noticed a problem in pre-1.1 maps where you could have overlapped info_locations and they work great. As for v1.1 and beyond, if changes are made to where info_locations are broken, I see changes to maps that will be needed. Especially, all those that are vertical "fun/fall" type maps, where the hives are on top and the marine base are on the bottom. Unless, only the hives have info_location and they aren't stacked vertically on top of eachother.
Basically, I'm all for this if it reduces file sizes and FPS issues. But, mappers will need to realize that they will need to make changes to their maps for v1.1. Also, pointing out the difference between what is now and what is coming would be good.
Most of the 8 MB graphics cards are ATI Rage Pro I guess, used mainly in notebooks today, I guess. I guess Flayra has doomed the Software renderer for it is not able to display all rendermodes AND allows only 4MB world textures, as I have read somewhere. I think we should not take texture limits serious any more. 12 MB world textures should be fine. NS uses particle effects, loads of animated models, a MP3 decompressor and what not... this is no longer at the performance class of Half-Life. And there is even a tool to bypass the 240 units texture chop somewhere, so you can use 512 pixel textures without odd cuts <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo--> (Someone said, if NS should look cool Flayra would have chosen a modern engine: 1. Flayra intended to have NS support software mode. 2. Half-Life is the only game that every damn FPS player has on his/her PC, if not it only costs 10 bucks.)
Great work Cagey, will you ever stop? <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->
<!--QuoteBegin--HoundDawg+Apr 21 2003, 10:04 AM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (HoundDawg @ Apr 21 2003, 10:04 AM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->RE: info_location <!--QuoteBegin--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> </td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->Uses X and Y bounds instead of brush shape to determine boundaries. Z information is disregarded, so making the brush "short" can reduce the map's size without hurting the effect.<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd--> I don't think this applies to pre-1.1 maps.<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd--> That's correct -- pre-1.1, the info_location is defined by the bounding box of the brush... the exact shape doesn't matter, but the mins/maxs along all three axes are used. <!--QuoteBegin--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> </td></tr><tr><td id='QUOTE'><!--QuoteEBegin--><!--QuoteBegin--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> </td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->Use of the NULL texture on this entity can reduce the amount of light data in your map, especially if the brush is large.<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd--> So, using NULL rather than AATRIGGER really makes a difference on these types of brush entities? Should the same apply to other brush entities like func_ladder or trigger_presence?<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd--> Yeah, the null texture really should be used for ANY invisible entity as well as a replacement for any use of the {blue texture, which is less effecient than NULL during runtime and has additional drawbacks (such as lighting differences on Solid Texturemode entities). The latest version of my tools (webbed thread) lets you specify a file listing the class or target names of items that you want to have automatically retextured with NULL so you can continue using whatever texture you want in the editor and automatically have old maps use NULL where appropriate ("-nullfile <filename>" in the HLCSG command line, where the file contains newline delimited classnames and targetnames to convert). <!--QuoteBegin--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> </td></tr><tr><td id='QUOTE'><!--QuoteEBegin--><!--QuoteBegin--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> </td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->info_locations should NEVER overlap in XY.<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd--> I haven't noticed a problem in pre-1.1 maps where you could have overlapped info_locations and they work great. As for v1.1 and beyond, if changes are made to where info_locations are broken, I see changes to maps that will be needed. Especially, all those that are vertical "fun/fall" type maps, where the hives are on top and the marine base are on the bottom. Unless, only the hives have info_location and they aren't stacked vertically on top of eachother.<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd--> Yeah, this will have an impact on those sorts of maps. It's basically a secondary drawback to the no room-over-room guideline those maps aren't following. Then again, if you have a vertical killbox, do you really need to label the rooms as the players are falling? <!--emo&;)--><img src='http://www.unknownworlds.com/forums/html/emoticons/wink.gif' border='0' style='vertical-align:middle' alt='wink.gif'><!--endemo-->
<!--QuoteBegin--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> </td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->Basically, I'm all for this if it reduces file sizes and FPS issues.? But, mappers will need to realize that they will need to make changes to their maps for v1.1.? Also, pointing out the difference between what is now and what is coming would be good.<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd--> Agreed--the next version will note that the Z information is disregarded <i>in version 1.1 and later</i> <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->
<!--QuoteBegin--oOTOo+Apr 21 2003, 09:38 AM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (oOTOo @ Apr 21 2003, 09:38 AM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> Me again. As im still translating each line of the new mapping guidelines, i noticed that the "Notes" paragraph is the same in Trigger_presence and Trigger_random descriptions :
" <i>Notes: This entity is designed to track whenever 1 or more entities of a given type are within its bounds. Activation target is fired when the count goes from 0 to 1+, and Deactivation Target fires when the count drops back to 0.</i>"
It shouldn't be, i suppose, cause the Trigger_random is not activated in the same way as Trigger_presence. Is it ? <!--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--> Fixed in the latest version -- thanks again for the bug reports.
MouseThe Lighter Side of PessimismJoin Date: 2002-03-02Member: 263Members, NS1 Playtester, Forum Moderators, Squad Five Blue, Reinforced - Shadow, WC 2013 - Shadow
<!--QuoteBegin--NerdIII+Apr 22 2003, 04:07 AM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (NerdIII @ Apr 22 2003, 04:07 AM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> I think we should not take texture limits serious any more. 12 MB world textures should be fine. NS uses particle effects, loads of animated models, a MP3 decompressor and what not... this is no longer at the performance class of Half-Life. <!--QuoteEnd--> </td></tr></table><span class='postcolor'> <!--QuoteEEnd--> Actually one good reason for having a 4mb texture limit is so that the .bsps aren't stupidly large. I seem to recall once upon a time DOD didn't have a texture limit and maps were regularly using 8mb or more of textures, resulting in maps that were huge. Another thing a 4mb texture limit is good for is forcing you to get creative with your texturing, which will help make you a better mapper.
As a point of reference, none of the official maps go over the 4mb limit.
In the "File Naming Standards" section, it is written (second line):
"<i>Any custom sprites, models, and sounds must be in directories named after your BSP: (ns/sprites/ns_yellow/mysprite.spr, ns/models/ns_yellow/mymodel.mdl, ns/sounds/<b>ns_sounds</b>/mysound.mp3). </i> .. < instead of > .. <b><i>ns_yellow</b>/mysound.mp3</i>, i guess. Tell if i'm wrong as i already corrected what i think is a bug.
[EDIT] : Another small one : "Naming standards for each type of required support file can be found <b>above</b>." <-- it's "below".
--------------------
And i have a question : You wrote a few lines below «No file in the standard NS distribution may be overwritten». What does it mean ? Does it mean we must not write TOO MUCH data in it, or that we must absolutely write no extra data in it ?
<!--QuoteBegin--oOTOo+Apr 22 2003, 08:38 AM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (oOTOo @ Apr 22 2003, 08:38 AM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> In the "File Naming Standards" section, it is written (second line):
"<i>Any custom sprites, models, and sounds must be in directories named after your BSP: (ns/sprites/ns_yellow/mysprite.spr, ns/models/ns_yellow/mymodel.mdl, ns/sounds/<b>ns_sounds</b>/mysound.mp3). </i> .. < instead of > .. <b><i>ns_yellow</b>/mysound.mp3</i>, i guess. Tell if i'm wrong as i already corrected what i think is a bug.
[EDIT] : Another small one : "Naming standards for each type of required support file can be found <b>above</b>." <-- it's "below".
--------------------
<!--QuoteEnd--> </td></tr></table><span class='postcolor'> <!--QuoteEEnd--> The ns_sounds -> ns_yellow correction will be made in 2.0.7 (I sent 2.0.6 to Flay over the weekend to post to the site).
Actually, in this case it is meant to be "above"--that sentence is referring to the Required Support Files section directly above it, not the zip file example below it which illustrates but does not define any naming standards.
<!--QuoteBegin--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> </td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->And i have a question : You wrote a few lines below «No file in the standard NS distribution may be overwritten». What does it mean ? Does it mean we must not write TOO MUCH data in it, or that we must absolutely write no extra data in it ?<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
You should not be writing any data at all into those files. If you follow the standard, you can only add new files to the directories and those files should be in a location unique to the map name as shown in the example zip. The naming standards provided are designed so that two maps will never write information to the same file (unless the maps have the same name, which they shouldn't with resources like NSWorld available).
If mappers were allowed to change standard files by adding data, any additions from previously installed maps would disappear each time a new map replaces a standard file (there is no way to update a file using in-game autodownload except through replacement, so only replacement can be considered as a way of installing map information). If adding to those files were an accepted practice, extra data written there might not be available the next time a user starts Half-Life.
The end user should never be worried about what adding a map will do to his or her copy of NS, and adding a new map should never break the existing maps in the user's directory. Since many people will acquire new maps using in-game autodownload services, it isn't practical to ask clients to manually merge files. In my experience, requiring end users to do this would be a lot to ask of them anyway.
The official NS mod releases from the development team (like the upcoming 1.1 client release) can modify these files because they are centrally governed and will be expanded consistently--that is, they overwrite the standard files with a newer standard. If custom maps don't rely on custom extensions to the standard files, they will continue to operate as expected when these updates are made.
I personally know what happens when something is written into these files but i wanted to be absolutely sure about the meaning of the word "overwrite" in this special section. Thanks for the complete explanation, i'm 100 sure now (would be nice to integrate it somewhere : a secondary weblink from the mapping guidelines or directly written in the main guidelines page ; dont feel afraid to release a huge huge NS mapping guidelines with plenty of annex documents : a web-like guide about a web-like map in a web-like world <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo--> )
<!--QuoteBegin--XP-Cagey+Apr 23 2003, 09:37 AM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (XP-Cagey @ Apr 23 2003, 09:37 AM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> Flay has posted the 2.0.6 guidelines that add a section on res files and incorporate bug fixes from the first 3 pages of this topic. <!--QuoteEnd--> </td></tr></table><span class='postcolor'> <!--QuoteEEnd--> Great work!
<!--QuoteBegin--Mouse+Apr 22 2003, 01:15 AM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (Mouse @ Apr 22 2003, 01:15 AM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> Actually one good reason for having a 4mb texture limit is so that the .bsps aren't stupidly large. I seem to recall once upon a time DOD didn't have a texture limit and maps were regularly using 8mb or more of textures, resulting in maps that were huge. <!--QuoteEnd--> </td></tr></table><span class='postcolor'> <!--QuoteEEnd--> That's what things like compression are for; ns_lost is 4.51MB uncompressed, but stick it in a RAR file and it's only 1.37MB.
Comments
"It is recommended that maps seeking official status use ns.wad for texturing to maintain a common look to the textures. You may be asked to retexture a submission that uses custom textures before it is accepted as an official map."
Would that only apply to textures that are just obviously not NS related (like castle walls and suchlike)? I wonder what the dev team deems to be reasons for a request to re-texture. If one make a map of mostly custom textures, but it had an obvious "spacey" or "futuristic lab" type feel, would that be asked to re-texture. Basically I'm wondering how strict this request to use the NS wad is and what you can get away with.
I don't think any modern card sold today by the major companies even has less than 64MB... What's with the bias towards 8MB cards? Isn't Half-Life's horrible texture support bad enough without setting extremely low limits on getting around those low-res low-depth textures by using a greater variety? <!--QuoteEnd--> </td></tr></table><span class='postcolor'> <!--QuoteEEnd-->
Bcos it's the engine that has the limit hard-coded, and the engine was written a looooooong time ago, and (until they release the source-code for HL), we can't edit it in any way
EDIT: Less than 400 entities... <!--emo&:(--><img src='http://www.unknownworlds.com/forums/html/emoticons/sad.gif' border='0' style='vertical-align:middle' alt='sad.gif'><!--endemo--> Ok then. <!--QuoteEnd--> </td></tr></table><span class='postcolor'> <!--QuoteEEnd-->
32MB cards might be pushing it, but I don't think a 16MB card would be out of the question; it covers every integrated video chipset there is today, and all videocards back to the Voodoo 3 or TNT.
Software mode? Is there any limit to the max memory used by textures in software mode?
And, I'd assume that people make mods for NS for a share of the massive userbase, which is due to CS more than the requirements.
If flayra is putting these limits on NS to maintain compatibility with software mode, I must dissagree with his decision. Though, perhaps a poll on the forums to see how many people use software mode would be useful. I think it's time to move beyond the days of DooM.
predatory_kangaroo: If there is a hard 4MB limit in HL preventing it from loading more than that many textures, why is the limit in the NS mapping guide stated as an approximate limit, as in, ~4MB? How come some CS maps have way more than 4MB of textures (I think)?
I don't think any modern card sold today by the major companies even has less than 64MB... What's with the bias towards 8MB cards? Isn't Half-Life's horrible texture support bad enough without setting extremely low limits on getting around those low-res low-depth textures by using a greater variety? <!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
Bcos it's the engine that has the limit hard-coded, and the engine was written a looooooong time ago, and (until they release the source-code for HL), we can't edit it in any way <!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
With ZHLT we can raise the limit, it's a simple command (sorry if that's not the correct term, but my english skills are not very good when I'm tired...):
for example: -texdata 8192
And that would raise the limit to 8 MB
I don't think the "_readme" should be there. Unless, this new naming convention is appearing in NS 1v1. Standard naming conventions in HL have the TXT file the same name as the BSP file, except for the extentions.
Another thing not mentioned, was .RES files. Mappers should be required to include this with their map if they have any other files needed besides the standard NS files or their BSP file. Heck, might as well just make it standard all together. The contents of this file would be similar to your example under "File Naming Standards".
I don't think the "_readme" should be there. Unless, this new naming convention is appearing in NS 1v1. Standard naming conventions in HL have the TXT file the same name as the BSP file, except for the extentions.
Another thing not mentioned, was .RES files. Mappers should be required to include this with their map if they have any other files needed besides the standard NS files or their BSP file. Heck, might as well just make it standard all together. The contents of this file would be similar to your example under "File Naming Standards".<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
I'll make the change to the filename to keep it consistant with HL naming conventions -- I recieved an email about .RES files yesterday, and I'll be putting in a new section on them under Required Files for the next revision of the doc.
<!--QuoteBegin--Calantus+Apr 15 2003, 09:23 AM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (Calantus @ Apr 15 2003, 09:23 AM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> I have a question about the comment on textures:
"It is recommended that maps seeking official status use ns.wad for texturing to maintain a common look to the textures. You may be asked to retexture a submission that uses custom textures before it is accepted as an official map."
Would that only apply to textures that are just obviously not NS related (like castle walls and suchlike)? I wonder what the dev team deems to be reasons for a request to re-texture. If one make a map of mostly custom textures, but it had an obvious "spacey" or "futuristic lab" type feel, would that be asked to re-texture. Basically I'm wondering how strict this request to use the NS wad is and what you can get away with.<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
I'm not on the dev team, but I think the best approach might be to create a test room with your new textures, post it to the Artwork forum, and get the opinion of Fam and some of the other developers to see whether it fits the theme closely enough before creating a full level using it. IMO there's still a lot of possible atmospheric variation within the sci-fi genre (if you compare Alien to episodes of the original Star Trek series, you'll see what I mean). I suspect that there is some leeway here since there is some atmospheric variation in the 1.0 maps, but the restriction is subjective and the final decisions aren't mine to make, so I can't supply concrete guidelines <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->.
If I remember correctly, there are additional textures for the 1.1 maps that will become part of the official set when the next client update is released. One item that's a definate no-no is the use of derivative textures from other projects or games that are copyrighted--that's off the topic you asked about, but it still could use repeating in any discussion of adding textures to NS <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->.
Check out that poll right there. I belive I was once told or read that the decision to keep Software-mode and the 4-meg texturelimit is based partly on that poll. Many things have been said on that poll to try and dismiss it's numbers.. still, it's the result of over 800.000 users.. must count for something?
Oh and please, could we not talk like the 4 megabytes texturelimit is directly related to having 16 megabytes on the videocard, or 32, 128, or whatever? There <i>are</i> other things that needs loading.. The framebuffers takes up plenty of space for one, as does the textures of the playermodels, buildings, weapons, etc. That's just off the top of my head, someone in the know might be able to mention more.
At the end of the day I'm not against raising the limits myself, but I don't know what it'd break.. I assume the developers has reasons for it being set to the classic 4 megabytes. Personally I've gone and taken the "shut up and accept you get to play a fun mod" approch on that issue <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->
it is written :
maps/ns_yellow.bsp *
sprites/minimaps/ns_yellow.spr *
overviews/ns_yellow.tga *
overviews/ns_yellow.txt *
maps/ns_yellow.txt
ns_yellow.wad
models/ns_yellow/mymodel.mdl
sprites/ns_yellow/mysprite.<b>mdl </b>
sounds/ns_yellow/mysound.<b>mdl </b>
Shouldn't it be .spr and .mp3 ?
It is not to find the little thing ; i just want it to be absolutely PER-FECT and avoid confusions <!--emo&:D--><img src='http://www.unknownworlds.com/forums/html/emoticons/biggrin.gif' border='0' style='vertical-align:middle' alt='biggrin.gif'><!--endemo-->
It is not to find the little thing ; i just want it to be absolutely PER-FECT and avoid confusions <!--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 catching the mistake -- it'll be fixed in the next version <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->
Check out that poll right there. I belive I was once told or read that the decision to keep Software-mode and the 4-meg texturelimit is based partly on that poll. Many things have been said on that poll to try and dismiss it's numbers.. still, it's the result of over 800.000 users.. must count for something?
Oh and please, could we not talk like the 4 megabytes texturelimit is directly related to having 16 megabytes on the videocard, or 32, 128, or whatever? There <i>are</i> other things that needs loading.. The framebuffers takes up plenty of space for one, as does the textures of the playermodels, buildings, weapons, etc. That's just off the top of my head, someone in the know might be able to mention more.
At the end of the day I'm not against raising the limits myself, but I don't know what it'd break.. I assume the developers has reasons for it being set to the classic 4 megabytes. Personally I've gone and taken the "shut up and accept you get to play a fun mod" approch on that issue <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo--> <!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
I know why the number of software users is so high. Software is the default setting. That poll is done from a patch. Many people install the patch right after installing HL. Therefore, the poll is done BEFORE people set their HL video settings! No wonder 44% "use" software mode <!--emo&:p--><img src='http://www.unknownworlds.com/forums/html/emoticons/tounge.gif' border='0' style='vertical-align:middle' alt='tounge.gif'><!--endemo--> Besides, Of all the people I know who play CS, and there are dozens of them, only one uses software mode because his computer only has a 2MB Cirrus video chipset <!--emo&:p--><img src='http://www.unknownworlds.com/forums/html/emoticons/tounge.gif' border='0' style='vertical-align:middle' alt='tounge.gif'><!--endemo-->
No, it is true there are other things. But at 800x600x16bit, the framebuffer is under 1MB. I admit, 4MB is a good limit for 8MB cards. But, when's the last time you saw an 8MB card? On that poll you send, 68.3% of the users had cards that I know for 100% certain have _32MB_ or more memory on them! When you add in all the 16MB cards on that list, plus the cards that have 16 or 32, but I don't know that, I'm sure you have well over 80%. Probably well over 90%. I'm pretty sure that the actual number of people that use hardware accelerated mode and have an 8MB card are a VERY small minority.
So, I think the minimum should be raised to 8 or 12MB. Nothing rediculous at the moment.
As for shut up and play, I think it's already happening, I'm sure I'd spend way more time complaining if I wasn't so damned busy playing <!--emo&:p--><img src='http://www.unknownworlds.com/forums/html/emoticons/tounge.gif' border='0' style='vertical-align:middle' alt='tounge.gif'><!--endemo--> While I fully enjoy the mod, and in fact think NS is the best FPS out there bar none, NONE, I think it would be a huge bonus if it looked better, and more textures can do just that <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->
True?
Lighting as you mention is one of the areas OGL and D3D likes to handle their way, in the sense that you don't neccessairly get a lot of control over how it's done. I think it's likely you can do some fancy things in software that might not be possible in OGL or D3D. That goes for landscapes as well, there are neat clever ways to optimize rendering a landscape, but at the end of the day they all rely on the CPU so much that I belive it's actually faster to just take all the **** polygons and throwing them at the graphicscard. I think that's how UT2003 does it, screw optimizing the dataset too much, modern graphicscards can handle the polygons faster.
Anyway, the drawback with software-mode is that it is indeed software, so it's incredibly slow compared to OGL or D3D. At the end of the day software mode may theoretically offer everything, but the slowness outweighs it all.. I belive Valve mentioned in interviews or some article that it was the software-renderer that was the most work keeping functional.. with their support for OGL, D3D <i>and</i> software that's roughly three times the work other games goes through that only has one supported mode. At least as far as I know almost everything involving drawing to the graphicscard has to be specialized to each renderer.. not so much fun.
..uh.. sorry for going so off-topic <!--emo&???--><img src='http://www.unknownworlds.com/forums/html/emoticons/confused.gif' border='0' style='vertical-align:middle' alt='confused.gif'><!--endemo-->
" <i>Notes: This entity is designed to track whenever 1 or more entities of a given type are within its bounds. Activation target is fired when the count goes from 0 to 1+, and Deactivation Target fires when the count drops back to 0.</i>"
It shouldn't be, i suppose, cause the Trigger_random is not activated in the same way as Trigger_presence. Is it ? <!--emo&???--><img src='http://www.unknownworlds.com/forums/html/emoticons/confused.gif' border='0' style='vertical-align:middle' alt='confused.gif'><!--endemo-->
<!--QuoteBegin--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> </td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->Uses X and Y bounds instead of brush shape to determine boundaries. Z information is disregarded, so making the brush "short" can reduce the map's size without hurting the effect.<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
I don't think this applies to pre-1.1 maps. I tested this by having an info_location 8 units high below a hive and it didn't name the hives. Nor did it work in any of the rooms the way this text says. The only way to get it to work is to use the Z axis and fill the area with the brush size that you want the info to be used.
<!--QuoteBegin--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> </td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->Use of the NULL texture on this entity can reduce the amount of light data in your map, especially if the brush is large.<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
So, using NULL rather than AATRIGGER really makes a difference on these types of brush entities? Should the same apply to other brush entities like func_ladder or trigger_presence?
<!--QuoteBegin--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> </td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->info_locations should NEVER overlap in XY.<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
I haven't noticed a problem in pre-1.1 maps where you could have overlapped info_locations and they work great. As for v1.1 and beyond, if changes are made to where info_locations are broken, I see changes to maps that will be needed. Especially, all those that are vertical "fun/fall" type maps, where the hives are on top and the marine base are on the bottom. Unless, only the hives have info_location and they aren't stacked vertically on top of eachother.
Basically, I'm all for this if it reduces file sizes and FPS issues. But, mappers will need to realize that they will need to make changes to their maps for v1.1. Also, pointing out the difference between what is now and what is coming would be good.
I guess Flayra has doomed the Software renderer for it is not able to display all rendermodes AND allows only 4MB world textures, as I have read somewhere.
I think we should not take texture limits serious any more. 12 MB world textures should be fine.
NS uses particle effects, loads of animated models, a MP3 decompressor and what not... this is no longer at the performance class of Half-Life.
And there is even a tool to bypass the 240 units texture chop somewhere, so you can use 512 pixel textures without odd cuts <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->
(Someone said, if NS should look cool Flayra would have chosen a modern engine:
1. Flayra intended to have NS support software mode.
2. Half-Life is the only game that every damn FPS player has on his/her PC, if not it only costs 10 bucks.)
<!--QuoteBegin--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> </td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->Uses X and Y bounds instead of brush shape to determine boundaries. Z information is disregarded, so making the brush "short" can reduce the map's size without hurting the effect.<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
I don't think this applies to pre-1.1 maps.<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
That's correct -- pre-1.1, the info_location is defined by the bounding box of the brush... the exact shape doesn't matter, but the mins/maxs along all three axes are used.
<!--QuoteBegin--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> </td></tr><tr><td id='QUOTE'><!--QuoteEBegin--><!--QuoteBegin--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> </td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->Use of the NULL texture on this entity can reduce the amount of light data in your map, especially if the brush is large.<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
So, using NULL rather than AATRIGGER really makes a difference on these types of brush entities? Should the same apply to other brush entities like func_ladder or trigger_presence?<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
Yeah, the null texture really should be used for ANY invisible entity as well as a replacement for any use of the {blue texture, which is less effecient than NULL during runtime and has additional drawbacks (such as lighting differences on Solid Texturemode entities). The latest version of my tools (webbed thread) lets you specify a file listing the class or target names of items that you want to have automatically retextured with NULL so you can continue using whatever texture you want in the editor and automatically have old maps use NULL where appropriate ("-nullfile <filename>" in the HLCSG command line, where the file contains newline delimited classnames and targetnames to convert).
<!--QuoteBegin--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> </td></tr><tr><td id='QUOTE'><!--QuoteEBegin--><!--QuoteBegin--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> </td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->info_locations should NEVER overlap in XY.<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
I haven't noticed a problem in pre-1.1 maps where you could have overlapped info_locations and they work great. As for v1.1 and beyond, if changes are made to where info_locations are broken, I see changes to maps that will be needed. Especially, all those that are vertical "fun/fall" type maps, where the hives are on top and the marine base are on the bottom. Unless, only the hives have info_location and they aren't stacked vertically on top of eachother.<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
Yeah, this will have an impact on those sorts of maps. It's basically a secondary drawback to the no room-over-room guideline those maps aren't following. Then again, if you have a vertical killbox, do you really need to label the rooms as the players are falling? <!--emo&;)--><img src='http://www.unknownworlds.com/forums/html/emoticons/wink.gif' border='0' style='vertical-align:middle' alt='wink.gif'><!--endemo-->
<!--QuoteBegin--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> </td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->Basically, I'm all for this if it reduces file sizes and FPS issues.? But, mappers will need to realize that they will need to make changes to their maps for v1.1.? Also, pointing out the difference between what is now and what is coming would be good.<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
Agreed--the next version will note that the Z information is disregarded <i>in version 1.1 and later</i> <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->
" <i>Notes: This entity is designed to track whenever 1 or more entities of a given type are within its bounds. Activation target is fired when the count goes from 0 to 1+, and Deactivation Target fires when the count drops back to 0.</i>"
It shouldn't be, i suppose, cause the Trigger_random is not activated in the same way as Trigger_presence. Is it ? <!--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-->
Fixed in the latest version -- thanks again for the bug reports.
NS uses particle effects, loads of animated models, a MP3 decompressor and what not... this is no longer at the performance class of Half-Life. <!--QuoteEnd--> </td></tr></table><span class='postcolor'> <!--QuoteEEnd-->
Actually one good reason for having a 4mb texture limit is so that the .bsps aren't stupidly large. I seem to recall once upon a time DOD didn't have a texture limit and maps were regularly using 8mb or more of textures, resulting in maps that were huge. Another thing a 4mb texture limit is good for is forcing you to get creative with your texturing, which will help make you a better mapper.
As a point of reference, none of the official maps go over the 4mb limit.
"<i>Any custom sprites, models, and sounds must be in directories named after your BSP: (ns/sprites/ns_yellow/mysprite.spr, ns/models/ns_yellow/mymodel.mdl, ns/sounds/<b>ns_sounds</b>/mysound.mp3). </i> .. < instead of > .. <b><i>ns_yellow</b>/mysound.mp3</i>, i guess. Tell if i'm wrong as i already corrected what i think is a bug.
[EDIT] : Another small one : "Naming standards for each type of required support file can be found <b>above</b>." <-- it's "below".
--------------------
And i have a question : You wrote a few lines below «No file in the standard NS distribution may be overwritten». What does it mean ? Does it mean we must not write TOO MUCH data in it, or that we must absolutely write no extra data in it ?
"<i>Any custom sprites, models, and sounds must be in directories named after your BSP: (ns/sprites/ns_yellow/mysprite.spr, ns/models/ns_yellow/mymodel.mdl, ns/sounds/<b>ns_sounds</b>/mysound.mp3). </i> .. < instead of > .. <b><i>ns_yellow</b>/mysound.mp3</i>, i guess. Tell if i'm wrong as i already corrected what i think is a bug.
[EDIT] : Another small one : "Naming standards for each type of required support file can be found <b>above</b>." <-- it's "below".
--------------------
<!--QuoteEnd--> </td></tr></table><span class='postcolor'> <!--QuoteEEnd-->
The ns_sounds -> ns_yellow correction will be made in 2.0.7 (I sent 2.0.6 to Flay over the weekend to post to the site).
Actually, in this case it is meant to be "above"--that sentence is referring to the Required Support Files section directly above it, not the zip file example below it which illustrates but does not define any naming standards.
<!--QuoteBegin--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> </td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->And i have a question : You wrote a few lines below «No file in the standard NS distribution may be overwritten». What does it mean ? Does it mean we must not write TOO MUCH data in it, or that we must absolutely write no extra data in it ?<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
You should not be writing any data at all into those files. If you follow the standard, you can only add new files to the directories and those files should be in a location unique to the map name as shown in the example zip. The naming standards provided are designed so that two maps will never write information to the same file (unless the maps have the same name, which they shouldn't with resources like NSWorld available).
If mappers were allowed to change standard files by adding data, any additions from previously installed maps would disappear each time a new map replaces a standard file (there is no way to update a file using in-game autodownload except through replacement, so only replacement can be considered as a way of installing map information). If adding to those files were an accepted practice, extra data written there might not be available the next time a user starts Half-Life.
The end user should never be worried about what adding a map will do to his or her copy of NS, and adding a new map should never break the existing maps in the user's directory. Since many people will acquire new maps using in-game autodownload services, it isn't practical to ask clients to manually merge files. In my experience, requiring end users to do this would be a lot to ask of them anyway.
The official NS mod releases from the development team (like the upcoming 1.1 client release) can modify these files because they are centrally governed and will be expanded consistently--that is, they overwrite the standard files with a newer standard. If custom maps don't rely on custom extensions to the standard files, they will continue to operate as expected when these updates are made.
Great work!
That's what things like compression are for; ns_lost is 4.51MB uncompressed, but stick it in a RAR file and it's only 1.37MB.