NS mapping info request
Angelusz
Harmonic entropist Join Date: 2003-07-10 Member: 18072Members, Forum Moderators, Constellation, NS2 Playtester
<div class="IPBDescription">Model sizes</div>So, since NS is getting more lively every day, I've started mapping again too. I haven't been a real pro or anything, i once made a NS map which i never got to finish due some bug i couldn't fix, the source is lost now.
However, I'm practicing again and wish to create a combat map to start with. I need information.
I've sent Merkaba a PM with some of these questions (I've talked to him about mapping before) but he probably has other things to do anyway, and I've gotten more questions since.
1) r_speeds; what is allowed? I've checked the mapping guidelines, and i read something about a max of 2100 w_polys, but what is the actual limit of e_polys and w_polys? Is the max of 2100 both "e" and "w", or either, or a different value for each? What'll it be?
2) Ns models; what's their sizes? I've looked all around, but i just can't seem to find it. I need some values like:
Dimensions of the following models: Onos, skulk, lerk, fade, fade-crouch marine, marine-crouch and gorge. As well as the structures and stuff like jump height, duck-jump height etc.
Is there some kind of list somewhere? I haven't found anything so far in the mapping forum.
3) Lighting; how do i make proper lighting, when i create a light over a "light" texture, it looks weird, the texture doesn't seem to glow, it doesn't seem to create the light. Do we use "spotlights" for that? (how are they "aimed"?)
4) Do's and Dont's - I've already found quite some in the mapping guidelines, but I'm wondering if there's any specific changes since it's been updated, or just general things i should or should not do?
Keep in mind I'm working on co_ atm, starting out small, when it's done and working well, i might take on the greater task of a ns_ map. Thanks in advance!
EDIT: Oh, and i just remembered, any tutorial sites are welcome, I've tried some in the guidelines, but the links seem to be broken and outdated. Know any good sites/links? Post here!
However, I'm practicing again and wish to create a combat map to start with. I need information.
I've sent Merkaba a PM with some of these questions (I've talked to him about mapping before) but he probably has other things to do anyway, and I've gotten more questions since.
1) r_speeds; what is allowed? I've checked the mapping guidelines, and i read something about a max of 2100 w_polys, but what is the actual limit of e_polys and w_polys? Is the max of 2100 both "e" and "w", or either, or a different value for each? What'll it be?
2) Ns models; what's their sizes? I've looked all around, but i just can't seem to find it. I need some values like:
Dimensions of the following models: Onos, skulk, lerk, fade, fade-crouch marine, marine-crouch and gorge. As well as the structures and stuff like jump height, duck-jump height etc.
Is there some kind of list somewhere? I haven't found anything so far in the mapping forum.
3) Lighting; how do i make proper lighting, when i create a light over a "light" texture, it looks weird, the texture doesn't seem to glow, it doesn't seem to create the light. Do we use "spotlights" for that? (how are they "aimed"?)
4) Do's and Dont's - I've already found quite some in the mapping guidelines, but I'm wondering if there's any specific changes since it's been updated, or just general things i should or should not do?
Keep in mind I'm working on co_ atm, starting out small, when it's done and working well, i might take on the greater task of a ns_ map. Thanks in advance!
EDIT: Oh, and i just remembered, any tutorial sites are welcome, I've tried some in the guidelines, but the links seem to be broken and outdated. Know any good sites/links? Post here!
Comments
as for r_speeds: you need to concern about w_polys, ingame they should be below 700, for the commander below 1000 or 1200 (not sure)
Model size:
32 32 72 Marine/Fade/Crouched Onos
64 64 108 Onos
32 32 36 Crouched Marine/Crouched Fade/Skulk/Gorge/Lerk
Lightning: Try some tutorials, look at other maps... It requires experience and talent to do good lightning
But I guess you already read that...<!--coloro:#666666--><span style="color:#666666"><!--/coloro--> >cricket noice< ... runs off...<!--colorc--></span><!--/colorc-->
Thanks for the info bERT0r, that sure helped, gonna take a look at that site.
And a subsequent question, if we only need to worry about w_polys, what's up with the e_polys then? Do they not cause any strain on computers? Is there some site that explains what exactly these polys are and how half life handles them? Although I've got a general idea of what they are, the better i understand things, the easier i work with 'em.
Currently I'm creating a practice map, using about every entity i can find, just so i know what i can use and how things work. Gonna do a train using a multimanager today ^_^ - wish me luck!
e_polys are polygons used for models, like the lmg you hold in your hand, the in-game built structures, the players etc...
I recommend reading some r_speeds articles, they will help you a lot. You need to understand the mechanism of the engine to make beautiful but also well performing maps.
Basically, the amount of polys (measured in tetrahedrons/tris?) a computer has to calculate and render according to where you are looking. Occasionally Hammer will decide to render more than it needs to (i.e. world brushes that are not in view). If this is happening you can try to use HINT brushes to remedy the situation, but there's a particular method to using them well that is lost on most (although there are some good tutorials about for this).
<b>e_polys = <i>entity polygons</i></b> (IIRC)
Basically, the same as w_polys but for entities. Entities include res nodes, <strike>moving doors, buttons,</strike> worldmodels (a.k.a. <i>props</i> these days), <strike>breakables, see-through glass, and pretty much any other brush-based entities</strike>. (Cut the crap, Crispy <img src="style_emoticons/<#EMO_DIR#>/tounge.gif" style="vertical-align:middle" emoid=":p" border="0" alt="tounge.gif" />)
I found a link to what looks to be an old version of the OMGs, but most of the vital info is there.
<a href="http://www.unknownworlds.com/uwe/static/portfolio/web/Mapping_Guidelines.html" target="_blank">http://www.unknownworlds.com/uwe/static/po...Guidelines.html</a>
For models you can use the entity boxes to give you a rough indication of dimensions, etc. but as for the crouch height, etc., it's a case of trial and error in the editor itself unless there's some uber-list nobody's told me about.
Studio models use e-polys. They're modelled in 3D Studio Max or (more commonly these days) Milkshape3D. They're vertex-lit.
Sprites (".spr", including the NS particle system) don't have their own number but are included in the overall r_speed figure.
<b>w_polys = <i>world polygons</i></b>
Basically, the amount of polys (measures in tetrahedrons/tris?) a computer has to calculate and render according to where you are looking. Occasionally Hammer will decide to render more than it needs to (i.e. world brushes that are not in view). If this is happening you can try to use HINT brushes to remedy the situation, but there's a particular method to using them well that is lost on most (although there are some good tutorials about for this).
<b>e_polys = <i>entity polygons</i></b> (IIRC)
Basically, the same as w_polys but for entities. Entities include res nodes, moving doors, buttons, worldmodels (a.k.a. <i>props</i> these days), breakables, see-through glass, and pretty much any other brush-based entities.
I found a link to what looks to be an old version of the OMGs, but most of the vital info is there.
<a href="http://www.unknownworlds.com/uwe/static/portfolio/web/Mapping_Guidelines.html" target="_blank">http://www.unknownworlds.com/uwe/static/po...Guidelines.html</a>
For models you can use the entity boxes to give you a rough indication of dimensions, etc. but as for the crouch height, etc., it's a case of trial and error in the editor itself unless there's some uber-list nobody's told me about.
<!--QuoteEnd--></div><!--QuoteEEnd-->
Thanks for the elaborate info <img src="style_emoticons/<#EMO_DIR#>/smile-fix.gif" style="vertical-align:middle" emoid=":)" border="0" alt="smile-fix.gif" /> for the guidelines, try this one:
<a href="http://www.unknownworlds.com/ns/static/Mapping_Guidelines.html" target="_blank">http://www.unknownworlds.com/ns/static/Map...Guidelines.html</a> <-- UWE site --> NS --> Game Info --> Mapping --> Guidelines
I think i get the point. Does this also mean that the more faces an object has the more w_polys? Say a cube, 64x64, if you cut it in half, ending up with two parts of 32x64, does the latter result in higher w_polys?
(Theoretically, i can imagine that this will have hardly/no effect practically, but in larger numbers)
Going strong with my practice map <img src="style_emoticons/<#EMO_DIR#>/tounge.gif" style="vertical-align:middle" emoid=":p" border="0" alt="tounge.gif" /> I'll post it here for fun once I'm satisfied <img src="style_emoticons/<#EMO_DIR#>/biggrin-fix.gif" style="vertical-align:middle" emoid=":D" border="0" alt="biggrin-fix.gif" />
I think i get the point. Does this also mean that the more faces an object has the more w_polys? Say a cube, 64x64, if you cut it in half, ending up with two parts of 32x64, does the latter result in higher w_polys?
<!--QuoteEnd--></div><!--QuoteEEnd-->Yes, but at the same time, if you had them sitting one on top of the other you could texture the two adjoining (and unseen) faces with a 'null' texture. It wouldn't cut down on the r_speeds, but it would optimise it in terms of textures. You might wonder why you would ever want to do that, one example would be if you wanted to have a wall divided up into a top and bottom section purely for stylistic reasons, using one texture along the top half and another along the bottom.
(is it called a 'null' texture? - been a while since I opened up Hammer tbh, hence the BS I was chanting about e_polys for brush-based textures! I still remember some stuff, though! <img src="style_emoticons/<#EMO_DIR#>/tounge.gif" style="vertical-align:middle" emoid=":p" border="0" alt="tounge.gif" />)
As I'm working on the testproject i find new problems and things i don't know; hence, more questions!
- I find that light emitting textures look much better than light textures with a light entity in front of them. Problem is, i don't know how to manipulate light emitting textures in any way. I can't turn 'em on or off, nor change color/brightness/style. Is there a way? And, how can i make my own LET's?
- Skybox, i've created one, and it displays correctly. But, i want another texture. Also, the lighting seems a bit odd, i want it to be as if it's night, how do i set the lighting correctly?
- light_env doesn't do jack shiet, how do i use that?
- env_gamma doesn't do anything either, how do i use it?
Errors:
- I had a bunch of Solid Entity "xxx" is empty, when i clicked "repair" or "repair all", nothing would happen in VHE, i have removed them all manually, but why oh why couldn't the editor do that tedious job for me?
- When i compile the map, everything works fine, though i did notice something strange in the compile log:
<!--quoteo--><div class='quotetop'>QUOTE</div><div class='quotemain'><!--quotec-->Warning: Too many light styles on a face(-384.000000,-631.990479,-568.003174)<!--QuoteEnd--></div><!--QuoteEEnd-->
I tried finding the face by using those numbers as coordinates, but i couldn't find anything. I have also been unable to find any documentary on this problem, even in the common trouble thread:
<a href="http://www.unknownworlds.com/forums/index.php?s=1132772139039041792&showtopic=55406" target="_blank">http://www.unknownworlds.com/forums/index....showtopic=55406</a>
So, who's in to give me some more knowledge!? (Thanks in advance, much appreciated! <img src="style_emoticons/<#EMO_DIR#>/wink-fix.gif" style="vertical-align:middle" emoid=";)" border="0" alt="wink-fix.gif" /> )
lighting of you skybox depends on you env_gamma, if you set this to 1.5 for example you can use photoshop to use a level layer to see it correctly like you would ingame (more info about this in the mapping faq)
A map only needs one light_env (the sun), just place it near any skybrush to make all other skybrushes in the map cast the same light style. It works exacly like a light_spot in terms of setting up up
env_gamma can be set to 1.5 for example ingame it will then make the game have more contrast.
error, I had a bunch of Solid Entity "xxx" is empty -->
If you're using Hammer, just select it from the list in the error check then close the error check popup and simply press delete. This works because once you select it from the list you actually select it in the editor. Only possible way to select and delete it btw, since it's not containing any brushes but is still in the entity list. Resulting in an error
Warning: Too many light styles on a face(-384.000000,-631.990479,-568.003174) usually means you have to many differant dynamic lights in one area (dynamic = anything else then Normal in the Appearance option of lights)
textured lights might look nice, but I prefer not one but four stacked together in front of monitors for example. This way you don't have to use overlays (func_illusionary) and safe runtime entities that way. imho this technique looks better then textured lights on small surfaces (monitors/computer textures)
<!--QuoteEnd--></div><!--QuoteEEnd--> I don't understand this part... what do you mean by stacking four together in front of monitors?
<!--quoteo(post=1577555:date=Nov 15 2006, 04:09 PM:name=Kouji_San)--><div class='quotetop'>QUOTE(Kouji_San @ Nov 15 2006, 04:09 PM) [snapback]1577555[/snapback]</div><div class='quotemain'><!--quotec-->lighting of you skybox depends on you env_gamma, if you set this to 1.5 for example you can use photoshop to use a level layer to see it correctly like you would ingame (more info about this in the mapping faq)
A map only needs one light_env (the sun), just place it near any skybrush to make all other skybrushes in the map cast the same light style. It works exacly like a light_spot in terms of setting up up
env_gamma can be set to 1.5 for example ingame it will then make the game have more contrast.
<!--QuoteEnd--></div><!--QuoteEEnd--> I'll check the mapping FAQ again then, i must have missed that. I don't understand the part about photoshop here, either. Also, the light_env; I haven't gotten to using light_spot's yet. Am i thinking along the right lines if i need a info_target and then have the light_spot "target" the info_target? Or must i use Pitch/Yaw? Also, if i were to set it to a pretty low darkness, would i be able to simulate "moonlight"?
<!--quoteo(post=1577555:date=Nov 15 2006, 04:09 PM:name=Kouji_San)--><div class='quotetop'>QUOTE(Kouji_San @ Nov 15 2006, 04:09 PM) [snapback]1577555[/snapback]</div><div class='quotemain'><!--quotec-->
error, I had a bunch of Solid Entity "xxx" is empty -->
If you're using Hammer, just select it from the list in the error check then close the error check popup and simply press delete. This works because once you select it from the list you actually select it in the editor. Only possible way to select and delete it btw, since it's not containing any brushes but is still in the entity list. Resulting in an error
<!--QuoteEnd--></div><!--QuoteEEnd--> What i've done this time is go through all of my entities in the entity report, and select them one by one to see if they point to a brush. I deleted the once that did not. (This took a bit of time) But i think that your technique takes even more time, since i'm gonna have to open up and close the error report window every time. Also, can you tell me how these things are caused/prevented?
<!--quoteo(post=1577555:date=Nov 15 2006, 04:09 PM:name=Kouji_San)--><div class='quotetop'>QUOTE(Kouji_San @ Nov 15 2006, 04:09 PM) [snapback]1577555[/snapback]</div><div class='quotemain'><!--quotec-->
Warning: Too many light styles on a face(-384.000000,-631.990479,-568.003174) usually means you have to many differant dynamic lights in one area (dynamic = anything else then Normal in the Appearance option of lights)
<!--QuoteEnd--></div><!--QuoteEEnd-->
Say, if i were to have 10 lights in a single room (theoretically), which all had the same light style, but not normal (slow pulse, noblack). Would this mean the surface has 10 different lightstyles on it?
Why i'm asking this; i've only got three light styles in use at this moment (as far as i know) and they're all quite far apart in the map. Though i could imagine some abnormalities concerning the light textures, i've seen some strange things happening to them.
For one, the light textures i used didn't glow. Once i put a "light" entity in front of them, they started glowing by themselves! After i had deleted the light, they would still glow.. Very odd imo.
Can i find some more info on light textures, and that other technique you described? I'm obviously too much in the dark about this here (hehe...), maybe a tutorial on how to make/edit/use them - would be great.
Thanks!
<b><u>Env_gamma</b></u> is a gamma ramp. That means that basically, if you dont have an env_gamma, it is set to 1. You set it at 1.5 (most maps have it at 1.7 which for whatever reason shows up in NS with dev mode on as 1.615 or something), because it gives everything more contrast. Lighter spots are lighter, darker spots are darker. Its awesome. If you go too high (or certain lights are too bright), they really start washing out and looking horrible, even painful to look directly at. To test it in-game, first put cheats on (sv_cheats 1), then dev mode (developer 1), then load up a map, ns_veil say.
Bind a key to 'setgamma 1.0', then another to 'setgamma 1.5', then another to 'setgamma 1.7'. Hit them as much as you want, and you'll see the world whip in and out of contrast all around you.
<b><u>As for moving and aiming spotlights or light_env's</b></u>, never, ever use an info_target. Instead, use the top-right circle to aim the spotlight from the top-down view, THEN USE THE 'PITCH' FIELD, ONLY. There are like 4 places or something where you can put in a value for pitch, ONLY use the solo 'pitch' field. I cant remember how it orients it specifically, but you can play with it. If the circle is you holding a flashlight straight out and spinning, the pitch is how far up or down you're aiming the flashlight, in degrees.
Yes, you can simulate moonlight. <b><u>Mapping in an art</b></u>. Lets see your take on moonlight.
That <b><u>empty Entity error</b></u> occurs when you do stuff like take two func_illusionaries (say two brushes that form a corner of a railing), hit Ctrl-T (turn into an entity, or toEntity), and then it asks you which entity you want to keep. You choose one of them. The other one is suddenly empty. Gotta find and select it from the Entity Report, then delete it. Seems, in all my attempts, that the Check For Problems thing will tell you about empty entities but doesn't seem to actually delete them when you hit 'fix'.
<b><u>The 'too many lightstyles' is simple.</b></u> More than four dynamic lights are hitting a surface. If you dont think they should be, turn on -nodynbounce, or lower your bounces (ask if you dont understand this). Its likely that they're bouncing right around the corners and meeting somewhere between, tricky f***ers. But yeah, any light that does anything special (glows, turns on/off, has an info_target) is considered a dynamic.
<b><u>Light textures</b></u> are another thing. You can have as many as you want, you'll pretty much never hit the lightdata limit... since there really is none. You can make it a lot bigger if you want, but this is directly added to the map filesize (and can make it unstable), so you dont really want to.
BUT.. textures are only 'texture lights' if they're in the <b><u>light.rad</b></u> in your Valve Hammer Editor/tools/ folder. Its a pretty simple file, you'll end up having a sexy personalized one by the time you're totally comfortable with it. Just find the texture name (or put it in if its not there), then find the colour and brightness (i just create a new light, find the perfect colour in the Palette thingy, copy it over and then delete the light). Voila, that texture now emits light.
Watch out with those though. Avoid full colours, e.g. 0 255 0 (thats pure red or pure green or something). If its pure green like that and the texture is relatively green, it's going to be absolutely washed out and look like balls. Putting it to even 10 255 10 will make it look drastically better.
/needs a drink
PM me or just reply if you want to dispute anything i say, or ask any questions <img src="style_emoticons/<#EMO_DIR#>/smile-fix.gif" style="vertical-align:middle" emoid=":)" border="0" alt="smile-fix.gif" />
Env_gamma: I get it, nothing more to be said, much appreciated.
light_environment: I'll play with it a bit, i *think* i understand. Be prepared to see moonlight next week tounge.gif
Empty entity: Good! Now i know what i did, i sometimes merged func_wall's... Great thing to know, next time I'll do "To world" before i merge them. Good info, should post that at the common bug thread as a "fix", though it's really a precaution.
Too many lightstyles: Do lasers count as lightstyles? If so, that might be one of the causes. About this error, how bad is it? What does it cause...? I've noticed the error in the compile log, but haven't really found any problems. No insanely high r_speeds, nor strangely looking surfaces.
I've never heard of "-nodynbounce" yet. Can you give me some more info? (about the bounces too, i understand the principal, light reflects off surfaces, but i can't directly tell how it affects HL editing.)
Light Textures: Hmm, sounds good, though i'm gonna need a bit more info. I understand the part where you select the color using a "light". What i want to know: When i edit light.rad, how does that affect compiling maps? Are maps compiled using that lightdata, thus running and looking the same on every machine? Also, is every single texture in that file? (gonna have to check that when i get home, maybe) When i add new wad's to my map/editor, will they automatically be added to lights.rad? I think i can work with this, it's looking good so far.
--- NEW QUESTION ---
Texture Files (WAD's): Okay, so right now, i'm using like 5 wad files in my editor: ns.wad, ns2.wad, halflife.wad (Extracted from the halflife gcf, used for origin texture etc.), zhlt.wad and ns_hera.wad.
Lets presume i choose a few textures i want to use, might extract them from existing ns wads, or halflife.wad, what ever. Would it be a problem if i created my own .wad file and use only that? (Including the zhlt wad files for compiling, and the origin and pink valve logo texture for the mapping process) I've got some basic knowledge about using wally, i'm sure i can learn how to make my own wads, but is that good, or should i try and stick to using the wads present in NS originally? I'd love as much info on this as possible, since it's pretty important.
(P.S. Does anyone have a list of "-commands" i can use? There's like, so many... I've got sv_cheats and devmode on by default for testing, but what are the possibilities, concerning mapping)
EDIT: Addition, i tried light_environment, but can't get it working. Mind making a little map as a tutorial, so i can learn from it?
<img src="style_emoticons/<#EMO_DIR#>/asrifle.gif" style="vertical-align:middle" emoid="::asrifle::" border="0" alt="asrifle.gif" /> <img src="style_emoticons/<#EMO_DIR#>/tiny.gif" style="vertical-align:middle" emoid="::onos::" border="0" alt="tiny.gif" /> <img src="style_emoticons/<#EMO_DIR#>/tounge.gif" style="vertical-align:middle" emoid=":p" border="0" alt="tounge.gif" />
'too many lightstyles' is very bad. It messes with your compile and can do some pretty whack stuff. It tells you exactly where this is happening in the compile log, so go find that coordinate and try to figure it out. I think it even goes so far as to be a cause of the alloc_block:full error.
'-nodynbounce' means simply No Dynamic Bounce. The default for bounces is 1, i believe. So every light shines from its origin, hits whatever, then bounces once more. If you want to light up areas a lot more 'naturally', you can up the bounces (Max uses 10 sometimes even), but it WILL light up your shadows significantly. I use bounce 2. What nodynbounce does though, is that any dynamic light simply doesnt bounce. If you make a spotlight that strobes, it'll strobe and loook pretty hot, but the light wont be noticeable on the nearby surfaces (which can look cool, but isnt totally necessary, and can really up your lightdata). Its an easy fix for that error or for high lightdatas, and frankly isnt noticeable.
Light Textures: You can make your own light.rad from scratch if you want. Just make a .txt, rename it to lights.rad, and put in what you want. It is NOT affected whatsoever by client's own rad files, because they dont even have any. Its only for *YOUR* compiler, and it determines how the lights come out. When Max and i were doing hundreds of test compiles with Nexus, he had a much different rad file than mine, and its very, very surprising how much lighting can affect a map.
So yeah, every machine will see the same end result. And no, not every texture is in there, you have to add in whatever you want. If your rad already has a lot of texture names in there, you might find a few in-game that you dont want (so just delete those names), and definitely a few that you'll want to add or tinker with. If you add new wads or custom textures or whatever, just verify if they're in there, and add them in if you need to.
WADS: You can create your own wad if you'd like, absolutely. Just remember that people will need the same wad, and hence will have to download it. No worries, simply means you'll have to include a .res file with the package you make available (they are REALLY EASY to make, just check any of the .res' in the ns/maps/ folder to see what i mean. they just list the files required and their paths, like the minimaps).
Another option is to have custom textures zipped into the bsp itself. Its a command option, that doesnt always seem to work, but does sometimes <img src="style_emoticons/<#EMO_DIR#>/tounge.gif" style="vertical-align:middle" emoid=":p" border="0" alt="tounge.gif" />. Maybe im doing it wrong.
With Nexus, i just used hl, ns, and ns2 textures. Ive had a few complaints that, with such a crazy new map, i should've used a custom set. I think for my next version, i'll simply 'find/replace' a few of the more noticeably veil-esque textures with sexy custom ones, and then have those included in the bsp. But its your choice.
If its one of your first maps (and you're not planning on taking over a year to make your masterpiece, like me <img src="style_emoticons/<#EMO_DIR#>/tounge.gif" style="vertical-align:middle" emoid=":p" border="0" alt="tounge.gif" />) its probably worth sticking to the basics. All that extra time on custom stuff means nothing if the map itself isnt fun or doesnt get played. There are some really quality textures in the NS set, just try to use them in ways people havn't seen yet, and hence wont recognize. It does sound like you know what you're doing with Wally and all, so heck, custom it up if you want to <img src="style_emoticons/<#EMO_DIR#>/biggrin-fix.gif" style="vertical-align:middle" emoid=":D" border="0" alt="biggrin-fix.gif" />.
As for the commands, the biggies are:
-sv_cheats 1 (this also starts a round, letting you test runtimes using the in-game timer)
-developer 1 (this shows all the dev info. You're now a dev. Try having it on and loading a map)
-numents (needs dev 1, tells you the number of runtime entities in the map. Recommended is below 200, but the limit in the guidelines is under 300. Affects the stability of the map, especially with larger servers or excessive turret farming, etc)
-r_speeds 1 (with dev 1 on, you'll see a constant update of the current r_speeds at the top of the screen. Great for determining where you need to optimize. I have this bound to Home and End, on and off.)
-gl_wireframe 2 (bind this to a key, like Insert or something, then Delete as gl_wireframe 0. This shows whats being drawn from wherever you are, so you often see things way around corners and whatnot. Also shows how r_speeds are actually found. Helps with the placement of Hints)
-noclip (lets you fly through walls, a good option when you have weldables a distance away from their target, etc)
-givepoints (give you res)
-bigdig (needs cheats, but everything insta-builds, so if you start a round on a testmap, you can tech to PGs in about 3 seconds and have pgs up anywhere you want, very quickly)
-spawnhive (spawns a hive in a random hive loc)
-setgamma 1.0 or 1.5 etc (useful for determining what you want you env_gamma set at)
**** LINKS
The entire list of commands for compiling, and many other things about compiling, can be found <a href="http://www.zhlt.info/index.html" target="_blank"><u>here</u></a>
A stupidly large list of errors and their possible solutions can be found <a href="http://www.frankclan.ca/maps/map_resources/mirrored/errors.shtml#leafsaw" target="_blank"><u>here</u></a>.
A decent list of tutorials can be found <a href="http://twhl.co.za/tutorialbrowse.php?tuttype=1" target="_blank"><u>here</u></a>.
If you want to learn about Hints but want to skip ahead to the best way of doing them, all you need is the <a href="http://home.comcast.net/~ninjagrinch/pyramidhint.htm" target="_blank"><u>tutorial on pyramid hints</u></a>.
/needs another drink
<img src="style_emoticons/<#EMO_DIR#>/biggrin-fix.gif" style="vertical-align:middle" emoid=":D" border="0" alt="biggrin-fix.gif" />
This is what I mean when stacking 4 light entities in front of a monitor, imho it looks better then using textured lights since textured lighting usually lights up the edges of the screen as wel. And using overlays looks worse if ya ask me. Plus the fact you're using valueable runtime entities with overlays, which could be used for more usefull/nicer things like particle systems, welding, doors, glass, breakables, sounds etc... Resulting in a more interactive map with perhaps more tactics and atmosphere
Mind you in some cases it is better to use texture lighting for example when the lighttexture is a complete light without metal edges in it. Or simply work arround it with brushwork (off and on texture with the on texture emiting the light)
[edit]
more work, but it will pay you back if you're adament about it, oh and ignore the foolishness of me with that lightbug. I just didn't feel like uploading another image when this one has the example in it as well <img src="style_emoticons/<#EMO_DIR#>/tounge.gif" style="vertical-align:middle" emoid=":p" border="0" alt="tounge.gif" />
[edit2]
btw when deleting that empty entity, my way is not slower or more work its actyally faster <img src="style_emoticons/<#EMO_DIR#>/tounge.gif" style="vertical-align:middle" emoid=":p" border="0" alt="tounge.gif" /> since you only have the error in the list. When you use the entity list you have to go and test each and every entity you have in the map...
<b><u>light_environment</u></b>: Can't get it to work.. really just can't. Is there some brightness setting i'm overlooking? Also, it doesn't have any flags, so i don't know what you're talking about there.
<b><u>Too many lightstyles</u></b>: Were caused by lasers, guess those can't be used in fancy ways without causing errors.
<u><b>-nodynbounce</b></u>: Okay, so we don't use nodynbounce for finished maps, having it set to two sounds good, what's the command for that, added in compile? (dynbounce 2 ?)
<b><u>Light Textures</u></b>: I understand this one, though i don't understand how to use an overlay. (func_illusionary?) It looks bad to have normal textures emit light, for the reason kouji_san states, the borders glow too. So, if i were to create my own overlay textures to light up (only the real light source), how do i use them? I tried a func_illusionary, where the part that should not have litten up was black, it lit up right, but you couldn't see through the black, which looked bad ofcourse. I've also tried making it a func_wall, having the black be full blue (solid, 255) But that didn't work either. Help?
<b><u>Wads</u></b>: Figured it out, it appears that Natural Selection can use textures in halflife.wad at any time, although halflife.wad is not in the ns folder. I presume this is because ns runs in halflife. But i understand this part now too, i've already made a few small custom textures to play with. However, i have not yet found out how i can compile a wad into my map, can you explain? Also, if i were to use custom sprites/models, can they be compiled into the map as well? And what are the pro's/con's about that?
This isn't exactly my first map, yet. It's just a test-project, in which i attempt to master all the different skills used while making a map. So far i've created one nice looking hallway, a working 2-piece door, a working elevator, a working 4-piece door that opens in all directions, a 4-piece bay door with glass in it, a 2-piece door with glass, and a train. Beside that some average architecture, ladders, see-through solids (grating), glass, and i'm working on outside terrain, realistically made using the triangle technique. (looking pretty damn good! I'll post a sample of all this some time soon, it's just a test thingie anyway. Not playable though, can only run around a bit <img src="style_emoticons/<#EMO_DIR#>/biggrin-fix.gif" style="vertical-align:middle" emoid=":D" border="0" alt="biggrin-fix.gif" /> When i feel i know enough to build a decent map i'm gonna start on a co map, named "Existenz" - i've started on ns_existenz about a year and a half ago, but stopped when i encountered a bug i couldn't fix. I lost the source somewhere in a HDD crash, but no bother, i didn't know anything about r_speeds and any of the bugs back then, it would have probably been a horrible map.
Also, i'm trying to learn how hint brushes work, i've got one working correctly in the testmap atm, but i don't quite get it yet, they often don't work as i had expected. They're difficult to use with more advanced architecture.
Kouji_san, i now understand your stacking thing, doesn't that use too many lights eventually?
*** New question ***
<b><u>func_train</b></u>: I've got a working func_train, following waypoints and all, but there's one thing that doesn't work as intended. When it follows the path, it doesn't rotate through corners, it keeps the same facing. This doesn't look very realistic, and i'd like it to rotate in corners, always having the nose of the entity face the direction it's going in. How can i make this? I haven't found any flags, or other ways of doing this. Help please <img src="style_emoticons/<#EMO_DIR#>/smile-fix.gif" style="vertical-align:middle" emoid=":)" border="0" alt="smile-fix.gif" />
Thanks again!
- Still at it...
Too Many Lightstyles: Odd. I have a laser as well (im assuming you mean an env_beam), and it doesnt seem to affect lighting whatsoever.
-nodynbounce can absolutely be used for finished maps. Its simply whether dynamic lights have their light bounce or not. You dont set it to a certain number, its either not there (so you dont have '-nodynbounce'), or its there (as '-nodynbounce').
E.G: hlrad.exe -extra -bounce 2 -nodynbounce
This would turn on the Extra setting (used for final compiles, makes it look nicer but takes longer), it would make all lights bounce twice, but it would make dynamic lights not bounce at all.
Hints: Yeah, they're tricky, and best used in 90-degree turns with hallways that are fairly square. You can still cut into architecture, i think it only really ups the r_speeds a tad as well as the compile time.
For the stacking lights idea, there arent 'too many ligths', theres simply the limit of the amount of lightdata. If lights are tiny like that, they only affect a small area, and therefore produce a small amount of lightdata. Its actually a decent concept, i might use them in the next version of Nexus.
Func_Train: I think the actual waypoint nodes (cant remember what they're called) are the entities that have a field saying to rotate this way or that, speed up this much or whatever.
light_env: remember that the 4th number is the brightness. So 25 25 25 0 would be some colour of light, with absolutely no brightness. Aside from that im guessing its the direction.
Too Many Lightstyles: Odd. I have a laser as well (im assuming you mean an env_beam), and it doesnt seem to affect lighting whatsoever.
-nodynbounce can absolutely be used for finished maps. Its simply whether dynamic lights have their light bounce or not. You dont set it to a certain number, its either not there (so you dont have '-nodynbounce'), or its there (as '-nodynbounce').
E.G: hlrad.exe -extra -bounce 2 -nodynbounce
This would turn on the Extra setting (used for final compiles, makes it look nicer but takes longer), it would make all lights bounce twice, but it would make dynamic lights not bounce at all.
Hints: Yeah, they're tricky, and best used in 90-degree turns with hallways that are fairly square. You can still cut into architecture, i think it only really ups the r_speeds a tad as well as the compile time.
For the stacking lights idea, there arent 'too many ligths', theres simply the limit of the amount of lightdata. If lights are tiny like that, they only affect a small area, and therefore produce a small amount of lightdata. Its actually a decent concept, i might use them in the next version of Nexus.
Func_Train: I think the actual waypoint nodes (cant remember what they're called) are the entities that have a field saying to rotate this way or that, speed up this much or whatever.
<!--QuoteEnd--></div><!--QuoteEEnd-->
- Can't get the light_env to work, brightness is not the problem. I'll try a light_spot with "is sky" instead.
- I was using a env_laser as.. laser! Maybe there's the problem. I'll try the beams.
- Ah okay, i thought nodynbounce was the same as that bounce. But i'll try it out, sounds good.
- Hints, i guess they just take lots of practice.
- Ah right, the radius matters alot, good call.
- Func_train, i tried those values, but they don't seem to do much. Does anyone have any idea how exactly it works, or a tutorial map on that? I can find basic "train" tutorials, but that's nothing new to me.
*** New Question ***
Say i've got this train, and a bay door, and a button. (which i do) I've got a multimanager having the door open first, then move the train, then close the door again. What i want it to do, next, is to turn off the button, so it can't be activated again, until the train is back. How can i do this? The turning off of the button is important for this to work.
I am going to have to look into that entity issue a bit more before i start my real map though, I'm not sure which entities do and do not count towards the total maximum. I'll be fine.
Does anyone have a clue as to any of the points described in my previous post?
<a href="http://www.unknownworlds.com/ns/static/Mapping_Guidelines.html#Appendix_B__Runtime_Entities" target="_blank">http://www.unknownworlds.com/ns/static/Map...untime_Entities</a>
A total of 275 runtime entities is the current maximum for 3.0
- The func_train, i didn't get that answered well enough yet, how can i make the nose face the direction it's going in?
- Unit run/walk speeds, where can i find some sort of list of speeds? (marines go at around 200 i think?)
- r_speeds, so we've got to keep the w_polys under 700 eh, i've been checking some, and for instance ns_origin, one of my favourite maps, has parts where w_polys exceed 1100! Even marine start and the hives are around 800 w_polys. What's up with this?
- func_illusionary, i'm using this for texture overlays when textures need some lighting on them. Okay, fun, nice etc, but what if i don't want it to be that bright, i can't change anything about this in the entity properties, is there a way to change it? (some things just glow too brightly)
- nodynbounce / bounce 2, i can't exactly find where i can set this, i've tried several places in the compile options, but i didn't get it to work. Can you show me something like a screenshot, or give some more specific directions? Much appreciated!
<a href=\"http://collective.valve-erc.com/index.php?go=avelocity\" target=\"_blank\">http://collective.valve-erc.com/index.php?go=avelocity</a>
explains all really <img src="style_emoticons/<#EMO_DIR#>/tounge.gif" style="vertical-align:middle" emoid=":p" border="0" alt="tounge.gif" /></li><li>no idea on walk speeds of units. Maybe theres something on the competative forum about this?</li><li>r_speeds 700 1st person, 1000 commander view (I say ~800 1st person and ~1100 commander view is acceptable, since current machines can handle it and so can gold source if ya ask me <img src="style_emoticons/<#EMO_DIR#>/tounge.gif" style="vertical-align:middle" emoid=":p" border="0" alt="tounge.gif" />)</li><li>func_illusionary lighting kind of works like this. You set the color and brighness in the rad file you're using for textured lights (in this case the overlay texture for a specific light texture). Then you can set the following to control the look of it:
- additive
- fxamount: 255 for a real bright look and perhaps arround 100-150 for a haze light effect (which doesn't look that good imho)
Another thing you can have a look at is the old ns map from ns 1.04. Hera for example has beatifull lights which kind of looks like a not dynamic HDR effect. WARNING: this will eat up runtime entities quickly if you're not carefull <img src="style_emoticons/<#EMO_DIR#>/biggrin-fix.gif" style="vertical-align:middle" emoid=":D" border="0" alt="biggrin-fix.gif" />
<a href=\"http://www.brywright.co.uk/ns/steam104.php\" target=\"_blank\">http://www.brywright.co.uk/ns/steam104.php</a></li><li>nodynbounce is just a parameter you add at the rad compile process. This will the disable bouncing of dynamic lights. Decreasing the lightdata significantly if you have lots of them. Bouncing lights just lights up the map more. if you use no bounce the map is at default level of lighting. if you use 2 the light will be bounced twice, making shadows more natural and bright areas brighter (overall smoother/brighter lighting)
The "additional" parameter to add is:
-nodynbounce
-bounce #
I also use -chart to keep track of the engine resources used
Dunno if you're already using it, but you might want to have a look at the batch compiler
<a href=\"http://nemesis.thewavelength.net/index.php?c=32&o=30\" target=\"_blank\">http://nemesis.thewavelength.net/index.php?c=32&o=30</a></li></ul>
I'll have a go on that train tutorial. Does the ns.fgd support it? If not, if i were to edit my ns.fgd; would that only change compiling, or is the file used by NS itself?
I'll look around for the run speeds, though i've got decent estimates.
Commander r_speeds; coming to think of it, i haven't tried commander mode in my testmap yet, when i type "startcommandermode" in console (Dev on, cheats on), the game locks up. I've got a info_mapinfo set, anything else i should know/do before i can check commandermode? Thanks for the info btw, i'll keep the r_speeds around that.
About the func_illusionary, i'm using an altered .fgd file to include an "info_texlights" entity. I specify lights.rad there; it doesn't seem to look that good, using additive and texlights. Also, when i adjust the renderfx, between 0-255, it doesn't change anything. What i'm trying to do is have the texlights be less bright, the textures themselves, not the light they emit. I haven't found a way of doing this though, might try using darker colors in the fx_overlay wad. (made that myself with wally)
Also, i tried the compiler, it seems to be a decent tool, but why use that over hammer's compile function? Also, it seems to have a problem with my folders, gonna have to put all the important folders like the compile tools and source stuff in c:\, it can't find certain files. - Not working too well. Ever had that?
Finally, i took a look at the guidelines again; concerning entities. When i use "nument" ingame, it names many entities, which ones can i discard there? Do lights count? They seem to be counted with "numents". The guidelines aren't very specific about this, what command should i believe?
1 x info_player_start
1 x team_hive
1 x info_team_start (team2)
1 x team_command
1 x info_team_start (team1)
info_mapinfo
info_gameplay
env_gamma (if I'm doing light tests)
info_texlights is not my piece of pie, never actually used it ^_^
Batchcompiler is a nice tool if you like to compile and during the compile work on something in the currently open hammer. And it's nice to actually see the compile tools do something with it's command promt and constat stream of updates. Not like hammer -> once in a while an update to see how far along the compilers are. And it's faster to change a few compile things in bc imho... That's actually all there is, it does the same job, but it's nicer <img src="style_emoticons/<#EMO_DIR#>/tounge.gif" style="vertical-align:middle" emoid=":p" border="0" alt="tounge.gif" />
Some might say it will compile faster because hammer is not eating away at mem, but if you still have hammer open to work on shizzle I think it's actually slower. An open Hammer (map editor in general) is just waiting to be used!
About the trouble you're having, perhaps take a look in the "options --> setup --> tab: paths?
numents should work if you're starting into ns with a shortcut with these parameters:
-dev +map "yourmaphere"
Light only count when you give them a name, btw it's all in the ns mapping guide. trust me. it even has a list of which entities it will exclude from runtime...
I've got a new question. I want to be able to "turn off" certain entities, but they're not lights. I'm trying to make a train that goes a certain track, but is able to go back the same way. You would expect this to be simple, i just make two sets of path corners, and have for instance 1~5 be one way, then 5~10 be back (with a wait for retrigger on 5), or i could try using a trigger_changetarget to change the path_corners, but i only just read about that in the other question thread and don't know about it or how to use it.
However, there's a problem. I'm using "Trigger_multiple" to trigger certain events during the ride, to be more exact, my train slides onto a "platform", then stops, if there's a player in the train, it will retrigger and have the train move down, together with the platform (which is a func_train as well). When it's down, it continues on to the end destination. The problem here is, that if i want to have it go back up, i'd have to use another trigger multiple on the lower part, which sends the stuff back up. If that is enabled while it's going down, it'll keep going up and down, and not work. Is this possible to make?
Thanks in advance again <img src="style_emoticons/<#EMO_DIR#>/smile-fix.gif" style="vertical-align:middle" emoid=":)" border="0" alt="smile-fix.gif" />
Okay, doing nicely =]]
... You would expect this to be simple, i just make two sets of path corners, and have for instance 1~5 be one way, then 5~10 be back (with a wait for retrigger on 5),
<!--QuoteEnd--></div><!--QuoteEEnd-->
Correct. Thats best method.
<!--quoteo(post=1582042:date=Nov 29 2006, 01:30 PM:name=Angelusz)--><div class='quotetop'>QUOTE(Angelusz @ Nov 29 2006, 01:30 PM) [snapback]1582042[/snapback]</div><div class='quotemain'><!--quotec-->
or i could try using a trigger_changetarget to change the path_corners, but i only just read about that in the other question thread and don't know about it or how to use it.
<!--QuoteEnd--></div><!--QuoteEEnd-->
Bad idea, it'll get messy.
<!--quoteo(post=1582042:date=Nov 29 2006, 01:30 PM:name=Angelusz)--><div class='quotetop'>QUOTE(Angelusz @ Nov 29 2006, 01:30 PM) [snapback]1582042[/snapback]</div><div class='quotemain'><!--quotec-->
However, there's a problem. I'm using "Trigger_multiple" to trigger certain events during the ride, to be more exact, my train slides onto a "platform", then stops, if there's a player in the train, it will retrigger and have the train move down, together with the platform (which is a func_train as well). When it's down, it continues on to the end destination. The problem here is, that if i want to have it go back up, i'd have to use another trigger multiple on the lower part, which sends the stuff back up. If that is enabled while it's going down, it'll keep going up and down, and not work. Is this possible to make?
<!--QuoteEnd--></div><!--QuoteEEnd-->
Why not use the brush_trigers so when the player passes (within the train) it'll trigger something. or a trigger once.... not sure i'f i'm understanding ...
You have a brush trigger the train when the player gets on... and you want to have another brush at the lower trigger to go back up when the player gets on again?
You could link both brushes together (shif-click) and tie to entity, and then adjust the 'reset' timer to be the length of the ride +/- a few seconds.
Okay, i'll stick to the extra path_corners. Thanks for the info, really helped <img src="style_emoticons/<#EMO_DIR#>/smile-fix.gif" style="vertical-align:middle" emoid=":)" border="0" alt="smile-fix.gif" />
By the way, does anyone know; i've got a certain difference in height in my map, it's quite a lot from the highest part to the lowest, is that a problem in commander mode? (should i stick to a certain min-max height?)
Although it's a test map, it's good to know when i would start a real one.