Quickstart Guide Update
ChromeAngel
Join Date: 2002-01-24 Member: 14Members, NS1 Playtester, Contributor
Join Date: 2002-01-24 Member: 14Members, NS1 Playtester, Contributor
<div class="IPBDescription">New info_mapinfo Appendix</div> I've update the <a href='http://nsworld.ns-central.co.uk/mappingguide/MappingGuide.php' target='_blank'>Quickstart Guide to Mapping for NS</a> to include more detail about some entites, more information about sieges and added to the "avoid like the plague" section.
There is also a new appendix focusing on the configuration of <a href='http://nsworld.ns-central.co.uk/mappingguide/appendix6.php' target='_blank'>info_mapinfo</a> entities.
I'm working on a sample map to acompany the Quickstart guide. If you have any map bit's that show off NS entities particuarly well please send them over so I can include them in the sample map (full credit will be given).
I'd also like to know what you think the guide need most :
Illustrations
A "primer" for complete n00bs
An appendix focusing on compiling and compiler optimizations
There is also a new appendix focusing on the configuration of <a href='http://nsworld.ns-central.co.uk/mappingguide/appendix6.php' target='_blank'>info_mapinfo</a> entities.
I'm working on a sample map to acompany the Quickstart guide. If you have any map bit's that show off NS entities particuarly well please send them over so I can include them in the sample map (full credit will be given).
I'd also like to know what you think the guide need most :
Illustrations
A "primer" for complete n00bs
An appendix focusing on compiling and compiler optimizations
Comments
Illustrations
A "primer" for complete n00bs
An appendix focusing on compiling and compiler optimizations <!--QuoteEnd--> </td></tr></table><span class='postcolor'> <!--QuoteEEnd-->
My vote is for the "compiling and compiler optimizations" appendix.
The primer comes in at a close second, however. <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->
Illustrations
A "primer" for complete n00bs
An appendix focusing on compiling and compiler optimizations<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
My vote is for the whole set <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo--> but "<i>compiling and compiler</i>" first
Also, ChromeAngel, why not make your document an extention to the existing and recently updated "Official NS Mapping Guidelines" document? Meaning, don't have duplicate information, but rather new information that isn't in the official document.
For example, I like the section "Siege Cannon Frequently Asked Question", which doesn't exist in the official document.
but i like your idea about some FAQs that the offical guide doesn't cover.
things like:
<i>
TF range = 1200 units diameter = 600 radius
seige cannon range = 1100 units
combined range from TF to max seige hitting is 1100+600=1700 one way.
so 3800+ space between hives?</i>
oh, NM - you HAVE a <a href='http://nsworld.ns-central.co.uk/mappingguide/MappingGuide.php#Siege%20Cannon%20FAQ' target='_blank'>seige FAQ </a> already.....
</i>
Isnt it 1250 units (radius) !!!!?
Chrome, we absolutely need these features in ur next guide !
compiling tricks to make your map look better:
i will show you a final compile setup that i used, and explain WHY i did what i did. it may give you ideas for improving how your level looks thru compiling.
<b>hlcsg -hullfile c:\sierra\half-life\nstr\nshulls.txt -wadinclude mycustomwad.wad -low -chart mymap.map</b>
remember you need to include <b>hlcsg -hullfile c:\sierra\half-life\nstr\nshulls.txt</b> to EVERY NS compile, because NS uses special hulls. That is what the FAQs say - it is mainly to keep Onos from "jumping out of" the map.
<!--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--><b>from the mapping guidelines</b>: Because of the various sizes of player models in Natural Selection, CSG requires a new hull file for the collision detection in a map. This is a fairly simply process. Just add the switch "-hullfile c:\sierra\half-life\nstr\nshulls.txt" to CSG's parameters (changing the path to reflect your local path of course). This is necessary so collision detection works properly. <!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
<i>the hulfile itself is just this:
32 32 72
64 64 108
32 32 36</i>
i used wadinclude so that servers can have my map downloaded without haveing to seperately send the .wad. it makes things easier.
i used the -low because it seems to make for less problems, and i can cruse the web while compiling.
i use -chart to keep track of what limits i am getting near.
<i>i did not put in Cagey's new CSG options, because it is a beta. anyway, if you want info on that look at cagey's post about his new tool that deals with maxplanes.</i>
<b>hlbsp -maxnodesize 512 -low -chart mymap.map</b>
-maxnodesize 512: since r_speeds are such a trouble to NS, and since large open areas are not workable, i find that smaller leafnodes tend to give smaller r_speeds. HOWEVER, you NEED to also run an earlier set for r_speed checks without this so you can compare if the standard default 1024 leafnode max size gives you better r_speeds. <i>note that a maxnodesize lower than the default 1024 may make you hit limits faster, running out of leafs, wpolys, patches and what have you. try it only if you are not next to limits, or try it and change back if it doesn't work.</i>
low and chart i have already explained.
<b>hlvis -full -low -chart mymap.map</b>
-full tends to solve problems, give more accurate r_speeds, help RAD to run later - and THIS rad is gonna need it! regardless, i always VIS -full, even for minor tests incase an r_speed problem comes up.
<b>hlrad -notexscale -sparse -texchop 16 -extra -chop 32 -bounce 4 -coring 0.2 -smooth 80 -full -low -chart mymap.map</b>
here is the meat of the looks improvement.
-notexscale: this seperates the light patch size from the texture scaling so often done to lower r_speeds. usually this means more patches of work for RAD to do, and often a max patches error...... but sparse....
-sparse: this stops the maxpatches error from happening. the final compile WILL be slower though.
-texchop 16: makes the biggest patch for a texture light SOURCE only 16x16. 4 times more light textrue work than the 32x32 default. this will make the texture light look better. (normal default=32)
-extra: splits the texture chop in 1/2 again, so that a texture light SOURCE is only 8x8 now - 16 times the default 32x32 RAD work. but it also helps point lights, spotlights, light env and any other light source look better. extra does a lot of oversampling, besides splitting texchop in half.
-chop 32: every single non light patch can now only be 32x32. this makes lighting from every source more precise, but also make the whole RAD thing take 4 times a long again. (normal default is 64)
-bounce 4: lets non switchable light bounce around 4 times. minor increase in work for a major increase in looks. if you skip the chop changes, keep this.
>><i>NOTE: bounce 4 is a matter of TASTE, for a lot of NS maps a bounce of 1 or 2 would be better looking!</i><<
-coring 0.2: for switchable lights on/off, makes them look better and aviods the "bullseye" so often seen around a switchable light. instead of cutting of light calc at 1.0, the light calc goes out to 0.2, giving a more shading effect. since ALL lights will stretch further, there is more work, but it doesn't seem that big a time cost. <i>but if you don't have switchable lights, you can drop this.</i>
-smooth 80: for any angle 80 degree or less, phong shading calc goes on. this makes cylinders look rounder, and shadows less jaggy. i don't use 90+, because i like right angles on walls to look as sharp as they can. on the other hand for some NS maps that use beveling of 60 or 45 degrees fro the walls, you want it to look sharp too - so then use -smooth 55 or smooth 40. another big improvement for little time cost.
well, that is the main ones i know of. if you are using the 1.7+ extension of zoners are a few specials, like switchable texture lights, but these are the main parameters that make levels look better. i hope they work for you.
Also, ChromeAngel, why not make your document an extention to the existing and recently updated "Official NS Mapping Guidelines" document? Meaning, don't have duplicate information, but rather new information that isn't in the official document.
For example, I like the section "Siege Cannon Frequently Asked Question", which doesn't exist in the official document. <!--QuoteEnd--> </td></tr></table><span class='postcolor'> <!--QuoteEEnd-->
I'd love to see the Quickstart Guide as part of the offical guidelines ( I was VERY disapointed Flayra didn't ask me to make the QSG the offical guidelines, after all the time I spent compiling and writing them [Guess that's what I get for putting in a whole section dedicated to Flayra's cockups]). If XP-Cagey is reading this and would like me to re-format the QSG to the same standard as the new Guildelines document i'm cool with that.
Having NS mapping info in 2 places could be usefull in the case one of the sites goes down ( which is not unknown ).
Thanks to Tommy14 for writing all that out <!--emo&:p--><img src='http://www.unknownworlds.com/forums/html/emoticons/tounge.gif' border='0' style='vertical-align:middle' alt='tounge.gif'><!--endemo-->