Strict Standards: Declaration of Auth_SMF::initUser() should be compatible with AuthPlugin::initUser(&$user, $autocreate = false) in /home/tremulous/tremulous.vilkacis.net/w/extensions/Auth_SMF.php on line 454

Warning: Cannot modify header information - headers already sent by (output started at /home/tremulous/tremulous.vilkacis.net/w/extensions/Auth_SMF.php:454) in /home/tremulous/tremulous.vilkacis.net/w/includes/Feed.php on line 145

Warning: Cannot modify header information - headers already sent by (output started at /home/tremulous/tremulous.vilkacis.net/w/extensions/Auth_SMF.php:454) in /home/tremulous/tremulous.vilkacis.net/w/includes/WebResponse.php on line 16

Warning: Cannot modify header information - headers already sent by (output started at /home/tremulous/tremulous.vilkacis.net/w/extensions/Auth_SMF.php:454) in /home/tremulous/tremulous.vilkacis.net/w/includes/WebResponse.php on line 16

Warning: Cannot modify header information - headers already sent by (output started at /home/tremulous/tremulous.vilkacis.net/w/extensions/Auth_SMF.php:454) in /home/tremulous/tremulous.vilkacis.net/w/includes/WebResponse.php on line 16

Warning: Cannot modify header information - headers already sent by (output started at /home/tremulous/tremulous.vilkacis.net/w/extensions/Auth_SMF.php:454) in /home/tremulous/tremulous.vilkacis.net/w/includes/WebResponse.php on line 16
Tremulous Wiki - User contributions [en] http://tremulous.net/wiki/Special:Contributions/God%2C_maker_of_the_world From Tremulous Wiki en MediaWiki 1.15.1 Thu, 18 Jan 2018 02:21:40 GMT Mapping http://tremulous.net/wiki/Mapping <p>God, maker of the world:&#32;</p> <hr /> <div>{{stub}}<br /> <br /> A [[mapper]] is a person who creates a game [[map]]. He is &quot;mapping&quot;. For a list of a few existing Tremulous maps, click [[:category:Maps|here]].<br /> <br /> [http://tremulous.net/forum/index.php?topic=7497.0 list of mapping tutorials]<br /> <br /> Mapping tutorial made in 2007, still very good: [http://tremmapping.pbworks.com/ tremmapping.pbworks.com]<br /> <br /> [[Category:Mapping]]</div> Fri, 30 Jul 2010 10:42:36 GMT God, maker of the world http://tremulous.net/wiki/Talk:Mapping Mapping http://tremulous.net/wiki/Mapping <p>God, maker of the world:&#32;removed article on request of the community - http://tremulous.net/forum/index.php?topic=9822.msg201224#msg201224</p> <hr /> <div>{{stub}}<br /> <br /> A [[mapper]] is a person who creates a game [[map]]. He is &quot;mapping&quot;. For a list of a few existing Tremulous maps, click [[:category:Maps|here]].<br /> <br /> [[Category:Mapping]]</div> Thu, 29 Jul 2010 04:30:16 GMT God, maker of the world http://tremulous.net/wiki/Talk:Mapping User talk:God, maker of the world http://tremulous.net/wiki/User_talk:God,_maker_of_the_world <p>God, maker of the world:&#32;Blanked the page</p> <hr /> <div></div> Fri, 23 Jul 2010 11:58:53 GMT God, maker of the world http://tremulous.net/wiki/User_talk:God,_maker_of_the_world User talk:Mooseberry http://tremulous.net/wiki/User_talk:Mooseberry <p>God, maker of the world:&#32;Replaced content with 'Neither is this one.'</p> <hr /> <div>Neither is this one.</div> Fri, 23 Jul 2010 11:58:44 GMT God, maker of the world http://tremulous.net/wiki/User_talk:Mooseberry User talk:Mooseberry http://tremulous.net/wiki/User_talk:Mooseberry <p>God, maker of the world:&#32;</p> <hr /> <div>Neither is this one.<br /> <br /> Moose, you said &quot;no personal vendettas please&quot;, and if it is really your judgment that this<br /> <br /> &quot;Another example of why the whole &quot;alpha&quot;, &quot;beta&quot; and &quot;final&quot; concept fails. The only thing that makes sense is to simply add a &quot;_001&quot; etc. for every release. You never know which one is a final.&quot;<br /> <br /> is a &quot;personal vendetta&quot;, then clearly you should not moderate the wiki. What kind of &quot;personal revenge&quot; could it possibly be when I point out that this map is a good example of why the &quot;alpha&quot;, &quot;beta&quot;, &quot;gamma&quot; concept is flawed? ''Do you believe that I have a problem with jex?'' Maybe the wording could be optimized. Maybe the information doesn't even belong on the page, but it does belong somewhere in the wiki. Mindlessness is not what should be promoted, and just blindly following the &quot;alpha&quot;,&quot;beta&quot;,&quot;final&quot; herd without reflecting other possibilities is not the right way. If the problem is that I am speaking out against the majority here, then the problem apparently is not about right and wrong but about power.<br /> <br /> I am convinced that the only reason that you struck like this is that you are unconditionally (as in &quot;brainlessly&quot;) defending the established opinion.<br /> <br /> I feel attacked and offended by your accusation of a &quot;personal vendetta&quot;. If it was a mistake that you called it that, then I expect a public apology, just as your change-comment was a public accusation.<br /> <br /> Or was it a mistake that I invested so much time in this wiki? Because I can't delete the data that I have contributed, can I. It's as if I build a base and my one teammate treats me like shit. If I justifiably decon and join spectators, I am beaten with the &quot;deconner&quot; club even though my actions would be just.<br /> <br /> EDIT: I offer you a cheap way out. Delete this text and delete (or change) the &quot;vendetta&quot; offense.</div> Thu, 22 Jul 2010 13:09:36 GMT God, maker of the world http://tremulous.net/wiki/User_talk:Mooseberry User talk:Mooseberry http://tremulous.net/wiki/User_talk:Mooseberry <p>God, maker of the world:&#32;</p> <hr /> <div>Neither is this one.<br /> <br /> Moose, you said &quot;no personal vendettas please&quot;, and if it is really your judgment that this<br /> <br /> &quot;Another example of why the whole &quot;alpha&quot;, &quot;beta&quot; and &quot;final&quot; concept fails. The only thing that makes sense is to simply add a &quot;_001&quot; etc. for every release. You never know which one is a final.&quot;<br /> <br /> is a &quot;personal vendetta&quot;, then clearly you should not moderate the wiki. What kind of &quot;personal revenge&quot; could it possibly be when I point out that this map is a good example of why the &quot;alpha&quot;, &quot;beta&quot;, &quot;gamma&quot; concept is flawed? ''Do you believe that I have a problem with jex?'' Maybe the wording could be optimized. Maybe the information doesn't even belong on the page, but it does belong somewhere in the wiki. Mindlessness is not what should be promoted, and just blindly following the &quot;alpha&quot;,&quot;beta&quot;,&quot;final&quot; herd without reflecting other possibilities is not the right way. If the problem is that I am speaking out against the majority here, then the problem apparently is not about right and wrong but about power.<br /> <br /> I am convinced that the only reason that you struck like this is that you are unconditionally (as in &quot;brainlessly&quot;) defending the established opinion.<br /> <br /> I feel attacked and offended by your accusation of a &quot;personal vendetta&quot;. If it was a mistake that you called it that, then I expect a public apology, just as your change-comment was a public accusation.<br /> <br /> Or was it a mistake that I invested so much time in this wiki? Because I can't delete the data that I have contributed, can I. It's as if I build a base and my one teammate treats me like shit. If I justifiably decon and join spectators, I am beaten with the &quot;deconner&quot; club even though my actions would be just.</div> Tue, 20 Jul 2010 06:50:49 GMT God, maker of the world http://tremulous.net/wiki/User_talk:Mooseberry Door http://tremulous.net/wiki/Door <p>God, maker of the world:&#32;Created page with 'A Tremulous door is a sliding brush (or set of brushes, so very complex door shapes are easily possible). Once a player gets near the door, the door moves. It does not rotate lik…'</p> <hr /> <div>A Tremulous door is a sliding brush (or set of brushes, so very complex door shapes are easily possible). Once a player gets near the door, the door moves. It does not rotate like the [[rotating door]].<br /> <br /> Doors are extremely flexible. For example: A door can easily be used as a lift (by setting lip to a high negative value). A door could also be very small, not intended for someone to walk through, to use it as a status light while, for example, a lift cycle is busy somewhere.<br /> <br /> Doors do not just react to someone getting close. If the &quot;health&quot; value is set, they ignore players and only move when they get hit by that amount of damage. (They don't get altered in the process, no matter how often they get shot.)<br /> <br /> If someone blocks a door in motion and cannot be pushed aside, the door can deal a definable amount of damage. It normally changes its direction then, but that can be prevented by defining the door to be a &quot;crusher&quot;.<br /> <br /> The door as 4 sounds: One when it starts its motion, one when it stops. And these two again in the other direction.<br /> <br /> Like all Tremulous movers, the door triggers its targets (if the &quot;target&quot; key is defined) when it reaches a final position (open or close). This is not documented in [[NetRadiant]] at the moment.<br /> <br /> Of course, the door itself supports the &quot;targetname&quot; key so that it can be triggered by any &quot;target&quot;ing entity.</div> Fri, 16 Jul 2010 10:45:02 GMT God, maker of the world http://tremulous.net/wiki/Talk:Door Rotating door http://tremulous.net/wiki/Rotating_door <p>God, maker of the world:&#32;Created page with '{{stub}} A rotating door is a door that rotates instead of sliding. Imagine the draw bridge of a castle, and you imagine a rotating door. Or imagine the door of a fridge, and…'</p> <hr /> <div>{{stub}}<br /> A rotating door is a [[door]] that rotates instead of sliding. Imagine the draw bridge of a castle, and you imagine a rotating door. Or imagine the door of a fridge, and you also imagine the rotating door.<br /> <br /> To make a rotating door in [[NetRadiant]], one needs to define where the rotation axis is. This is done in the entity inspector by not selecting an x,y,z option (to have the default axis) or by selecting ''one'' of the given x,y,z options. That defines the axis. But you also have to define one point that lies on that axis.<br /> <br /> To define a point on the selected axis, you need to create an [[origin brush]]. That's just a normal box brush with the &quot;origin&quot; texture. This brush must be a part of the rotating door entity, so it's best to first create the door brushes and the origin brush, and then to select them all and turn them into the rotating door entity.<br /> <br /> The rotation angle also needs to be defined. Speed, damage and so forth - just as one knows it from the normal door.</div> Fri, 16 Jul 2010 10:36:54 GMT God, maker of the world http://tremulous.net/wiki/Talk:Rotating_door Origin brush http://tremulous.net/wiki/Origin_brush <p>God, maker of the world:&#32;typo</p> <hr /> <div>{{stub}}<br /> An origin brush is just a [[brush]] (usually a simple box shape) with the texture &quot;origin&quot;. Such a brush is used to define the anchor point of entities like e.g. a [[train]] or a [[rotating door]].<br /> <br /> The origin brush must be part of the entity to fulfill its function.<br /> <br /> The software determines the origin defined by that brush by calculating its three-dimensional center. So, the center of the origin brush is the anchor point of the entity that uses the origin brush.</div> Fri, 16 Jul 2010 10:29:11 GMT God, maker of the world http://tremulous.net/wiki/Talk:Origin_brush Origin brush http://tremulous.net/wiki/Origin_brush <p>God, maker of the world:&#32;</p> <hr /> <div>{{stub}}<br /> An origin brush is just a [[brush]] (usually a simple box shape) with the texture &quot;origin&quot;. Such a brush is used to define the anchor point of entities like e.g. a [[train]] or a [[rotating door]].<br /> <br /> The origin brush must be part of the entity to fulfill its function.<br /> <br /> The software determins the origin defined by that brush by calculating its three-dimensional center. So, the center of the origin brush is the anchor point of the entity that uses the origin brush.</div> Fri, 16 Jul 2010 10:28:59 GMT God, maker of the world http://tremulous.net/wiki/Talk:Origin_brush Origin brush http://tremulous.net/wiki/Origin_brush <p>God, maker of the world:&#32;Created page with '{{stub}} An origin brush is just a brush (usually a simple box shape) with the texture &quot;origin&quot;. Such a brush is used to define the anchor point of entities like e.g. a [[tra…'</p> <hr /> <div>{{stub}}<br /> An origin brush is just a [[brush]] (usually a simple box shape) with the texture &quot;origin&quot;. Such a brush is used to define the anchor point of entities like e.g. a [[train]] or a [[rotating door]].<br /> <br /> The origin brush must be part of the entity to fulfill its function.</div> Fri, 16 Jul 2010 10:27:42 GMT God, maker of the world http://tremulous.net/wiki/Talk:Origin_brush Worldspawn http://tremulous.net/wiki/Worldspawn <p>God, maker of the world:&#32;</p> <hr /> <div>{{stub}}<br /> <br /> The term &quot;worldspawn&quot; is used by [[mapper|mappers]] (See also [[mapping]].) to refer to the first [[entity]] of a [[map]] file. This entity holds all [[brush|brushes]] (walls, floors etc.) of the 3D world that are not used by other entities (like automatic doors etc.).<br /> <br /> Worldspawn brushes are &quot;dead&quot;, they're just there, while the brushes of other entities fulfill a certain function depending on the entity. A door's brush, for example, moves around. There are also [[origin brush|origin brushes]] (normal brushes with the texture &quot;origin&quot;) which are used to define the anchor point of entities like e.g. a train or a rotating door.<br /> <br /> A complete map usually has thousands of brushes in their worldspawn entity, and then there are lots (often hundreds) of entities which can also have brushes.<br /> <br /> The worldspawn is not just the element that holds all world brushes. It can also hold definitions which alter the functionality of a map. See for example: [[G_disabledEquipment]], [[G_disabledBuildables]], [[G_disabledClasses]]. The amount of buildpoints available to the teams and the amount of kills necessary to reach stage 2 and stage 3 can also be defined there. All this can be read in the immediate help text available in the map editor [[NetRadiant]].<br /> <br /> [[Category:Mapping]]</div> Fri, 16 Jul 2010 10:26:52 GMT God, maker of the world http://tremulous.net/wiki/Talk:Worldspawn Gmotw Skybox http://tremulous.net/wiki/Gmotw_Skybox <p>God, maker of the world:&#32;typo</p> <hr /> <div>{{Infobox Map<br /> |levelshot=Image:gmotw_skybox.jpg<br /> |author=God, maker of the world<br /> |version=1.1.0<br /> |fullname=Skybox<br /> |mapname=gmotw_skybox_004<br /> }}<br /> <br /> The main part of the map is contained in a simple (but huge) box that is open on one side, showing sky and landscape. If you fall out, you're dead. The [[jetpack]] is not available on this map. Each team has 400 build points.<br /> <br /> This map features many areas (with [[location name|location names]]) that can be accessed at any time, but the paths that lead to them (and the size of the paths - think tyrant) can be altered.<br /> <br /> Part of this concept is that [[overmind]] and [[reactor]] are built in a place that the players can not access or see. The players have to make little bases using eggs and repeaters. A few small bases do already exist, so humans are not totally lost before reaching stage 2 when they can finally make new repeaters.<br /> <br /> There are 11 special doors on the map that can be switched from open to closed or vice versa. The doors are combined into 4 sets. The first set has 4 doors, the second has 3, the third has 2, and the fourth has 2. Some of the doors of a set are closed at the beginning and will be opened by switching the set, and vice versa.<br /> <br /> These 4 door sets can be switched by removing/making buildings in certain places. There are 4 glass boxes on the map that contain a building (3 repeaters, 1 acid tube). To switch a repeater box, the buildings that are powered by the repeater have to be removed, so that 90 seconds later, the repeater explodes and the door set is switched. This gives aliens a greater purpose in attacking the bases near the repeaters. To switch the acid tube box, the nearby eggs have to be removed. Every glass boxes has an information sign with screenshots that explains which doors will be switched in which way.<br /> <br /> When a door set is switched from &quot;building&quot; to &quot;no building&quot;, an announcer tells every player that this is happening and which doors are affected in which way.<br /> <br /> After all 4 door sets have been switched, a button appears somewhere in the big swimming pool at the bottom of the map. When this button is pushed, the hidden overmind and reactor are destroyed, which will also be announced globally. Additionally, the 4 glass boxes open so that from now on, buildings can be made inside of them to switch the door sets.<br /> <br /> Another specialty of the map: When one of the teams reaches stage 2 or 3, an announcer tells every player about this.<br /> <br /> Different from most maps, nearly every spot in this map is used for rooms, so if there's a wall, there's likely a place behind it. Players might at first experience it to be a maze, but the locations and paths, though complex, are easy to memorize.<br /> <br /> The map features several hazardous zones (radioactivity/slime), several secret doors that have to be attacked to open them temporarily, two health water pools, two health+ammo recharge stations, a underwater area that can be pumped dry temporarily, and an extensive easter egg area with a small two-base arena that can even be locked via building so that no one can get out. This allows server [[administrator|administrators]] to make a [[layout]] in a way that both teams are confined to the little easter egg arena for the whole match. If the locking building is a repeater, the teams can get out eventually. The map is a feast for layout makers.<br /> <br /> The [[lightmap]] of this version (004) has a very high resolution so that users with 128MB graphics cards will probably experience [[lag|lags]].<br /> <br /> Download link: [http://downloads.mercenariesguild.net/maps/map-gmotw_skybox_004-1.1.0.pk3 gmotw_skybox_004] 12MB<br /> <br /> [[Category:Maps]]</div> Thu, 15 Jul 2010 08:40:17 GMT God, maker of the world http://tremulous.net/wiki/Talk:Gmotw_Skybox Mapping http://tremulous.net/wiki/Mapping <p>God, maker of the world:&#32;/* NetRadiant crash course */</p> <hr /> <div>A [[mapper]] is a person who creates a game [[map]]. He is &quot;mapping&quot;. This article describes how that works in the Tremulous context. For a list of a few existing Tremulous maps, click [[:category:Maps|here]].<br /> <br /> <br /> =mapping crash course=<br /> <br /> I started this article on 2010-06-29, just so you know why it doesn't refer to Tremulous 1.2 etc. I am a Windows user (2000 and XP), so that's the perspective that I use. If you can't translate that into your perspective, then you probably shouldn't use the system you're using.<br /> <br /> There are already several mapping guides out there ([http://tremulous.net/forum/index.php?topic=7497.0 list]), one of the best of which is at [http://tremmapping.pbworks.com/ tremmapping.pbworks.com]. It is easy and very comprehensive. I'll try to write a new one from scratch here based on my experiences - and much more up to date. It will save you some steps that were necessary 3 years ago when the linked guide was made. This article here will not enable you to make good maps, but it will give you a truckload of know-how of the kind you don't find in other mapping guides.<br /> <br /> If you've ever written something like a guide, you know that you'll inevitably get into ramble mode from time to time. I guess you can forgive me that.<br /> <br /> <br /> ==setting up your computer==<br /> <br /> ===Tremulous client===<br /> <br /> Download and install the original Tremulous 1.1.0 client. It can be found [http://tremulous.net/files/ here], but it's all over the Web, just search. Now, you ''could'' use a different Tremulous client, but I suggest that you don't. Reason: The original client is what many people out there still use, and when you test your map, you'd want to see what it looks and behaves like (and if it works at all) in the client all those [[newbie|noobs]] use who wouldn't know how to fix a problem if your map causes it. You want your map to work and to shine in the original client. You don't want it to look great only in the latest client with magical rendering v9.9.999 and bloom effect.<br /> <br /> Maybe also download the [http://tremulous.tjw.org/backport TJW backport] client. It's a slightly updated version of the original client. Not too new to violate what I said in the previous paragraph. This is not a full Tremulous release. It's just the program itself. Put it into the program folder of the above mentioned original client. This client supports [[GUID]] and much faster auto-[[Cl_allowDownload|download]].<br /> <br /> You might already have all this. But consider starting anew in a VirtualMachine or on a new computer. If you're more proficient, you'll be able to maybe clean up all your Tremulous base folders so that you don't have magical conditions that a person using the naked client wouldn't have. If you're not proficient enough in this and don't want to make a clean install, prepare to experience problems like &quot;But the texture wasn't missing on my machine!&quot;.<br /> <br /> ===NetRadiant===<br /> <br /> Now the most important part: Download and install [http://ingar.satgnu.net/gtkradiant/installation.html Ingar's NetRadiant and the Tremulous support files]. That's two downloads. The instructions on the linked page are short and comprehensive, it's easy to do. [[NetRadiant]] is the tool that you actually make the maps with. You probably also heard about &quot;GtkRadiant&quot;. Forget it. It's 99% the same as NetRadiant, but it's no longer developed. Also, installation is more complicated because it is not prepared for Tremulous. Additionally, Ingar's NetRadiant already includes the [[Q3Map2]] program that compiles your .map document to a playable .bsp map file.<br /> <br /> Change the NetRadiant preferences (and learn a few things about them): Start it. You'll probably see a little window offering a game type selection. Choose &quot;Tremulous&quot;. There's also a checkbox to prevent this window from appearing every time you start NetRadiant. Technically, that was all. But please, continue adjusting the preferences: Go into the preferences window, which can be found in the &quot;edit&quot; menu at the bottom. I'll go from top to bottom, not from most to least important.<br /> <br /> '''Textures:''' Later, you might want to change &quot;gamma&quot; to something like &quot;0.8&quot; to make the 3D display of the editor brighter. '''Undo:''' Increase queue size to 128. You'll use undo very often, sometimes to undo shifting textures around, and that's an undo step for every texture shift step even if it was a button autorepeat result.<br /> <br /> '''Brush:''' Definitely activate &quot;Always use caulk for new brushes&quot;. You can also activate &quot;Use alternative texture-projection&quot;, but most people do not do that, so if you want to open their maps, you'd have to turn it back off and restart the program. And there is no way to convert a .map from one setting to the other. If you decompile a playable map you found somewhere (like ATCS etc.), you would need to use the alternative projection to load the result in NetRadiant, so why not completely live in that world? I, however, have not done so. Because I didn't know better when I started mapping. I also don't know if I would ever regret turning this option on to make my own maps, so be careful. Maybe better leave it off.<br /> <br /> '''Grid:''' Set default grid spacing to &quot;32&quot;. That's the smallest room-wall-thickness that you want to use to prevent [[light bleeding]] (though the best measure to prevent light bleeding still is clipping). Once you're an experienced mapper, you might want to set this to &quot;256&quot;, the largest setting. '''Camera:''' Movement Speed 100 is good, but you'll come back later and change this, depending on your mapping situation. (I think NetRadiant should have a control element on the edit window to adjust the camera more quickly.) Smaller value for working on details, larger value if you have to travel a lot with your editor camera. Enable far clip plane: It's best to turn it off for now, you'll see everything then, no matter how far away it is. Enabling this option and setting the far plane to something close (menu &quot;view&quot;, submenu &quot;camera&quot;) would be helpful for selecting stuff with the box selection. Also, depending on your hardware and the map, it can speed up display considerably.<br /> <br /> '''Orthographic:''' Turn on &quot;display size info&quot; which will show you the size of one or more selected objects in the 2D view. Turn off &quot;chase mouse during drags&quot;, it would turn you crazy. '''Clipper:''' Definitely activate &quot;clipper tool uses caulk&quot;. '''Autosave:''' Deactivate it. If you're not a total computer noob, you'll know and use CTRL+S oftentimes anyway, and the autosave feature really gets in the way. The coders don't even reset the autosave timer when you hit CTRL+S (lol), so you're better off without it. Saving can take some time on bigger maps, so you want to be in control here. Also, very important: Make backups! Once you saved your map, go into the folder and duplicate the file (CTRL+C, CTRL+V, or whatever it is on your system). Sadly, the Radiant coders didn't include a save rotation like jEdit has it. You have to do that manually.<br /> <br /> Later, when you've worked a bit with NetRadiant, you might want to change the grid colors in the menu &quot;misc&quot;, submenu &quot;colors&quot;. My &quot;grid major&quot; is &quot;#00DF00&quot; (a big fat green) and &quot;grid minor&quot; is &quot;#ADFFAD&quot; (a very bright green, fading into white). Now, you should go into the &quot;view&quot; menu, submenu &quot;show&quot; and activate &quot;show workzone&quot; which will draw additional line garbage in the 2D view - the stuff you have drawn/selected last will have an additional red line pair around it. Makes it easier to find it. You have no idea how confusing the 2D view will become once your map is a bit more complex. Rule of thumb: Before you find the lines in the 2D view confusing, you shouldn't even think about presenting your map to the community.<br /> <br /> ===create the asset folders===<br /> <br /> '''Manually create folders in the base folder:''' You already know the base folder. You extracted the Tremulous support file here as Ingar's website instructed. Now, manually create a folder called &quot;maps&quot;. Also the folders &quot;textures&quot;, &quot;sound&quot; (NOT &quot;SOUNDS&quot;), &quot;scripts&quot;, &quot;env&quot;, &quot;models&quot;. If you have already seen a [[.pk3]] file from the inside, you'll have realized that the folders in those archives are treated by the game client as if they were really existing. So, you'll have guessed what those folders you just made will be used for: They'll hold the exact same kind of files that you see in the .pk3 map files.<br /> <br /> ===obtain a frontend for q3map2===<br /> <br /> If you're on Windows, definitely download [http://www.bobdev.com/q3map2build.php q3map2build]. The program is not necessary to make a playable map, but it's a big help in compiling. NetRadiant already has a build menu which calls q3map2 with parameters, also you could manually create batch files and just launch them every time you want to compile a map, which makes sense if you need very special settings for a map. For example: I worked on a map where I used q3map2's &quot;gamma&quot; option, quite unusual, so you would probably not reconfigure NetRadiant's build menu for that. You'd instead use a batch file. Or q3map2build.<br /> <br /> This VisualBasic program is a '''frontend for q3map2'''. It creates batch files and executes them. Depending on what you selected, there will be up to four lines in such a file: The first one compiles the binary BSP file from your MAP ascii document. The second one (&quot;[[VIS]]&quot;) calculates what point on your map can be seen from which other point and optimizes the BSP accordingly. Can be omitted oftentimes when you just want to have a look at your map, but for releases, this is absolutely necessary. It's the difference between 1 FPS and 90 FPS. Among other things. And the third line (&quot;LIGHT&quot;) finally calculates the light maps, so everything looks and feels real - without this phase, everything would be at full brightness which totally destroys the mood. The fourth line starts the Tremulous client with your freshly compiled map. Very convenient.<br /> <br /> '''After downloading q3map2build, you have to configure it:''' Start it. Go to &quot;directory options&quot;. Set &quot;game executable location&quot; to your tremulous.exe. Set &quot;q3map2.exe location&quot; to the file &quot;q3map2.exe&quot; located somewhere in the NetRadiant folder. Click &quot;save&quot;. Open the &quot;game options&quot; window, check the &quot;base mod dir&quot; box and type &quot;base&quot; into the text box. Click &quot;save&quot;. That was the basic setup of the program.<br /> <br /> '''While we're at it:''' In the little &quot;'''BSP'''&quot; area, select &quot;custom&quot; and click &quot;options&quot;. Activate &quot;custinfoparms&quot;, &quot;info&quot;, &quot;meta&quot; and &quot;patchmeta&quot;. Click &quot;save&quot;.<br /> <br /> In the little &quot;'''VIS'''&quot; area, select &quot;custom&quot; and click &quot;options&quot;. Activate &quot;saveprt&quot; (This makes sure that the portal file generated in the compile process is ''not'' deleted after the compile is completed, though it will be deleted and recreated on next compile. The portal file can be loaded into NetRadiant. You can then see in 2D and 3D the VIS areas that were compiled. Sometimes, you need this to help the software a bit. Keyword &quot;hint brushes&quot;.) and click &quot;save&quot;.<br /> <br /> In the little &quot;'''LIGHT'''&quot; area, select &quot;custom&quot; and click &quot;options&quot;. Activate &quot;bouncegrid&quot; (If you calc radiosity bounces, this option will make sure that the lightgrid (Whatever that is. I believe that it's a 3D grid of light. If you walk somewhere with your gun, it will receive e.g. red light. The light grid is where this is coming from, I believe.) is recalculated on every bounce, incorporating the light that was created by the bounces.), &quot;custinfoparms&quot; (which is necessary, I think, for shader parameters like &quot;nobuild&quot;, otherwise they might not get transported into the bsp, I believe), &quot;filter&quot; (softens the lightmaps so that shadow seams are soft, not pixelled), &quot;patchshadows&quot; (necessary for your pipes and models to cast shadows), &quot;bounce&quot;, &quot;bouncescale&quot;. Enter a &quot;500&quot; in bounce and a &quot;2&quot; in bouncescale. Remember these two options because you will later come back and deactivate them both, instead you will then (Later, as I said.) activate &quot;fast&quot;.<br /> <br /> Before you click &quot;save&quot;, let me explain what's going on here: These options define how the lightmaps will be rendered. The option &quot;fast&quot; really really increases the speed of the calculations, and you will use it most of the time because it even doesn't change the lighting drastically. But your first map tests will be of so little complexity that the rendering will be fast anyway.<br /> <br /> The &quot;bounce&quot; option is for radiosity bounces. So, your surfaces will not just have the light that is cast on them by the light sources. Instead, as in physical reality, your surfaces will also have the light that is reflected by the other surfaces. This is, of course, a question of iterations, because once a surface has received light from another surface, guess what: The next time, the light that comes from the surfaces is different. Realistically, 2 or 3 passes do the trick of giving the right impression. 500 passes will never be reached, all light will be used up at pass 5 or 7 maybe, the program will then stop calculating this. You should definitely use radiosity bounces in the maps you publish (if you have the time to calculate them), because they give a much more natural lighting feeling. For example: Colored surfaces will reflect colored light into the bounce process, and you'll see that in the endresult, especially if you use amplified bounces. Just turn this on for now so that you immediatelly collect data in your mind. The parameter &quot;bouncescale&quot; defines the amplification of the bounced light. Theoretically, this should be set to 1 (and hence could just be turned off), but I have made good experiences with amplifying the bounces a bit. This causes more radiosity bounces, of course, because the light will not be used up so quickly. It can even happen that the light will not be used up at all. Hey. This is a crash course, not a &quot;click here and you're done, but you stay uninformed&quot; course. There's more information about these settings further down in this article ([[#_lightmapscale.2C_gridsize.2C_turbo_rendering|lightmapscale/gridsize/turbo_rendering]]).<br /> <br /> You might wonder why I don't just use the &quot;build&quot; features in NetRadiant. Because I want to be in control, and I want to be flexible. This crash course will, for example, deal with &quot;amplified radiosity bounces&quot;, the lightmapscale and somesuch. If I had used the build features as presented, I'd still only work with non-amplified bounces, I wouldn't have dealt with the gridsize or the lightmapscale, I wouldn't have used the &quot;filter&quot; feature. Maybe there's still stuff to discover, but I won't discover it if I use the preconfigured built-in buttons. You don't have to go that way, but I won't spare you the ugly details.<br /> <br /> '''So, until now you have installed the Tremulous client, the NetRadiant map editor, the NetRadiant support files, you have configured NetRadiant a bit, you have hopefully gotten your hands on a good q3map2 frontend, and you have created those folders. That's it, now let's go mapping.'''<br /> <br /> ==NetRadiant crash course==<br /> <br /> In Netradiant, move the mouse to the white area with all the confusing lines. Click and hold the left mouse button. Drag the mouse a bit. Release the left mouse button. You just made a floor. Or a ceiling. '''That thing you just made is called a [[brush]].''' This can only be done in the 2D view. Brushes are the building blocks used to make the map world. They can be changed into different shapes and also be drawn directly in different shapes, but most of the time, you'll draw simple box brushes. If you have done everything in the setup section, the box you have just drawn should have a number pair at its left top (position), a number on the right side and a number on the bottom (dimensions). The unit system used is called &quot;world units&quot;. Rule of thumb (that I heard - can't say that I have really verified it) is: 32 world units = 1 meter. There should also be red lines from all four directions leading to the box brush you made. Click and hold the right mouse button. Move the mouse a bit. Release the button. You have just dragged the whole 2D world. Scroll the mouse wheel to zoom. '''You can now navigate the 2D view.'''<br /> <br /> By the way: When you draw a brush, you obviously control its dimensions in both directions, but what about the third? NetRadiant will make the brush as thick as the gridsize is set - unless your work area (the one we made visible via menu &quot;view&quot;, submenu &quot;show&quot;) says different. So, the last thing you had selected (even if it is now deselected) decides how thick your brush will be. You can of course change the size of a brush afterwards, but now that you know this, you'll some day begin to take this effect into account.<br /> <br /> On the right side, you should see a big gray empty space. That's the 3D view. This one is a bit tricky. I hope you have deactivated the far clip plane in the preferences (&quot;camera&quot;) as I've said. Otherwise, the next steps might take you too far away from the box you just drew, and so you would not get to see it. Right click in the 3D view, and release the mouse button. The mouse cursor should have vanished. When you do that again, the mouse pointer returns to normal. With the mouse pointer locked into the 3D view, press the downwards arrow on your keyboard for about one second. After that, move the mouse around in all directions. If you have done everything as I said, you will find an ugly pink box. Congratulations! You've just discovered the world of the mapper: Ugly pink boxes. Much of the mapping process will take place in your head, not in front of your eyes. Experiment with the arrow keys, the mouse movements, the CTRL and SHIFT key, and the mouse wheel in the 3D view. '''You can now navigate the 3D view.'''<br /> <br /> Time for a few keyboard shortcuts:<br /> <br /> Press the ESC key. The box should now look different in the 3D and 2D view because it is no longer selected. In later situations, you'll have to press the ESC key several times in a row to '''deselect stuff''' because some selection modes go deeper into the structure, and every ESC press takes you a step back until everything is harmlessly unselected. And then it looks like it does now.<br /> <br /> To '''select the box''' again, click on it in the 3D view while holding SHIFT. Most of the time, you will select stuff in the 3D view because it's a pain in the ass to do so in the 2D view. NetRadiant still needs much work. Why they didn't include a box selection mode that only selects stuff that completely fits into the box is beyond me. Don't they use their own software?<br /> <br /> Now that the box is selected again, press the BACKSPACE key. You know, the big leftward arrow above the return key. Whoops, '''box deleted'''. Select &quot;'''undo'''&quot; from the &quot;edit&quot; menu or press CTRL+z to get it back again.<br /> <br /> We will now apply a texture to one of the sides of the box. Well, it already has a texture - the name is '''&quot;Caulk&quot;, that's the most important texture of all''', really. You should have this texture applied to every surface that the player cannot see. So, it's best to start with all-Caulk'd surfaces, and whenever you're working on stuff, keep in mind that every unused surface should be returned to Caulk. This is not a ''must''. But you'll bite your own ass one day if you want to squeeze all possible FPS out of your map, so you'll want to Caulk everything, but didn't take care all the time to prevent unnecessary textures. I've been there.<br /> <br /> Press ESC to deselect the box. Now click on it in 3D, but this time, hold SHIFT and CTRL. '''You just selected a surface.''' The texture browser is right under the 3D view. Doubleclick on &quot;arachnid2&quot;, wait till all textures are loaded, then click on the first texture that you can see: &quot;001metal&quot;. Yay, '''you painted the surface'''. The texture in the texture browser does have a red border now. This means that this is the current texture. Without changing the preferences to &quot;new brushes have Caulk&quot;, every new brush you make would have the red bordered texture. But believe me that you'll later find out yourself that you don't want to go that way. Next to the big texture with the red border, there is &quot;arach_fog_s&quot;, a '''texture with a white border'''. Textures with white borders are [[shader]] textures. Shader textures are not just images, they can even have functions, for example they decide whether a brush textured with them is made of water that you can swim in - or slime/lava that kills you.<br /> <br /> Remember the folders you made in the &quot;base&quot; folder? The pictures you see in the texture browser are stored in the folder &quot;textures&quot; or in one of its many virtual versions - I am speaking of the texture folders in all those .pk3 files. They are treated as if they were really existing folders/files. Which means that it's easy to have a file with the same path and file name existing several times, something impossible in the normal file system (may I remind you that I speak from the Windows perspective). '''You should read the [[.pk3]] article''' because it contains important information on how to deal with this. It's really tricky, and you don't want to go through the process of finding out the hard way. Things that can happen if you fail here: Your map can cause other maps to malfunction. Or your map will be incompatible with older versions of itself. Or it will not function the way it did on your computer. By the way - if you wonder where the textures of all those maps you might have downloaded and played until now are: On my machine (Windows), I have ''several'' &quot;base&quot; folders. One is somewhere in the system user area. If you want to use the textures of those maps, too, move them into the &quot;base&quot; folder where the program is installed. And no, you don't have to unpack the .pk3 files to use their contents in NetRadiant. But if you're a mapping beginner, you shouldn't have other files in your installation &quot;base&quot; folder than the ones that actually came with the Tremulous installation (and the Radiant Tremulous support file). Reason: Later, you'll make a .pk3 release pack, and you have to put all files into it that people will not have from the default installation, so have fun figuring those out when your &quot;base&quot; folder is polluted and you're a beginner.<br /> <br /> In the beginning, you will probably use the textures/shaders/sounds etc. that are part of the original Tremulous 1.1.0 pack. '''You don't have to deliver Tremulous 1.1.0 standard files with your map''' because you can assume that everyone has those. I don't know about the Tremulous 1.2 world that is about to emerge, though. But until now, it's the right way to go, and many people have done so. It's accepted. It keeps your map file small. And it means less file- and folder-hassle for you.<br /> <br /> '''Let's save the map.''' NetRadiant doesn't know a name yet, so it will show you a box where you can enter a name. The folder (&quot;maps&quot;) should already be set. Or did you forget to make the folder? You can leave the name &quot;unnamed&quot;, I mean, why call it &quot;terror castle zero&quot; when you don't even know how to make one. From now on, you can just press CTRL+s to save the map. And from time to time, go to the folder window (outside NetRadiant) and '''make a backup of the map file''' (e.g. by copying and pasting it into the same place). Too much garbage in the folder? Learn to live with it. You don't want to live with lost data. '''Maps can get broken in weird ways.''' If you know how to debug them, good. Otherwise, go to an older version and start over. Example: Maybe you know that a map file is just a human readable text that you can open in any text editor. If you open a more complex map, you'll see that it only consists of [[entity|entities]] which in turn sometimes have parameters and/or brushes. Now, one of the bad things that can happen (because NetRadiant is really just a rudimentary editor that allows to make maps but which is really far from being a reliable pro tool) is that an entity that needs brushes (as for example a door - the brush(es) are the moving door) loses all of them. Such a map would not run in Tremulous. To fix such a situation, you would have to use a text editor, locate the erroneous entity and fix or delete it (which is not hard but also not for beginners). Or you'd go back to a previous map version. And no matter how experienced you'll be one day, there will sometimes be problems that you cannot fix. For example: I had a map once with one telenode. The Tremulous client, though, behaved as if there were two. But there was only one. That's easy to verify because the node can be searched for in the text file. I even searched in the compiled map: Only one telenode. Well, the system is not free from bugs, and this is what can happen. Because I was already so far into the map, I had to test-delete many brushes, compile, run - still one telenode too many. Again. And so forth. After a day, the problem was fixed even though the elements that I finally found out to delete and remake didn't have anything to do with the telenode and also didn't seem broken. Also, the telenode problem was absent in some of my delete runs - even though it was different stuff that I had deleted. By the way, there's a comprehensive forum thread about exactly this kind of problem: [http://tremulous.net/forum/index.php?topic=10307.0 How To: Fix Spawn Bug]<br /> <br /> Another word on backups: If you're not a total computer noob, you use archiving software from time to time. But &quot;ZIP&quot; is not the archive format of choice (except of course to make .pk3 files, those have to be ZIP, but you can create that with other archivers, too). [http://www.win-rar.com/downloadnow.html RAR] is very good (but not free, so there's a nag screen or you have to pay). But the best one currently (even though it doesn't support recovery records - haven't really needed those till today, anyway) is [http://www.7-zip.org/ 7z], and it's free. There are also versions for Linux etc. (search yourself). So, why do I mention all this? Well, if you have a bunch of backup copies of your map file (which will eventually outgrow the 1 mb limit, can even reach 20 mb), you'll quickly have tons of &quot;wasted&quot; space. But don't delete the backups if you're not absolutely perfectly sure that you won't need them any more! Just compress them. They compress very well, to about a 10th of their size. And if you use a ''modern'' archiver instead of ZIP when compressing like 20 backups into one archive, the archiver will not just squeeze down every map backup individually, but it will take into account that most parts of the files are equal. That's called a &quot;solid archive&quot;. Unpacking stuff out of them is a bit annoying because oftentimes, the whole archive has to be calculated through for one file. But who cares. So: Just pack all your backups into one archive from time to time. Instead of 100 mb &quot;wasted&quot; space, you'll only have like 1 mb! And you will have all backups of your map! I do it like this for every map individually: &quot;backups till 2010-06-29.7z&quot; and so forth. Makes you sleep better.<br /> <br /> The last word on backups: It's not enough to just backup the map onto the same machine. That is only for the work process in case something gets broken or you need to copy an object from an earlier version that doesn't exist in the current one. No, you also need to backup your files from your PC to another medium. That doesn't really belong into this article because every serious computer user should do that from time to time anyway. But I'd like to mention that here. What I do (apart from backing up my whole machine onto extra harddisks that I then put away somewhere from time to time): I have all mapping relevant files in the Tremulous install folder. And so, I just make a 7z archive of the whole folder tree once a week or so, and I copy it onto a USB stick. I don't know how reliable those are, but my experiences have been good so far. You'll sleep better if you know that the hundreds of mapping hours are safe somewhere.<br /> <br /> Let's go back to our brush. Press ESC to deselect the surface. Then SHIFT and left-click the brush to '''select it in the 2D view'''. Yes, in the 2D view. You can also hold SHIFT and the left mouse button, drag a box that touches the brush you made, and release both. That's the '''box selection'''. Another thing you can do (but you can't really test now because you only have one element in your map) is to SHIFT and left-click in the 2D view and also hold the ALT key. This selects one of the things that are in the position that you click at, just as the normal SHIFT and left-click does. But if you do this several times, the first selection is deselected, and something else in the same place is selected instead. Very useful function to '''toggle through all the stuff in that place.''' Less useful is the fact that it is buggy - sometimes, you have to move the mouse a bit to make the program allow you to use this function again. Box-selection (SHIFT and left-click, drag, release) is also possible in the 3D view (also the SHIFT-ALT-click toggle-through-stuff function), and only the elements currently in view will be selected - so you'll probably enable far-clip-plane from time to time (preferences, &quot;camera&quot;), adjust its distance (menu &quot;view&quot;, submenu &quot;camera&quot;), enabling you to easily select a group of objects (for example a truckload of lights that you used to slightly paint the light situation without people noticing) in front of you while the things behind them are too far away to be visible or get selected.<br /> <br /> If you have a look at the menu &quot;view&quot;, submenu &quot;filter&quot;, you see that you can '''filter''' the 2D and 3D view for the many different kinds of things and thing-groups that a map can consist of. This will be very useful for selecting. And for not getting distracted/confused. Also, displaying the graphics in the editor is faster if less stuff is being drawn, obviously. If you see anything in the filter list activated right now, select the lowest point &quot;reset filters&quot; which will turn everything off - so that you can see everything that exists in the 2D and 3D view. Another way of '''making stuff temporarily invisible''' is the '''hide function'''. Make sure your brush is selected. Then press the &quot;h&quot; key. Bang, it's gone. You can hide all kinds of elements. If you want everything to be visible again, press SHIFT &quot;h&quot;. Filters and hide have no influence on the map functionality, they are not even stored in the map file. When you close NetRadiant and open it again, the previous filter settings are still active which can be confusing at times. The hidden stuff, though, is visible again. By the way: Did you notice the - - - - - line at the top of the menu? If you click that, the menu will be opened in a window that does not go away when you select something in it. Very useful.<br /> <br /> Another very important function that can be toggled on and off is the &quot;'''texture lock'''&quot; function. There is a button with a lock picture for that somewhere at the top right of the screen. When it's active, it should actually blink and play a loud HONK!-sound all the time or something. And when NetRadiant is closed and opened again, it should be deactivated. But all of this does not happen. So, '''you have to take care whether or not the texture lock function is activated'''. Here is what it does: When it's not on, the textures on a brush seem to scroll around when you move the brush around. That is because the textures are normally locked to the world position. This is very practical, as you will find out with time. Now, the &quot;texture lock&quot; function changes that: When you drag a brush while that function is activated, the textures of the brush will move with it. That is very useful in cases where you have made a brush or several brushes with specific texture work (for example light fixtures), and you want to move those brushes without the design to change. Be aware whether or not the function is activated. You will remember this text here for sure. Because you will at some point see textures in wrong positions, realizing: &quot;Damn, I moved brushes around with texture lock on! Why isn't that function automatically turned off when I start the program?&quot; The texture lock function also changes the behavior of textures when you use the rotate-brush-by-90-degrees function.<br /> <br /> Remember when I called your brush a floor or ceiling? That's because the 2D view shows a view from the top (or bottom, depends on how you think) on the map when the program opens. Press CTRL and TAB. If nothing weird is going on with your input focus and keyboard (which can happen from time to time), the '''2D view was just switched from &quot;top view&quot; to &quot;side view 1&quot;'''. Do that again, and it changes to &quot;side view 2&quot;. Once again, and you're back at &quot;top view&quot;. You can determine what view you're currently on by looking at the little right angle labeled &quot;z&quot; and &quot;y&quot; or &quot;x&quot; and &quot;y&quot;, you get the picture. You'll probably determine that later by rather looking at the map, though. It's helpful/important to learn that the vertical axis is the Z axis. If you can currently see the X and Y axis, you're looking along the Z-axis (meaning: from the top).<br /> <br /> Now, let's finally get to '''how to move and scale a brush:''' Make sure the brush is selected. In the 2D or 3D view, click on the brush, hold the button, move the mouse, release the button. You just moved the brush (if the grid versus the amount of mouse movement didn't prevent this). Moving it in the 2D view makes sure that it is not moved along the axis that is pointing directly towards you. Moving it in the 3D view is comfortable, but can have unwanted results because of the fact that the camera is &quot;never&quot; perfectly aligned with the three space axes. To scale the brush instead of moving it, do the same, but don't click inside of it. Instead, click beside it. Important: Don't scale it too small so that it vanished. I have no idea what happens then. I always hit &quot;undo&quot; in such a situation. Might be a map-breaker.<br /> <br /> '''The grid''' is very important. In most cases, brushes should be perfectly aligned with grid points. Otherwise, have fun debugging your map. To '''change the grid scale''', press one of the number keys from 1 to 9. You can also do that in the grid menu. You'll do that from time to time, because, believe it or not, the grid spacings below 1 are actually used sometimes. The current grid spacing can be seen at the bottom of the NetRadiant window, on the right side. Careful with the key &quot;0&quot;: It toggles the grid from visible to invisible (and back). On a side note: I hope that the NetRadiant developers will be nice and implement a feature that draws the grid with thicker lines (e.g. 3 instead of 1 pixel) because it's simply invisible with all the stuff in front of it on more complex maps, and that sucks considerably.<br /> <br /> '''A word about world units / grid size / reactor and overmind etc.:''' It will take a while until you have memorized all the building and player sizes. Until then, just memorize this: An opening or room with the size '''128x128x128''' (second largest grid setting (&quot;8&quot;)) is just high and certainly wide enough to contain the overmind or reactor (112 would be enough). Tyrants etc. fit through nicely (96 would be enough). Those numbers might not really tell you anything, but any long-time computer user knows the drill: 1 2 4 8 16 32 64 128 256 512 1024 2048 4096 8192 16384 32768 65536 ... You should know those numbers up to 256 to be more efficient with NetRadiant. And 96 is three elements of the size 32, '''96 is just high enough for a tyrant''' to get through. '''64x64x64''' is big enough for a dragoon. A human can still crawl through a height of 32, if I am not mistaken. '''If you want to make a stair, 16 is a nice step height.''' Though 16 might seem a bit big on closer inspection since it's theoretically half a meter.<br /> <br /> Make sure that your brush is selected. Then, press CTRL and C, then CTRL and V, or use the &quot;edit&quot; menu. The '''brush exists now twice in the same place''', a common error that can cause weird map behavior, yet a situation that you will intentionally create many many times, because it's often useful to take an existing brush and copy/paste it somewhere else. At this point I should remind you: Keep everything Caulk'd that cannot be seen by the player. Ok, now press ESC. Yes, keep the two brushes in the one place for now.<br /> <br /> Travel to the side of the brush that shows the &quot;001metal&quot; surface. Select it (SHIFT CTRL left-click). Now go to another texture section. Not &quot;arachnid2&quot; but instead &quot;common&quot;. Most of the '''textures in the &quot;common&quot; group''' are actually shaders, as you know already because you saw the white borders around them. The one called &quot;caulk&quot; is among the first. It should have a green border because the currently open map uses it in at least one place. Click on &quot;caulk&quot;. This applies the caulk shader to the surface you selected. It also gets the red border because it's now the current texture, which is unimportant to us because all our new brushes have caulk, not the current texture. The &quot;common&quot; textures are really useful. There is, for example, a shader called &quot;ladder&quot;. Any vertical surface that you apply this texture to can be climbed. It's really that simple. Well, to make an actual ladder, build something that looks like it can be climbed, then make a brush with the ladder shader around / in front of it. The ladder shader is invisible, but you can't walk though it. There is also a texture called &quot;clip&quot; which you'd sometimes use to invisibly even out too odd wall and floor situations. The dretches will thank you. The players who don't get stuck while running away from the beasts will thank you, too. Some of the textures/shaders of the &quot;common&quot; section can be used without you having to distribute these shaders with your map (like for example the &quot;caulk&quot;, &quot;ladder&quot; and &quot;clip&quot; shaders), but it's best to just add these few bytes to your map file. Better safe than sorry. Ironically, the &quot;invisible&quot; shader, for example, would cause '''&quot;missing texture&quot; optics''' (Missing textures in the game are gray with a big white grid. Hard to miss. Easy to miss, though, if your testing environment is improper, because then you'll not have missing textures, but the players will.) if the Radiant Tremulous support files are not present, so put them into the release file. A .pk3 without those shaders will of course work on your machine - because you have the &quot;data-radiant-1.1.0.pk3&quot; in your &quot;base&quot; folder! Others do not have this.<br /> <br /> '''Get to know the phenomenon called [[Z-fight]] (or Z-fighting):''' Press ESC to deselect. Now, select &quot;the&quot; brush (doesn't matter which one, but just one of them, Wassily), so SHIFT left-click on it. Now for the important part: Move the brush a bit. Not too much. You'll see that the copy (or the original, you never know which one you'll click if there are several in one place) is revealed by you moving the other one. Don't move it too far - they should still overlap. Now, study the area in which the textured face of the one brush and the Caulk'd face of the other brush are drawn in the same place. Move the camera around a bit. If you've done everything right, then you are just observing a Z-fight. Two surfaces want to have the same distance from the observer and fight about it. No one wins, especially not the spectator/player. For historical reasons, the distance an object has from the camera is called the z-distance. You could also read up on the term &quot;[[Z-buffer]]&quot;.<br /> <br /> It is very probable that you will get to see Z-fighting somewhere during one of your many testruns of your maps. You can even find those in finished maps that can be found on many servers. I can remember at least one z-fight in a professional map that came with Tremulous 1.1.0 ([[Nexus6]]). Ironically, right now, there is nothing wrong about your map in that regard. Because one of the two surfaces that are fighting has the Caulk shader - which is defined to be invisible. There would be no z-fighting in your map right now.<br /> <br /> '''Mirroring and rotating:''' Select one of the brushes and toy around with the 6 buttons at the top left of the NetRadiant window. The first one is &quot;x|x&quot; and mirrors the brush along the x axis. I find it irritating that the Radiant developers chose to mirror the brush ''along'' the x axis instead of using the x axis as the, well, mirror axis, but you'll get used to that. The button next to that is the rotate-around-x-axis button, and that actually works like you'd expect it. Depending on the grid-versus-brush situation, the position of the brush gets changed accordingly, too, so later, you'll adjust the grid spacing before rotating a brush around 90 degrees. Mirroring does not care about the grid, just about where the brush begins/ends. If the &quot;texture lock&quot; is active, the textures get rotated and mirrored accordingly. Nice one. But if you rotate a brush using &quot;arbitrary rotation&quot; (menu &quot;modify&quot;), the textures will not be rotated with it, no matter if the &quot;texture lock&quot; was active or not. &quot;arbitrary scale&quot; (same menu), though, scales the textures (if &quot;texture lock&quot; is on).<br /> <br /> Left of the &quot;texture lock&quot; button, there is another (currently selected) button with a rectangle inside of it. If you hover your mouse above it, it'll say &quot;Resize (Q)&quot;. That's your normal brush draw/move/resize tool. Two buttons to the left, there is the &quot;Rotate (R)&quot; tool. Select it and rotate your brush a bit. This is the same as &quot;arbitrary rotation&quot;, only it's handled with the mouse instead of numbers. Don't forget to switch back to &quot;Resize&quot;.<br /> <br /> Now a quick tour of '''dealing with entities''': In the &quot;view&quot; menu, select &quot;entity inspector&quot; (or press &quot;n&quot;). There are several sections in that new window that appeared, and you might have to vertically scale those sections a bit before use. The most important area in that window is the one saying &quot;classname worldspawn&quot;. If there is no such text visible, you probably don't have a brush selected at the moment. Select one (or several, doesn't matter now). If there's still no text &quot;classname worldspawn&quot; in the window, you have to scale and move stuff in the window around a bit. The &quot;most important area&quot; with said text is not the lowest part of the window, but it's the lowest big white box in the entity inspector. Once you've found it, click on the text &quot;classname worldspawn&quot;. You'll see that, once you've selected it, the text &quot;classname&quot; appears below the area in a textbox labeled &quot;key&quot;, &quot;worldspawn&quot; in the &quot;value&quot; box. The '''key-value-principle''' is very important. The area in which you selected the key-value-pair will later have more key-value-pairs. These are the properties of the entity that you've currently selected. Wait, a brush is an entity? Well, if you deselect the brushes with ESC, &quot;classname worldspawn&quot; is no longer visible in the entity inspector window (only as a relict in the &quot;key&quot; and &quot;value&quot; input text boxes). So, every brush is an entity with the text &quot;classname&quot; in it? No. All brushes are one combined entity. The entity's name (And it's better to think of this as a type, not as a name. Later, you will have several entities with &quot;classname&quot; &quot;light&quot;, so it's obviously not just a name but really a type.) is &quot;[[worldspawn]]&quot;, a term mappers toss around oftentimes. Every map has min. and max. one worldspawn. It's the first entity in the .map file (if you look at it with a simple text editor.) The worldspawn can have very important settings regarding the map, for example the amount of buildpoints the teams have, or you can add a little message that is displayed while the map loads. The text area above the &quot;most important area&quot; describes which keys and values can be used for the world spawn. Once you select a different type of entity in the 2D or 3D view (or in the area at the top of the entity inspector, where all possible entity types are listed), the help text changes.<br /> <br /> When dealing with the entity inspector, be careful what you have selected in the map. It's possible to select a brush (usually part of the one &quot;worldspawn&quot; entity) and another entity type, for example a &quot;light&quot;. This flexibility can be useful, but if used improperly, it's a big source for errors. '''Always be aware of what's selected before using any function.'''<br /> <br /> Now, let's use an entity we haven't used before: Select one (or all) of the brushes. Then, right-click in the 2D view. A menu should appear. If it didn't, try again without moving the mouse even the slightest bit. In the menu, go to the item &quot;info&quot;, and from the new submenu, select &quot;info_player_intermission&quot;. This creates a little box of that entity type. Also, the brush(es) that were selected have gone, replaced by the new entity. You better undo that and remember this effect for later, because if you're dealing with a somehow broken map later, it might have been caused by the action that was just demonstrated. But everything should be fine if you use &quot;undo&quot; on such an action. Ok, now press ESC to deselect everything, and then create the entity anew. What is it good for? Well, it defines the position and orientation of the spectator camera when you enter a map or leave a team. '''The &quot;info_player_intermission&quot; entity is absolutely essential. Without it, a map does not work in Tremulous!''' The &quot;info_alien_intermission&quot; and &quot;info_human_intermission&quot; entities have a similar function (camera position and orientation when you're on a team and are currently not alive), but they are not technically necessary. You'll of course place them when you're making a real map.<br /> <br /> You can use the &quot;arbitrary rotation&quot; or the mouse rotate tool to change the direction into which the player_intermission camera is facing.<br /> <br /> Man, I almost forgot THE LOG. Move the mouse to the bottom of the window directly above the status line (that's the area with several texts and horizontal segments). There should be a handle looking like ............ Click and drag it up. You should now see the log. Sadly, you'll have to do that again next time the program is opened. The log shows the actions the program performs (and errors that happened). Have an eye on the log when you map, it'll save you a few map-repair-sessions because you'll see that something you wanted to do didn't work out, or something was done that you didn't expect and so forth.<br /> <br /> There are more NetRadiant explanations in the other sections of this mapping crash course.<br /> <br /> ==making your first (ultra basic) map==<br /> <br /> ===create the map===<br /> <br /> Now that you know how to handle the most important functions of NetRadiant, let's make a map, violating all rules, offending all experienced mappers. In the &quot;file&quot; menu, select &quot;new map&quot;. If a window appears asking you if you want to save the current map, you're doing it wrong because you should have saved the map already a few times with at least one or two backups. Ok, it's a worthless map that you wouldn't really save or backup often, but I want to give you an idea of how to deal with a real map.<br /> <br /> Press CTRL and TAB until the 2D view shows the X and Y axes, so you're '''looking from the top. Press the key &quot;9&quot; to have the largest grid spacing.''' If the grid is invisible, press &quot;0&quot;. If that doesn't make the grid visible, then it probably was not invisible before but just too big for your current zoom (use mouse wheel and maybe &quot;0&quot;). Read on once the grid is visible and also on its largest setting (displaying &quot;G:256&quot; at the bottom of the window).<br /> <br /> '''Create a brush in the 2D view, exactly one grid block in size.''' The numbers on its right and bottom size read &quot;256&quot; if you've done it right. Assuming that 32 world units are one meter, this brush is a nice 8 by 8 meters floor. Which is also 8 meters thick, by the way. But who cares. It's not like we're wasting concrete or something.<br /> <br /> The brush is pink, yes? Otherwise, shame on you. Now, move the camera in the 3D view so that you can see the top of the brush. Select the top face (CTRL SHIFT left-click, don't just SHIFT left-click it or you'll select the whole thing). Go to the &quot;arachnid2&quot; texture section and click the first texture (&quot;001metal&quot;). '''The top surface now has this texture.'''<br /> <br /> Press ESC to deselect everything. Then right click in the 2D view, and select &quot;team_human_spawn&quot; from it. Press ESC again, call the menu again, and select &quot;team_alien_spawn&quot;. Press ESC again, call the menu again, and select &quot;team_player_intermission&quot;. Great! '''Now you have all the three essential elements''' that you need to have a working Tremulous map. But there is a problem: '''If the spawns are not in a proper place''', they might not get created when the map loads. So, move the egg and the node around until they stand somewhere on the box. Make sure that there is enough distance between the two. Also, have a look at them from the side: They must not be too close to the surface of the box or they will not get created when the map loads. You can really place them quite high (Be reasonable.) above the surface. When the map loads, they will be created in that spot and then fall down to the surface (without taking damage). To move the entities around, you have to set the grid to a higher resolution. Just blindly hit one of the left digit keys for a high resolution, which one doesn't matter at the moment. By the way: Too many people ''in the game'' fail to place the spawns in the right rotation. It's easy: The player will spawn to face the position from which you made the spawn. Makes sense: That position can be assumed to be a valid place to go. Making spawns in the right rotation can influence the game flow positively.<br /> <br /> Please check if the surface on which you are trying to put the spawns is the one you have textured. If not, then you did something wrong earlier when texturing it. Spawns cannot be rotated in the editor in the way that they can be put on walls or something, so it's not the spawns that are wrong. By the way, you can '''rotate the spawns''' around the high axis (Z) to define the direction into which the player will look when he spawns. The human spawn, at least the one in the editor, has the aparatus-thingy on the side into which you will spawn. The egg spawns you into the direction the red axis at the egg's center points. The human spawn does so, too, but the aparatus-thingy is easier to see.<br /> <br /> Ok, we have a floor with a texture, both teams have a spawn, and the player_intermission camera does also exist (maybe you want to move and rotate it around a bit until it will probably show something meaningful, but it's not necessary for the map to run).<br /> <br /> What's missing? Light! ESC, 2D, rightclick, '''select &quot;light&quot;'''. A text box appears. Make sure that the number inside of it is &quot;100&quot;. That's the brightness of the light. Click ok or press RETURN. Pressing RETURN is not always advised: The &quot;arbitrary rotation&quot; dialog, for example, will not do anything then. Now move the point light you created until it is in the middle above the box brush. For that, press &quot;8&quot; to set the grid to the second largest spacing. Now it's easy to move the light to the middle. Seen from the top, it must be in the middle. Seen from the side, it must be one grid step above the floor. With setting &quot;8&quot;, that's 128 world units - 4 meters.<br /> <br /> ===build the BSP file and run it===<br /> <br /> If you have not yet saved the map, shame on you. Also, do it now. The name should be &quot;unnamed&quot;. Then, close NetRadiant. '''Because now we'll play the map!'''<br /> <br /> If you're a lucky Windows user, you'll have downloaded and configured q3map2build, I hope. Start that program, select the map &quot;base\maps\unnamed.map&quot; that you've just created, make sure that &quot;Play after build&quot; (left border of the window) is activated - and then click &quot;build&quot;!<br /> <br /> Alternatively, if you are not using this nice frontent for q3map2, you can create a batch file. The program does nothing different, only it's more comfy, and the texts displayed when you hover the mouse above the many switches certainly make things more clear. So, if you don't use the program, create a batch file. That's a normal text file with commands in it that has to be renamed to &quot;somethingsomething.bat&quot;. Sadly, those mega-idiots at Microsoft chose to hide file extensions (stuff like &quot;.bat&quot;) by default, so you can't rename the whole file name, only everything except the extension. For this reason and overall security improvement, Windows users are urged to turn the display of file extensions on. In any file explorer window, go to the &quot;Tools&quot; menu, select &quot;Folder Options&quot;. At the top of that new window, click on &quot;View&quot; and then scroll down until you see the option &quot;Hide extensions for known file types&quot;. Turn it off and click &quot;Ok&quot; at the bottom of the window.<br /> <br /> Here's the text for the batch file:<br /> <br /> &quot;C:\Program Files\netradiant-20100214-win32\q3map2.exe&quot; -fs_basepath &quot;C:\Program Files\Tremulous&quot; -fs_game &quot;base&quot; -custinfoparms -info -meta -patchmeta &quot;C:\Program Files\Tremulous\base\maps\unnamed.map&quot;<br /> &quot;C:\Program Files\netradiant-20100214-win32\q3map2.exe&quot; -fs_basepath &quot;C:\Program Files\Tremulous&quot; -fs_game &quot;base&quot; -vis -saveprt &quot;C:\Program Files\Tremulous\base\maps\unnamed.map&quot;<br /> &quot;C:\Program Files\netradiant-20100214-win32\q3map2.exe&quot; -fs_basepath &quot;C:\Program Files\Tremulous&quot; -fs_game &quot;base&quot; -light -bouncegrid -custinfoparms -filter -patchshadows -bounce 500 -bouncescale 2 &quot;C:\Program Files\Tremulous\base\maps\unnamed.map&quot;<br /> Pause<br /> &quot;C:\Program Files\Tremulous\tremulous.exe&quot; +set fs_basepath &quot;C:\Program Files\Tremulous&quot; +set fs_game base +devmap &quot;unnamed&quot;<br /> <br /> The line &quot;Pause&quot; is not necessary, though it can be useful to have the process wait between calculating and playing. q3map2build has options to insert &quot;pause&quot;, too. I once had the computer calculate a map for four days in a row, and I had &quot;Play after build&quot; unchecked because why should I &quot;burn&quot; my machine uselessly? This means that after calculating, the machine would just have closed the system's console text box without me being able to read the text. This makes the &quot;pause&quot; feature seem much less superfluous all of a sudden. Of course I could have saved the console output into files automatically (by adding &quot; &gt; outputtext1.txt&quot; to the end of the first line, and bla 2 3 4 to the other lines), but then again I wouldn't have been able to have a look at the console text because it would just have been in the files.<br /> <br /> You'll probably have to adapt the batch file text to suit your computer/setup.<br /> <br /> Doubleclick the batch file to start the compile.<br /> <br /> One of the things that will appear in the text window (which is the system's console text output) is &quot;LEAKED&quot;. Well, we didn't give the map a proper shell, we just made a floor. Doesn't matter at the moment, but later, we'll have to improve on that.<br /> <br /> Well. If everything went right, you're playing the smallest map in the world. And everything around your little world is pitch black. Or you see the [[hall of mirrors]] effect around you, really annoying. But it's a working Tremulous map!<br /> <br /> I bet you want to experiment now. Do that. But don't yet make a big map that kinda asks to be published, people are probably not going to like it. You have to learn some more first.<br /> <br /> <br /> <br /> <br /> <br /> ==making your second (more advanced) map==<br /> <br /> ===choose a name===<br /> <br /> You can freely create folders in the &quot;map&quot; folder, doesn't hurt the game system. So, you should make a folder and throw all files into it that have been created so far.<br /> <br /> Now, open NetRadiant (or select &quot;new map&quot; from the &quot;file&quot; menu if it was already open). Save this empty map. Reason: '''We want to give it a name.''' Press CTRL and S (or select &quot;save&quot; or &quot;save as&quot; from the file menu). The name shall be ... wait, what's your nick name? The name you use as a player or in the forums? If it were &quot;God, maker of the world&quot; (which is my nick name), we could make a short version of that, for example &quot;gmotw&quot;. Let's assume that your nick name is &quot;scrollbar5&quot;. A shorter version would be &quot;scr5&quot; or something. Let's stick to that. Back to naming the map: Please save it as &quot;scr5_dretchnest&quot;. If you actually have a nick name that you want to stick to and that can be nicely expressed with a few letters, use that from now on. I'll keep calling it &quot;scr5_...&quot;.<br /> <br /> You see where I'm heading. I called my first map [[Gmotw_Skybox|&quot;gmotw_skybox&quot;]], and this is not mainly about people attributing the map to my person (or so that all my maps would be in one alphabetical place in the huge map repositories that exist, hehehe) but instead so that I could freely choose my map names without having to worry about the name maybe already existing - or someone else taking the same name. I have not yet seen anyone do it like this, but I think this is actually the way it should be done by everyone, and so I tell my helpless scholar prey (Not really.) to do it just like that. '''Add a short version of your nick name with a &quot;_&quot; at the beginning of your map names.''' Keep it short, though. It's good if this prefix &quot;doesn't make sense&quot;, so it's not confused to be a part of the map's real name. So, &quot;gmotw_&quot; (Hey, that's mine.) is better than &quot;stellar_&quot;. By the way, if you look at the screenshot in the skybox article, you read the message &quot;Remove older versions of Skybox to prevent texture problems.&quot; which is really lame. You won't have problems like this since you can read my experiences and conclusions in this mapping guide. Comfy, no?<br /> <br /> If you use these prefixes, by the way, '''NetRadiant will nicely group all your map assets''' in the texture browser instead of spreading them all around the alphabetical map list.<br /> <br /> If you've read the [[.pk3]] article (which you should at some point), you'll already know about the '''filename uniqueness problem''' and about how to deal with it through several release versions of your map. We have halfway solved the uniqueness problem by choosing &quot;scr5_dretchnest&quot; (or whatever your prefix is), which is probably a name not yet taken. Except if 10 people go through with this mapping crash course without choosing a different prefix. But I wonder if anyone's gonna read it at all :/<br /> <br /> A word about &quot;alpha&quot;, &quot;beta&quot;, and &quot;final&quot; releases: BULLSHIT! That was actually just one word. No really: I think it's a meme or an &quot;I'm doing it just like the real guys! I feel like I'm taking a step into a larger world!&quot;-thing that people release their maps as alpha, beta, and final. Well, it has practical reasons, but it also has its problems. To make it short (meaning: I just deleted about 300 words of bla that I was about to save, and that was just the half of it.): Just give your releases a number. So, just add &quot;_001&quot; to the map name. Three digits seems to be much, but you never know. If you increase the release number every time you make a .pk3 and test it with friends or on the server of a guy you know, you'll quickly be above 9, and with all the stuff you have to keep in mind, you don't want to worry about the goddamn number. And once you have chosen to use the path of the &quot;_001&quot;... instead of the &quot;_a01&quot;... &quot;_b01&quot;... &quot;_final&quot;, you'll laugh at all the mappers who have decided to make their maps a &quot;final&quot; too early. &quot;Oh, something's still broken. Damn, already released as 'final'. Can't change it now.&quot; Weird people anyway. I mean, what makes you so sure that you will never add something to the map in a year or so? And then you have the other guys who are more careful. They make their alphas, then you find their betas in the wild... but there is never a &quot;final&quot;. Guess why. The last beta effectively ''is'' the final. Not changed after years. Assimilated by the community. No, you don't want to play that game. '''Just give your releases a number. Just a stupid counter suffix like &quot;_001&quot;.'''<br /> <br /> So, we're about to create a map. The &quot;next&quot; release of it will of course be the first, so its name is &quot;_001&quot;. (I should add that &quot;release&quot; in this context does not mean that you give it to the Mercenaries' Guild Map Repository and brag about it in the forums or something. I am just talking about a proper .pk3 file that you can test on servers.) When people callvote for it, they'd type:<br /> <br /> &quot;/callvote map scr5_dretchnest_001&quot;<br /> <br /> While we're at it: The .pk3 file of this (as can be read in the [[.pk3]] article) would be named<br /> <br /> &quot;map-scr5_dretchnest_001-1.1.0.pk3&quot;<br /> <br /> The name of the .pk3 file has nothing to do with the callvotes. But the name should be kept equal to the real map name for consistency reasons.<br /> <br /> If you're using the batch file solution, please '''edit the batch file just now''' to use &quot;scr5_dretchnest_001&quot; instead of &quot;unnamed&quot;. Reason: So that it hurts if you change the prefix or map name later. Get used to this. Of course, you can theoretically rename a map a hundred times before releasing it the first time, but we want to train here. If you decide to wait with the batch file editing, you're technically making the right choice in case you rename later, but you should experience the name lock, it'll help your mind to get into the real mapper world. Also, all following steps will make use of the map name and cement it some more, and '''you do not want the asset folders and the map to have different names. It's enough hassle as it is, and this would double the file naming work.'''<br /> <br /> By the way, how did I come to the name &quot;dretchnest&quot;? Ok, it's not rocket science, but you'd think that about most map names ''once they exist''. Obviously, I thought of Tremulous elements. What you can do to come up with a map name depends on whether you create it at the beginning, in the middle, or at the end of the mapping process. For example, when I came up with &quot;dretchnest&quot;, I had no idea what exactly the map should be like (other than something with 4 walls that you are supposed to clip diagonally in the corners). I only grabbed a name out of the clouds to complete this section. '''But now that I have a name, it gave me ideas about the map.''' Actually ideas that are ill placed in a beginner's mapping guide, so I'm probably not gonna put them into action here, but here they are: There would be a rectangular (Duh. Beginners always make box maps.) room with a few eggs. The room would be closed from all 6 sides, but there would be openings at the bottom, small enough for dretches to get out. Maybe there would have to be contraptions against crouching humans, maybe that would have to be done by basecamping dretches. If you spawn as granger, you can't get out, so maybe I would have added a trigger that checks if you're granger - and kills you. The ceiling of the room would be something that can be set in motion somehow with a button or by making a building or by reaching a certain spot or by reaching stage 3 etc., and this ceiling would squish the eggs in the room. Since there are no other eggs and grangers cannot get out, the aliens would have lost the game (if the aliens still alive don't win it). This is obviously not a standard Tremulous map, but I digg stuff like this (Trem has enough standard maps, lets bring something new to the table). Read the [[Gmotw_Skybox|skybox]] article if you don't know what I mean. That was my first map, by the way.<br /> <br /> &quot;dretchnest&quot; would have been a fitting name for the above described map. See? '''The name idea resulted in a map idea.''' I believe that it's usually the other way round. But it's improbable that the mapper does not decide for a name until the map is completed, because you'd need to test the map from time to time, and so you'd come up with a name to make a release file. (I repeat: The name you choose once you publish the map should never change, if you can somehow make it so.) Once the name is chosen, the name will probably feedback into the mapping process (e.g. you'd want it to be justified, the least you would do is add fitting decorations).<br /> <br /> '''How you can come up with a map name''': I speak english and german, so when I am thinking about the map that I already created a bit, I think of its prominent building and gameplay elements, enter those terms into a Web translator (like [http://dict.leo.org dict.leo.org]) in english or german, and then I play '''translation ping pong'''. You can also use a Web '''thesaurus''' for that. There are also '''map name generators''' on the Web, probably not Tremulous-specific. You'd rather want to use them for inspiration (and to fuel your translator and thesaurus attempts), not to really make the name for you.<br /> <br /> ===make a shader and a texture===<br /> <br /> Now, go to your Tremulous &quot;base&quot; folder. '''Create a new folder in the folder &quot;textures&quot;.''' Name: &quot;scr5_dretchnest&quot;. Why not &quot;scr5_dretchnest_001&quot;? Because then you'd have to re-assign all textures on every new release because the foldername changes. The project you're working on is &quot;scr5_dretchnest&quot;, and that's the name the asset folders should have. You can also make a folder like this in the &quot;sound&quot; folder, but I currently don't plan on talking about adding a sound. But this is the way it would work for sounds, too.<br /> <br /> If you want to add shaders (which we will do - it's easy if you know how), you have to add the release number again. Reason: The shaders are not several files stored in a new folder, like textures will be. No, the shaders of a map are little text blocks that are all stored in one text file. (You can also make several files, but let's keep this simple.) And '''if you change the contents of the shader file for a new release, you have to give that file a new name.''' Just as if you would have to give a texture a different name that you change from one release to the next. If you don't do this, your map will be incompatible with older versions of itself. You can be lucky with that. But lets do this properly. Use this knowledge. Imagine you had to gather this knowledge by experience which I had to... urgh!<br /> <br /> So, the texture folder is prepared. But '''lets make a shader first.''' Go to your Tremulous &quot;base&quot; folder into the folder &quot;scripts&quot;. Create a new text file called &quot;scr5_dretchnest_001.shader&quot;. If we add a shader into it, it will appear in NetRadiant the next time you start it. Well, you'd think so, but for some reason only the programmers know, you have to add an entry in the &quot;shaderlist.txt&quot; file in the same folder. At the end of that file, add &quot;scr5_dretchnest_001&quot; (without &quot;.shader&quot;), press return, save and close the file. Now open the &quot;scr5_dretchnest_001.shader&quot; file again and put the following text into it, save and close the file:<br /> <br /> textures/scr5_dretchnest/brightglass_001_s<br /> {<br /> qer_editorimage textures/scr5_dretchnest/brightglass_001.jpg<br /> qer_trans .5<br /> surfaceparm trans<br /> surfaceparm solid<br /> cull disable<br /> {<br /> map textures/scr5_dretchnest/brightglass_001.jpg<br /> tcgen environment<br /> blendfunc gl_one gl_one<br /> rgbGen identity<br /> }<br /> {<br /> map $lightmap<br /> blendFunc gl_dst_color gl_src_color<br /> rgbgen identity<br /> }<br /> }<br /> <br /> Close NetRadiant. Open it again and load the empty map file you created. If you look at the texture browser now, you'll see an entry called &quot;scr5&quot;. Now, how did that happen? Oh, the stupid nick name prefix idea! Yes, NetRadiant interprets names with a &quot;_&quot; in it differently. It creates categories. So, all your maps will be under the category &quot;scr5&quot; instead of being spread around like crazy.<br /> <br /> Unfold the category by clicking on the little triangle on its left side. &quot;scr5_dretchnest&quot; appears. It does so for two reasons: 1. You created a folder with that name in the textures folder. 2. You created a shader that in turn created the virtual (= not really existing) file &quot;textures/scr5_dretchnest/brightglass_001_s&quot;, so another reason why NetRadiant would think that the folder exists.<br /> <br /> The texture browser should now show an element called &quot;brightglass_001_s&quot;, something like a blue-black checkerboard, expressing that the image which was to be shown here can not be found. No wonder - we didn't make that one yet. And that's a bit tricky, because I don't intend to explain any graphics software to you now. '''You'll just ''somehow'' have to come up with a .jpg file that has power-of-2 dimensions''' (you know... 1 2 4 8 16 32 64 128 and so forth, computer numbers, as mentioned earlier in this article, though obviously, a texture with ''anything'' on it and the size of 32x32 or smaller hardly makes sense), I'd say 128x128 should be the choice here, that's enough for a simple reflection picture (which this one is). Textures don't have to be quare, by the way, but let's keep this one simple. Also, I think that a texture with an arbitrary size (not power-of-2) would work, too - but what &quot;would work&quot; is not the question. What surely will work in all Tremulous clients and with all graphics cards, that's the question.<br /> <br /> The jpg quality doesn't need to be maximum for a texture. &quot;high&quot; (60) or &quot;very high&quot; (80) (as they are called in Photoshop) is good enough. &quot;medium&quot; is too low in nearly all cases, I'd say. You know what would be nice? An actual screenshot you take yourself in Tremulous. Cropped and sized to 128x128 or bigger, util max. 2048x2048 for a normal texture and, I'd say, max. 512x512 for a reflection texture, but that's plenty. By the way: The bit depth per color channel must be 8, as most existing image files are. You can use 16 and even 32 bit in Photoshop etc., but not in the game. While we're at it: You can also use .tga pictures. If you know when to use gif/png versus jpg, then you know when to use tga versus jpg. Example: If you need a simple color texture (pure red, no other pixels), then .tga is the perfect choice. Tga supports an 8 bit alpha channel (save as 32 bit then, not 24 bit) and also a simple and lossless compression that can be used with Tremulous.<br /> <br /> So, assuming that you have somehow found a suitable .jpg file (.tga (even compressed) would also work, but I think you have to change the shader text then, though I believe that I have seen that the file extension named in the shader is irrelevant, but better safe than sorry), move / rename it to achieve this name: '''&quot;textures/scr5_dretchnest/brightglass_001.jpg&quot;'''.<br /> <br /> Again, close and open NetRadiant and feast your eyes on the new contents of the &quot;scr5_dretchnest&quot; texture browser category. Well, your image should be there now. Twice even. WTF? Well, one instance is from the actual file in the texture folder, and the other one is the shader you created. '''Now you see why the shader ends in &quot;_s&quot;: This prevents the names from colliding.''' (Adding &quot;_s&quot; is the way everyone does it.) See? Naming is a really delicate subject!<br /> <br /> So, before we finally start making the goddamn map, let me explain the shader we've created:<br /> <br /> The first line creates the virtual file by giving it a path and filename. Again, take care of those file names, be they virtual or real. The brackets don't need explanation, I guess.<br /> <br /> The &quot;qer_editorimage&quot; line is irrelevant for the game, but it gives our shader a nice image in NetRadiant. If you apply this shader to a wall, instead of the ugly &quot;no pic!!1&quot; texture, you now see your nice .jpg image. Half transparent even! That is caused by the &quot;qer_trans&quot; line, which is also irrelevant for the game. It's there purely for the editor. And both these lines are not necessary for editing. Later, you can add &quot;//&quot; to the beginning of these two lines, which means that they are &quot;commented out&quot;. Anything behind &quot;//&quot; is arbitrary text until the line ends. I don't know, though, if a comment can be written on the right end of a shader command. If you comment these two lines out later, when you've actually used the shader in the map, and restart NetRadiant, you'll probably realize that they are not technically necessary, but man do you want them to be there.<br /> <br /> &quot;surfaceparm trans&quot; says that the surface is transparent. This does not mean that you can look through it - it only means that ''the computer'' can look through it! Yes, he has to know, too. A later command will make the shader transparent for us humans, too. As the name said: It's a glass shader.<br /> <br /> &quot;surfaceparm solid&quot; says that the surface is solid. You cannot walk/fall/shoot through it.<br /> <br /> &quot;cull disable&quot; means that the opposite side of a brush that is completely painted with this shader will not be invisible, as it would be with a normal texture. &quot;culling&quot; means to temporarily remove elements (objects, faces etc.) that are irrelevant for the current situation. To speed things up. But it is disabled here because it's glass, so you can see the presence/absence of backside faces, so they must be there.<br /> <br /> So far, this was the description of how the surface behaves. I'm not the shader pro, so the following explanations might be a little stumbly.<br /> <br /> The next {}block describes the actual graphics that will be drawn. The {}block after that tells the system to also create a lightmap and overlay it.<br /> <br /> &quot;map textures/scr5_dretchnest/brightglass_001.jpg&quot; obviously makes the shader use your new texture file. &quot;tcgen environment&quot; is short for &quot;TextureCoordinateGeneration&quot; with the parameter &quot;environment&quot;. Man, do I have to explain environment mapping now? In short, this makes the texture appear in a way that is not like a normal 3D shape but instead like it were a reflection in the 3D shape.<br /> <br /> &quot;blendfunc gl_one gl_one&quot; means: The pixels of the source (this shader) will be multiplied by one, then added to the destination pixels (which is whatever's already drawn on screen behind the glass) also multiplied by one. So, this just adds your lightened (Remember that this shader has a lightmap.) environmentmap-glasstexture onto the world graphics. Now you might realize why it's called &quot;brightglass&quot;. If you want something darker, look for &quot;textures/tremor/darkglass3&quot;.<br /> <br /> I don't really know about shaders. I look at how the other guys did it (There are already tons of existing shaders, look in the folder &quot;scripts&quot; in the map .pk3 files.), I read a bit in the shader manual, trial and error testing, etc. For example, I have no idea what &quot;rgbGen identity&quot; really does, but it belongs there. If you want to dive into that yourself, read [http://www.heppler.com/shader/ this comprehensive shader manual]. Also, lets drop the rest of the shader explanation and get into mapping, damned.<br /> <br /> ===start making the map===<br /> <br /> Assuming that you're still in NetRadiant with your named map (that doesn't have any stuff in it) open, set the 2D to view from the top, set the gridsize to &quot;9&quot; (256), and draw a square, 8x8 grid elements in size, so it will be 2048x2048 world units. It's not really important where you do this, but since NetRadiant positions the camera at position 0,0,0 every time you load a map (which can somehow be changed with an entity, but I currently don't remember how, saw it in a decompiled ATCS once), I'd suggest that you draw this brush exactly centered around the coordinate 0,0. After you've done so, press CTRL and TAB to set the 2D to view from the side (doesn't matter which). If the brush isn't exactly one grid block high, drag it smaller so that it is. Then move the whole platform so that its upper side (which is the floor to walk on) is at coordinate 0. Unnecessary to say: The whole thing, every face, should have the Caulk shader, the ugly pink one that you already know.<br /> <br /> Copy and paste the selected brush. Click into it and drag it upwards so that its lower side (which will be the ceiling of the map) is at coordinate 256. That's an 8 meters high map hall.<br /> <br /> Press ESC, then draw a square brush left of the two existing brushes, exactly between them. If you press CTRL and TAB, you see that the depth of this square brush is already as we want it because the last selected brush(es) had this depth. Assuming that you're still in the side view in which you drew the square brush, draw another one, on the right side this time. Did you fall for the &quot;something is currently selected&quot; trap, or did you think of pressing ESC yourself?<br /> <br /> Press CTRL and TAB two times to get back to the top view. Now select the two side walls you made. To do that in the 2D view, it's ok to just use the box select in the currently mostly empty map space that we have. So, press SHIFT and then left-click and drag the mouse to select the unselected wall(s). The ceiling and floor (both visible in one place as a big square) must not be selected now! Once you've done that, copy and paste them, then click on the rotate-90-degrees-Z button (a Z with a blue arrow around 90 degrees of the Z). Now you should have a big room with ceiling, floor, and 4 walls. The wall and floor brushes should be edge-on-edge, that will work properly, don't worry. The brushes must not overlap, though! Admittedly, the walls are a bit thick, but they are the outer map walls, so that doesn't matter. Actually, it's not so bad to have them this thick. Why shouldn't they stand out in the editor as a unique structure.<br /> <br /> If you have done it right (which is more probable with this large grid spacing than it would be with a smaller spacing), you should have a proper shell in which you can go crazy without having to worry about [[leaking]]. The [[void]] is properly locked out. The [[VIS]] calculation can hence be performed. You will not have the [[hall of mirrors]] effect.<br /> <br /> Well, yes, you will have the HOM effect, because everything is still Caulk, but we'll change that now. First, select a proper texture: Select &quot;arachnid2&quot;, then scroll down a bit until you see &quot;cement_1_clean&quot;. Now, select all the 6 surfaces that form the room (CTRL SHIFT left-click, and as a NetRadiant user, you'll have learned to press ESC a few times before this new select action, I guess). Then click on the texture.<br /> <br /> '''Save the map. If this is your first save in this &quot;start making the map&quot; chapter, you're still doing it wrong!''' Also, duplicate the saved map file.<br /> <br /> Actually, the floor and ceiling look just wrong this way. Go to the &quot;karith&quot; texture section, scroll down a bit until you see &quot;cement_3&quot;, select only the floor and ceiling face (Not the whole brush, but I guess I don't have to say that any more.) and apply the texture. Save the map. No new backup this time.<br /> <br /> Nice room. If you fly around in it with your camera, you might get the impression that it's too dark. In that case, open the NetRadiant preferences. Don't worry about a message saying that you'd better save before entering the preferences - in most cases, it doesn't matter. Except that saving is usually fast and in most cases not a problem. And if that dialog appeared just now, you didn't save the map when I said so, sinner! :&gt; Go to the preferences section &quot;display&quot;, subsection &quot;textures&quot;, and set the texture gamma to, let's say, 0.8<br /> <br /> ===about clipping, most underestimated by beginners===<br /> <br /> Assuming that the current situation is the result of your actions in the last chapter, you should still be looking from the top in the 2D view. Gridsize should still be largest (key &quot;9&quot;). Now, draw a new brush, 4 grid elements in size, around the 0,0 coordinate. So, the size should be 512x512. The brush should be inside the map shell room that you built, exactly from floor to ceiling.<br /> <br /> We'll use a little trick now. Set the grid spacing to 32 (key &quot;6&quot;). As I said, 32 is the smallest wall thickness you should use if you want to prevent light bleeding. You can be lucky with smaller values or still unlucky with larger ones, but 32 is a good base to work with. I've read somewhere that a thinner wall risks that objects or players might pass through it when playing on the Internet, but I think that's not true, at least I haven't seen problems like these ''ever'' in the Tremulous world, and there are maps with thinner walls around. Another thing about wall thickness: Even a wall with 64 world units might still let the damage effect of a fully charged [[Lucifer Cannon]] shot through a bit. I wonder how much or how little calculation time / network overhead impact it would have meant to prevent this, because this behavior sucks considerably.<br /> <br /> So, with the grid set to spacing 32 and the new 512x512 brush selected, search for the 5th button right of the 90-degree-Z-rotate button. When you hover over it, it says &quot;Hollow&quot;. Alternatively, go to the &quot;brush&quot; menu, submenu &quot;CSG&quot; and select &quot;Make Hollow&quot;. This function is not widely used, because it motivates box rooms (and other reasons, I guess), but right now it's the best thing in the world because it guarantees that you have a new room with 6 walls, all edges ''overlapping'', wall/ceiling/floor thickness 32. (Side note: Why the &quot;hollow&quot; tool doesn't come with the option to automatically clip the resulting brushes is beyond me.)<br /> <br /> Overlapping brushes should be prevented &quot;at all costs&quot;. We'll do that now, too, which brings us to &quot;clipping&quot;.<br /> <br /> Did I say &quot;save the map&quot;? No, and I won't say that any more.<br /> <br /> While still looking from the top, try to select one of the four walls in the 2D view. It's tricky, isn't it? Now you see why you'll select stuff in the 3D view most of the time. But let's try the 2D view again. Press ESC. Then, box-select the middle part of one of the walls (which will also select other stuff). Then, box-select the center of this new room. Shazam, everything except the wall is deselected. Box-select inverts the current selection where it is in effect. Also, nice that we activated &quot;display size info&quot; in the preferences (&quot;orthographic&quot;) before, because now we can clearly see that all elements of the current selection have the position and size of the wall we wanted - which makes it reasonable to assume that only the wall is selected. Once your maps are a bit more complex, that assumption is not so reasonable. I think that it would save the mappers of the world tons of time if there were a simple but prominent number stating how many elements are currently selected. Well, rudimentary tool, as I said. Instead, you can see how many milliseconds it took the 3D view to redraw.<br /> <br /> Now that one wall is selected, choose a different tool. Currently, the button with the square on it is activated (&quot;Resize (Q)&quot;). Activate the button right from it, the one with the diagonal line (&quot;Clipper (X)&quot;). This tool can be used to cut away parts of brushes or to split them into two brushes. Reminder: The preferences of the &quot;clipper&quot; should be set to &quot;Clipper tool uses caulk&quot;.<br /> <br /> You have to cut away a small diagonal part of the wall in the corner. What we want to achieve is that the four walls do not overlap in the corner but do instead end exactly where the next one begins. Yes, you could just use the resize tool for that, but that's not how a good mapper does it (except when it makes more sense than clipping). Imagine: When the walls are clipped in the way I described it, then not just the outer walls will be perfectly connected, but the inner walls, too. So, when you paint textures on them, you can use the &quot;fit&quot; tool of the &quot;surface inspector&quot; (key &quot;s&quot;) to make the texture fit the wall perfectly while you can mostly forget about all the numbers in that window. Or, if you're dealing with the numbers, you can copy them from other surfaces because the other walls have the same special properties (brush corners clipped).<br /> <br /> Well, if you had drawn the walls edge-on-edge like you did with the outer map walls, painting the inner walls would be exactly as easy as the clipped result will be. But we want to paint the outer walls, too! This will be a room visible from the outside, hence it must be properly built.<br /> <br /> So, let's just try to clip one of the corners of the selected wall now. Choose one end of the wall, then click once on the corner that is outside of the room, then on the one that's inside of the room. Two blue dots (&quot;1&quot; and &quot;2&quot;) should have appeared. The line that connects them should point from the outside room corner to the inside of the room. Also, there is another line (the &quot;perpendicular&quot; or &quot;normal&quot;) beginning at the middle of the clip line. Both lines are not existing objects but just editor tools.<br /> <br /> Press ENTER. So, the brush was divided by that clip line you made, and now one of the two parts of the brush is gone. It's the one that the additional line (the &quot;normal&quot;) went through, that's the rule. Which way the &quot;normal&quot; points depends on the order in which you created the clipper points. Also, you can invert the clipper direction (menu &quot;brush&quot;, submenu &quot;clipper&quot;). Also, the brush part that will stay will have the clip face painted blue in the 3D view (as long as you didn't complete the clip by pressing ENTER).<br /> <br /> Clipper tips: You can drag the clip points around on the 2D view. You can even add a third point. You can change the 2D view from top to side etc. and then still drag the points around. And you cannot remove the clip points by pressing ESC. To remove them, you have to select a different tool (like &quot;resize&quot;) and then switch back to the clipper tool. Or just click again once all 3 clipper points are placed, because that will place number 1 again, removing the other two. Only if you click directly on one of them, you can drag them.<br /> <br /> Very frustrating: While the &quot;undo&quot; can be used to return to the unclipped brush, it does not return you to the situation with existing clipper points, so you have to place them anew.<br /> <br /> Now that you kinda know how to work the clipper tools, clip all 8 wall ends diagonally, so that the walls are perfectly face on face, not overlapping any more. So that the inner walls start and end exactly in the inner room corners.<br /> <br /> Wow, finally done with the stupid clipping. Let's paint and resize a few more blocks, right? No. The clipper tool is one of the most important tools in mapping, and you'll use it much more often than you can imagine right now.<br /> <br /> For example: It's time to clip the ceiling and floor so that they diagonally meet the walls - which, thusly, also have to be clipped. In the end, all 6 walls/floor/ceiling of the little room will be kinda like the bottom ends of pyramids pointing into the room, perfectly face to face which each other. During all this, you should leave the grid spacing on 32.<br /> <br /> Done yet? An experienced mapper needs 1 or 2 minutes to finish this properly.<br /> <br /> You might be wondering why we didn't just delete the ceiling and floor of the little room (after all, there's still the outer map ceiling and floor). Reason one: Using a map shell room like we did is a crutch. Not necessarily a bad one, but also not necessarily the way an experienced mapper does it. Reason two: You'd make yourself dependent on the outer ceiling and floor, and once you get out of the room and map some more, you'll have more dependency-situation-possibilities like this. You don't want to tie it all together and stand in your own way. I had that when making skybox. &quot;Can I texture this wall? No, damned, it's the outer wall again.&quot; Reason three: Lightmaps! I don't know how exactly it is decided how many pixels a lightmap has, but I am pretty sure that a huge brush will have a less high resolution (so, rather stretched) light map. Oh, speaking of which:<br /> <br /> ===_lightmapscale, gridsize, turbo rendering===<br /> <br /> (You can skip this now and go to &quot;enjoy the fruits of the clipping labour&quot;. One day, you should read this, though.)<br /> <br /> I already explained the worldspawn. Press ESC and select any one of the brushes. Since we currently only have simple worldspawn brushes (as opposed to, for example, doors), you could also just box-select a bunch of them. Anyway: Press &quot;n&quot; if the entity inspector was not yet visible. As you know, the second section shows a help text for the currently selected entity type, and since the third section shows &quot;classname worldspawn&quot;, the help text describes the worldspawn. Scroll far down (not to the end) until you see the explanation of &quot;_lightmapscale&quot;. Read it. Then, write &quot;_lightmapscale&quot; and &quot;0.25&quot; into the &quot;key&quot; and &quot;value&quot; textboxes and press RETURN while you're in the value textbox. I thoroughly tested it in a relatively small room: Values smaller than 0.25 don't increase the lightmap resolution any more.<br /> <br /> Setting the lightmapscale to 0.25 will result in a higher lightmap resolution, so you'd have better shadows etc., think of the difference between the thumbnail of a picture and the full size version (only the difference is not that drastic here). The default setting is &quot;1.0&quot; (when the _lightmapscale key is not present). 0.25 also means that the LIGHT phase, in which the lightmaps are calculated, will take much longer. This also means that larger settings than 1 will make it shorter.<br /> <br /> If you've followed this mapping crash course so far, you'll either have prepared q3map2 frontend &quot;q3map2build&quot; or a build batch file, and you will have done so that the light rendering result is very good:<br /> <br /> &quot;fast&quot; is not activated. &quot;bouncescale&quot; is on 2, &quot;bounce&quot; is on 500 (meaning: effectively &quot;6&quot; or something). And to top it off, your map now has the best lightmap scale. The option &quot;filter&quot; is not relevant for the calculation time. It will smooth the resulting lightmap a little so that shadow seams don't look so pixeled. I am not repeating all this from other guides, these are actual experiences that I gathered in many tests over months.<br /> <br /> Now, as long as your map is very small, these settings are ok. Calculation will be done in a few minutes or less than a minute. But once your map is a huge monstrosity, calculation with these settings takes several days on a fast computer. That's still ok as long as you have an extra machine for things like these, but '''here's how you can speed up the rendering like crazy''' (resulting in less good result, of course):<br /> <br /> Add the key &quot;gridsize&quot;, value &quot;1024 1024 1024&quot; to your worldspawn (default would be 64x64x128 as far as I know, and to achieve default, just delete the key again). As far as I know, the gridsize defines the ''volumetric'' lightmap calculation. If you get closer to a bright red spot in the map, your weapon will receive red light. If the gridsize is as coarse as we have set it here, those effects will be less prominent. I could be totally wrong about this. Maybe the gridsize is more about how the raytracing really takes place. In any case: Changing the gridsize has ''huge'' (!) impact on the calculation time. Setting it to this value will make it faster. Deleting the key, so that you're back on the (very good) default value makes it slower. Setting the gridsize to something like 48x48x48 increases the calculation time insanely, and as far as my test results go, it doesn't have any merit. So: For high quality results, you'd use the default setting. For quick and less proper results, you use the 1024 (or an even rougher) one.<br /> <br /> You can also drop the &quot;bouncegrid&quot; option. Bouncegrid means that before every radiosity bounce, the lightgrid (see &quot;gridsize&quot;) is calculated anew, because somethingsomething bounce influence grid somethingbla. Honestly, I didn't test the difference it really makes, but I believe that it's safe to assume that this option increases the light rendering quality even further.<br /> <br /> Change the rendering settings (in &quot;q3map2build&quot; or your batch file) so that the LIGHT phase uses the key &quot;-fast&quot;. This does not change the lighting ''very'' much (but still too much for my taste when I want to make a real proper release), but it insanely reduces calculation time.<br /> <br /> Removing the &quot;bounce&quot; option (&quot;bouncescale&quot; is irrelevant for the time (except in regards of the caused number of iterations) and is bound to &quot;bounce&quot;, so you don't have to touch it here) has strong influence on the lighting. You should try to have a few bounces in your released maps, the light looks considerably more natural. Removing the &quot;bounce&quot; option decreases calculation time, though. Very much even. If the initial pass (not yet bounced) takes 10 seconds, every bounce will also take about 10. If the first took 1 day, guess what. Depending on the bouncescale you used, the amount of bounces will have strong influence on the lighting result. This is something for tweaker guys. Just as the &quot;gamma&quot; option (that I didn't mention yet) in the LIGHT phase is. You should know that these options exist and that it's a good idea to toy with them. Now let's move on.<br /> <br /> Another option that you can add to speed up calculation: &quot;-fast&quot; in the VIS phase. Please don't do this, though, if you want to release the results into the public. And definitely don't release the result if you omit the VIS phase completely - which you can also do to decrease rendering time even more. The VIS phase calculates which spot of the map can be seen from which other spot. This information allows the game engine to draw only the necessary graphics. As far as I know, it also influences the radar functions of helmet and aliens. It's essential for a release, and you should do it without &quot;-fast&quot; for a release.<br /> <br /> '''In short:'''<br /> <br /> '''For fast rendering''', add &quot;-fast&quot; to the VIS phase (or drop it completely), add &quot;-fast&quot; to the LIGHT phase, remove &quot;bounce&quot; from the light phase (or just &quot;bouncegrid&quot;, but I think if you're already doing bounces, you might as well do them properly), remove the &quot;_lightmapscale 0.25&quot; thing from the worldspawn, add &quot;gridsize 1024 1024 1024&quot; to the worldspawn.<br /> <br /> '''For best (slow) rendering''', have a not-fast VIS phase, not-fast LIGHT phase, bouncegrid, bounce 500. Remove &quot;gridsize&quot; from the worldspawn. Add &quot;_lightmapscale 0.25&quot; to the world spawn.<br /> <br /> If you want to see a map that rendered for 112 hours with lightmapscale 0.25 and 11 radiosity bounces (Then it was tuesday morning and I needed the computer :/ Yes, you can abort the calculation at any time. Previous bounces will still be existent, and the current half-done one will also not be visible.) and want to see what the higher lightmap resolution might do to a 128MB graphics card, take a look at [[Gmotw_Skybox]]. I'm not really proud of the rendering result. There should be more shadow cast situations and so forth, but it's the best I have to offer in that regard yet. I think the lightmap can best be enjoyed in and above the pump station.<br /> <br /> ===enjoy the fruits of the clipping labour===<br /> <br /> Inspect the result of your work. It's very useful that you can move the camera to the inside of a wall, making it temporarily vanish from the 3D view.<br /> <br /> While you were working on the clipping, I picked a nice texture to demonstrate the described advantages of clipped walls. The texture browser should still be in the &quot;karith&quot; section, showing the &quot;cement_3&quot; texture (near the top). Scroll a bit further up until you see a broad texture called &quot;base_grooved&quot;. (Well, you might have a hard time finding it if there's another texture with a long name to the left of it, because then, the name on screen is partly overwritten. As I said: Rudimentary tool.) It should be the 8th texture. Press ESC and then click on the texture. At the bottom of the screen, there should be a text saying &quot;textures/karith/base_groove...&quot;. The texture looks like someone used a comb on a gray piece of butter from the left to the right.<br /> <br /> Now, select one of the faces inside the little room, then click on the texture. If you have done everything like I described, you'll see the texture on the wall, but there's something like a split in its middle. What you see are the outer ends of the texture. Textures are always looped on the brushes, so now lets place this texture properly. Press &quot;s&quot; (if the surface inspector was not already visible), then click &quot;Fit&quot; (if there is a 1 in both text boxes beside the fit button, otherwise set the boxes to 1 (or 1.000000, it's the same)). That was easy, wasn't it? Imagine what would have happened without the clipping. The texture would be partly hidden. If you look at the surface inspector and the numbers in it, can you imagine the hassle of adjusting everything until it looks like it does now?<br /> <br /> If you look at the horizontal and vertical stretch, you see something between 0.5 and 1 (and they are different - thank the programmers for the &quot;fit&quot; button). That's kinda ok-ish, but smaller values mean higher texture resolution. Only we can't put the texture in twice because that doesn't look good, either. The &quot;width&quot; and &quot;height&quot; value next to the &quot;fit&quot; button, by the way, define how often the texture is to fit the surface when you click &quot;fit&quot;. Yes, &quot;0.5&quot; etc. works, too.<br /> <br /> Paint all four walls in the described manner. You can do them all at once.<br /> <br /> After that, paint floor and ceiling with the next texture in the list, &quot;base_small&quot;, and fit it in 1 by 1. Again, this wouldn't have worked so easily without clipping. The horizontal and vertical stretch are close to 2, which is much too high. You can already see how blurry and cheap it looks. But keep it for now.<br /> <br /> ===let's add a door===<br /> <br /> Look from the top in the 2D view. Set the grid spacing to 128 (key &quot;8&quot;). Select one of the 4 walls. Just for training, let's use the toggle-selection, so press and hold SHIFT and ALT, then click on one of the 4 walls a few times until it is selected. You don't have to press ESC before this.<br /> <br /> With the wall selected and the clipper tool active, click on the wall. Gridwise, it has 4 sections. Click so that 3/4 of the wall would be cut off. Umm, where to put the second clip point? The grid doesn't allow to put it on the wall! Well, doesn't matter. Just put it a bit further away. Only the direction and position of the line itself must be correct, not its length. If you have made a nice (and non-diagonal) clipping line, press SHIFT and ENTER or select &quot;split selection&quot; from the &quot;brush&quot; menu, submenu &quot;clipper&quot;. You have cut the wall into two segments. Do that again on the other side, so that the middle segment is two grid elements in size. By the way, you can join brushes if the result would &quot;make sense&quot; (convex brush) using menu &quot;brush&quot;, submenu &quot;CSG&quot;, item &quot;CSG merge&quot;. If you try to merge brushes that can't be merged, you'll see an error message in the log area.<br /> <br /> Ok, now deselect everything (ESC). Then '''select the middle part of the split wall. Then, right-click in the 2D view, go to &quot;func&quot; and select &quot;func_door&quot;. You just made an automatic door''' that opens to the side if you get close, complete with sound. Nice, huh? Let's change the angle to &quot;top&quot; by adding the key &quot;angle&quot;, value &quot;-1&quot; in the entity inspector.<br /> <br /> You could actually make a door that uses a sensor that only reacts to someone carrying a lucifer cannon. Or to dretches and dragoons. Then, a sound would play and dark light would go bright (without lighting the environment, though (then again, I think it can be done using a shader with specular lighting)). Bars in front of the door would move to the sides (with sound). Then, the door would ''rotate'' open kinda like a garage door. Later, everything would move back. This can really be done using triggers, delays and so forth. But dude, I'm not gonna guide you through that.<br /> <br /> You can adjust the door in the &quot;entity inspector&quot; (&quot;n&quot;). You can change the sound, the direction into which it opens, how much of it is still visible once it's open, whether its default is open or closed, how much damage it does to you if you stand in its way, how fast it moves and more. The &quot;lip&quot; value is especially useful. You know, a door is just a brush (or a bunch of brushes - yes, '''you can make complex designs and have them move as one unit''') that moves. It has convenient defaults and a sensor. But you don't need to use the sensor. Also, '''you can use huge negative values for the &quot;lip&quot;, making the door move much further than necessary when it opens. And what is that then? A lift! :)''' There is also an extra lift function, but its default sounds are broken, and also it cannot be set to &quot;crusher&quot;, as far as I know. The big lift in skybox is a door, consisting of several brushes. '''Doors are really versatile.''' You know what? I once used doors to make a programmable soundtracker in Tremulous (&quot;gmotw_pianolessons&quot;, named like this because there's also a big piano with black and white keys that you can step on, and guess what, they are all doors). 16 doors would hammer down in a sequence, and their &quot;I'm closed now!&quot; sound wouldn't play if they don't arrive at the closed state, so I just made buildings in their way to program the sound steps. Did I say that doors are versatile yet? A server where you can save the current building layout can then even save the rhythm for later! Problem is, once too many elements are used, the rhythm stumbles a bit. Maybe a faster computer or newer Trem client doesn't have that problem. I used 16 steps and 3 instruments (bassdrum, snare, closed highhat), and it already got a bit stumbly. Another thing you can do with a door is use it as a busy-light that appears from out of nowhere (was hidden in a wall) and vanishes once the busy cycle (lift or whatever) is over. Also, I once made a door that actually consisted of 8 by 8 doors that you had to shoot. It was a pixel-door. If you didn't shoot the pixels away fast enough, they would return and you wouldn't get through. A tyrant (or whatever) filter. A dream if you carry a lucifer gun. That was in skybox, but I had to remove it in later releases because with all the other map elements, it reduced the FPS too much. But the door maze is still in the map. Looks like solid walls, but it is a small 2D maze. No, even 3D.<br /> <br /> Now, press &quot;h&quot; to hide the door and move the camera so that you look at the room from the outside. We'll now paint the frame of the door. Use the texture &quot;base_verts&quot; which comes shortly after the &quot;base_small&quot; that we used for floor and ceiling. Select the two faces at the side of the opening. Click the texture. Click &quot;fit&quot;. If you look at the stretch values, you see that one is 0.5 and the other 0.25, which can look odd, so better enter a &quot;2&quot; instead of the &quot;1&quot; in height (next to the &quot;fit&quot; button) and click &quot;fit&quot; again. The texture is now used 2 times in height, so it is not as streched in that direction. Press ESC. Then select the upper and lower face of the opening. Click the texture. Looks wrong. Now what? Well, it needs to be rotated. If you look at the &quot;rotate&quot; text box, there is a &quot;0&quot; in it. The text boxes on the right side can be changed at any time without influencing the map in any way - they are only an editor tool. The box right to &quot;rotate&quot; should have a &quot;90&quot; right now. If so, click the up or down arrow (doesn't really matter now) of the rotate value, changing it to 90 or -90 degrees. The texture looks better now. Click &quot;fit&quot;. Damn, bad stretching. Change the height preference to &quot;4&quot; and click &quot;fit&quot; again. See? The &quot;height&quot; now means &quot;width&quot; because the texture is rotated.<br /> <br /> If you look now from the inside of the room, you'll see that the wall (not frame) texture is cleanly cut, as it should be. If you would want to apply and fit the texture now, you'd have problems. '''To use &quot;fit&quot; on a surface with the &quot;wrong&quot; size, temporarily resize the wall to an appropriate width, click &quot;fit&quot;, return the size to normal again.'''<br /> <br /> Paint the 3 outer walls with the texture we used on the inside walls (for that, select an inside wall surface and use CTRL and C, which will not just copy the texture settings, rotation and so forth, but will also select that texture in the browser, so you can just click it then instead of using paste). Don't forget to fit (1x1). Paint the two short front walls with the texture &quot;base_v_rigged&quot;. Fit them in (1x1). By now, you'll have realized that the textures are sorted by alphabet. <br /> <br /> Press SHIFT h to get the door back. Press ESC. Select the door. Press i or choose &quot;invert selection&quot; from the edit menu. Press h. Now, only the door is visible, and it obviously needs some texturing. Put &quot;base_small&quot; on the outside and inside (fit 1x1).<br /> <br /> The four outer sides of the door are still unpainted. Let's select them all at once and then apply &quot;base_verts&quot;. Fit them 1x1. There's a problem: Even though the stretch values on the side surfaces are different from the top/bottom surfaces, you only see one number pair. Keep that in mind, also when dealing with the entity inspector while several elements are selected. A common reason would be to copy the values of one door to another. Select the correct door first, the one you want to fill with values as second, and for every value that you want to copy, click it and then press ENTER in the &quot;value&quot; text box to re-apply the key-value-pair to the correct door, which will also copy it to the other(s).<br /> <br /> So, let's do this again properly (and maybe you have already realized that this is all wrong, then follow me without acting, also smile). Press ESC. Select both side surfaces. Click &quot;fit&quot; with 1x2, so both stretch values should become &quot;0.25&quot;. Select the top and bottom, rotate the texture by 90 degrees, fit 1x2. Why not 1x4 like the same surfaces of the room walls? Because the surfaces of the room walls didn't begin/end at the door opening! So, we have a few meters of unnecessarily painted faces there. I don't know if a real pro mapper would now fix that by causing a few more brushes or if they would just ignore the few meters of unnecessary texture. We'll just leave it at this now. Don't tell anyone.<br /> <br /> The door is now painted on the front, back, and on the other 4 sides. Unnecessarily. The reason is that we didn't think enough like a mapper should, instead we were stuck too much in real-world thinking. Since you will never get to see the left, right and top side of the door, we should apply the Caulk shader to them.<br /> <br /> The texture browser has a little drop down menu, too. Go into that &quot;view&quot; menu and click &quot;hide unused&quot;. This hides all textures from the texture browser that are currently not used by the map. Even better: Also select &quot;show all&quot; from the same menu. Now, every texture that you had loaded in this program session (except the unused ones because you just hid those) is in the texture panel. You should memorize this trick, it will make your mapping much easier. For example: The caulk shader is here! Apply it to the left, right, and upper surface of the door. Then press SHIFT h to unhide everything.<br /> <br /> Press ESC. Select the door. Go to the entity inspector. Add the key &quot;lip&quot;, value &quot;80&quot; to the door, because otherwise it would look kinda weird while open. A bit of its lower end would stick out of the ceiling without any apparent cavity or mechanism for the door. With &quot;80&quot;, it sticks out so far that no one will ask questions.<br /> <br /> This, by the way, makes another surface's texture unnecessary. Since I don't plan on toying around with the door some more, let's set that surface to caulk, too. So: Hide the door. Then look from the outside. The upper diagonal surface will be invisible because the door will never reveal that surface.<br /> <br /> ===let's populate the map===<br /> <br /> Add an &quot;info_player_intermission&quot; entity. (I won't tell you how because I already did. If you didn't read the whole truckload of text, use the in-page-search function of your browser.) Move and rotate the entity so that it looks at the door of the little room from the outside, from a bit further away, slightly diagonal so that you can see the side wall of the room, too, and much of the rest of the map.<br /> <br /> Press the &quot;1&quot; key for the highest grid resolution that you can achieve with the keyboard. In the room (top view in 2D), create a &quot;team_human_reactor&quot; entity. Move it around a little. Then press &quot;8&quot; for grid spacing &quot;128&quot;. Move the reactor again. You see that the amount by which it moves is 128, as the grid forces it to. But its position is kinda off (if we're not unlucky). To force the reactor back into a nice x y and z grid position, press CTRL and &quot;g&quot; or use &quot;snap selection to grid&quot; in the &quot;brush&quot; menu. Now, with the 128 grid, move the reactor as far into the corner as possible. I don't care which one, as long as it's not on the door side. Switch the 2D to side view, set the grid to &quot;7&quot; (64), drag the reactor to a reasonable height position. It must not be in or above the ceiling and not in or below the floor.<br /> <br /> Rotate it around the Z axis by 90 degrees until the nice control panel can be seen. You might even want to rotate it arbitrarily by 45 degrees and then in 90 degree steps until it nicely faces the room.<br /> <br /> Also build an armory, a medistation, two nodes and a few turrets. Give them enough space. Especially the armory is tricky. Too few people know that '''the game system only allows square [[Hitbox|hitboxes]]'''. The height can vary, but the shape when seen from top is square. Even the armory? '''Yes, even the armory.''' If you keep that in mind, it will explain every occasion on which the armory or a nearby building didn't appear in the game.<br /> <br /> You should already rotate the turrets so that they face the door. This is not a [[Building|base building guide]], so I'll stop here.<br /> <br /> Don't forget to make a few alien buildings (overmind, SPAWN!, ...) somewhere in the outside hall.<br /> <br /> Then add &quot;player_human_intermission&quot; and &quot;player_alien_intermission&quot; (one of each) and make them look at the human and alien base.<br /> <br /> You can have a look at the map if you want, even though we haven't placed any lights yet. Just omit the LIGHT phase. Everything will be at full brightness. The batch file:<br /> <br /> &quot;C:\Program Files\netradiant-20100214-win32\q3map2.exe&quot; -fs_basepath &quot;C:\Program Files\Tremulous&quot; -fs_game &quot;base&quot; -custinfoparms -info -meta -patchmeta &quot;C:\Program Files\Tremulous\base\maps\scr5_dretchnest.map&quot;<br /> &quot;C:\Program Files\netradiant-20100214-win32\q3map2.exe&quot; -fs_basepath &quot;C:\Program Files\Tremulous&quot; -fs_game &quot;base&quot; -vis -saveprt &quot;C:\Program Files\Tremulous\base\maps\scr5_dretchnest.map&quot;<br /> &quot;C:\Program Files\Tremulous\tremulous.exe&quot; +set fs_basepath &quot;C:\Program Files\Tremulous&quot; +set fs_game base +devmap &quot;scr5_dretchnest&quot;<br /> <br /> ===lighting===<br /> <br /> On second thought, you should definitely look at the map right now. With full brightness, it sucks. Once we've added nice lighting, it will look so much more pleasant. Lighting makes and breaks the mood.<br /> <br /> Just as decorations (which we haven't dealt with yet) are not a burden but a passion to a real mapper, lighting is not something to be dealt with by just throwing strong point lights with no apparent light source (fixture) all over the place. And definitely '''''do not'' use the &quot;_minlight&quot; or &quot;_ambient&quot; features in the worldspawn.''' You might use them sometimes - really rarely - to test something, but a map with proper lighting will, I dare to claim, never have one of these features in use.<br /> <br /> '''There are two possible light sources:''' Point lights (which can be made with the right-click menu) and light textures (or light shaders, same thing, different term). We have already dealt with shaders. It's possible to make shaders with a parameter that makes it emit light. The larger the surface that uses the light shader, the more light is emitted. The advantage of using light shaders is that you always have a &quot;something&quot; that the light is actually coming from. This contributes considerably to the mood, because it is more believable. You can, of course, just build a &quot;something&quot; that might be a light, then add a point light source to it. That works, too. Actually, the main reason people rarely do that probably is that you can't group brushes and point lights together. You see, the &quot;worldspawn&quot; entity is not the only &quot;dead&quot; entity that can hold brushes. '''You can also select a bunch of brushes and then select &quot;func_group&quot; from the right-click menu.''' This creates a new entity of type (or &quot;classname&quot;) &quot;func_group&quot;. You cannot add other entities (like light or a doorbrush) to such a group which is sad, because if you could, people would probably also try to construct light fixtures and then just put a point light into them instead of fiddling with shaders. And what is the advantage of such a group? Well, if you select one of its brushes, you can then use &quot;expand selection -&gt; to whole entities&quot; from the edit menu. You can then conveniently move them around or copy/paste of them - which creates a new func_group with the copied brushes in them. The expand selection function also works for several such things in parallel. Sadly, I haven't yet found out how to add another brush to such a group. &quot;regroup&quot; in the &quot;entity&quot; menu does the opposite of what you'd expect, and I haven't tried the next function, &quot;ungroup&quot; because I suspect that it does what you'd expect.<br /> <br /> ===decorations, structural/detail brushes===<br /> <br /> <br /> <br /> ===create a release file===<br /> <br /> <br /> <br /> [[Category:Mapping]]</div> Wed, 14 Jul 2010 14:49:01 GMT God, maker of the world http://tremulous.net/wiki/Talk:Mapping .pk3 http://tremulous.net/wiki/.pk3 <p>God, maker of the world:&#32;</p> <hr /> <div>.'''PK3''' files are used in games based on the Quake III engine. They are just simple ZIP files that have been renamed to have the file extension &quot;.pk3&quot; instead of &quot;.zip&quot;. (For this reason and overall security improvement, Windows users are urged to turn the display of file extensions on. In any file explorer window, go to the &quot;Tools&quot; menu, select &quot;Folder Options&quot;. At the top of that new window, click on &quot;View&quot; and then scroll down until you see the option &quot;Hide extensions for known file types&quot;. Turn it off and click &quot;Ok&quot; at the bottom of the window.)<br /> <br /> .pk3 files can contain any game assets like weapons, textures, music and so forth. They are just containers for more files. .pk3 files can be created/opened with any archive program that supports the ZIP file format. There are also programs specially designed to create .pk3 files (like for example [http://www.google.com/search?q=pakscape pakscape]), but they are not necessary to make a proper file.<br /> <br /> The most common use of .pk3 files in the Tremulous world is to store/distribute game maps.<br /> <br /> A map .PK3 file contains the [[map]], [[texture|textures]], [[sound|sounds]], [[shader|shaders]], the [[arena file]], and the [[levelshot]] which is displayed while the map is being loaded. (also see [[File Extensions]])<br /> <br /> <br /> <br /> ==File Names and Uniqueness==<br /> <br /> It is important to know that, on program start, the Tremulous clients read the content list of all .pk3 files that are in the game's &quot;base&quot; folder(s) into a list that is held in memory. The file &quot;map-atcs-1.1.0.pk3&quot; file, for example, contains the standard folder &quot;maps&quot; which contains the file &quot;atcs.bsp&quot;. The bsp file is the actual 3D map environment in which you play. This (&quot;atcs&quot;) is the real name of the map that you can use with the [[map|/map]] command. The long name &quot;A.T.C.S.&quot;, which is displayed in the map vote menu and in the map list you see when you create a server, is not the name of a file. The long name is created by the arena file which is stored in the standard folder &quot;scripts&quot; of this .pk3 file.<br /> <br /> All of these files are known to the Tremulous client when it starts. But there is a catch: Because of the .pk3 approach to file storing, it is possible to have a file with the same path and name existent several times. The Tremulous client will &quot;forget&quot; the previous occurrences of a file once it encounters another file with the same path and name. This is the reason that you might have .pk3 files with names like &quot;zzzchristmastextures.pk3&quot;. This example would be a file that is explicitly designed to override existing textures with new ones, therefore a name was chosen that would be dealt with after most other files.<br /> <br /> '''You have to keep this file behaviour in mind when you create a map. You have to choose unique names, or your maps will cause trouble or get into trouble with other maps. This is also especially important for a newer version of your own map: You cannot expect people to delete all older versions of your map from their servers and game computers, so when you release a newer version of a map, the changed files (e.g. the shaders) MUST have a different name.''' One way to deal with this is to add the version number of the next map release to the new file that you add to your map. So, if your next map release will be &quot;mymap_003&quot;, the texture you add now into your map could have the name &quot;brickwall_003.jpg&quot; to ensure that you stay compatible with your own creation. This does not mean that the file is meant to be valid only for release 003. It is meant to say that this file was added to the map between release 002 and 003. If you change this file between release 005 and 006, you would delete the ..._003.jpg and name the new one ..._006.jpg. Obviously, you would have to replace all occurrences of the old version of the texture in your map with the new one, but that's not as much work as you would think: Make a backup of your .map file, open the original map file with a text editor that has a &quot;search and replace&quot; feature, and use it to swap the old texture name for the new one. It's really that simple. (It might be even simpler: In NetRadiant's texture browser, there is a &quot;tools&quot; drop down menu with the function &quot;find/replace&quot;. That might do the trick, but I never tested it.)<br /> <br /> '''The uniqueness problem is even more complicated:''' The shaders contained in the shader file(s) also create entries in the Tremulous clients' temporary file list. So, this list is not just filled with the content lists of the .pk3 ZIP files but also with the content of all found shader files. The first shader in the file &quot;atcs.shader&quot; in the &quot;scripts&quot; standard folder inside of the atcs .pk3 file, for example, is called &quot;textures/atcs/skybox_s&quot;. This means that the short shader description text that follows underneath this name will be handled as if it were a real existing file called &quot;skybox_s&quot; stored in a real folder &quot;atcs&quot; in a real folder &quot;textures&quot;, even though none of these really exist. They only exist in the .pk3 file. '''If any other .pk3 file contains a shader file with a shader named &quot;textures/atcs/skybox_s&quot;, it will interfere with the atcs map. You really have to make sure that you choose proper directory and file names, even though these files are only virtual.'''<br /> <br /> So, when you change a shader from one map release to the next, you would have to deal with that just in the way that you deal with a texture update - as described further up. Give them version names. And replace the occurrences.<br /> <br /> ''Actually, I don't know if the shader files themselves do also have to have unique names. Theoretically, the client would read all shader files in all .pk3 files and would add the contained shaders to the file list in memory. So, the shaders themselves definitely have to be treated with the described uniqueness thinking. Maybe the shader files themselves can have the same name, for example from map release to map release, even if they change. I don't know. But there's nothing wrong with playing it safe. Changing a shader file name does not even require you to change anything in the map, so better safe than sorry.''<br /> <br /> The root directory that the Tremulous client uses to think about these directory and file names is the &quot;base&quot; folder of the Tremulous installation. There can be multiple &quot;base&quot; folders, for example one in the installation folder and one in the user data folder.<br /> <br /> The files and folders found in the .pk3 are used by the Tremulous client as if they were really existing, and so it is no surprise that you can have real existing &quot;textures&quot;, &quot;maps&quot;, &quot;sound&quot;, &quot;scripts&quot;, &quot;env&quot; etc. folders in your &quot;base&quot; folder. And, just like in the .pk3 files, you would have subfolders in your physical &quot;textures&quot; folder named like the maps those textures are an asset of.<br /> <br /> These physically existing folders (which are not existing in a fresh Tremulous installation but which can just normally be created by you) actually are the source of all those .pk3 files that you meet on the Internet: Someone made a map and then copied all physically existing files from the really existing folders (like &quot;textures&quot;), but only the ones needed by the map, into a separate temporary folder tree, upholding the original directory structure and the file names. Then they created a .zip file from this temporary folder tree (whereas all the mentioned assed folders must be directly in the root of that .zip file), and then they renamed it to .pk3 - that's really all there is to it!<br /> <br /> While we're at it: If you make a .pk3 file, you should properly test it. This means: Delete the file &quot;data-radiant-1.1.0.pk3&quot; from your base folder(s). Also, delete all non-standard maps from your base folder(s) - only leave the ones that came with the original Tremulous 1.1.0 installation (arachnid2, atcs, karith, nexus6, niveus, transit, tremor, uncreation). Copy your new .pk3 into the base folder. Start the Tremulous client and try to create a server choosing your new map from the map list. Look around if you see missing textures. Missing textures are usually easy to recognize: They are grey with a white square grid. Check for missing sounds: If you start a lift which uses a missing sound file, an error message is temporarily displayed on your game screen and stored in the console text buffer.<br /> <br /> If you really want to make sure that your test is proper, you'd want to rename your asset folders (textures, sound, ...), too. The files in those folders should be ignored automatically if your client is set to [[sv_pure|sv_pure=1]], but it's simple to create a batch file that renames the folders.<br /> <br /> ==Map PK3 Name Conventions==<br /> <br /> The .pk3 file should have a name like this: &quot;map-atcs-1.1.0.pk3&quot;. It consists of three parts plus the file extension. The parts are separated by a &quot;-&quot;. The first part ensures that all the map files in one folder stay together alphabetically, also it tells a human reader that this file is a map which is helpful because a .pk3 file can contain any game asset, not just maps. The second part is the name of the map itself. It should be perfectly identical to the name of the actual map file in the .pk3 (but without the .bsp extension). The third part tells the Tremulous version for which this map was designed. This does not refer to the Tremulous client version but to the actual Tremulous rules and behaviours that are used. You are probably aware that Tremulous 1.2 is in the works. Some changes will affect the way old maps play. The battlesuit, for example, is slightly taller, and so it does not fit through small openings that the 1.1.0 battlesuit would have fit through. A &quot;1.1.0&quot; in the name does not mean that the map will not work with later Tremulous versions. It just expresses which version the map authors had in mind when they made the map.<br /> <br /> Choosing a good map name is of course very tricky. You should definitely stick to the name that you chose once you have had a public release of the map. Also, as said, you should keep the name of the .bsp file (which is the map itself) and the second part of the .pk3 file name perfectly identical.<br /> <br /> The problem of name uniqueness can easily be overcome if you decide to add an author name to the beginning of each map name. Sadly, no one does this, so the global map name space probably has at least five maps called &quot;reactor&quot; or &quot;spacestation&quot;. If you have a player or forum name like &quot;j4ck&quot;, why not use this as part of your map names? This would also keep all your maps alphabetically in one place in the map repositories that hold hundreds of maps. Your map distribution file would be called &quot;map-j4ck_spacestation-1.1.0.pk3&quot;, the map file itself (in the &quot;maps&quot; folder of the .pk3) would be called &quot;j4ck_spacestation.bsp&quot;. Definitely use &quot;_&quot; and not &quot;-&quot; to separate these multiple parts.<br /> <br /> A file name like &quot;map-j4ck_spacestation_003-1.1.0.pk3&quot; (The 003 is for the release version.) might seem very complicated, but the Tremulous world deals with many files from many people, and so we have to keep it somewhat systematic.<br /> <br /> [[Category:Mapping]]</div> Wed, 14 Jul 2010 14:21:31 GMT God, maker of the world http://tremulous.net/wiki/Talk:.pk3 Mapping http://tremulous.net/wiki/Mapping <p>God, maker of the world:&#32;/* obtain a frontend for q3map2 */</p> <hr /> <div>A [[mapper]] is a person who creates a game [[map]]. He is &quot;mapping&quot;. This article describes how that works in the Tremulous context. For a list of a few existing Tremulous maps, click [[:category:Maps|here]].<br /> <br /> <br /> =mapping crash course=<br /> <br /> I started this article on 2010-06-29, just so you know why it doesn't refer to Tremulous 1.2 etc. I am a Windows user (2000 and XP), so that's the perspective that I use. If you can't translate that into your perspective, then you probably shouldn't use the system you're using.<br /> <br /> There are already several mapping guides out there ([http://tremulous.net/forum/index.php?topic=7497.0 list]), one of the best of which is at [http://tremmapping.pbworks.com/ tremmapping.pbworks.com]. It is easy and very comprehensive. I'll try to write a new one from scratch here based on my experiences - and much more up to date. It will save you some steps that were necessary 3 years ago when the linked guide was made. This article here will not enable you to make good maps, but it will give you a truckload of know-how of the kind you don't find in other mapping guides.<br /> <br /> If you've ever written something like a guide, you know that you'll inevitably get into ramble mode from time to time. I guess you can forgive me that.<br /> <br /> <br /> ==setting up your computer==<br /> <br /> ===Tremulous client===<br /> <br /> Download and install the original Tremulous 1.1.0 client. It can be found [http://tremulous.net/files/ here], but it's all over the Web, just search. Now, you ''could'' use a different Tremulous client, but I suggest that you don't. Reason: The original client is what many people out there still use, and when you test your map, you'd want to see what it looks and behaves like (and if it works at all) in the client all those [[newbie|noobs]] use who wouldn't know how to fix a problem if your map causes it. You want your map to work and to shine in the original client. You don't want it to look great only in the latest client with magical rendering v9.9.999 and bloom effect.<br /> <br /> Maybe also download the [http://tremulous.tjw.org/backport TJW backport] client. It's a slightly updated version of the original client. Not too new to violate what I said in the previous paragraph. This is not a full Tremulous release. It's just the program itself. Put it into the program folder of the above mentioned original client. This client supports [[GUID]] and much faster auto-[[Cl_allowDownload|download]].<br /> <br /> You might already have all this. But consider starting anew in a VirtualMachine or on a new computer. If you're more proficient, you'll be able to maybe clean up all your Tremulous base folders so that you don't have magical conditions that a person using the naked client wouldn't have. If you're not proficient enough in this and don't want to make a clean install, prepare to experience problems like &quot;But the texture wasn't missing on my machine!&quot;.<br /> <br /> ===NetRadiant===<br /> <br /> Now the most important part: Download and install [http://ingar.satgnu.net/gtkradiant/installation.html Ingar's NetRadiant and the Tremulous support files]. That's two downloads. The instructions on the linked page are short and comprehensive, it's easy to do. [[NetRadiant]] is the tool that you actually make the maps with. You probably also heard about &quot;GtkRadiant&quot;. Forget it. It's 99% the same as NetRadiant, but it's no longer developed. Also, installation is more complicated because it is not prepared for Tremulous. Additionally, Ingar's NetRadiant already includes the [[Q3Map2]] program that compiles your .map document to a playable .bsp map file.<br /> <br /> Change the NetRadiant preferences (and learn a few things about them): Start it. You'll probably see a little window offering a game type selection. Choose &quot;Tremulous&quot;. There's also a checkbox to prevent this window from appearing every time you start NetRadiant. Technically, that was all. But please, continue adjusting the preferences: Go into the preferences window, which can be found in the &quot;edit&quot; menu at the bottom. I'll go from top to bottom, not from most to least important.<br /> <br /> '''Textures:''' Later, you might want to change &quot;gamma&quot; to something like &quot;0.8&quot; to make the 3D display of the editor brighter. '''Undo:''' Increase queue size to 128. You'll use undo very often, sometimes to undo shifting textures around, and that's an undo step for every texture shift step even if it was a button autorepeat result.<br /> <br /> '''Brush:''' Definitely activate &quot;Always use caulk for new brushes&quot;. You can also activate &quot;Use alternative texture-projection&quot;, but most people do not do that, so if you want to open their maps, you'd have to turn it back off and restart the program. And there is no way to convert a .map from one setting to the other. If you decompile a playable map you found somewhere (like ATCS etc.), you would need to use the alternative projection to load the result in NetRadiant, so why not completely live in that world? I, however, have not done so. Because I didn't know better when I started mapping. I also don't know if I would ever regret turning this option on to make my own maps, so be careful. Maybe better leave it off.<br /> <br /> '''Grid:''' Set default grid spacing to &quot;32&quot;. That's the smallest room-wall-thickness that you want to use to prevent [[light bleeding]] (though the best measure to prevent light bleeding still is clipping). Once you're an experienced mapper, you might want to set this to &quot;256&quot;, the largest setting. '''Camera:''' Movement Speed 100 is good, but you'll come back later and change this, depending on your mapping situation. (I think NetRadiant should have a control element on the edit window to adjust the camera more quickly.) Smaller value for working on details, larger value if you have to travel a lot with your editor camera. Enable far clip plane: It's best to turn it off for now, you'll see everything then, no matter how far away it is. Enabling this option and setting the far plane to something close (menu &quot;view&quot;, submenu &quot;camera&quot;) would be helpful for selecting stuff with the box selection. Also, depending on your hardware and the map, it can speed up display considerably.<br /> <br /> '''Orthographic:''' Turn on &quot;display size info&quot; which will show you the size of one or more selected objects in the 2D view. Turn off &quot;chase mouse during drags&quot;, it would turn you crazy. '''Clipper:''' Definitely activate &quot;clipper tool uses caulk&quot;. '''Autosave:''' Deactivate it. If you're not a total computer noob, you'll know and use CTRL+S oftentimes anyway, and the autosave feature really gets in the way. The coders don't even reset the autosave timer when you hit CTRL+S (lol), so you're better off without it. Saving can take some time on bigger maps, so you want to be in control here. Also, very important: Make backups! Once you saved your map, go into the folder and duplicate the file (CTRL+C, CTRL+V, or whatever it is on your system). Sadly, the Radiant coders didn't include a save rotation like jEdit has it. You have to do that manually.<br /> <br /> Later, when you've worked a bit with NetRadiant, you might want to change the grid colors in the menu &quot;misc&quot;, submenu &quot;colors&quot;. My &quot;grid major&quot; is &quot;#00DF00&quot; (a big fat green) and &quot;grid minor&quot; is &quot;#ADFFAD&quot; (a very bright green, fading into white). Now, you should go into the &quot;view&quot; menu, submenu &quot;show&quot; and activate &quot;show workzone&quot; which will draw additional line garbage in the 2D view - the stuff you have drawn/selected last will have an additional red line pair around it. Makes it easier to find it. You have no idea how confusing the 2D view will become once your map is a bit more complex. Rule of thumb: Before you find the lines in the 2D view confusing, you shouldn't even think about presenting your map to the community.<br /> <br /> ===create the asset folders===<br /> <br /> '''Manually create folders in the base folder:''' You already know the base folder. You extracted the Tremulous support file here as Ingar's website instructed. Now, manually create a folder called &quot;maps&quot;. Also the folders &quot;textures&quot;, &quot;sound&quot; (NOT &quot;SOUNDS&quot;), &quot;scripts&quot;, &quot;env&quot;, &quot;models&quot;. If you have already seen a [[.pk3]] file from the inside, you'll have realized that the folders in those archives are treated by the game client as if they were really existing. So, you'll have guessed what those folders you just made will be used for: They'll hold the exact same kind of files that you see in the .pk3 map files.<br /> <br /> ===obtain a frontend for q3map2===<br /> <br /> If you're on Windows, definitely download [http://www.bobdev.com/q3map2build.php q3map2build]. The program is not necessary to make a playable map, but it's a big help in compiling. NetRadiant already has a build menu which calls q3map2 with parameters, also you could manually create batch files and just launch them every time you want to compile a map, which makes sense if you need very special settings for a map. For example: I worked on a map where I used q3map2's &quot;gamma&quot; option, quite unusual, so you would probably not reconfigure NetRadiant's build menu for that. You'd instead use a batch file. Or q3map2build.<br /> <br /> This VisualBasic program is a '''frontend for q3map2'''. It creates batch files and executes them. Depending on what you selected, there will be up to four lines in such a file: The first one compiles the binary BSP file from your MAP ascii document. The second one (&quot;[[VIS]]&quot;) calculates what point on your map can be seen from which other point and optimizes the BSP accordingly. Can be omitted oftentimes when you just want to have a look at your map, but for releases, this is absolutely necessary. It's the difference between 1 FPS and 90 FPS. Among other things. And the third line (&quot;LIGHT&quot;) finally calculates the light maps, so everything looks and feels real - without this phase, everything would be at full brightness which totally destroys the mood. The fourth line starts the Tremulous client with your freshly compiled map. Very convenient.<br /> <br /> '''After downloading q3map2build, you have to configure it:''' Start it. Go to &quot;directory options&quot;. Set &quot;game executable location&quot; to your tremulous.exe. Set &quot;q3map2.exe location&quot; to the file &quot;q3map2.exe&quot; located somewhere in the NetRadiant folder. Click &quot;save&quot;. Open the &quot;game options&quot; window, check the &quot;base mod dir&quot; box and type &quot;base&quot; into the text box. Click &quot;save&quot;. That was the basic setup of the program.<br /> <br /> '''While we're at it:''' In the little &quot;'''BSP'''&quot; area, select &quot;custom&quot; and click &quot;options&quot;. Activate &quot;custinfoparms&quot;, &quot;info&quot;, &quot;meta&quot; and &quot;patchmeta&quot;. Click &quot;save&quot;.<br /> <br /> In the little &quot;'''VIS'''&quot; area, select &quot;custom&quot; and click &quot;options&quot;. Activate &quot;saveprt&quot; (This makes sure that the portal file generated in the compile process is ''not'' deleted after the compile is completed, though it will be deleted and recreated on next compile. The portal file can be loaded into NetRadiant. You can then see in 2D and 3D the VIS areas that were compiled. Sometimes, you need this to help the software a bit. Keyword &quot;hint brushes&quot;.) and click &quot;save&quot;.<br /> <br /> In the little &quot;'''LIGHT'''&quot; area, select &quot;custom&quot; and click &quot;options&quot;. Activate &quot;bouncegrid&quot; (If you calc radiosity bounces, this option will make sure that the lightgrid (Whatever that is. I believe that it's a 3D grid of light. If you walk somewhere with your gun, it will receive e.g. red light. The light grid is where this is coming from, I believe.) is recalculated on every bounce, incorporating the light that was created by the bounces.), &quot;custinfoparms&quot; (which is necessary, I think, for shader parameters like &quot;nobuild&quot;, otherwise they might not get transported into the bsp, I believe), &quot;filter&quot; (softens the lightmaps so that shadow seams are soft, not pixelled), &quot;patchshadows&quot; (necessary for your pipes and models to cast shadows), &quot;bounce&quot;, &quot;bouncescale&quot;. Enter a &quot;500&quot; in bounce and a &quot;2&quot; in bouncescale. Remember these two options because you will later come back and deactivate them both, instead you will then (Later, as I said.) activate &quot;fast&quot;.<br /> <br /> Before you click &quot;save&quot;, let me explain what's going on here: These options define how the lightmaps will be rendered. The option &quot;fast&quot; really really increases the speed of the calculations, and you will use it most of the time because it even doesn't change the lighting drastically. But your first map tests will be of so little complexity that the rendering will be fast anyway.<br /> <br /> The &quot;bounce&quot; option is for radiosity bounces. So, your surfaces will not just have the light that is cast on them by the light sources. Instead, as in physical reality, your surfaces will also have the light that is reflected by the other surfaces. This is, of course, a question of iterations, because once a surface has received light from another surface, guess what: The next time, the light that comes from the surfaces is different. Realistically, 2 or 3 passes do the trick of giving the right impression. 500 passes will never be reached, all light will be used up at pass 5 or 7 maybe, the program will then stop calculating this. You should definitely use radiosity bounces in the maps you publish (if you have the time to calculate them), because they give a much more natural lighting feeling. For example: Colored surfaces will reflect colored light into the bounce process, and you'll see that in the endresult, especially if you use amplified bounces. Just turn this on for now so that you immediatelly collect data in your mind. The parameter &quot;bouncescale&quot; defines the amplification of the bounced light. Theoretically, this should be set to 1 (and hence could just be turned off), but I have made good experiences with amplifying the bounces a bit. This causes more radiosity bounces, of course, because the light will not be used up so quickly. It can even happen that the light will not be used up at all. Hey. This is a crash course, not a &quot;click here and you're done, but you stay uninformed&quot; course. There's more information about these settings further down in this article ([[#_lightmapscale.2C_gridsize.2C_turbo_rendering|lightmapscale/gridsize/turbo_rendering]]).<br /> <br /> You might wonder why I don't just use the &quot;build&quot; features in NetRadiant. Because I want to be in control, and I want to be flexible. This crash course will, for example, deal with &quot;amplified radiosity bounces&quot;, the lightmapscale and somesuch. If I had used the build features as presented, I'd still only work with non-amplified bounces, I wouldn't have dealt with the gridsize or the lightmapscale, I wouldn't have used the &quot;filter&quot; feature. Maybe there's still stuff to discover, but I won't discover it if I use the preconfigured built-in buttons. You don't have to go that way, but I won't spare you the ugly details.<br /> <br /> '''So, until now you have installed the Tremulous client, the NetRadiant map editor, the NetRadiant support files, you have configured NetRadiant a bit, you have hopefully gotten your hands on a good q3map2 frontend, and you have created those folders. That's it, now let's go mapping.'''<br /> <br /> ==NetRadiant crash course==<br /> <br /> In Netradiant, move the mouse to the white area with all the confusing lines. Click and hold the left mouse button. Drag the mouse a bit. Release the left mouse button. You just made a floor. Or a ceiling. '''That thing you just made is called a [[brush]].''' This can only be done in the 2D view. Brushes are the building blocks used to make the map world. They can be changed into different shapes and also be drawn directly in different shapes, but most of the time, you'll draw simple box brushes. If you have done everything in the setup section, the box you have just drawn should have a number pair at its left top (position), a number on the right side and a number on the bottom (dimensions). The unit system used is called &quot;world units&quot;. Rule of thumb (that I heard - can't say that I have really verified it) is: 32 world units = 1 meter. There should also be red lines from all four directions leading to the box brush you made. Click and hold the right mouse button. Move the mouse a bit. Release the button. You have just dragged the whole 2D world. Scroll the mouse wheel to zoom. '''You can now navigate the 2D view.'''<br /> <br /> By the way: When you draw a brush, you obviously control its dimensions in both directions, but what about the third? NetRadiant will make the brush as thick as the gridsize is set - unless your work area (the one we made visible via menu &quot;view&quot;, submenu &quot;show&quot;) says different. So, the last thing you had selected (even if it is now deselected) decides how thick your brush will be. You can of course change the size of a brush afterwards, but now that you know this, you'll some day begin to take this effect into account.<br /> <br /> On the right side, you should see a big gray empty space. That's the 3D view. This one is a bit tricky. I hope you have deactivated the far clip plane in the preferences (&quot;camera&quot;) as I've said. Otherwise, the next steps might take you too far away from the box you just drew, and so you would not get to see it. Right click in the 3D view, and release the mouse button. The mouse cursor should have vanished. When you do that again, the mouse pointer returns to normal. With the mouse pointer locked into the 3D view, press the downwards arrow on your keyboard for about one second. After that, move the mouse around in all directions. If you have done everything as I said, you will find an ugly pink box. Congratulations! You've just discovered the world of the mapper: Ugly pink boxes. Much of the mapping process will take place in your head, not in front of your eyes. Experiment with the arrow keys, the mouse movements, the CTRL and SHIFT key, and the mouse wheel in the 3D view. '''You can now navigate the 3D view.'''<br /> <br /> Time for a few keyboard shortcuts:<br /> <br /> Press the ESC key. The box should now look different in the 3D and 2D view because it is no longer selected. In later situations, you'll have to press the ESC key several times in a row to '''deselect stuff''' because some selection modes go deeper into the structure, and every ESC press takes you a step back until everything is harmlessly unselected. And then it looks like it does now.<br /> <br /> To '''select the box''' again, click on it in the 3D view while holding SHIFT. Most of the time, you will select stuff in the 3D view because it's a pain in the ass to do so in the 2D view. NetRadiant still needs much work. Why they didn't include a box selection mode that only selects stuff that completely fits into the box is beyond me. Don't they use their own software?<br /> <br /> Now that the box is selected again, press the BACKSPACE key. You know, the big leftward arrow above the return key. Whoops, '''box deleted'''. Select &quot;'''undo'''&quot; from the &quot;edit&quot; menu or press CTRL+z to get it back again.<br /> <br /> We will now apply a texture to one of the sides of the box. Well, it already has a texture - the name is '''&quot;Caulk&quot;, that's the most important texture of all''', really. You should have this texture applied to every surface that the player cannot see. So, it's best to start with all-Caulk'd surfaces, and whenever you're working on stuff, keep in mind that every unused surface should be returned to Caulk. This is not a ''must''. But you'll bite your own ass one day if you want to squeeze all possible FPS out of your map, so you'll want to Caulk everything, but didn't take care all the time to prevent unnecessary textures. I've been there.<br /> <br /> Press ESC to deselect the box. Now click on it in 3D, but this time, hold SHIFT and CTRL. '''You just selected a surface.''' The texture browser is right under the 3D view. Doubleclick on &quot;arachnid2&quot;, wait till all textures are loaded, then click on the first texture that you can see: &quot;001metal&quot;. Yay, '''you painted the surface'''. The texture in the texture browser does have a red border now. This means that this is the current texture. Without changing the preferences to &quot;new brushes have Caulk&quot;, every new brush you make would have the red bordered texture. But believe me that you'll later find out yourself that you don't want to go that way. Next to the big texture with the red border, there is &quot;arach_fog_s&quot;, a '''texture with a white border'''. Textures with white borders are [[shader]] textures. Shader textures are not just images, they can even have functions, for example they decide whether a brush textured with them is made of water that you can swim in - or slime/lava that kills you.<br /> <br /> Remember the folders you made in the &quot;base&quot; folder? The pictures you see in the texture browser are stored in the folder &quot;textures&quot; or in one of its many virtual versions - I am speaking of the texture folders in all those .pk3 files. They are treated as if they were really existing folders/files. Which means that it's easy to have a file with the same path and file name existing several times, something impossible in the normal file system (may I remind you that I speak from the Windows perspective). '''You should read the [[.pk3]] article''' because it contains important information on how to deal with this. It's really tricky, and you don't want to go through the process of finding out the hard way. Things that can happen if you fail here: Your map can cause other maps to malfunction. Or your map will be incompatible with older versions of itself. Or it will not function the way it did on your computer. By the way - if you wonder where the textures of all those maps you might have downloaded and played until now are: On my machine (Windows), I have ''several'' &quot;base&quot; folders. One is somewhere in the system user area. If you want to use the textures of those maps, too, move them into the &quot;base&quot; folder where the program is installed. And no, you don't have to unpack the .pk3 files to use their contents in NetRadiant. But if you're a mapping beginner, you shouldn't have other files in your installation &quot;base&quot; folder than the ones that actually came with the Tremulous installation (and the Radiant Tremulous support file). Reason: Later, you'll make a .pk3 release pack, and you have to put all files into it that people will not have from the default installation, so have fun figuring those out when your &quot;base&quot; folder is polluted and you're a beginner.<br /> <br /> In the beginning, you will probably use the textures/shaders/sounds etc. that are part of the original Tremulous 1.1.0 pack. '''You don't have to deliver Tremulous 1.1.0 standard files with your map''' because you can assume that everyone has those. I don't know about the Tremulous 1.2 world that is about to emerge, though. But until now, it's the right way to go, and many people have done so. It's accepted. It keeps your map file small. And it means less file- and folder-hassle for you.<br /> <br /> '''Let's save the map.''' NetRadiant doesn't know a name yet, so it will show you a box where you can enter a name. The folder (&quot;maps&quot;) should already be set. Or did you forget to make the folder? You can leave the name &quot;unnamed&quot;, I mean, why call it &quot;terror castle zero&quot; when you don't even know how to make one. From now on, you can just press CTRL+s to save the map. And from time to time, go to the folder window (outside NetRadiant) and '''make a backup of the map file''' (e.g. by copying and pasting it into the same place). Too much garbage in the folder? Learn to live with it. You don't want to live with lost data. '''Maps can get broken in weird ways.''' If you know how to debug them, good. Otherwise, go to an older version and start over. Example: Maybe you know that a map file is just a human readable text that you can open in any text editor. If you open a more complex map, you'll see that it only consists of [[entity|entities]] which in turn sometimes have parameters and/or brushes. Now, one of the bad things that can happen (because NetRadiant is really just a rudimentary editor that allows to make maps but which is really far from being a reliable pro tool) is that an entity that needs brushes (as for example a door - the brush(es) are the moving door) loses all of them. Such a map would not run in Tremulous. To fix such a situation, you would have to use a text editor, locate the erroneous entity and fix or delete it (which is not hard but also not for beginners). Or you'd go back to a previous map version. And no matter how experienced you'll be one day, there will sometimes be problems that you cannot fix. For example: I had a map once with one telenode. The Tremulous client, though, behaved as if there were two. But there was only one. That's easy to verify because the node can be searched for in the text file. I even searched in the compiled map: Only one telenode. Well, the system is not free from bugs, and this is what can happen. Because I was already so far into the map, I had to test-delete many brushes, compile, run - still one telenode too many. Again. And so forth. After a day, the problem was fixed even though the elements that I finally found out to delete and remake didn't have anything to do with the telenode and also didn't seem broken. Also, the telenode problem was absent in some of my delete runs - even though it was different stuff that I had deleted.<br /> <br /> Another word on backups: If you're not a total computer noob, you use archiving software from time to time. But &quot;ZIP&quot; is not the archive format of choice (except of course to make .pk3 files, those have to be ZIP, but you can create that with other archivers, too). [http://www.win-rar.com/downloadnow.html RAR] is very good (but not free, so there's a nag screen or you have to pay). But the best one currently (even though it doesn't support recovery records - haven't really needed those till today, anyway) is [http://www.7-zip.org/ 7z], and it's free. There are also versions for Linux etc. (search yourself). So, why do I mention all this? Well, if you have a bunch of backup copies of your map file (which will eventually outgrow the 1 mb limit, can even reach 20 mb), you'll quickly have tons of &quot;wasted&quot; space. But don't delete the backups if you're not absolutely perfectly sure that you won't need them any more! Just compress them. They compress very well, to about a 10th of their size. And if you use a ''modern'' archiver instead of ZIP when compressing like 20 backups into one archive, the archiver will not just squeeze down every map backup individually, but it will take into account that most parts of the files are equal. That's called a &quot;solid archive&quot;. Unpacking stuff out of them is a bit annoying because oftentimes, the whole archive has to be calculated through for one file. But who cares. So: Just pack all your backups into one archive from time to time. Instead of 100 mb &quot;wasted&quot; space, you'll only have like 1 mb! And you will have all backups of your map! I do it like this for every map individually: &quot;backups till 2010-06-29.7z&quot; and so forth. Makes you sleep better.<br /> <br /> The last word on backups: It's not enough to just backup the map onto the same machine. That is only for the work process in case something gets broken or you need to copy an object from an earlier version that doesn't exist in the current one. No, you also need to backup your files from your PC to another medium. That doesn't really belong into this article because every serious computer user should do that from time to time anyway. But I'd like to mention that here. What I do (apart from backing up my whole machine onto extra harddisks that I then put away somewhere from time to time): I have all mapping relevant files in the Tremulous install folder. And so, I just make a 7z archive of the whole folder tree once a week or so, and I copy it onto a USB stick. I don't know how reliable those are, but my experiences have been good so far. You'll sleep better if you know that the hundreds of mapping hours are safe somewhere.<br /> <br /> Let's go back to our brush. Press ESC to deselect the surface. Then SHIFT and left-click the brush to '''select it in the 2D view'''. Yes, in the 2D view. You can also hold SHIFT and the left mouse button, drag a box that touches the brush you made, and release both. That's the '''box selection'''. Another thing you can do (but you can't really test now because you only have one element in your map) is to SHIFT and left-click in the 2D view and also hold the ALT key. This selects one of the things that are in the position that you click at, just as the normal SHIFT and left-click does. But if you do this several times, the first selection is deselected, and something else in the same place is selected instead. Very useful function to '''toggle through all the stuff in that place.''' Less useful is the fact that it is buggy - sometimes, you have to move the mouse a bit to make the program allow you to use this function again. Box-selection (SHIFT and left-click, drag, release) is also possible in the 3D view (also the SHIFT-ALT-click toggle-through-stuff function), and only the elements currently in view will be selected - so you'll probably enable far-clip-plane from time to time (preferences, &quot;camera&quot;), adjust its distance (menu &quot;view&quot;, submenu &quot;camera&quot;), enabling you to easily select a group of objects (for example a truckload of lights that you used to slightly paint the light situation without people noticing) in front of you while the things behind them are too far away to be visible or get selected.<br /> <br /> If you have a look at the menu &quot;view&quot;, submenu &quot;filter&quot;, you see that you can '''filter''' the 2D and 3D view for the many different kinds of things and thing-groups that a map can consist of. This will be very useful for selecting. And for not getting distracted/confused. Also, displaying the graphics in the editor is faster if less stuff is being drawn, obviously. If you see anything in the filter list activated right now, select the lowest point &quot;reset filters&quot; which will turn everything off - so that you can see everything that exists in the 2D and 3D view. Another way of '''making stuff temporarily invisible''' is the '''hide function'''. Make sure your brush is selected. Then press the &quot;h&quot; key. Bang, it's gone. You can hide all kinds of elements. If you want everything to be visible again, press SHIFT &quot;h&quot;. Filters and hide have no influence on the map functionality, they are not even stored in the map file. When you close NetRadiant and open it again, the previous filter settings are still active which can be confusing at times. The hidden stuff, though, is visible again. By the way: Did you notice the - - - - - line at the top of the menu? If you click that, the menu will be opened in a window that does not go away when you select something in it. Very useful.<br /> <br /> Another very important function that can be toggled on and off is the &quot;'''texture lock'''&quot; function. There is a button with a lock picture for that somewhere at the top right of the screen. When it's active, it should actually blink and play a loud HONK!-sound all the time or something. And when NetRadiant is closed and opened again, it should be deactivated. But all of this does not happen. So, '''you have to take care whether or not the texture lock function is activated'''. Here is what it does: When it's not on, the textures on a brush seem to scroll around when you move the brush around. That is because the textures are normally locked to the world position. This is very practical, as you will find out with time. Now, the &quot;texture lock&quot; function changes that: When you drag a brush while that function is activated, the textures of the brush will move with it. That is very useful in cases where you have made a brush or several brushes with specific texture work (for example light fixtures), and you want to move those brushes without the design to change. Be aware whether or not the function is activated. You will remember this text here for sure. Because you will at some point see textures in wrong positions, realizing: &quot;Damn, I moved brushes around with texture lock on! Why isn't that function automatically turned off when I start the program?&quot; The texture lock function also changes the behavior of textures when you use the rotate-brush-by-90-degrees function.<br /> <br /> Remember when I called your brush a floor or ceiling? That's because the 2D view shows a view from the top (or bottom, depends on how you think) on the map when the program opens. Press CTRL and TAB. If nothing weird is going on with your input focus and keyboard (which can happen from time to time), the '''2D view was just switched from &quot;top view&quot; to &quot;side view 1&quot;'''. Do that again, and it changes to &quot;side view 2&quot;. Once again, and you're back at &quot;top view&quot;. You can determine what view you're currently on by looking at the little right angle labeled &quot;z&quot; and &quot;y&quot; or &quot;x&quot; and &quot;y&quot;, you get the picture. You'll probably determine that later by rather looking at the map, though. It's helpful/important to learn that the vertical axis is the Z axis. If you can currently see the X and Y axis, you're looking along the Z-axis (meaning: from the top).<br /> <br /> Now, let's finally get to '''how to move and scale a brush:''' Make sure the brush is selected. In the 2D or 3D view, click on the brush, hold the button, move the mouse, release the button. You just moved the brush (if the grid versus the amount of mouse movement didn't prevent this). Moving it in the 2D view makes sure that it is not moved along the axis that is pointing directly towards you. Moving it in the 3D view is comfortable, but can have unwanted results because of the fact that the camera is &quot;never&quot; perfectly aligned with the three space axes. To scale the brush instead of moving it, do the same, but don't click inside of it. Instead, click beside it. Important: Don't scale it too small so that it vanished. I have no idea what happens then. I always hit &quot;undo&quot; in such a situation. Might be a map-breaker.<br /> <br /> '''The grid''' is very important. In most cases, brushes should be perfectly aligned with grid points. Otherwise, have fun debugging your map. To '''change the grid scale''', press one of the number keys from 1 to 9. You can also do that in the grid menu. You'll do that from time to time, because, believe it or not, the grid spacings below 1 are actually used sometimes. The current grid spacing can be seen at the bottom of the NetRadiant window, on the right side. Careful with the key &quot;0&quot;: It toggles the grid from visible to invisible (and back). On a side note: I hope that the NetRadiant developers will be nice and implement a feature that draws the grid with thicker lines (e.g. 3 instead of 1 pixel) because it's simply invisible with all the stuff in front of it on more complex maps, and that sucks considerably.<br /> <br /> '''A word about world units / grid size / reactor and overmind etc.:''' It will take a while until you have memorized all the building and player sizes. Until then, just memorize this: An opening or room with the size '''128x128x128''' (second largest grid setting (&quot;8&quot;)) is just high and certainly wide enough to contain the overmind or reactor (112 would be enough). Tyrants etc. fit through nicely (96 would be enough). Those numbers might not really tell you anything, but any long-time computer user knows the drill: 1 2 4 8 16 32 64 128 256 512 1024 2048 4096 8192 16384 32768 65536 ... You should know those numbers up to 256 to be more efficient with NetRadiant. And 96 is three elements of the size 32, '''96 is just high enough for a tyrant''' to get through. '''64x64x64''' is big enough for a dragoon. A human can still crawl through a height of 32, if I am not mistaken. '''If you want to make a stair, 16 is a nice step height.''' Though 16 might seem a bit big on closer inspection since it's theoretically half a meter.<br /> <br /> Make sure that your brush is selected. Then, press CTRL and C, then CTRL and V, or use the &quot;edit&quot; menu. The '''brush exists now twice in the same place''', a common error that can cause weird map behavior, yet a situation that you will intentionally create many many times, because it's often useful to take an existing brush and copy/paste it somewhere else. At this point I should remind you: Keep everything Caulk'd that cannot be seen by the player. Ok, now press ESC. Yes, keep the two brushes in the one place for now.<br /> <br /> Travel to the side of the brush that shows the &quot;001metal&quot; surface. Select it (SHIFT CTRL left-click). Now go to another texture section. Not &quot;arachnid2&quot; but instead &quot;common&quot;. Most of the '''textures in the &quot;common&quot; group''' are actually shaders, as you know already because you saw the white borders around them. The one called &quot;caulk&quot; is among the first. It should have a green border because the currently open map uses it in at least one place. Click on &quot;caulk&quot;. This applies the caulk shader to the surface you selected. It also gets the red border because it's now the current texture, which is unimportant to us because all our new brushes have caulk, not the current texture. The &quot;common&quot; textures are really useful. There is, for example, a shader called &quot;ladder&quot;. Any vertical surface that you apply this texture to can be climbed. It's really that simple. Well, to make an actual ladder, build something that looks like it can be climbed, then make a brush with the ladder shader around / in front of it. The ladder shader is invisible, but you can't walk though it. There is also a texture called &quot;clip&quot; which you'd sometimes use to invisibly even out too odd wall and floor situations. The dretches will thank you. The players who don't get stuck while running away from the beasts will thank you, too. Some of the textures/shaders of the &quot;common&quot; section can be used without you having to distribute these shaders with your map (like for example the &quot;caulk&quot;, &quot;ladder&quot; and &quot;clip&quot; shaders), but it's best to just add these few bytes to your map file. Better safe than sorry. Ironically, the &quot;invisible&quot; shader, for example, would cause '''&quot;missing texture&quot; optics''' (Missing textures in the game are gray with a big white grid. Hard to miss. Easy to miss, though, if your testing environment is improper, because then you'll not have missing textures, but the players will.) if the Radiant Tremulous support files are not present, so put them into the release file. A .pk3 without those shaders will of course work on your machine - because you have the &quot;data-radiant-1.1.0.pk3&quot; in your &quot;base&quot; folder! Others do not have this.<br /> <br /> '''Get to know the phenomenon called [[Z-fight]] (or Z-fighting):''' Press ESC to deselect. Now, select &quot;the&quot; brush (doesn't matter which one, but just one of them, Wassily), so SHIFT left-click on it. Now for the important part: Move the brush a bit. Not too much. You'll see that the copy (or the original, you never know which one you'll click if there are several in one place) is revealed by you moving the other one. Don't move it too far - they should still overlap. Now, study the area in which the textured face of the one brush and the Caulk'd face of the other brush are drawn in the same place. Move the camera around a bit. If you've done everything right, then you are just observing a Z-fight. Two surfaces want to have the same distance from the observer and fight about it. No one wins, especially not the spectator/player. For historical reasons, the distance an object has from the camera is called the z-distance. You could also read up on the term &quot;[[Z-buffer]]&quot;.<br /> <br /> It is very probable that you will get to see Z-fighting somewhere during one of your many testruns of your maps. You can even find those in finished maps that can be found on many servers. I can remember at least one z-fight in a professional map that came with Tremulous 1.1.0 ([[Nexus6]]). Ironically, right now, there is nothing wrong about your map in that regard. Because one of the two surfaces that are fighting has the Caulk shader - which is defined to be invisible. There would be no z-fighting in your map right now.<br /> <br /> '''Mirroring and rotating:''' Select one of the brushes and toy around with the 6 buttons at the top left of the NetRadiant window. The first one is &quot;x|x&quot; and mirrors the brush along the x axis. I find it irritating that the Radiant developers chose to mirror the brush ''along'' the x axis instead of using the x axis as the, well, mirror axis, but you'll get used to that. The button next to that is the rotate-around-x-axis button, and that actually works like you'd expect it. Depending on the grid-versus-brush situation, the position of the brush gets changed accordingly, too, so later, you'll adjust the grid spacing before rotating a brush around 90 degrees. Mirroring does not care about the grid, just about where the brush begins/ends. If the &quot;texture lock&quot; is active, the textures get rotated and mirrored accordingly. Nice one. But if you rotate a brush using &quot;arbitrary rotation&quot; (menu &quot;modify&quot;), the textures will not be rotated with it, no matter if the &quot;texture lock&quot; was active or not. &quot;arbitrary scale&quot; (same menu), though, scales the textures (if &quot;texture lock&quot; is on).<br /> <br /> Left of the &quot;texture lock&quot; button, there is another (currently selected) button with a rectangle inside of it. If you hover your mouse above it, it'll say &quot;Resize (Q)&quot;. That's your normal brush draw/move/resize tool. Two buttons to the left, there is the &quot;Rotate (R)&quot; tool. Select it and rotate your brush a bit. This is the same as &quot;arbitrary rotation&quot;, only it's handled with the mouse instead of numbers. Don't forget to switch back to &quot;Resize&quot;.<br /> <br /> Now a quick tour of '''dealing with entities''': In the &quot;view&quot; menu, select &quot;entity inspector&quot; (or press &quot;n&quot;). There are several sections in that new window that appeared, and you might have to vertically scale those sections a bit before use. The most important area in that window is the one saying &quot;classname worldspawn&quot;. If there is no such text visible, you probably don't have a brush selected at the moment. Select one (or several, doesn't matter now). If there's still no text &quot;classname worldspawn&quot; in the window, you have to scale and move stuff in the window around a bit. The &quot;most important area&quot; with said text is not the lowest part of the window, but it's the lowest big white box in the entity inspector. Once you've found it, click on the text &quot;classname worldspawn&quot;. You'll see that, once you've selected it, the text &quot;classname&quot; appears below the area in a textbox labeled &quot;key&quot;, &quot;worldspawn&quot; in the &quot;value&quot; box. The '''key-value-principle''' is very important. The area in which you selected the key-value-pair will later have more key-value-pairs. These are the properties of the entity that you've currently selected. Wait, a brush is an entity? Well, if you deselect the brushes with ESC, &quot;classname worldspawn&quot; is no longer visible in the entity inspector window (only as a relict in the &quot;key&quot; and &quot;value&quot; input text boxes). So, every brush is an entity with the text &quot;classname&quot; in it? No. All brushes are one combined entity. The entity's name (And it's better to think of this as a type, not as a name. Later, you will have several entities with &quot;classname&quot; &quot;light&quot;, so it's obviously not just a name but really a type.) is &quot;[[worldspawn]]&quot;, a term mappers toss around oftentimes. Every map has min. and max. one worldspawn. It's the first entity in the .map file (if you look at it with a simple text editor.) The worldspawn can have very important settings regarding the map, for example the amount of buildpoints the teams have, or you can add a little message that is displayed while the map loads. The text area above the &quot;most important area&quot; describes which keys and values can be used for the world spawn. Once you select a different type of entity in the 2D or 3D view (or in the area at the top of the entity inspector, where all possible entity types are listed), the help text changes.<br /> <br /> When dealing with the entity inspector, be careful what you have selected in the map. It's possible to select a brush (usually part of the one &quot;worldspawn&quot; entity) and another entity type, for example a &quot;light&quot;. This flexibility can be useful, but if used improperly, it's a big source for errors. '''Always be aware of what's selected before using any function.'''<br /> <br /> Now, let's use an entity we haven't used before: Select one (or all) of the brushes. Then, right-click in the 2D view. A menu should appear. If it didn't, try again without moving the mouse even the slightest bit. In the menu, go to the item &quot;info&quot;, and from the new submenu, select &quot;info_player_intermission&quot;. This creates a little box of that entity type. Also, the brush(es) that were selected have gone, replaced by the new entity. You better undo that and remember this effect for later, because if you're dealing with a somehow broken map later, it might have been caused by the action that was just demonstrated. But everything should be fine if you use &quot;undo&quot; on such an action. Ok, now press ESC to deselect everything, and then create the entity anew. What is it good for? Well, it defines the position and orientation of the spectator camera when you enter a map or leave a team. '''The &quot;info_player_intermission&quot; entity is absolutely essential. Without it, a map does not work in Tremulous!''' The &quot;info_alien_intermission&quot; and &quot;info_human_intermission&quot; entities have a similar function (camera position and orientation when you're on a team and are currently not alive), but they are not technically necessary. You'll of course place them when you're making a real map.<br /> <br /> You can use the &quot;arbitrary rotation&quot; or the mouse rotate tool to change the direction into which the player_intermission camera is facing.<br /> <br /> Man, I almost forgot THE LOG. Move the mouse to the bottom of the window directly above the status line (that's the area with several texts and horizontal segments). There should be a handle looking like ............ Click and drag it up. You should now see the log. Sadly, you'll have to do that again next time the program is opened. The log shows the actions the program performs (and errors that happened). Have an eye on the log when you map, it'll save you a few map-repair-sessions because you'll see that something you wanted to do didn't work out, or something was done that you didn't expect and so forth.<br /> <br /> There are more NetRadiant explanations in the other sections of this mapping crash course.<br /> <br /> ==making your first (ultra basic) map==<br /> <br /> ===create the map===<br /> <br /> Now that you know how to handle the most important functions of NetRadiant, let's make a map, violating all rules, offending all experienced mappers. In the &quot;file&quot; menu, select &quot;new map&quot;. If a window appears asking you if you want to save the current map, you're doing it wrong because you should have saved the map already a few times with at least one or two backups. Ok, it's a worthless map that you wouldn't really save or backup often, but I want to give you an idea of how to deal with a real map.<br /> <br /> Press CTRL and TAB until the 2D view shows the X and Y axes, so you're '''looking from the top. Press the key &quot;9&quot; to have the largest grid spacing.''' If the grid is invisible, press &quot;0&quot;. If that doesn't make the grid visible, then it probably was not invisible before but just too big for your current zoom (use mouse wheel and maybe &quot;0&quot;). Read on once the grid is visible and also on its largest setting (displaying &quot;G:256&quot; at the bottom of the window).<br /> <br /> '''Create a brush in the 2D view, exactly one grid block in size.''' The numbers on its right and bottom size read &quot;256&quot; if you've done it right. Assuming that 32 world units are one meter, this brush is a nice 8 by 8 meters floor. Which is also 8 meters thick, by the way. But who cares. It's not like we're wasting concrete or something.<br /> <br /> The brush is pink, yes? Otherwise, shame on you. Now, move the camera in the 3D view so that you can see the top of the brush. Select the top face (CTRL SHIFT left-click, don't just SHIFT left-click it or you'll select the whole thing). Go to the &quot;arachnid2&quot; texture section and click the first texture (&quot;001metal&quot;). '''The top surface now has this texture.'''<br /> <br /> Press ESC to deselect everything. Then right click in the 2D view, and select &quot;team_human_spawn&quot; from it. Press ESC again, call the menu again, and select &quot;team_alien_spawn&quot;. Press ESC again, call the menu again, and select &quot;team_player_intermission&quot;. Great! '''Now you have all the three essential elements''' that you need to have a working Tremulous map. But there is a problem: '''If the spawns are not in a proper place''', they might not get created when the map loads. So, move the egg and the node around until they stand somewhere on the box. Make sure that there is enough distance between the two. Also, have a look at them from the side: They must not be too close to the surface of the box or they will not get created when the map loads. You can really place them quite high (Be reasonable.) above the surface. When the map loads, they will be created in that spot and then fall down to the surface (without taking damage). To move the entities around, you have to set the grid to a higher resolution. Just blindly hit one of the left digit keys for a high resolution, which one doesn't matter at the moment. By the way: Too many people ''in the game'' fail to place the spawns in the right rotation. It's easy: The player will spawn to face the position from which you made the spawn. Makes sense: That position can be assumed to be a valid place to go. Making spawns in the right rotation can influence the game flow positively.<br /> <br /> Please check if the surface on which you are trying to put the spawns is the one you have textured. If not, then you did something wrong earlier when texturing it. Spawns cannot be rotated in the editor in the way that they can be put on walls or something, so it's not the spawns that are wrong. By the way, you can '''rotate the spawns''' around the high axis (Z) to define the direction into which the player will look when he spawns. The human spawn, at least the one in the editor, has the aparatus-thingy on the side into which you will spawn. The egg spawns you into the direction the red axis at the egg's center points. The human spawn does so, too, but the aparatus-thingy is easier to see.<br /> <br /> Ok, we have a floor with a texture, both teams have a spawn, and the player_intermission camera does also exist (maybe you want to move and rotate it around a bit until it will probably show something meaningful, but it's not necessary for the map to run).<br /> <br /> What's missing? Light! ESC, 2D, rightclick, '''select &quot;light&quot;'''. A text box appears. Make sure that the number inside of it is &quot;100&quot;. That's the brightness of the light. Click ok or press RETURN. Pressing RETURN is not always advised: The &quot;arbitrary rotation&quot; dialog, for example, will not do anything then. Now move the point light you created until it is in the middle above the box brush. For that, press &quot;8&quot; to set the grid to the second largest spacing. Now it's easy to move the light to the middle. Seen from the top, it must be in the middle. Seen from the side, it must be one grid step above the floor. With setting &quot;8&quot;, that's 128 world units - 4 meters.<br /> <br /> ===build the BSP file and run it===<br /> <br /> If you have not yet saved the map, shame on you. Also, do it now. The name should be &quot;unnamed&quot;. Then, close NetRadiant. '''Because now we'll play the map!'''<br /> <br /> If you're a lucky Windows user, you'll have downloaded and configured q3map2build, I hope. Start that program, select the map &quot;base\maps\unnamed.map&quot; that you've just created, make sure that &quot;Play after build&quot; (left border of the window) is activated - and then click &quot;build&quot;!<br /> <br /> Alternatively, if you are not using this nice frontent for q3map2, you can create a batch file. The program does nothing different, only it's more comfy, and the texts displayed when you hover the mouse above the many switches certainly make things more clear. So, if you don't use the program, create a batch file. That's a normal text file with commands in it that has to be renamed to &quot;somethingsomething.bat&quot;. Sadly, those mega-idiots at Microsoft chose to hide file extensions (stuff like &quot;.bat&quot;) by default, so you can't rename the whole file name, only everything except the extension. For this reason and overall security improvement, Windows users are urged to turn the display of file extensions on. In any file explorer window, go to the &quot;Tools&quot; menu, select &quot;Folder Options&quot;. At the top of that new window, click on &quot;View&quot; and then scroll down until you see the option &quot;Hide extensions for known file types&quot;. Turn it off and click &quot;Ok&quot; at the bottom of the window.<br /> <br /> Here's the text for the batch file:<br /> <br /> &quot;C:\Program Files\netradiant-20100214-win32\q3map2.exe&quot; -fs_basepath &quot;C:\Program Files\Tremulous&quot; -fs_game &quot;base&quot; -custinfoparms -info -meta -patchmeta &quot;C:\Program Files\Tremulous\base\maps\unnamed.map&quot;<br /> &quot;C:\Program Files\netradiant-20100214-win32\q3map2.exe&quot; -fs_basepath &quot;C:\Program Files\Tremulous&quot; -fs_game &quot;base&quot; -vis -saveprt &quot;C:\Program Files\Tremulous\base\maps\unnamed.map&quot;<br /> &quot;C:\Program Files\netradiant-20100214-win32\q3map2.exe&quot; -fs_basepath &quot;C:\Program Files\Tremulous&quot; -fs_game &quot;base&quot; -light -bouncegrid -custinfoparms -filter -patchshadows -bounce 500 -bouncescale 2 &quot;C:\Program Files\Tremulous\base\maps\unnamed.map&quot;<br /> Pause<br /> &quot;C:\Program Files\Tremulous\tremulous.exe&quot; +set fs_basepath &quot;C:\Program Files\Tremulous&quot; +set fs_game base +devmap &quot;unnamed&quot;<br /> <br /> The line &quot;Pause&quot; is not necessary, though it can be useful to have the process wait between calculating and playing. q3map2build has options to insert &quot;pause&quot;, too. I once had the computer calculate a map for four days in a row, and I had &quot;Play after build&quot; unchecked because why should I &quot;burn&quot; my machine uselessly? This means that after calculating, the machine would just have closed the system's console text box without me being able to read the text. This makes the &quot;pause&quot; feature seem much less superfluous all of a sudden. Of course I could have saved the console output into files automatically (by adding &quot; &gt; outputtext1.txt&quot; to the end of the first line, and bla 2 3 4 to the other lines), but then again I wouldn't have been able to have a look at the console text because it would just have been in the files.<br /> <br /> You'll probably have to adapt the batch file text to suit your computer/setup.<br /> <br /> Doubleclick the batch file to start the compile.<br /> <br /> One of the things that will appear in the text window (which is the system's console text output) is &quot;LEAKED&quot;. Well, we didn't give the map a proper shell, we just made a floor. Doesn't matter at the moment, but later, we'll have to improve on that.<br /> <br /> Well. If everything went right, you're playing the smallest map in the world. And everything around your little world is pitch black. Or you see the [[hall of mirrors]] effect around you, really annoying. But it's a working Tremulous map!<br /> <br /> I bet you want to experiment now. Do that. But don't yet make a big map that kinda asks to be published, people are probably not going to like it. You have to learn some more first.<br /> <br /> <br /> <br /> <br /> <br /> ==making your second (more advanced) map==<br /> <br /> ===choose a name===<br /> <br /> You can freely create folders in the &quot;map&quot; folder, doesn't hurt the game system. So, you should make a folder and throw all files into it that have been created so far.<br /> <br /> Now, open NetRadiant (or select &quot;new map&quot; from the &quot;file&quot; menu if it was already open). Save this empty map. Reason: '''We want to give it a name.''' Press CTRL and S (or select &quot;save&quot; or &quot;save as&quot; from the file menu). The name shall be ... wait, what's your nick name? The name you use as a player or in the forums? If it were &quot;God, maker of the world&quot; (which is my nick name), we could make a short version of that, for example &quot;gmotw&quot;. Let's assume that your nick name is &quot;scrollbar5&quot;. A shorter version would be &quot;scr5&quot; or something. Let's stick to that. Back to naming the map: Please save it as &quot;scr5_dretchnest&quot;. If you actually have a nick name that you want to stick to and that can be nicely expressed with a few letters, use that from now on. I'll keep calling it &quot;scr5_...&quot;.<br /> <br /> You see where I'm heading. I called my first map [[Gmotw_Skybox|&quot;gmotw_skybox&quot;]], and this is not mainly about people attributing the map to my person (or so that all my maps would be in one alphabetical place in the huge map repositories that exist, hehehe) but instead so that I could freely choose my map names without having to worry about the name maybe already existing - or someone else taking the same name. I have not yet seen anyone do it like this, but I think this is actually the way it should be done by everyone, and so I tell my helpless scholar prey (Not really.) to do it just like that. '''Add a short version of your nick name with a &quot;_&quot; at the beginning of your map names.''' Keep it short, though. It's good if this prefix &quot;doesn't make sense&quot;, so it's not confused to be a part of the map's real name. So, &quot;gmotw_&quot; (Hey, that's mine.) is better than &quot;stellar_&quot;. By the way, if you look at the screenshot in the skybox article, you read the message &quot;Remove older versions of Skybox to prevent texture problems.&quot; which is really lame. You won't have problems like this since you can read my experiences and conclusions in this mapping guide. Comfy, no?<br /> <br /> If you use these prefixes, by the way, '''NetRadiant will nicely group all your map assets''' in the texture browser instead of spreading them all around the alphabetical map list.<br /> <br /> If you've read the [[.pk3]] article (which you should at some point), you'll already know about the '''filename uniqueness problem''' and about how to deal with it through several release versions of your map. We have halfway solved the uniqueness problem by choosing &quot;scr5_dretchnest&quot; (or whatever your prefix is), which is probably a name not yet taken. Except if 10 people go through with this mapping crash course without choosing a different prefix. But I wonder if anyone's gonna read it at all :/<br /> <br /> A word about &quot;alpha&quot;, &quot;beta&quot;, and &quot;final&quot; releases: BULLSHIT! That was actually just one word. No really: I think it's a meme or an &quot;I'm doing it just like the real guys! I feel like I'm taking a step into a larger world!&quot;-thing that people release their maps as alpha, beta, and final. Well, it has practical reasons, but it also has its problems. To make it short (meaning: I just deleted about 300 words of bla that I was about to save, and that was just the half of it.): Just give your releases a number. So, just add &quot;_001&quot; to the map name. Three digits seems to be much, but you never know. If you increase the release number every time you make a .pk3 and test it with friends or on the server of a guy you know, you'll quickly be above 9, and with all the stuff you have to keep in mind, you don't want to worry about the goddamn number. And once you have chosen to use the path of the &quot;_001&quot;... instead of the &quot;_a01&quot;... &quot;_b01&quot;... &quot;_final&quot;, you'll laugh at all the mappers who have decided to make their maps a &quot;final&quot; too early. &quot;Oh, something's still broken. Damn, already released as 'final'. Can't change it now.&quot; Weird people anyway. I mean, what makes you so sure that you will never add something to the map in a year or so? And then you have the other guys who are more careful. They make their alphas, then you find their betas in the wild... but there is never a &quot;final&quot;. Guess why. The last beta effectively ''is'' the final. Not changed after years. Assimilated by the community. No, you don't want to play that game. '''Just give your releases a number. Just a stupid counter suffix like &quot;_001&quot;.'''<br /> <br /> So, we're about to create a map. The &quot;next&quot; release of it will of course be the first, so its name is &quot;_001&quot;. (I should add that &quot;release&quot; in this context does not mean that you give it to the Mercenaries' Guild Map Repository and brag about it in the forums or something. I am just talking about a proper .pk3 file that you can test on servers.) When people callvote for it, they'd type:<br /> <br /> &quot;/callvote map scr5_dretchnest_001&quot;<br /> <br /> While we're at it: The .pk3 file of this (as can be read in the [[.pk3]] article) would be named<br /> <br /> &quot;map-scr5_dretchnest_001-1.1.0.pk3&quot;<br /> <br /> The name of the .pk3 file has nothing to do with the callvotes. But the name should be kept equal to the real map name for consistency reasons.<br /> <br /> If you're using the batch file solution, please '''edit the batch file just now''' to use &quot;scr5_dretchnest_001&quot; instead of &quot;unnamed&quot;. Reason: So that it hurts if you change the prefix or map name later. Get used to this. Of course, you can theoretically rename a map a hundred times before releasing it the first time, but we want to train here. If you decide to wait with the batch file editing, you're technically making the right choice in case you rename later, but you should experience the name lock, it'll help your mind to get into the real mapper world. Also, all following steps will make use of the map name and cement it some more, and '''you do not want the asset folders and the map to have different names. It's enough hassle as it is, and this would double the file naming work.'''<br /> <br /> By the way, how did I come to the name &quot;dretchnest&quot;? Ok, it's not rocket science, but you'd think that about most map names ''once they exist''. Obviously, I thought of Tremulous elements. What you can do to come up with a map name depends on whether you create it at the beginning, in the middle, or at the end of the mapping process. For example, when I came up with &quot;dretchnest&quot;, I had no idea what exactly the map should be like (other than something with 4 walls that you are supposed to clip diagonally in the corners). I only grabbed a name out of the clouds to complete this section. '''But now that I have a name, it gave me ideas about the map.''' Actually ideas that are ill placed in a beginner's mapping guide, so I'm probably not gonna put them into action here, but here they are: There would be a rectangular (Duh. Beginners always make box maps.) room with a few eggs. The room would be closed from all 6 sides, but there would be openings at the bottom, small enough for dretches to get out. Maybe there would have to be contraptions against crouching humans, maybe that would have to be done by basecamping dretches. If you spawn as granger, you can't get out, so maybe I would have added a trigger that checks if you're granger - and kills you. The ceiling of the room would be something that can be set in motion somehow with a button or by making a building or by reaching a certain spot or by reaching stage 3 etc., and this ceiling would squish the eggs in the room. Since there are no other eggs and grangers cannot get out, the aliens would have lost the game (if the aliens still alive don't win it). This is obviously not a standard Tremulous map, but I digg stuff like this (Trem has enough standard maps, lets bring something new to the table). Read the [[Gmotw_Skybox|skybox]] article if you don't know what I mean. That was my first map, by the way.<br /> <br /> &quot;dretchnest&quot; would have been a fitting name for the above described map. See? '''The name idea resulted in a map idea.''' I believe that it's usually the other way round. But it's improbable that the mapper does not decide for a name until the map is completed, because you'd need to test the map from time to time, and so you'd come up with a name to make a release file. (I repeat: The name you choose once you publish the map should never change, if you can somehow make it so.) Once the name is chosen, the name will probably feedback into the mapping process (e.g. you'd want it to be justified, the least you would do is add fitting decorations).<br /> <br /> '''How you can come up with a map name''': I speak english and german, so when I am thinking about the map that I already created a bit, I think of its prominent building and gameplay elements, enter those terms into a Web translator (like [http://dict.leo.org dict.leo.org]) in english or german, and then I play '''translation ping pong'''. You can also use a Web '''thesaurus''' for that. There are also '''map name generators''' on the Web, probably not Tremulous-specific. You'd rather want to use them for inspiration (and to fuel your translator and thesaurus attempts), not to really make the name for you.<br /> <br /> ===make a shader and a texture===<br /> <br /> Now, go to your Tremulous &quot;base&quot; folder. '''Create a new folder in the folder &quot;textures&quot;.''' Name: &quot;scr5_dretchnest&quot;. Why not &quot;scr5_dretchnest_001&quot;? Because then you'd have to re-assign all textures on every new release because the foldername changes. The project you're working on is &quot;scr5_dretchnest&quot;, and that's the name the asset folders should have. You can also make a folder like this in the &quot;sound&quot; folder, but I currently don't plan on talking about adding a sound. But this is the way it would work for sounds, too.<br /> <br /> If you want to add shaders (which we will do - it's easy if you know how), you have to add the release number again. Reason: The shaders are not several files stored in a new folder, like textures will be. No, the shaders of a map are little text blocks that are all stored in one text file. (You can also make several files, but let's keep this simple.) And '''if you change the contents of the shader file for a new release, you have to give that file a new name.''' Just as if you would have to give a texture a different name that you change from one release to the next. If you don't do this, your map will be incompatible with older versions of itself. You can be lucky with that. But lets do this properly. Use this knowledge. Imagine you had to gather this knowledge by experience which I had to... urgh!<br /> <br /> So, the texture folder is prepared. But '''lets make a shader first.''' Go to your Tremulous &quot;base&quot; folder into the folder &quot;scripts&quot;. Create a new text file called &quot;scr5_dretchnest_001.shader&quot;. If we add a shader into it, it will appear in NetRadiant the next time you start it. Well, you'd think so, but for some reason only the programmers know, you have to add an entry in the &quot;shaderlist.txt&quot; file in the same folder. At the end of that file, add &quot;scr5_dretchnest_001&quot; (without &quot;.shader&quot;), press return, save and close the file. Now open the &quot;scr5_dretchnest_001.shader&quot; file again and put the following text into it, save and close the file:<br /> <br /> textures/scr5_dretchnest/brightglass_001_s<br /> {<br /> qer_editorimage textures/scr5_dretchnest/brightglass_001.jpg<br /> qer_trans .5<br /> surfaceparm trans<br /> surfaceparm solid<br /> cull disable<br /> {<br /> map textures/scr5_dretchnest/brightglass_001.jpg<br /> tcgen environment<br /> blendfunc gl_one gl_one<br /> rgbGen identity<br /> }<br /> {<br /> map $lightmap<br /> blendFunc gl_dst_color gl_src_color<br /> rgbgen identity<br /> }<br /> }<br /> <br /> Close NetRadiant. Open it again and load the empty map file you created. If you look at the texture browser now, you'll see an entry called &quot;scr5&quot;. Now, how did that happen? Oh, the stupid nick name prefix idea! Yes, NetRadiant interprets names with a &quot;_&quot; in it differently. It creates categories. So, all your maps will be under the category &quot;scr5&quot; instead of being spread around like crazy.<br /> <br /> Unfold the category by clicking on the little triangle on its left side. &quot;scr5_dretchnest&quot; appears. It does so for two reasons: 1. You created a folder with that name in the textures folder. 2. You created a shader that in turn created the virtual (= not really existing) file &quot;textures/scr5_dretchnest/brightglass_001_s&quot;, so another reason why NetRadiant would think that the folder exists.<br /> <br /> The texture browser should now show an element called &quot;brightglass_001_s&quot;, something like a blue-black checkerboard, expressing that the image which was to be shown here can not be found. No wonder - we didn't make that one yet. And that's a bit tricky, because I don't intend to explain any graphics software to you now. '''You'll just ''somehow'' have to come up with a .jpg file that has power-of-2 dimensions''' (you know... 1 2 4 8 16 32 64 128 and so forth, computer numbers, as mentioned earlier in this article, though obviously, a texture with ''anything'' on it and the size of 32x32 or smaller hardly makes sense), I'd say 128x128 should be the choice here, that's enough for a simple reflection picture (which this one is). Textures don't have to be quare, by the way, but let's keep this one simple. Also, I think that a texture with an arbitrary size (not power-of-2) would work, too - but what &quot;would work&quot; is not the question. What surely will work in all Tremulous clients and with all graphics cards, that's the question.<br /> <br /> The jpg quality doesn't need to be maximum for a texture. &quot;high&quot; (60) or &quot;very high&quot; (80) (as they are called in Photoshop) is good enough. &quot;medium&quot; is too low in nearly all cases, I'd say. You know what would be nice? An actual screenshot you take yourself in Tremulous. Cropped and sized to 128x128 or bigger, util max. 2048x2048 for a normal texture and, I'd say, max. 512x512 for a reflection texture, but that's plenty. By the way: The bit depth per color channel must be 8, as most existing image files are. You can use 16 and even 32 bit in Photoshop etc., but not in the game. While we're at it: You can also use .tga pictures. If you know when to use gif/png versus jpg, then you know when to use tga versus jpg. Example: If you need a simple color texture (pure red, no other pixels), then .tga is the perfect choice. Tga supports an 8 bit alpha channel (save as 32 bit then, not 24 bit) and also a simple and lossless compression that can be used with Tremulous.<br /> <br /> So, assuming that you have somehow found a suitable .jpg file (.tga (even compressed) would also work, but I think you have to change the shader text then, though I believe that I have seen that the file extension named in the shader is irrelevant, but better safe than sorry), move / rename it to achieve this name: '''&quot;textures/scr5_dretchnest/brightglass_001.jpg&quot;'''.<br /> <br /> Again, close and open NetRadiant and feast your eyes on the new contents of the &quot;scr5_dretchnest&quot; texture browser category. Well, your image should be there now. Twice even. WTF? Well, one instance is from the actual file in the texture folder, and the other one is the shader you created. '''Now you see why the shader ends in &quot;_s&quot;: This prevents the names from colliding.''' (Adding &quot;_s&quot; is the way everyone does it.) See? Naming is a really delicate subject!<br /> <br /> So, before we finally start making the goddamn map, let me explain the shader we've created:<br /> <br /> The first line creates the virtual file by giving it a path and filename. Again, take care of those file names, be they virtual or real. The brackets don't need explanation, I guess.<br /> <br /> The &quot;qer_editorimage&quot; line is irrelevant for the game, but it gives our shader a nice image in NetRadiant. If you apply this shader to a wall, instead of the ugly &quot;no pic!!1&quot; texture, you now see your nice .jpg image. Half transparent even! That is caused by the &quot;qer_trans&quot; line, which is also irrelevant for the game. It's there purely for the editor. And both these lines are not necessary for editing. Later, you can add &quot;//&quot; to the beginning of these two lines, which means that they are &quot;commented out&quot;. Anything behind &quot;//&quot; is arbitrary text until the line ends. I don't know, though, if a comment can be written on the right end of a shader command. If you comment these two lines out later, when you've actually used the shader in the map, and restart NetRadiant, you'll probably realize that they are not technically necessary, but man do you want them to be there.<br /> <br /> &quot;surfaceparm trans&quot; says that the surface is transparent. This does not mean that you can look through it - it only means that ''the computer'' can look through it! Yes, he has to know, too. A later command will make the shader transparent for us humans, too. As the name said: It's a glass shader.<br /> <br /> &quot;surfaceparm solid&quot; says that the surface is solid. You cannot walk/fall/shoot through it.<br /> <br /> &quot;cull disable&quot; means that the opposite side of a brush that is completely painted with this shader will not be invisible, as it would be with a normal texture. &quot;culling&quot; means to temporarily remove elements (objects, faces etc.) that are irrelevant for the current situation. To speed things up. But it is disabled here because it's glass, so you can see the presence/absence of backside faces, so they must be there.<br /> <br /> So far, this was the description of how the surface behaves. I'm not the shader pro, so the following explanations might be a little stumbly.<br /> <br /> The next {}block describes the actual graphics that will be drawn. The {}block after that tells the system to also create a lightmap and overlay it.<br /> <br /> &quot;map textures/scr5_dretchnest/brightglass_001.jpg&quot; obviously makes the shader use your new texture file. &quot;tcgen environment&quot; is short for &quot;TextureCoordinateGeneration&quot; with the parameter &quot;environment&quot;. Man, do I have to explain environment mapping now? In short, this makes the texture appear in a way that is not like a normal 3D shape but instead like it were a reflection in the 3D shape.<br /> <br /> &quot;blendfunc gl_one gl_one&quot; means: The pixels of the source (this shader) will be multiplied by one, then added to the destination pixels (which is whatever's already drawn on screen behind the glass) also multiplied by one. So, this just adds your lightened (Remember that this shader has a lightmap.) environmentmap-glasstexture onto the world graphics. Now you might realize why it's called &quot;brightglass&quot;. If you want something darker, look for &quot;textures/tremor/darkglass3&quot;.<br /> <br /> I don't really know about shaders. I look at how the other guys did it (There are already tons of existing shaders, look in the folder &quot;scripts&quot; in the map .pk3 files.), I read a bit in the shader manual, trial and error testing, etc. For example, I have no idea what &quot;rgbGen identity&quot; really does, but it belongs there. If you want to dive into that yourself, read [http://www.heppler.com/shader/ this comprehensive shader manual]. Also, lets drop the rest of the shader explanation and get into mapping, damned.<br /> <br /> ===start making the map===<br /> <br /> Assuming that you're still in NetRadiant with your named map (that doesn't have any stuff in it) open, set the 2D to view from the top, set the gridsize to &quot;9&quot; (256), and draw a square, 8x8 grid elements in size, so it will be 2048x2048 world units. It's not really important where you do this, but since NetRadiant positions the camera at position 0,0,0 every time you load a map (which can somehow be changed with an entity, but I currently don't remember how, saw it in a decompiled ATCS once), I'd suggest that you draw this brush exactly centered around the coordinate 0,0. After you've done so, press CTRL and TAB to set the 2D to view from the side (doesn't matter which). If the brush isn't exactly one grid block high, drag it smaller so that it is. Then move the whole platform so that its upper side (which is the floor to walk on) is at coordinate 0. Unnecessary to say: The whole thing, every face, should have the Caulk shader, the ugly pink one that you already know.<br /> <br /> Copy and paste the selected brush. Click into it and drag it upwards so that its lower side (which will be the ceiling of the map) is at coordinate 256. That's an 8 meters high map hall.<br /> <br /> Press ESC, then draw a square brush left of the two existing brushes, exactly between them. If you press CTRL and TAB, you see that the depth of this square brush is already as we want it because the last selected brush(es) had this depth. Assuming that you're still in the side view in which you drew the square brush, draw another one, on the right side this time. Did you fall for the &quot;something is currently selected&quot; trap, or did you think of pressing ESC yourself?<br /> <br /> Press CTRL and TAB two times to get back to the top view. Now select the two side walls you made. To do that in the 2D view, it's ok to just use the box select in the currently mostly empty map space that we have. So, press SHIFT and then left-click and drag the mouse to select the unselected wall(s). The ceiling and floor (both visible in one place as a big square) must not be selected now! Once you've done that, copy and paste them, then click on the rotate-90-degrees-Z button (a Z with a blue arrow around 90 degrees of the Z). Now you should have a big room with ceiling, floor, and 4 walls. The wall and floor brushes should be edge-on-edge, that will work properly, don't worry. The brushes must not overlap, though! Admittedly, the walls are a bit thick, but they are the outer map walls, so that doesn't matter. Actually, it's not so bad to have them this thick. Why shouldn't they stand out in the editor as a unique structure.<br /> <br /> If you have done it right (which is more probable with this large grid spacing than it would be with a smaller spacing), you should have a proper shell in which you can go crazy without having to worry about [[leaking]]. The [[void]] is properly locked out. The [[VIS]] calculation can hence be performed. You will not have the [[hall of mirrors]] effect.<br /> <br /> Well, yes, you will have the HOM effect, because everything is still Caulk, but we'll change that now. First, select a proper texture: Select &quot;arachnid2&quot;, then scroll down a bit until you see &quot;cement_1_clean&quot;. Now, select all the 6 surfaces that form the room (CTRL SHIFT left-click, and as a NetRadiant user, you'll have learned to press ESC a few times before this new select action, I guess). Then click on the texture.<br /> <br /> '''Save the map. If this is your first save in this &quot;start making the map&quot; chapter, you're still doing it wrong!''' Also, duplicate the saved map file.<br /> <br /> Actually, the floor and ceiling look just wrong this way. Go to the &quot;karith&quot; texture section, scroll down a bit until you see &quot;cement_3&quot;, select only the floor and ceiling face (Not the whole brush, but I guess I don't have to say that any more.) and apply the texture. Save the map. No new backup this time.<br /> <br /> Nice room. If you fly around in it with your camera, you might get the impression that it's too dark. In that case, open the NetRadiant preferences. Don't worry about a message saying that you'd better save before entering the preferences - in most cases, it doesn't matter. Except that saving is usually fast and in most cases not a problem. And if that dialog appeared just now, you didn't save the map when I said so, sinner! :&gt; Go to the preferences section &quot;display&quot;, subsection &quot;textures&quot;, and set the texture gamma to, let's say, 0.8<br /> <br /> ===about clipping, most underestimated by beginners===<br /> <br /> Assuming that the current situation is the result of your actions in the last chapter, you should still be looking from the top in the 2D view. Gridsize should still be largest (key &quot;9&quot;). Now, draw a new brush, 4 grid elements in size, around the 0,0 coordinate. So, the size should be 512x512. The brush should be inside the map shell room that you built, exactly from floor to ceiling.<br /> <br /> We'll use a little trick now. Set the grid spacing to 32 (key &quot;6&quot;). As I said, 32 is the smallest wall thickness you should use if you want to prevent light bleeding. You can be lucky with smaller values or still unlucky with larger ones, but 32 is a good base to work with. I've read somewhere that a thinner wall risks that objects or players might pass through it when playing on the Internet, but I think that's not true, at least I haven't seen problems like these ''ever'' in the Tremulous world, and there are maps with thinner walls around. Another thing about wall thickness: Even a wall with 64 world units might still let the damage effect of a fully charged [[Lucifer Cannon]] shot through a bit. I wonder how much or how little calculation time / network overhead impact it would have meant to prevent this, because this behavior sucks considerably.<br /> <br /> So, with the grid set to spacing 32 and the new 512x512 brush selected, search for the 5th button right of the 90-degree-Z-rotate button. When you hover over it, it says &quot;Hollow&quot;. Alternatively, go to the &quot;brush&quot; menu, submenu &quot;CSG&quot; and select &quot;Make Hollow&quot;. This function is not widely used, because it motivates box rooms (and other reasons, I guess), but right now it's the best thing in the world because it guarantees that you have a new room with 6 walls, all edges ''overlapping'', wall/ceiling/floor thickness 32. (Side note: Why the &quot;hollow&quot; tool doesn't come with the option to automatically clip the resulting brushes is beyond me.)<br /> <br /> Overlapping brushes should be prevented &quot;at all costs&quot;. We'll do that now, too, which brings us to &quot;clipping&quot;.<br /> <br /> Did I say &quot;save the map&quot;? No, and I won't say that any more.<br /> <br /> While still looking from the top, try to select one of the four walls in the 2D view. It's tricky, isn't it? Now you see why you'll select stuff in the 3D view most of the time. But let's try the 2D view again. Press ESC. Then, box-select the middle part of one of the walls (which will also select other stuff). Then, box-select the center of this new room. Shazam, everything except the wall is deselected. Box-select inverts the current selection where it is in effect. Also, nice that we activated &quot;display size info&quot; in the preferences (&quot;orthographic&quot;) before, because now we can clearly see that all elements of the current selection have the position and size of the wall we wanted - which makes it reasonable to assume that only the wall is selected. Once your maps are a bit more complex, that assumption is not so reasonable. I think that it would save the mappers of the world tons of time if there were a simple but prominent number stating how many elements are currently selected. Well, rudimentary tool, as I said. Instead, you can see how many milliseconds it took the 3D view to redraw.<br /> <br /> Now that one wall is selected, choose a different tool. Currently, the button with the square on it is activated (&quot;Resize (Q)&quot;). Activate the button right from it, the one with the diagonal line (&quot;Clipper (X)&quot;). This tool can be used to cut away parts of brushes or to split them into two brushes. Reminder: The preferences of the &quot;clipper&quot; should be set to &quot;Clipper tool uses caulk&quot;.<br /> <br /> You have to cut away a small diagonal part of the wall in the corner. What we want to achieve is that the four walls do not overlap in the corner but do instead end exactly where the next one begins. Yes, you could just use the resize tool for that, but that's not how a good mapper does it (except when it makes more sense than clipping). Imagine: When the walls are clipped in the way I described it, then not just the outer walls will be perfectly connected, but the inner walls, too. So, when you paint textures on them, you can use the &quot;fit&quot; tool of the &quot;surface inspector&quot; (key &quot;s&quot;) to make the texture fit the wall perfectly while you can mostly forget about all the numbers in that window. Or, if you're dealing with the numbers, you can copy them from other surfaces because the other walls have the same special properties (brush corners clipped).<br /> <br /> Well, if you had drawn the walls edge-on-edge like you did with the outer map walls, painting the inner walls would be exactly as easy as the clipped result will be. But we want to paint the outer walls, too! This will be a room visible from the outside, hence it must be properly built.<br /> <br /> So, let's just try to clip one of the corners of the selected wall now. Choose one end of the wall, then click once on the corner that is outside of the room, then on the one that's inside of the room. Two blue dots (&quot;1&quot; and &quot;2&quot;) should have appeared. The line that connects them should point from the outside room corner to the inside of the room. Also, there is another line (the &quot;perpendicular&quot; or &quot;normal&quot;) beginning at the middle of the clip line. Both lines are not existing objects but just editor tools.<br /> <br /> Press ENTER. So, the brush was divided by that clip line you made, and now one of the two parts of the brush is gone. It's the one that the additional line (the &quot;normal&quot;) went through, that's the rule. Which way the &quot;normal&quot; points depends on the order in which you created the clipper points. Also, you can invert the clipper direction (menu &quot;brush&quot;, submenu &quot;clipper&quot;). Also, the brush part that will stay will have the clip face painted blue in the 3D view (as long as you didn't complete the clip by pressing ENTER).<br /> <br /> Clipper tips: You can drag the clip points around on the 2D view. You can even add a third point. You can change the 2D view from top to side etc. and then still drag the points around. And you cannot remove the clip points by pressing ESC. To remove them, you have to select a different tool (like &quot;resize&quot;) and then switch back to the clipper tool. Or just click again once all 3 clipper points are placed, because that will place number 1 again, removing the other two. Only if you click directly on one of them, you can drag them.<br /> <br /> Very frustrating: While the &quot;undo&quot; can be used to return to the unclipped brush, it does not return you to the situation with existing clipper points, so you have to place them anew.<br /> <br /> Now that you kinda know how to work the clipper tools, clip all 8 wall ends diagonally, so that the walls are perfectly face on face, not overlapping any more. So that the inner walls start and end exactly in the inner room corners.<br /> <br /> Wow, finally done with the stupid clipping. Let's paint and resize a few more blocks, right? No. The clipper tool is one of the most important tools in mapping, and you'll use it much more often than you can imagine right now.<br /> <br /> For example: It's time to clip the ceiling and floor so that they diagonally meet the walls - which, thusly, also have to be clipped. In the end, all 6 walls/floor/ceiling of the little room will be kinda like the bottom ends of pyramids pointing into the room, perfectly face to face which each other. During all this, you should leave the grid spacing on 32.<br /> <br /> Done yet? An experienced mapper needs 1 or 2 minutes to finish this properly.<br /> <br /> You might be wondering why we didn't just delete the ceiling and floor of the little room (after all, there's still the outer map ceiling and floor). Reason one: Using a map shell room like we did is a crutch. Not necessarily a bad one, but also not necessarily the way an experienced mapper does it. Reason two: You'd make yourself dependent on the outer ceiling and floor, and once you get out of the room and map some more, you'll have more dependency-situation-possibilities like this. You don't want to tie it all together and stand in your own way. I had that when making skybox. &quot;Can I texture this wall? No, damned, it's the outer wall again.&quot; Reason three: Lightmaps! I don't know how exactly it is decided how many pixels a lightmap has, but I am pretty sure that a huge brush will have a less high resolution (so, rather stretched) light map. Oh, speaking of which:<br /> <br /> ===_lightmapscale, gridsize, turbo rendering===<br /> <br /> (You can skip this now and go to &quot;enjoy the fruits of the clipping labour&quot;. One day, you should read this, though.)<br /> <br /> I already explained the worldspawn. Press ESC and select any one of the brushes. Since we currently only have simple worldspawn brushes (as opposed to, for example, doors), you could also just box-select a bunch of them. Anyway: Press &quot;n&quot; if the entity inspector was not yet visible. As you know, the second section shows a help text for the currently selected entity type, and since the third section shows &quot;classname worldspawn&quot;, the help text describes the worldspawn. Scroll far down (not to the end) until you see the explanation of &quot;_lightmapscale&quot;. Read it. Then, write &quot;_lightmapscale&quot; and &quot;0.25&quot; into the &quot;key&quot; and &quot;value&quot; textboxes and press RETURN while you're in the value textbox. I thoroughly tested it in a relatively small room: Values smaller than 0.25 don't increase the lightmap resolution any more.<br /> <br /> Setting the lightmapscale to 0.25 will result in a higher lightmap resolution, so you'd have better shadows etc., think of the difference between the thumbnail of a picture and the full size version (only the difference is not that drastic here). The default setting is &quot;1.0&quot; (when the _lightmapscale key is not present). 0.25 also means that the LIGHT phase, in which the lightmaps are calculated, will take much longer. This also means that larger settings than 1 will make it shorter.<br /> <br /> If you've followed this mapping crash course so far, you'll either have prepared q3map2 frontend &quot;q3map2build&quot; or a build batch file, and you will have done so that the light rendering result is very good:<br /> <br /> &quot;fast&quot; is not activated. &quot;bouncescale&quot; is on 2, &quot;bounce&quot; is on 500 (meaning: effectively &quot;6&quot; or something). And to top it off, your map now has the best lightmap scale. The option &quot;filter&quot; is not relevant for the calculation time. It will smooth the resulting lightmap a little so that shadow seams don't look so pixeled. I am not repeating all this from other guides, these are actual experiences that I gathered in many tests over months.<br /> <br /> Now, as long as your map is very small, these settings are ok. Calculation will be done in a few minutes or less than a minute. But once your map is a huge monstrosity, calculation with these settings takes several days on a fast computer. That's still ok as long as you have an extra machine for things like these, but '''here's how you can speed up the rendering like crazy''' (resulting in less good result, of course):<br /> <br /> Add the key &quot;gridsize&quot;, value &quot;1024 1024 1024&quot; to your worldspawn (default would be 64x64x128 as far as I know, and to achieve default, just delete the key again). As far as I know, the gridsize defines the ''volumetric'' lightmap calculation. If you get closer to a bright red spot in the map, your weapon will receive red light. If the gridsize is as coarse as we have set it here, those effects will be less prominent. I could be totally wrong about this. Maybe the gridsize is more about how the raytracing really takes place. In any case: Changing the gridsize has ''huge'' (!) impact on the calculation time. Setting it to this value will make it faster. Deleting the key, so that you're back on the (very good) default value makes it slower. Setting the gridsize to something like 48x48x48 increases the calculation time insanely, and as far as my test results go, it doesn't have any merit. So: For high quality results, you'd use the default setting. For quick and less proper results, you use the 1024 (or an even rougher) one.<br /> <br /> You can also drop the &quot;bouncegrid&quot; option. Bouncegrid means that before every radiosity bounce, the lightgrid (see &quot;gridsize&quot;) is calculated anew, because somethingsomething bounce influence grid somethingbla. Honestly, I didn't test the difference it really makes, but I believe that it's safe to assume that this option increases the light rendering quality even further.<br /> <br /> Change the rendering settings (in &quot;q3map2build&quot; or your batch file) so that the LIGHT phase uses the key &quot;-fast&quot;. This does not change the lighting ''very'' much (but still too much for my taste when I want to make a real proper release), but it insanely reduces calculation time.<br /> <br /> Removing the &quot;bounce&quot; option (&quot;bouncescale&quot; is irrelevant for the time (except in regards of the caused number of iterations) and is bound to &quot;bounce&quot;, so you don't have to touch it here) has strong influence on the lighting. You should try to have a few bounces in your released maps, the light looks considerably more natural. Removing the &quot;bounce&quot; option decreases calculation time, though. Very much even. If the initial pass (not yet bounced) takes 10 seconds, every bounce will also take about 10. If the first took 1 day, guess what. Depending on the bouncescale you used, the amount of bounces will have strong influence on the lighting result. This is something for tweaker guys. Just as the &quot;gamma&quot; option (that I didn't mention yet) in the LIGHT phase is. You should know that these options exist and that it's a good idea to toy with them. Now let's move on.<br /> <br /> Another option that you can add to speed up calculation: &quot;-fast&quot; in the VIS phase. Please don't do this, though, if you want to release the results into the public. And definitely don't release the result if you omit the VIS phase completely - which you can also do to decrease rendering time even more. The VIS phase calculates which spot of the map can be seen from which other spot. This information allows the game engine to draw only the necessary graphics. As far as I know, it also influences the radar functions of helmet and aliens. It's essential for a release, and you should do it without &quot;-fast&quot; for a release.<br /> <br /> '''In short:'''<br /> <br /> '''For fast rendering''', add &quot;-fast&quot; to the VIS phase (or drop it completely), add &quot;-fast&quot; to the LIGHT phase, remove &quot;bounce&quot; from the light phase (or just &quot;bouncegrid&quot;, but I think if you're already doing bounces, you might as well do them properly), remove the &quot;_lightmapscale 0.25&quot; thing from the worldspawn, add &quot;gridsize 1024 1024 1024&quot; to the worldspawn.<br /> <br /> '''For best (slow) rendering''', have a not-fast VIS phase, not-fast LIGHT phase, bouncegrid, bounce 500. Remove &quot;gridsize&quot; from the worldspawn. Add &quot;_lightmapscale 0.25&quot; to the world spawn.<br /> <br /> If you want to see a map that rendered for 112 hours with lightmapscale 0.25 and 11 radiosity bounces (Then it was tuesday morning and I needed the computer :/ Yes, you can abort the calculation at any time. Previous bounces will still be existent, and the current half-done one will also not be visible.) and want to see what the higher lightmap resolution might do to a 128MB graphics card, take a look at [[Gmotw_Skybox]]. I'm not really proud of the rendering result. There should be more shadow cast situations and so forth, but it's the best I have to offer in that regard yet. I think the lightmap can best be enjoyed in and above the pump station.<br /> <br /> ===enjoy the fruits of the clipping labour===<br /> <br /> Inspect the result of your work. It's very useful that you can move the camera to the inside of a wall, making it temporarily vanish from the 3D view.<br /> <br /> While you were working on the clipping, I picked a nice texture to demonstrate the described advantages of clipped walls. The texture browser should still be in the &quot;karith&quot; section, showing the &quot;cement_3&quot; texture (near the top). Scroll a bit further up until you see a broad texture called &quot;base_grooved&quot;. (Well, you might have a hard time finding it if there's another texture with a long name to the left of it, because then, the name on screen is partly overwritten. As I said: Rudimentary tool.) It should be the 8th texture. Press ESC and then click on the texture. At the bottom of the screen, there should be a text saying &quot;textures/karith/base_groove...&quot;. The texture looks like someone used a comb on a gray piece of butter from the left to the right.<br /> <br /> Now, select one of the faces inside the little room, then click on the texture. If you have done everything like I described, you'll see the texture on the wall, but there's something like a split in its middle. What you see are the outer ends of the texture. Textures are always looped on the brushes, so now lets place this texture properly. Press &quot;s&quot; (if the surface inspector was not already visible), then click &quot;Fit&quot; (if there is a 1 in both text boxes beside the fit button, otherwise set the boxes to 1 (or 1.000000, it's the same)). That was easy, wasn't it? Imagine what would have happened without the clipping. The texture would be partly hidden. If you look at the surface inspector and the numbers in it, can you imagine the hassle of adjusting everything until it looks like it does now?<br /> <br /> If you look at the horizontal and vertical stretch, you see something between 0.5 and 1 (and they are different - thank the programmers for the &quot;fit&quot; button). That's kinda ok-ish, but smaller values mean higher texture resolution. Only we can't put the texture in twice because that doesn't look good, either. The &quot;width&quot; and &quot;height&quot; value next to the &quot;fit&quot; button, by the way, define how often the texture is to fit the surface when you click &quot;fit&quot;. Yes, &quot;0.5&quot; etc. works, too.<br /> <br /> Paint all four walls in the described manner. You can do them all at once.<br /> <br /> After that, paint floor and ceiling with the next texture in the list, &quot;base_small&quot;, and fit it in 1 by 1. Again, this wouldn't have worked so easily without clipping. The horizontal and vertical stretch are close to 2, which is much too high. You can already see how blurry and cheap it looks. But keep it for now.<br /> <br /> ===let's add a door===<br /> <br /> Look from the top in the 2D view. Set the grid spacing to 128 (key &quot;8&quot;). Select one of the 4 walls. Just for training, let's use the toggle-selection, so press and hold SHIFT and ALT, then click on one of the 4 walls a few times until it is selected. You don't have to press ESC before this.<br /> <br /> With the wall selected and the clipper tool active, click on the wall. Gridwise, it has 4 sections. Click so that 3/4 of the wall would be cut off. Umm, where to put the second clip point? The grid doesn't allow to put it on the wall! Well, doesn't matter. Just put it a bit further away. Only the direction and position of the line itself must be correct, not its length. If you have made a nice (and non-diagonal) clipping line, press SHIFT and ENTER or select &quot;split selection&quot; from the &quot;brush&quot; menu, submenu &quot;clipper&quot;. You have cut the wall into two segments. Do that again on the other side, so that the middle segment is two grid elements in size. By the way, you can join brushes if the result would &quot;make sense&quot; (convex brush) using menu &quot;brush&quot;, submenu &quot;CSG&quot;, item &quot;CSG merge&quot;. If you try to merge brushes that can't be merged, you'll see an error message in the log area.<br /> <br /> Ok, now deselect everything (ESC). Then '''select the middle part of the split wall. Then, right-click in the 2D view, go to &quot;func&quot; and select &quot;func_door&quot;. You just made an automatic door''' that opens to the side if you get close, complete with sound. Nice, huh? Let's change the angle to &quot;top&quot; by adding the key &quot;angle&quot;, value &quot;-1&quot; in the entity inspector.<br /> <br /> You could actually make a door that uses a sensor that only reacts to someone carrying a lucifer cannon. Or to dretches and dragoons. Then, a sound would play and dark light would go bright (without lighting the environment, though (then again, I think it can be done using a shader with specular lighting)). Bars in front of the door would move to the sides (with sound). Then, the door would ''rotate'' open kinda like a garage door. Later, everything would move back. This can really be done using triggers, delays and so forth. But dude, I'm not gonna guide you through that.<br /> <br /> You can adjust the door in the &quot;entity inspector&quot; (&quot;n&quot;). You can change the sound, the direction into which it opens, how much of it is still visible once it's open, whether its default is open or closed, how much damage it does to you if you stand in its way, how fast it moves and more. The &quot;lip&quot; value is especially useful. You know, a door is just a brush (or a bunch of brushes - yes, '''you can make complex designs and have them move as one unit''') that moves. It has convenient defaults and a sensor. But you don't need to use the sensor. Also, '''you can use huge negative values for the &quot;lip&quot;, making the door move much further than necessary when it opens. And what is that then? A lift! :)''' There is also an extra lift function, but its default sounds are broken, and also it cannot be set to &quot;crusher&quot;, as far as I know. The big lift in skybox is a door, consisting of several brushes. '''Doors are really versatile.''' You know what? I once used doors to make a programmable soundtracker in Tremulous (&quot;gmotw_pianolessons&quot;, named like this because there's also a big piano with black and white keys that you can step on, and guess what, they are all doors). 16 doors would hammer down in a sequence, and their &quot;I'm closed now!&quot; sound wouldn't play if they don't arrive at the closed state, so I just made buildings in their way to program the sound steps. Did I say that doors are versatile yet? A server where you can save the current building layout can then even save the rhythm for later! Problem is, once too many elements are used, the rhythm stumbles a bit. Maybe a faster computer or newer Trem client doesn't have that problem. I used 16 steps and 3 instruments (bassdrum, snare, closed highhat), and it already got a bit stumbly. Another thing you can do with a door is use it as a busy-light that appears from out of nowhere (was hidden in a wall) and vanishes once the busy cycle (lift or whatever) is over. Also, I once made a door that actually consisted of 8 by 8 doors that you had to shoot. It was a pixel-door. If you didn't shoot the pixels away fast enough, they would return and you wouldn't get through. A tyrant (or whatever) filter. A dream if you carry a lucifer gun. That was in skybox, but I had to remove it in later releases because with all the other map elements, it reduced the FPS too much. But the door maze is still in the map. Looks like solid walls, but it is a small 2D maze. No, even 3D.<br /> <br /> Now, press &quot;h&quot; to hide the door and move the camera so that you look at the room from the outside. We'll now paint the frame of the door. Use the texture &quot;base_verts&quot; which comes shortly after the &quot;base_small&quot; that we used for floor and ceiling. Select the two faces at the side of the opening. Click the texture. Click &quot;fit&quot;. If you look at the stretch values, you see that one is 0.5 and the other 0.25, which can look odd, so better enter a &quot;2&quot; instead of the &quot;1&quot; in height (next to the &quot;fit&quot; button) and click &quot;fit&quot; again. The texture is now used 2 times in height, so it is not as streched in that direction. Press ESC. Then select the upper and lower face of the opening. Click the texture. Looks wrong. Now what? Well, it needs to be rotated. If you look at the &quot;rotate&quot; text box, there is a &quot;0&quot; in it. The text boxes on the right side can be changed at any time without influencing the map in any way - they are only an editor tool. The box right to &quot;rotate&quot; should have a &quot;90&quot; right now. If so, click the up or down arrow (doesn't really matter now) of the rotate value, changing it to 90 or -90 degrees. The texture looks better now. Click &quot;fit&quot;. Damn, bad stretching. Change the height preference to &quot;4&quot; and click &quot;fit&quot; again. See? The &quot;height&quot; now means &quot;width&quot; because the texture is rotated.<br /> <br /> If you look now from the inside of the room, you'll see that the wall (not frame) texture is cleanly cut, as it should be. If you would want to apply and fit the texture now, you'd have problems. '''To use &quot;fit&quot; on a surface with the &quot;wrong&quot; size, temporarily resize the wall to an appropriate width, click &quot;fit&quot;, return the size to normal again.'''<br /> <br /> Paint the 3 outer walls with the texture we used on the inside walls (for that, select an inside wall surface and use CTRL and C, which will not just copy the texture settings, rotation and so forth, but will also select that texture in the browser, so you can just click it then instead of using paste). Don't forget to fit (1x1). Paint the two short front walls with the texture &quot;base_v_rigged&quot;. Fit them in (1x1). By now, you'll have realized that the textures are sorted by alphabet. <br /> <br /> Press SHIFT h to get the door back. Press ESC. Select the door. Press i or choose &quot;invert selection&quot; from the edit menu. Press h. Now, only the door is visible, and it obviously needs some texturing. Put &quot;base_small&quot; on the outside and inside (fit 1x1).<br /> <br /> The four outer sides of the door are still unpainted. Let's select them all at once and then apply &quot;base_verts&quot;. Fit them 1x1. There's a problem: Even though the stretch values on the side surfaces are different from the top/bottom surfaces, you only see one number pair. Keep that in mind, also when dealing with the entity inspector while several elements are selected. A common reason would be to copy the values of one door to another. Select the correct door first, the one you want to fill with values as second, and for every value that you want to copy, click it and then press ENTER in the &quot;value&quot; text box to re-apply the key-value-pair to the correct door, which will also copy it to the other(s).<br /> <br /> So, let's do this again properly (and maybe you have already realized that this is all wrong, then follow me without acting, also smile). Press ESC. Select both side surfaces. Click &quot;fit&quot; with 1x2, so both stretch values should become &quot;0.25&quot;. Select the top and bottom, rotate the texture by 90 degrees, fit 1x2. Why not 1x4 like the same surfaces of the room walls? Because the surfaces of the room walls didn't begin/end at the door opening! So, we have a few meters of unnecessarily painted faces there. I don't know if a real pro mapper would now fix that by causing a few more brushes or if they would just ignore the few meters of unnecessary texture. We'll just leave it at this now. Don't tell anyone.<br /> <br /> The door is now painted on the front, back, and on the other 4 sides. Unnecessarily. The reason is that we didn't think enough like a mapper should, instead we were stuck too much in real-world thinking. Since you will never get to see the left, right and top side of the door, we should apply the Caulk shader to them.<br /> <br /> The texture browser has a little drop down menu, too. Go into that &quot;view&quot; menu and click &quot;hide unused&quot;. This hides all textures from the texture browser that are currently not used by the map. Even better: Also select &quot;show all&quot; from the same menu. Now, every texture that you had loaded in this program session (except the unused ones because you just hid those) is in the texture panel. You should memorize this trick, it will make your mapping much easier. For example: The caulk shader is here! Apply it to the left, right, and upper surface of the door. Then press SHIFT h to unhide everything.<br /> <br /> Press ESC. Select the door. Go to the entity inspector. Add the key &quot;lip&quot;, value &quot;80&quot; to the door, because otherwise it would look kinda weird while open. A bit of its lower end would stick out of the ceiling without any apparent cavity or mechanism for the door. With &quot;80&quot;, it sticks out so far that no one will ask questions.<br /> <br /> This, by the way, makes another surface's texture unnecessary. Since I don't plan on toying around with the door some more, let's set that surface to caulk, too. So: Hide the door. Then look from the outside. The upper diagonal surface will be invisible because the door will never reveal that surface.<br /> <br /> ===let's populate the map===<br /> <br /> Add an &quot;info_player_intermission&quot; entity. (I won't tell you how because I already did. If you didn't read the whole truckload of text, use the in-page-search function of your browser.) Move and rotate the entity so that it looks at the door of the little room from the outside, from a bit further away, slightly diagonal so that you can see the side wall of the room, too, and much of the rest of the map.<br /> <br /> Press the &quot;1&quot; key for the highest grid resolution that you can achieve with the keyboard. In the room (top view in 2D), create a &quot;team_human_reactor&quot; entity. Move it around a little. Then press &quot;8&quot; for grid spacing &quot;128&quot;. Move the reactor again. You see that the amount by which it moves is 128, as the grid forces it to. But its position is kinda off (if we're not unlucky). To force the reactor back into a nice x y and z grid position, press CTRL and &quot;g&quot; or use &quot;snap selection to grid&quot; in the &quot;brush&quot; menu. Now, with the 128 grid, move the reactor as far into the corner as possible. I don't care which one, as long as it's not on the door side. Switch the 2D to side view, set the grid to &quot;7&quot; (64), drag the reactor to a reasonable height position. It must not be in or above the ceiling and not in or below the floor.<br /> <br /> Rotate it around the Z axis by 90 degrees until the nice control panel can be seen. You might even want to rotate it arbitrarily by 45 degrees and then in 90 degree steps until it nicely faces the room.<br /> <br /> Also build an armory, a medistation, two nodes and a few turrets. Give them enough space. Especially the armory is tricky. Too few people know that '''the game system only allows square [[Hitbox|hitboxes]]'''. The height can vary, but the shape when seen from top is square. Even the armory? '''Yes, even the armory.''' If you keep that in mind, it will explain every occasion on which the armory or a nearby building didn't appear in the game.<br /> <br /> You should already rotate the turrets so that they face the door. This is not a [[Building|base building guide]], so I'll stop here.<br /> <br /> Don't forget to make a few alien buildings (overmind, SPAWN!, ...) somewhere in the outside hall.<br /> <br /> Then add &quot;player_human_intermission&quot; and &quot;player_alien_intermission&quot; (one of each) and make them look at the human and alien base.<br /> <br /> You can have a look at the map if you want, even though we haven't placed any lights yet. Just omit the LIGHT phase. Everything will be at full brightness. The batch file:<br /> <br /> &quot;C:\Program Files\netradiant-20100214-win32\q3map2.exe&quot; -fs_basepath &quot;C:\Program Files\Tremulous&quot; -fs_game &quot;base&quot; -custinfoparms -info -meta -patchmeta &quot;C:\Program Files\Tremulous\base\maps\scr5_dretchnest.map&quot;<br /> &quot;C:\Program Files\netradiant-20100214-win32\q3map2.exe&quot; -fs_basepath &quot;C:\Program Files\Tremulous&quot; -fs_game &quot;base&quot; -vis -saveprt &quot;C:\Program Files\Tremulous\base\maps\scr5_dretchnest.map&quot;<br /> &quot;C:\Program Files\Tremulous\tremulous.exe&quot; +set fs_basepath &quot;C:\Program Files\Tremulous&quot; +set fs_game base +devmap &quot;scr5_dretchnest&quot;<br /> <br /> ===lighting===<br /> <br /> On second thought, you should definitely look at the map right now. With full brightness, it sucks. Once we've added nice lighting, it will look so much more pleasant. Lighting makes and breaks the mood.<br /> <br /> Just as decorations (which we haven't dealt with yet) are not a burden but a passion to a real mapper, lighting is not something to be dealt with by just throwing strong point lights with no apparent light source (fixture) all over the place. And definitely '''''do not'' use the &quot;_minlight&quot; or &quot;_ambient&quot; features in the worldspawn.''' You might use them sometimes - really rarely - to test something, but a map with proper lighting will, I dare to claim, never have one of these features in use.<br /> <br /> '''There are two possible light sources:''' Point lights (which can be made with the right-click menu) and light textures (or light shaders, same thing, different term). We have already dealt with shaders. It's possible to make shaders with a parameter that makes it emit light. The larger the surface that uses the light shader, the more light is emitted. The advantage of using light shaders is that you always have a &quot;something&quot; that the light is actually coming from. This contributes considerably to the mood, because it is more believable. You can, of course, just build a &quot;something&quot; that might be a light, then add a point light source to it. That works, too. Actually, the main reason people rarely do that probably is that you can't group brushes and point lights together. You see, the &quot;worldspawn&quot; entity is not the only &quot;dead&quot; entity that can hold brushes. '''You can also select a bunch of brushes and then select &quot;func_group&quot; from the right-click menu.''' This creates a new entity of type (or &quot;classname&quot;) &quot;func_group&quot;. You cannot add other entities (like light or a doorbrush) to such a group which is sad, because if you could, people would probably also try to construct light fixtures and then just put a point light into them instead of fiddling with shaders. And what is the advantage of such a group? Well, if you select one of its brushes, you can then use &quot;expand selection -&gt; to whole entities&quot; from the edit menu. You can then conveniently move them around or copy/paste of them - which creates a new func_group with the copied brushes in them. The expand selection function also works for several such things in parallel. Sadly, I haven't yet found out how to add another brush to such a group. &quot;regroup&quot; in the &quot;entity&quot; menu does the opposite of what you'd expect, and I haven't tried the next function, &quot;ungroup&quot; because I suspect that it does what you'd expect.<br /> <br /> ===decorations, structural/detail brushes===<br /> <br /> <br /> <br /> ===create a release file===<br /> <br /> <br /> <br /> [[Category:Mapping]]</div> Wed, 14 Jul 2010 11:05:21 GMT God, maker of the world http://tremulous.net/wiki/Talk:Mapping Mapping http://tremulous.net/wiki/Mapping <p>God, maker of the world:&#32;/* obtain a frontend for q3map2 */</p> <hr /> <div>A [[mapper]] is a person who creates a game [[map]]. He is &quot;mapping&quot;. This article describes how that works in the Tremulous context. For a list of a few existing Tremulous maps, click [[:category:Maps|here]].<br /> <br /> <br /> =mapping crash course=<br /> <br /> I started this article on 2010-06-29, just so you know why it doesn't refer to Tremulous 1.2 etc. I am a Windows user (2000 and XP), so that's the perspective that I use. If you can't translate that into your perspective, then you probably shouldn't use the system you're using.<br /> <br /> There are already several mapping guides out there ([http://tremulous.net/forum/index.php?topic=7497.0 list]), one of the best of which is at [http://tremmapping.pbworks.com/ tremmapping.pbworks.com]. It is easy and very comprehensive. I'll try to write a new one from scratch here based on my experiences - and much more up to date. It will save you some steps that were necessary 3 years ago when the linked guide was made. This article here will not enable you to make good maps, but it will give you a truckload of know-how of the kind you don't find in other mapping guides.<br /> <br /> If you've ever written something like a guide, you know that you'll inevitably get into ramble mode from time to time. I guess you can forgive me that.<br /> <br /> <br /> ==setting up your computer==<br /> <br /> ===Tremulous client===<br /> <br /> Download and install the original Tremulous 1.1.0 client. It can be found [http://tremulous.net/files/ here], but it's all over the Web, just search. Now, you ''could'' use a different Tremulous client, but I suggest that you don't. Reason: The original client is what many people out there still use, and when you test your map, you'd want to see what it looks and behaves like (and if it works at all) in the client all those [[newbie|noobs]] use who wouldn't know how to fix a problem if your map causes it. You want your map to work and to shine in the original client. You don't want it to look great only in the latest client with magical rendering v9.9.999 and bloom effect.<br /> <br /> Maybe also download the [http://tremulous.tjw.org/backport TJW backport] client. It's a slightly updated version of the original client. Not too new to violate what I said in the previous paragraph. This is not a full Tremulous release. It's just the program itself. Put it into the program folder of the above mentioned original client. This client supports [[GUID]] and much faster auto-[[Cl_allowDownload|download]].<br /> <br /> You might already have all this. But consider starting anew in a VirtualMachine or on a new computer. If you're more proficient, you'll be able to maybe clean up all your Tremulous base folders so that you don't have magical conditions that a person using the naked client wouldn't have. If you're not proficient enough in this and don't want to make a clean install, prepare to experience problems like &quot;But the texture wasn't missing on my machine!&quot;.<br /> <br /> ===NetRadiant===<br /> <br /> Now the most important part: Download and install [http://ingar.satgnu.net/gtkradiant/installation.html Ingar's NetRadiant and the Tremulous support files]. That's two downloads. The instructions on the linked page are short and comprehensive, it's easy to do. [[NetRadiant]] is the tool that you actually make the maps with. You probably also heard about &quot;GtkRadiant&quot;. Forget it. It's 99% the same as NetRadiant, but it's no longer developed. Also, installation is more complicated because it is not prepared for Tremulous. Additionally, Ingar's NetRadiant already includes the [[Q3Map2]] program that compiles your .map document to a playable .bsp map file.<br /> <br /> Change the NetRadiant preferences (and learn a few things about them): Start it. You'll probably see a little window offering a game type selection. Choose &quot;Tremulous&quot;. There's also a checkbox to prevent this window from appearing every time you start NetRadiant. Technically, that was all. But please, continue adjusting the preferences: Go into the preferences window, which can be found in the &quot;edit&quot; menu at the bottom. I'll go from top to bottom, not from most to least important.<br /> <br /> '''Textures:''' Later, you might want to change &quot;gamma&quot; to something like &quot;0.8&quot; to make the 3D display of the editor brighter. '''Undo:''' Increase queue size to 128. You'll use undo very often, sometimes to undo shifting textures around, and that's an undo step for every texture shift step even if it was a button autorepeat result.<br /> <br /> '''Brush:''' Definitely activate &quot;Always use caulk for new brushes&quot;. You can also activate &quot;Use alternative texture-projection&quot;, but most people do not do that, so if you want to open their maps, you'd have to turn it back off and restart the program. And there is no way to convert a .map from one setting to the other. If you decompile a playable map you found somewhere (like ATCS etc.), you would need to use the alternative projection to load the result in NetRadiant, so why not completely live in that world? I, however, have not done so. Because I didn't know better when I started mapping. I also don't know if I would ever regret turning this option on to make my own maps, so be careful. Maybe better leave it off.<br /> <br /> '''Grid:''' Set default grid spacing to &quot;32&quot;. That's the smallest room-wall-thickness that you want to use to prevent [[light bleeding]] (though the best measure to prevent light bleeding still is clipping). Once you're an experienced mapper, you might want to set this to &quot;256&quot;, the largest setting. '''Camera:''' Movement Speed 100 is good, but you'll come back later and change this, depending on your mapping situation. (I think NetRadiant should have a control element on the edit window to adjust the camera more quickly.) Smaller value for working on details, larger value if you have to travel a lot with your editor camera. Enable far clip plane: It's best to turn it off for now, you'll see everything then, no matter how far away it is. Enabling this option and setting the far plane to something close (menu &quot;view&quot;, submenu &quot;camera&quot;) would be helpful for selecting stuff with the box selection. Also, depending on your hardware and the map, it can speed up display considerably.<br /> <br /> '''Orthographic:''' Turn on &quot;display size info&quot; which will show you the size of one or more selected objects in the 2D view. Turn off &quot;chase mouse during drags&quot;, it would turn you crazy. '''Clipper:''' Definitely activate &quot;clipper tool uses caulk&quot;. '''Autosave:''' Deactivate it. If you're not a total computer noob, you'll know and use CTRL+S oftentimes anyway, and the autosave feature really gets in the way. The coders don't even reset the autosave timer when you hit CTRL+S (lol), so you're better off without it. Saving can take some time on bigger maps, so you want to be in control here. Also, very important: Make backups! Once you saved your map, go into the folder and duplicate the file (CTRL+C, CTRL+V, or whatever it is on your system). Sadly, the Radiant coders didn't include a save rotation like jEdit has it. You have to do that manually.<br /> <br /> Later, when you've worked a bit with NetRadiant, you might want to change the grid colors in the menu &quot;misc&quot;, submenu &quot;colors&quot;. My &quot;grid major&quot; is &quot;#00DF00&quot; (a big fat green) and &quot;grid minor&quot; is &quot;#ADFFAD&quot; (a very bright green, fading into white). Now, you should go into the &quot;view&quot; menu, submenu &quot;show&quot; and activate &quot;show workzone&quot; which will draw additional line garbage in the 2D view - the stuff you have drawn/selected last will have an additional red line pair around it. Makes it easier to find it. You have no idea how confusing the 2D view will become once your map is a bit more complex. Rule of thumb: Before you find the lines in the 2D view confusing, you shouldn't even think about presenting your map to the community.<br /> <br /> ===create the asset folders===<br /> <br /> '''Manually create folders in the base folder:''' You already know the base folder. You extracted the Tremulous support file here as Ingar's website instructed. Now, manually create a folder called &quot;maps&quot;. Also the folders &quot;textures&quot;, &quot;sound&quot; (NOT &quot;SOUNDS&quot;), &quot;scripts&quot;, &quot;env&quot;, &quot;models&quot;. If you have already seen a [[.pk3]] file from the inside, you'll have realized that the folders in those archives are treated by the game client as if they were really existing. So, you'll have guessed what those folders you just made will be used for: They'll hold the exact same kind of files that you see in the .pk3 map files.<br /> <br /> ===obtain a frontend for q3map2===<br /> <br /> If you're on Windows, definitely download [http://www.bobdev.com/q3map2build.php q3map2build]. The program is not necessary to make a playable map, but it's a big help in compiling. NetRadiant already has a build menu which calls q3map2 with parameters, also you could manually create batch files and just launch them every time you want to compile a map, which makes sense if you need very special settings for a map. For example: I worked on a map where I used q3map2's &quot;gamma&quot; option, quite unusual, so you would probably not reconfigure NetRadiant's build menu for that. You'd instead use a batch file. Or q3map2build.<br /> <br /> This VisualBasic program is a '''frontend for q3map2'''. It creates batch files and executes them. Depending on what you selected, there will be up to four lines in such a file: The first one compiles the binary BSP file from your MAP ascii document. The second one (&quot;[[VIS]]&quot;) calculates what point on your map can be seen from which other point and optimizes the BSP accordingly. Can be omitted oftentimes when you just want to have a look at your map, but for releases, this is absolutely necessary. It's the difference between 1 FPS and 90 FPS. Among other things. And the third line (&quot;LIGHT&quot;) finally calculates the light maps, so everything looks and feels real - without this phase, everything would be at full brightness which totally destroys the mood. The fourth line starts the Tremulous client with your freshly compiled map. Very convenient.<br /> <br /> '''After downloading q3map2build, you have to configure it:''' Start it. Go to &quot;directory options&quot;. Set &quot;game executable location&quot; to your tremulous.exe. Set &quot;q3map2.exe location&quot; to the file &quot;q3map2.exe&quot; located somewhere in the NetRadiant folder. Click &quot;save&quot;. Open the &quot;game options&quot; window, check the &quot;base mod dir&quot; box and type &quot;base&quot; into the text box. Click &quot;save&quot;. That was the basic setup of the program.<br /> <br /> '''While we're at it:''' In the little &quot;'''BSP'''&quot; area, select &quot;custom&quot; and click &quot;options&quot;. Activate &quot;custinfoparms&quot;, &quot;info&quot;, &quot;meta&quot; and &quot;patchmeta&quot;. Click &quot;save&quot;.<br /> <br /> In the little &quot;'''VIS'''&quot; area, select &quot;custom&quot; and click &quot;options&quot;. Activate &quot;saveprt&quot; (This makes sure that the portal file generated in the compile process is ''not'' deleted after the compile is completed, though it will be deleted and recreated on next compile. The portal file can be loaded into NetRadiant. You can then see in 2D and 3D the VIS areas that were compiled. Sometimes, you need this to help the software a bit. Keyword &quot;hint brushes&quot;.) and click &quot;save&quot;.<br /> <br /> In the little &quot;'''LIGHT'''&quot; area, select &quot;custom&quot; and click &quot;options&quot;. Activate &quot;bouncegrid&quot; (If you calc radiosity bounces, this option will make sure that the lightgrid (Whatever that is. I believe that it's a 3D grid of light. If you walk somewhere with your gun, it will receive e.g. red light. The light grid is where this is coming from, I believe.) is recalculated on every bounce, incorporating the light that was created by the bounces.), &quot;custinfoparms&quot; (which is necessary, I think, for shader parameters like &quot;nobuild&quot;, otherwise they might not get transported into the bsp, I believe), &quot;filter&quot; (softens the lightmaps so that shadow seams are soft, not pixelled), &quot;patchshadows&quot; (necessary for your pipes and models to cast shadows), &quot;bounce&quot;, &quot;bouncescale&quot;. Enter a &quot;500&quot; in bounce and a &quot;2&quot; in bouncescale. Remember these two options because you will later come back and deactivate them both, instead you will then (Later, as I said.) activate &quot;fast&quot;.<br /> <br /> Before you click &quot;save&quot;, let me explain what's going on here: These options define how the lightmaps will be rendered. The option &quot;fast&quot; really really increases the speed of the calculations, and you will use it most of the time because it even doesn't change the lighting drastically. But your first map tests will be of so little complexity that the rendering will be fast anyway.<br /> <br /> The &quot;bounce&quot; option is for radiosity bounces. So, your surfaces will not just have the light that is cast on them by the light sources. Instead, as in physical reality, your surfaces will also have the light that is reflected by the other surfaces. This is, of course, a question of iterations, because once a surface has received light from another surface, guess what: The next time, the light that comes from the surfaces is different. Realistically, 2 or 3 passes do the trick of giving the right impression. 500 passes will never be reached, all light will be used up at pass 5 or 7 maybe, the program will then stop calculating this. You should definitely use radiosity bounces in the maps you publish (if you have the time to calculate them), because they give a much more natural lighting feeling. For example: Colored surfaces will reflect colored light. You get the picture. Just turn this on for now so that you immediatelly collect data in your mind. The parameter &quot;bouncescale&quot; defines the amplification of the bounced light. Theoretically, this should be set to 1 (and hence just be disabled), but I have made good experiences with amplifying the bounces a bit. This causes more radiosity bounces, of course, because the light will not be used up so quickly. It can even happen that the light will not be used up at all. Hey. This is a crash course, not a &quot;click here and you're done, but you stay uninformed&quot; course. There's more information about these settings further down in this article ([[#_lightmapscale.2C_gridsize.2C_turbo_rendering|lightmapscale/gridsize/turbo_rendering]]).<br /> <br /> You might wonder why I don't just use the &quot;build&quot; features in NetRadiant. Because I want to be in control, and I want to be flexible. This crash course will, for example, deal with &quot;amplified radiosity bounces&quot;, the lightmapscale and somesuch. If I had used the build features as presented, I'd still only work with non-amplified bounces, I wouldn't have dealt with the gridsize or the lightmapscale, I wouldn't have used the &quot;filter&quot; feature. Maybe there's still stuff to discover, but I won't discover it if I use the preconfigured built-in buttons. You don't have to go that way, but I won't spare you the ugly details.<br /> <br /> '''So, until now you have installed the Tremulous client, the NetRadiant map editor, the NetRadiant support files, you have configured NetRadiant a bit, you have hopefully gotten your hands on a good q3map2 frontend, and you have created those folders. That's it, now let's go mapping.'''<br /> <br /> ==NetRadiant crash course==<br /> <br /> In Netradiant, move the mouse to the white area with all the confusing lines. Click and hold the left mouse button. Drag the mouse a bit. Release the left mouse button. You just made a floor. Or a ceiling. '''That thing you just made is called a [[brush]].''' This can only be done in the 2D view. Brushes are the building blocks used to make the map world. They can be changed into different shapes and also be drawn directly in different shapes, but most of the time, you'll draw simple box brushes. If you have done everything in the setup section, the box you have just drawn should have a number pair at its left top (position), a number on the right side and a number on the bottom (dimensions). The unit system used is called &quot;world units&quot;. Rule of thumb (that I heard - can't say that I have really verified it) is: 32 world units = 1 meter. There should also be red lines from all four directions leading to the box brush you made. Click and hold the right mouse button. Move the mouse a bit. Release the button. You have just dragged the whole 2D world. Scroll the mouse wheel to zoom. '''You can now navigate the 2D view.'''<br /> <br /> By the way: When you draw a brush, you obviously control its dimensions in both directions, but what about the third? NetRadiant will make the brush as thick as the gridsize is set - unless your work area (the one we made visible via menu &quot;view&quot;, submenu &quot;show&quot;) says different. So, the last thing you had selected (even if it is now deselected) decides how thick your brush will be. You can of course change the size of a brush afterwards, but now that you know this, you'll some day begin to take this effect into account.<br /> <br /> On the right side, you should see a big gray empty space. That's the 3D view. This one is a bit tricky. I hope you have deactivated the far clip plane in the preferences (&quot;camera&quot;) as I've said. Otherwise, the next steps might take you too far away from the box you just drew, and so you would not get to see it. Right click in the 3D view, and release the mouse button. The mouse cursor should have vanished. When you do that again, the mouse pointer returns to normal. With the mouse pointer locked into the 3D view, press the downwards arrow on your keyboard for about one second. After that, move the mouse around in all directions. If you have done everything as I said, you will find an ugly pink box. Congratulations! You've just discovered the world of the mapper: Ugly pink boxes. Much of the mapping process will take place in your head, not in front of your eyes. Experiment with the arrow keys, the mouse movements, the CTRL and SHIFT key, and the mouse wheel in the 3D view. '''You can now navigate the 3D view.'''<br /> <br /> Time for a few keyboard shortcuts:<br /> <br /> Press the ESC key. The box should now look different in the 3D and 2D view because it is no longer selected. In later situations, you'll have to press the ESC key several times in a row to '''deselect stuff''' because some selection modes go deeper into the structure, and every ESC press takes you a step back until everything is harmlessly unselected. And then it looks like it does now.<br /> <br /> To '''select the box''' again, click on it in the 3D view while holding SHIFT. Most of the time, you will select stuff in the 3D view because it's a pain in the ass to do so in the 2D view. NetRadiant still needs much work. Why they didn't include a box selection mode that only selects stuff that completely fits into the box is beyond me. Don't they use their own software?<br /> <br /> Now that the box is selected again, press the BACKSPACE key. You know, the big leftward arrow above the return key. Whoops, '''box deleted'''. Select &quot;'''undo'''&quot; from the &quot;edit&quot; menu or press CTRL+z to get it back again.<br /> <br /> We will now apply a texture to one of the sides of the box. Well, it already has a texture - the name is '''&quot;Caulk&quot;, that's the most important texture of all''', really. You should have this texture applied to every surface that the player cannot see. So, it's best to start with all-Caulk'd surfaces, and whenever you're working on stuff, keep in mind that every unused surface should be returned to Caulk. This is not a ''must''. But you'll bite your own ass one day if you want to squeeze all possible FPS out of your map, so you'll want to Caulk everything, but didn't take care all the time to prevent unnecessary textures. I've been there.<br /> <br /> Press ESC to deselect the box. Now click on it in 3D, but this time, hold SHIFT and CTRL. '''You just selected a surface.''' The texture browser is right under the 3D view. Doubleclick on &quot;arachnid2&quot;, wait till all textures are loaded, then click on the first texture that you can see: &quot;001metal&quot;. Yay, '''you painted the surface'''. The texture in the texture browser does have a red border now. This means that this is the current texture. Without changing the preferences to &quot;new brushes have Caulk&quot;, every new brush you make would have the red bordered texture. But believe me that you'll later find out yourself that you don't want to go that way. Next to the big texture with the red border, there is &quot;arach_fog_s&quot;, a '''texture with a white border'''. Textures with white borders are [[shader]] textures. Shader textures are not just images, they can even have functions, for example they decide whether a brush textured with them is made of water that you can swim in - or slime/lava that kills you.<br /> <br /> Remember the folders you made in the &quot;base&quot; folder? The pictures you see in the texture browser are stored in the folder &quot;textures&quot; or in one of its many virtual versions - I am speaking of the texture folders in all those .pk3 files. They are treated as if they were really existing folders/files. Which means that it's easy to have a file with the same path and file name existing several times, something impossible in the normal file system (may I remind you that I speak from the Windows perspective). '''You should read the [[.pk3]] article''' because it contains important information on how to deal with this. It's really tricky, and you don't want to go through the process of finding out the hard way. Things that can happen if you fail here: Your map can cause other maps to malfunction. Or your map will be incompatible with older versions of itself. Or it will not function the way it did on your computer. By the way - if you wonder where the textures of all those maps you might have downloaded and played until now are: On my machine (Windows), I have ''several'' &quot;base&quot; folders. One is somewhere in the system user area. If you want to use the textures of those maps, too, move them into the &quot;base&quot; folder where the program is installed. And no, you don't have to unpack the .pk3 files to use their contents in NetRadiant. But if you're a mapping beginner, you shouldn't have other files in your installation &quot;base&quot; folder than the ones that actually came with the Tremulous installation (and the Radiant Tremulous support file). Reason: Later, you'll make a .pk3 release pack, and you have to put all files into it that people will not have from the default installation, so have fun figuring those out when your &quot;base&quot; folder is polluted and you're a beginner.<br /> <br /> In the beginning, you will probably use the textures/shaders/sounds etc. that are part of the original Tremulous 1.1.0 pack. '''You don't have to deliver Tremulous 1.1.0 standard files with your map''' because you can assume that everyone has those. I don't know about the Tremulous 1.2 world that is about to emerge, though. But until now, it's the right way to go, and many people have done so. It's accepted. It keeps your map file small. And it means less file- and folder-hassle for you.<br /> <br /> '''Let's save the map.''' NetRadiant doesn't know a name yet, so it will show you a box where you can enter a name. The folder (&quot;maps&quot;) should already be set. Or did you forget to make the folder? You can leave the name &quot;unnamed&quot;, I mean, why call it &quot;terror castle zero&quot; when you don't even know how to make one. From now on, you can just press CTRL+s to save the map. And from time to time, go to the folder window (outside NetRadiant) and '''make a backup of the map file''' (e.g. by copying and pasting it into the same place). Too much garbage in the folder? Learn to live with it. You don't want to live with lost data. '''Maps can get broken in weird ways.''' If you know how to debug them, good. Otherwise, go to an older version and start over. Example: Maybe you know that a map file is just a human readable text that you can open in any text editor. If you open a more complex map, you'll see that it only consists of [[entity|entities]] which in turn sometimes have parameters and/or brushes. Now, one of the bad things that can happen (because NetRadiant is really just a rudimentary editor that allows to make maps but which is really far from being a reliable pro tool) is that an entity that needs brushes (as for example a door - the brush(es) are the moving door) loses all of them. Such a map would not run in Tremulous. To fix such a situation, you would have to use a text editor, locate the erroneous entity and fix or delete it (which is not hard but also not for beginners). Or you'd go back to a previous map version. And no matter how experienced you'll be one day, there will sometimes be problems that you cannot fix. For example: I had a map once with one telenode. The Tremulous client, though, behaved as if there were two. But there was only one. That's easy to verify because the node can be searched for in the text file. I even searched in the compiled map: Only one telenode. Well, the system is not free from bugs, and this is what can happen. Because I was already so far into the map, I had to test-delete many brushes, compile, run - still one telenode too many. Again. And so forth. After a day, the problem was fixed even though the elements that I finally found out to delete and remake didn't have anything to do with the telenode and also didn't seem broken. Also, the telenode problem was absent in some of my delete runs - even though it was different stuff that I had deleted.<br /> <br /> Another word on backups: If you're not a total computer noob, you use archiving software from time to time. But &quot;ZIP&quot; is not the archive format of choice (except of course to make .pk3 files, those have to be ZIP, but you can create that with other archivers, too). [http://www.win-rar.com/downloadnow.html RAR] is very good (but not free, so there's a nag screen or you have to pay). But the best one currently (even though it doesn't support recovery records - haven't really needed those till today, anyway) is [http://www.7-zip.org/ 7z], and it's free. There are also versions for Linux etc. (search yourself). So, why do I mention all this? Well, if you have a bunch of backup copies of your map file (which will eventually outgrow the 1 mb limit, can even reach 20 mb), you'll quickly have tons of &quot;wasted&quot; space. But don't delete the backups if you're not absolutely perfectly sure that you won't need them any more! Just compress them. They compress very well, to about a 10th of their size. And if you use a ''modern'' archiver instead of ZIP when compressing like 20 backups into one archive, the archiver will not just squeeze down every map backup individually, but it will take into account that most parts of the files are equal. That's called a &quot;solid archive&quot;. Unpacking stuff out of them is a bit annoying because oftentimes, the whole archive has to be calculated through for one file. But who cares. So: Just pack all your backups into one archive from time to time. Instead of 100 mb &quot;wasted&quot; space, you'll only have like 1 mb! And you will have all backups of your map! I do it like this for every map individually: &quot;backups till 2010-06-29.7z&quot; and so forth. Makes you sleep better.<br /> <br /> The last word on backups: It's not enough to just backup the map onto the same machine. That is only for the work process in case something gets broken or you need to copy an object from an earlier version that doesn't exist in the current one. No, you also need to backup your files from your PC to another medium. That doesn't really belong into this article because every serious computer user should do that from time to time anyway. But I'd like to mention that here. What I do (apart from backing up my whole machine onto extra harddisks that I then put away somewhere from time to time): I have all mapping relevant files in the Tremulous install folder. And so, I just make a 7z archive of the whole folder tree once a week or so, and I copy it onto a USB stick. I don't know how reliable those are, but my experiences have been good so far. You'll sleep better if you know that the hundreds of mapping hours are safe somewhere.<br /> <br /> Let's go back to our brush. Press ESC to deselect the surface. Then SHIFT and left-click the brush to '''select it in the 2D view'''. Yes, in the 2D view. You can also hold SHIFT and the left mouse button, drag a box that touches the brush you made, and release both. That's the '''box selection'''. Another thing you can do (but you can't really test now because you only have one element in your map) is to SHIFT and left-click in the 2D view and also hold the ALT key. This selects one of the things that are in the position that you click at, just as the normal SHIFT and left-click does. But if you do this several times, the first selection is deselected, and something else in the same place is selected instead. Very useful function to '''toggle through all the stuff in that place.''' Less useful is the fact that it is buggy - sometimes, you have to move the mouse a bit to make the program allow you to use this function again. Box-selection (SHIFT and left-click, drag, release) is also possible in the 3D view (also the SHIFT-ALT-click toggle-through-stuff function), and only the elements currently in view will be selected - so you'll probably enable far-clip-plane from time to time (preferences, &quot;camera&quot;), adjust its distance (menu &quot;view&quot;, submenu &quot;camera&quot;), enabling you to easily select a group of objects (for example a truckload of lights that you used to slightly paint the light situation without people noticing) in front of you while the things behind them are too far away to be visible or get selected.<br /> <br /> If you have a look at the menu &quot;view&quot;, submenu &quot;filter&quot;, you see that you can '''filter''' the 2D and 3D view for the many different kinds of things and thing-groups that a map can consist of. This will be very useful for selecting. And for not getting distracted/confused. Also, displaying the graphics in the editor is faster if less stuff is being drawn, obviously. If you see anything in the filter list activated right now, select the lowest point &quot;reset filters&quot; which will turn everything off - so that you can see everything that exists in the 2D and 3D view. Another way of '''making stuff temporarily invisible''' is the '''hide function'''. Make sure your brush is selected. Then press the &quot;h&quot; key. Bang, it's gone. You can hide all kinds of elements. If you want everything to be visible again, press SHIFT &quot;h&quot;. Filters and hide have no influence on the map functionality, they are not even stored in the map file. When you close NetRadiant and open it again, the previous filter settings are still active which can be confusing at times. The hidden stuff, though, is visible again. By the way: Did you notice the - - - - - line at the top of the menu? If you click that, the menu will be opened in a window that does not go away when you select something in it. Very useful.<br /> <br /> Another very important function that can be toggled on and off is the &quot;'''texture lock'''&quot; function. There is a button with a lock picture for that somewhere at the top right of the screen. When it's active, it should actually blink and play a loud HONK!-sound all the time or something. And when NetRadiant is closed and opened again, it should be deactivated. But all of this does not happen. So, '''you have to take care whether or not the texture lock function is activated'''. Here is what it does: When it's not on, the textures on a brush seem to scroll around when you move the brush around. That is because the textures are normally locked to the world position. This is very practical, as you will find out with time. Now, the &quot;texture lock&quot; function changes that: When you drag a brush while that function is activated, the textures of the brush will move with it. That is very useful in cases where you have made a brush or several brushes with specific texture work (for example light fixtures), and you want to move those brushes without the design to change. Be aware whether or not the function is activated. You will remember this text here for sure. Because you will at some point see textures in wrong positions, realizing: &quot;Damn, I moved brushes around with texture lock on! Why isn't that function automatically turned off when I start the program?&quot; The texture lock function also changes the behavior of textures when you use the rotate-brush-by-90-degrees function.<br /> <br /> Remember when I called your brush a floor or ceiling? That's because the 2D view shows a view from the top (or bottom, depends on how you think) on the map when the program opens. Press CTRL and TAB. If nothing weird is going on with your input focus and keyboard (which can happen from time to time), the '''2D view was just switched from &quot;top view&quot; to &quot;side view 1&quot;'''. Do that again, and it changes to &quot;side view 2&quot;. Once again, and you're back at &quot;top view&quot;. You can determine what view you're currently on by looking at the little right angle labeled &quot;z&quot; and &quot;y&quot; or &quot;x&quot; and &quot;y&quot;, you get the picture. You'll probably determine that later by rather looking at the map, though. It's helpful/important to learn that the vertical axis is the Z axis. If you can currently see the X and Y axis, you're looking along the Z-axis (meaning: from the top).<br /> <br /> Now, let's finally get to '''how to move and scale a brush:''' Make sure the brush is selected. In the 2D or 3D view, click on the brush, hold the button, move the mouse, release the button. You just moved the brush (if the grid versus the amount of mouse movement didn't prevent this). Moving it in the 2D view makes sure that it is not moved along the axis that is pointing directly towards you. Moving it in the 3D view is comfortable, but can have unwanted results because of the fact that the camera is &quot;never&quot; perfectly aligned with the three space axes. To scale the brush instead of moving it, do the same, but don't click inside of it. Instead, click beside it. Important: Don't scale it too small so that it vanished. I have no idea what happens then. I always hit &quot;undo&quot; in such a situation. Might be a map-breaker.<br /> <br /> '''The grid''' is very important. In most cases, brushes should be perfectly aligned with grid points. Otherwise, have fun debugging your map. To '''change the grid scale''', press one of the number keys from 1 to 9. You can also do that in the grid menu. You'll do that from time to time, because, believe it or not, the grid spacings below 1 are actually used sometimes. The current grid spacing can be seen at the bottom of the NetRadiant window, on the right side. Careful with the key &quot;0&quot;: It toggles the grid from visible to invisible (and back). On a side note: I hope that the NetRadiant developers will be nice and implement a feature that draws the grid with thicker lines (e.g. 3 instead of 1 pixel) because it's simply invisible with all the stuff in front of it on more complex maps, and that sucks considerably.<br /> <br /> '''A word about world units / grid size / reactor and overmind etc.:''' It will take a while until you have memorized all the building and player sizes. Until then, just memorize this: An opening or room with the size '''128x128x128''' (second largest grid setting (&quot;8&quot;)) is just high and certainly wide enough to contain the overmind or reactor (112 would be enough). Tyrants etc. fit through nicely (96 would be enough). Those numbers might not really tell you anything, but any long-time computer user knows the drill: 1 2 4 8 16 32 64 128 256 512 1024 2048 4096 8192 16384 32768 65536 ... You should know those numbers up to 256 to be more efficient with NetRadiant. And 96 is three elements of the size 32, '''96 is just high enough for a tyrant''' to get through. '''64x64x64''' is big enough for a dragoon. A human can still crawl through a height of 32, if I am not mistaken. '''If you want to make a stair, 16 is a nice step height.''' Though 16 might seem a bit big on closer inspection since it's theoretically half a meter.<br /> <br /> Make sure that your brush is selected. Then, press CTRL and C, then CTRL and V, or use the &quot;edit&quot; menu. The '''brush exists now twice in the same place''', a common error that can cause weird map behavior, yet a situation that you will intentionally create many many times, because it's often useful to take an existing brush and copy/paste it somewhere else. At this point I should remind you: Keep everything Caulk'd that cannot be seen by the player. Ok, now press ESC. Yes, keep the two brushes in the one place for now.<br /> <br /> Travel to the side of the brush that shows the &quot;001metal&quot; surface. Select it (SHIFT CTRL left-click). Now go to another texture section. Not &quot;arachnid2&quot; but instead &quot;common&quot;. Most of the '''textures in the &quot;common&quot; group''' are actually shaders, as you know already because you saw the white borders around them. The one called &quot;caulk&quot; is among the first. It should have a green border because the currently open map uses it in at least one place. Click on &quot;caulk&quot;. This applies the caulk shader to the surface you selected. It also gets the red border because it's now the current texture, which is unimportant to us because all our new brushes have caulk, not the current texture. The &quot;common&quot; textures are really useful. There is, for example, a shader called &quot;ladder&quot;. Any vertical surface that you apply this texture to can be climbed. It's really that simple. Well, to make an actual ladder, build something that looks like it can be climbed, then make a brush with the ladder shader around / in front of it. The ladder shader is invisible, but you can't walk though it. There is also a texture called &quot;clip&quot; which you'd sometimes use to invisibly even out too odd wall and floor situations. The dretches will thank you. The players who don't get stuck while running away from the beasts will thank you, too. Some of the textures/shaders of the &quot;common&quot; section can be used without you having to distribute these shaders with your map (like for example the &quot;caulk&quot;, &quot;ladder&quot; and &quot;clip&quot; shaders), but it's best to just add these few bytes to your map file. Better safe than sorry. Ironically, the &quot;invisible&quot; shader, for example, would cause '''&quot;missing texture&quot; optics''' (Missing textures in the game are gray with a big white grid. Hard to miss. Easy to miss, though, if your testing environment is improper, because then you'll not have missing textures, but the players will.) if the Radiant Tremulous support files are not present, so put them into the release file. A .pk3 without those shaders will of course work on your machine - because you have the &quot;data-radiant-1.1.0.pk3&quot; in your &quot;base&quot; folder! Others do not have this.<br /> <br /> '''Get to know the phenomenon called [[Z-fight]] (or Z-fighting):''' Press ESC to deselect. Now, select &quot;the&quot; brush (doesn't matter which one, but just one of them, Wassily), so SHIFT left-click on it. Now for the important part: Move the brush a bit. Not too much. You'll see that the copy (or the original, you never know which one you'll click if there are several in one place) is revealed by you moving the other one. Don't move it too far - they should still overlap. Now, study the area in which the textured face of the one brush and the Caulk'd face of the other brush are drawn in the same place. Move the camera around a bit. If you've done everything right, then you are just observing a Z-fight. Two surfaces want to have the same distance from the observer and fight about it. No one wins, especially not the spectator/player. For historical reasons, the distance an object has from the camera is called the z-distance. You could also read up on the term &quot;[[Z-buffer]]&quot;.<br /> <br /> It is very probable that you will get to see Z-fighting somewhere during one of your many testruns of your maps. You can even find those in finished maps that can be found on many servers. I can remember at least one z-fight in a professional map that came with Tremulous 1.1.0 ([[Nexus6]]). Ironically, right now, there is nothing wrong about your map in that regard. Because one of the two surfaces that are fighting has the Caulk shader - which is defined to be invisible. There would be no z-fighting in your map right now.<br /> <br /> '''Mirroring and rotating:''' Select one of the brushes and toy around with the 6 buttons at the top left of the NetRadiant window. The first one is &quot;x|x&quot; and mirrors the brush along the x axis. I find it irritating that the Radiant developers chose to mirror the brush ''along'' the x axis instead of using the x axis as the, well, mirror axis, but you'll get used to that. The button next to that is the rotate-around-x-axis button, and that actually works like you'd expect it. Depending on the grid-versus-brush situation, the position of the brush gets changed accordingly, too, so later, you'll adjust the grid spacing before rotating a brush around 90 degrees. Mirroring does not care about the grid, just about where the brush begins/ends. If the &quot;texture lock&quot; is active, the textures get rotated and mirrored accordingly. Nice one. But if you rotate a brush using &quot;arbitrary rotation&quot; (menu &quot;modify&quot;), the textures will not be rotated with it, no matter if the &quot;texture lock&quot; was active or not. &quot;arbitrary scale&quot; (same menu), though, scales the textures (if &quot;texture lock&quot; is on).<br /> <br /> Left of the &quot;texture lock&quot; button, there is another (currently selected) button with a rectangle inside of it. If you hover your mouse above it, it'll say &quot;Resize (Q)&quot;. That's your normal brush draw/move/resize tool. Two buttons to the left, there is the &quot;Rotate (R)&quot; tool. Select it and rotate your brush a bit. This is the same as &quot;arbitrary rotation&quot;, only it's handled with the mouse instead of numbers. Don't forget to switch back to &quot;Resize&quot;.<br /> <br /> Now a quick tour of '''dealing with entities''': In the &quot;view&quot; menu, select &quot;entity inspector&quot; (or press &quot;n&quot;). There are several sections in that new window that appeared, and you might have to vertically scale those sections a bit before use. The most important area in that window is the one saying &quot;classname worldspawn&quot;. If there is no such text visible, you probably don't have a brush selected at the moment. Select one (or several, doesn't matter now). If there's still no text &quot;classname worldspawn&quot; in the window, you have to scale and move stuff in the window around a bit. The &quot;most important area&quot; with said text is not the lowest part of the window, but it's the lowest big white box in the entity inspector. Once you've found it, click on the text &quot;classname worldspawn&quot;. You'll see that, once you've selected it, the text &quot;classname&quot; appears below the area in a textbox labeled &quot;key&quot;, &quot;worldspawn&quot; in the &quot;value&quot; box. The '''key-value-principle''' is very important. The area in which you selected the key-value-pair will later have more key-value-pairs. These are the properties of the entity that you've currently selected. Wait, a brush is an entity? Well, if you deselect the brushes with ESC, &quot;classname worldspawn&quot; is no longer visible in the entity inspector window (only as a relict in the &quot;key&quot; and &quot;value&quot; input text boxes). So, every brush is an entity with the text &quot;classname&quot; in it? No. All brushes are one combined entity. The entity's name (And it's better to think of this as a type, not as a name. Later, you will have several entities with &quot;classname&quot; &quot;light&quot;, so it's obviously not just a name but really a type.) is &quot;[[worldspawn]]&quot;, a term mappers toss around oftentimes. Every map has min. and max. one worldspawn. It's the first entity in the .map file (if you look at it with a simple text editor.) The worldspawn can have very important settings regarding the map, for example the amount of buildpoints the teams have, or you can add a little message that is displayed while the map loads. The text area above the &quot;most important area&quot; describes which keys and values can be used for the world spawn. Once you select a different type of entity in the 2D or 3D view (or in the area at the top of the entity inspector, where all possible entity types are listed), the help text changes.<br /> <br /> When dealing with the entity inspector, be careful what you have selected in the map. It's possible to select a brush (usually part of the one &quot;worldspawn&quot; entity) and another entity type, for example a &quot;light&quot;. This flexibility can be useful, but if used improperly, it's a big source for errors. '''Always be aware of what's selected before using any function.'''<br /> <br /> Now, let's use an entity we haven't used before: Select one (or all) of the brushes. Then, right-click in the 2D view. A menu should appear. If it didn't, try again without moving the mouse even the slightest bit. In the menu, go to the item &quot;info&quot;, and from the new submenu, select &quot;info_player_intermission&quot;. This creates a little box of that entity type. Also, the brush(es) that were selected have gone, replaced by the new entity. You better undo that and remember this effect for later, because if you're dealing with a somehow broken map later, it might have been caused by the action that was just demonstrated. But everything should be fine if you use &quot;undo&quot; on such an action. Ok, now press ESC to deselect everything, and then create the entity anew. What is it good for? Well, it defines the position and orientation of the spectator camera when you enter a map or leave a team. '''The &quot;info_player_intermission&quot; entity is absolutely essential. Without it, a map does not work in Tremulous!''' The &quot;info_alien_intermission&quot; and &quot;info_human_intermission&quot; entities have a similar function (camera position and orientation when you're on a team and are currently not alive), but they are not technically necessary. You'll of course place them when you're making a real map.<br /> <br /> You can use the &quot;arbitrary rotation&quot; or the mouse rotate tool to change the direction into which the player_intermission camera is facing.<br /> <br /> Man, I almost forgot THE LOG. Move the mouse to the bottom of the window directly above the status line (that's the area with several texts and horizontal segments). There should be a handle looking like ............ Click and drag it up. You should now see the log. Sadly, you'll have to do that again next time the program is opened. The log shows the actions the program performs (and errors that happened). Have an eye on the log when you map, it'll save you a few map-repair-sessions because you'll see that something you wanted to do didn't work out, or something was done that you didn't expect and so forth.<br /> <br /> There are more NetRadiant explanations in the other sections of this mapping crash course.<br /> <br /> ==making your first (ultra basic) map==<br /> <br /> ===create the map===<br /> <br /> Now that you know how to handle the most important functions of NetRadiant, let's make a map, violating all rules, offending all experienced mappers. In the &quot;file&quot; menu, select &quot;new map&quot;. If a window appears asking you if you want to save the current map, you're doing it wrong because you should have saved the map already a few times with at least one or two backups. Ok, it's a worthless map that you wouldn't really save or backup often, but I want to give you an idea of how to deal with a real map.<br /> <br /> Press CTRL and TAB until the 2D view shows the X and Y axes, so you're '''looking from the top. Press the key &quot;9&quot; to have the largest grid spacing.''' If the grid is invisible, press &quot;0&quot;. If that doesn't make the grid visible, then it probably was not invisible before but just too big for your current zoom (use mouse wheel and maybe &quot;0&quot;). Read on once the grid is visible and also on its largest setting (displaying &quot;G:256&quot; at the bottom of the window).<br /> <br /> '''Create a brush in the 2D view, exactly one grid block in size.''' The numbers on its right and bottom size read &quot;256&quot; if you've done it right. Assuming that 32 world units are one meter, this brush is a nice 8 by 8 meters floor. Which is also 8 meters thick, by the way. But who cares. It's not like we're wasting concrete or something.<br /> <br /> The brush is pink, yes? Otherwise, shame on you. Now, move the camera in the 3D view so that you can see the top of the brush. Select the top face (CTRL SHIFT left-click, don't just SHIFT left-click it or you'll select the whole thing). Go to the &quot;arachnid2&quot; texture section and click the first texture (&quot;001metal&quot;). '''The top surface now has this texture.'''<br /> <br /> Press ESC to deselect everything. Then right click in the 2D view, and select &quot;team_human_spawn&quot; from it. Press ESC again, call the menu again, and select &quot;team_alien_spawn&quot;. Press ESC again, call the menu again, and select &quot;team_player_intermission&quot;. Great! '''Now you have all the three essential elements''' that you need to have a working Tremulous map. But there is a problem: '''If the spawns are not in a proper place''', they might not get created when the map loads. So, move the egg and the node around until they stand somewhere on the box. Make sure that there is enough distance between the two. Also, have a look at them from the side: They must not be too close to the surface of the box or they will not get created when the map loads. You can really place them quite high (Be reasonable.) above the surface. When the map loads, they will be created in that spot and then fall down to the surface (without taking damage). To move the entities around, you have to set the grid to a higher resolution. Just blindly hit one of the left digit keys for a high resolution, which one doesn't matter at the moment. By the way: Too many people ''in the game'' fail to place the spawns in the right rotation. It's easy: The player will spawn to face the position from which you made the spawn. Makes sense: That position can be assumed to be a valid place to go. Making spawns in the right rotation can influence the game flow positively.<br /> <br /> Please check if the surface on which you are trying to put the spawns is the one you have textured. If not, then you did something wrong earlier when texturing it. Spawns cannot be rotated in the editor in the way that they can be put on walls or something, so it's not the spawns that are wrong. By the way, you can '''rotate the spawns''' around the high axis (Z) to define the direction into which the player will look when he spawns. The human spawn, at least the one in the editor, has the aparatus-thingy on the side into which you will spawn. The egg spawns you into the direction the red axis at the egg's center points. The human spawn does so, too, but the aparatus-thingy is easier to see.<br /> <br /> Ok, we have a floor with a texture, both teams have a spawn, and the player_intermission camera does also exist (maybe you want to move and rotate it around a bit until it will probably show something meaningful, but it's not necessary for the map to run).<br /> <br /> What's missing? Light! ESC, 2D, rightclick, '''select &quot;light&quot;'''. A text box appears. Make sure that the number inside of it is &quot;100&quot;. That's the brightness of the light. Click ok or press RETURN. Pressing RETURN is not always advised: The &quot;arbitrary rotation&quot; dialog, for example, will not do anything then. Now move the point light you created until it is in the middle above the box brush. For that, press &quot;8&quot; to set the grid to the second largest spacing. Now it's easy to move the light to the middle. Seen from the top, it must be in the middle. Seen from the side, it must be one grid step above the floor. With setting &quot;8&quot;, that's 128 world units - 4 meters.<br /> <br /> ===build the BSP file and run it===<br /> <br /> If you have not yet saved the map, shame on you. Also, do it now. The name should be &quot;unnamed&quot;. Then, close NetRadiant. '''Because now we'll play the map!'''<br /> <br /> If you're a lucky Windows user, you'll have downloaded and configured q3map2build, I hope. Start that program, select the map &quot;base\maps\unnamed.map&quot; that you've just created, make sure that &quot;Play after build&quot; (left border of the window) is activated - and then click &quot;build&quot;!<br /> <br /> Alternatively, if you are not using this nice frontent for q3map2, you can create a batch file. The program does nothing different, only it's more comfy, and the texts displayed when you hover the mouse above the many switches certainly make things more clear. So, if you don't use the program, create a batch file. That's a normal text file with commands in it that has to be renamed to &quot;somethingsomething.bat&quot;. Sadly, those mega-idiots at Microsoft chose to hide file extensions (stuff like &quot;.bat&quot;) by default, so you can't rename the whole file name, only everything except the extension. For this reason and overall security improvement, Windows users are urged to turn the display of file extensions on. In any file explorer window, go to the &quot;Tools&quot; menu, select &quot;Folder Options&quot;. At the top of that new window, click on &quot;View&quot; and then scroll down until you see the option &quot;Hide extensions for known file types&quot;. Turn it off and click &quot;Ok&quot; at the bottom of the window.<br /> <br /> Here's the text for the batch file:<br /> <br /> &quot;C:\Program Files\netradiant-20100214-win32\q3map2.exe&quot; -fs_basepath &quot;C:\Program Files\Tremulous&quot; -fs_game &quot;base&quot; -custinfoparms -info -meta -patchmeta &quot;C:\Program Files\Tremulous\base\maps\unnamed.map&quot;<br /> &quot;C:\Program Files\netradiant-20100214-win32\q3map2.exe&quot; -fs_basepath &quot;C:\Program Files\Tremulous&quot; -fs_game &quot;base&quot; -vis -saveprt &quot;C:\Program Files\Tremulous\base\maps\unnamed.map&quot;<br /> &quot;C:\Program Files\netradiant-20100214-win32\q3map2.exe&quot; -fs_basepath &quot;C:\Program Files\Tremulous&quot; -fs_game &quot;base&quot; -light -bouncegrid -custinfoparms -filter -patchshadows -bounce 500 -bouncescale 2 &quot;C:\Program Files\Tremulous\base\maps\unnamed.map&quot;<br /> Pause<br /> &quot;C:\Program Files\Tremulous\tremulous.exe&quot; +set fs_basepath &quot;C:\Program Files\Tremulous&quot; +set fs_game base +devmap &quot;unnamed&quot;<br /> <br /> The line &quot;Pause&quot; is not necessary, though it can be useful to have the process wait between calculating and playing. q3map2build has options to insert &quot;pause&quot;, too. I once had the computer calculate a map for four days in a row, and I had &quot;Play after build&quot; unchecked because why should I &quot;burn&quot; my machine uselessly? This means that after calculating, the machine would just have closed the system's console text box without me being able to read the text. This makes the &quot;pause&quot; feature seem much less superfluous all of a sudden. Of course I could have saved the console output into files automatically (by adding &quot; &gt; outputtext1.txt&quot; to the end of the first line, and bla 2 3 4 to the other lines), but then again I wouldn't have been able to have a look at the console text because it would just have been in the files.<br /> <br /> You'll probably have to adapt the batch file text to suit your computer/setup.<br /> <br /> Doubleclick the batch file to start the compile.<br /> <br /> One of the things that will appear in the text window (which is the system's console text output) is &quot;LEAKED&quot;. Well, we didn't give the map a proper shell, we just made a floor. Doesn't matter at the moment, but later, we'll have to improve on that.<br /> <br /> Well. If everything went right, you're playing the smallest map in the world. And everything around your little world is pitch black. Or you see the [[hall of mirrors]] effect around you, really annoying. But it's a working Tremulous map!<br /> <br /> I bet you want to experiment now. Do that. But don't yet make a big map that kinda asks to be published, people are probably not going to like it. You have to learn some more first.<br /> <br /> <br /> <br /> <br /> <br /> ==making your second (more advanced) map==<br /> <br /> ===choose a name===<br /> <br /> You can freely create folders in the &quot;map&quot; folder, doesn't hurt the game system. So, you should make a folder and throw all files into it that have been created so far.<br /> <br /> Now, open NetRadiant (or select &quot;new map&quot; from the &quot;file&quot; menu if it was already open). Save this empty map. Reason: '''We want to give it a name.''' Press CTRL and S (or select &quot;save&quot; or &quot;save as&quot; from the file menu). The name shall be ... wait, what's your nick name? The name you use as a player or in the forums? If it were &quot;God, maker of the world&quot; (which is my nick name), we could make a short version of that, for example &quot;gmotw&quot;. Let's assume that your nick name is &quot;scrollbar5&quot;. A shorter version would be &quot;scr5&quot; or something. Let's stick to that. Back to naming the map: Please save it as &quot;scr5_dretchnest&quot;. If you actually have a nick name that you want to stick to and that can be nicely expressed with a few letters, use that from now on. I'll keep calling it &quot;scr5_...&quot;.<br /> <br /> You see where I'm heading. I called my first map [[Gmotw_Skybox|&quot;gmotw_skybox&quot;]], and this is not mainly about people attributing the map to my person (or so that all my maps would be in one alphabetical place in the huge map repositories that exist, hehehe) but instead so that I could freely choose my map names without having to worry about the name maybe already existing - or someone else taking the same name. I have not yet seen anyone do it like this, but I think this is actually the way it should be done by everyone, and so I tell my helpless scholar prey (Not really.) to do it just like that. '''Add a short version of your nick name with a &quot;_&quot; at the beginning of your map names.''' Keep it short, though. It's good if this prefix &quot;doesn't make sense&quot;, so it's not confused to be a part of the map's real name. So, &quot;gmotw_&quot; (Hey, that's mine.) is better than &quot;stellar_&quot;. By the way, if you look at the screenshot in the skybox article, you read the message &quot;Remove older versions of Skybox to prevent texture problems.&quot; which is really lame. You won't have problems like this since you can read my experiences and conclusions in this mapping guide. Comfy, no?<br /> <br /> If you use these prefixes, by the way, '''NetRadiant will nicely group all your map assets''' in the texture browser instead of spreading them all around the alphabetical map list.<br /> <br /> If you've read the [[.pk3]] article (which you should at some point), you'll already know about the '''filename uniqueness problem''' and about how to deal with it through several release versions of your map. We have halfway solved the uniqueness problem by choosing &quot;scr5_dretchnest&quot; (or whatever your prefix is), which is probably a name not yet taken. Except if 10 people go through with this mapping crash course without choosing a different prefix. But I wonder if anyone's gonna read it at all :/<br /> <br /> A word about &quot;alpha&quot;, &quot;beta&quot;, and &quot;final&quot; releases: BULLSHIT! That was actually just one word. No really: I think it's a meme or an &quot;I'm doing it just like the real guys! I feel like I'm taking a step into a larger world!&quot;-thing that people release their maps as alpha, beta, and final. Well, it has practical reasons, but it also has its problems. To make it short (meaning: I just deleted about 300 words of bla that I was about to save, and that was just the half of it.): Just give your releases a number. So, just add &quot;_001&quot; to the map name. Three digits seems to be much, but you never know. If you increase the release number every time you make a .pk3 and test it with friends or on the server of a guy you know, you'll quickly be above 9, and with all the stuff you have to keep in mind, you don't want to worry about the goddamn number. And once you have chosen to use the path of the &quot;_001&quot;... instead of the &quot;_a01&quot;... &quot;_b01&quot;... &quot;_final&quot;, you'll laugh at all the mappers who have decided to make their maps a &quot;final&quot; too early. &quot;Oh, something's still broken. Damn, already released as 'final'. Can't change it now.&quot; Weird people anyway. I mean, what makes you so sure that you will never add something to the map in a year or so? And then you have the other guys who are more careful. They make their alphas, then you find their betas in the wild... but there is never a &quot;final&quot;. Guess why. The last beta effectively ''is'' the final. Not changed after years. Assimilated by the community. No, you don't want to play that game. '''Just give your releases a number. Just a stupid counter suffix like &quot;_001&quot;.'''<br /> <br /> So, we're about to create a map. The &quot;next&quot; release of it will of course be the first, so its name is &quot;_001&quot;. (I should add that &quot;release&quot; in this context does not mean that you give it to the Mercenaries' Guild Map Repository and brag about it in the forums or something. I am just talking about a proper .pk3 file that you can test on servers.) When people callvote for it, they'd type:<br /> <br /> &quot;/callvote map scr5_dretchnest_001&quot;<br /> <br /> While we're at it: The .pk3 file of this (as can be read in the [[.pk3]] article) would be named<br /> <br /> &quot;map-scr5_dretchnest_001-1.1.0.pk3&quot;<br /> <br /> The name of the .pk3 file has nothing to do with the callvotes. But the name should be kept equal to the real map name for consistency reasons.<br /> <br /> If you're using the batch file solution, please '''edit the batch file just now''' to use &quot;scr5_dretchnest_001&quot; instead of &quot;unnamed&quot;. Reason: So that it hurts if you change the prefix or map name later. Get used to this. Of course, you can theoretically rename a map a hundred times before releasing it the first time, but we want to train here. If you decide to wait with the batch file editing, you're technically making the right choice in case you rename later, but you should experience the name lock, it'll help your mind to get into the real mapper world. Also, all following steps will make use of the map name and cement it some more, and '''you do not want the asset folders and the map to have different names. It's enough hassle as it is, and this would double the file naming work.'''<br /> <br /> By the way, how did I come to the name &quot;dretchnest&quot;? Ok, it's not rocket science, but you'd think that about most map names ''once they exist''. Obviously, I thought of Tremulous elements. What you can do to come up with a map name depends on whether you create it at the beginning, in the middle, or at the end of the mapping process. For example, when I came up with &quot;dretchnest&quot;, I had no idea what exactly the map should be like (other than something with 4 walls that you are supposed to clip diagonally in the corners). I only grabbed a name out of the clouds to complete this section. '''But now that I have a name, it gave me ideas about the map.''' Actually ideas that are ill placed in a beginner's mapping guide, so I'm probably not gonna put them into action here, but here they are: There would be a rectangular (Duh. Beginners always make box maps.) room with a few eggs. The room would be closed from all 6 sides, but there would be openings at the bottom, small enough for dretches to get out. Maybe there would have to be contraptions against crouching humans, maybe that would have to be done by basecamping dretches. If you spawn as granger, you can't get out, so maybe I would have added a trigger that checks if you're granger - and kills you. The ceiling of the room would be something that can be set in motion somehow with a button or by making a building or by reaching a certain spot or by reaching stage 3 etc., and this ceiling would squish the eggs in the room. Since there are no other eggs and grangers cannot get out, the aliens would have lost the game (if the aliens still alive don't win it). This is obviously not a standard Tremulous map, but I digg stuff like this (Trem has enough standard maps, lets bring something new to the table). Read the [[Gmotw_Skybox|skybox]] article if you don't know what I mean. That was my first map, by the way.<br /> <br /> &quot;dretchnest&quot; would have been a fitting name for the above described map. See? '''The name idea resulted in a map idea.''' I believe that it's usually the other way round. But it's improbable that the mapper does not decide for a name until the map is completed, because you'd need to test the map from time to time, and so you'd come up with a name to make a release file. (I repeat: The name you choose once you publish the map should never change, if you can somehow make it so.) Once the name is chosen, the name will probably feedback into the mapping process (e.g. you'd want it to be justified, the least you would do is add fitting decorations).<br /> <br /> '''How you can come up with a map name''': I speak english and german, so when I am thinking about the map that I already created a bit, I think of its prominent building and gameplay elements, enter those terms into a Web translator (like [http://dict.leo.org dict.leo.org]) in english or german, and then I play '''translation ping pong'''. You can also use a Web '''thesaurus''' for that. There are also '''map name generators''' on the Web, probably not Tremulous-specific. You'd rather want to use them for inspiration (and to fuel your translator and thesaurus attempts), not to really make the name for you.<br /> <br /> ===make a shader and a texture===<br /> <br /> Now, go to your Tremulous &quot;base&quot; folder. '''Create a new folder in the folder &quot;textures&quot;.''' Name: &quot;scr5_dretchnest&quot;. Why not &quot;scr5_dretchnest_001&quot;? Because then you'd have to re-assign all textures on every new release because the foldername changes. The project you're working on is &quot;scr5_dretchnest&quot;, and that's the name the asset folders should have. You can also make a folder like this in the &quot;sound&quot; folder, but I currently don't plan on talking about adding a sound. But this is the way it would work for sounds, too.<br /> <br /> If you want to add shaders (which we will do - it's easy if you know how), you have to add the release number again. Reason: The shaders are not several files stored in a new folder, like textures will be. No, the shaders of a map are little text blocks that are all stored in one text file. (You can also make several files, but let's keep this simple.) And '''if you change the contents of the shader file for a new release, you have to give that file a new name.''' Just as if you would have to give a texture a different name that you change from one release to the next. If you don't do this, your map will be incompatible with older versions of itself. You can be lucky with that. But lets do this properly. Use this knowledge. Imagine you had to gather this knowledge by experience which I had to... urgh!<br /> <br /> So, the texture folder is prepared. But '''lets make a shader first.''' Go to your Tremulous &quot;base&quot; folder into the folder &quot;scripts&quot;. Create a new text file called &quot;scr5_dretchnest_001.shader&quot;. If we add a shader into it, it will appear in NetRadiant the next time you start it. Well, you'd think so, but for some reason only the programmers know, you have to add an entry in the &quot;shaderlist.txt&quot; file in the same folder. At the end of that file, add &quot;scr5_dretchnest_001&quot; (without &quot;.shader&quot;), press return, save and close the file. Now open the &quot;scr5_dretchnest_001.shader&quot; file again and put the following text into it, save and close the file:<br /> <br /> textures/scr5_dretchnest/brightglass_001_s<br /> {<br /> qer_editorimage textures/scr5_dretchnest/brightglass_001.jpg<br /> qer_trans .5<br /> surfaceparm trans<br /> surfaceparm solid<br /> cull disable<br /> {<br /> map textures/scr5_dretchnest/brightglass_001.jpg<br /> tcgen environment<br /> blendfunc gl_one gl_one<br /> rgbGen identity<br /> }<br /> {<br /> map $lightmap<br /> blendFunc gl_dst_color gl_src_color<br /> rgbgen identity<br /> }<br /> }<br /> <br /> Close NetRadiant. Open it again and load the empty map file you created. If you look at the texture browser now, you'll see an entry called &quot;scr5&quot;. Now, how did that happen? Oh, the stupid nick name prefix idea! Yes, NetRadiant interprets names with a &quot;_&quot; in it differently. It creates categories. So, all your maps will be under the category &quot;scr5&quot; instead of being spread around like crazy.<br /> <br /> Unfold the category by clicking on the little triangle on its left side. &quot;scr5_dretchnest&quot; appears. It does so for two reasons: 1. You created a folder with that name in the textures folder. 2. You created a shader that in turn created the virtual (= not really existing) file &quot;textures/scr5_dretchnest/brightglass_001_s&quot;, so another reason why NetRadiant would think that the folder exists.<br /> <br /> The texture browser should now show an element called &quot;brightglass_001_s&quot;, something like a blue-black checkerboard, expressing that the image which was to be shown here can not be found. No wonder - we didn't make that one yet. And that's a bit tricky, because I don't intend to explain any graphics software to you now. '''You'll just ''somehow'' have to come up with a .jpg file that has power-of-2 dimensions''' (you know... 1 2 4 8 16 32 64 128 and so forth, computer numbers, as mentioned earlier in this article, though obviously, a texture with ''anything'' on it and the size of 32x32 or smaller hardly makes sense), I'd say 128x128 should be the choice here, that's enough for a simple reflection picture (which this one is). Textures don't have to be quare, by the way, but let's keep this one simple. Also, I think that a texture with an arbitrary size (not power-of-2) would work, too - but what &quot;would work&quot; is not the question. What surely will work in all Tremulous clients and with all graphics cards, that's the question.<br /> <br /> The jpg quality doesn't need to be maximum for a texture. &quot;high&quot; (60) or &quot;very high&quot; (80) (as they are called in Photoshop) is good enough. &quot;medium&quot; is too low in nearly all cases, I'd say. You know what would be nice? An actual screenshot you take yourself in Tremulous. Cropped and sized to 128x128 or bigger, util max. 2048x2048 for a normal texture and, I'd say, max. 512x512 for a reflection texture, but that's plenty. By the way: The bit depth per color channel must be 8, as most existing image files are. You can use 16 and even 32 bit in Photoshop etc., but not in the game. While we're at it: You can also use .tga pictures. If you know when to use gif/png versus jpg, then you know when to use tga versus jpg. Example: If you need a simple color texture (pure red, no other pixels), then .tga is the perfect choice. Tga supports an 8 bit alpha channel (save as 32 bit then, not 24 bit) and also a simple and lossless compression that can be used with Tremulous.<br /> <br /> So, assuming that you have somehow found a suitable .jpg file (.tga (even compressed) would also work, but I think you have to change the shader text then, though I believe that I have seen that the file extension named in the shader is irrelevant, but better safe than sorry), move / rename it to achieve this name: '''&quot;textures/scr5_dretchnest/brightglass_001.jpg&quot;'''.<br /> <br /> Again, close and open NetRadiant and feast your eyes on the new contents of the &quot;scr5_dretchnest&quot; texture browser category. Well, your image should be there now. Twice even. WTF? Well, one instance is from the actual file in the texture folder, and the other one is the shader you created. '''Now you see why the shader ends in &quot;_s&quot;: This prevents the names from colliding.''' (Adding &quot;_s&quot; is the way everyone does it.) See? Naming is a really delicate subject!<br /> <br /> So, before we finally start making the goddamn map, let me explain the shader we've created:<br /> <br /> The first line creates the virtual file by giving it a path and filename. Again, take care of those file names, be they virtual or real. The brackets don't need explanation, I guess.<br /> <br /> The &quot;qer_editorimage&quot; line is irrelevant for the game, but it gives our shader a nice image in NetRadiant. If you apply this shader to a wall, instead of the ugly &quot;no pic!!1&quot; texture, you now see your nice .jpg image. Half transparent even! That is caused by the &quot;qer_trans&quot; line, which is also irrelevant for the game. It's there purely for the editor. And both these lines are not necessary for editing. Later, you can add &quot;//&quot; to the beginning of these two lines, which means that they are &quot;commented out&quot;. Anything behind &quot;//&quot; is arbitrary text until the line ends. I don't know, though, if a comment can be written on the right end of a shader command. If you comment these two lines out later, when you've actually used the shader in the map, and restart NetRadiant, you'll probably realize that they are not technically necessary, but man do you want them to be there.<br /> <br /> &quot;surfaceparm trans&quot; says that the surface is transparent. This does not mean that you can look through it - it only means that ''the computer'' can look through it! Yes, he has to know, too. A later command will make the shader transparent for us humans, too. As the name said: It's a glass shader.<br /> <br /> &quot;surfaceparm solid&quot; says that the surface is solid. You cannot walk/fall/shoot through it.<br /> <br /> &quot;cull disable&quot; means that the opposite side of a brush that is completely painted with this shader will not be invisible, as it would be with a normal texture. &quot;culling&quot; means to temporarily remove elements (objects, faces etc.) that are irrelevant for the current situation. To speed things up. But it is disabled here because it's glass, so you can see the presence/absence of backside faces, so they must be there.<br /> <br /> So far, this was the description of how the surface behaves. I'm not the shader pro, so the following explanations might be a little stumbly.<br /> <br /> The next {}block describes the actual graphics that will be drawn. The {}block after that tells the system to also create a lightmap and overlay it.<br /> <br /> &quot;map textures/scr5_dretchnest/brightglass_001.jpg&quot; obviously makes the shader use your new texture file. &quot;tcgen environment&quot; is short for &quot;TextureCoordinateGeneration&quot; with the parameter &quot;environment&quot;. Man, do I have to explain environment mapping now? In short, this makes the texture appear in a way that is not like a normal 3D shape but instead like it were a reflection in the 3D shape.<br /> <br /> &quot;blendfunc gl_one gl_one&quot; means: The pixels of the source (this shader) will be multiplied by one, then added to the destination pixels (which is whatever's already drawn on screen behind the glass) also multiplied by one. So, this just adds your lightened (Remember that this shader has a lightmap.) environmentmap-glasstexture onto the world graphics. Now you might realize why it's called &quot;brightglass&quot;. If you want something darker, look for &quot;textures/tremor/darkglass3&quot;.<br /> <br /> I don't really know about shaders. I look at how the other guys did it (There are already tons of existing shaders, look in the folder &quot;scripts&quot; in the map .pk3 files.), I read a bit in the shader manual, trial and error testing, etc. For example, I have no idea what &quot;rgbGen identity&quot; really does, but it belongs there. If you want to dive into that yourself, read [http://www.heppler.com/shader/ this comprehensive shader manual]. Also, lets drop the rest of the shader explanation and get into mapping, damned.<br /> <br /> ===start making the map===<br /> <br /> Assuming that you're still in NetRadiant with your named map (that doesn't have any stuff in it) open, set the 2D to view from the top, set the gridsize to &quot;9&quot; (256), and draw a square, 8x8 grid elements in size, so it will be 2048x2048 world units. It's not really important where you do this, but since NetRadiant positions the camera at position 0,0,0 every time you load a map (which can somehow be changed with an entity, but I currently don't remember how, saw it in a decompiled ATCS once), I'd suggest that you draw this brush exactly centered around the coordinate 0,0. After you've done so, press CTRL and TAB to set the 2D to view from the side (doesn't matter which). If the brush isn't exactly one grid block high, drag it smaller so that it is. Then move the whole platform so that its upper side (which is the floor to walk on) is at coordinate 0. Unnecessary to say: The whole thing, every face, should have the Caulk shader, the ugly pink one that you already know.<br /> <br /> Copy and paste the selected brush. Click into it and drag it upwards so that its lower side (which will be the ceiling of the map) is at coordinate 256. That's an 8 meters high map hall.<br /> <br /> Press ESC, then draw a square brush left of the two existing brushes, exactly between them. If you press CTRL and TAB, you see that the depth of this square brush is already as we want it because the last selected brush(es) had this depth. Assuming that you're still in the side view in which you drew the square brush, draw another one, on the right side this time. Did you fall for the &quot;something is currently selected&quot; trap, or did you think of pressing ESC yourself?<br /> <br /> Press CTRL and TAB two times to get back to the top view. Now select the two side walls you made. To do that in the 2D view, it's ok to just use the box select in the currently mostly empty map space that we have. So, press SHIFT and then left-click and drag the mouse to select the unselected wall(s). The ceiling and floor (both visible in one place as a big square) must not be selected now! Once you've done that, copy and paste them, then click on the rotate-90-degrees-Z button (a Z with a blue arrow around 90 degrees of the Z). Now you should have a big room with ceiling, floor, and 4 walls. The wall and floor brushes should be edge-on-edge, that will work properly, don't worry. The brushes must not overlap, though! Admittedly, the walls are a bit thick, but they are the outer map walls, so that doesn't matter. Actually, it's not so bad to have them this thick. Why shouldn't they stand out in the editor as a unique structure.<br /> <br /> If you have done it right (which is more probable with this large grid spacing than it would be with a smaller spacing), you should have a proper shell in which you can go crazy without having to worry about [[leaking]]. The [[void]] is properly locked out. The [[VIS]] calculation can hence be performed. You will not have the [[hall of mirrors]] effect.<br /> <br /> Well, yes, you will have the HOM effect, because everything is still Caulk, but we'll change that now. First, select a proper texture: Select &quot;arachnid2&quot;, then scroll down a bit until you see &quot;cement_1_clean&quot;. Now, select all the 6 surfaces that form the room (CTRL SHIFT left-click, and as a NetRadiant user, you'll have learned to press ESC a few times before this new select action, I guess). Then click on the texture.<br /> <br /> '''Save the map. If this is your first save in this &quot;start making the map&quot; chapter, you're still doing it wrong!''' Also, duplicate the saved map file.<br /> <br /> Actually, the floor and ceiling look just wrong this way. Go to the &quot;karith&quot; texture section, scroll down a bit until you see &quot;cement_3&quot;, select only the floor and ceiling face (Not the whole brush, but I guess I don't have to say that any more.) and apply the texture. Save the map. No new backup this time.<br /> <br /> Nice room. If you fly around in it with your camera, you might get the impression that it's too dark. In that case, open the NetRadiant preferences. Don't worry about a message saying that you'd better save before entering the preferences - in most cases, it doesn't matter. Except that saving is usually fast and in most cases not a problem. And if that dialog appeared just now, you didn't save the map when I said so, sinner! :&gt; Go to the preferences section &quot;display&quot;, subsection &quot;textures&quot;, and set the texture gamma to, let's say, 0.8<br /> <br /> ===about clipping, most underestimated by beginners===<br /> <br /> Assuming that the current situation is the result of your actions in the last chapter, you should still be looking from the top in the 2D view. Gridsize should still be largest (key &quot;9&quot;). Now, draw a new brush, 4 grid elements in size, around the 0,0 coordinate. So, the size should be 512x512. The brush should be inside the map shell room that you built, exactly from floor to ceiling.<br /> <br /> We'll use a little trick now. Set the grid spacing to 32 (key &quot;6&quot;). As I said, 32 is the smallest wall thickness you should use if you want to prevent light bleeding. You can be lucky with smaller values or still unlucky with larger ones, but 32 is a good base to work with. I've read somewhere that a thinner wall risks that objects or players might pass through it when playing on the Internet, but I think that's not true, at least I haven't seen problems like these ''ever'' in the Tremulous world, and there are maps with thinner walls around. Another thing about wall thickness: Even a wall with 64 world units might still let the damage effect of a fully charged [[Lucifer Cannon]] shot through a bit. I wonder how much or how little calculation time / network overhead impact it would have meant to prevent this, because this behavior sucks considerably.<br /> <br /> So, with the grid set to spacing 32 and the new 512x512 brush selected, search for the 5th button right of the 90-degree-Z-rotate button. When you hover over it, it says &quot;Hollow&quot;. Alternatively, go to the &quot;brush&quot; menu, submenu &quot;CSG&quot; and select &quot;Make Hollow&quot;. This function is not widely used, because it motivates box rooms (and other reasons, I guess), but right now it's the best thing in the world because it guarantees that you have a new room with 6 walls, all edges ''overlapping'', wall/ceiling/floor thickness 32. (Side note: Why the &quot;hollow&quot; tool doesn't come with the option to automatically clip the resulting brushes is beyond me.)<br /> <br /> Overlapping brushes should be prevented &quot;at all costs&quot;. We'll do that now, too, which brings us to &quot;clipping&quot;.<br /> <br /> Did I say &quot;save the map&quot;? No, and I won't say that any more.<br /> <br /> While still looking from the top, try to select one of the four walls in the 2D view. It's tricky, isn't it? Now you see why you'll select stuff in the 3D view most of the time. But let's try the 2D view again. Press ESC. Then, box-select the middle part of one of the walls (which will also select other stuff). Then, box-select the center of this new room. Shazam, everything except the wall is deselected. Box-select inverts the current selection where it is in effect. Also, nice that we activated &quot;display size info&quot; in the preferences (&quot;orthographic&quot;) before, because now we can clearly see that all elements of the current selection have the position and size of the wall we wanted - which makes it reasonable to assume that only the wall is selected. Once your maps are a bit more complex, that assumption is not so reasonable. I think that it would save the mappers of the world tons of time if there were a simple but prominent number stating how many elements are currently selected. Well, rudimentary tool, as I said. Instead, you can see how many milliseconds it took the 3D view to redraw.<br /> <br /> Now that one wall is selected, choose a different tool. Currently, the button with the square on it is activated (&quot;Resize (Q)&quot;). Activate the button right from it, the one with the diagonal line (&quot;Clipper (X)&quot;). This tool can be used to cut away parts of brushes or to split them into two brushes. Reminder: The preferences of the &quot;clipper&quot; should be set to &quot;Clipper tool uses caulk&quot;.<br /> <br /> You have to cut away a small diagonal part of the wall in the corner. What we want to achieve is that the four walls do not overlap in the corner but do instead end exactly where the next one begins. Yes, you could just use the resize tool for that, but that's not how a good mapper does it (except when it makes more sense than clipping). Imagine: When the walls are clipped in the way I described it, then not just the outer walls will be perfectly connected, but the inner walls, too. So, when you paint textures on them, you can use the &quot;fit&quot; tool of the &quot;surface inspector&quot; (key &quot;s&quot;) to make the texture fit the wall perfectly while you can mostly forget about all the numbers in that window. Or, if you're dealing with the numbers, you can copy them from other surfaces because the other walls have the same special properties (brush corners clipped).<br /> <br /> Well, if you had drawn the walls edge-on-edge like you did with the outer map walls, painting the inner walls would be exactly as easy as the clipped result will be. But we want to paint the outer walls, too! This will be a room visible from the outside, hence it must be properly built.<br /> <br /> So, let's just try to clip one of the corners of the selected wall now. Choose one end of the wall, then click once on the corner that is outside of the room, then on the one that's inside of the room. Two blue dots (&quot;1&quot; and &quot;2&quot;) should have appeared. The line that connects them should point from the outside room corner to the inside of the room. Also, there is another line (the &quot;perpendicular&quot; or &quot;normal&quot;) beginning at the middle of the clip line. Both lines are not existing objects but just editor tools.<br /> <br /> Press ENTER. So, the brush was divided by that clip line you made, and now one of the two parts of the brush is gone. It's the one that the additional line (the &quot;normal&quot;) went through, that's the rule. Which way the &quot;normal&quot; points depends on the order in which you created the clipper points. Also, you can invert the clipper direction (menu &quot;brush&quot;, submenu &quot;clipper&quot;). Also, the brush part that will stay will have the clip face painted blue in the 3D view (as long as you didn't complete the clip by pressing ENTER).<br /> <br /> Clipper tips: You can drag the clip points around on the 2D view. You can even add a third point. You can change the 2D view from top to side etc. and then still drag the points around. And you cannot remove the clip points by pressing ESC. To remove them, you have to select a different tool (like &quot;resize&quot;) and then switch back to the clipper tool. Or just click again once all 3 clipper points are placed, because that will place number 1 again, removing the other two. Only if you click directly on one of them, you can drag them.<br /> <br /> Very frustrating: While the &quot;undo&quot; can be used to return to the unclipped brush, it does not return you to the situation with existing clipper points, so you have to place them anew.<br /> <br /> Now that you kinda know how to work the clipper tools, clip all 8 wall ends diagonally, so that the walls are perfectly face on face, not overlapping any more. So that the inner walls start and end exactly in the inner room corners.<br /> <br /> Wow, finally done with the stupid clipping. Let's paint and resize a few more blocks, right? No. The clipper tool is one of the most important tools in mapping, and you'll use it much more often than you can imagine right now.<br /> <br /> For example: It's time to clip the ceiling and floor so that they diagonally meet the walls - which, thusly, also have to be clipped. In the end, all 6 walls/floor/ceiling of the little room will be kinda like the bottom ends of pyramids pointing into the room, perfectly face to face which each other. During all this, you should leave the grid spacing on 32.<br /> <br /> Done yet? An experienced mapper needs 1 or 2 minutes to finish this properly.<br /> <br /> You might be wondering why we didn't just delete the ceiling and floor of the little room (after all, there's still the outer map ceiling and floor). Reason one: Using a map shell room like we did is a crutch. Not necessarily a bad one, but also not necessarily the way an experienced mapper does it. Reason two: You'd make yourself dependent on the outer ceiling and floor, and once you get out of the room and map some more, you'll have more dependency-situation-possibilities like this. You don't want to tie it all together and stand in your own way. I had that when making skybox. &quot;Can I texture this wall? No, damned, it's the outer wall again.&quot; Reason three: Lightmaps! I don't know how exactly it is decided how many pixels a lightmap has, but I am pretty sure that a huge brush will have a less high resolution (so, rather stretched) light map. Oh, speaking of which:<br /> <br /> ===_lightmapscale, gridsize, turbo rendering===<br /> <br /> (You can skip this now and go to &quot;enjoy the fruits of the clipping labour&quot;. One day, you should read this, though.)<br /> <br /> I already explained the worldspawn. Press ESC and select any one of the brushes. Since we currently only have simple worldspawn brushes (as opposed to, for example, doors), you could also just box-select a bunch of them. Anyway: Press &quot;n&quot; if the entity inspector was not yet visible. As you know, the second section shows a help text for the currently selected entity type, and since the third section shows &quot;classname worldspawn&quot;, the help text describes the worldspawn. Scroll far down (not to the end) until you see the explanation of &quot;_lightmapscale&quot;. Read it. Then, write &quot;_lightmapscale&quot; and &quot;0.25&quot; into the &quot;key&quot; and &quot;value&quot; textboxes and press RETURN while you're in the value textbox. I thoroughly tested it in a relatively small room: Values smaller than 0.25 don't increase the lightmap resolution any more.<br /> <br /> Setting the lightmapscale to 0.25 will result in a higher lightmap resolution, so you'd have better shadows etc., think of the difference between the thumbnail of a picture and the full size version (only the difference is not that drastic here). The default setting is &quot;1.0&quot; (when the _lightmapscale key is not present). 0.25 also means that the LIGHT phase, in which the lightmaps are calculated, will take much longer. This also means that larger settings than 1 will make it shorter.<br /> <br /> If you've followed this mapping crash course so far, you'll either have prepared q3map2 frontend &quot;q3map2build&quot; or a build batch file, and you will have done so that the light rendering result is very good:<br /> <br /> &quot;fast&quot; is not activated. &quot;bouncescale&quot; is on 2, &quot;bounce&quot; is on 500 (meaning: effectively &quot;6&quot; or something). And to top it off, your map now has the best lightmap scale. The option &quot;filter&quot; is not relevant for the calculation time. It will smooth the resulting lightmap a little so that shadow seams don't look so pixeled. I am not repeating all this from other guides, these are actual experiences that I gathered in many tests over months.<br /> <br /> Now, as long as your map is very small, these settings are ok. Calculation will be done in a few minutes or less than a minute. But once your map is a huge monstrosity, calculation with these settings takes several days on a fast computer. That's still ok as long as you have an extra machine for things like these, but '''here's how you can speed up the rendering like crazy''' (resulting in less good result, of course):<br /> <br /> Add the key &quot;gridsize&quot;, value &quot;1024 1024 1024&quot; to your worldspawn (default would be 64x64x128 as far as I know, and to achieve default, just delete the key again). As far as I know, the gridsize defines the ''volumetric'' lightmap calculation. If you get closer to a bright red spot in the map, your weapon will receive red light. If the gridsize is as coarse as we have set it here, those effects will be less prominent. I could be totally wrong about this. Maybe the gridsize is more about how the raytracing really takes place. In any case: Changing the gridsize has ''huge'' (!) impact on the calculation time. Setting it to this value will make it faster. Deleting the key, so that you're back on the (very good) default value makes it slower. Setting the gridsize to something like 48x48x48 increases the calculation time insanely, and as far as my test results go, it doesn't have any merit. So: For high quality results, you'd use the default setting. For quick and less proper results, you use the 1024 (or an even rougher) one.<br /> <br /> You can also drop the &quot;bouncegrid&quot; option. Bouncegrid means that before every radiosity bounce, the lightgrid (see &quot;gridsize&quot;) is calculated anew, because somethingsomething bounce influence grid somethingbla. Honestly, I didn't test the difference it really makes, but I believe that it's safe to assume that this option increases the light rendering quality even further.<br /> <br /> Change the rendering settings (in &quot;q3map2build&quot; or your batch file) so that the LIGHT phase uses the key &quot;-fast&quot;. This does not change the lighting ''very'' much (but still too much for my taste when I want to make a real proper release), but it insanely reduces calculation time.<br /> <br /> Removing the &quot;bounce&quot; option (&quot;bouncescale&quot; is irrelevant for the time (except in regards of the caused number of iterations) and is bound to &quot;bounce&quot;, so you don't have to touch it here) has strong influence on the lighting. You should try to have a few bounces in your released maps, the light looks considerably more natural. Removing the &quot;bounce&quot; option decreases calculation time, though. Very much even. If the initial pass (not yet bounced) takes 10 seconds, every bounce will also take about 10. If the first took 1 day, guess what. Depending on the bouncescale you used, the amount of bounces will have strong influence on the lighting result. This is something for tweaker guys. Just as the &quot;gamma&quot; option (that I didn't mention yet) in the LIGHT phase is. You should know that these options exist and that it's a good idea to toy with them. Now let's move on.<br /> <br /> Another option that you can add to speed up calculation: &quot;-fast&quot; in the VIS phase. Please don't do this, though, if you want to release the results into the public. And definitely don't release the result if you omit the VIS phase completely - which you can also do to decrease rendering time even more. The VIS phase calculates which spot of the map can be seen from which other spot. This information allows the game engine to draw only the necessary graphics. As far as I know, it also influences the radar functions of helmet and aliens. It's essential for a release, and you should do it without &quot;-fast&quot; for a release.<br /> <br /> '''In short:'''<br /> <br /> '''For fast rendering''', add &quot;-fast&quot; to the VIS phase (or drop it completely), add &quot;-fast&quot; to the LIGHT phase, remove &quot;bounce&quot; from the light phase (or just &quot;bouncegrid&quot;, but I think if you're already doing bounces, you might as well do them properly), remove the &quot;_lightmapscale 0.25&quot; thing from the worldspawn, add &quot;gridsize 1024 1024 1024&quot; to the worldspawn.<br /> <br /> '''For best (slow) rendering''', have a not-fast VIS phase, not-fast LIGHT phase, bouncegrid, bounce 500. Remove &quot;gridsize&quot; from the worldspawn. Add &quot;_lightmapscale 0.25&quot; to the world spawn.<br /> <br /> If you want to see a map that rendered for 112 hours with lightmapscale 0.25 and 11 radiosity bounces (Then it was tuesday morning and I needed the computer :/ Yes, you can abort the calculation at any time. Previous bounces will still be existent, and the current half-done one will also not be visible.) and want to see what the higher lightmap resolution might do to a 128MB graphics card, take a look at [[Gmotw_Skybox]]. I'm not really proud of the rendering result. There should be more shadow cast situations and so forth, but it's the best I have to offer in that regard yet. I think the lightmap can best be enjoyed in and above the pump station.<br /> <br /> ===enjoy the fruits of the clipping labour===<br /> <br /> Inspect the result of your work. It's very useful that you can move the camera to the inside of a wall, making it temporarily vanish from the 3D view.<br /> <br /> While you were working on the clipping, I picked a nice texture to demonstrate the described advantages of clipped walls. The texture browser should still be in the &quot;karith&quot; section, showing the &quot;cement_3&quot; texture (near the top). Scroll a bit further up until you see a broad texture called &quot;base_grooved&quot;. (Well, you might have a hard time finding it if there's another texture with a long name to the left of it, because then, the name on screen is partly overwritten. As I said: Rudimentary tool.) It should be the 8th texture. Press ESC and then click on the texture. At the bottom of the screen, there should be a text saying &quot;textures/karith/base_groove...&quot;. The texture looks like someone used a comb on a gray piece of butter from the left to the right.<br /> <br /> Now, select one of the faces inside the little room, then click on the texture. If you have done everything like I described, you'll see the texture on the wall, but there's something like a split in its middle. What you see are the outer ends of the texture. Textures are always looped on the brushes, so now lets place this texture properly. Press &quot;s&quot; (if the surface inspector was not already visible), then click &quot;Fit&quot; (if there is a 1 in both text boxes beside the fit button, otherwise set the boxes to 1 (or 1.000000, it's the same)). That was easy, wasn't it? Imagine what would have happened without the clipping. The texture would be partly hidden. If you look at the surface inspector and the numbers in it, can you imagine the hassle of adjusting everything until it looks like it does now?<br /> <br /> If you look at the horizontal and vertical stretch, you see something between 0.5 and 1 (and they are different - thank the programmers for the &quot;fit&quot; button). That's kinda ok-ish, but smaller values mean higher texture resolution. Only we can't put the texture in twice because that doesn't look good, either. The &quot;width&quot; and &quot;height&quot; value next to the &quot;fit&quot; button, by the way, define how often the texture is to fit the surface when you click &quot;fit&quot;. Yes, &quot;0.5&quot; etc. works, too.<br /> <br /> Paint all four walls in the described manner. You can do them all at once.<br /> <br /> After that, paint floor and ceiling with the next texture in the list, &quot;base_small&quot;, and fit it in 1 by 1. Again, this wouldn't have worked so easily without clipping. The horizontal and vertical stretch are close to 2, which is much too high. You can already see how blurry and cheap it looks. But keep it for now.<br /> <br /> ===let's add a door===<br /> <br /> Look from the top in the 2D view. Set the grid spacing to 128 (key &quot;8&quot;). Select one of the 4 walls. Just for training, let's use the toggle-selection, so press and hold SHIFT and ALT, then click on one of the 4 walls a few times until it is selected. You don't have to press ESC before this.<br /> <br /> With the wall selected and the clipper tool active, click on the wall. Gridwise, it has 4 sections. Click so that 3/4 of the wall would be cut off. Umm, where to put the second clip point? The grid doesn't allow to put it on the wall! Well, doesn't matter. Just put it a bit further away. Only the direction and position of the line itself must be correct, not its length. If you have made a nice (and non-diagonal) clipping line, press SHIFT and ENTER or select &quot;split selection&quot; from the &quot;brush&quot; menu, submenu &quot;clipper&quot;. You have cut the wall into two segments. Do that again on the other side, so that the middle segment is two grid elements in size. By the way, you can join brushes if the result would &quot;make sense&quot; (convex brush) using menu &quot;brush&quot;, submenu &quot;CSG&quot;, item &quot;CSG merge&quot;. If you try to merge brushes that can't be merged, you'll see an error message in the log area.<br /> <br /> Ok, now deselect everything (ESC). Then '''select the middle part of the split wall. Then, right-click in the 2D view, go to &quot;func&quot; and select &quot;func_door&quot;. You just made an automatic door''' that opens to the side if you get close, complete with sound. Nice, huh? Let's change the angle to &quot;top&quot; by adding the key &quot;angle&quot;, value &quot;-1&quot; in the entity inspector.<br /> <br /> You could actually make a door that uses a sensor that only reacts to someone carrying a lucifer cannon. Or to dretches and dragoons. Then, a sound would play and dark light would go bright (without lighting the environment, though (then again, I think it can be done using a shader with specular lighting)). Bars in front of the door would move to the sides (with sound). Then, the door would ''rotate'' open kinda like a garage door. Later, everything would move back. This can really be done using triggers, delays and so forth. But dude, I'm not gonna guide you through that.<br /> <br /> You can adjust the door in the &quot;entity inspector&quot; (&quot;n&quot;). You can change the sound, the direction into which it opens, how much of it is still visible once it's open, whether its default is open or closed, how much damage it does to you if you stand in its way, how fast it moves and more. The &quot;lip&quot; value is especially useful. You know, a door is just a brush (or a bunch of brushes - yes, '''you can make complex designs and have them move as one unit''') that moves. It has convenient defaults and a sensor. But you don't need to use the sensor. Also, '''you can use huge negative values for the &quot;lip&quot;, making the door move much further than necessary when it opens. And what is that then? A lift! :)''' There is also an extra lift function, but its default sounds are broken, and also it cannot be set to &quot;crusher&quot;, as far as I know. The big lift in skybox is a door, consisting of several brushes. '''Doors are really versatile.''' You know what? I once used doors to make a programmable soundtracker in Tremulous (&quot;gmotw_pianolessons&quot;, named like this because there's also a big piano with black and white keys that you can step on, and guess what, they are all doors). 16 doors would hammer down in a sequence, and their &quot;I'm closed now!&quot; sound wouldn't play if they don't arrive at the closed state, so I just made buildings in their way to program the sound steps. Did I say that doors are versatile yet? A server where you can save the current building layout can then even save the rhythm for later! Problem is, once too many elements are used, the rhythm stumbles a bit. Maybe a faster computer or newer Trem client doesn't have that problem. I used 16 steps and 3 instruments (bassdrum, snare, closed highhat), and it already got a bit stumbly. Another thing you can do with a door is use it as a busy-light that appears from out of nowhere (was hidden in a wall) and vanishes once the busy cycle (lift or whatever) is over. Also, I once made a door that actually consisted of 8 by 8 doors that you had to shoot. It was a pixel-door. If you didn't shoot the pixels away fast enough, they would return and you wouldn't get through. A tyrant (or whatever) filter. A dream if you carry a lucifer gun. That was in skybox, but I had to remove it in later releases because with all the other map elements, it reduced the FPS too much. But the door maze is still in the map. Looks like solid walls, but it is a small 2D maze. No, even 3D.<br /> <br /> Now, press &quot;h&quot; to hide the door and move the camera so that you look at the room from the outside. We'll now paint the frame of the door. Use the texture &quot;base_verts&quot; which comes shortly after the &quot;base_small&quot; that we used for floor and ceiling. Select the two faces at the side of the opening. Click the texture. Click &quot;fit&quot;. If you look at the stretch values, you see that one is 0.5 and the other 0.25, which can look odd, so better enter a &quot;2&quot; instead of the &quot;1&quot; in height (next to the &quot;fit&quot; button) and click &quot;fit&quot; again. The texture is now used 2 times in height, so it is not as streched in that direction. Press ESC. Then select the upper and lower face of the opening. Click the texture. Looks wrong. Now what? Well, it needs to be rotated. If you look at the &quot;rotate&quot; text box, there is a &quot;0&quot; in it. The text boxes on the right side can be changed at any time without influencing the map in any way - they are only an editor tool. The box right to &quot;rotate&quot; should have a &quot;90&quot; right now. If so, click the up or down arrow (doesn't really matter now) of the rotate value, changing it to 90 or -90 degrees. The texture looks better now. Click &quot;fit&quot;. Damn, bad stretching. Change the height preference to &quot;4&quot; and click &quot;fit&quot; again. See? The &quot;height&quot; now means &quot;width&quot; because the texture is rotated.<br /> <br /> If you look now from the inside of the room, you'll see that the wall (not frame) texture is cleanly cut, as it should be. If you would want to apply and fit the texture now, you'd have problems. '''To use &quot;fit&quot; on a surface with the &quot;wrong&quot; size, temporarily resize the wall to an appropriate width, click &quot;fit&quot;, return the size to normal again.'''<br /> <br /> Paint the 3 outer walls with the texture we used on the inside walls (for that, select an inside wall surface and use CTRL and C, which will not just copy the texture settings, rotation and so forth, but will also select that texture in the browser, so you can just click it then instead of using paste). Don't forget to fit (1x1). Paint the two short front walls with the texture &quot;base_v_rigged&quot;. Fit them in (1x1). By now, you'll have realized that the textures are sorted by alphabet. <br /> <br /> Press SHIFT h to get the door back. Press ESC. Select the door. Press i or choose &quot;invert selection&quot; from the edit menu. Press h. Now, only the door is visible, and it obviously needs some texturing. Put &quot;base_small&quot; on the outside and inside (fit 1x1).<br /> <br /> The four outer sides of the door are still unpainted. Let's select them all at once and then apply &quot;base_verts&quot;. Fit them 1x1. There's a problem: Even though the stretch values on the side surfaces are different from the top/bottom surfaces, you only see one number pair. Keep that in mind, also when dealing with the entity inspector while several elements are selected. A common reason would be to copy the values of one door to another. Select the correct door first, the one you want to fill with values as second, and for every value that you want to copy, click it and then press ENTER in the &quot;value&quot; text box to re-apply the key-value-pair to the correct door, which will also copy it to the other(s).<br /> <br /> So, let's do this again properly (and maybe you have already realized that this is all wrong, then follow me without acting, also smile). Press ESC. Select both side surfaces. Click &quot;fit&quot; with 1x2, so both stretch values should become &quot;0.25&quot;. Select the top and bottom, rotate the texture by 90 degrees, fit 1x2. Why not 1x4 like the same surfaces of the room walls? Because the surfaces of the room walls didn't begin/end at the door opening! So, we have a few meters of unnecessarily painted faces there. I don't know if a real pro mapper would now fix that by causing a few more brushes or if they would just ignore the few meters of unnecessary texture. We'll just leave it at this now. Don't tell anyone.<br /> <br /> The door is now painted on the front, back, and on the other 4 sides. Unnecessarily. The reason is that we didn't think enough like a mapper should, instead we were stuck too much in real-world thinking. Since you will never get to see the left, right and top side of the door, we should apply the Caulk shader to them.<br /> <br /> The texture browser has a little drop down menu, too. Go into that &quot;view&quot; menu and click &quot;hide unused&quot;. This hides all textures from the texture browser that are currently not used by the map. Even better: Also select &quot;show all&quot; from the same menu. Now, every texture that you had loaded in this program session (except the unused ones because you just hid those) is in the texture panel. You should memorize this trick, it will make your mapping much easier. For example: The caulk shader is here! Apply it to the left, right, and upper surface of the door. Then press SHIFT h to unhide everything.<br /> <br /> Press ESC. Select the door. Go to the entity inspector. Add the key &quot;lip&quot;, value &quot;80&quot; to the door, because otherwise it would look kinda weird while open. A bit of its lower end would stick out of the ceiling without any apparent cavity or mechanism for the door. With &quot;80&quot;, it sticks out so far that no one will ask questions.<br /> <br /> This, by the way, makes another surface's texture unnecessary. Since I don't plan on toying around with the door some more, let's set that surface to caulk, too. So: Hide the door. Then look from the outside. The upper diagonal surface will be invisible because the door will never reveal that surface.<br /> <br /> ===let's populate the map===<br /> <br /> Add an &quot;info_player_intermission&quot; entity. (I won't tell you how because I already did. If you didn't read the whole truckload of text, use the in-page-search function of your browser.) Move and rotate the entity so that it looks at the door of the little room from the outside, from a bit further away, slightly diagonal so that you can see the side wall of the room, too, and much of the rest of the map.<br /> <br /> Press the &quot;1&quot; key for the highest grid resolution that you can achieve with the keyboard. In the room (top view in 2D), create a &quot;team_human_reactor&quot; entity. Move it around a little. Then press &quot;8&quot; for grid spacing &quot;128&quot;. Move the reactor again. You see that the amount by which it moves is 128, as the grid forces it to. But its position is kinda off (if we're not unlucky). To force the reactor back into a nice x y and z grid position, press CTRL and &quot;g&quot; or use &quot;snap selection to grid&quot; in the &quot;brush&quot; menu. Now, with the 128 grid, move the reactor as far into the corner as possible. I don't care which one, as long as it's not on the door side. Switch the 2D to side view, set the grid to &quot;7&quot; (64), drag the reactor to a reasonable height position. It must not be in or above the ceiling and not in or below the floor.<br /> <br /> Rotate it around the Z axis by 90 degrees until the nice control panel can be seen. You might even want to rotate it arbitrarily by 45 degrees and then in 90 degree steps until it nicely faces the room.<br /> <br /> Also build an armory, a medistation, two nodes and a few turrets. Give them enough space. Especially the armory is tricky. Too few people know that '''the game system only allows square [[Hitbox|hitboxes]]'''. The height can vary, but the shape when seen from top is square. Even the armory? '''Yes, even the armory.''' If you keep that in mind, it will explain every occasion on which the armory or a nearby building didn't appear in the game.<br /> <br /> You should already rotate the turrets so that they face the door. This is not a [[Building|base building guide]], so I'll stop here.<br /> <br /> Don't forget to make a few alien buildings (overmind, SPAWN!, ...) somewhere in the outside hall.<br /> <br /> Then add &quot;player_human_intermission&quot; and &quot;player_alien_intermission&quot; (one of each) and make them look at the human and alien base.<br /> <br /> You can have a look at the map if you want, even though we haven't placed any lights yet. Just omit the LIGHT phase. Everything will be at full brightness. The batch file:<br /> <br /> &quot;C:\Program Files\netradiant-20100214-win32\q3map2.exe&quot; -fs_basepath &quot;C:\Program Files\Tremulous&quot; -fs_game &quot;base&quot; -custinfoparms -info -meta -patchmeta &quot;C:\Program Files\Tremulous\base\maps\scr5_dretchnest.map&quot;<br /> &quot;C:\Program Files\netradiant-20100214-win32\q3map2.exe&quot; -fs_basepath &quot;C:\Program Files\Tremulous&quot; -fs_game &quot;base&quot; -vis -saveprt &quot;C:\Program Files\Tremulous\base\maps\scr5_dretchnest.map&quot;<br /> &quot;C:\Program Files\Tremulous\tremulous.exe&quot; +set fs_basepath &quot;C:\Program Files\Tremulous&quot; +set fs_game base +devmap &quot;scr5_dretchnest&quot;<br /> <br /> ===lighting===<br /> <br /> On second thought, you should definitely look at the map right now. With full brightness, it sucks. Once we've added nice lighting, it will look so much more pleasant. Lighting makes and breaks the mood.<br /> <br /> Just as decorations (which we haven't dealt with yet) are not a burden but a passion to a real mapper, lighting is not something to be dealt with by just throwing strong point lights with no apparent light source (fixture) all over the place. And definitely '''''do not'' use the &quot;_minlight&quot; or &quot;_ambient&quot; features in the worldspawn.''' You might use them sometimes - really rarely - to test something, but a map with proper lighting will, I dare to claim, never have one of these features in use.<br /> <br /> '''There are two possible light sources:''' Point lights (which can be made with the right-click menu) and light textures (or light shaders, same thing, different term). We have already dealt with shaders. It's possible to make shaders with a parameter that makes it emit light. The larger the surface that uses the light shader, the more light is emitted. The advantage of using light shaders is that you always have a &quot;something&quot; that the light is actually coming from. This contributes considerably to the mood, because it is more believable. You can, of course, just build a &quot;something&quot; that might be a light, then add a point light source to it. That works, too. Actually, the main reason people rarely do that probably is that you can't group brushes and point lights together. You see, the &quot;worldspawn&quot; entity is not the only &quot;dead&quot; entity that can hold brushes. '''You can also select a bunch of brushes and then select &quot;func_group&quot; from the right-click menu.''' This creates a new entity of type (or &quot;classname&quot;) &quot;func_group&quot;. You cannot add other entities (like light or a doorbrush) to such a group which is sad, because if you could, people would probably also try to construct light fixtures and then just put a point light into them instead of fiddling with shaders. And what is the advantage of such a group? Well, if you select one of its brushes, you can then use &quot;expand selection -&gt; to whole entities&quot; from the edit menu. You can then conveniently move them around or copy/paste of them - which creates a new func_group with the copied brushes in them. The expand selection function also works for several such things in parallel. Sadly, I haven't yet found out how to add another brush to such a group. &quot;regroup&quot; in the &quot;entity&quot; menu does the opposite of what you'd expect, and I haven't tried the next function, &quot;ungroup&quot; because I suspect that it does what you'd expect.<br /> <br /> ===decorations, structural/detail brushes===<br /> <br /> <br /> <br /> ===create a release file===<br /> <br /> <br /> <br /> [[Category:Mapping]]</div> Tue, 13 Jul 2010 14:01:05 GMT God, maker of the world http://tremulous.net/wiki/Talk:Mapping Mapping http://tremulous.net/wiki/Mapping <p>God, maker of the world:&#32;/* obtain a frontend for q3map2 */</p> <hr /> <div>A [[mapper]] is a person who creates a game [[map]]. He is &quot;mapping&quot;. This article describes how that works in the Tremulous context. For a list of a few existing Tremulous maps, click [[:category:Maps|here]].<br /> <br /> <br /> =mapping crash course=<br /> <br /> I started this article on 2010-06-29, just so you know why it doesn't refer to Tremulous 1.2 etc. I am a Windows user (2000 and XP), so that's the perspective that I use. If you can't translate that into your perspective, then you probably shouldn't use the system you're using.<br /> <br /> There are already several mapping guides out there ([http://tremulous.net/forum/index.php?topic=7497.0 list]), one of the best of which is at [http://tremmapping.pbworks.com/ tremmapping.pbworks.com]. It is easy and very comprehensive. I'll try to write a new one from scratch here based on my experiences - and much more up to date. It will save you some steps that were necessary 3 years ago when the linked guide was made. This article here will not enable you to make good maps, but it will give you a truckload of know-how of the kind you don't find in other mapping guides.<br /> <br /> If you've ever written something like a guide, you know that you'll inevitably get into ramble mode from time to time. I guess you can forgive me that.<br /> <br /> <br /> ==setting up your computer==<br /> <br /> ===Tremulous client===<br /> <br /> Download and install the original Tremulous 1.1.0 client. It can be found [http://tremulous.net/files/ here], but it's all over the Web, just search. Now, you ''could'' use a different Tremulous client, but I suggest that you don't. Reason: The original client is what many people out there still use, and when you test your map, you'd want to see what it looks and behaves like (and if it works at all) in the client all those [[newbie|noobs]] use who wouldn't know how to fix a problem if your map causes it. You want your map to work and to shine in the original client. You don't want it to look great only in the latest client with magical rendering v9.9.999 and bloom effect.<br /> <br /> Maybe also download the [http://tremulous.tjw.org/backport TJW backport] client. It's a slightly updated version of the original client. Not too new to violate what I said in the previous paragraph. This is not a full Tremulous release. It's just the program itself. Put it into the program folder of the above mentioned original client. This client supports [[GUID]] and much faster auto-[[Cl_allowDownload|download]].<br /> <br /> You might already have all this. But consider starting anew in a VirtualMachine or on a new computer. If you're more proficient, you'll be able to maybe clean up all your Tremulous base folders so that you don't have magical conditions that a person using the naked client wouldn't have. If you're not proficient enough in this and don't want to make a clean install, prepare to experience problems like &quot;But the texture wasn't missing on my machine!&quot;.<br /> <br /> ===NetRadiant===<br /> <br /> Now the most important part: Download and install [http://ingar.satgnu.net/gtkradiant/installation.html Ingar's NetRadiant and the Tremulous support files]. That's two downloads. The instructions on the linked page are short and comprehensive, it's easy to do. [[NetRadiant]] is the tool that you actually make the maps with. You probably also heard about &quot;GtkRadiant&quot;. Forget it. It's 99% the same as NetRadiant, but it's no longer developed. Also, installation is more complicated because it is not prepared for Tremulous. Additionally, Ingar's NetRadiant already includes the [[Q3Map2]] program that compiles your .map document to a playable .bsp map file.<br /> <br /> Change the NetRadiant preferences (and learn a few things about them): Start it. You'll probably see a little window offering a game type selection. Choose &quot;Tremulous&quot;. There's also a checkbox to prevent this window from appearing every time you start NetRadiant. Technically, that was all. But please, continue adjusting the preferences: Go into the preferences window, which can be found in the &quot;edit&quot; menu at the bottom. I'll go from top to bottom, not from most to least important.<br /> <br /> '''Textures:''' Later, you might want to change &quot;gamma&quot; to something like &quot;0.8&quot; to make the 3D display of the editor brighter. '''Undo:''' Increase queue size to 128. You'll use undo very often, sometimes to undo shifting textures around, and that's an undo step for every texture shift step even if it was a button autorepeat result.<br /> <br /> '''Brush:''' Definitely activate &quot;Always use caulk for new brushes&quot;. You can also activate &quot;Use alternative texture-projection&quot;, but most people do not do that, so if you want to open their maps, you'd have to turn it back off and restart the program. And there is no way to convert a .map from one setting to the other. If you decompile a playable map you found somewhere (like ATCS etc.), you would need to use the alternative projection to load the result in NetRadiant, so why not completely live in that world? I, however, have not done so. Because I didn't know better when I started mapping. I also don't know if I would ever regret turning this option on to make my own maps, so be careful. Maybe better leave it off.<br /> <br /> '''Grid:''' Set default grid spacing to &quot;32&quot;. That's the smallest room-wall-thickness that you want to use to prevent [[light bleeding]] (though the best measure to prevent light bleeding still is clipping). Once you're an experienced mapper, you might want to set this to &quot;256&quot;, the largest setting. '''Camera:''' Movement Speed 100 is good, but you'll come back later and change this, depending on your mapping situation. (I think NetRadiant should have a control element on the edit window to adjust the camera more quickly.) Smaller value for working on details, larger value if you have to travel a lot with your editor camera. Enable far clip plane: It's best to turn it off for now, you'll see everything then, no matter how far away it is. Enabling this option and setting the far plane to something close (menu &quot;view&quot;, submenu &quot;camera&quot;) would be helpful for selecting stuff with the box selection. Also, depending on your hardware and the map, it can speed up display considerably.<br /> <br /> '''Orthographic:''' Turn on &quot;display size info&quot; which will show you the size of one or more selected objects in the 2D view. Turn off &quot;chase mouse during drags&quot;, it would turn you crazy. '''Clipper:''' Definitely activate &quot;clipper tool uses caulk&quot;. '''Autosave:''' Deactivate it. If you're not a total computer noob, you'll know and use CTRL+S oftentimes anyway, and the autosave feature really gets in the way. The coders don't even reset the autosave timer when you hit CTRL+S (lol), so you're better off without it. Saving can take some time on bigger maps, so you want to be in control here. Also, very important: Make backups! Once you saved your map, go into the folder and duplicate the file (CTRL+C, CTRL+V, or whatever it is on your system). Sadly, the Radiant coders didn't include a save rotation like jEdit has it. You have to do that manually.<br /> <br /> Later, when you've worked a bit with NetRadiant, you might want to change the grid colors in the menu &quot;misc&quot;, submenu &quot;colors&quot;. My &quot;grid major&quot; is &quot;#00DF00&quot; (a big fat green) and &quot;grid minor&quot; is &quot;#ADFFAD&quot; (a very bright green, fading into white). Now, you should go into the &quot;view&quot; menu, submenu &quot;show&quot; and activate &quot;show workzone&quot; which will draw additional line garbage in the 2D view - the stuff you have drawn/selected last will have an additional red line pair around it. Makes it easier to find it. You have no idea how confusing the 2D view will become once your map is a bit more complex. Rule of thumb: Before you find the lines in the 2D view confusing, you shouldn't even think about presenting your map to the community.<br /> <br /> ===create the asset folders===<br /> <br /> '''Manually create folders in the base folder:''' You already know the base folder. You extracted the Tremulous support file here as Ingar's website instructed. Now, manually create a folder called &quot;maps&quot;. Also the folders &quot;textures&quot;, &quot;sound&quot; (NOT &quot;SOUNDS&quot;), &quot;scripts&quot;, &quot;env&quot;, &quot;models&quot;. If you have already seen a [[.pk3]] file from the inside, you'll have realized that the folders in those archives are treated by the game client as if they were really existing. So, you'll have guessed what those folders you just made will be used for: They'll hold the exact same kind of files that you see in the .pk3 map files.<br /> <br /> ===obtain a frontend for q3map2===<br /> <br /> If you're on Windows, definitely download [http://www.bobdev.com/q3map2build.php q3map2build]. The program is not necessary to make a playable map, but it's a big help in compiling. NetRadiant already has a build menu which calls q3map2 with parameters, also you could manually create batch files and just launch them every time you want to compile a map, which makes sense if you need very special settings for a map. For example: I worked on a map where I used q3map2's &quot;gamma&quot; option, quite unusual, so you would probably not reconfigure NetRadiant's build menu for that. You'd instead use a batch file. Or q3map2build. This VisualBasic program is a '''frontend for q3map2'''. It creates batch files and executes them. Depending on what you selected, there will be up to four lines in such a file: The first one compiles the binary BSP file from your MAP ascii document. The second one (&quot;[[VIS]]&quot;) calculates what point on your map can be seen from which other point and optimizes the BSP accordingly. Can be omitted oftentimes when you just want to have a look at your map, but for releases, this is absolutely necessary. It's the difference between 1 FPS and 90 FPS. Among other things. And the third line (&quot;LIGHT&quot;) finally calculates the light maps, so everything looks and feels real - without this phase, everything would be at full brightness which totally destroys the mood. The fourth line starts the Tremulous client with your freshly compiled map. Very convenient. '''After downloading q3map2build, you have to configure it:''' Start it. Go to &quot;directory options&quot;. Set &quot;game executable location&quot; to your tremulous.exe. Set &quot;q3map2.exe location&quot; to the file &quot;q3map2.exe&quot; located somewhere in the NetRadiant folder. Click &quot;save&quot;. Open the &quot;game options&quot; window, check the &quot;base mod dir&quot; box and type &quot;base&quot; into the text box. Click &quot;save&quot;. That was the basic setup of the program. '''While we're at it:''' In the little &quot;'''BSP'''&quot; area, select &quot;custom&quot; and click &quot;options&quot;. Activate &quot;custinfoparms&quot;, &quot;info&quot;, &quot;meta&quot; and &quot;patchmeta&quot;. Click &quot;save&quot;. In the little &quot;'''VIS'''&quot; area, select &quot;custom&quot; and click &quot;options&quot;. Activate &quot;saveprt&quot; (This makes sure that the portal file generated in the compile process is ''not'' deleted after the compile is completed, though it will be deleted and recreated on next compile. The portal file can be loaded into NetRadiant. You can then see in 2D and 3D the VIS areas that were compiled. Sometimes, you need this to help the software a bit. Keyword &quot;hint brushes&quot;.) and click &quot;save&quot;. In the little &quot;'''LIGHT'''&quot; area, select &quot;custom&quot; and click &quot;options&quot;. Activate &quot;bouncegrid&quot; (If you calc radiosity bounces, this option will make sure that the lightgrid (Whatever that is. I believe that it's a 3D grid of light. If you walk somewhere with your gun, it will receive e.g. red light. The light grid is where this is coming from, I believe.) is recalculated on every bounce, incorporating the light that was created by the bounces.), &quot;custinfoparms&quot; (which is necessary, I think, for shader parameters like &quot;nobuild&quot;, otherwise they might not get transported into the bsp, I believe), &quot;filter&quot; (softens the lightmaps so that shadow seams are soft, not pixelled), &quot;patchshadows&quot; (necessary for your pipes and models to cast shadows), &quot;bounce&quot;, &quot;bouncescale&quot;. Enter a &quot;500&quot; in bounce and a &quot;2&quot; in bouncescale. Remember these two options because you will later come back and deactivate them both, instead you will then (Later, as I said.) activate &quot;fast&quot;. Before you click &quot;save&quot;, let me explain what's going on here: These options define how the lightmaps will be rendered. The option &quot;fast&quot; really really increases the speed of the calculations, and you will use it most of the time because it even doesn't change the lighting drastically. But your first map tests will be of so little complexity that the rendering will be fast anyway. The &quot;bounce&quot; option is for radiosity bounces. So, your surfaces will not just have the light that is cast on them by the light sources. Instead, as in physical reality, your surfaces will also have the light that is reflected by the other surfaces. This is, of course, a question of iterations, because once a surface has received light from another surface, guess what: The next time, the light that comes from the surfaces is different. Realistically, 2 or 3 passes do the trick of giving the right impression. 500 passes will never be reached, all light will be used up at pass 5 or 7 maybe, the program will then stop calculating this. You should definitely use radiosity bounces in the maps you publish (if you have the time to calculate them), because they give a much more natural lighting feeling. For example: Colored surfaces will reflect colored light. You get the picture. Just turn this on for now so that you immediatelly collect data in your mind. The parameter &quot;bouncescale&quot; defines the amplification of the bounced light. Theoretically, this should be set to 1 (and hence just be disabled), but I have made good experiences with amplifying the bounces a bit. This causes more radiosity bounces, of course, because the light will not be used up so quickly. It can even happen that the light will not be used up at all. Hey. This is a crash course, not a &quot;click here and you're done, but you stay uninformed&quot; course. There's more information about these settings further down in this article ([[#_lightmapscale.2C_gridsize.2C_turbo_rendering|lightmapscale/gridsize/turbo_rendering]]).<br /> <br /> You might wonder why I don't just use the &quot;build&quot; features in NetRadiant. Because I want to be in control, and I want to be flexible. This crash course will, for example, deal with &quot;amplified radiosity bounces&quot;, the lightmapscale and somesuch. If I had used the build features as presented, I'd still only work with non-amplified bounces, I wouldn't have dealt with the gridsize or the lightmapscale, I wouldn't have used the &quot;filter&quot; feature. Maybe there's still stuff to discover, but I won't discover it if I use the preconfigured built-in buttons. You don't have to go that way, but I won't spare you the ugly details.<br /> <br /> '''So, until now you have installed the Tremulous client, the NetRadiant map editor, the NetRadiant support files, you have configured NetRadiant a bit, you have hopefully gotten your hands on a good q3map2 frontend, and you have created those folders. That's it, now let's go mapping.'''<br /> <br /> ==NetRadiant crash course==<br /> <br /> In Netradiant, move the mouse to the white area with all the confusing lines. Click and hold the left mouse button. Drag the mouse a bit. Release the left mouse button. You just made a floor. Or a ceiling. '''That thing you just made is called a [[brush]].''' This can only be done in the 2D view. Brushes are the building blocks used to make the map world. They can be changed into different shapes and also be drawn directly in different shapes, but most of the time, you'll draw simple box brushes. If you have done everything in the setup section, the box you have just drawn should have a number pair at its left top (position), a number on the right side and a number on the bottom (dimensions). The unit system used is called &quot;world units&quot;. Rule of thumb (that I heard - can't say that I have really verified it) is: 32 world units = 1 meter. There should also be red lines from all four directions leading to the box brush you made. Click and hold the right mouse button. Move the mouse a bit. Release the button. You have just dragged the whole 2D world. Scroll the mouse wheel to zoom. '''You can now navigate the 2D view.'''<br /> <br /> By the way: When you draw a brush, you obviously control its dimensions in both directions, but what about the third? NetRadiant will make the brush as thick as the gridsize is set - unless your work area (the one we made visible via menu &quot;view&quot;, submenu &quot;show&quot;) says different. So, the last thing you had selected (even if it is now deselected) decides how thick your brush will be. You can of course change the size of a brush afterwards, but now that you know this, you'll some day begin to take this effect into account.<br /> <br /> On the right side, you should see a big gray empty space. That's the 3D view. This one is a bit tricky. I hope you have deactivated the far clip plane in the preferences (&quot;camera&quot;) as I've said. Otherwise, the next steps might take you too far away from the box you just drew, and so you would not get to see it. Right click in the 3D view, and release the mouse button. The mouse cursor should have vanished. When you do that again, the mouse pointer returns to normal. With the mouse pointer locked into the 3D view, press the downwards arrow on your keyboard for about one second. After that, move the mouse around in all directions. If you have done everything as I said, you will find an ugly pink box. Congratulations! You've just discovered the world of the mapper: Ugly pink boxes. Much of the mapping process will take place in your head, not in front of your eyes. Experiment with the arrow keys, the mouse movements, the CTRL and SHIFT key, and the mouse wheel in the 3D view. '''You can now navigate the 3D view.'''<br /> <br /> Time for a few keyboard shortcuts:<br /> <br /> Press the ESC key. The box should now look different in the 3D and 2D view because it is no longer selected. In later situations, you'll have to press the ESC key several times in a row to '''deselect stuff''' because some selection modes go deeper into the structure, and every ESC press takes you a step back until everything is harmlessly unselected. And then it looks like it does now.<br /> <br /> To '''select the box''' again, click on it in the 3D view while holding SHIFT. Most of the time, you will select stuff in the 3D view because it's a pain in the ass to do so in the 2D view. NetRadiant still needs much work. Why they didn't include a box selection mode that only selects stuff that completely fits into the box is beyond me. Don't they use their own software?<br /> <br /> Now that the box is selected again, press the BACKSPACE key. You know, the big leftward arrow above the return key. Whoops, '''box deleted'''. Select &quot;'''undo'''&quot; from the &quot;edit&quot; menu or press CTRL+z to get it back again.<br /> <br /> We will now apply a texture to one of the sides of the box. Well, it already has a texture - the name is '''&quot;Caulk&quot;, that's the most important texture of all''', really. You should have this texture applied to every surface that the player cannot see. So, it's best to start with all-Caulk'd surfaces, and whenever you're working on stuff, keep in mind that every unused surface should be returned to Caulk. This is not a ''must''. But you'll bite your own ass one day if you want to squeeze all possible FPS out of your map, so you'll want to Caulk everything, but didn't take care all the time to prevent unnecessary textures. I've been there.<br /> <br /> Press ESC to deselect the box. Now click on it in 3D, but this time, hold SHIFT and CTRL. '''You just selected a surface.''' The texture browser is right under the 3D view. Doubleclick on &quot;arachnid2&quot;, wait till all textures are loaded, then click on the first texture that you can see: &quot;001metal&quot;. Yay, '''you painted the surface'''. The texture in the texture browser does have a red border now. This means that this is the current texture. Without changing the preferences to &quot;new brushes have Caulk&quot;, every new brush you make would have the red bordered texture. But believe me that you'll later find out yourself that you don't want to go that way. Next to the big texture with the red border, there is &quot;arach_fog_s&quot;, a '''texture with a white border'''. Textures with white borders are [[shader]] textures. Shader textures are not just images, they can even have functions, for example they decide whether a brush textured with them is made of water that you can swim in - or slime/lava that kills you.<br /> <br /> Remember the folders you made in the &quot;base&quot; folder? The pictures you see in the texture browser are stored in the folder &quot;textures&quot; or in one of its many virtual versions - I am speaking of the texture folders in all those .pk3 files. They are treated as if they were really existing folders/files. Which means that it's easy to have a file with the same path and file name existing several times, something impossible in the normal file system (may I remind you that I speak from the Windows perspective). '''You should read the [[.pk3]] article''' because it contains important information on how to deal with this. It's really tricky, and you don't want to go through the process of finding out the hard way. Things that can happen if you fail here: Your map can cause other maps to malfunction. Or your map will be incompatible with older versions of itself. Or it will not function the way it did on your computer. By the way - if you wonder where the textures of all those maps you might have downloaded and played until now are: On my machine (Windows), I have ''several'' &quot;base&quot; folders. One is somewhere in the system user area. If you want to use the textures of those maps, too, move them into the &quot;base&quot; folder where the program is installed. And no, you don't have to unpack the .pk3 files to use their contents in NetRadiant. But if you're a mapping beginner, you shouldn't have other files in your installation &quot;base&quot; folder than the ones that actually came with the Tremulous installation (and the Radiant Tremulous support file). Reason: Later, you'll make a .pk3 release pack, and you have to put all files into it that people will not have from the default installation, so have fun figuring those out when your &quot;base&quot; folder is polluted and you're a beginner.<br /> <br /> In the beginning, you will probably use the textures/shaders/sounds etc. that are part of the original Tremulous 1.1.0 pack. '''You don't have to deliver Tremulous 1.1.0 standard files with your map''' because you can assume that everyone has those. I don't know about the Tremulous 1.2 world that is about to emerge, though. But until now, it's the right way to go, and many people have done so. It's accepted. It keeps your map file small. And it means less file- and folder-hassle for you.<br /> <br /> '''Let's save the map.''' NetRadiant doesn't know a name yet, so it will show you a box where you can enter a name. The folder (&quot;maps&quot;) should already be set. Or did you forget to make the folder? You can leave the name &quot;unnamed&quot;, I mean, why call it &quot;terror castle zero&quot; when you don't even know how to make one. From now on, you can just press CTRL+s to save the map. And from time to time, go to the folder window (outside NetRadiant) and '''make a backup of the map file''' (e.g. by copying and pasting it into the same place). Too much garbage in the folder? Learn to live with it. You don't want to live with lost data. '''Maps can get broken in weird ways.''' If you know how to debug them, good. Otherwise, go to an older version and start over. Example: Maybe you know that a map file is just a human readable text that you can open in any text editor. If you open a more complex map, you'll see that it only consists of [[entity|entities]] which in turn sometimes have parameters and/or brushes. Now, one of the bad things that can happen (because NetRadiant is really just a rudimentary editor that allows to make maps but which is really far from being a reliable pro tool) is that an entity that needs brushes (as for example a door - the brush(es) are the moving door) loses all of them. Such a map would not run in Tremulous. To fix such a situation, you would have to use a text editor, locate the erroneous entity and fix or delete it (which is not hard but also not for beginners). Or you'd go back to a previous map version. And no matter how experienced you'll be one day, there will sometimes be problems that you cannot fix. For example: I had a map once with one telenode. The Tremulous client, though, behaved as if there were two. But there was only one. That's easy to verify because the node can be searched for in the text file. I even searched in the compiled map: Only one telenode. Well, the system is not free from bugs, and this is what can happen. Because I was already so far into the map, I had to test-delete many brushes, compile, run - still one telenode too many. Again. And so forth. After a day, the problem was fixed even though the elements that I finally found out to delete and remake didn't have anything to do with the telenode and also didn't seem broken. Also, the telenode problem was absent in some of my delete runs - even though it was different stuff that I had deleted.<br /> <br /> Another word on backups: If you're not a total computer noob, you use archiving software from time to time. But &quot;ZIP&quot; is not the archive format of choice (except of course to make .pk3 files, those have to be ZIP, but you can create that with other archivers, too). [http://www.win-rar.com/downloadnow.html RAR] is very good (but not free, so there's a nag screen or you have to pay). But the best one currently (even though it doesn't support recovery records - haven't really needed those till today, anyway) is [http://www.7-zip.org/ 7z], and it's free. There are also versions for Linux etc. (search yourself). So, why do I mention all this? Well, if you have a bunch of backup copies of your map file (which will eventually outgrow the 1 mb limit, can even reach 20 mb), you'll quickly have tons of &quot;wasted&quot; space. But don't delete the backups if you're not absolutely perfectly sure that you won't need them any more! Just compress them. They compress very well, to about a 10th of their size. And if you use a ''modern'' archiver instead of ZIP when compressing like 20 backups into one archive, the archiver will not just squeeze down every map backup individually, but it will take into account that most parts of the files are equal. That's called a &quot;solid archive&quot;. Unpacking stuff out of them is a bit annoying because oftentimes, the whole archive has to be calculated through for one file. But who cares. So: Just pack all your backups into one archive from time to time. Instead of 100 mb &quot;wasted&quot; space, you'll only have like 1 mb! And you will have all backups of your map! I do it like this for every map individually: &quot;backups till 2010-06-29.7z&quot; and so forth. Makes you sleep better.<br /> <br /> The last word on backups: It's not enough to just backup the map onto the same machine. That is only for the work process in case something gets broken or you need to copy an object from an earlier version that doesn't exist in the current one. No, you also need to backup your files from your PC to another medium. That doesn't really belong into this article because every serious computer user should do that from time to time anyway. But I'd like to mention that here. What I do (apart from backing up my whole machine onto extra harddisks that I then put away somewhere from time to time): I have all mapping relevant files in the Tremulous install folder. And so, I just make a 7z archive of the whole folder tree once a week or so, and I copy it onto a USB stick. I don't know how reliable those are, but my experiences have been good so far. You'll sleep better if you know that the hundreds of mapping hours are safe somewhere.<br /> <br /> Let's go back to our brush. Press ESC to deselect the surface. Then SHIFT and left-click the brush to '''select it in the 2D view'''. Yes, in the 2D view. You can also hold SHIFT and the left mouse button, drag a box that touches the brush you made, and release both. That's the '''box selection'''. Another thing you can do (but you can't really test now because you only have one element in your map) is to SHIFT and left-click in the 2D view and also hold the ALT key. This selects one of the things that are in the position that you click at, just as the normal SHIFT and left-click does. But if you do this several times, the first selection is deselected, and something else in the same place is selected instead. Very useful function to '''toggle through all the stuff in that place.''' Less useful is the fact that it is buggy - sometimes, you have to move the mouse a bit to make the program allow you to use this function again. Box-selection (SHIFT and left-click, drag, release) is also possible in the 3D view (also the SHIFT-ALT-click toggle-through-stuff function), and only the elements currently in view will be selected - so you'll probably enable far-clip-plane from time to time (preferences, &quot;camera&quot;), adjust its distance (menu &quot;view&quot;, submenu &quot;camera&quot;), enabling you to easily select a group of objects (for example a truckload of lights that you used to slightly paint the light situation without people noticing) in front of you while the things behind them are too far away to be visible or get selected.<br /> <br /> If you have a look at the menu &quot;view&quot;, submenu &quot;filter&quot;, you see that you can '''filter''' the 2D and 3D view for the many different kinds of things and thing-groups that a map can consist of. This will be very useful for selecting. And for not getting distracted/confused. Also, displaying the graphics in the editor is faster if less stuff is being drawn, obviously. If you see anything in the filter list activated right now, select the lowest point &quot;reset filters&quot; which will turn everything off - so that you can see everything that exists in the 2D and 3D view. Another way of '''making stuff temporarily invisible''' is the '''hide function'''. Make sure your brush is selected. Then press the &quot;h&quot; key. Bang, it's gone. You can hide all kinds of elements. If you want everything to be visible again, press SHIFT &quot;h&quot;. Filters and hide have no influence on the map functionality, they are not even stored in the map file. When you close NetRadiant and open it again, the previous filter settings are still active which can be confusing at times. The hidden stuff, though, is visible again. By the way: Did you notice the - - - - - line at the top of the menu? If you click that, the menu will be opened in a window that does not go away when you select something in it. Very useful.<br /> <br /> Another very important function that can be toggled on and off is the &quot;'''texture lock'''&quot; function. There is a button with a lock picture for that somewhere at the top right of the screen. When it's active, it should actually blink and play a loud HONK!-sound all the time or something. And when NetRadiant is closed and opened again, it should be deactivated. But all of this does not happen. So, '''you have to take care whether or not the texture lock function is activated'''. Here is what it does: When it's not on, the textures on a brush seem to scroll around when you move the brush around. That is because the textures are normally locked to the world position. This is very practical, as you will find out with time. Now, the &quot;texture lock&quot; function changes that: When you drag a brush while that function is activated, the textures of the brush will move with it. That is very useful in cases where you have made a brush or several brushes with specific texture work (for example light fixtures), and you want to move those brushes without the design to change. Be aware whether or not the function is activated. You will remember this text here for sure. Because you will at some point see textures in wrong positions, realizing: &quot;Damn, I moved brushes around with texture lock on! Why isn't that function automatically turned off when I start the program?&quot; The texture lock function also changes the behavior of textures when you use the rotate-brush-by-90-degrees function.<br /> <br /> Remember when I called your brush a floor or ceiling? That's because the 2D view shows a view from the top (or bottom, depends on how you think) on the map when the program opens. Press CTRL and TAB. If nothing weird is going on with your input focus and keyboard (which can happen from time to time), the '''2D view was just switched from &quot;top view&quot; to &quot;side view 1&quot;'''. Do that again, and it changes to &quot;side view 2&quot;. Once again, and you're back at &quot;top view&quot;. You can determine what view you're currently on by looking at the little right angle labeled &quot;z&quot; and &quot;y&quot; or &quot;x&quot; and &quot;y&quot;, you get the picture. You'll probably determine that later by rather looking at the map, though. It's helpful/important to learn that the vertical axis is the Z axis. If you can currently see the X and Y axis, you're looking along the Z-axis (meaning: from the top).<br /> <br /> Now, let's finally get to '''how to move and scale a brush:''' Make sure the brush is selected. In the 2D or 3D view, click on the brush, hold the button, move the mouse, release the button. You just moved the brush (if the grid versus the amount of mouse movement didn't prevent this). Moving it in the 2D view makes sure that it is not moved along the axis that is pointing directly towards you. Moving it in the 3D view is comfortable, but can have unwanted results because of the fact that the camera is &quot;never&quot; perfectly aligned with the three space axes. To scale the brush instead of moving it, do the same, but don't click inside of it. Instead, click beside it. Important: Don't scale it too small so that it vanished. I have no idea what happens then. I always hit &quot;undo&quot; in such a situation. Might be a map-breaker.<br /> <br /> '''The grid''' is very important. In most cases, brushes should be perfectly aligned with grid points. Otherwise, have fun debugging your map. To '''change the grid scale''', press one of the number keys from 1 to 9. You can also do that in the grid menu. You'll do that from time to time, because, believe it or not, the grid spacings below 1 are actually used sometimes. The current grid spacing can be seen at the bottom of the NetRadiant window, on the right side. Careful with the key &quot;0&quot;: It toggles the grid from visible to invisible (and back). On a side note: I hope that the NetRadiant developers will be nice and implement a feature that draws the grid with thicker lines (e.g. 3 instead of 1 pixel) because it's simply invisible with all the stuff in front of it on more complex maps, and that sucks considerably.<br /> <br /> '''A word about world units / grid size / reactor and overmind etc.:''' It will take a while until you have memorized all the building and player sizes. Until then, just memorize this: An opening or room with the size '''128x128x128''' (second largest grid setting (&quot;8&quot;)) is just high and certainly wide enough to contain the overmind or reactor (112 would be enough). Tyrants etc. fit through nicely (96 would be enough). Those numbers might not really tell you anything, but any long-time computer user knows the drill: 1 2 4 8 16 32 64 128 256 512 1024 2048 4096 8192 16384 32768 65536 ... You should know those numbers up to 256 to be more efficient with NetRadiant. And 96 is three elements of the size 32, '''96 is just high enough for a tyrant''' to get through. '''64x64x64''' is big enough for a dragoon. A human can still crawl through a height of 32, if I am not mistaken. '''If you want to make a stair, 16 is a nice step height.''' Though 16 might seem a bit big on closer inspection since it's theoretically half a meter.<br /> <br /> Make sure that your brush is selected. Then, press CTRL and C, then CTRL and V, or use the &quot;edit&quot; menu. The '''brush exists now twice in the same place''', a common error that can cause weird map behavior, yet a situation that you will intentionally create many many times, because it's often useful to take an existing brush and copy/paste it somewhere else. At this point I should remind you: Keep everything Caulk'd that cannot be seen by the player. Ok, now press ESC. Yes, keep the two brushes in the one place for now.<br /> <br /> Travel to the side of the brush that shows the &quot;001metal&quot; surface. Select it (SHIFT CTRL left-click). Now go to another texture section. Not &quot;arachnid2&quot; but instead &quot;common&quot;. Most of the '''textures in the &quot;common&quot; group''' are actually shaders, as you know already because you saw the white borders around them. The one called &quot;caulk&quot; is among the first. It should have a green border because the currently open map uses it in at least one place. Click on &quot;caulk&quot;. This applies the caulk shader to the surface you selected. It also gets the red border because it's now the current texture, which is unimportant to us because all our new brushes have caulk, not the current texture. The &quot;common&quot; textures are really useful. There is, for example, a shader called &quot;ladder&quot;. Any vertical surface that you apply this texture to can be climbed. It's really that simple. Well, to make an actual ladder, build something that looks like it can be climbed, then make a brush with the ladder shader around / in front of it. The ladder shader is invisible, but you can't walk though it. There is also a texture called &quot;clip&quot; which you'd sometimes use to invisibly even out too odd wall and floor situations. The dretches will thank you. The players who don't get stuck while running away from the beasts will thank you, too. Some of the textures/shaders of the &quot;common&quot; section can be used without you having to distribute these shaders with your map (like for example the &quot;caulk&quot;, &quot;ladder&quot; and &quot;clip&quot; shaders), but it's best to just add these few bytes to your map file. Better safe than sorry. Ironically, the &quot;invisible&quot; shader, for example, would cause '''&quot;missing texture&quot; optics''' (Missing textures in the game are gray with a big white grid. Hard to miss. Easy to miss, though, if your testing environment is improper, because then you'll not have missing textures, but the players will.) if the Radiant Tremulous support files are not present, so put them into the release file. A .pk3 without those shaders will of course work on your machine - because you have the &quot;data-radiant-1.1.0.pk3&quot; in your &quot;base&quot; folder! Others do not have this.<br /> <br /> '''Get to know the phenomenon called [[Z-fight]] (or Z-fighting):''' Press ESC to deselect. Now, select &quot;the&quot; brush (doesn't matter which one, but just one of them, Wassily), so SHIFT left-click on it. Now for the important part: Move the brush a bit. Not too much. You'll see that the copy (or the original, you never know which one you'll click if there are several in one place) is revealed by you moving the other one. Don't move it too far - they should still overlap. Now, study the area in which the textured face of the one brush and the Caulk'd face of the other brush are drawn in the same place. Move the camera around a bit. If you've done everything right, then you are just observing a Z-fight. Two surfaces want to have the same distance from the observer and fight about it. No one wins, especially not the spectator/player. For historical reasons, the distance an object has from the camera is called the z-distance. You could also read up on the term &quot;[[Z-buffer]]&quot;.<br /> <br /> It is very probable that you will get to see Z-fighting somewhere during one of your many testruns of your maps. You can even find those in finished maps that can be found on many servers. I can remember at least one z-fight in a professional map that came with Tremulous 1.1.0 ([[Nexus6]]). Ironically, right now, there is nothing wrong about your map in that regard. Because one of the two surfaces that are fighting has the Caulk shader - which is defined to be invisible. There would be no z-fighting in your map right now.<br /> <br /> '''Mirroring and rotating:''' Select one of the brushes and toy around with the 6 buttons at the top left of the NetRadiant window. The first one is &quot;x|x&quot; and mirrors the brush along the x axis. I find it irritating that the Radiant developers chose to mirror the brush ''along'' the x axis instead of using the x axis as the, well, mirror axis, but you'll get used to that. The button next to that is the rotate-around-x-axis button, and that actually works like you'd expect it. Depending on the grid-versus-brush situation, the position of the brush gets changed accordingly, too, so later, you'll adjust the grid spacing before rotating a brush around 90 degrees. Mirroring does not care about the grid, just about where the brush begins/ends. If the &quot;texture lock&quot; is active, the textures get rotated and mirrored accordingly. Nice one. But if you rotate a brush using &quot;arbitrary rotation&quot; (menu &quot;modify&quot;), the textures will not be rotated with it, no matter if the &quot;texture lock&quot; was active or not. &quot;arbitrary scale&quot; (same menu), though, scales the textures (if &quot;texture lock&quot; is on).<br /> <br /> Left of the &quot;texture lock&quot; button, there is another (currently selected) button with a rectangle inside of it. If you hover your mouse above it, it'll say &quot;Resize (Q)&quot;. That's your normal brush draw/move/resize tool. Two buttons to the left, there is the &quot;Rotate (R)&quot; tool. Select it and rotate your brush a bit. This is the same as &quot;arbitrary rotation&quot;, only it's handled with the mouse instead of numbers. Don't forget to switch back to &quot;Resize&quot;.<br /> <br /> Now a quick tour of '''dealing with entities''': In the &quot;view&quot; menu, select &quot;entity inspector&quot; (or press &quot;n&quot;). There are several sections in that new window that appeared, and you might have to vertically scale those sections a bit before use. The most important area in that window is the one saying &quot;classname worldspawn&quot;. If there is no such text visible, you probably don't have a brush selected at the moment. Select one (or several, doesn't matter now). If there's still no text &quot;classname worldspawn&quot; in the window, you have to scale and move stuff in the window around a bit. The &quot;most important area&quot; with said text is not the lowest part of the window, but it's the lowest big white box in the entity inspector. Once you've found it, click on the text &quot;classname worldspawn&quot;. You'll see that, once you've selected it, the text &quot;classname&quot; appears below the area in a textbox labeled &quot;key&quot;, &quot;worldspawn&quot; in the &quot;value&quot; box. The '''key-value-principle''' is very important. The area in which you selected the key-value-pair will later have more key-value-pairs. These are the properties of the entity that you've currently selected. Wait, a brush is an entity? Well, if you deselect the brushes with ESC, &quot;classname worldspawn&quot; is no longer visible in the entity inspector window (only as a relict in the &quot;key&quot; and &quot;value&quot; input text boxes). So, every brush is an entity with the text &quot;classname&quot; in it? No. All brushes are one combined entity. The entity's name (And it's better to think of this as a type, not as a name. Later, you will have several entities with &quot;classname&quot; &quot;light&quot;, so it's obviously not just a name but really a type.) is &quot;[[worldspawn]]&quot;, a term mappers toss around oftentimes. Every map has min. and max. one worldspawn. It's the first entity in the .map file (if you look at it with a simple text editor.) The worldspawn can have very important settings regarding the map, for example the amount of buildpoints the teams have, or you can add a little message that is displayed while the map loads. The text area above the &quot;most important area&quot; describes which keys and values can be used for the world spawn. Once you select a different type of entity in the 2D or 3D view (or in the area at the top of the entity inspector, where all possible entity types are listed), the help text changes.<br /> <br /> When dealing with the entity inspector, be careful what you have selected in the map. It's possible to select a brush (usually part of the one &quot;worldspawn&quot; entity) and another entity type, for example a &quot;light&quot;. This flexibility can be useful, but if used improperly, it's a big source for errors. '''Always be aware of what's selected before using any function.'''<br /> <br /> Now, let's use an entity we haven't used before: Select one (or all) of the brushes. Then, right-click in the 2D view. A menu should appear. If it didn't, try again without moving the mouse even the slightest bit. In the menu, go to the item &quot;info&quot;, and from the new submenu, select &quot;info_player_intermission&quot;. This creates a little box of that entity type. Also, the brush(es) that were selected have gone, replaced by the new entity. You better undo that and remember this effect for later, because if you're dealing with a somehow broken map later, it might have been caused by the action that was just demonstrated. But everything should be fine if you use &quot;undo&quot; on such an action. Ok, now press ESC to deselect everything, and then create the entity anew. What is it good for? Well, it defines the position and orientation of the spectator camera when you enter a map or leave a team. '''The &quot;info_player_intermission&quot; entity is absolutely essential. Without it, a map does not work in Tremulous!''' The &quot;info_alien_intermission&quot; and &quot;info_human_intermission&quot; entities have a similar function (camera position and orientation when you're on a team and are currently not alive), but they are not technically necessary. You'll of course place them when you're making a real map.<br /> <br /> You can use the &quot;arbitrary rotation&quot; or the mouse rotate tool to change the direction into which the player_intermission camera is facing.<br /> <br /> Man, I almost forgot THE LOG. Move the mouse to the bottom of the window directly above the status line (that's the area with several texts and horizontal segments). There should be a handle looking like ............ Click and drag it up. You should now see the log. Sadly, you'll have to do that again next time the program is opened. The log shows the actions the program performs (and errors that happened). Have an eye on the log when you map, it'll save you a few map-repair-sessions because you'll see that something you wanted to do didn't work out, or something was done that you didn't expect and so forth.<br /> <br /> There are more NetRadiant explanations in the other sections of this mapping crash course.<br /> <br /> ==making your first (ultra basic) map==<br /> <br /> ===create the map===<br /> <br /> Now that you know how to handle the most important functions of NetRadiant, let's make a map, violating all rules, offending all experienced mappers. In the &quot;file&quot; menu, select &quot;new map&quot;. If a window appears asking you if you want to save the current map, you're doing it wrong because you should have saved the map already a few times with at least one or two backups. Ok, it's a worthless map that you wouldn't really save or backup often, but I want to give you an idea of how to deal with a real map.<br /> <br /> Press CTRL and TAB until the 2D view shows the X and Y axes, so you're '''looking from the top. Press the key &quot;9&quot; to have the largest grid spacing.''' If the grid is invisible, press &quot;0&quot;. If that doesn't make the grid visible, then it probably was not invisible before but just too big for your current zoom (use mouse wheel and maybe &quot;0&quot;). Read on once the grid is visible and also on its largest setting (displaying &quot;G:256&quot; at the bottom of the window).<br /> <br /> '''Create a brush in the 2D view, exactly one grid block in size.''' The numbers on its right and bottom size read &quot;256&quot; if you've done it right. Assuming that 32 world units are one meter, this brush is a nice 8 by 8 meters floor. Which is also 8 meters thick, by the way. But who cares. It's not like we're wasting concrete or something.<br /> <br /> The brush is pink, yes? Otherwise, shame on you. Now, move the camera in the 3D view so that you can see the top of the brush. Select the top face (CTRL SHIFT left-click, don't just SHIFT left-click it or you'll select the whole thing). Go to the &quot;arachnid2&quot; texture section and click the first texture (&quot;001metal&quot;). '''The top surface now has this texture.'''<br /> <br /> Press ESC to deselect everything. Then right click in the 2D view, and select &quot;team_human_spawn&quot; from it. Press ESC again, call the menu again, and select &quot;team_alien_spawn&quot;. Press ESC again, call the menu again, and select &quot;team_player_intermission&quot;. Great! '''Now you have all the three essential elements''' that you need to have a working Tremulous map. But there is a problem: '''If the spawns are not in a proper place''', they might not get created when the map loads. So, move the egg and the node around until they stand somewhere on the box. Make sure that there is enough distance between the two. Also, have a look at them from the side: They must not be too close to the surface of the box or they will not get created when the map loads. You can really place them quite high (Be reasonable.) above the surface. When the map loads, they will be created in that spot and then fall down to the surface (without taking damage). To move the entities around, you have to set the grid to a higher resolution. Just blindly hit one of the left digit keys for a high resolution, which one doesn't matter at the moment. By the way: Too many people ''in the game'' fail to place the spawns in the right rotation. It's easy: The player will spawn to face the position from which you made the spawn. Makes sense: That position can be assumed to be a valid place to go. Making spawns in the right rotation can influence the game flow positively.<br /> <br /> Please check if the surface on which you are trying to put the spawns is the one you have textured. If not, then you did something wrong earlier when texturing it. Spawns cannot be rotated in the editor in the way that they can be put on walls or something, so it's not the spawns that are wrong. By the way, you can '''rotate the spawns''' around the high axis (Z) to define the direction into which the player will look when he spawns. The human spawn, at least the one in the editor, has the aparatus-thingy on the side into which you will spawn. The egg spawns you into the direction the red axis at the egg's center points. The human spawn does so, too, but the aparatus-thingy is easier to see.<br /> <br /> Ok, we have a floor with a texture, both teams have a spawn, and the player_intermission camera does also exist (maybe you want to move and rotate it around a bit until it will probably show something meaningful, but it's not necessary for the map to run).<br /> <br /> What's missing? Light! ESC, 2D, rightclick, '''select &quot;light&quot;'''. A text box appears. Make sure that the number inside of it is &quot;100&quot;. That's the brightness of the light. Click ok or press RETURN. Pressing RETURN is not always advised: The &quot;arbitrary rotation&quot; dialog, for example, will not do anything then. Now move the point light you created until it is in the middle above the box brush. For that, press &quot;8&quot; to set the grid to the second largest spacing. Now it's easy to move the light to the middle. Seen from the top, it must be in the middle. Seen from the side, it must be one grid step above the floor. With setting &quot;8&quot;, that's 128 world units - 4 meters.<br /> <br /> ===build the BSP file and run it===<br /> <br /> If you have not yet saved the map, shame on you. Also, do it now. The name should be &quot;unnamed&quot;. Then, close NetRadiant. '''Because now we'll play the map!'''<br /> <br /> If you're a lucky Windows user, you'll have downloaded and configured q3map2build, I hope. Start that program, select the map &quot;base\maps\unnamed.map&quot; that you've just created, make sure that &quot;Play after build&quot; (left border of the window) is activated - and then click &quot;build&quot;!<br /> <br /> Alternatively, if you are not using this nice frontent for q3map2, you can create a batch file. The program does nothing different, only it's more comfy, and the texts displayed when you hover the mouse above the many switches certainly make things more clear. So, if you don't use the program, create a batch file. That's a normal text file with commands in it that has to be renamed to &quot;somethingsomething.bat&quot;. Sadly, those mega-idiots at Microsoft chose to hide file extensions (stuff like &quot;.bat&quot;) by default, so you can't rename the whole file name, only everything except the extension. For this reason and overall security improvement, Windows users are urged to turn the display of file extensions on. In any file explorer window, go to the &quot;Tools&quot; menu, select &quot;Folder Options&quot;. At the top of that new window, click on &quot;View&quot; and then scroll down until you see the option &quot;Hide extensions for known file types&quot;. Turn it off and click &quot;Ok&quot; at the bottom of the window.<br /> <br /> Here's the text for the batch file:<br /> <br /> &quot;C:\Program Files\netradiant-20100214-win32\q3map2.exe&quot; -fs_basepath &quot;C:\Program Files\Tremulous&quot; -fs_game &quot;base&quot; -custinfoparms -info -meta -patchmeta &quot;C:\Program Files\Tremulous\base\maps\unnamed.map&quot;<br /> &quot;C:\Program Files\netradiant-20100214-win32\q3map2.exe&quot; -fs_basepath &quot;C:\Program Files\Tremulous&quot; -fs_game &quot;base&quot; -vis -saveprt &quot;C:\Program Files\Tremulous\base\maps\unnamed.map&quot;<br /> &quot;C:\Program Files\netradiant-20100214-win32\q3map2.exe&quot; -fs_basepath &quot;C:\Program Files\Tremulous&quot; -fs_game &quot;base&quot; -light -bouncegrid -custinfoparms -filter -patchshadows -bounce 500 -bouncescale 2 &quot;C:\Program Files\Tremulous\base\maps\unnamed.map&quot;<br /> Pause<br /> &quot;C:\Program Files\Tremulous\tremulous.exe&quot; +set fs_basepath &quot;C:\Program Files\Tremulous&quot; +set fs_game base +devmap &quot;unnamed&quot;<br /> <br /> The line &quot;Pause&quot; is not necessary, though it can be useful to have the process wait between calculating and playing. q3map2build has options to insert &quot;pause&quot;, too. I once had the computer calculate a map for four days in a row, and I had &quot;Play after build&quot; unchecked because why should I &quot;burn&quot; my machine uselessly? This means that after calculating, the machine would just have closed the system's console text box without me being able to read the text. This makes the &quot;pause&quot; feature seem much less superfluous all of a sudden. Of course I could have saved the console output into files automatically (by adding &quot; &gt; outputtext1.txt&quot; to the end of the first line, and bla 2 3 4 to the other lines), but then again I wouldn't have been able to have a look at the console text because it would just have been in the files.<br /> <br /> You'll probably have to adapt the batch file text to suit your computer/setup.<br /> <br /> Doubleclick the batch file to start the compile.<br /> <br /> One of the things that will appear in the text window (which is the system's console text output) is &quot;LEAKED&quot;. Well, we didn't give the map a proper shell, we just made a floor. Doesn't matter at the moment, but later, we'll have to improve on that.<br /> <br /> Well. If everything went right, you're playing the smallest map in the world. And everything around your little world is pitch black. Or you see the [[hall of mirrors]] effect around you, really annoying. But it's a working Tremulous map!<br /> <br /> I bet you want to experiment now. Do that. But don't yet make a big map that kinda asks to be published, people are probably not going to like it. You have to learn some more first.<br /> <br /> <br /> <br /> <br /> <br /> ==making your second (more advanced) map==<br /> <br /> ===choose a name===<br /> <br /> You can freely create folders in the &quot;map&quot; folder, doesn't hurt the game system. So, you should make a folder and throw all files into it that have been created so far.<br /> <br /> Now, open NetRadiant (or select &quot;new map&quot; from the &quot;file&quot; menu if it was already open). Save this empty map. Reason: '''We want to give it a name.''' Press CTRL and S (or select &quot;save&quot; or &quot;save as&quot; from the file menu). The name shall be ... wait, what's your nick name? The name you use as a player or in the forums? If it were &quot;God, maker of the world&quot; (which is my nick name), we could make a short version of that, for example &quot;gmotw&quot;. Let's assume that your nick name is &quot;scrollbar5&quot;. A shorter version would be &quot;scr5&quot; or something. Let's stick to that. Back to naming the map: Please save it as &quot;scr5_dretchnest&quot;. If you actually have a nick name that you want to stick to and that can be nicely expressed with a few letters, use that from now on. I'll keep calling it &quot;scr5_...&quot;.<br /> <br /> You see where I'm heading. I called my first map [[Gmotw_Skybox|&quot;gmotw_skybox&quot;]], and this is not mainly about people attributing the map to my person (or so that all my maps would be in one alphabetical place in the huge map repositories that exist, hehehe) but instead so that I could freely choose my map names without having to worry about the name maybe already existing - or someone else taking the same name. I have not yet seen anyone do it like this, but I think this is actually the way it should be done by everyone, and so I tell my helpless scholar prey (Not really.) to do it just like that. '''Add a short version of your nick name with a &quot;_&quot; at the beginning of your map names.''' Keep it short, though. It's good if this prefix &quot;doesn't make sense&quot;, so it's not confused to be a part of the map's real name. So, &quot;gmotw_&quot; (Hey, that's mine.) is better than &quot;stellar_&quot;. By the way, if you look at the screenshot in the skybox article, you read the message &quot;Remove older versions of Skybox to prevent texture problems.&quot; which is really lame. You won't have problems like this since you can read my experiences and conclusions in this mapping guide. Comfy, no?<br /> <br /> If you use these prefixes, by the way, '''NetRadiant will nicely group all your map assets''' in the texture browser instead of spreading them all around the alphabetical map list.<br /> <br /> If you've read the [[.pk3]] article (which you should at some point), you'll already know about the '''filename uniqueness problem''' and about how to deal with it through several release versions of your map. We have halfway solved the uniqueness problem by choosing &quot;scr5_dretchnest&quot; (or whatever your prefix is), which is probably a name not yet taken. Except if 10 people go through with this mapping crash course without choosing a different prefix. But I wonder if anyone's gonna read it at all :/<br /> <br /> A word about &quot;alpha&quot;, &quot;beta&quot;, and &quot;final&quot; releases: BULLSHIT! That was actually just one word. No really: I think it's a meme or an &quot;I'm doing it just like the real guys! I feel like I'm taking a step into a larger world!&quot;-thing that people release their maps as alpha, beta, and final. Well, it has practical reasons, but it also has its problems. To make it short (meaning: I just deleted about 300 words of bla that I was about to save, and that was just the half of it.): Just give your releases a number. So, just add &quot;_001&quot; to the map name. Three digits seems to be much, but you never know. If you increase the release number every time you make a .pk3 and test it with friends or on the server of a guy you know, you'll quickly be above 9, and with all the stuff you have to keep in mind, you don't want to worry about the goddamn number. And once you have chosen to use the path of the &quot;_001&quot;... instead of the &quot;_a01&quot;... &quot;_b01&quot;... &quot;_final&quot;, you'll laugh at all the mappers who have decided to make their maps a &quot;final&quot; too early. &quot;Oh, something's still broken. Damn, already released as 'final'. Can't change it now.&quot; Weird people anyway. I mean, what makes you so sure that you will never add something to the map in a year or so? And then you have the other guys who are more careful. They make their alphas, then you find their betas in the wild... but there is never a &quot;final&quot;. Guess why. The last beta effectively ''is'' the final. Not changed after years. Assimilated by the community. No, you don't want to play that game. '''Just give your releases a number. Just a stupid counter suffix like &quot;_001&quot;.'''<br /> <br /> So, we're about to create a map. The &quot;next&quot; release of it will of course be the first, so its name is &quot;_001&quot;. (I should add that &quot;release&quot; in this context does not mean that you give it to the Mercenaries' Guild Map Repository and brag about it in the forums or something. I am just talking about a proper .pk3 file that you can test on servers.) When people callvote for it, they'd type:<br /> <br /> &quot;/callvote map scr5_dretchnest_001&quot;<br /> <br /> While we're at it: The .pk3 file of this (as can be read in the [[.pk3]] article) would be named<br /> <br /> &quot;map-scr5_dretchnest_001-1.1.0.pk3&quot;<br /> <br /> The name of the .pk3 file has nothing to do with the callvotes. But the name should be kept equal to the real map name for consistency reasons.<br /> <br /> If you're using the batch file solution, please '''edit the batch file just now''' to use &quot;scr5_dretchnest_001&quot; instead of &quot;unnamed&quot;. Reason: So that it hurts if you change the prefix or map name later. Get used to this. Of course, you can theoretically rename a map a hundred times before releasing it the first time, but we want to train here. If you decide to wait with the batch file editing, you're technically making the right choice in case you rename later, but you should experience the name lock, it'll help your mind to get into the real mapper world. Also, all following steps will make use of the map name and cement it some more, and '''you do not want the asset folders and the map to have different names. It's enough hassle as it is, and this would double the file naming work.'''<br /> <br /> By the way, how did I come to the name &quot;dretchnest&quot;? Ok, it's not rocket science, but you'd think that about most map names ''once they exist''. Obviously, I thought of Tremulous elements. What you can do to come up with a map name depends on whether you create it at the beginning, in the middle, or at the end of the mapping process. For example, when I came up with &quot;dretchnest&quot;, I had no idea what exactly the map should be like (other than something with 4 walls that you are supposed to clip diagonally in the corners). I only grabbed a name out of the clouds to complete this section. '''But now that I have a name, it gave me ideas about the map.''' Actually ideas that are ill placed in a beginner's mapping guide, so I'm probably not gonna put them into action here, but here they are: There would be a rectangular (Duh. Beginners always make box maps.) room with a few eggs. The room would be closed from all 6 sides, but there would be openings at the bottom, small enough for dretches to get out. Maybe there would have to be contraptions against crouching humans, maybe that would have to be done by basecamping dretches. If you spawn as granger, you can't get out, so maybe I would have added a trigger that checks if you're granger - and kills you. The ceiling of the room would be something that can be set in motion somehow with a button or by making a building or by reaching a certain spot or by reaching stage 3 etc., and this ceiling would squish the eggs in the room. Since there are no other eggs and grangers cannot get out, the aliens would have lost the game (if the aliens still alive don't win it). This is obviously not a standard Tremulous map, but I digg stuff like this (Trem has enough standard maps, lets bring something new to the table). Read the [[Gmotw_Skybox|skybox]] article if you don't know what I mean. That was my first map, by the way.<br /> <br /> &quot;dretchnest&quot; would have been a fitting name for the above described map. See? '''The name idea resulted in a map idea.''' I believe that it's usually the other way round. But it's improbable that the mapper does not decide for a name until the map is completed, because you'd need to test the map from time to time, and so you'd come up with a name to make a release file. (I repeat: The name you choose once you publish the map should never change, if you can somehow make it so.) Once the name is chosen, the name will probably feedback into the mapping process (e.g. you'd want it to be justified, the least you would do is add fitting decorations).<br /> <br /> '''How you can come up with a map name''': I speak english and german, so when I am thinking about the map that I already created a bit, I think of its prominent building and gameplay elements, enter those terms into a Web translator (like [http://dict.leo.org dict.leo.org]) in english or german, and then I play '''translation ping pong'''. You can also use a Web '''thesaurus''' for that. There are also '''map name generators''' on the Web, probably not Tremulous-specific. You'd rather want to use them for inspiration (and to fuel your translator and thesaurus attempts), not to really make the name for you.<br /> <br /> ===make a shader and a texture===<br /> <br /> Now, go to your Tremulous &quot;base&quot; folder. '''Create a new folder in the folder &quot;textures&quot;.''' Name: &quot;scr5_dretchnest&quot;. Why not &quot;scr5_dretchnest_001&quot;? Because then you'd have to re-assign all textures on every new release because the foldername changes. The project you're working on is &quot;scr5_dretchnest&quot;, and that's the name the asset folders should have. You can also make a folder like this in the &quot;sound&quot; folder, but I currently don't plan on talking about adding a sound. But this is the way it would work for sounds, too.<br /> <br /> If you want to add shaders (which we will do - it's easy if you know how), you have to add the release number again. Reason: The shaders are not several files stored in a new folder, like textures will be. No, the shaders of a map are little text blocks that are all stored in one text file. (You can also make several files, but let's keep this simple.) And '''if you change the contents of the shader file for a new release, you have to give that file a new name.''' Just as if you would have to give a texture a different name that you change from one release to the next. If you don't do this, your map will be incompatible with older versions of itself. You can be lucky with that. But lets do this properly. Use this knowledge. Imagine you had to gather this knowledge by experience which I had to... urgh!<br /> <br /> So, the texture folder is prepared. But '''lets make a shader first.''' Go to your Tremulous &quot;base&quot; folder into the folder &quot;scripts&quot;. Create a new text file called &quot;scr5_dretchnest_001.shader&quot;. If we add a shader into it, it will appear in NetRadiant the next time you start it. Well, you'd think so, but for some reason only the programmers know, you have to add an entry in the &quot;shaderlist.txt&quot; file in the same folder. At the end of that file, add &quot;scr5_dretchnest_001&quot; (without &quot;.shader&quot;), press return, save and close the file. Now open the &quot;scr5_dretchnest_001.shader&quot; file again and put the following text into it, save and close the file:<br /> <br /> textures/scr5_dretchnest/brightglass_001_s<br /> {<br /> qer_editorimage textures/scr5_dretchnest/brightglass_001.jpg<br /> qer_trans .5<br /> surfaceparm trans<br /> surfaceparm solid<br /> cull disable<br /> {<br /> map textures/scr5_dretchnest/brightglass_001.jpg<br /> tcgen environment<br /> blendfunc gl_one gl_one<br /> rgbGen identity<br /> }<br /> {<br /> map $lightmap<br /> blendFunc gl_dst_color gl_src_color<br /> rgbgen identity<br /> }<br /> }<br /> <br /> Close NetRadiant. Open it again and load the empty map file you created. If you look at the texture browser now, you'll see an entry called &quot;scr5&quot;. Now, how did that happen? Oh, the stupid nick name prefix idea! Yes, NetRadiant interprets names with a &quot;_&quot; in it differently. It creates categories. So, all your maps will be under the category &quot;scr5&quot; instead of being spread around like crazy.<br /> <br /> Unfold the category by clicking on the little triangle on its left side. &quot;scr5_dretchnest&quot; appears. It does so for two reasons: 1. You created a folder with that name in the textures folder. 2. You created a shader that in turn created the virtual (= not really existing) file &quot;textures/scr5_dretchnest/brightglass_001_s&quot;, so another reason why NetRadiant would think that the folder exists.<br /> <br /> The texture browser should now show an element called &quot;brightglass_001_s&quot;, something like a blue-black checkerboard, expressing that the image which was to be shown here can not be found. No wonder - we didn't make that one yet. And that's a bit tricky, because I don't intend to explain any graphics software to you now. '''You'll just ''somehow'' have to come up with a .jpg file that has power-of-2 dimensions''' (you know... 1 2 4 8 16 32 64 128 and so forth, computer numbers, as mentioned earlier in this article, though obviously, a texture with ''anything'' on it and the size of 32x32 or smaller hardly makes sense), I'd say 128x128 should be the choice here, that's enough for a simple reflection picture (which this one is). Textures don't have to be quare, by the way, but let's keep this one simple. Also, I think that a texture with an arbitrary size (not power-of-2) would work, too - but what &quot;would work&quot; is not the question. What surely will work in all Tremulous clients and with all graphics cards, that's the question.<br /> <br /> The jpg quality doesn't need to be maximum for a texture. &quot;high&quot; (60) or &quot;very high&quot; (80) (as they are called in Photoshop) is good enough. &quot;medium&quot; is too low in nearly all cases, I'd say. You know what would be nice? An actual screenshot you take yourself in Tremulous. Cropped and sized to 128x128 or bigger, util max. 2048x2048 for a normal texture and, I'd say, max. 512x512 for a reflection texture, but that's plenty. By the way: The bit depth per color channel must be 8, as most existing image files are. You can use 16 and even 32 bit in Photoshop etc., but not in the game. While we're at it: You can also use .tga pictures. If you know when to use gif/png versus jpg, then you know when to use tga versus jpg. Example: If you need a simple color texture (pure red, no other pixels), then .tga is the perfect choice. Tga supports an 8 bit alpha channel (save as 32 bit then, not 24 bit) and also a simple and lossless compression that can be used with Tremulous.<br /> <br /> So, assuming that you have somehow found a suitable .jpg file (.tga (even compressed) would also work, but I think you have to change the shader text then, though I believe that I have seen that the file extension named in the shader is irrelevant, but better safe than sorry), move / rename it to achieve this name: '''&quot;textures/scr5_dretchnest/brightglass_001.jpg&quot;'''.<br /> <br /> Again, close and open NetRadiant and feast your eyes on the new contents of the &quot;scr5_dretchnest&quot; texture browser category. Well, your image should be there now. Twice even. WTF? Well, one instance is from the actual file in the texture folder, and the other one is the shader you created. '''Now you see why the shader ends in &quot;_s&quot;: This prevents the names from colliding.''' (Adding &quot;_s&quot; is the way everyone does it.) See? Naming is a really delicate subject!<br /> <br /> So, before we finally start making the goddamn map, let me explain the shader we've created:<br /> <br /> The first line creates the virtual file by giving it a path and filename. Again, take care of those file names, be they virtual or real. The brackets don't need explanation, I guess.<br /> <br /> The &quot;qer_editorimage&quot; line is irrelevant for the game, but it gives our shader a nice image in NetRadiant. If you apply this shader to a wall, instead of the ugly &quot;no pic!!1&quot; texture, you now see your nice .jpg image. Half transparent even! That is caused by the &quot;qer_trans&quot; line, which is also irrelevant for the game. It's there purely for the editor. And both these lines are not necessary for editing. Later, you can add &quot;//&quot; to the beginning of these two lines, which means that they are &quot;commented out&quot;. Anything behind &quot;//&quot; is arbitrary text until the line ends. I don't know, though, if a comment can be written on the right end of a shader command. If you comment these two lines out later, when you've actually used the shader in the map, and restart NetRadiant, you'll probably realize that they are not technically necessary, but man do you want them to be there.<br /> <br /> &quot;surfaceparm trans&quot; says that the surface is transparent. This does not mean that you can look through it - it only means that ''the computer'' can look through it! Yes, he has to know, too. A later command will make the shader transparent for us humans, too. As the name said: It's a glass shader.<br /> <br /> &quot;surfaceparm solid&quot; says that the surface is solid. You cannot walk/fall/shoot through it.<br /> <br /> &quot;cull disable&quot; means that the opposite side of a brush that is completely painted with this shader will not be invisible, as it would be with a normal texture. &quot;culling&quot; means to temporarily remove elements (objects, faces etc.) that are irrelevant for the current situation. To speed things up. But it is disabled here because it's glass, so you can see the presence/absence of backside faces, so they must be there.<br /> <br /> So far, this was the description of how the surface behaves. I'm not the shader pro, so the following explanations might be a little stumbly.<br /> <br /> The next {}block describes the actual graphics that will be drawn. The {}block after that tells the system to also create a lightmap and overlay it.<br /> <br /> &quot;map textures/scr5_dretchnest/brightglass_001.jpg&quot; obviously makes the shader use your new texture file. &quot;tcgen environment&quot; is short for &quot;TextureCoordinateGeneration&quot; with the parameter &quot;environment&quot;. Man, do I have to explain environment mapping now? In short, this makes the texture appear in a way that is not like a normal 3D shape but instead like it were a reflection in the 3D shape.<br /> <br /> &quot;blendfunc gl_one gl_one&quot; means: The pixels of the source (this shader) will be multiplied by one, then added to the destination pixels (which is whatever's already drawn on screen behind the glass) also multiplied by one. So, this just adds your lightened (Remember that this shader has a lightmap.) environmentmap-glasstexture onto the world graphics. Now you might realize why it's called &quot;brightglass&quot;. If you want something darker, look for &quot;textures/tremor/darkglass3&quot;.<br /> <br /> I don't really know about shaders. I look at how the other guys did it (There are already tons of existing shaders, look in the folder &quot;scripts&quot; in the map .pk3 files.), I read a bit in the shader manual, trial and error testing, etc. For example, I have no idea what &quot;rgbGen identity&quot; really does, but it belongs there. If you want to dive into that yourself, read [http://www.heppler.com/shader/ this comprehensive shader manual]. Also, lets drop the rest of the shader explanation and get into mapping, damned.<br /> <br /> ===start making the map===<br /> <br /> Assuming that you're still in NetRadiant with your named map (that doesn't have any stuff in it) open, set the 2D to view from the top, set the gridsize to &quot;9&quot; (256), and draw a square, 8x8 grid elements in size, so it will be 2048x2048 world units. It's not really important where you do this, but since NetRadiant positions the camera at position 0,0,0 every time you load a map (which can somehow be changed with an entity, but I currently don't remember how, saw it in a decompiled ATCS once), I'd suggest that you draw this brush exactly centered around the coordinate 0,0. After you've done so, press CTRL and TAB to set the 2D to view from the side (doesn't matter which). If the brush isn't exactly one grid block high, drag it smaller so that it is. Then move the whole platform so that its upper side (which is the floor to walk on) is at coordinate 0. Unnecessary to say: The whole thing, every face, should have the Caulk shader, the ugly pink one that you already know.<br /> <br /> Copy and paste the selected brush. Click into it and drag it upwards so that its lower side (which will be the ceiling of the map) is at coordinate 256. That's an 8 meters high map hall.<br /> <br /> Press ESC, then draw a square brush left of the two existing brushes, exactly between them. If you press CTRL and TAB, you see that the depth of this square brush is already as we want it because the last selected brush(es) had this depth. Assuming that you're still in the side view in which you drew the square brush, draw another one, on the right side this time. Did you fall for the &quot;something is currently selected&quot; trap, or did you think of pressing ESC yourself?<br /> <br /> Press CTRL and TAB two times to get back to the top view. Now select the two side walls you made. To do that in the 2D view, it's ok to just use the box select in the currently mostly empty map space that we have. So, press SHIFT and then left-click and drag the mouse to select the unselected wall(s). The ceiling and floor (both visible in one place as a big square) must not be selected now! Once you've done that, copy and paste them, then click on the rotate-90-degrees-Z button (a Z with a blue arrow around 90 degrees of the Z). Now you should have a big room with ceiling, floor, and 4 walls. The wall and floor brushes should be edge-on-edge, that will work properly, don't worry. The brushes must not overlap, though! Admittedly, the walls are a bit thick, but they are the outer map walls, so that doesn't matter. Actually, it's not so bad to have them this thick. Why shouldn't they stand out in the editor as a unique structure.<br /> <br /> If you have done it right (which is more probable with this large grid spacing than it would be with a smaller spacing), you should have a proper shell in which you can go crazy without having to worry about [[leaking]]. The [[void]] is properly locked out. The [[VIS]] calculation can hence be performed. You will not have the [[hall of mirrors]] effect.<br /> <br /> Well, yes, you will have the HOM effect, because everything is still Caulk, but we'll change that now. First, select a proper texture: Select &quot;arachnid2&quot;, then scroll down a bit until you see &quot;cement_1_clean&quot;. Now, select all the 6 surfaces that form the room (CTRL SHIFT left-click, and as a NetRadiant user, you'll have learned to press ESC a few times before this new select action, I guess). Then click on the texture.<br /> <br /> '''Save the map. If this is your first save in this &quot;start making the map&quot; chapter, you're still doing it wrong!''' Also, duplicate the saved map file.<br /> <br /> Actually, the floor and ceiling look just wrong this way. Go to the &quot;karith&quot; texture section, scroll down a bit until you see &quot;cement_3&quot;, select only the floor and ceiling face (Not the whole brush, but I guess I don't have to say that any more.) and apply the texture. Save the map. No new backup this time.<br /> <br /> Nice room. If you fly around in it with your camera, you might get the impression that it's too dark. In that case, open the NetRadiant preferences. Don't worry about a message saying that you'd better save before entering the preferences - in most cases, it doesn't matter. Except that saving is usually fast and in most cases not a problem. And if that dialog appeared just now, you didn't save the map when I said so, sinner! :&gt; Go to the preferences section &quot;display&quot;, subsection &quot;textures&quot;, and set the texture gamma to, let's say, 0.8<br /> <br /> ===about clipping, most underestimated by beginners===<br /> <br /> Assuming that the current situation is the result of your actions in the last chapter, you should still be looking from the top in the 2D view. Gridsize should still be largest (key &quot;9&quot;). Now, draw a new brush, 4 grid elements in size, around the 0,0 coordinate. So, the size should be 512x512. The brush should be inside the map shell room that you built, exactly from floor to ceiling.<br /> <br /> We'll use a little trick now. Set the grid spacing to 32 (key &quot;6&quot;). As I said, 32 is the smallest wall thickness you should use if you want to prevent light bleeding. You can be lucky with smaller values or still unlucky with larger ones, but 32 is a good base to work with. I've read somewhere that a thinner wall risks that objects or players might pass through it when playing on the Internet, but I think that's not true, at least I haven't seen problems like these ''ever'' in the Tremulous world, and there are maps with thinner walls around. Another thing about wall thickness: Even a wall with 64 world units might still let the damage effect of a fully charged [[Lucifer Cannon]] shot through a bit. I wonder how much or how little calculation time / network overhead impact it would have meant to prevent this, because this behavior sucks considerably.<br /> <br /> So, with the grid set to spacing 32 and the new 512x512 brush selected, search for the 5th button right of the 90-degree-Z-rotate button. When you hover over it, it says &quot;Hollow&quot;. Alternatively, go to the &quot;brush&quot; menu, submenu &quot;CSG&quot; and select &quot;Make Hollow&quot;. This function is not widely used, because it motivates box rooms (and other reasons, I guess), but right now it's the best thing in the world because it guarantees that you have a new room with 6 walls, all edges ''overlapping'', wall/ceiling/floor thickness 32. (Side note: Why the &quot;hollow&quot; tool doesn't come with the option to automatically clip the resulting brushes is beyond me.)<br /> <br /> Overlapping brushes should be prevented &quot;at all costs&quot;. We'll do that now, too, which brings us to &quot;clipping&quot;.<br /> <br /> Did I say &quot;save the map&quot;? No, and I won't say that any more.<br /> <br /> While still looking from the top, try to select one of the four walls in the 2D view. It's tricky, isn't it? Now you see why you'll select stuff in the 3D view most of the time. But let's try the 2D view again. Press ESC. Then, box-select the middle part of one of the walls (which will also select other stuff). Then, box-select the center of this new room. Shazam, everything except the wall is deselected. Box-select inverts the current selection where it is in effect. Also, nice that we activated &quot;display size info&quot; in the preferences (&quot;orthographic&quot;) before, because now we can clearly see that all elements of the current selection have the position and size of the wall we wanted - which makes it reasonable to assume that only the wall is selected. Once your maps are a bit more complex, that assumption is not so reasonable. I think that it would save the mappers of the world tons of time if there were a simple but prominent number stating how many elements are currently selected. Well, rudimentary tool, as I said. Instead, you can see how many milliseconds it took the 3D view to redraw.<br /> <br /> Now that one wall is selected, choose a different tool. Currently, the button with the square on it is activated (&quot;Resize (Q)&quot;). Activate the button right from it, the one with the diagonal line (&quot;Clipper (X)&quot;). This tool can be used to cut away parts of brushes or to split them into two brushes. Reminder: The preferences of the &quot;clipper&quot; should be set to &quot;Clipper tool uses caulk&quot;.<br /> <br /> You have to cut away a small diagonal part of the wall in the corner. What we want to achieve is that the four walls do not overlap in the corner but do instead end exactly where the next one begins. Yes, you could just use the resize tool for that, but that's not how a good mapper does it (except when it makes more sense than clipping). Imagine: When the walls are clipped in the way I described it, then not just the outer walls will be perfectly connected, but the inner walls, too. So, when you paint textures on them, you can use the &quot;fit&quot; tool of the &quot;surface inspector&quot; (key &quot;s&quot;) to make the texture fit the wall perfectly while you can mostly forget about all the numbers in that window. Or, if you're dealing with the numbers, you can copy them from other surfaces because the other walls have the same special properties (brush corners clipped).<br /> <br /> Well, if you had drawn the walls edge-on-edge like you did with the outer map walls, painting the inner walls would be exactly as easy as the clipped result will be. But we want to paint the outer walls, too! This will be a room visible from the outside, hence it must be properly built.<br /> <br /> So, let's just try to clip one of the corners of the selected wall now. Choose one end of the wall, then click once on the corner that is outside of the room, then on the one that's inside of the room. Two blue dots (&quot;1&quot; and &quot;2&quot;) should have appeared. The line that connects them should point from the outside room corner to the inside of the room. Also, there is another line (the &quot;perpendicular&quot; or &quot;normal&quot;) beginning at the middle of the clip line. Both lines are not existing objects but just editor tools.<br /> <br /> Press ENTER. So, the brush was divided by that clip line you made, and now one of the two parts of the brush is gone. It's the one that the additional line (the &quot;normal&quot;) went through, that's the rule. Which way the &quot;normal&quot; points depends on the order in which you created the clipper points. Also, you can invert the clipper direction (menu &quot;brush&quot;, submenu &quot;clipper&quot;). Also, the brush part that will stay will have the clip face painted blue in the 3D view (as long as you didn't complete the clip by pressing ENTER).<br /> <br /> Clipper tips: You can drag the clip points around on the 2D view. You can even add a third point. You can change the 2D view from top to side etc. and then still drag the points around. And you cannot remove the clip points by pressing ESC. To remove them, you have to select a different tool (like &quot;resize&quot;) and then switch back to the clipper tool. Or just click again once all 3 clipper points are placed, because that will place number 1 again, removing the other two. Only if you click directly on one of them, you can drag them.<br /> <br /> Very frustrating: While the &quot;undo&quot; can be used to return to the unclipped brush, it does not return you to the situation with existing clipper points, so you have to place them anew.<br /> <br /> Now that you kinda know how to work the clipper tools, clip all 8 wall ends diagonally, so that the walls are perfectly face on face, not overlapping any more. So that the inner walls start and end exactly in the inner room corners.<br /> <br /> Wow, finally done with the stupid clipping. Let's paint and resize a few more blocks, right? No. The clipper tool is one of the most important tools in mapping, and you'll use it much more often than you can imagine right now.<br /> <br /> For example: It's time to clip the ceiling and floor so that they diagonally meet the walls - which, thusly, also have to be clipped. In the end, all 6 walls/floor/ceiling of the little room will be kinda like the bottom ends of pyramids pointing into the room, perfectly face to face which each other. During all this, you should leave the grid spacing on 32.<br /> <br /> Done yet? An experienced mapper needs 1 or 2 minutes to finish this properly.<br /> <br /> You might be wondering why we didn't just delete the ceiling and floor of the little room (after all, there's still the outer map ceiling and floor). Reason one: Using a map shell room like we did is a crutch. Not necessarily a bad one, but also not necessarily the way an experienced mapper does it. Reason two: You'd make yourself dependent on the outer ceiling and floor, and once you get out of the room and map some more, you'll have more dependency-situation-possibilities like this. You don't want to tie it all together and stand in your own way. I had that when making skybox. &quot;Can I texture this wall? No, damned, it's the outer wall again.&quot; Reason three: Lightmaps! I don't know how exactly it is decided how many pixels a lightmap has, but I am pretty sure that a huge brush will have a less high resolution (so, rather stretched) light map. Oh, speaking of which:<br /> <br /> ===_lightmapscale, gridsize, turbo rendering===<br /> <br /> (You can skip this now and go to &quot;enjoy the fruits of the clipping labour&quot;. One day, you should read this, though.)<br /> <br /> I already explained the worldspawn. Press ESC and select any one of the brushes. Since we currently only have simple worldspawn brushes (as opposed to, for example, doors), you could also just box-select a bunch of them. Anyway: Press &quot;n&quot; if the entity inspector was not yet visible. As you know, the second section shows a help text for the currently selected entity type, and since the third section shows &quot;classname worldspawn&quot;, the help text describes the worldspawn. Scroll far down (not to the end) until you see the explanation of &quot;_lightmapscale&quot;. Read it. Then, write &quot;_lightmapscale&quot; and &quot;0.25&quot; into the &quot;key&quot; and &quot;value&quot; textboxes and press RETURN while you're in the value textbox. I thoroughly tested it in a relatively small room: Values smaller than 0.25 don't increase the lightmap resolution any more.<br /> <br /> Setting the lightmapscale to 0.25 will result in a higher lightmap resolution, so you'd have better shadows etc., think of the difference between the thumbnail of a picture and the full size version (only the difference is not that drastic here). The default setting is &quot;1.0&quot; (when the _lightmapscale key is not present). 0.25 also means that the LIGHT phase, in which the lightmaps are calculated, will take much longer. This also means that larger settings than 1 will make it shorter.<br /> <br /> If you've followed this mapping crash course so far, you'll either have prepared q3map2 frontend &quot;q3map2build&quot; or a build batch file, and you will have done so that the light rendering result is very good:<br /> <br /> &quot;fast&quot; is not activated. &quot;bouncescale&quot; is on 2, &quot;bounce&quot; is on 500 (meaning: effectively &quot;6&quot; or something). And to top it off, your map now has the best lightmap scale. The option &quot;filter&quot; is not relevant for the calculation time. It will smooth the resulting lightmap a little so that shadow seams don't look so pixeled. I am not repeating all this from other guides, these are actual experiences that I gathered in many tests over months.<br /> <br /> Now, as long as your map is very small, these settings are ok. Calculation will be done in a few minutes or less than a minute. But once your map is a huge monstrosity, calculation with these settings takes several days on a fast computer. That's still ok as long as you have an extra machine for things like these, but '''here's how you can speed up the rendering like crazy''' (resulting in less good result, of course):<br /> <br /> Add the key &quot;gridsize&quot;, value &quot;1024 1024 1024&quot; to your worldspawn (default would be 64x64x128 as far as I know, and to achieve default, just delete the key again). As far as I know, the gridsize defines the ''volumetric'' lightmap calculation. If you get closer to a bright red spot in the map, your weapon will receive red light. If the gridsize is as coarse as we have set it here, those effects will be less prominent. I could be totally wrong about this. Maybe the gridsize is more about how the raytracing really takes place. In any case: Changing the gridsize has ''huge'' (!) impact on the calculation time. Setting it to this value will make it faster. Deleting the key, so that you're back on the (very good) default value makes it slower. Setting the gridsize to something like 48x48x48 increases the calculation time insanely, and as far as my test results go, it doesn't have any merit. So: For high quality results, you'd use the default setting. For quick and less proper results, you use the 1024 (or an even rougher) one.<br /> <br /> You can also drop the &quot;bouncegrid&quot; option. Bouncegrid means that before every radiosity bounce, the lightgrid (see &quot;gridsize&quot;) is calculated anew, because somethingsomething bounce influence grid somethingbla. Honestly, I didn't test the difference it really makes, but I believe that it's safe to assume that this option increases the light rendering quality even further.<br /> <br /> Change the rendering settings (in &quot;q3map2build&quot; or your batch file) so that the LIGHT phase uses the key &quot;-fast&quot;. This does not change the lighting ''very'' much (but still too much for my taste when I want to make a real proper release), but it insanely reduces calculation time.<br /> <br /> Removing the &quot;bounce&quot; option (&quot;bouncescale&quot; is irrelevant for the time (except in regards of the caused number of iterations) and is bound to &quot;bounce&quot;, so you don't have to touch it here) has strong influence on the lighting. You should try to have a few bounces in your released maps, the light looks considerably more natural. Removing the &quot;bounce&quot; option decreases calculation time, though. Very much even. If the initial pass (not yet bounced) takes 10 seconds, every bounce will also take about 10. If the first took 1 day, guess what. Depending on the bouncescale you used, the amount of bounces will have strong influence on the lighting result. This is something for tweaker guys. Just as the &quot;gamma&quot; option (that I didn't mention yet) in the LIGHT phase is. You should know that these options exist and that it's a good idea to toy with them. Now let's move on.<br /> <br /> Another option that you can add to speed up calculation: &quot;-fast&quot; in the VIS phase. Please don't do this, though, if you want to release the results into the public. And definitely don't release the result if you omit the VIS phase completely - which you can also do to decrease rendering time even more. The VIS phase calculates which spot of the map can be seen from which other spot. This information allows the game engine to draw only the necessary graphics. As far as I know, it also influences the radar functions of helmet and aliens. It's essential for a release, and you should do it without &quot;-fast&quot; for a release.<br /> <br /> '''In short:'''<br /> <br /> '''For fast rendering''', add &quot;-fast&quot; to the VIS phase (or drop it completely), add &quot;-fast&quot; to the LIGHT phase, remove &quot;bounce&quot; from the light phase (or just &quot;bouncegrid&quot;, but I think if you're already doing bounces, you might as well do them properly), remove the &quot;_lightmapscale 0.25&quot; thing from the worldspawn, add &quot;gridsize 1024 1024 1024&quot; to the worldspawn.<br /> <br /> '''For best (slow) rendering''', have a not-fast VIS phase, not-fast LIGHT phase, bouncegrid, bounce 500. Remove &quot;gridsize&quot; from the worldspawn. Add &quot;_lightmapscale 0.25&quot; to the world spawn.<br /> <br /> If you want to see a map that rendered for 112 hours with lightmapscale 0.25 and 11 radiosity bounces (Then it was tuesday morning and I needed the computer :/ Yes, you can abort the calculation at any time. Previous bounces will still be existent, and the current half-done one will also not be visible.) and want to see what the higher lightmap resolution might do to a 128MB graphics card, take a look at [[Gmotw_Skybox]]. I'm not really proud of the rendering result. There should be more shadow cast situations and so forth, but it's the best I have to offer in that regard yet. I think the lightmap can best be enjoyed in and above the pump station.<br /> <br /> ===enjoy the fruits of the clipping labour===<br /> <br /> Inspect the result of your work. It's very useful that you can move the camera to the inside of a wall, making it temporarily vanish from the 3D view.<br /> <br /> While you were working on the clipping, I picked a nice texture to demonstrate the described advantages of clipped walls. The texture browser should still be in the &quot;karith&quot; section, showing the &quot;cement_3&quot; texture (near the top). Scroll a bit further up until you see a broad texture called &quot;base_grooved&quot;. (Well, you might have a hard time finding it if there's another texture with a long name to the left of it, because then, the name on screen is partly overwritten. As I said: Rudimentary tool.) It should be the 8th texture. Press ESC and then click on the texture. At the bottom of the screen, there should be a text saying &quot;textures/karith/base_groove...&quot;. The texture looks like someone used a comb on a gray piece of butter from the left to the right.<br /> <br /> Now, select one of the faces inside the little room, then click on the texture. If you have done everything like I described, you'll see the texture on the wall, but there's something like a split in its middle. What you see are the outer ends of the texture. Textures are always looped on the brushes, so now lets place this texture properly. Press &quot;s&quot; (if the surface inspector was not already visible), then click &quot;Fit&quot; (if there is a 1 in both text boxes beside the fit button, otherwise set the boxes to 1 (or 1.000000, it's the same)). That was easy, wasn't it? Imagine what would have happened without the clipping. The texture would be partly hidden. If you look at the surface inspector and the numbers in it, can you imagine the hassle of adjusting everything until it looks like it does now?<br /> <br /> If you look at the horizontal and vertical stretch, you see something between 0.5 and 1 (and they are different - thank the programmers for the &quot;fit&quot; button). That's kinda ok-ish, but smaller values mean higher texture resolution. Only we can't put the texture in twice because that doesn't look good, either. The &quot;width&quot; and &quot;height&quot; value next to the &quot;fit&quot; button, by the way, define how often the texture is to fit the surface when you click &quot;fit&quot;. Yes, &quot;0.5&quot; etc. works, too.<br /> <br /> Paint all four walls in the described manner. You can do them all at once.<br /> <br /> After that, paint floor and ceiling with the next texture in the list, &quot;base_small&quot;, and fit it in 1 by 1. Again, this wouldn't have worked so easily without clipping. The horizontal and vertical stretch are close to 2, which is much too high. You can already see how blurry and cheap it looks. But keep it for now.<br /> <br /> ===let's add a door===<br /> <br /> Look from the top in the 2D view. Set the grid spacing to 128 (key &quot;8&quot;). Select one of the 4 walls. Just for training, let's use the toggle-selection, so press and hold SHIFT and ALT, then click on one of the 4 walls a few times until it is selected. You don't have to press ESC before this.<br /> <br /> With the wall selected and the clipper tool active, click on the wall. Gridwise, it has 4 sections. Click so that 3/4 of the wall would be cut off. Umm, where to put the second clip point? The grid doesn't allow to put it on the wall! Well, doesn't matter. Just put it a bit further away. Only the direction and position of the line itself must be correct, not its length. If you have made a nice (and non-diagonal) clipping line, press SHIFT and ENTER or select &quot;split selection&quot; from the &quot;brush&quot; menu, submenu &quot;clipper&quot;. You have cut the wall into two segments. Do that again on the other side, so that the middle segment is two grid elements in size. By the way, you can join brushes if the result would &quot;make sense&quot; (convex brush) using menu &quot;brush&quot;, submenu &quot;CSG&quot;, item &quot;CSG merge&quot;. If you try to merge brushes that can't be merged, you'll see an error message in the log area.<br /> <br /> Ok, now deselect everything (ESC). Then '''select the middle part of the split wall. Then, right-click in the 2D view, go to &quot;func&quot; and select &quot;func_door&quot;. You just made an automatic door''' that opens to the side if you get close, complete with sound. Nice, huh? Let's change the angle to &quot;top&quot; by adding the key &quot;angle&quot;, value &quot;-1&quot; in the entity inspector.<br /> <br /> You could actually make a door that uses a sensor that only reacts to someone carrying a lucifer cannon. Or to dretches and dragoons. Then, a sound would play and dark light would go bright (without lighting the environment, though (then again, I think it can be done using a shader with specular lighting)). Bars in front of the door would move to the sides (with sound). Then, the door would ''rotate'' open kinda like a garage door. Later, everything would move back. This can really be done using triggers, delays and so forth. But dude, I'm not gonna guide you through that.<br /> <br /> You can adjust the door in the &quot;entity inspector&quot; (&quot;n&quot;). You can change the sound, the direction into which it opens, how much of it is still visible once it's open, whether its default is open or closed, how much damage it does to you if you stand in its way, how fast it moves and more. The &quot;lip&quot; value is especially useful. You know, a door is just a brush (or a bunch of brushes - yes, '''you can make complex designs and have them move as one unit''') that moves. It has convenient defaults and a sensor. But you don't need to use the sensor. Also, '''you can use huge negative values for the &quot;lip&quot;, making the door move much further than necessary when it opens. And what is that then? A lift! :)''' There is also an extra lift function, but its default sounds are broken, and also it cannot be set to &quot;crusher&quot;, as far as I know. The big lift in skybox is a door, consisting of several brushes. '''Doors are really versatile.''' You know what? I once used doors to make a programmable soundtracker in Tremulous (&quot;gmotw_pianolessons&quot;, named like this because there's also a big piano with black and white keys that you can step on, and guess what, they are all doors). 16 doors would hammer down in a sequence, and their &quot;I'm closed now!&quot; sound wouldn't play if they don't arrive at the closed state, so I just made buildings in their way to program the sound steps. Did I say that doors are versatile yet? A server where you can save the current building layout can then even save the rhythm for later! Problem is, once too many elements are used, the rhythm stumbles a bit. Maybe a faster computer or newer Trem client doesn't have that problem. I used 16 steps and 3 instruments (bassdrum, snare, closed highhat), and it already got a bit stumbly. Another thing you can do with a door is use it as a busy-light that appears from out of nowhere (was hidden in a wall) and vanishes once the busy cycle (lift or whatever) is over. Also, I once made a door that actually consisted of 8 by 8 doors that you had to shoot. It was a pixel-door. If you didn't shoot the pixels away fast enough, they would return and you wouldn't get through. A tyrant (or whatever) filter. A dream if you carry a lucifer gun. That was in skybox, but I had to remove it in later releases because with all the other map elements, it reduced the FPS too much. But the door maze is still in the map. Looks like solid walls, but it is a small 2D maze. No, even 3D.<br /> <br /> Now, press &quot;h&quot; to hide the door and move the camera so that you look at the room from the outside. We'll now paint the frame of the door. Use the texture &quot;base_verts&quot; which comes shortly after the &quot;base_small&quot; that we used for floor and ceiling. Select the two faces at the side of the opening. Click the texture. Click &quot;fit&quot;. If you look at the stretch values, you see that one is 0.5 and the other 0.25, which can look odd, so better enter a &quot;2&quot; instead of the &quot;1&quot; in height (next to the &quot;fit&quot; button) and click &quot;fit&quot; again. The texture is now used 2 times in height, so it is not as streched in that direction. Press ESC. Then select the upper and lower face of the opening. Click the texture. Looks wrong. Now what? Well, it needs to be rotated. If you look at the &quot;rotate&quot; text box, there is a &quot;0&quot; in it. The text boxes on the right side can be changed at any time without influencing the map in any way - they are only an editor tool. The box right to &quot;rotate&quot; should have a &quot;90&quot; right now. If so, click the up or down arrow (doesn't really matter now) of the rotate value, changing it to 90 or -90 degrees. The texture looks better now. Click &quot;fit&quot;. Damn, bad stretching. Change the height preference to &quot;4&quot; and click &quot;fit&quot; again. See? The &quot;height&quot; now means &quot;width&quot; because the texture is rotated.<br /> <br /> If you look now from the inside of the room, you'll see that the wall (not frame) texture is cleanly cut, as it should be. If you would want to apply and fit the texture now, you'd have problems. '''To use &quot;fit&quot; on a surface with the &quot;wrong&quot; size, temporarily resize the wall to an appropriate width, click &quot;fit&quot;, return the size to normal again.'''<br /> <br /> Paint the 3 outer walls with the texture we used on the inside walls (for that, select an inside wall surface and use CTRL and C, which will not just copy the texture settings, rotation and so forth, but will also select that texture in the browser, so you can just click it then instead of using paste). Don't forget to fit (1x1). Paint the two short front walls with the texture &quot;base_v_rigged&quot;. Fit them in (1x1). By now, you'll have realized that the textures are sorted by alphabet. <br /> <br /> Press SHIFT h to get the door back. Press ESC. Select the door. Press i or choose &quot;invert selection&quot; from the edit menu. Press h. Now, only the door is visible, and it obviously needs some texturing. Put &quot;base_small&quot; on the outside and inside (fit 1x1).<br /> <br /> The four outer sides of the door are still unpainted. Let's select them all at once and then apply &quot;base_verts&quot;. Fit them 1x1. There's a problem: Even though the stretch values on the side surfaces are different from the top/bottom surfaces, you only see one number pair. Keep that in mind, also when dealing with the entity inspector while several elements are selected. A common reason would be to copy the values of one door to another. Select the correct door first, the one you want to fill with values as second, and for every value that you want to copy, click it and then press ENTER in the &quot;value&quot; text box to re-apply the key-value-pair to the correct door, which will also copy it to the other(s).<br /> <br /> So, let's do this again properly (and maybe you have already realized that this is all wrong, then follow me without acting, also smile). Press ESC. Select both side surfaces. Click &quot;fit&quot; with 1x2, so both stretch values should become &quot;0.25&quot;. Select the top and bottom, rotate the texture by 90 degrees, fit 1x2. Why not 1x4 like the same surfaces of the room walls? Because the surfaces of the room walls didn't begin/end at the door opening! So, we have a few meters of unnecessarily painted faces there. I don't know if a real pro mapper would now fix that by causing a few more brushes or if they would just ignore the few meters of unnecessary texture. We'll just leave it at this now. Don't tell anyone.<br /> <br /> The door is now painted on the front, back, and on the other 4 sides. Unnecessarily. The reason is that we didn't think enough like a mapper should, instead we were stuck too much in real-world thinking. Since you will never get to see the left, right and top side of the door, we should apply the Caulk shader to them.<br /> <br /> The texture browser has a little drop down menu, too. Go into that &quot;view&quot; menu and click &quot;hide unused&quot;. This hides all textures from the texture browser that are currently not used by the map. Even better: Also select &quot;show all&quot; from the same menu. Now, every texture that you had loaded in this program session (except the unused ones because you just hid those) is in the texture panel. You should memorize this trick, it will make your mapping much easier. For example: The caulk shader is here! Apply it to the left, right, and upper surface of the door. Then press SHIFT h to unhide everything.<br /> <br /> Press ESC. Select the door. Go to the entity inspector. Add the key &quot;lip&quot;, value &quot;80&quot; to the door, because otherwise it would look kinda weird while open. A bit of its lower end would stick out of the ceiling without any apparent cavity or mechanism for the door. With &quot;80&quot;, it sticks out so far that no one will ask questions.<br /> <br /> This, by the way, makes another surface's texture unnecessary. Since I don't plan on toying around with the door some more, let's set that surface to caulk, too. So: Hide the door. Then look from the outside. The upper diagonal surface will be invisible because the door will never reveal that surface.<br /> <br /> ===let's populate the map===<br /> <br /> Add an &quot;info_player_intermission&quot; entity. (I won't tell you how because I already did. If you didn't read the whole truckload of text, use the in-page-search function of your browser.) Move and rotate the entity so that it looks at the door of the little room from the outside, from a bit further away, slightly diagonal so that you can see the side wall of the room, too, and much of the rest of the map.<br /> <br /> Press the &quot;1&quot; key for the highest grid resolution that you can achieve with the keyboard. In the room (top view in 2D), create a &quot;team_human_reactor&quot; entity. Move it around a little. Then press &quot;8&quot; for grid spacing &quot;128&quot;. Move the reactor again. You see that the amount by which it moves is 128, as the grid forces it to. But its position is kinda off (if we're not unlucky). To force the reactor back into a nice x y and z grid position, press CTRL and &quot;g&quot; or use &quot;snap selection to grid&quot; in the &quot;brush&quot; menu. Now, with the 128 grid, move the reactor as far into the corner as possible. I don't care which one, as long as it's not on the door side. Switch the 2D to side view, set the grid to &quot;7&quot; (64), drag the reactor to a reasonable height position. It must not be in or above the ceiling and not in or below the floor.<br /> <br /> Rotate it around the Z axis by 90 degrees until the nice control panel can be seen. You might even want to rotate it arbitrarily by 45 degrees and then in 90 degree steps until it nicely faces the room.<br /> <br /> Also build an armory, a medistation, two nodes and a few turrets. Give them enough space. Especially the armory is tricky. Too few people know that '''the game system only allows square [[Hitbox|hitboxes]]'''. The height can vary, but the shape when seen from top is square. Even the armory? '''Yes, even the armory.''' If you keep that in mind, it will explain every occasion on which the armory or a nearby building didn't appear in the game.<br /> <br /> You should already rotate the turrets so that they face the door. This is not a [[Building|base building guide]], so I'll stop here.<br /> <br /> Don't forget to make a few alien buildings (overmind, SPAWN!, ...) somewhere in the outside hall.<br /> <br /> Then add &quot;player_human_intermission&quot; and &quot;player_alien_intermission&quot; (one of each) and make them look at the human and alien base.<br /> <br /> You can have a look at the map if you want, even though we haven't placed any lights yet. Just omit the LIGHT phase. Everything will be at full brightness. The batch file:<br /> <br /> &quot;C:\Program Files\netradiant-20100214-win32\q3map2.exe&quot; -fs_basepath &quot;C:\Program Files\Tremulous&quot; -fs_game &quot;base&quot; -custinfoparms -info -meta -patchmeta &quot;C:\Program Files\Tremulous\base\maps\scr5_dretchnest.map&quot;<br /> &quot;C:\Program Files\netradiant-20100214-win32\q3map2.exe&quot; -fs_basepath &quot;C:\Program Files\Tremulous&quot; -fs_game &quot;base&quot; -vis -saveprt &quot;C:\Program Files\Tremulous\base\maps\scr5_dretchnest.map&quot;<br /> &quot;C:\Program Files\Tremulous\tremulous.exe&quot; +set fs_basepath &quot;C:\Program Files\Tremulous&quot; +set fs_game base +devmap &quot;scr5_dretchnest&quot;<br /> <br /> ===lighting===<br /> <br /> On second thought, you should definitely look at the map right now. With full brightness, it sucks. Once we've added nice lighting, it will look so much more pleasant. Lighting makes and breaks the mood.<br /> <br /> Just as decorations (which we haven't dealt with yet) are not a burden but a passion to a real mapper, lighting is not something to be dealt with by just throwing strong point lights with no apparent light source (fixture) all over the place. And definitely '''''do not'' use the &quot;_minlight&quot; or &quot;_ambient&quot; features in the worldspawn.''' You might use them sometimes - really rarely - to test something, but a map with proper lighting will, I dare to claim, never have one of these features in use.<br /> <br /> '''There are two possible light sources:''' Point lights (which can be made with the right-click menu) and light textures (or light shaders, same thing, different term). We have already dealt with shaders. It's possible to make shaders with a parameter that makes it emit light. The larger the surface that uses the light shader, the more light is emitted. The advantage of using light shaders is that you always have a &quot;something&quot; that the light is actually coming from. This contributes considerably to the mood, because it is more believable. You can, of course, just build a &quot;something&quot; that might be a light, then add a point light source to it. That works, too. Actually, the main reason people rarely do that probably is that you can't group brushes and point lights together. You see, the &quot;worldspawn&quot; entity is not the only &quot;dead&quot; entity that can hold brushes. '''You can also select a bunch of brushes and then select &quot;func_group&quot; from the right-click menu.''' This creates a new entity of type (or &quot;classname&quot;) &quot;func_group&quot;. You cannot add other entities (like light or a doorbrush) to such a group which is sad, because if you could, people would probably also try to construct light fixtures and then just put a point light into them instead of fiddling with shaders. And what is the advantage of such a group? Well, if you select one of its brushes, you can then use &quot;expand selection -&gt; to whole entities&quot; from the edit menu. You can then conveniently move them around or copy/paste of them - which creates a new func_group with the copied brushes in them. The expand selection function also works for several such things in parallel. Sadly, I haven't yet found out how to add another brush to such a group. &quot;regroup&quot; in the &quot;entity&quot; menu does the opposite of what you'd expect, and I haven't tried the next function, &quot;ungroup&quot; because I suspect that it does what you'd expect.<br /> <br /> ===decorations, structural/detail brushes===<br /> <br /> <br /> <br /> ===create a release file===<br /> <br /> <br /> <br /> [[Category:Mapping]]</div> Tue, 13 Jul 2010 13:58:59 GMT God, maker of the world http://tremulous.net/wiki/Talk:Mapping Mapping http://tremulous.net/wiki/Mapping <p>God, maker of the world:&#32;/* obtain a frontend for q3map2 */</p> <hr /> <div>A [[mapper]] is a person who creates a game [[map]]. He is &quot;mapping&quot;. This article describes how that works in the Tremulous context. For a list of a few existing Tremulous maps, click [[:category:Maps|here]].<br /> <br /> <br /> =mapping crash course=<br /> <br /> I started this article on 2010-06-29, just so you know why it doesn't refer to Tremulous 1.2 etc. I am a Windows user (2000 and XP), so that's the perspective that I use. If you can't translate that into your perspective, then you probably shouldn't use the system you're using.<br /> <br /> There are already several mapping guides out there ([http://tremulous.net/forum/index.php?topic=7497.0 list]), one of the best of which is at [http://tremmapping.pbworks.com/ tremmapping.pbworks.com]. It is easy and very comprehensive. I'll try to write a new one from scratch here based on my experiences - and much more up to date. It will save you some steps that were necessary 3 years ago when the linked guide was made. This article here will not enable you to make good maps, but it will give you a truckload of know-how of the kind you don't find in other mapping guides.<br /> <br /> If you've ever written something like a guide, you know that you'll inevitably get into ramble mode from time to time. I guess you can forgive me that.<br /> <br /> <br /> ==setting up your computer==<br /> <br /> ===Tremulous client===<br /> <br /> Download and install the original Tremulous 1.1.0 client. It can be found [http://tremulous.net/files/ here], but it's all over the Web, just search. Now, you ''could'' use a different Tremulous client, but I suggest that you don't. Reason: The original client is what many people out there still use, and when you test your map, you'd want to see what it looks and behaves like (and if it works at all) in the client all those [[newbie|noobs]] use who wouldn't know how to fix a problem if your map causes it. You want your map to work and to shine in the original client. You don't want it to look great only in the latest client with magical rendering v9.9.999 and bloom effect.<br /> <br /> Maybe also download the [http://tremulous.tjw.org/backport TJW backport] client. It's a slightly updated version of the original client. Not too new to violate what I said in the previous paragraph. This is not a full Tremulous release. It's just the program itself. Put it into the program folder of the above mentioned original client. This client supports [[GUID]] and much faster auto-[[Cl_allowDownload|download]].<br /> <br /> You might already have all this. But consider starting anew in a VirtualMachine or on a new computer. If you're more proficient, you'll be able to maybe clean up all your Tremulous base folders so that you don't have magical conditions that a person using the naked client wouldn't have. If you're not proficient enough in this and don't want to make a clean install, prepare to experience problems like &quot;But the texture wasn't missing on my machine!&quot;.<br /> <br /> ===NetRadiant===<br /> <br /> Now the most important part: Download and install [http://ingar.satgnu.net/gtkradiant/installation.html Ingar's NetRadiant and the Tremulous support files]. That's two downloads. The instructions on the linked page are short and comprehensive, it's easy to do. [[NetRadiant]] is the tool that you actually make the maps with. You probably also heard about &quot;GtkRadiant&quot;. Forget it. It's 99% the same as NetRadiant, but it's no longer developed. Also, installation is more complicated because it is not prepared for Tremulous. Additionally, Ingar's NetRadiant already includes the [[Q3Map2]] program that compiles your .map document to a playable .bsp map file.<br /> <br /> Change the NetRadiant preferences (and learn a few things about them): Start it. You'll probably see a little window offering a game type selection. Choose &quot;Tremulous&quot;. There's also a checkbox to prevent this window from appearing every time you start NetRadiant. Technically, that was all. But please, continue adjusting the preferences: Go into the preferences window, which can be found in the &quot;edit&quot; menu at the bottom. I'll go from top to bottom, not from most to least important.<br /> <br /> '''Textures:''' Later, you might want to change &quot;gamma&quot; to something like &quot;0.8&quot; to make the 3D display of the editor brighter. '''Undo:''' Increase queue size to 128. You'll use undo very often, sometimes to undo shifting textures around, and that's an undo step for every texture shift step even if it was a button autorepeat result.<br /> <br /> '''Brush:''' Definitely activate &quot;Always use caulk for new brushes&quot;. You can also activate &quot;Use alternative texture-projection&quot;, but most people do not do that, so if you want to open their maps, you'd have to turn it back off and restart the program. And there is no way to convert a .map from one setting to the other. If you decompile a playable map you found somewhere (like ATCS etc.), you would need to use the alternative projection to load the result in NetRadiant, so why not completely live in that world? I, however, have not done so. Because I didn't know better when I started mapping. I also don't know if I would ever regret turning this option on to make my own maps, so be careful. Maybe better leave it off.<br /> <br /> '''Grid:''' Set default grid spacing to &quot;32&quot;. That's the smallest room-wall-thickness that you want to use to prevent [[light bleeding]] (though the best measure to prevent light bleeding still is clipping). Once you're an experienced mapper, you might want to set this to &quot;256&quot;, the largest setting. '''Camera:''' Movement Speed 100 is good, but you'll come back later and change this, depending on your mapping situation. (I think NetRadiant should have a control element on the edit window to adjust the camera more quickly.) Smaller value for working on details, larger value if you have to travel a lot with your editor camera. Enable far clip plane: It's best to turn it off for now, you'll see everything then, no matter how far away it is. Enabling this option and setting the far plane to something close (menu &quot;view&quot;, submenu &quot;camera&quot;) would be helpful for selecting stuff with the box selection. Also, depending on your hardware and the map, it can speed up display considerably.<br /> <br /> '''Orthographic:''' Turn on &quot;display size info&quot; which will show you the size of one or more selected objects in the 2D view. Turn off &quot;chase mouse during drags&quot;, it would turn you crazy. '''Clipper:''' Definitely activate &quot;clipper tool uses caulk&quot;. '''Autosave:''' Deactivate it. If you're not a total computer noob, you'll know and use CTRL+S oftentimes anyway, and the autosave feature really gets in the way. The coders don't even reset the autosave timer when you hit CTRL+S (lol), so you're better off without it. Saving can take some time on bigger maps, so you want to be in control here. Also, very important: Make backups! Once you saved your map, go into the folder and duplicate the file (CTRL+C, CTRL+V, or whatever it is on your system). Sadly, the Radiant coders didn't include a save rotation like jEdit has it. You have to do that manually.<br /> <br /> Later, when you've worked a bit with NetRadiant, you might want to change the grid colors in the menu &quot;misc&quot;, submenu &quot;colors&quot;. My &quot;grid major&quot; is &quot;#00DF00&quot; (a big fat green) and &quot;grid minor&quot; is &quot;#ADFFAD&quot; (a very bright green, fading into white). Now, you should go into the &quot;view&quot; menu, submenu &quot;show&quot; and activate &quot;show workzone&quot; which will draw additional line garbage in the 2D view - the stuff you have drawn/selected last will have an additional red line pair around it. Makes it easier to find it. You have no idea how confusing the 2D view will become once your map is a bit more complex. Rule of thumb: Before you find the lines in the 2D view confusing, you shouldn't even think about presenting your map to the community.<br /> <br /> ===create the asset folders===<br /> <br /> '''Manually create folders in the base folder:''' You already know the base folder. You extracted the Tremulous support file here as Ingar's website instructed. Now, manually create a folder called &quot;maps&quot;. Also the folders &quot;textures&quot;, &quot;sound&quot; (NOT &quot;SOUNDS&quot;), &quot;scripts&quot;, &quot;env&quot;, &quot;models&quot;. If you have already seen a [[.pk3]] file from the inside, you'll have realized that the folders in those archives are treated by the game client as if they were really existing. So, you'll have guessed what those folders you just made will be used for: They'll hold the exact same kind of files that you see in the .pk3 map files.<br /> <br /> ===obtain a frontend for q3map2===<br /> <br /> If you're on Windows, definitely download [http://www.bobdev.com/q3map2build.php q3map2build]. The program is not necessary to make a playable map, but it's a big help in compiling. NetRadiant already has a build menu which calls q3map2 with parameters, also you could manually create batch files and just launch them every time you want to compile a map, which makes sense if you need very special settings for a map. For example: I worked on a map where I used q3map2's &quot;gamma&quot; option, quite unusual, so you would probably not reconfigure NetRadiant's build menu for that. You'd instead use a batch file. Or q3map2build. This VisualBasic program is a '''frontend for q3map2'''. It creates batch files and executes them. Depending on what you selected, there will be up to four lines in such a file: The first one compiles the binary BSP file from your MAP ascii document. The second one (&quot;[[VIS]]&quot;) calculates what point on your map can be seen from which other point and optimizes the BSP accordingly. Can be omitted oftentimes when you just want to have a look at your map, but for releases, this is absolutely necessary. It's the difference between 1 FPS and 90 FPS. Among other things. And the third line (&quot;LIGHT&quot;) finally calculates the light maps, so everything looks and feels real - without this phase, everything would be at full brightness which totally destroys the mood. The fourth line starts the Tremulous client with your freshly compiled map. Very convenient. '''After downloading q3map2build, you have to configure it:''' Start it. Go to &quot;directory options&quot;. Set &quot;game executable location&quot; to your tremulous.exe. Set &quot;q3map2.exe location&quot; to the file &quot;q3map2.exe&quot; located somewhere in the NetRadiant folder. Click &quot;save&quot;. Open the &quot;game options&quot; window, check the &quot;base mod dir&quot; box and type &quot;base&quot; into the text box. Click &quot;save&quot;. That was the basic setup of the program. '''While we're at it:''' In the little &quot;'''BSP'''&quot; area, select &quot;custom&quot; and click &quot;options&quot;. Activate &quot;custinfoparms&quot;, &quot;info&quot;, &quot;meta&quot; and &quot;patchmeta&quot;. Click &quot;save&quot;. In the little &quot;'''VIS'''&quot; area, select &quot;custom&quot; and click &quot;options&quot;. Activate &quot;saveprt&quot; (This makes sure that the portal file generated in the compile process is ''not'' deleted after the compile is completed, though it will be deleted and recreated on next compile. The portal file can be loaded into NetRadiant. You can then see in 2D and 3D the VIS areas that were compiled. Sometimes, you need this to help the software a bit. Keyword &quot;hint brushes&quot;.) and click &quot;save&quot;. In the little &quot;'''LIGHT'''&quot; area, select &quot;custom&quot; and click &quot;options&quot;. Activate &quot;bouncegrid&quot; (If you calc radiosity bounces, this option will make sure that the lightgrid (Whatever that is. I believe that it's a 3D grid of light. If you walk somewhere with your gun, it will receive e.g. red light. The light grid is where this is coming from, I believe.) is recalculated on every bounce, incorporating the light that was created by the bounces.), &quot;custinfoparms&quot; (which is necessary, I think, for shader parameters like &quot;nobuild&quot;, otherwise they might not get transported into the bsp, I believe), &quot;filter&quot; (softens the lightmaps so that shadow seams are soft, not pixelled), &quot;patchshadows&quot; (necessary for your pipes and models to cast shadows), &quot;bounce&quot;, &quot;bouncescale&quot;. Enter a &quot;500&quot; in bounce and a &quot;2&quot; in bouncescale. Remember these two options because you will later come back and deactivate them both, instead you will then (Later, as I said.) activate &quot;fast&quot;. Before you click &quot;save&quot;, let me explain what's going on here: These options define how the lightmaps will be rendered. The option &quot;fast&quot; really really increases the speed of the calculations, and you will use it most of the time because it even doesn't change the lighting drastically. But your first map tests will be of so little complexity that the rendering will be fast anyway. The &quot;bounce&quot; option is for radiosity bounces. So, your surfaces will not just have the light that is cast on them by the light sources. Instead, as in physical reality, your surfaces will also have the light that is reflected by the other surfaces. This is, of course, a question of iterations, because once a surface has received light from another surface, guess what: The next time, the light that comes from the surfaces is different. Realistically, 2 or 3 passes do the trick of giving the right impression. 500 passes will never be reached, all light will be used up at pass 5 or 7 maybe, the program will then stop calculating this. You should definitely use radiosity bounces in the maps you publish (if you have the time to calculate them), because they give a much more natural lighting feeling. For example: Colored surfaces will reflect colored light. You get the picture. Just turn this on for now so that you immediatelly collect data in your mind. The parameter &quot;bouncescale&quot; defines the amplification of the bounced light. Theoretically, this should be set to 1 (and hence just be disabled), but I have made good experiences with amplifying the bounces a bit. This causes more radiosity bounces, of course, because the light will not be used up so quickly. It can even happen that the light will not be used up at all. Hey. This is a crash course, not a &quot;click here and you're done, but you stay uninformed&quot; course.<br /> <br /> You might wonder why I don't just use the &quot;build&quot; features in NetRadiant. Because I want to be in control, and I want to be flexible. This crash course will, for example, deal with &quot;amplified radiosity bounces&quot;, the lightmapscale and somesuch. If I had used the build features as presented, I'd still only work with non-amplified bounces, I wouldn't have dealt with the gridsize or the lightmapscale, I wouldn't have used the &quot;filter&quot; feature. Maybe there's still stuff to discover, but I won't discover it if I use the preconfigured built-in buttons. You don't have to go that way, but I won't spare you the ugly details.<br /> <br /> '''So, until now you have installed the Tremulous client, the NetRadiant map editor, the NetRadiant support files, you have configured NetRadiant a bit, you have hopefully gotten your hands on a good q3map2 frontend, and you have created those folders. That's it, now let's go mapping.'''<br /> <br /> ==NetRadiant crash course==<br /> <br /> In Netradiant, move the mouse to the white area with all the confusing lines. Click and hold the left mouse button. Drag the mouse a bit. Release the left mouse button. You just made a floor. Or a ceiling. '''That thing you just made is called a [[brush]].''' This can only be done in the 2D view. Brushes are the building blocks used to make the map world. They can be changed into different shapes and also be drawn directly in different shapes, but most of the time, you'll draw simple box brushes. If you have done everything in the setup section, the box you have just drawn should have a number pair at its left top (position), a number on the right side and a number on the bottom (dimensions). The unit system used is called &quot;world units&quot;. Rule of thumb (that I heard - can't say that I have really verified it) is: 32 world units = 1 meter. There should also be red lines from all four directions leading to the box brush you made. Click and hold the right mouse button. Move the mouse a bit. Release the button. You have just dragged the whole 2D world. Scroll the mouse wheel to zoom. '''You can now navigate the 2D view.'''<br /> <br /> By the way: When you draw a brush, you obviously control its dimensions in both directions, but what about the third? NetRadiant will make the brush as thick as the gridsize is set - unless your work area (the one we made visible via menu &quot;view&quot;, submenu &quot;show&quot;) says different. So, the last thing you had selected (even if it is now deselected) decides how thick your brush will be. You can of course change the size of a brush afterwards, but now that you know this, you'll some day begin to take this effect into account.<br /> <br /> On the right side, you should see a big gray empty space. That's the 3D view. This one is a bit tricky. I hope you have deactivated the far clip plane in the preferences (&quot;camera&quot;) as I've said. Otherwise, the next steps might take you too far away from the box you just drew, and so you would not get to see it. Right click in the 3D view, and release the mouse button. The mouse cursor should have vanished. When you do that again, the mouse pointer returns to normal. With the mouse pointer locked into the 3D view, press the downwards arrow on your keyboard for about one second. After that, move the mouse around in all directions. If you have done everything as I said, you will find an ugly pink box. Congratulations! You've just discovered the world of the mapper: Ugly pink boxes. Much of the mapping process will take place in your head, not in front of your eyes. Experiment with the arrow keys, the mouse movements, the CTRL and SHIFT key, and the mouse wheel in the 3D view. '''You can now navigate the 3D view.'''<br /> <br /> Time for a few keyboard shortcuts:<br /> <br /> Press the ESC key. The box should now look different in the 3D and 2D view because it is no longer selected. In later situations, you'll have to press the ESC key several times in a row to '''deselect stuff''' because some selection modes go deeper into the structure, and every ESC press takes you a step back until everything is harmlessly unselected. And then it looks like it does now.<br /> <br /> To '''select the box''' again, click on it in the 3D view while holding SHIFT. Most of the time, you will select stuff in the 3D view because it's a pain in the ass to do so in the 2D view. NetRadiant still needs much work. Why they didn't include a box selection mode that only selects stuff that completely fits into the box is beyond me. Don't they use their own software?<br /> <br /> Now that the box is selected again, press the BACKSPACE key. You know, the big leftward arrow above the return key. Whoops, '''box deleted'''. Select &quot;'''undo'''&quot; from the &quot;edit&quot; menu or press CTRL+z to get it back again.<br /> <br /> We will now apply a texture to one of the sides of the box. Well, it already has a texture - the name is '''&quot;Caulk&quot;, that's the most important texture of all''', really. You should have this texture applied to every surface that the player cannot see. So, it's best to start with all-Caulk'd surfaces, and whenever you're working on stuff, keep in mind that every unused surface should be returned to Caulk. This is not a ''must''. But you'll bite your own ass one day if you want to squeeze all possible FPS out of your map, so you'll want to Caulk everything, but didn't take care all the time to prevent unnecessary textures. I've been there.<br /> <br /> Press ESC to deselect the box. Now click on it in 3D, but this time, hold SHIFT and CTRL. '''You just selected a surface.''' The texture browser is right under the 3D view. Doubleclick on &quot;arachnid2&quot;, wait till all textures are loaded, then click on the first texture that you can see: &quot;001metal&quot;. Yay, '''you painted the surface'''. The texture in the texture browser does have a red border now. This means that this is the current texture. Without changing the preferences to &quot;new brushes have Caulk&quot;, every new brush you make would have the red bordered texture. But believe me that you'll later find out yourself that you don't want to go that way. Next to the big texture with the red border, there is &quot;arach_fog_s&quot;, a '''texture with a white border'''. Textures with white borders are [[shader]] textures. Shader textures are not just images, they can even have functions, for example they decide whether a brush textured with them is made of water that you can swim in - or slime/lava that kills you.<br /> <br /> Remember the folders you made in the &quot;base&quot; folder? The pictures you see in the texture browser are stored in the folder &quot;textures&quot; or in one of its many virtual versions - I am speaking of the texture folders in all those .pk3 files. They are treated as if they were really existing folders/files. Which means that it's easy to have a file with the same path and file name existing several times, something impossible in the normal file system (may I remind you that I speak from the Windows perspective). '''You should read the [[.pk3]] article''' because it contains important information on how to deal with this. It's really tricky, and you don't want to go through the process of finding out the hard way. Things that can happen if you fail here: Your map can cause other maps to malfunction. Or your map will be incompatible with older versions of itself. Or it will not function the way it did on your computer. By the way - if you wonder where the textures of all those maps you might have downloaded and played until now are: On my machine (Windows), I have ''several'' &quot;base&quot; folders. One is somewhere in the system user area. If you want to use the textures of those maps, too, move them into the &quot;base&quot; folder where the program is installed. And no, you don't have to unpack the .pk3 files to use their contents in NetRadiant. But if you're a mapping beginner, you shouldn't have other files in your installation &quot;base&quot; folder than the ones that actually came with the Tremulous installation (and the Radiant Tremulous support file). Reason: Later, you'll make a .pk3 release pack, and you have to put all files into it that people will not have from the default installation, so have fun figuring those out when your &quot;base&quot; folder is polluted and you're a beginner.<br /> <br /> In the beginning, you will probably use the textures/shaders/sounds etc. that are part of the original Tremulous 1.1.0 pack. '''You don't have to deliver Tremulous 1.1.0 standard files with your map''' because you can assume that everyone has those. I don't know about the Tremulous 1.2 world that is about to emerge, though. But until now, it's the right way to go, and many people have done so. It's accepted. It keeps your map file small. And it means less file- and folder-hassle for you.<br /> <br /> '''Let's save the map.''' NetRadiant doesn't know a name yet, so it will show you a box where you can enter a name. The folder (&quot;maps&quot;) should already be set. Or did you forget to make the folder? You can leave the name &quot;unnamed&quot;, I mean, why call it &quot;terror castle zero&quot; when you don't even know how to make one. From now on, you can just press CTRL+s to save the map. And from time to time, go to the folder window (outside NetRadiant) and '''make a backup of the map file''' (e.g. by copying and pasting it into the same place). Too much garbage in the folder? Learn to live with it. You don't want to live with lost data. '''Maps can get broken in weird ways.''' If you know how to debug them, good. Otherwise, go to an older version and start over. Example: Maybe you know that a map file is just a human readable text that you can open in any text editor. If you open a more complex map, you'll see that it only consists of [[entity|entities]] which in turn sometimes have parameters and/or brushes. Now, one of the bad things that can happen (because NetRadiant is really just a rudimentary editor that allows to make maps but which is really far from being a reliable pro tool) is that an entity that needs brushes (as for example a door - the brush(es) are the moving door) loses all of them. Such a map would not run in Tremulous. To fix such a situation, you would have to use a text editor, locate the erroneous entity and fix or delete it (which is not hard but also not for beginners). Or you'd go back to a previous map version. And no matter how experienced you'll be one day, there will sometimes be problems that you cannot fix. For example: I had a map once with one telenode. The Tremulous client, though, behaved as if there were two. But there was only one. That's easy to verify because the node can be searched for in the text file. I even searched in the compiled map: Only one telenode. Well, the system is not free from bugs, and this is what can happen. Because I was already so far into the map, I had to test-delete many brushes, compile, run - still one telenode too many. Again. And so forth. After a day, the problem was fixed even though the elements that I finally found out to delete and remake didn't have anything to do with the telenode and also didn't seem broken. Also, the telenode problem was absent in some of my delete runs - even though it was different stuff that I had deleted.<br /> <br /> Another word on backups: If you're not a total computer noob, you use archiving software from time to time. But &quot;ZIP&quot; is not the archive format of choice (except of course to make .pk3 files, those have to be ZIP, but you can create that with other archivers, too). [http://www.win-rar.com/downloadnow.html RAR] is very good (but not free, so there's a nag screen or you have to pay). But the best one currently (even though it doesn't support recovery records - haven't really needed those till today, anyway) is [http://www.7-zip.org/ 7z], and it's free. There are also versions for Linux etc. (search yourself). So, why do I mention all this? Well, if you have a bunch of backup copies of your map file (which will eventually outgrow the 1 mb limit, can even reach 20 mb), you'll quickly have tons of &quot;wasted&quot; space. But don't delete the backups if you're not absolutely perfectly sure that you won't need them any more! Just compress them. They compress very well, to about a 10th of their size. And if you use a ''modern'' archiver instead of ZIP when compressing like 20 backups into one archive, the archiver will not just squeeze down every map backup individually, but it will take into account that most parts of the files are equal. That's called a &quot;solid archive&quot;. Unpacking stuff out of them is a bit annoying because oftentimes, the whole archive has to be calculated through for one file. But who cares. So: Just pack all your backups into one archive from time to time. Instead of 100 mb &quot;wasted&quot; space, you'll only have like 1 mb! And you will have all backups of your map! I do it like this for every map individually: &quot;backups till 2010-06-29.7z&quot; and so forth. Makes you sleep better.<br /> <br /> The last word on backups: It's not enough to just backup the map onto the same machine. That is only for the work process in case something gets broken or you need to copy an object from an earlier version that doesn't exist in the current one. No, you also need to backup your files from your PC to another medium. That doesn't really belong into this article because every serious computer user should do that from time to time anyway. But I'd like to mention that here. What I do (apart from backing up my whole machine onto extra harddisks that I then put away somewhere from time to time): I have all mapping relevant files in the Tremulous install folder. And so, I just make a 7z archive of the whole folder tree once a week or so, and I copy it onto a USB stick. I don't know how reliable those are, but my experiences have been good so far. You'll sleep better if you know that the hundreds of mapping hours are safe somewhere.<br /> <br /> Let's go back to our brush. Press ESC to deselect the surface. Then SHIFT and left-click the brush to '''select it in the 2D view'''. Yes, in the 2D view. You can also hold SHIFT and the left mouse button, drag a box that touches the brush you made, and release both. That's the '''box selection'''. Another thing you can do (but you can't really test now because you only have one element in your map) is to SHIFT and left-click in the 2D view and also hold the ALT key. This selects one of the things that are in the position that you click at, just as the normal SHIFT and left-click does. But if you do this several times, the first selection is deselected, and something else in the same place is selected instead. Very useful function to '''toggle through all the stuff in that place.''' Less useful is the fact that it is buggy - sometimes, you have to move the mouse a bit to make the program allow you to use this function again. Box-selection (SHIFT and left-click, drag, release) is also possible in the 3D view (also the SHIFT-ALT-click toggle-through-stuff function), and only the elements currently in view will be selected - so you'll probably enable far-clip-plane from time to time (preferences, &quot;camera&quot;), adjust its distance (menu &quot;view&quot;, submenu &quot;camera&quot;), enabling you to easily select a group of objects (for example a truckload of lights that you used to slightly paint the light situation without people noticing) in front of you while the things behind them are too far away to be visible or get selected.<br /> <br /> If you have a look at the menu &quot;view&quot;, submenu &quot;filter&quot;, you see that you can '''filter''' the 2D and 3D view for the many different kinds of things and thing-groups that a map can consist of. This will be very useful for selecting. And for not getting distracted/confused. Also, displaying the graphics in the editor is faster if less stuff is being drawn, obviously. If you see anything in the filter list activated right now, select the lowest point &quot;reset filters&quot; which will turn everything off - so that you can see everything that exists in the 2D and 3D view. Another way of '''making stuff temporarily invisible''' is the '''hide function'''. Make sure your brush is selected. Then press the &quot;h&quot; key. Bang, it's gone. You can hide all kinds of elements. If you want everything to be visible again, press SHIFT &quot;h&quot;. Filters and hide have no influence on the map functionality, they are not even stored in the map file. When you close NetRadiant and open it again, the previous filter settings are still active which can be confusing at times. The hidden stuff, though, is visible again. By the way: Did you notice the - - - - - line at the top of the menu? If you click that, the menu will be opened in a window that does not go away when you select something in it. Very useful.<br /> <br /> Another very important function that can be toggled on and off is the &quot;'''texture lock'''&quot; function. There is a button with a lock picture for that somewhere at the top right of the screen. When it's active, it should actually blink and play a loud HONK!-sound all the time or something. And when NetRadiant is closed and opened again, it should be deactivated. But all of this does not happen. So, '''you have to take care whether or not the texture lock function is activated'''. Here is what it does: When it's not on, the textures on a brush seem to scroll around when you move the brush around. That is because the textures are normally locked to the world position. This is very practical, as you will find out with time. Now, the &quot;texture lock&quot; function changes that: When you drag a brush while that function is activated, the textures of the brush will move with it. That is very useful in cases where you have made a brush or several brushes with specific texture work (for example light fixtures), and you want to move those brushes without the design to change. Be aware whether or not the function is activated. You will remember this text here for sure. Because you will at some point see textures in wrong positions, realizing: &quot;Damn, I moved brushes around with texture lock on! Why isn't that function automatically turned off when I start the program?&quot; The texture lock function also changes the behavior of textures when you use the rotate-brush-by-90-degrees function.<br /> <br /> Remember when I called your brush a floor or ceiling? That's because the 2D view shows a view from the top (or bottom, depends on how you think) on the map when the program opens. Press CTRL and TAB. If nothing weird is going on with your input focus and keyboard (which can happen from time to time), the '''2D view was just switched from &quot;top view&quot; to &quot;side view 1&quot;'''. Do that again, and it changes to &quot;side view 2&quot;. Once again, and you're back at &quot;top view&quot;. You can determine what view you're currently on by looking at the little right angle labeled &quot;z&quot; and &quot;y&quot; or &quot;x&quot; and &quot;y&quot;, you get the picture. You'll probably determine that later by rather looking at the map, though. It's helpful/important to learn that the vertical axis is the Z axis. If you can currently see the X and Y axis, you're looking along the Z-axis (meaning: from the top).<br /> <br /> Now, let's finally get to '''how to move and scale a brush:''' Make sure the brush is selected. In the 2D or 3D view, click on the brush, hold the button, move the mouse, release the button. You just moved the brush (if the grid versus the amount of mouse movement didn't prevent this). Moving it in the 2D view makes sure that it is not moved along the axis that is pointing directly towards you. Moving it in the 3D view is comfortable, but can have unwanted results because of the fact that the camera is &quot;never&quot; perfectly aligned with the three space axes. To scale the brush instead of moving it, do the same, but don't click inside of it. Instead, click beside it. Important: Don't scale it too small so that it vanished. I have no idea what happens then. I always hit &quot;undo&quot; in such a situation. Might be a map-breaker.<br /> <br /> '''The grid''' is very important. In most cases, brushes should be perfectly aligned with grid points. Otherwise, have fun debugging your map. To '''change the grid scale''', press one of the number keys from 1 to 9. You can also do that in the grid menu. You'll do that from time to time, because, believe it or not, the grid spacings below 1 are actually used sometimes. The current grid spacing can be seen at the bottom of the NetRadiant window, on the right side. Careful with the key &quot;0&quot;: It toggles the grid from visible to invisible (and back). On a side note: I hope that the NetRadiant developers will be nice and implement a feature that draws the grid with thicker lines (e.g. 3 instead of 1 pixel) because it's simply invisible with all the stuff in front of it on more complex maps, and that sucks considerably.<br /> <br /> '''A word about world units / grid size / reactor and overmind etc.:''' It will take a while until you have memorized all the building and player sizes. Until then, just memorize this: An opening or room with the size '''128x128x128''' (second largest grid setting (&quot;8&quot;)) is just high and certainly wide enough to contain the overmind or reactor (112 would be enough). Tyrants etc. fit through nicely (96 would be enough). Those numbers might not really tell you anything, but any long-time computer user knows the drill: 1 2 4 8 16 32 64 128 256 512 1024 2048 4096 8192 16384 32768 65536 ... You should know those numbers up to 256 to be more efficient with NetRadiant. And 96 is three elements of the size 32, '''96 is just high enough for a tyrant''' to get through. '''64x64x64''' is big enough for a dragoon. A human can still crawl through a height of 32, if I am not mistaken. '''If you want to make a stair, 16 is a nice step height.''' Though 16 might seem a bit big on closer inspection since it's theoretically half a meter.<br /> <br /> Make sure that your brush is selected. Then, press CTRL and C, then CTRL and V, or use the &quot;edit&quot; menu. The '''brush exists now twice in the same place''', a common error that can cause weird map behavior, yet a situation that you will intentionally create many many times, because it's often useful to take an existing brush and copy/paste it somewhere else. At this point I should remind you: Keep everything Caulk'd that cannot be seen by the player. Ok, now press ESC. Yes, keep the two brushes in the one place for now.<br /> <br /> Travel to the side of the brush that shows the &quot;001metal&quot; surface. Select it (SHIFT CTRL left-click). Now go to another texture section. Not &quot;arachnid2&quot; but instead &quot;common&quot;. Most of the '''textures in the &quot;common&quot; group''' are actually shaders, as you know already because you saw the white borders around them. The one called &quot;caulk&quot; is among the first. It should have a green border because the currently open map uses it in at least one place. Click on &quot;caulk&quot;. This applies the caulk shader to the surface you selected. It also gets the red border because it's now the current texture, which is unimportant to us because all our new brushes have caulk, not the current texture. The &quot;common&quot; textures are really useful. There is, for example, a shader called &quot;ladder&quot;. Any vertical surface that you apply this texture to can be climbed. It's really that simple. Well, to make an actual ladder, build something that looks like it can be climbed, then make a brush with the ladder shader around / in front of it. The ladder shader is invisible, but you can't walk though it. There is also a texture called &quot;clip&quot; which you'd sometimes use to invisibly even out too odd wall and floor situations. The dretches will thank you. The players who don't get stuck while running away from the beasts will thank you, too. Some of the textures/shaders of the &quot;common&quot; section can be used without you having to distribute these shaders with your map (like for example the &quot;caulk&quot;, &quot;ladder&quot; and &quot;clip&quot; shaders), but it's best to just add these few bytes to your map file. Better safe than sorry. Ironically, the &quot;invisible&quot; shader, for example, would cause '''&quot;missing texture&quot; optics''' (Missing textures in the game are gray with a big white grid. Hard to miss. Easy to miss, though, if your testing environment is improper, because then you'll not have missing textures, but the players will.) if the Radiant Tremulous support files are not present, so put them into the release file. A .pk3 without those shaders will of course work on your machine - because you have the &quot;data-radiant-1.1.0.pk3&quot; in your &quot;base&quot; folder! Others do not have this.<br /> <br /> '''Get to know the phenomenon called [[Z-fight]] (or Z-fighting):''' Press ESC to deselect. Now, select &quot;the&quot; brush (doesn't matter which one, but just one of them, Wassily), so SHIFT left-click on it. Now for the important part: Move the brush a bit. Not too much. You'll see that the copy (or the original, you never know which one you'll click if there are several in one place) is revealed by you moving the other one. Don't move it too far - they should still overlap. Now, study the area in which the textured face of the one brush and the Caulk'd face of the other brush are drawn in the same place. Move the camera around a bit. If you've done everything right, then you are just observing a Z-fight. Two surfaces want to have the same distance from the observer and fight about it. No one wins, especially not the spectator/player. For historical reasons, the distance an object has from the camera is called the z-distance. You could also read up on the term &quot;[[Z-buffer]]&quot;.<br /> <br /> It is very probable that you will get to see Z-fighting somewhere during one of your many testruns of your maps. You can even find those in finished maps that can be found on many servers. I can remember at least one z-fight in a professional map that came with Tremulous 1.1.0 ([[Nexus6]]). Ironically, right now, there is nothing wrong about your map in that regard. Because one of the two surfaces that are fighting has the Caulk shader - which is defined to be invisible. There would be no z-fighting in your map right now.<br /> <br /> '''Mirroring and rotating:''' Select one of the brushes and toy around with the 6 buttons at the top left of the NetRadiant window. The first one is &quot;x|x&quot; and mirrors the brush along the x axis. I find it irritating that the Radiant developers chose to mirror the brush ''along'' the x axis instead of using the x axis as the, well, mirror axis, but you'll get used to that. The button next to that is the rotate-around-x-axis button, and that actually works like you'd expect it. Depending on the grid-versus-brush situation, the position of the brush gets changed accordingly, too, so later, you'll adjust the grid spacing before rotating a brush around 90 degrees. Mirroring does not care about the grid, just about where the brush begins/ends. If the &quot;texture lock&quot; is active, the textures get rotated and mirrored accordingly. Nice one. But if you rotate a brush using &quot;arbitrary rotation&quot; (menu &quot;modify&quot;), the textures will not be rotated with it, no matter if the &quot;texture lock&quot; was active or not. &quot;arbitrary scale&quot; (same menu), though, scales the textures (if &quot;texture lock&quot; is on).<br /> <br /> Left of the &quot;texture lock&quot; button, there is another (currently selected) button with a rectangle inside of it. If you hover your mouse above it, it'll say &quot;Resize (Q)&quot;. That's your normal brush draw/move/resize tool. Two buttons to the left, there is the &quot;Rotate (R)&quot; tool. Select it and rotate your brush a bit. This is the same as &quot;arbitrary rotation&quot;, only it's handled with the mouse instead of numbers. Don't forget to switch back to &quot;Resize&quot;.<br /> <br /> Now a quick tour of '''dealing with entities''': In the &quot;view&quot; menu, select &quot;entity inspector&quot; (or press &quot;n&quot;). There are several sections in that new window that appeared, and you might have to vertically scale those sections a bit before use. The most important area in that window is the one saying &quot;classname worldspawn&quot;. If there is no such text visible, you probably don't have a brush selected at the moment. Select one (or several, doesn't matter now). If there's still no text &quot;classname worldspawn&quot; in the window, you have to scale and move stuff in the window around a bit. The &quot;most important area&quot; with said text is not the lowest part of the window, but it's the lowest big white box in the entity inspector. Once you've found it, click on the text &quot;classname worldspawn&quot;. You'll see that, once you've selected it, the text &quot;classname&quot; appears below the area in a textbox labeled &quot;key&quot;, &quot;worldspawn&quot; in the &quot;value&quot; box. The '''key-value-principle''' is very important. The area in which you selected the key-value-pair will later have more key-value-pairs. These are the properties of the entity that you've currently selected. Wait, a brush is an entity? Well, if you deselect the brushes with ESC, &quot;classname worldspawn&quot; is no longer visible in the entity inspector window (only as a relict in the &quot;key&quot; and &quot;value&quot; input text boxes). So, every brush is an entity with the text &quot;classname&quot; in it? No. All brushes are one combined entity. The entity's name (And it's better to think of this as a type, not as a name. Later, you will have several entities with &quot;classname&quot; &quot;light&quot;, so it's obviously not just a name but really a type.) is &quot;[[worldspawn]]&quot;, a term mappers toss around oftentimes. Every map has min. and max. one worldspawn. It's the first entity in the .map file (if you look at it with a simple text editor.) The worldspawn can have very important settings regarding the map, for example the amount of buildpoints the teams have, or you can add a little message that is displayed while the map loads. The text area above the &quot;most important area&quot; describes which keys and values can be used for the world spawn. Once you select a different type of entity in the 2D or 3D view (or in the area at the top of the entity inspector, where all possible entity types are listed), the help text changes.<br /> <br /> When dealing with the entity inspector, be careful what you have selected in the map. It's possible to select a brush (usually part of the one &quot;worldspawn&quot; entity) and another entity type, for example a &quot;light&quot;. This flexibility can be useful, but if used improperly, it's a big source for errors. '''Always be aware of what's selected before using any function.'''<br /> <br /> Now, let's use an entity we haven't used before: Select one (or all) of the brushes. Then, right-click in the 2D view. A menu should appear. If it didn't, try again without moving the mouse even the slightest bit. In the menu, go to the item &quot;info&quot;, and from the new submenu, select &quot;info_player_intermission&quot;. This creates a little box of that entity type. Also, the brush(es) that were selected have gone, replaced by the new entity. You better undo that and remember this effect for later, because if you're dealing with a somehow broken map later, it might have been caused by the action that was just demonstrated. But everything should be fine if you use &quot;undo&quot; on such an action. Ok, now press ESC to deselect everything, and then create the entity anew. What is it good for? Well, it defines the position and orientation of the spectator camera when you enter a map or leave a team. '''The &quot;info_player_intermission&quot; entity is absolutely essential. Without it, a map does not work in Tremulous!''' The &quot;info_alien_intermission&quot; and &quot;info_human_intermission&quot; entities have a similar function (camera position and orientation when you're on a team and are currently not alive), but they are not technically necessary. You'll of course place them when you're making a real map.<br /> <br /> You can use the &quot;arbitrary rotation&quot; or the mouse rotate tool to change the direction into which the player_intermission camera is facing.<br /> <br /> Man, I almost forgot THE LOG. Move the mouse to the bottom of the window directly above the status line (that's the area with several texts and horizontal segments). There should be a handle looking like ............ Click and drag it up. You should now see the log. Sadly, you'll have to do that again next time the program is opened. The log shows the actions the program performs (and errors that happened). Have an eye on the log when you map, it'll save you a few map-repair-sessions because you'll see that something you wanted to do didn't work out, or something was done that you didn't expect and so forth.<br /> <br /> There are more NetRadiant explanations in the other sections of this mapping crash course.<br /> <br /> ==making your first (ultra basic) map==<br /> <br /> ===create the map===<br /> <br /> Now that you know how to handle the most important functions of NetRadiant, let's make a map, violating all rules, offending all experienced mappers. In the &quot;file&quot; menu, select &quot;new map&quot;. If a window appears asking you if you want to save the current map, you're doing it wrong because you should have saved the map already a few times with at least one or two backups. Ok, it's a worthless map that you wouldn't really save or backup often, but I want to give you an idea of how to deal with a real map.<br /> <br /> Press CTRL and TAB until the 2D view shows the X and Y axes, so you're '''looking from the top. Press the key &quot;9&quot; to have the largest grid spacing.''' If the grid is invisible, press &quot;0&quot;. If that doesn't make the grid visible, then it probably was not invisible before but just too big for your current zoom (use mouse wheel and maybe &quot;0&quot;). Read on once the grid is visible and also on its largest setting (displaying &quot;G:256&quot; at the bottom of the window).<br /> <br /> '''Create a brush in the 2D view, exactly one grid block in size.''' The numbers on its right and bottom size read &quot;256&quot; if you've done it right. Assuming that 32 world units are one meter, this brush is a nice 8 by 8 meters floor. Which is also 8 meters thick, by the way. But who cares. It's not like we're wasting concrete or something.<br /> <br /> The brush is pink, yes? Otherwise, shame on you. Now, move the camera in the 3D view so that you can see the top of the brush. Select the top face (CTRL SHIFT left-click, don't just SHIFT left-click it or you'll select the whole thing). Go to the &quot;arachnid2&quot; texture section and click the first texture (&quot;001metal&quot;). '''The top surface now has this texture.'''<br /> <br /> Press ESC to deselect everything. Then right click in the 2D view, and select &quot;team_human_spawn&quot; from it. Press ESC again, call the menu again, and select &quot;team_alien_spawn&quot;. Press ESC again, call the menu again, and select &quot;team_player_intermission&quot;. Great! '''Now you have all the three essential elements''' that you need to have a working Tremulous map. But there is a problem: '''If the spawns are not in a proper place''', they might not get created when the map loads. So, move the egg and the node around until they stand somewhere on the box. Make sure that there is enough distance between the two. Also, have a look at them from the side: They must not be too close to the surface of the box or they will not get created when the map loads. You can really place them quite high (Be reasonable.) above the surface. When the map loads, they will be created in that spot and then fall down to the surface (without taking damage). To move the entities around, you have to set the grid to a higher resolution. Just blindly hit one of the left digit keys for a high resolution, which one doesn't matter at the moment. By the way: Too many people ''in the game'' fail to place the spawns in the right rotation. It's easy: The player will spawn to face the position from which you made the spawn. Makes sense: That position can be assumed to be a valid place to go. Making spawns in the right rotation can influence the game flow positively.<br /> <br /> Please check if the surface on which you are trying to put the spawns is the one you have textured. If not, then you did something wrong earlier when texturing it. Spawns cannot be rotated in the editor in the way that they can be put on walls or something, so it's not the spawns that are wrong. By the way, you can '''rotate the spawns''' around the high axis (Z) to define the direction into which the player will look when he spawns. The human spawn, at least the one in the editor, has the aparatus-thingy on the side into which you will spawn. The egg spawns you into the direction the red axis at the egg's center points. The human spawn does so, too, but the aparatus-thingy is easier to see.<br /> <br /> Ok, we have a floor with a texture, both teams have a spawn, and the player_intermission camera does also exist (maybe you want to move and rotate it around a bit until it will probably show something meaningful, but it's not necessary for the map to run).<br /> <br /> What's missing? Light! ESC, 2D, rightclick, '''select &quot;light&quot;'''. A text box appears. Make sure that the number inside of it is &quot;100&quot;. That's the brightness of the light. Click ok or press RETURN. Pressing RETURN is not always advised: The &quot;arbitrary rotation&quot; dialog, for example, will not do anything then. Now move the point light you created until it is in the middle above the box brush. For that, press &quot;8&quot; to set the grid to the second largest spacing. Now it's easy to move the light to the middle. Seen from the top, it must be in the middle. Seen from the side, it must be one grid step above the floor. With setting &quot;8&quot;, that's 128 world units - 4 meters.<br /> <br /> ===build the BSP file and run it===<br /> <br /> If you have not yet saved the map, shame on you. Also, do it now. The name should be &quot;unnamed&quot;. Then, close NetRadiant. '''Because now we'll play the map!'''<br /> <br /> If you're a lucky Windows user, you'll have downloaded and configured q3map2build, I hope. Start that program, select the map &quot;base\maps\unnamed.map&quot; that you've just created, make sure that &quot;Play after build&quot; (left border of the window) is activated - and then click &quot;build&quot;!<br /> <br /> Alternatively, if you are not using this nice frontent for q3map2, you can create a batch file. The program does nothing different, only it's more comfy, and the texts displayed when you hover the mouse above the many switches certainly make things more clear. So, if you don't use the program, create a batch file. That's a normal text file with commands in it that has to be renamed to &quot;somethingsomething.bat&quot;. Sadly, those mega-idiots at Microsoft chose to hide file extensions (stuff like &quot;.bat&quot;) by default, so you can't rename the whole file name, only everything except the extension. For this reason and overall security improvement, Windows users are urged to turn the display of file extensions on. In any file explorer window, go to the &quot;Tools&quot; menu, select &quot;Folder Options&quot;. At the top of that new window, click on &quot;View&quot; and then scroll down until you see the option &quot;Hide extensions for known file types&quot;. Turn it off and click &quot;Ok&quot; at the bottom of the window.<br /> <br /> Here's the text for the batch file:<br /> <br /> &quot;C:\Program Files\netradiant-20100214-win32\q3map2.exe&quot; -fs_basepath &quot;C:\Program Files\Tremulous&quot; -fs_game &quot;base&quot; -custinfoparms -info -meta -patchmeta &quot;C:\Program Files\Tremulous\base\maps\unnamed.map&quot;<br /> &quot;C:\Program Files\netradiant-20100214-win32\q3map2.exe&quot; -fs_basepath &quot;C:\Program Files\Tremulous&quot; -fs_game &quot;base&quot; -vis -saveprt &quot;C:\Program Files\Tremulous\base\maps\unnamed.map&quot;<br /> &quot;C:\Program Files\netradiant-20100214-win32\q3map2.exe&quot; -fs_basepath &quot;C:\Program Files\Tremulous&quot; -fs_game &quot;base&quot; -light -bouncegrid -custinfoparms -filter -patchshadows -bounce 500 -bouncescale 2 &quot;C:\Program Files\Tremulous\base\maps\unnamed.map&quot;<br /> Pause<br /> &quot;C:\Program Files\Tremulous\tremulous.exe&quot; +set fs_basepath &quot;C:\Program Files\Tremulous&quot; +set fs_game base +devmap &quot;unnamed&quot;<br /> <br /> The line &quot;Pause&quot; is not necessary, though it can be useful to have the process wait between calculating and playing. q3map2build has options to insert &quot;pause&quot;, too. I once had the computer calculate a map for four days in a row, and I had &quot;Play after build&quot; unchecked because why should I &quot;burn&quot; my machine uselessly? This means that after calculating, the machine would just have closed the system's console text box without me being able to read the text. This makes the &quot;pause&quot; feature seem much less superfluous all of a sudden. Of course I could have saved the console output into files automatically (by adding &quot; &gt; outputtext1.txt&quot; to the end of the first line, and bla 2 3 4 to the other lines), but then again I wouldn't have been able to have a look at the console text because it would just have been in the files.<br /> <br /> You'll probably have to adapt the batch file text to suit your computer/setup.<br /> <br /> Doubleclick the batch file to start the compile.<br /> <br /> One of the things that will appear in the text window (which is the system's console text output) is &quot;LEAKED&quot;. Well, we didn't give the map a proper shell, we just made a floor. Doesn't matter at the moment, but later, we'll have to improve on that.<br /> <br /> Well. If everything went right, you're playing the smallest map in the world. And everything around your little world is pitch black. Or you see the [[hall of mirrors]] effect around you, really annoying. But it's a working Tremulous map!<br /> <br /> I bet you want to experiment now. Do that. But don't yet make a big map that kinda asks to be published, people are probably not going to like it. You have to learn some more first.<br /> <br /> <br /> <br /> <br /> <br /> ==making your second (more advanced) map==<br /> <br /> ===choose a name===<br /> <br /> You can freely create folders in the &quot;map&quot; folder, doesn't hurt the game system. So, you should make a folder and throw all files into it that have been created so far.<br /> <br /> Now, open NetRadiant (or select &quot;new map&quot; from the &quot;file&quot; menu if it was already open). Save this empty map. Reason: '''We want to give it a name.''' Press CTRL and S (or select &quot;save&quot; or &quot;save as&quot; from the file menu). The name shall be ... wait, what's your nick name? The name you use as a player or in the forums? If it were &quot;God, maker of the world&quot; (which is my nick name), we could make a short version of that, for example &quot;gmotw&quot;. Let's assume that your nick name is &quot;scrollbar5&quot;. A shorter version would be &quot;scr5&quot; or something. Let's stick to that. Back to naming the map: Please save it as &quot;scr5_dretchnest&quot;. If you actually have a nick name that you want to stick to and that can be nicely expressed with a few letters, use that from now on. I'll keep calling it &quot;scr5_...&quot;.<br /> <br /> You see where I'm heading. I called my first map [[Gmotw_Skybox|&quot;gmotw_skybox&quot;]], and this is not mainly about people attributing the map to my person (or so that all my maps would be in one alphabetical place in the huge map repositories that exist, hehehe) but instead so that I could freely choose my map names without having to worry about the name maybe already existing - or someone else taking the same name. I have not yet seen anyone do it like this, but I think this is actually the way it should be done by everyone, and so I tell my helpless scholar prey (Not really.) to do it just like that. '''Add a short version of your nick name with a &quot;_&quot; at the beginning of your map names.''' Keep it short, though. It's good if this prefix &quot;doesn't make sense&quot;, so it's not confused to be a part of the map's real name. So, &quot;gmotw_&quot; (Hey, that's mine.) is better than &quot;stellar_&quot;. By the way, if you look at the screenshot in the skybox article, you read the message &quot;Remove older versions of Skybox to prevent texture problems.&quot; which is really lame. You won't have problems like this since you can read my experiences and conclusions in this mapping guide. Comfy, no?<br /> <br /> If you use these prefixes, by the way, '''NetRadiant will nicely group all your map assets''' in the texture browser instead of spreading them all around the alphabetical map list.<br /> <br /> If you've read the [[.pk3]] article (which you should at some point), you'll already know about the '''filename uniqueness problem''' and about how to deal with it through several release versions of your map. We have halfway solved the uniqueness problem by choosing &quot;scr5_dretchnest&quot; (or whatever your prefix is), which is probably a name not yet taken. Except if 10 people go through with this mapping crash course without choosing a different prefix. But I wonder if anyone's gonna read it at all :/<br /> <br /> A word about &quot;alpha&quot;, &quot;beta&quot;, and &quot;final&quot; releases: BULLSHIT! That was actually just one word. No really: I think it's a meme or an &quot;I'm doing it just like the real guys! I feel like I'm taking a step into a larger world!&quot;-thing that people release their maps as alpha, beta, and final. Well, it has practical reasons, but it also has its problems. To make it short (meaning: I just deleted about 300 words of bla that I was about to save, and that was just the half of it.): Just give your releases a number. So, just add &quot;_001&quot; to the map name. Three digits seems to be much, but you never know. If you increase the release number every time you make a .pk3 and test it with friends or on the server of a guy you know, you'll quickly be above 9, and with all the stuff you have to keep in mind, you don't want to worry about the goddamn number. And once you have chosen to use the path of the &quot;_001&quot;... instead of the &quot;_a01&quot;... &quot;_b01&quot;... &quot;_final&quot;, you'll laugh at all the mappers who have decided to make their maps a &quot;final&quot; too early. &quot;Oh, something's still broken. Damn, already released as 'final'. Can't change it now.&quot; Weird people anyway. I mean, what makes you so sure that you will never add something to the map in a year or so? And then you have the other guys who are more careful. They make their alphas, then you find their betas in the wild... but there is never a &quot;final&quot;. Guess why. The last beta effectively ''is'' the final. Not changed after years. Assimilated by the community. No, you don't want to play that game. '''Just give your releases a number. Just a stupid counter suffix like &quot;_001&quot;.'''<br /> <br /> So, we're about to create a map. The &quot;next&quot; release of it will of course be the first, so its name is &quot;_001&quot;. (I should add that &quot;release&quot; in this context does not mean that you give it to the Mercenaries' Guild Map Repository and brag about it in the forums or something. I am just talking about a proper .pk3 file that you can test on servers.) When people callvote for it, they'd type:<br /> <br /> &quot;/callvote map scr5_dretchnest_001&quot;<br /> <br /> While we're at it: The .pk3 file of this (as can be read in the [[.pk3]] article) would be named<br /> <br /> &quot;map-scr5_dretchnest_001-1.1.0.pk3&quot;<br /> <br /> The name of the .pk3 file has nothing to do with the callvotes. But the name should be kept equal to the real map name for consistency reasons.<br /> <br /> If you're using the batch file solution, please '''edit the batch file just now''' to use &quot;scr5_dretchnest_001&quot; instead of &quot;unnamed&quot;. Reason: So that it hurts if you change the prefix or map name later. Get used to this. Of course, you can theoretically rename a map a hundred times before releasing it the first time, but we want to train here. If you decide to wait with the batch file editing, you're technically making the right choice in case you rename later, but you should experience the name lock, it'll help your mind to get into the real mapper world. Also, all following steps will make use of the map name and cement it some more, and '''you do not want the asset folders and the map to have different names. It's enough hassle as it is, and this would double the file naming work.'''<br /> <br /> By the way, how did I come to the name &quot;dretchnest&quot;? Ok, it's not rocket science, but you'd think that about most map names ''once they exist''. Obviously, I thought of Tremulous elements. What you can do to come up with a map name depends on whether you create it at the beginning, in the middle, or at the end of the mapping process. For example, when I came up with &quot;dretchnest&quot;, I had no idea what exactly the map should be like (other than something with 4 walls that you are supposed to clip diagonally in the corners). I only grabbed a name out of the clouds to complete this section. '''But now that I have a name, it gave me ideas about the map.''' Actually ideas that are ill placed in a beginner's mapping guide, so I'm probably not gonna put them into action here, but here they are: There would be a rectangular (Duh. Beginners always make box maps.) room with a few eggs. The room would be closed from all 6 sides, but there would be openings at the bottom, small enough for dretches to get out. Maybe there would have to be contraptions against crouching humans, maybe that would have to be done by basecamping dretches. If you spawn as granger, you can't get out, so maybe I would have added a trigger that checks if you're granger - and kills you. The ceiling of the room would be something that can be set in motion somehow with a button or by making a building or by reaching a certain spot or by reaching stage 3 etc., and this ceiling would squish the eggs in the room. Since there are no other eggs and grangers cannot get out, the aliens would have lost the game (if the aliens still alive don't win it). This is obviously not a standard Tremulous map, but I digg stuff like this (Trem has enough standard maps, lets bring something new to the table). Read the [[Gmotw_Skybox|skybox]] article if you don't know what I mean. That was my first map, by the way.<br /> <br /> &quot;dretchnest&quot; would have been a fitting name for the above described map. See? '''The name idea resulted in a map idea.''' I believe that it's usually the other way round. But it's improbable that the mapper does not decide for a name until the map is completed, because you'd need to test the map from time to time, and so you'd come up with a name to make a release file. (I repeat: The name you choose once you publish the map should never change, if you can somehow make it so.) Once the name is chosen, the name will probably feedback into the mapping process (e.g. you'd want it to be justified, the least you would do is add fitting decorations).<br /> <br /> '''How you can come up with a map name''': I speak english and german, so when I am thinking about the map that I already created a bit, I think of its prominent building and gameplay elements, enter those terms into a Web translator (like [http://dict.leo.org dict.leo.org]) in english or german, and then I play '''translation ping pong'''. You can also use a Web '''thesaurus''' for that. There are also '''map name generators''' on the Web, probably not Tremulous-specific. You'd rather want to use them for inspiration (and to fuel your translator and thesaurus attempts), not to really make the name for you.<br /> <br /> ===make a shader and a texture===<br /> <br /> Now, go to your Tremulous &quot;base&quot; folder. '''Create a new folder in the folder &quot;textures&quot;.''' Name: &quot;scr5_dretchnest&quot;. Why not &quot;scr5_dretchnest_001&quot;? Because then you'd have to re-assign all textures on every new release because the foldername changes. The project you're working on is &quot;scr5_dretchnest&quot;, and that's the name the asset folders should have. You can also make a folder like this in the &quot;sound&quot; folder, but I currently don't plan on talking about adding a sound. But this is the way it would work for sounds, too.<br /> <br /> If you want to add shaders (which we will do - it's easy if you know how), you have to add the release number again. Reason: The shaders are not several files stored in a new folder, like textures will be. No, the shaders of a map are little text blocks that are all stored in one text file. (You can also make several files, but let's keep this simple.) And '''if you change the contents of the shader file for a new release, you have to give that file a new name.''' Just as if you would have to give a texture a different name that you change from one release to the next. If you don't do this, your map will be incompatible with older versions of itself. You can be lucky with that. But lets do this properly. Use this knowledge. Imagine you had to gather this knowledge by experience which I had to... urgh!<br /> <br /> So, the texture folder is prepared. But '''lets make a shader first.''' Go to your Tremulous &quot;base&quot; folder into the folder &quot;scripts&quot;. Create a new text file called &quot;scr5_dretchnest_001.shader&quot;. If we add a shader into it, it will appear in NetRadiant the next time you start it. Well, you'd think so, but for some reason only the programmers know, you have to add an entry in the &quot;shaderlist.txt&quot; file in the same folder. At the end of that file, add &quot;scr5_dretchnest_001&quot; (without &quot;.shader&quot;), press return, save and close the file. Now open the &quot;scr5_dretchnest_001.shader&quot; file again and put the following text into it, save and close the file:<br /> <br /> textures/scr5_dretchnest/brightglass_001_s<br /> {<br /> qer_editorimage textures/scr5_dretchnest/brightglass_001.jpg<br /> qer_trans .5<br /> surfaceparm trans<br /> surfaceparm solid<br /> cull disable<br /> {<br /> map textures/scr5_dretchnest/brightglass_001.jpg<br /> tcgen environment<br /> blendfunc gl_one gl_one<br /> rgbGen identity<br /> }<br /> {<br /> map $lightmap<br /> blendFunc gl_dst_color gl_src_color<br /> rgbgen identity<br /> }<br /> }<br /> <br /> Close NetRadiant. Open it again and load the empty map file you created. If you look at the texture browser now, you'll see an entry called &quot;scr5&quot;. Now, how did that happen? Oh, the stupid nick name prefix idea! Yes, NetRadiant interprets names with a &quot;_&quot; in it differently. It creates categories. So, all your maps will be under the category &quot;scr5&quot; instead of being spread around like crazy.<br /> <br /> Unfold the category by clicking on the little triangle on its left side. &quot;scr5_dretchnest&quot; appears. It does so for two reasons: 1. You created a folder with that name in the textures folder. 2. You created a shader that in turn created the virtual (= not really existing) file &quot;textures/scr5_dretchnest/brightglass_001_s&quot;, so another reason why NetRadiant would think that the folder exists.<br /> <br /> The texture browser should now show an element called &quot;brightglass_001_s&quot;, something like a blue-black checkerboard, expressing that the image which was to be shown here can not be found. No wonder - we didn't make that one yet. And that's a bit tricky, because I don't intend to explain any graphics software to you now. '''You'll just ''somehow'' have to come up with a .jpg file that has power-of-2 dimensions''' (you know... 1 2 4 8 16 32 64 128 and so forth, computer numbers, as mentioned earlier in this article, though obviously, a texture with ''anything'' on it and the size of 32x32 or smaller hardly makes sense), I'd say 128x128 should be the choice here, that's enough for a simple reflection picture (which this one is). Textures don't have to be quare, by the way, but let's keep this one simple. Also, I think that a texture with an arbitrary size (not power-of-2) would work, too - but what &quot;would work&quot; is not the question. What surely will work in all Tremulous clients and with all graphics cards, that's the question.<br /> <br /> The jpg quality doesn't need to be maximum for a texture. &quot;high&quot; (60) or &quot;very high&quot; (80) (as they are called in Photoshop) is good enough. &quot;medium&quot; is too low in nearly all cases, I'd say. You know what would be nice? An actual screenshot you take yourself in Tremulous. Cropped and sized to 128x128 or bigger, util max. 2048x2048 for a normal texture and, I'd say, max. 512x512 for a reflection texture, but that's plenty. By the way: The bit depth per color channel must be 8, as most existing image files are. You can use 16 and even 32 bit in Photoshop etc., but not in the game. While we're at it: You can also use .tga pictures. If you know when to use gif/png versus jpg, then you know when to use tga versus jpg. Example: If you need a simple color texture (pure red, no other pixels), then .tga is the perfect choice. Tga supports an 8 bit alpha channel (save as 32 bit then, not 24 bit) and also a simple and lossless compression that can be used with Tremulous.<br /> <br /> So, assuming that you have somehow found a suitable .jpg file (.tga (even compressed) would also work, but I think you have to change the shader text then, though I believe that I have seen that the file extension named in the shader is irrelevant, but better safe than sorry), move / rename it to achieve this name: '''&quot;textures/scr5_dretchnest/brightglass_001.jpg&quot;'''.<br /> <br /> Again, close and open NetRadiant and feast your eyes on the new contents of the &quot;scr5_dretchnest&quot; texture browser category. Well, your image should be there now. Twice even. WTF? Well, one instance is from the actual file in the texture folder, and the other one is the shader you created. '''Now you see why the shader ends in &quot;_s&quot;: This prevents the names from colliding.''' (Adding &quot;_s&quot; is the way everyone does it.) See? Naming is a really delicate subject!<br /> <br /> So, before we finally start making the goddamn map, let me explain the shader we've created:<br /> <br /> The first line creates the virtual file by giving it a path and filename. Again, take care of those file names, be they virtual or real. The brackets don't need explanation, I guess.<br /> <br /> The &quot;qer_editorimage&quot; line is irrelevant for the game, but it gives our shader a nice image in NetRadiant. If you apply this shader to a wall, instead of the ugly &quot;no pic!!1&quot; texture, you now see your nice .jpg image. Half transparent even! That is caused by the &quot;qer_trans&quot; line, which is also irrelevant for the game. It's there purely for the editor. And both these lines are not necessary for editing. Later, you can add &quot;//&quot; to the beginning of these two lines, which means that they are &quot;commented out&quot;. Anything behind &quot;//&quot; is arbitrary text until the line ends. I don't know, though, if a comment can be written on the right end of a shader command. If you comment these two lines out later, when you've actually used the shader in the map, and restart NetRadiant, you'll probably realize that they are not technically necessary, but man do you want them to be there.<br /> <br /> &quot;surfaceparm trans&quot; says that the surface is transparent. This does not mean that you can look through it - it only means that ''the computer'' can look through it! Yes, he has to know, too. A later command will make the shader transparent for us humans, too. As the name said: It's a glass shader.<br /> <br /> &quot;surfaceparm solid&quot; says that the surface is solid. You cannot walk/fall/shoot through it.<br /> <br /> &quot;cull disable&quot; means that the opposite side of a brush that is completely painted with this shader will not be invisible, as it would be with a normal texture. &quot;culling&quot; means to temporarily remove elements (objects, faces etc.) that are irrelevant for the current situation. To speed things up. But it is disabled here because it's glass, so you can see the presence/absence of backside faces, so they must be there.<br /> <br /> So far, this was the description of how the surface behaves. I'm not the shader pro, so the following explanations might be a little stumbly.<br /> <br /> The next {}block describes the actual graphics that will be drawn. The {}block after that tells the system to also create a lightmap and overlay it.<br /> <br /> &quot;map textures/scr5_dretchnest/brightglass_001.jpg&quot; obviously makes the shader use your new texture file. &quot;tcgen environment&quot; is short for &quot;TextureCoordinateGeneration&quot; with the parameter &quot;environment&quot;. Man, do I have to explain environment mapping now? In short, this makes the texture appear in a way that is not like a normal 3D shape but instead like it were a reflection in the 3D shape.<br /> <br /> &quot;blendfunc gl_one gl_one&quot; means: The pixels of the source (this shader) will be multiplied by one, then added to the destination pixels (which is whatever's already drawn on screen behind the glass) also multiplied by one. So, this just adds your lightened (Remember that this shader has a lightmap.) environmentmap-glasstexture onto the world graphics. Now you might realize why it's called &quot;brightglass&quot;. If you want something darker, look for &quot;textures/tremor/darkglass3&quot;.<br /> <br /> I don't really know about shaders. I look at how the other guys did it (There are already tons of existing shaders, look in the folder &quot;scripts&quot; in the map .pk3 files.), I read a bit in the shader manual, trial and error testing, etc. For example, I have no idea what &quot;rgbGen identity&quot; really does, but it belongs there. If you want to dive into that yourself, read [http://www.heppler.com/shader/ this comprehensive shader manual]. Also, lets drop the rest of the shader explanation and get into mapping, damned.<br /> <br /> ===start making the map===<br /> <br /> Assuming that you're still in NetRadiant with your named map (that doesn't have any stuff in it) open, set the 2D to view from the top, set the gridsize to &quot;9&quot; (256), and draw a square, 8x8 grid elements in size, so it will be 2048x2048 world units. It's not really important where you do this, but since NetRadiant positions the camera at position 0,0,0 every time you load a map (which can somehow be changed with an entity, but I currently don't remember how, saw it in a decompiled ATCS once), I'd suggest that you draw this brush exactly centered around the coordinate 0,0. After you've done so, press CTRL and TAB to set the 2D to view from the side (doesn't matter which). If the brush isn't exactly one grid block high, drag it smaller so that it is. Then move the whole platform so that its upper side (which is the floor to walk on) is at coordinate 0. Unnecessary to say: The whole thing, every face, should have the Caulk shader, the ugly pink one that you already know.<br /> <br /> Copy and paste the selected brush. Click into it and drag it upwards so that its lower side (which will be the ceiling of the map) is at coordinate 256. That's an 8 meters high map hall.<br /> <br /> Press ESC, then draw a square brush left of the two existing brushes, exactly between them. If you press CTRL and TAB, you see that the depth of this square brush is already as we want it because the last selected brush(es) had this depth. Assuming that you're still in the side view in which you drew the square brush, draw another one, on the right side this time. Did you fall for the &quot;something is currently selected&quot; trap, or did you think of pressing ESC yourself?<br /> <br /> Press CTRL and TAB two times to get back to the top view. Now select the two side walls you made. To do that in the 2D view, it's ok to just use the box select in the currently mostly empty map space that we have. So, press SHIFT and then left-click and drag the mouse to select the unselected wall(s). The ceiling and floor (both visible in one place as a big square) must not be selected now! Once you've done that, copy and paste them, then click on the rotate-90-degrees-Z button (a Z with a blue arrow around 90 degrees of the Z). Now you should have a big room with ceiling, floor, and 4 walls. The wall and floor brushes should be edge-on-edge, that will work properly, don't worry. The brushes must not overlap, though! Admittedly, the walls are a bit thick, but they are the outer map walls, so that doesn't matter. Actually, it's not so bad to have them this thick. Why shouldn't they stand out in the editor as a unique structure.<br /> <br /> If you have done it right (which is more probable with this large grid spacing than it would be with a smaller spacing), you should have a proper shell in which you can go crazy without having to worry about [[leaking]]. The [[void]] is properly locked out. The [[VIS]] calculation can hence be performed. You will not have the [[hall of mirrors]] effect.<br /> <br /> Well, yes, you will have the HOM effect, because everything is still Caulk, but we'll change that now. First, select a proper texture: Select &quot;arachnid2&quot;, then scroll down a bit until you see &quot;cement_1_clean&quot;. Now, select all the 6 surfaces that form the room (CTRL SHIFT left-click, and as a NetRadiant user, you'll have learned to press ESC a few times before this new select action, I guess). Then click on the texture.<br /> <br /> '''Save the map. If this is your first save in this &quot;start making the map&quot; chapter, you're still doing it wrong!''' Also, duplicate the saved map file.<br /> <br /> Actually, the floor and ceiling look just wrong this way. Go to the &quot;karith&quot; texture section, scroll down a bit until you see &quot;cement_3&quot;, select only the floor and ceiling face (Not the whole brush, but I guess I don't have to say that any more.) and apply the texture. Save the map. No new backup this time.<br /> <br /> Nice room. If you fly around in it with your camera, you might get the impression that it's too dark. In that case, open the NetRadiant preferences. Don't worry about a message saying that you'd better save before entering the preferences - in most cases, it doesn't matter. Except that saving is usually fast and in most cases not a problem. And if that dialog appeared just now, you didn't save the map when I said so, sinner! :&gt; Go to the preferences section &quot;display&quot;, subsection &quot;textures&quot;, and set the texture gamma to, let's say, 0.8<br /> <br /> ===about clipping, most underestimated by beginners===<br /> <br /> Assuming that the current situation is the result of your actions in the last chapter, you should still be looking from the top in the 2D view. Gridsize should still be largest (key &quot;9&quot;). Now, draw a new brush, 4 grid elements in size, around the 0,0 coordinate. So, the size should be 512x512. The brush should be inside the map shell room that you built, exactly from floor to ceiling.<br /> <br /> We'll use a little trick now. Set the grid spacing to 32 (key &quot;6&quot;). As I said, 32 is the smallest wall thickness you should use if you want to prevent light bleeding. You can be lucky with smaller values or still unlucky with larger ones, but 32 is a good base to work with. I've read somewhere that a thinner wall risks that objects or players might pass through it when playing on the Internet, but I think that's not true, at least I haven't seen problems like these ''ever'' in the Tremulous world, and there are maps with thinner walls around. Another thing about wall thickness: Even a wall with 64 world units might still let the damage effect of a fully charged [[Lucifer Cannon]] shot through a bit. I wonder how much or how little calculation time / network overhead impact it would have meant to prevent this, because this behavior sucks considerably.<br /> <br /> So, with the grid set to spacing 32 and the new 512x512 brush selected, search for the 5th button right of the 90-degree-Z-rotate button. When you hover over it, it says &quot;Hollow&quot;. Alternatively, go to the &quot;brush&quot; menu, submenu &quot;CSG&quot; and select &quot;Make Hollow&quot;. This function is not widely used, because it motivates box rooms (and other reasons, I guess), but right now it's the best thing in the world because it guarantees that you have a new room with 6 walls, all edges ''overlapping'', wall/ceiling/floor thickness 32. (Side note: Why the &quot;hollow&quot; tool doesn't come with the option to automatically clip the resulting brushes is beyond me.)<br /> <br /> Overlapping brushes should be prevented &quot;at all costs&quot;. We'll do that now, too, which brings us to &quot;clipping&quot;.<br /> <br /> Did I say &quot;save the map&quot;? No, and I won't say that any more.<br /> <br /> While still looking from the top, try to select one of the four walls in the 2D view. It's tricky, isn't it? Now you see why you'll select stuff in the 3D view most of the time. But let's try the 2D view again. Press ESC. Then, box-select the middle part of one of the walls (which will also select other stuff). Then, box-select the center of this new room. Shazam, everything except the wall is deselected. Box-select inverts the current selection where it is in effect. Also, nice that we activated &quot;display size info&quot; in the preferences (&quot;orthographic&quot;) before, because now we can clearly see that all elements of the current selection have the position and size of the wall we wanted - which makes it reasonable to assume that only the wall is selected. Once your maps are a bit more complex, that assumption is not so reasonable. I think that it would save the mappers of the world tons of time if there were a simple but prominent number stating how many elements are currently selected. Well, rudimentary tool, as I said. Instead, you can see how many milliseconds it took the 3D view to redraw.<br /> <br /> Now that one wall is selected, choose a different tool. Currently, the button with the square on it is activated (&quot;Resize (Q)&quot;). Activate the button right from it, the one with the diagonal line (&quot;Clipper (X)&quot;). This tool can be used to cut away parts of brushes or to split them into two brushes. Reminder: The preferences of the &quot;clipper&quot; should be set to &quot;Clipper tool uses caulk&quot;.<br /> <br /> You have to cut away a small diagonal part of the wall in the corner. What we want to achieve is that the four walls do not overlap in the corner but do instead end exactly where the next one begins. Yes, you could just use the resize tool for that, but that's not how a good mapper does it (except when it makes more sense than clipping). Imagine: When the walls are clipped in the way I described it, then not just the outer walls will be perfectly connected, but the inner walls, too. So, when you paint textures on them, you can use the &quot;fit&quot; tool of the &quot;surface inspector&quot; (key &quot;s&quot;) to make the texture fit the wall perfectly while you can mostly forget about all the numbers in that window. Or, if you're dealing with the numbers, you can copy them from other surfaces because the other walls have the same special properties (brush corners clipped).<br /> <br /> Well, if you had drawn the walls edge-on-edge like you did with the outer map walls, painting the inner walls would be exactly as easy as the clipped result will be. But we want to paint the outer walls, too! This will be a room visible from the outside, hence it must be properly built.<br /> <br /> So, let's just try to clip one of the corners of the selected wall now. Choose one end of the wall, then click once on the corner that is outside of the room, then on the one that's inside of the room. Two blue dots (&quot;1&quot; and &quot;2&quot;) should have appeared. The line that connects them should point from the outside room corner to the inside of the room. Also, there is another line (the &quot;perpendicular&quot; or &quot;normal&quot;) beginning at the middle of the clip line. Both lines are not existing objects but just editor tools.<br /> <br /> Press ENTER. So, the brush was divided by that clip line you made, and now one of the two parts of the brush is gone. It's the one that the additional line (the &quot;normal&quot;) went through, that's the rule. Which way the &quot;normal&quot; points depends on the order in which you created the clipper points. Also, you can invert the clipper direction (menu &quot;brush&quot;, submenu &quot;clipper&quot;). Also, the brush part that will stay will have the clip face painted blue in the 3D view (as long as you didn't complete the clip by pressing ENTER).<br /> <br /> Clipper tips: You can drag the clip points around on the 2D view. You can even add a third point. You can change the 2D view from top to side etc. and then still drag the points around. And you cannot remove the clip points by pressing ESC. To remove them, you have to select a different tool (like &quot;resize&quot;) and then switch back to the clipper tool. Or just click again once all 3 clipper points are placed, because that will place number 1 again, removing the other two. Only if you click directly on one of them, you can drag them.<br /> <br /> Very frustrating: While the &quot;undo&quot; can be used to return to the unclipped brush, it does not return you to the situation with existing clipper points, so you have to place them anew.<br /> <br /> Now that you kinda know how to work the clipper tools, clip all 8 wall ends diagonally, so that the walls are perfectly face on face, not overlapping any more. So that the inner walls start and end exactly in the inner room corners.<br /> <br /> Wow, finally done with the stupid clipping. Let's paint and resize a few more blocks, right? No. The clipper tool is one of the most important tools in mapping, and you'll use it much more often than you can imagine right now.<br /> <br /> For example: It's time to clip the ceiling and floor so that they diagonally meet the walls - which, thusly, also have to be clipped. In the end, all 6 walls/floor/ceiling of the little room will be kinda like the bottom ends of pyramids pointing into the room, perfectly face to face which each other. During all this, you should leave the grid spacing on 32.<br /> <br /> Done yet? An experienced mapper needs 1 or 2 minutes to finish this properly.<br /> <br /> You might be wondering why we didn't just delete the ceiling and floor of the little room (after all, there's still the outer map ceiling and floor). Reason one: Using a map shell room like we did is a crutch. Not necessarily a bad one, but also not necessarily the way an experienced mapper does it. Reason two: You'd make yourself dependent on the outer ceiling and floor, and once you get out of the room and map some more, you'll have more dependency-situation-possibilities like this. You don't want to tie it all together and stand in your own way. I had that when making skybox. &quot;Can I texture this wall? No, damned, it's the outer wall again.&quot; Reason three: Lightmaps! I don't know how exactly it is decided how many pixels a lightmap has, but I am pretty sure that a huge brush will have a less high resolution (so, rather stretched) light map. Oh, speaking of which:<br /> <br /> ===_lightmapscale, gridsize, turbo rendering===<br /> <br /> (You can skip this now and go to &quot;enjoy the fruits of the clipping labour&quot;. One day, you should read this, though.)<br /> <br /> I already explained the worldspawn. Press ESC and select any one of the brushes. Since we currently only have simple worldspawn brushes (as opposed to, for example, doors), you could also just box-select a bunch of them. Anyway: Press &quot;n&quot; if the entity inspector was not yet visible. As you know, the second section shows a help text for the currently selected entity type, and since the third section shows &quot;classname worldspawn&quot;, the help text describes the worldspawn. Scroll far down (not to the end) until you see the explanation of &quot;_lightmapscale&quot;. Read it. Then, write &quot;_lightmapscale&quot; and &quot;0.25&quot; into the &quot;key&quot; and &quot;value&quot; textboxes and press RETURN while you're in the value textbox. I thoroughly tested it in a relatively small room: Values smaller than 0.25 don't increase the lightmap resolution any more.<br /> <br /> Setting the lightmapscale to 0.25 will result in a higher lightmap resolution, so you'd have better shadows etc., think of the difference between the thumbnail of a picture and the full size version (only the difference is not that drastic here). The default setting is &quot;1.0&quot; (when the _lightmapscale key is not present). 0.25 also means that the LIGHT phase, in which the lightmaps are calculated, will take much longer. This also means that larger settings than 1 will make it shorter.<br /> <br /> If you've followed this mapping crash course so far, you'll either have prepared q3map2 frontend &quot;q3map2build&quot; or a build batch file, and you will have done so that the light rendering result is very good:<br /> <br /> &quot;fast&quot; is not activated. &quot;bouncescale&quot; is on 2, &quot;bounce&quot; is on 500 (meaning: effectively &quot;6&quot; or something). And to top it off, your map now has the best lightmap scale. The option &quot;filter&quot; is not relevant for the calculation time. It will smooth the resulting lightmap a little so that shadow seams don't look so pixeled. I am not repeating all this from other guides, these are actual experiences that I gathered in many tests over months.<br /> <br /> Now, as long as your map is very small, these settings are ok. Calculation will be done in a few minutes or less than a minute. But once your map is a huge monstrosity, calculation with these settings takes several days on a fast computer. That's still ok as long as you have an extra machine for things like these, but '''here's how you can speed up the rendering like crazy''' (resulting in less good result, of course):<br /> <br /> Add the key &quot;gridsize&quot;, value &quot;1024 1024 1024&quot; to your worldspawn (default would be 64x64x128 as far as I know, and to achieve default, just delete the key again). As far as I know, the gridsize defines the ''volumetric'' lightmap calculation. If you get closer to a bright red spot in the map, your weapon will receive red light. If the gridsize is as coarse as we have set it here, those effects will be less prominent. I could be totally wrong about this. Maybe the gridsize is more about how the raytracing really takes place. In any case: Changing the gridsize has ''huge'' (!) impact on the calculation time. Setting it to this value will make it faster. Deleting the key, so that you're back on the (very good) default value makes it slower. Setting the gridsize to something like 48x48x48 increases the calculation time insanely, and as far as my test results go, it doesn't have any merit. So: For high quality results, you'd use the default setting. For quick and less proper results, you use the 1024 (or an even rougher) one.<br /> <br /> You can also drop the &quot;bouncegrid&quot; option. Bouncegrid means that before every radiosity bounce, the lightgrid (see &quot;gridsize&quot;) is calculated anew, because somethingsomething bounce influence grid somethingbla. Honestly, I didn't test the difference it really makes, but I believe that it's safe to assume that this option increases the light rendering quality even further.<br /> <br /> Change the rendering settings (in &quot;q3map2build&quot; or your batch file) so that the LIGHT phase uses the key &quot;-fast&quot;. This does not change the lighting ''very'' much (but still too much for my taste when I want to make a real proper release), but it insanely reduces calculation time.<br /> <br /> Removing the &quot;bounce&quot; option (&quot;bouncescale&quot; is irrelevant for the time (except in regards of the caused number of iterations) and is bound to &quot;bounce&quot;, so you don't have to touch it here) has strong influence on the lighting. You should try to have a few bounces in your released maps, the light looks considerably more natural. Removing the &quot;bounce&quot; option decreases calculation time, though. Very much even. If the initial pass (not yet bounced) takes 10 seconds, every bounce will also take about 10. If the first took 1 day, guess what. Depending on the bouncescale you used, the amount of bounces will have strong influence on the lighting result. This is something for tweaker guys. Just as the &quot;gamma&quot; option (that I didn't mention yet) in the LIGHT phase is. You should know that these options exist and that it's a good idea to toy with them. Now let's move on.<br /> <br /> Another option that you can add to speed up calculation: &quot;-fast&quot; in the VIS phase. Please don't do this, though, if you want to release the results into the public. And definitely don't release the result if you omit the VIS phase completely - which you can also do to decrease rendering time even more. The VIS phase calculates which spot of the map can be seen from which other spot. This information allows the game engine to draw only the necessary graphics. As far as I know, it also influences the radar functions of helmet and aliens. It's essential for a release, and you should do it without &quot;-fast&quot; for a release.<br /> <br /> '''In short:'''<br /> <br /> '''For fast rendering''', add &quot;-fast&quot; to the VIS phase (or drop it completely), add &quot;-fast&quot; to the LIGHT phase, remove &quot;bounce&quot; from the light phase (or just &quot;bouncegrid&quot;, but I think if you're already doing bounces, you might as well do them properly), remove the &quot;_lightmapscale 0.25&quot; thing from the worldspawn, add &quot;gridsize 1024 1024 1024&quot; to the worldspawn.<br /> <br /> '''For best (slow) rendering''', have a not-fast VIS phase, not-fast LIGHT phase, bouncegrid, bounce 500. Remove &quot;gridsize&quot; from the worldspawn. Add &quot;_lightmapscale 0.25&quot; to the world spawn.<br /> <br /> If you want to see a map that rendered for 112 hours with lightmapscale 0.25 and 11 radiosity bounces (Then it was tuesday morning and I needed the computer :/ Yes, you can abort the calculation at any time. Previous bounces will still be existent, and the current half-done one will also not be visible.) and want to see what the higher lightmap resolution might do to a 128MB graphics card, take a look at [[Gmotw_Skybox]]. I'm not really proud of the rendering result. There should be more shadow cast situations and so forth, but it's the best I have to offer in that regard yet. I think the lightmap can best be enjoyed in and above the pump station.<br /> <br /> ===enjoy the fruits of the clipping labour===<br /> <br /> Inspect the result of your work. It's very useful that you can move the camera to the inside of a wall, making it temporarily vanish from the 3D view.<br /> <br /> While you were working on the clipping, I picked a nice texture to demonstrate the described advantages of clipped walls. The texture browser should still be in the &quot;karith&quot; section, showing the &quot;cement_3&quot; texture (near the top). Scroll a bit further up until you see a broad texture called &quot;base_grooved&quot;. (Well, you might have a hard time finding it if there's another texture with a long name to the left of it, because then, the name on screen is partly overwritten. As I said: Rudimentary tool.) It should be the 8th texture. Press ESC and then click on the texture. At the bottom of the screen, there should be a text saying &quot;textures/karith/base_groove...&quot;. The texture looks like someone used a comb on a gray piece of butter from the left to the right.<br /> <br /> Now, select one of the faces inside the little room, then click on the texture. If you have done everything like I described, you'll see the texture on the wall, but there's something like a split in its middle. What you see are the outer ends of the texture. Textures are always looped on the brushes, so now lets place this texture properly. Press &quot;s&quot; (if the surface inspector was not already visible), then click &quot;Fit&quot; (if there is a 1 in both text boxes beside the fit button, otherwise set the boxes to 1 (or 1.000000, it's the same)). That was easy, wasn't it? Imagine what would have happened without the clipping. The texture would be partly hidden. If you look at the surface inspector and the numbers in it, can you imagine the hassle of adjusting everything until it looks like it does now?<br /> <br /> If you look at the horizontal and vertical stretch, you see something between 0.5 and 1 (and they are different - thank the programmers for the &quot;fit&quot; button). That's kinda ok-ish, but smaller values mean higher texture resolution. Only we can't put the texture in twice because that doesn't look good, either. The &quot;width&quot; and &quot;height&quot; value next to the &quot;fit&quot; button, by the way, define how often the texture is to fit the surface when you click &quot;fit&quot;. Yes, &quot;0.5&quot; etc. works, too.<br /> <br /> Paint all four walls in the described manner. You can do them all at once.<br /> <br /> After that, paint floor and ceiling with the next texture in the list, &quot;base_small&quot;, and fit it in 1 by 1. Again, this wouldn't have worked so easily without clipping. The horizontal and vertical stretch are close to 2, which is much too high. You can already see how blurry and cheap it looks. But keep it for now.<br /> <br /> ===let's add a door===<br /> <br /> Look from the top in the 2D view. Set the grid spacing to 128 (key &quot;8&quot;). Select one of the 4 walls. Just for training, let's use the toggle-selection, so press and hold SHIFT and ALT, then click on one of the 4 walls a few times until it is selected. You don't have to press ESC before this.<br /> <br /> With the wall selected and the clipper tool active, click on the wall. Gridwise, it has 4 sections. Click so that 3/4 of the wall would be cut off. Umm, where to put the second clip point? The grid doesn't allow to put it on the wall! Well, doesn't matter. Just put it a bit further away. Only the direction and position of the line itself must be correct, not its length. If you have made a nice (and non-diagonal) clipping line, press SHIFT and ENTER or select &quot;split selection&quot; from the &quot;brush&quot; menu, submenu &quot;clipper&quot;. You have cut the wall into two segments. Do that again on the other side, so that the middle segment is two grid elements in size. By the way, you can join brushes if the result would &quot;make sense&quot; (convex brush) using menu &quot;brush&quot;, submenu &quot;CSG&quot;, item &quot;CSG merge&quot;. If you try to merge brushes that can't be merged, you'll see an error message in the log area.<br /> <br /> Ok, now deselect everything (ESC). Then '''select the middle part of the split wall. Then, right-click in the 2D view, go to &quot;func&quot; and select &quot;func_door&quot;. You just made an automatic door''' that opens to the side if you get close, complete with sound. Nice, huh? Let's change the angle to &quot;top&quot; by adding the key &quot;angle&quot;, value &quot;-1&quot; in the entity inspector.<br /> <br /> You could actually make a door that uses a sensor that only reacts to someone carrying a lucifer cannon. Or to dretches and dragoons. Then, a sound would play and dark light would go bright (without lighting the environment, though (then again, I think it can be done using a shader with specular lighting)). Bars in front of the door would move to the sides (with sound). Then, the door would ''rotate'' open kinda like a garage door. Later, everything would move back. This can really be done using triggers, delays and so forth. But dude, I'm not gonna guide you through that.<br /> <br /> You can adjust the door in the &quot;entity inspector&quot; (&quot;n&quot;). You can change the sound, the direction into which it opens, how much of it is still visible once it's open, whether its default is open or closed, how much damage it does to you if you stand in its way, how fast it moves and more. The &quot;lip&quot; value is especially useful. You know, a door is just a brush (or a bunch of brushes - yes, '''you can make complex designs and have them move as one unit''') that moves. It has convenient defaults and a sensor. But you don't need to use the sensor. Also, '''you can use huge negative values for the &quot;lip&quot;, making the door move much further than necessary when it opens. And what is that then? A lift! :)''' There is also an extra lift function, but its default sounds are broken, and also it cannot be set to &quot;crusher&quot;, as far as I know. The big lift in skybox is a door, consisting of several brushes. '''Doors are really versatile.''' You know what? I once used doors to make a programmable soundtracker in Tremulous (&quot;gmotw_pianolessons&quot;, named like this because there's also a big piano with black and white keys that you can step on, and guess what, they are all doors). 16 doors would hammer down in a sequence, and their &quot;I'm closed now!&quot; sound wouldn't play if they don't arrive at the closed state, so I just made buildings in their way to program the sound steps. Did I say that doors are versatile yet? A server where you can save the current building layout can then even save the rhythm for later! Problem is, once too many elements are used, the rhythm stumbles a bit. Maybe a faster computer or newer Trem client doesn't have that problem. I used 16 steps and 3 instruments (bassdrum, snare, closed highhat), and it already got a bit stumbly. Another thing you can do with a door is use it as a busy-light that appears from out of nowhere (was hidden in a wall) and vanishes once the busy cycle (lift or whatever) is over. Also, I once made a door that actually consisted of 8 by 8 doors that you had to shoot. It was a pixel-door. If you didn't shoot the pixels away fast enough, they would return and you wouldn't get through. A tyrant (or whatever) filter. A dream if you carry a lucifer gun. That was in skybox, but I had to remove it in later releases because with all the other map elements, it reduced the FPS too much. But the door maze is still in the map. Looks like solid walls, but it is a small 2D maze. No, even 3D.<br /> <br /> Now, press &quot;h&quot; to hide the door and move the camera so that you look at the room from the outside. We'll now paint the frame of the door. Use the texture &quot;base_verts&quot; which comes shortly after the &quot;base_small&quot; that we used for floor and ceiling. Select the two faces at the side of the opening. Click the texture. Click &quot;fit&quot;. If you look at the stretch values, you see that one is 0.5 and the other 0.25, which can look odd, so better enter a &quot;2&quot; instead of the &quot;1&quot; in height (next to the &quot;fit&quot; button) and click &quot;fit&quot; again. The texture is now used 2 times in height, so it is not as streched in that direction. Press ESC. Then select the upper and lower face of the opening. Click the texture. Looks wrong. Now what? Well, it needs to be rotated. If you look at the &quot;rotate&quot; text box, there is a &quot;0&quot; in it. The text boxes on the right side can be changed at any time without influencing the map in any way - they are only an editor tool. The box right to &quot;rotate&quot; should have a &quot;90&quot; right now. If so, click the up or down arrow (doesn't really matter now) of the rotate value, changing it to 90 or -90 degrees. The texture looks better now. Click &quot;fit&quot;. Damn, bad stretching. Change the height preference to &quot;4&quot; and click &quot;fit&quot; again. See? The &quot;height&quot; now means &quot;width&quot; because the texture is rotated.<br /> <br /> If you look now from the inside of the room, you'll see that the wall (not frame) texture is cleanly cut, as it should be. If you would want to apply and fit the texture now, you'd have problems. '''To use &quot;fit&quot; on a surface with the &quot;wrong&quot; size, temporarily resize the wall to an appropriate width, click &quot;fit&quot;, return the size to normal again.'''<br /> <br /> Paint the 3 outer walls with the texture we used on the inside walls (for that, select an inside wall surface and use CTRL and C, which will not just copy the texture settings, rotation and so forth, but will also select that texture in the browser, so you can just click it then instead of using paste). Don't forget to fit (1x1). Paint the two short front walls with the texture &quot;base_v_rigged&quot;. Fit them in (1x1). By now, you'll have realized that the textures are sorted by alphabet. <br /> <br /> Press SHIFT h to get the door back. Press ESC. Select the door. Press i or choose &quot;invert selection&quot; from the edit menu. Press h. Now, only the door is visible, and it obviously needs some texturing. Put &quot;base_small&quot; on the outside and inside (fit 1x1).<br /> <br /> The four outer sides of the door are still unpainted. Let's select them all at once and then apply &quot;base_verts&quot;. Fit them 1x1. There's a problem: Even though the stretch values on the side surfaces are different from the top/bottom surfaces, you only see one number pair. Keep that in mind, also when dealing with the entity inspector while several elements are selected. A common reason would be to copy the values of one door to another. Select the correct door first, the one you want to fill with values as second, and for every value that you want to copy, click it and then press ENTER in the &quot;value&quot; text box to re-apply the key-value-pair to the correct door, which will also copy it to the other(s).<br /> <br /> So, let's do this again properly (and maybe you have already realized that this is all wrong, then follow me without acting, also smile). Press ESC. Select both side surfaces. Click &quot;fit&quot; with 1x2, so both stretch values should become &quot;0.25&quot;. Select the top and bottom, rotate the texture by 90 degrees, fit 1x2. Why not 1x4 like the same surfaces of the room walls? Because the surfaces of the room walls didn't begin/end at the door opening! So, we have a few meters of unnecessarily painted faces there. I don't know if a real pro mapper would now fix that by causing a few more brushes or if they would just ignore the few meters of unnecessary texture. We'll just leave it at this now. Don't tell anyone.<br /> <br /> The door is now painted on the front, back, and on the other 4 sides. Unnecessarily. The reason is that we didn't think enough like a mapper should, instead we were stuck too much in real-world thinking. Since you will never get to see the left, right and top side of the door, we should apply the Caulk shader to them.<br /> <br /> The texture browser has a little drop down menu, too. Go into that &quot;view&quot; menu and click &quot;hide unused&quot;. This hides all textures from the texture browser that are currently not used by the map. Even better: Also select &quot;show all&quot; from the same menu. Now, every texture that you had loaded in this program session (except the unused ones because you just hid those) is in the texture panel. You should memorize this trick, it will make your mapping much easier. For example: The caulk shader is here! Apply it to the left, right, and upper surface of the door. Then press SHIFT h to unhide everything.<br /> <br /> Press ESC. Select the door. Go to the entity inspector. Add the key &quot;lip&quot;, value &quot;80&quot; to the door, because otherwise it would look kinda weird while open. A bit of its lower end would stick out of the ceiling without any apparent cavity or mechanism for the door. With &quot;80&quot;, it sticks out so far that no one will ask questions.<br /> <br /> This, by the way, makes another surface's texture unnecessary. Since I don't plan on toying around with the door some more, let's set that surface to caulk, too. So: Hide the door. Then look from the outside. The upper diagonal surface will be invisible because the door will never reveal that surface.<br /> <br /> ===let's populate the map===<br /> <br /> Add an &quot;info_player_intermission&quot; entity. (I won't tell you how because I already did. If you didn't read the whole truckload of text, use the in-page-search function of your browser.) Move and rotate the entity so that it looks at the door of the little room from the outside, from a bit further away, slightly diagonal so that you can see the side wall of the room, too, and much of the rest of the map.<br /> <br /> Press the &quot;1&quot; key for the highest grid resolution that you can achieve with the keyboard. In the room (top view in 2D), create a &quot;team_human_reactor&quot; entity. Move it around a little. Then press &quot;8&quot; for grid spacing &quot;128&quot;. Move the reactor again. You see that the amount by which it moves is 128, as the grid forces it to. But its position is kinda off (if we're not unlucky). To force the reactor back into a nice x y and z grid position, press CTRL and &quot;g&quot; or use &quot;snap selection to grid&quot; in the &quot;brush&quot; menu. Now, with the 128 grid, move the reactor as far into the corner as possible. I don't care which one, as long as it's not on the door side. Switch the 2D to side view, set the grid to &quot;7&quot; (64), drag the reactor to a reasonable height position. It must not be in or above the ceiling and not in or below the floor.<br /> <br /> Rotate it around the Z axis by 90 degrees until the nice control panel can be seen. You might even want to rotate it arbitrarily by 45 degrees and then in 90 degree steps until it nicely faces the room.<br /> <br /> Also build an armory, a medistation, two nodes and a few turrets. Give them enough space. Especially the armory is tricky. Too few people know that '''the game system only allows square [[Hitbox|hitboxes]]'''. The height can vary, but the shape when seen from top is square. Even the armory? '''Yes, even the armory.''' If you keep that in mind, it will explain every occasion on which the armory or a nearby building didn't appear in the game.<br /> <br /> You should already rotate the turrets so that they face the door. This is not a [[Building|base building guide]], so I'll stop here.<br /> <br /> Don't forget to make a few alien buildings (overmind, SPAWN!, ...) somewhere in the outside hall.<br /> <br /> Then add &quot;player_human_intermission&quot; and &quot;player_alien_intermission&quot; (one of each) and make them look at the human and alien base.<br /> <br /> You can have a look at the map if you want, even though we haven't placed any lights yet. Just omit the LIGHT phase. Everything will be at full brightness. The batch file:<br /> <br /> &quot;C:\Program Files\netradiant-20100214-win32\q3map2.exe&quot; -fs_basepath &quot;C:\Program Files\Tremulous&quot; -fs_game &quot;base&quot; -custinfoparms -info -meta -patchmeta &quot;C:\Program Files\Tremulous\base\maps\scr5_dretchnest.map&quot;<br /> &quot;C:\Program Files\netradiant-20100214-win32\q3map2.exe&quot; -fs_basepath &quot;C:\Program Files\Tremulous&quot; -fs_game &quot;base&quot; -vis -saveprt &quot;C:\Program Files\Tremulous\base\maps\scr5_dretchnest.map&quot;<br /> &quot;C:\Program Files\Tremulous\tremulous.exe&quot; +set fs_basepath &quot;C:\Program Files\Tremulous&quot; +set fs_game base +devmap &quot;scr5_dretchnest&quot;<br /> <br /> ===lighting===<br /> <br /> On second thought, you should definitely look at the map right now. With full brightness, it sucks. Once we've added nice lighting, it will look so much more pleasant. Lighting makes and breaks the mood.<br /> <br /> Just as decorations (which we haven't dealt with yet) are not a burden but a passion to a real mapper, lighting is not something to be dealt with by just throwing strong point lights with no apparent light source (fixture) all over the place. And definitely '''''do not'' use the &quot;_minlight&quot; or &quot;_ambient&quot; features in the worldspawn.''' You might use them sometimes - really rarely - to test something, but a map with proper lighting will, I dare to claim, never have one of these features in use.<br /> <br /> '''There are two possible light sources:''' Point lights (which can be made with the right-click menu) and light textures (or light shaders, same thing, different term). We have already dealt with shaders. It's possible to make shaders with a parameter that makes it emit light. The larger the surface that uses the light shader, the more light is emitted. The advantage of using light shaders is that you always have a &quot;something&quot; that the light is actually coming from. This contributes considerably to the mood, because it is more believable. You can, of course, just build a &quot;something&quot; that might be a light, then add a point light source to it. That works, too. Actually, the main reason people rarely do that probably is that you can't group brushes and point lights together. You see, the &quot;worldspawn&quot; entity is not the only &quot;dead&quot; entity that can hold brushes. '''You can also select a bunch of brushes and then select &quot;func_group&quot; from the right-click menu.''' This creates a new entity of type (or &quot;classname&quot;) &quot;func_group&quot;. You cannot add other entities (like light or a doorbrush) to such a group which is sad, because if you could, people would probably also try to construct light fixtures and then just put a point light into them instead of fiddling with shaders. And what is the advantage of such a group? Well, if you select one of its brushes, you can then use &quot;expand selection -&gt; to whole entities&quot; from the edit menu. You can then conveniently move them around or copy/paste of them - which creates a new func_group with the copied brushes in them. The expand selection function also works for several such things in parallel. Sadly, I haven't yet found out how to add another brush to such a group. &quot;regroup&quot; in the &quot;entity&quot; menu does the opposite of what you'd expect, and I haven't tried the next function, &quot;ungroup&quot; because I suspect that it does what you'd expect.<br /> <br /> ===decorations, structural/detail brushes===<br /> <br /> <br /> <br /> ===create a release file===<br /> <br /> <br /> <br /> [[Category:Mapping]]</div> Tue, 13 Jul 2010 13:57:03 GMT God, maker of the world http://tremulous.net/wiki/Talk:Mapping Mapping http://tremulous.net/wiki/Mapping <p>God, maker of the world:&#32;/* obtain a frontend for q3map2 */</p> <hr /> <div>A [[mapper]] is a person who creates a game [[map]]. He is &quot;mapping&quot;. This article describes how that works in the Tremulous context. For a list of a few existing Tremulous maps, click [[:category:Maps|here]].<br /> <br /> <br /> =mapping crash course=<br /> <br /> I started this article on 2010-06-29, just so you know why it doesn't refer to Tremulous 1.2 etc. I am a Windows user (2000 and XP), so that's the perspective that I use. If you can't translate that into your perspective, then you probably shouldn't use the system you're using.<br /> <br /> There are already several mapping guides out there ([http://tremulous.net/forum/index.php?topic=7497.0 list]), one of the best of which is at [http://tremmapping.pbworks.com/ tremmapping.pbworks.com]. It is easy and very comprehensive. I'll try to write a new one from scratch here based on my experiences - and much more up to date. It will save you some steps that were necessary 3 years ago when the linked guide was made. This article here will not enable you to make good maps, but it will give you a truckload of know-how of the kind you don't find in other mapping guides.<br /> <br /> If you've ever written something like a guide, you know that you'll inevitably get into ramble mode from time to time. I guess you can forgive me that.<br /> <br /> <br /> ==setting up your computer==<br /> <br /> ===Tremulous client===<br /> <br /> Download and install the original Tremulous 1.1.0 client. It can be found [http://tremulous.net/files/ here], but it's all over the Web, just search. Now, you ''could'' use a different Tremulous client, but I suggest that you don't. Reason: The original client is what many people out there still use, and when you test your map, you'd want to see what it looks and behaves like (and if it works at all) in the client all those [[newbie|noobs]] use who wouldn't know how to fix a problem if your map causes it. You want your map to work and to shine in the original client. You don't want it to look great only in the latest client with magical rendering v9.9.999 and bloom effect.<br /> <br /> Maybe also download the [http://tremulous.tjw.org/backport TJW backport] client. It's a slightly updated version of the original client. Not too new to violate what I said in the previous paragraph. This is not a full Tremulous release. It's just the program itself. Put it into the program folder of the above mentioned original client. This client supports [[GUID]] and much faster auto-[[Cl_allowDownload|download]].<br /> <br /> You might already have all this. But consider starting anew in a VirtualMachine or on a new computer. If you're more proficient, you'll be able to maybe clean up all your Tremulous base folders so that you don't have magical conditions that a person using the naked client wouldn't have. If you're not proficient enough in this and don't want to make a clean install, prepare to experience problems like &quot;But the texture wasn't missing on my machine!&quot;.<br /> <br /> ===NetRadiant===<br /> <br /> Now the most important part: Download and install [http://ingar.satgnu.net/gtkradiant/installation.html Ingar's NetRadiant and the Tremulous support files]. That's two downloads. The instructions on the linked page are short and comprehensive, it's easy to do. [[NetRadiant]] is the tool that you actually make the maps with. You probably also heard about &quot;GtkRadiant&quot;. Forget it. It's 99% the same as NetRadiant, but it's no longer developed. Also, installation is more complicated because it is not prepared for Tremulous. Additionally, Ingar's NetRadiant already includes the [[Q3Map2]] program that compiles your .map document to a playable .bsp map file.<br /> <br /> Change the NetRadiant preferences (and learn a few things about them): Start it. You'll probably see a little window offering a game type selection. Choose &quot;Tremulous&quot;. There's also a checkbox to prevent this window from appearing every time you start NetRadiant. Technically, that was all. But please, continue adjusting the preferences: Go into the preferences window, which can be found in the &quot;edit&quot; menu at the bottom. I'll go from top to bottom, not from most to least important.<br /> <br /> '''Textures:''' Later, you might want to change &quot;gamma&quot; to something like &quot;0.8&quot; to make the 3D display of the editor brighter. '''Undo:''' Increase queue size to 128. You'll use undo very often, sometimes to undo shifting textures around, and that's an undo step for every texture shift step even if it was a button autorepeat result.<br /> <br /> '''Brush:''' Definitely activate &quot;Always use caulk for new brushes&quot;. You can also activate &quot;Use alternative texture-projection&quot;, but most people do not do that, so if you want to open their maps, you'd have to turn it back off and restart the program. And there is no way to convert a .map from one setting to the other. If you decompile a playable map you found somewhere (like ATCS etc.), you would need to use the alternative projection to load the result in NetRadiant, so why not completely live in that world? I, however, have not done so. Because I didn't know better when I started mapping. I also don't know if I would ever regret turning this option on to make my own maps, so be careful. Maybe better leave it off.<br /> <br /> '''Grid:''' Set default grid spacing to &quot;32&quot;. That's the smallest room-wall-thickness that you want to use to prevent [[light bleeding]] (though the best measure to prevent light bleeding still is clipping). Once you're an experienced mapper, you might want to set this to &quot;256&quot;, the largest setting. '''Camera:''' Movement Speed 100 is good, but you'll come back later and change this, depending on your mapping situation. (I think NetRadiant should have a control element on the edit window to adjust the camera more quickly.) Smaller value for working on details, larger value if you have to travel a lot with your editor camera. Enable far clip plane: It's best to turn it off for now, you'll see everything then, no matter how far away it is. Enabling this option and setting the far plane to something close (menu &quot;view&quot;, submenu &quot;camera&quot;) would be helpful for selecting stuff with the box selection. Also, depending on your hardware and the map, it can speed up display considerably.<br /> <br /> '''Orthographic:''' Turn on &quot;display size info&quot; which will show you the size of one or more selected objects in the 2D view. Turn off &quot;chase mouse during drags&quot;, it would turn you crazy. '''Clipper:''' Definitely activate &quot;clipper tool uses caulk&quot;. '''Autosave:''' Deactivate it. If you're not a total computer noob, you'll know and use CTRL+S oftentimes anyway, and the autosave feature really gets in the way. The coders don't even reset the autosave timer when you hit CTRL+S (lol), so you're better off without it. Saving can take some time on bigger maps, so you want to be in control here. Also, very important: Make backups! Once you saved your map, go into the folder and duplicate the file (CTRL+C, CTRL+V, or whatever it is on your system). Sadly, the Radiant coders didn't include a save rotation like jEdit has it. You have to do that manually.<br /> <br /> Later, when you've worked a bit with NetRadiant, you might want to change the grid colors in the menu &quot;misc&quot;, submenu &quot;colors&quot;. My &quot;grid major&quot; is &quot;#00DF00&quot; (a big fat green) and &quot;grid minor&quot; is &quot;#ADFFAD&quot; (a very bright green, fading into white). Now, you should go into the &quot;view&quot; menu, submenu &quot;show&quot; and activate &quot;show workzone&quot; which will draw additional line garbage in the 2D view - the stuff you have drawn/selected last will have an additional red line pair around it. Makes it easier to find it. You have no idea how confusing the 2D view will become once your map is a bit more complex. Rule of thumb: Before you find the lines in the 2D view confusing, you shouldn't even think about presenting your map to the community.<br /> <br /> ===create the asset folders===<br /> <br /> '''Manually create folders in the base folder:''' You already know the base folder. You extracted the Tremulous support file here as Ingar's website instructed. Now, manually create a folder called &quot;maps&quot;. Also the folders &quot;textures&quot;, &quot;sound&quot; (NOT &quot;SOUNDS&quot;), &quot;scripts&quot;, &quot;env&quot;, &quot;models&quot;. If you have already seen a [[.pk3]] file from the inside, you'll have realized that the folders in those archives are treated by the game client as if they were really existing. So, you'll have guessed what those folders you just made will be used for: They'll hold the exact same kind of files that you see in the .pk3 map files.<br /> <br /> ===obtain a frontend for q3map2===<br /> <br /> If you're on Windows, definitely download [http://www.bobdev.com/q3map2build.php q3map2build]. The program is not necessary to make a playable map, but it's a big help in compiling. NetRadiant already has a build menu which calls q3map2 with parameters, also you could manually create batch files and just launch them every time you want to compile a map, which makes sense if you need very special settings for a map. For example: I worked on a map where I used q3map2's &quot;gamma&quot; option, quite unusual, so you would probably not reconfigure NetRadiant's build menu for that. You'd instead use a batch file. Or q3map2build. This VisualBasic program is a '''frontend for q3map2'''. It creates batch files and executes them. Depending on what you selected, there will be up to four lines in such a file: The first one compiles the binary BSP file from your MAP ascii document. The second one (&quot;[[VIS]]&quot;) calculates what point on your map can be seen from which other point and optimizes the BSP accordingly. Can be omitted oftentimes when you just want to have a look at your map, but for releases, this is absolutely necessary. It's the difference between 1 FPS and 90 FPS. Among other things. And the third line (&quot;LIGHT&quot;) finally calculates the light maps, so everything looks and feels real - without this phase, everything would be at full brightness which totally destroys the mood. The fourth line starts the Tremulous client with your freshly compiled map. Very convenient. '''After downloading q3map2build, you have to configure it:''' Start it. Go to &quot;directory options&quot;. Set &quot;game executable location&quot; to your tremulous.exe. Set &quot;q3map2.exe location&quot; to the file &quot;q3map2.exe&quot; located somewhere in the NetRadiant folder. Click &quot;save&quot;. Open the &quot;game options&quot; window, check the &quot;base mod dir&quot; box and type &quot;base&quot; into the text box. Click &quot;save&quot;. That was the basic setup of the program. '''While we're at it:''' In the little &quot;'''BSP'''&quot; area, select &quot;custom&quot; and click &quot;options&quot;. Activate &quot;custinfoparms&quot;, &quot;info&quot;, &quot;meta&quot; and &quot;patchmeta&quot;. Click &quot;save&quot;. In the little &quot;'''VIS'''&quot; area, select &quot;custom&quot; and click &quot;options&quot;. Activate &quot;saveprt&quot; (This makes sure that the portal file generated in the compile process is ''not'' deleted after the compile is completed, though it will be deleted and recreated on next compile. The portal file can be loaded into NetRadiant. You can then see in 2D and 3D the VIS areas that were compiled. Sometimes, you need this to help the software a bit. Keyword &quot;hint brushes&quot;.) and click &quot;save&quot;. In the little &quot;'''LIGHT'''&quot; area, select &quot;custom&quot; and click &quot;options&quot;. Activate &quot;bouncegrid&quot;, &quot;custinfoparms&quot;, &quot;filter&quot;, &quot;patchshadows&quot;, &quot;bounce&quot;, &quot;bouncescale&quot;. Enter a &quot;500&quot; in bounce and a &quot;2&quot; in bouncescale. Remember these two options because you will later come back and deactivate them both, instead you will then (Later, as I said.) activate &quot;fast&quot;. Before you click &quot;save&quot;, let me explain what's going on here: These options define how the lightmaps will be rendered. The option &quot;fast&quot; really really increases the speed of the calculations, and you will use it most of the time because it even doesn't change the lighting drastically. But your first map tests will be of so little complexity that the rendering will be fast anyway. The &quot;bounce&quot; option is for radiosity bounces. So, your surfaces will not just have the light that is cast on them by the light sources. Instead, as in physical reality, your surfaces will also have the light that is reflected by the other surfaces. This is, of course, a question of iterations, because once a surface has received light from another surface, guess what: The next time, the light that comes from the surfaces is different. Realistically, 2 or 3 passes do the trick of giving the right impression. 500 passes will never be reached, all light will be used up at pass 5 or 7 maybe, the program will then stop calculating this. You should definitely use radiosity bounces in the maps you publish (if you have the time to calculate them), because they give a much more natural lighting feeling. For example: Colored surfaces will reflect colored light. You get the picture. Just turn this on for now so that you immediatelly collect data in your mind. The parameter &quot;bouncescale&quot; defines the amplification of the bounced light. Theoretically, this should be set to 1 (and hence just be disabled), but I have made good experiences with amplifying the bounces a bit. This causes more radiosity bounces, of course, because the light will not be used up so quickly. It can even happen that the light will not be used up at all. Hey. This is a crash course, not a &quot;click here and you're done, but you stay uninformed&quot; course.<br /> <br /> You might wonder why I don't just use the &quot;build&quot; features in NetRadiant. Because I want to be in control, and I want to be flexible. This crash course will, for example, deal with &quot;amplified radiosity bounces&quot;, the lightmapscale and somesuch. If I had used the build features as presented, I'd still only work with non-amplified bounces, I wouldn't have dealt with the gridsize or the lightmapscale, I wouldn't have used the &quot;filter&quot; feature. Maybe there's still stuff to discover, but I won't discover it if I use the preconfigured built-in buttons. You don't have to go that way, but I won't spare you the ugly details.<br /> <br /> '''So, until now you have installed the Tremulous client, the NetRadiant map editor, the NetRadiant support files, you have configured NetRadiant a bit, you have hopefully gotten your hands on a good q3map2 frontend, and you have created those folders. That's it, now let's go mapping.'''<br /> <br /> ==NetRadiant crash course==<br /> <br /> In Netradiant, move the mouse to the white area with all the confusing lines. Click and hold the left mouse button. Drag the mouse a bit. Release the left mouse button. You just made a floor. Or a ceiling. '''That thing you just made is called a [[brush]].''' This can only be done in the 2D view. Brushes are the building blocks used to make the map world. They can be changed into different shapes and also be drawn directly in different shapes, but most of the time, you'll draw simple box brushes. If you have done everything in the setup section, the box you have just drawn should have a number pair at its left top (position), a number on the right side and a number on the bottom (dimensions). The unit system used is called &quot;world units&quot;. Rule of thumb (that I heard - can't say that I have really verified it) is: 32 world units = 1 meter. There should also be red lines from all four directions leading to the box brush you made. Click and hold the right mouse button. Move the mouse a bit. Release the button. You have just dragged the whole 2D world. Scroll the mouse wheel to zoom. '''You can now navigate the 2D view.'''<br /> <br /> By the way: When you draw a brush, you obviously control its dimensions in both directions, but what about the third? NetRadiant will make the brush as thick as the gridsize is set - unless your work area (the one we made visible via menu &quot;view&quot;, submenu &quot;show&quot;) says different. So, the last thing you had selected (even if it is now deselected) decides how thick your brush will be. You can of course change the size of a brush afterwards, but now that you know this, you'll some day begin to take this effect into account.<br /> <br /> On the right side, you should see a big gray empty space. That's the 3D view. This one is a bit tricky. I hope you have deactivated the far clip plane in the preferences (&quot;camera&quot;) as I've said. Otherwise, the next steps might take you too far away from the box you just drew, and so you would not get to see it. Right click in the 3D view, and release the mouse button. The mouse cursor should have vanished. When you do that again, the mouse pointer returns to normal. With the mouse pointer locked into the 3D view, press the downwards arrow on your keyboard for about one second. After that, move the mouse around in all directions. If you have done everything as I said, you will find an ugly pink box. Congratulations! You've just discovered the world of the mapper: Ugly pink boxes. Much of the mapping process will take place in your head, not in front of your eyes. Experiment with the arrow keys, the mouse movements, the CTRL and SHIFT key, and the mouse wheel in the 3D view. '''You can now navigate the 3D view.'''<br /> <br /> Time for a few keyboard shortcuts:<br /> <br /> Press the ESC key. The box should now look different in the 3D and 2D view because it is no longer selected. In later situations, you'll have to press the ESC key several times in a row to '''deselect stuff''' because some selection modes go deeper into the structure, and every ESC press takes you a step back until everything is harmlessly unselected. And then it looks like it does now.<br /> <br /> To '''select the box''' again, click on it in the 3D view while holding SHIFT. Most of the time, you will select stuff in the 3D view because it's a pain in the ass to do so in the 2D view. NetRadiant still needs much work. Why they didn't include a box selection mode that only selects stuff that completely fits into the box is beyond me. Don't they use their own software?<br /> <br /> Now that the box is selected again, press the BACKSPACE key. You know, the big leftward arrow above the return key. Whoops, '''box deleted'''. Select &quot;'''undo'''&quot; from the &quot;edit&quot; menu or press CTRL+z to get it back again.<br /> <br /> We will now apply a texture to one of the sides of the box. Well, it already has a texture - the name is '''&quot;Caulk&quot;, that's the most important texture of all''', really. You should have this texture applied to every surface that the player cannot see. So, it's best to start with all-Caulk'd surfaces, and whenever you're working on stuff, keep in mind that every unused surface should be returned to Caulk. This is not a ''must''. But you'll bite your own ass one day if you want to squeeze all possible FPS out of your map, so you'll want to Caulk everything, but didn't take care all the time to prevent unnecessary textures. I've been there.<br /> <br /> Press ESC to deselect the box. Now click on it in 3D, but this time, hold SHIFT and CTRL. '''You just selected a surface.''' The texture browser is right under the 3D view. Doubleclick on &quot;arachnid2&quot;, wait till all textures are loaded, then click on the first texture that you can see: &quot;001metal&quot;. Yay, '''you painted the surface'''. The texture in the texture browser does have a red border now. This means that this is the current texture. Without changing the preferences to &quot;new brushes have Caulk&quot;, every new brush you make would have the red bordered texture. But believe me that you'll later find out yourself that you don't want to go that way. Next to the big texture with the red border, there is &quot;arach_fog_s&quot;, a '''texture with a white border'''. Textures with white borders are [[shader]] textures. Shader textures are not just images, they can even have functions, for example they decide whether a brush textured with them is made of water that you can swim in - or slime/lava that kills you.<br /> <br /> Remember the folders you made in the &quot;base&quot; folder? The pictures you see in the texture browser are stored in the folder &quot;textures&quot; or in one of its many virtual versions - I am speaking of the texture folders in all those .pk3 files. They are treated as if they were really existing folders/files. Which means that it's easy to have a file with the same path and file name existing several times, something impossible in the normal file system (may I remind you that I speak from the Windows perspective). '''You should read the [[.pk3]] article''' because it contains important information on how to deal with this. It's really tricky, and you don't want to go through the process of finding out the hard way. Things that can happen if you fail here: Your map can cause other maps to malfunction. Or your map will be incompatible with older versions of itself. Or it will not function the way it did on your computer. By the way - if you wonder where the textures of all those maps you might have downloaded and played until now are: On my machine (Windows), I have ''several'' &quot;base&quot; folders. One is somewhere in the system user area. If you want to use the textures of those maps, too, move them into the &quot;base&quot; folder where the program is installed. And no, you don't have to unpack the .pk3 files to use their contents in NetRadiant. But if you're a mapping beginner, you shouldn't have other files in your installation &quot;base&quot; folder than the ones that actually came with the Tremulous installation (and the Radiant Tremulous support file). Reason: Later, you'll make a .pk3 release pack, and you have to put all files into it that people will not have from the default installation, so have fun figuring those out when your &quot;base&quot; folder is polluted and you're a beginner.<br /> <br /> In the beginning, you will probably use the textures/shaders/sounds etc. that are part of the original Tremulous 1.1.0 pack. '''You don't have to deliver Tremulous 1.1.0 standard files with your map''' because you can assume that everyone has those. I don't know about the Tremulous 1.2 world that is about to emerge, though. But until now, it's the right way to go, and many people have done so. It's accepted. It keeps your map file small. And it means less file- and folder-hassle for you.<br /> <br /> '''Let's save the map.''' NetRadiant doesn't know a name yet, so it will show you a box where you can enter a name. The folder (&quot;maps&quot;) should already be set. Or did you forget to make the folder? You can leave the name &quot;unnamed&quot;, I mean, why call it &quot;terror castle zero&quot; when you don't even know how to make one. From now on, you can just press CTRL+s to save the map. And from time to time, go to the folder window (outside NetRadiant) and '''make a backup of the map file''' (e.g. by copying and pasting it into the same place). Too much garbage in the folder? Learn to live with it. You don't want to live with lost data. '''Maps can get broken in weird ways.''' If you know how to debug them, good. Otherwise, go to an older version and start over. Example: Maybe you know that a map file is just a human readable text that you can open in any text editor. If you open a more complex map, you'll see that it only consists of [[entity|entities]] which in turn sometimes have parameters and/or brushes. Now, one of the bad things that can happen (because NetRadiant is really just a rudimentary editor that allows to make maps but which is really far from being a reliable pro tool) is that an entity that needs brushes (as for example a door - the brush(es) are the moving door) loses all of them. Such a map would not run in Tremulous. To fix such a situation, you would have to use a text editor, locate the erroneous entity and fix or delete it (which is not hard but also not for beginners). Or you'd go back to a previous map version. And no matter how experienced you'll be one day, there will sometimes be problems that you cannot fix. For example: I had a map once with one telenode. The Tremulous client, though, behaved as if there were two. But there was only one. That's easy to verify because the node can be searched for in the text file. I even searched in the compiled map: Only one telenode. Well, the system is not free from bugs, and this is what can happen. Because I was already so far into the map, I had to test-delete many brushes, compile, run - still one telenode too many. Again. And so forth. After a day, the problem was fixed even though the elements that I finally found out to delete and remake didn't have anything to do with the telenode and also didn't seem broken. Also, the telenode problem was absent in some of my delete runs - even though it was different stuff that I had deleted.<br /> <br /> Another word on backups: If you're not a total computer noob, you use archiving software from time to time. But &quot;ZIP&quot; is not the archive format of choice (except of course to make .pk3 files, those have to be ZIP, but you can create that with other archivers, too). [http://www.win-rar.com/downloadnow.html RAR] is very good (but not free, so there's a nag screen or you have to pay). But the best one currently (even though it doesn't support recovery records - haven't really needed those till today, anyway) is [http://www.7-zip.org/ 7z], and it's free. There are also versions for Linux etc. (search yourself). So, why do I mention all this? Well, if you have a bunch of backup copies of your map file (which will eventually outgrow the 1 mb limit, can even reach 20 mb), you'll quickly have tons of &quot;wasted&quot; space. But don't delete the backups if you're not absolutely perfectly sure that you won't need them any more! Just compress them. They compress very well, to about a 10th of their size. And if you use a ''modern'' archiver instead of ZIP when compressing like 20 backups into one archive, the archiver will not just squeeze down every map backup individually, but it will take into account that most parts of the files are equal. That's called a &quot;solid archive&quot;. Unpacking stuff out of them is a bit annoying because oftentimes, the whole archive has to be calculated through for one file. But who cares. So: Just pack all your backups into one archive from time to time. Instead of 100 mb &quot;wasted&quot; space, you'll only have like 1 mb! And you will have all backups of your map! I do it like this for every map individually: &quot;backups till 2010-06-29.7z&quot; and so forth. Makes you sleep better.<br /> <br /> The last word on backups: It's not enough to just backup the map onto the same machine. That is only for the work process in case something gets broken or you need to copy an object from an earlier version that doesn't exist in the current one. No, you also need to backup your files from your PC to another medium. That doesn't really belong into this article because every serious computer user should do that from time to time anyway. But I'd like to mention that here. What I do (apart from backing up my whole machine onto extra harddisks that I then put away somewhere from time to time): I have all mapping relevant files in the Tremulous install folder. And so, I just make a 7z archive of the whole folder tree once a week or so, and I copy it onto a USB stick. I don't know how reliable those are, but my experiences have been good so far. You'll sleep better if you know that the hundreds of mapping hours are safe somewhere.<br /> <br /> Let's go back to our brush. Press ESC to deselect the surface. Then SHIFT and left-click the brush to '''select it in the 2D view'''. Yes, in the 2D view. You can also hold SHIFT and the left mouse button, drag a box that touches the brush you made, and release both. That's the '''box selection'''. Another thing you can do (but you can't really test now because you only have one element in your map) is to SHIFT and left-click in the 2D view and also hold the ALT key. This selects one of the things that are in the position that you click at, just as the normal SHIFT and left-click does. But if you do this several times, the first selection is deselected, and something else in the same place is selected instead. Very useful function to '''toggle through all the stuff in that place.''' Less useful is the fact that it is buggy - sometimes, you have to move the mouse a bit to make the program allow you to use this function again. Box-selection (SHIFT and left-click, drag, release) is also possible in the 3D view (also the SHIFT-ALT-click toggle-through-stuff function), and only the elements currently in view will be selected - so you'll probably enable far-clip-plane from time to time (preferences, &quot;camera&quot;), adjust its distance (menu &quot;view&quot;, submenu &quot;camera&quot;), enabling you to easily select a group of objects (for example a truckload of lights that you used to slightly paint the light situation without people noticing) in front of you while the things behind them are too far away to be visible or get selected.<br /> <br /> If you have a look at the menu &quot;view&quot;, submenu &quot;filter&quot;, you see that you can '''filter''' the 2D and 3D view for the many different kinds of things and thing-groups that a map can consist of. This will be very useful for selecting. And for not getting distracted/confused. Also, displaying the graphics in the editor is faster if less stuff is being drawn, obviously. If you see anything in the filter list activated right now, select the lowest point &quot;reset filters&quot; which will turn everything off - so that you can see everything that exists in the 2D and 3D view. Another way of '''making stuff temporarily invisible''' is the '''hide function'''. Make sure your brush is selected. Then press the &quot;h&quot; key. Bang, it's gone. You can hide all kinds of elements. If you want everything to be visible again, press SHIFT &quot;h&quot;. Filters and hide have no influence on the map functionality, they are not even stored in the map file. When you close NetRadiant and open it again, the previous filter settings are still active which can be confusing at times. The hidden stuff, though, is visible again. By the way: Did you notice the - - - - - line at the top of the menu? If you click that, the menu will be opened in a window that does not go away when you select something in it. Very useful.<br /> <br /> Another very important function that can be toggled on and off is the &quot;'''texture lock'''&quot; function. There is a button with a lock picture for that somewhere at the top right of the screen. When it's active, it should actually blink and play a loud HONK!-sound all the time or something. And when NetRadiant is closed and opened again, it should be deactivated. But all of this does not happen. So, '''you have to take care whether or not the texture lock function is activated'''. Here is what it does: When it's not on, the textures on a brush seem to scroll around when you move the brush around. That is because the textures are normally locked to the world position. This is very practical, as you will find out with time. Now, the &quot;texture lock&quot; function changes that: When you drag a brush while that function is activated, the textures of the brush will move with it. That is very useful in cases where you have made a brush or several brushes with specific texture work (for example light fixtures), and you want to move those brushes without the design to change. Be aware whether or not the function is activated. You will remember this text here for sure. Because you will at some point see textures in wrong positions, realizing: &quot;Damn, I moved brushes around with texture lock on! Why isn't that function automatically turned off when I start the program?&quot; The texture lock function also changes the behavior of textures when you use the rotate-brush-by-90-degrees function.<br /> <br /> Remember when I called your brush a floor or ceiling? That's because the 2D view shows a view from the top (or bottom, depends on how you think) on the map when the program opens. Press CTRL and TAB. If nothing weird is going on with your input focus and keyboard (which can happen from time to time), the '''2D view was just switched from &quot;top view&quot; to &quot;side view 1&quot;'''. Do that again, and it changes to &quot;side view 2&quot;. Once again, and you're back at &quot;top view&quot;. You can determine what view you're currently on by looking at the little right angle labeled &quot;z&quot; and &quot;y&quot; or &quot;x&quot; and &quot;y&quot;, you get the picture. You'll probably determine that later by rather looking at the map, though. It's helpful/important to learn that the vertical axis is the Z axis. If you can currently see the X and Y axis, you're looking along the Z-axis (meaning: from the top).<br /> <br /> Now, let's finally get to '''how to move and scale a brush:''' Make sure the brush is selected. In the 2D or 3D view, click on the brush, hold the button, move the mouse, release the button. You just moved the brush (if the grid versus the amount of mouse movement didn't prevent this). Moving it in the 2D view makes sure that it is not moved along the axis that is pointing directly towards you. Moving it in the 3D view is comfortable, but can have unwanted results because of the fact that the camera is &quot;never&quot; perfectly aligned with the three space axes. To scale the brush instead of moving it, do the same, but don't click inside of it. Instead, click beside it. Important: Don't scale it too small so that it vanished. I have no idea what happens then. I always hit &quot;undo&quot; in such a situation. Might be a map-breaker.<br /> <br /> '''The grid''' is very important. In most cases, brushes should be perfectly aligned with grid points. Otherwise, have fun debugging your map. To '''change the grid scale''', press one of the number keys from 1 to 9. You can also do that in the grid menu. You'll do that from time to time, because, believe it or not, the grid spacings below 1 are actually used sometimes. The current grid spacing can be seen at the bottom of the NetRadiant window, on the right side. Careful with the key &quot;0&quot;: It toggles the grid from visible to invisible (and back). On a side note: I hope that the NetRadiant developers will be nice and implement a feature that draws the grid with thicker lines (e.g. 3 instead of 1 pixel) because it's simply invisible with all the stuff in front of it on more complex maps, and that sucks considerably.<br /> <br /> '''A word about world units / grid size / reactor and overmind etc.:''' It will take a while until you have memorized all the building and player sizes. Until then, just memorize this: An opening or room with the size '''128x128x128''' (second largest grid setting (&quot;8&quot;)) is just high and certainly wide enough to contain the overmind or reactor (112 would be enough). Tyrants etc. fit through nicely (96 would be enough). Those numbers might not really tell you anything, but any long-time computer user knows the drill: 1 2 4 8 16 32 64 128 256 512 1024 2048 4096 8192 16384 32768 65536 ... You should know those numbers up to 256 to be more efficient with NetRadiant. And 96 is three elements of the size 32, '''96 is just high enough for a tyrant''' to get through. '''64x64x64''' is big enough for a dragoon. A human can still crawl through a height of 32, if I am not mistaken. '''If you want to make a stair, 16 is a nice step height.''' Though 16 might seem a bit big on closer inspection since it's theoretically half a meter.<br /> <br /> Make sure that your brush is selected. Then, press CTRL and C, then CTRL and V, or use the &quot;edit&quot; menu. The '''brush exists now twice in the same place''', a common error that can cause weird map behavior, yet a situation that you will intentionally create many many times, because it's often useful to take an existing brush and copy/paste it somewhere else. At this point I should remind you: Keep everything Caulk'd that cannot be seen by the player. Ok, now press ESC. Yes, keep the two brushes in the one place for now.<br /> <br /> Travel to the side of the brush that shows the &quot;001metal&quot; surface. Select it (SHIFT CTRL left-click). Now go to another texture section. Not &quot;arachnid2&quot; but instead &quot;common&quot;. Most of the '''textures in the &quot;common&quot; group''' are actually shaders, as you know already because you saw the white borders around them. The one called &quot;caulk&quot; is among the first. It should have a green border because the currently open map uses it in at least one place. Click on &quot;caulk&quot;. This applies the caulk shader to the surface you selected. It also gets the red border because it's now the current texture, which is unimportant to us because all our new brushes have caulk, not the current texture. The &quot;common&quot; textures are really useful. There is, for example, a shader called &quot;ladder&quot;. Any vertical surface that you apply this texture to can be climbed. It's really that simple. Well, to make an actual ladder, build something that looks like it can be climbed, then make a brush with the ladder shader around / in front of it. The ladder shader is invisible, but you can't walk though it. There is also a texture called &quot;clip&quot; which you'd sometimes use to invisibly even out too odd wall and floor situations. The dretches will thank you. The players who don't get stuck while running away from the beasts will thank you, too. Some of the textures/shaders of the &quot;common&quot; section can be used without you having to distribute these shaders with your map (like for example the &quot;caulk&quot;, &quot;ladder&quot; and &quot;clip&quot; shaders), but it's best to just add these few bytes to your map file. Better safe than sorry. Ironically, the &quot;invisible&quot; shader, for example, would cause '''&quot;missing texture&quot; optics''' (Missing textures in the game are gray with a big white grid. Hard to miss. Easy to miss, though, if your testing environment is improper, because then you'll not have missing textures, but the players will.) if the Radiant Tremulous support files are not present, so put them into the release file. A .pk3 without those shaders will of course work on your machine - because you have the &quot;data-radiant-1.1.0.pk3&quot; in your &quot;base&quot; folder! Others do not have this.<br /> <br /> '''Get to know the phenomenon called [[Z-fight]] (or Z-fighting):''' Press ESC to deselect. Now, select &quot;the&quot; brush (doesn't matter which one, but just one of them, Wassily), so SHIFT left-click on it. Now for the important part: Move the brush a bit. Not too much. You'll see that the copy (or the original, you never know which one you'll click if there are several in one place) is revealed by you moving the other one. Don't move it too far - they should still overlap. Now, study the area in which the textured face of the one brush and the Caulk'd face of the other brush are drawn in the same place. Move the camera around a bit. If you've done everything right, then you are just observing a Z-fight. Two surfaces want to have the same distance from the observer and fight about it. No one wins, especially not the spectator/player. For historical reasons, the distance an object has from the camera is called the z-distance. You could also read up on the term &quot;[[Z-buffer]]&quot;.<br /> <br /> It is very probable that you will get to see Z-fighting somewhere during one of your many testruns of your maps. You can even find those in finished maps that can be found on many servers. I can remember at least one z-fight in a professional map that came with Tremulous 1.1.0 ([[Nexus6]]). Ironically, right now, there is nothing wrong about your map in that regard. Because one of the two surfaces that are fighting has the Caulk shader - which is defined to be invisible. There would be no z-fighting in your map right now.<br /> <br /> '''Mirroring and rotating:''' Select one of the brushes and toy around with the 6 buttons at the top left of the NetRadiant window. The first one is &quot;x|x&quot; and mirrors the brush along the x axis. I find it irritating that the Radiant developers chose to mirror the brush ''along'' the x axis instead of using the x axis as the, well, mirror axis, but you'll get used to that. The button next to that is the rotate-around-x-axis button, and that actually works like you'd expect it. Depending on the grid-versus-brush situation, the position of the brush gets changed accordingly, too, so later, you'll adjust the grid spacing before rotating a brush around 90 degrees. Mirroring does not care about the grid, just about where the brush begins/ends. If the &quot;texture lock&quot; is active, the textures get rotated and mirrored accordingly. Nice one. But if you rotate a brush using &quot;arbitrary rotation&quot; (menu &quot;modify&quot;), the textures will not be rotated with it, no matter if the &quot;texture lock&quot; was active or not. &quot;arbitrary scale&quot; (same menu), though, scales the textures (if &quot;texture lock&quot; is on).<br /> <br /> Left of the &quot;texture lock&quot; button, there is another (currently selected) button with a rectangle inside of it. If you hover your mouse above it, it'll say &quot;Resize (Q)&quot;. That's your normal brush draw/move/resize tool. Two buttons to the left, there is the &quot;Rotate (R)&quot; tool. Select it and rotate your brush a bit. This is the same as &quot;arbitrary rotation&quot;, only it's handled with the mouse instead of numbers. Don't forget to switch back to &quot;Resize&quot;.<br /> <br /> Now a quick tour of '''dealing with entities''': In the &quot;view&quot; menu, select &quot;entity inspector&quot; (or press &quot;n&quot;). There are several sections in that new window that appeared, and you might have to vertically scale those sections a bit before use. The most important area in that window is the one saying &quot;classname worldspawn&quot;. If there is no such text visible, you probably don't have a brush selected at the moment. Select one (or several, doesn't matter now). If there's still no text &quot;classname worldspawn&quot; in the window, you have to scale and move stuff in the window around a bit. The &quot;most important area&quot; with said text is not the lowest part of the window, but it's the lowest big white box in the entity inspector. Once you've found it, click on the text &quot;classname worldspawn&quot;. You'll see that, once you've selected it, the text &quot;classname&quot; appears below the area in a textbox labeled &quot;key&quot;, &quot;worldspawn&quot; in the &quot;value&quot; box. The '''key-value-principle''' is very important. The area in which you selected the key-value-pair will later have more key-value-pairs. These are the properties of the entity that you've currently selected. Wait, a brush is an entity? Well, if you deselect the brushes with ESC, &quot;classname worldspawn&quot; is no longer visible in the entity inspector window (only as a relict in the &quot;key&quot; and &quot;value&quot; input text boxes). So, every brush is an entity with the text &quot;classname&quot; in it? No. All brushes are one combined entity. The entity's name (And it's better to think of this as a type, not as a name. Later, you will have several entities with &quot;classname&quot; &quot;light&quot;, so it's obviously not just a name but really a type.) is &quot;[[worldspawn]]&quot;, a term mappers toss around oftentimes. Every map has min. and max. one worldspawn. It's the first entity in the .map file (if you look at it with a simple text editor.) The worldspawn can have very important settings regarding the map, for example the amount of buildpoints the teams have, or you can add a little message that is displayed while the map loads. The text area above the &quot;most important area&quot; describes which keys and values can be used for the world spawn. Once you select a different type of entity in the 2D or 3D view (or in the area at the top of the entity inspector, where all possible entity types are listed), the help text changes.<br /> <br /> When dealing with the entity inspector, be careful what you have selected in the map. It's possible to select a brush (usually part of the one &quot;worldspawn&quot; entity) and another entity type, for example a &quot;light&quot;. This flexibility can be useful, but if used improperly, it's a big source for errors. '''Always be aware of what's selected before using any function.'''<br /> <br /> Now, let's use an entity we haven't used before: Select one (or all) of the brushes. Then, right-click in the 2D view. A menu should appear. If it didn't, try again without moving the mouse even the slightest bit. In the menu, go to the item &quot;info&quot;, and from the new submenu, select &quot;info_player_intermission&quot;. This creates a little box of that entity type. Also, the brush(es) that were selected have gone, replaced by the new entity. You better undo that and remember this effect for later, because if you're dealing with a somehow broken map later, it might have been caused by the action that was just demonstrated. But everything should be fine if you use &quot;undo&quot; on such an action. Ok, now press ESC to deselect everything, and then create the entity anew. What is it good for? Well, it defines the position and orientation of the spectator camera when you enter a map or leave a team. '''The &quot;info_player_intermission&quot; entity is absolutely essential. Without it, a map does not work in Tremulous!''' The &quot;info_alien_intermission&quot; and &quot;info_human_intermission&quot; entities have a similar function (camera position and orientation when you're on a team and are currently not alive), but they are not technically necessary. You'll of course place them when you're making a real map.<br /> <br /> You can use the &quot;arbitrary rotation&quot; or the mouse rotate tool to change the direction into which the player_intermission camera is facing.<br /> <br /> Man, I almost forgot THE LOG. Move the mouse to the bottom of the window directly above the status line (that's the area with several texts and horizontal segments). There should be a handle looking like ............ Click and drag it up. You should now see the log. Sadly, you'll have to do that again next time the program is opened. The log shows the actions the program performs (and errors that happened). Have an eye on the log when you map, it'll save you a few map-repair-sessions because you'll see that something you wanted to do didn't work out, or something was done that you didn't expect and so forth.<br /> <br /> There are more NetRadiant explanations in the other sections of this mapping crash course.<br /> <br /> ==making your first (ultra basic) map==<br /> <br /> ===create the map===<br /> <br /> Now that you know how to handle the most important functions of NetRadiant, let's make a map, violating all rules, offending all experienced mappers. In the &quot;file&quot; menu, select &quot;new map&quot;. If a window appears asking you if you want to save the current map, you're doing it wrong because you should have saved the map already a few times with at least one or two backups. Ok, it's a worthless map that you wouldn't really save or backup often, but I want to give you an idea of how to deal with a real map.<br /> <br /> Press CTRL and TAB until the 2D view shows the X and Y axes, so you're '''looking from the top. Press the key &quot;9&quot; to have the largest grid spacing.''' If the grid is invisible, press &quot;0&quot;. If that doesn't make the grid visible, then it probably was not invisible before but just too big for your current zoom (use mouse wheel and maybe &quot;0&quot;). Read on once the grid is visible and also on its largest setting (displaying &quot;G:256&quot; at the bottom of the window).<br /> <br /> '''Create a brush in the 2D view, exactly one grid block in size.''' The numbers on its right and bottom size read &quot;256&quot; if you've done it right. Assuming that 32 world units are one meter, this brush is a nice 8 by 8 meters floor. Which is also 8 meters thick, by the way. But who cares. It's not like we're wasting concrete or something.<br /> <br /> The brush is pink, yes? Otherwise, shame on you. Now, move the camera in the 3D view so that you can see the top of the brush. Select the top face (CTRL SHIFT left-click, don't just SHIFT left-click it or you'll select the whole thing). Go to the &quot;arachnid2&quot; texture section and click the first texture (&quot;001metal&quot;). '''The top surface now has this texture.'''<br /> <br /> Press ESC to deselect everything. Then right click in the 2D view, and select &quot;team_human_spawn&quot; from it. Press ESC again, call the menu again, and select &quot;team_alien_spawn&quot;. Press ESC again, call the menu again, and select &quot;team_player_intermission&quot;. Great! '''Now you have all the three essential elements''' that you need to have a working Tremulous map. But there is a problem: '''If the spawns are not in a proper place''', they might not get created when the map loads. So, move the egg and the node around until they stand somewhere on the box. Make sure that there is enough distance between the two. Also, have a look at them from the side: They must not be too close to the surface of the box or they will not get created when the map loads. You can really place them quite high (Be reasonable.) above the surface. When the map loads, they will be created in that spot and then fall down to the surface (without taking damage). To move the entities around, you have to set the grid to a higher resolution. Just blindly hit one of the left digit keys for a high resolution, which one doesn't matter at the moment. By the way: Too many people ''in the game'' fail to place the spawns in the right rotation. It's easy: The player will spawn to face the position from which you made the spawn. Makes sense: That position can be assumed to be a valid place to go. Making spawns in the right rotation can influence the game flow positively.<br /> <br /> Please check if the surface on which you are trying to put the spawns is the one you have textured. If not, then you did something wrong earlier when texturing it. Spawns cannot be rotated in the editor in the way that they can be put on walls or something, so it's not the spawns that are wrong. By the way, you can '''rotate the spawns''' around the high axis (Z) to define the direction into which the player will look when he spawns. The human spawn, at least the one in the editor, has the aparatus-thingy on the side into which you will spawn. The egg spawns you into the direction the red axis at the egg's center points. The human spawn does so, too, but the aparatus-thingy is easier to see.<br /> <br /> Ok, we have a floor with a texture, both teams have a spawn, and the player_intermission camera does also exist (maybe you want to move and rotate it around a bit until it will probably show something meaningful, but it's not necessary for the map to run).<br /> <br /> What's missing? Light! ESC, 2D, rightclick, '''select &quot;light&quot;'''. A text box appears. Make sure that the number inside of it is &quot;100&quot;. That's the brightness of the light. Click ok or press RETURN. Pressing RETURN is not always advised: The &quot;arbitrary rotation&quot; dialog, for example, will not do anything then. Now move the point light you created until it is in the middle above the box brush. For that, press &quot;8&quot; to set the grid to the second largest spacing. Now it's easy to move the light to the middle. Seen from the top, it must be in the middle. Seen from the side, it must be one grid step above the floor. With setting &quot;8&quot;, that's 128 world units - 4 meters.<br /> <br /> ===build the BSP file and run it===<br /> <br /> If you have not yet saved the map, shame on you. Also, do it now. The name should be &quot;unnamed&quot;. Then, close NetRadiant. '''Because now we'll play the map!'''<br /> <br /> If you're a lucky Windows user, you'll have downloaded and configured q3map2build, I hope. Start that program, select the map &quot;base\maps\unnamed.map&quot; that you've just created, make sure that &quot;Play after build&quot; (left border of the window) is activated - and then click &quot;build&quot;!<br /> <br /> Alternatively, if you are not using this nice frontent for q3map2, you can create a batch file. The program does nothing different, only it's more comfy, and the texts displayed when you hover the mouse above the many switches certainly make things more clear. So, if you don't use the program, create a batch file. That's a normal text file with commands in it that has to be renamed to &quot;somethingsomething.bat&quot;. Sadly, those mega-idiots at Microsoft chose to hide file extensions (stuff like &quot;.bat&quot;) by default, so you can't rename the whole file name, only everything except the extension. For this reason and overall security improvement, Windows users are urged to turn the display of file extensions on. In any file explorer window, go to the &quot;Tools&quot; menu, select &quot;Folder Options&quot;. At the top of that new window, click on &quot;View&quot; and then scroll down until you see the option &quot;Hide extensions for known file types&quot;. Turn it off and click &quot;Ok&quot; at the bottom of the window.<br /> <br /> Here's the text for the batch file:<br /> <br /> &quot;C:\Program Files\netradiant-20100214-win32\q3map2.exe&quot; -fs_basepath &quot;C:\Program Files\Tremulous&quot; -fs_game &quot;base&quot; -custinfoparms -info -meta -patchmeta &quot;C:\Program Files\Tremulous\base\maps\unnamed.map&quot;<br /> &quot;C:\Program Files\netradiant-20100214-win32\q3map2.exe&quot; -fs_basepath &quot;C:\Program Files\Tremulous&quot; -fs_game &quot;base&quot; -vis -saveprt &quot;C:\Program Files\Tremulous\base\maps\unnamed.map&quot;<br /> &quot;C:\Program Files\netradiant-20100214-win32\q3map2.exe&quot; -fs_basepath &quot;C:\Program Files\Tremulous&quot; -fs_game &quot;base&quot; -light -bouncegrid -custinfoparms -filter -patchshadows -bounce 500 -bouncescale 2 &quot;C:\Program Files\Tremulous\base\maps\unnamed.map&quot;<br /> Pause<br /> &quot;C:\Program Files\Tremulous\tremulous.exe&quot; +set fs_basepath &quot;C:\Program Files\Tremulous&quot; +set fs_game base +devmap &quot;unnamed&quot;<br /> <br /> The line &quot;Pause&quot; is not necessary, though it can be useful to have the process wait between calculating and playing. q3map2build has options to insert &quot;pause&quot;, too. I once had the computer calculate a map for four days in a row, and I had &quot;Play after build&quot; unchecked because why should I &quot;burn&quot; my machine uselessly? This means that after calculating, the machine would just have closed the system's console text box without me being able to read the text. This makes the &quot;pause&quot; feature seem much less superfluous all of a sudden. Of course I could have saved the console output into files automatically (by adding &quot; &gt; outputtext1.txt&quot; to the end of the first line, and bla 2 3 4 to the other lines), but then again I wouldn't have been able to have a look at the console text because it would just have been in the files.<br /> <br /> You'll probably have to adapt the batch file text to suit your computer/setup.<br /> <br /> Doubleclick the batch file to start the compile.<br /> <br /> One of the things that will appear in the text window (which is the system's console text output) is &quot;LEAKED&quot;. Well, we didn't give the map a proper shell, we just made a floor. Doesn't matter at the moment, but later, we'll have to improve on that.<br /> <br /> Well. If everything went right, you're playing the smallest map in the world. And everything around your little world is pitch black. Or you see the [[hall of mirrors]] effect around you, really annoying. But it's a working Tremulous map!<br /> <br /> I bet you want to experiment now. Do that. But don't yet make a big map that kinda asks to be published, people are probably not going to like it. You have to learn some more first.<br /> <br /> <br /> <br /> <br /> <br /> ==making your second (more advanced) map==<br /> <br /> ===choose a name===<br /> <br /> You can freely create folders in the &quot;map&quot; folder, doesn't hurt the game system. So, you should make a folder and throw all files into it that have been created so far.<br /> <br /> Now, open NetRadiant (or select &quot;new map&quot; from the &quot;file&quot; menu if it was already open). Save this empty map. Reason: '''We want to give it a name.''' Press CTRL and S (or select &quot;save&quot; or &quot;save as&quot; from the file menu). The name shall be ... wait, what's your nick name? The name you use as a player or in the forums? If it were &quot;God, maker of the world&quot; (which is my nick name), we could make a short version of that, for example &quot;gmotw&quot;. Let's assume that your nick name is &quot;scrollbar5&quot;. A shorter version would be &quot;scr5&quot; or something. Let's stick to that. Back to naming the map: Please save it as &quot;scr5_dretchnest&quot;. If you actually have a nick name that you want to stick to and that can be nicely expressed with a few letters, use that from now on. I'll keep calling it &quot;scr5_...&quot;.<br /> <br /> You see where I'm heading. I called my first map [[Gmotw_Skybox|&quot;gmotw_skybox&quot;]], and this is not mainly about people attributing the map to my person (or so that all my maps would be in one alphabetical place in the huge map repositories that exist, hehehe) but instead so that I could freely choose my map names without having to worry about the name maybe already existing - or someone else taking the same name. I have not yet seen anyone do it like this, but I think this is actually the way it should be done by everyone, and so I tell my helpless scholar prey (Not really.) to do it just like that. '''Add a short version of your nick name with a &quot;_&quot; at the beginning of your map names.''' Keep it short, though. It's good if this prefix &quot;doesn't make sense&quot;, so it's not confused to be a part of the map's real name. So, &quot;gmotw_&quot; (Hey, that's mine.) is better than &quot;stellar_&quot;. By the way, if you look at the screenshot in the skybox article, you read the message &quot;Remove older versions of Skybox to prevent texture problems.&quot; which is really lame. You won't have problems like this since you can read my experiences and conclusions in this mapping guide. Comfy, no?<br /> <br /> If you use these prefixes, by the way, '''NetRadiant will nicely group all your map assets''' in the texture browser instead of spreading them all around the alphabetical map list.<br /> <br /> If you've read the [[.pk3]] article (which you should at some point), you'll already know about the '''filename uniqueness problem''' and about how to deal with it through several release versions of your map. We have halfway solved the uniqueness problem by choosing &quot;scr5_dretchnest&quot; (or whatever your prefix is), which is probably a name not yet taken. Except if 10 people go through with this mapping crash course without choosing a different prefix. But I wonder if anyone's gonna read it at all :/<br /> <br /> A word about &quot;alpha&quot;, &quot;beta&quot;, and &quot;final&quot; releases: BULLSHIT! That was actually just one word. No really: I think it's a meme or an &quot;I'm doing it just like the real guys! I feel like I'm taking a step into a larger world!&quot;-thing that people release their maps as alpha, beta, and final. Well, it has practical reasons, but it also has its problems. To make it short (meaning: I just deleted about 300 words of bla that I was about to save, and that was just the half of it.): Just give your releases a number. So, just add &quot;_001&quot; to the map name. Three digits seems to be much, but you never know. If you increase the release number every time you make a .pk3 and test it with friends or on the server of a guy you know, you'll quickly be above 9, and with all the stuff you have to keep in mind, you don't want to worry about the goddamn number. And once you have chosen to use the path of the &quot;_001&quot;... instead of the &quot;_a01&quot;... &quot;_b01&quot;... &quot;_final&quot;, you'll laugh at all the mappers who have decided to make their maps a &quot;final&quot; too early. &quot;Oh, something's still broken. Damn, already released as 'final'. Can't change it now.&quot; Weird people anyway. I mean, what makes you so sure that you will never add something to the map in a year or so? And then you have the other guys who are more careful. They make their alphas, then you find their betas in the wild... but there is never a &quot;final&quot;. Guess why. The last beta effectively ''is'' the final. Not changed after years. Assimilated by the community. No, you don't want to play that game. '''Just give your releases a number. Just a stupid counter suffix like &quot;_001&quot;.'''<br /> <br /> So, we're about to create a map. The &quot;next&quot; release of it will of course be the first, so its name is &quot;_001&quot;. (I should add that &quot;release&quot; in this context does not mean that you give it to the Mercenaries' Guild Map Repository and brag about it in the forums or something. I am just talking about a proper .pk3 file that you can test on servers.) When people callvote for it, they'd type:<br /> <br /> &quot;/callvote map scr5_dretchnest_001&quot;<br /> <br /> While we're at it: The .pk3 file of this (as can be read in the [[.pk3]] article) would be named<br /> <br /> &quot;map-scr5_dretchnest_001-1.1.0.pk3&quot;<br /> <br /> The name of the .pk3 file has nothing to do with the callvotes. But the name should be kept equal to the real map name for consistency reasons.<br /> <br /> If you're using the batch file solution, please '''edit the batch file just now''' to use &quot;scr5_dretchnest_001&quot; instead of &quot;unnamed&quot;. Reason: So that it hurts if you change the prefix or map name later. Get used to this. Of course, you can theoretically rename a map a hundred times before releasing it the first time, but we want to train here. If you decide to wait with the batch file editing, you're technically making the right choice in case you rename later, but you should experience the name lock, it'll help your mind to get into the real mapper world. Also, all following steps will make use of the map name and cement it some more, and '''you do not want the asset folders and the map to have different names. It's enough hassle as it is, and this would double the file naming work.'''<br /> <br /> By the way, how did I come to the name &quot;dretchnest&quot;? Ok, it's not rocket science, but you'd think that about most map names ''once they exist''. Obviously, I thought of Tremulous elements. What you can do to come up with a map name depends on whether you create it at the beginning, in the middle, or at the end of the mapping process. For example, when I came up with &quot;dretchnest&quot;, I had no idea what exactly the map should be like (other than something with 4 walls that you are supposed to clip diagonally in the corners). I only grabbed a name out of the clouds to complete this section. '''But now that I have a name, it gave me ideas about the map.''' Actually ideas that are ill placed in a beginner's mapping guide, so I'm probably not gonna put them into action here, but here they are: There would be a rectangular (Duh. Beginners always make box maps.) room with a few eggs. The room would be closed from all 6 sides, but there would be openings at the bottom, small enough for dretches to get out. Maybe there would have to be contraptions against crouching humans, maybe that would have to be done by basecamping dretches. If you spawn as granger, you can't get out, so maybe I would have added a trigger that checks if you're granger - and kills you. The ceiling of the room would be something that can be set in motion somehow with a button or by making a building or by reaching a certain spot or by reaching stage 3 etc., and this ceiling would squish the eggs in the room. Since there are no other eggs and grangers cannot get out, the aliens would have lost the game (if the aliens still alive don't win it). This is obviously not a standard Tremulous map, but I digg stuff like this (Trem has enough standard maps, lets bring something new to the table). Read the [[Gmotw_Skybox|skybox]] article if you don't know what I mean. That was my first map, by the way.<br /> <br /> &quot;dretchnest&quot; would have been a fitting name for the above described map. See? '''The name idea resulted in a map idea.''' I believe that it's usually the other way round. But it's improbable that the mapper does not decide for a name until the map is completed, because you'd need to test the map from time to time, and so you'd come up with a name to make a release file. (I repeat: The name you choose once you publish the map should never change, if you can somehow make it so.) Once the name is chosen, the name will probably feedback into the mapping process (e.g. you'd want it to be justified, the least you would do is add fitting decorations).<br /> <br /> '''How you can come up with a map name''': I speak english and german, so when I am thinking about the map that I already created a bit, I think of its prominent building and gameplay elements, enter those terms into a Web translator (like [http://dict.leo.org dict.leo.org]) in english or german, and then I play '''translation ping pong'''. You can also use a Web '''thesaurus''' for that. There are also '''map name generators''' on the Web, probably not Tremulous-specific. You'd rather want to use them for inspiration (and to fuel your translator and thesaurus attempts), not to really make the name for you.<br /> <br /> ===make a shader and a texture===<br /> <br /> Now, go to your Tremulous &quot;base&quot; folder. '''Create a new folder in the folder &quot;textures&quot;.''' Name: &quot;scr5_dretchnest&quot;. Why not &quot;scr5_dretchnest_001&quot;? Because then you'd have to re-assign all textures on every new release because the foldername changes. The project you're working on is &quot;scr5_dretchnest&quot;, and that's the name the asset folders should have. You can also make a folder like this in the &quot;sound&quot; folder, but I currently don't plan on talking about adding a sound. But this is the way it would work for sounds, too.<br /> <br /> If you want to add shaders (which we will do - it's easy if you know how), you have to add the release number again. Reason: The shaders are not several files stored in a new folder, like textures will be. No, the shaders of a map are little text blocks that are all stored in one text file. (You can also make several files, but let's keep this simple.) And '''if you change the contents of the shader file for a new release, you have to give that file a new name.''' Just as if you would have to give a texture a different name that you change from one release to the next. If you don't do this, your map will be incompatible with older versions of itself. You can be lucky with that. But lets do this properly. Use this knowledge. Imagine you had to gather this knowledge by experience which I had to... urgh!<br /> <br /> So, the texture folder is prepared. But '''lets make a shader first.''' Go to your Tremulous &quot;base&quot; folder into the folder &quot;scripts&quot;. Create a new text file called &quot;scr5_dretchnest_001.shader&quot;. If we add a shader into it, it will appear in NetRadiant the next time you start it. Well, you'd think so, but for some reason only the programmers know, you have to add an entry in the &quot;shaderlist.txt&quot; file in the same folder. At the end of that file, add &quot;scr5_dretchnest_001&quot; (without &quot;.shader&quot;), press return, save and close the file. Now open the &quot;scr5_dretchnest_001.shader&quot; file again and put the following text into it, save and close the file:<br /> <br /> textures/scr5_dretchnest/brightglass_001_s<br /> {<br /> qer_editorimage textures/scr5_dretchnest/brightglass_001.jpg<br /> qer_trans .5<br /> surfaceparm trans<br /> surfaceparm solid<br /> cull disable<br /> {<br /> map textures/scr5_dretchnest/brightglass_001.jpg<br /> tcgen environment<br /> blendfunc gl_one gl_one<br /> rgbGen identity<br /> }<br /> {<br /> map $lightmap<br /> blendFunc gl_dst_color gl_src_color<br /> rgbgen identity<br /> }<br /> }<br /> <br /> Close NetRadiant. Open it again and load the empty map file you created. If you look at the texture browser now, you'll see an entry called &quot;scr5&quot;. Now, how did that happen? Oh, the stupid nick name prefix idea! Yes, NetRadiant interprets names with a &quot;_&quot; in it differently. It creates categories. So, all your maps will be under the category &quot;scr5&quot; instead of being spread around like crazy.<br /> <br /> Unfold the category by clicking on the little triangle on its left side. &quot;scr5_dretchnest&quot; appears. It does so for two reasons: 1. You created a folder with that name in the textures folder. 2. You created a shader that in turn created the virtual (= not really existing) file &quot;textures/scr5_dretchnest/brightglass_001_s&quot;, so another reason why NetRadiant would think that the folder exists.<br /> <br /> The texture browser should now show an element called &quot;brightglass_001_s&quot;, something like a blue-black checkerboard, expressing that the image which was to be shown here can not be found. No wonder - we didn't make that one yet. And that's a bit tricky, because I don't intend to explain any graphics software to you now. '''You'll just ''somehow'' have to come up with a .jpg file that has power-of-2 dimensions''' (you know... 1 2 4 8 16 32 64 128 and so forth, computer numbers, as mentioned earlier in this article, though obviously, a texture with ''anything'' on it and the size of 32x32 or smaller hardly makes sense), I'd say 128x128 should be the choice here, that's enough for a simple reflection picture (which this one is). Textures don't have to be quare, by the way, but let's keep this one simple. Also, I think that a texture with an arbitrary size (not power-of-2) would work, too - but what &quot;would work&quot; is not the question. What surely will work in all Tremulous clients and with all graphics cards, that's the question.<br /> <br /> The jpg quality doesn't need to be maximum for a texture. &quot;high&quot; (60) or &quot;very high&quot; (80) (as they are called in Photoshop) is good enough. &quot;medium&quot; is too low in nearly all cases, I'd say. You know what would be nice? An actual screenshot you take yourself in Tremulous. Cropped and sized to 128x128 or bigger, util max. 2048x2048 for a normal texture and, I'd say, max. 512x512 for a reflection texture, but that's plenty. By the way: The bit depth per color channel must be 8, as most existing image files are. You can use 16 and even 32 bit in Photoshop etc., but not in the game. While we're at it: You can also use .tga pictures. If you know when to use gif/png versus jpg, then you know when to use tga versus jpg. Example: If you need a simple color texture (pure red, no other pixels), then .tga is the perfect choice. Tga supports an 8 bit alpha channel (save as 32 bit then, not 24 bit) and also a simple and lossless compression that can be used with Tremulous.<br /> <br /> So, assuming that you have somehow found a suitable .jpg file (.tga (even compressed) would also work, but I think you have to change the shader text then, though I believe that I have seen that the file extension named in the shader is irrelevant, but better safe than sorry), move / rename it to achieve this name: '''&quot;textures/scr5_dretchnest/brightglass_001.jpg&quot;'''.<br /> <br /> Again, close and open NetRadiant and feast your eyes on the new contents of the &quot;scr5_dretchnest&quot; texture browser category. Well, your image should be there now. Twice even. WTF? Well, one instance is from the actual file in the texture folder, and the other one is the shader you created. '''Now you see why the shader ends in &quot;_s&quot;: This prevents the names from colliding.''' (Adding &quot;_s&quot; is the way everyone does it.) See? Naming is a really delicate subject!<br /> <br /> So, before we finally start making the goddamn map, let me explain the shader we've created:<br /> <br /> The first line creates the virtual file by giving it a path and filename. Again, take care of those file names, be they virtual or real. The brackets don't need explanation, I guess.<br /> <br /> The &quot;qer_editorimage&quot; line is irrelevant for the game, but it gives our shader a nice image in NetRadiant. If you apply this shader to a wall, instead of the ugly &quot;no pic!!1&quot; texture, you now see your nice .jpg image. Half transparent even! That is caused by the &quot;qer_trans&quot; line, which is also irrelevant for the game. It's there purely for the editor. And both these lines are not necessary for editing. Later, you can add &quot;//&quot; to the beginning of these two lines, which means that they are &quot;commented out&quot;. Anything behind &quot;//&quot; is arbitrary text until the line ends. I don't know, though, if a comment can be written on the right end of a shader command. If you comment these two lines out later, when you've actually used the shader in the map, and restart NetRadiant, you'll probably realize that they are not technically necessary, but man do you want them to be there.<br /> <br /> &quot;surfaceparm trans&quot; says that the surface is transparent. This does not mean that you can look through it - it only means that ''the computer'' can look through it! Yes, he has to know, too. A later command will make the shader transparent for us humans, too. As the name said: It's a glass shader.<br /> <br /> &quot;surfaceparm solid&quot; says that the surface is solid. You cannot walk/fall/shoot through it.<br /> <br /> &quot;cull disable&quot; means that the opposite side of a brush that is completely painted with this shader will not be invisible, as it would be with a normal texture. &quot;culling&quot; means to temporarily remove elements (objects, faces etc.) that are irrelevant for the current situation. To speed things up. But it is disabled here because it's glass, so you can see the presence/absence of backside faces, so they must be there.<br /> <br /> So far, this was the description of how the surface behaves. I'm not the shader pro, so the following explanations might be a little stumbly.<br /> <br /> The next {}block describes the actual graphics that will be drawn. The {}block after that tells the system to also create a lightmap and overlay it.<br /> <br /> &quot;map textures/scr5_dretchnest/brightglass_001.jpg&quot; obviously makes the shader use your new texture file. &quot;tcgen environment&quot; is short for &quot;TextureCoordinateGeneration&quot; with the parameter &quot;environment&quot;. Man, do I have to explain environment mapping now? In short, this makes the texture appear in a way that is not like a normal 3D shape but instead like it were a reflection in the 3D shape.<br /> <br /> &quot;blendfunc gl_one gl_one&quot; means: The pixels of the source (this shader) will be multiplied by one, then added to the destination pixels (which is whatever's already drawn on screen behind the glass) also multiplied by one. So, this just adds your lightened (Remember that this shader has a lightmap.) environmentmap-glasstexture onto the world graphics. Now you might realize why it's called &quot;brightglass&quot;. If you want something darker, look for &quot;textures/tremor/darkglass3&quot;.<br /> <br /> I don't really know about shaders. I look at how the other guys did it (There are already tons of existing shaders, look in the folder &quot;scripts&quot; in the map .pk3 files.), I read a bit in the shader manual, trial and error testing, etc. For example, I have no idea what &quot;rgbGen identity&quot; really does, but it belongs there. If you want to dive into that yourself, read [http://www.heppler.com/shader/ this comprehensive shader manual]. Also, lets drop the rest of the shader explanation and get into mapping, damned.<br /> <br /> ===start making the map===<br /> <br /> Assuming that you're still in NetRadiant with your named map (that doesn't have any stuff in it) open, set the 2D to view from the top, set the gridsize to &quot;9&quot; (256), and draw a square, 8x8 grid elements in size, so it will be 2048x2048 world units. It's not really important where you do this, but since NetRadiant positions the camera at position 0,0,0 every time you load a map (which can somehow be changed with an entity, but I currently don't remember how, saw it in a decompiled ATCS once), I'd suggest that you draw this brush exactly centered around the coordinate 0,0. After you've done so, press CTRL and TAB to set the 2D to view from the side (doesn't matter which). If the brush isn't exactly one grid block high, drag it smaller so that it is. Then move the whole platform so that its upper side (which is the floor to walk on) is at coordinate 0. Unnecessary to say: The whole thing, every face, should have the Caulk shader, the ugly pink one that you already know.<br /> <br /> Copy and paste the selected brush. Click into it and drag it upwards so that its lower side (which will be the ceiling of the map) is at coordinate 256. That's an 8 meters high map hall.<br /> <br /> Press ESC, then draw a square brush left of the two existing brushes, exactly between them. If you press CTRL and TAB, you see that the depth of this square brush is already as we want it because the last selected brush(es) had this depth. Assuming that you're still in the side view in which you drew the square brush, draw another one, on the right side this time. Did you fall for the &quot;something is currently selected&quot; trap, or did you think of pressing ESC yourself?<br /> <br /> Press CTRL and TAB two times to get back to the top view. Now select the two side walls you made. To do that in the 2D view, it's ok to just use the box select in the currently mostly empty map space that we have. So, press SHIFT and then left-click and drag the mouse to select the unselected wall(s). The ceiling and floor (both visible in one place as a big square) must not be selected now! Once you've done that, copy and paste them, then click on the rotate-90-degrees-Z button (a Z with a blue arrow around 90 degrees of the Z). Now you should have a big room with ceiling, floor, and 4 walls. The wall and floor brushes should be edge-on-edge, that will work properly, don't worry. The brushes must not overlap, though! Admittedly, the walls are a bit thick, but they are the outer map walls, so that doesn't matter. Actually, it's not so bad to have them this thick. Why shouldn't they stand out in the editor as a unique structure.<br /> <br /> If you have done it right (which is more probable with this large grid spacing than it would be with a smaller spacing), you should have a proper shell in which you can go crazy without having to worry about [[leaking]]. The [[void]] is properly locked out. The [[VIS]] calculation can hence be performed. You will not have the [[hall of mirrors]] effect.<br /> <br /> Well, yes, you will have the HOM effect, because everything is still Caulk, but we'll change that now. First, select a proper texture: Select &quot;arachnid2&quot;, then scroll down a bit until you see &quot;cement_1_clean&quot;. Now, select all the 6 surfaces that form the room (CTRL SHIFT left-click, and as a NetRadiant user, you'll have learned to press ESC a few times before this new select action, I guess). Then click on the texture.<br /> <br /> '''Save the map. If this is your first save in this &quot;start making the map&quot; chapter, you're still doing it wrong!''' Also, duplicate the saved map file.<br /> <br /> Actually, the floor and ceiling look just wrong this way. Go to the &quot;karith&quot; texture section, scroll down a bit until you see &quot;cement_3&quot;, select only the floor and ceiling face (Not the whole brush, but I guess I don't have to say that any more.) and apply the texture. Save the map. No new backup this time.<br /> <br /> Nice room. If you fly around in it with your camera, you might get the impression that it's too dark. In that case, open the NetRadiant preferences. Don't worry about a message saying that you'd better save before entering the preferences - in most cases, it doesn't matter. Except that saving is usually fast and in most cases not a problem. And if that dialog appeared just now, you didn't save the map when I said so, sinner! :&gt; Go to the preferences section &quot;display&quot;, subsection &quot;textures&quot;, and set the texture gamma to, let's say, 0.8<br /> <br /> ===about clipping, most underestimated by beginners===<br /> <br /> Assuming that the current situation is the result of your actions in the last chapter, you should still be looking from the top in the 2D view. Gridsize should still be largest (key &quot;9&quot;). Now, draw a new brush, 4 grid elements in size, around the 0,0 coordinate. So, the size should be 512x512. The brush should be inside the map shell room that you built, exactly from floor to ceiling.<br /> <br /> We'll use a little trick now. Set the grid spacing to 32 (key &quot;6&quot;). As I said, 32 is the smallest wall thickness you should use if you want to prevent light bleeding. You can be lucky with smaller values or still unlucky with larger ones, but 32 is a good base to work with. I've read somewhere that a thinner wall risks that objects or players might pass through it when playing on the Internet, but I think that's not true, at least I haven't seen problems like these ''ever'' in the Tremulous world, and there are maps with thinner walls around. Another thing about wall thickness: Even a wall with 64 world units might still let the damage effect of a fully charged [[Lucifer Cannon]] shot through a bit. I wonder how much or how little calculation time / network overhead impact it would have meant to prevent this, because this behavior sucks considerably.<br /> <br /> So, with the grid set to spacing 32 and the new 512x512 brush selected, search for the 5th button right of the 90-degree-Z-rotate button. When you hover over it, it says &quot;Hollow&quot;. Alternatively, go to the &quot;brush&quot; menu, submenu &quot;CSG&quot; and select &quot;Make Hollow&quot;. This function is not widely used, because it motivates box rooms (and other reasons, I guess), but right now it's the best thing in the world because it guarantees that you have a new room with 6 walls, all edges ''overlapping'', wall/ceiling/floor thickness 32. (Side note: Why the &quot;hollow&quot; tool doesn't come with the option to automatically clip the resulting brushes is beyond me.)<br /> <br /> Overlapping brushes should be prevented &quot;at all costs&quot;. We'll do that now, too, which brings us to &quot;clipping&quot;.<br /> <br /> Did I say &quot;save the map&quot;? No, and I won't say that any more.<br /> <br /> While still looking from the top, try to select one of the four walls in the 2D view. It's tricky, isn't it? Now you see why you'll select stuff in the 3D view most of the time. But let's try the 2D view again. Press ESC. Then, box-select the middle part of one of the walls (which will also select other stuff). Then, box-select the center of this new room. Shazam, everything except the wall is deselected. Box-select inverts the current selection where it is in effect. Also, nice that we activated &quot;display size info&quot; in the preferences (&quot;orthographic&quot;) before, because now we can clearly see that all elements of the current selection have the position and size of the wall we wanted - which makes it reasonable to assume that only the wall is selected. Once your maps are a bit more complex, that assumption is not so reasonable. I think that it would save the mappers of the world tons of time if there were a simple but prominent number stating how many elements are currently selected. Well, rudimentary tool, as I said. Instead, you can see how many milliseconds it took the 3D view to redraw.<br /> <br /> Now that one wall is selected, choose a different tool. Currently, the button with the square on it is activated (&quot;Resize (Q)&quot;). Activate the button right from it, the one with the diagonal line (&quot;Clipper (X)&quot;). This tool can be used to cut away parts of brushes or to split them into two brushes. Reminder: The preferences of the &quot;clipper&quot; should be set to &quot;Clipper tool uses caulk&quot;.<br /> <br /> You have to cut away a small diagonal part of the wall in the corner. What we want to achieve is that the four walls do not overlap in the corner but do instead end exactly where the next one begins. Yes, you could just use the resize tool for that, but that's not how a good mapper does it (except when it makes more sense than clipping). Imagine: When the walls are clipped in the way I described it, then not just the outer walls will be perfectly connected, but the inner walls, too. So, when you paint textures on them, you can use the &quot;fit&quot; tool of the &quot;surface inspector&quot; (key &quot;s&quot;) to make the texture fit the wall perfectly while you can mostly forget about all the numbers in that window. Or, if you're dealing with the numbers, you can copy them from other surfaces because the other walls have the same special properties (brush corners clipped).<br /> <br /> Well, if you had drawn the walls edge-on-edge like you did with the outer map walls, painting the inner walls would be exactly as easy as the clipped result will be. But we want to paint the outer walls, too! This will be a room visible from the outside, hence it must be properly built.<br /> <br /> So, let's just try to clip one of the corners of the selected wall now. Choose one end of the wall, then click once on the corner that is outside of the room, then on the one that's inside of the room. Two blue dots (&quot;1&quot; and &quot;2&quot;) should have appeared. The line that connects them should point from the outside room corner to the inside of the room. Also, there is another line (the &quot;perpendicular&quot; or &quot;normal&quot;) beginning at the middle of the clip line. Both lines are not existing objects but just editor tools.<br /> <br /> Press ENTER. So, the brush was divided by that clip line you made, and now one of the two parts of the brush is gone. It's the one that the additional line (the &quot;normal&quot;) went through, that's the rule. Which way the &quot;normal&quot; points depends on the order in which you created the clipper points. Also, you can invert the clipper direction (menu &quot;brush&quot;, submenu &quot;clipper&quot;). Also, the brush part that will stay will have the clip face painted blue in the 3D view (as long as you didn't complete the clip by pressing ENTER).<br /> <br /> Clipper tips: You can drag the clip points around on the 2D view. You can even add a third point. You can change the 2D view from top to side etc. and then still drag the points around. And you cannot remove the clip points by pressing ESC. To remove them, you have to select a different tool (like &quot;resize&quot;) and then switch back to the clipper tool. Or just click again once all 3 clipper points are placed, because that will place number 1 again, removing the other two. Only if you click directly on one of them, you can drag them.<br /> <br /> Very frustrating: While the &quot;undo&quot; can be used to return to the unclipped brush, it does not return you to the situation with existing clipper points, so you have to place them anew.<br /> <br /> Now that you kinda know how to work the clipper tools, clip all 8 wall ends diagonally, so that the walls are perfectly face on face, not overlapping any more. So that the inner walls start and end exactly in the inner room corners.<br /> <br /> Wow, finally done with the stupid clipping. Let's paint and resize a few more blocks, right? No. The clipper tool is one of the most important tools in mapping, and you'll use it much more often than you can imagine right now.<br /> <br /> For example: It's time to clip the ceiling and floor so that they diagonally meet the walls - which, thusly, also have to be clipped. In the end, all 6 walls/floor/ceiling of the little room will be kinda like the bottom ends of pyramids pointing into the room, perfectly face to face which each other. During all this, you should leave the grid spacing on 32.<br /> <br /> Done yet? An experienced mapper needs 1 or 2 minutes to finish this properly.<br /> <br /> You might be wondering why we didn't just delete the ceiling and floor of the little room (after all, there's still the outer map ceiling and floor). Reason one: Using a map shell room like we did is a crutch. Not necessarily a bad one, but also not necessarily the way an experienced mapper does it. Reason two: You'd make yourself dependent on the outer ceiling and floor, and once you get out of the room and map some more, you'll have more dependency-situation-possibilities like this. You don't want to tie it all together and stand in your own way. I had that when making skybox. &quot;Can I texture this wall? No, damned, it's the outer wall again.&quot; Reason three: Lightmaps! I don't know how exactly it is decided how many pixels a lightmap has, but I am pretty sure that a huge brush will have a less high resolution (so, rather stretched) light map. Oh, speaking of which:<br /> <br /> ===_lightmapscale, gridsize, turbo rendering===<br /> <br /> (You can skip this now and go to &quot;enjoy the fruits of the clipping labour&quot;. One day, you should read this, though.)<br /> <br /> I already explained the worldspawn. Press ESC and select any one of the brushes. Since we currently only have simple worldspawn brushes (as opposed to, for example, doors), you could also just box-select a bunch of them. Anyway: Press &quot;n&quot; if the entity inspector was not yet visible. As you know, the second section shows a help text for the currently selected entity type, and since the third section shows &quot;classname worldspawn&quot;, the help text describes the worldspawn. Scroll far down (not to the end) until you see the explanation of &quot;_lightmapscale&quot;. Read it. Then, write &quot;_lightmapscale&quot; and &quot;0.25&quot; into the &quot;key&quot; and &quot;value&quot; textboxes and press RETURN while you're in the value textbox. I thoroughly tested it in a relatively small room: Values smaller than 0.25 don't increase the lightmap resolution any more.<br /> <br /> Setting the lightmapscale to 0.25 will result in a higher lightmap resolution, so you'd have better shadows etc., think of the difference between the thumbnail of a picture and the full size version (only the difference is not that drastic here). The default setting is &quot;1.0&quot; (when the _lightmapscale key is not present). 0.25 also means that the LIGHT phase, in which the lightmaps are calculated, will take much longer. This also means that larger settings than 1 will make it shorter.<br /> <br /> If you've followed this mapping crash course so far, you'll either have prepared q3map2 frontend &quot;q3map2build&quot; or a build batch file, and you will have done so that the light rendering result is very good:<br /> <br /> &quot;fast&quot; is not activated. &quot;bouncescale&quot; is on 2, &quot;bounce&quot; is on 500 (meaning: effectively &quot;6&quot; or something). And to top it off, your map now has the best lightmap scale. The option &quot;filter&quot; is not relevant for the calculation time. It will smooth the resulting lightmap a little so that shadow seams don't look so pixeled. I am not repeating all this from other guides, these are actual experiences that I gathered in many tests over months.<br /> <br /> Now, as long as your map is very small, these settings are ok. Calculation will be done in a few minutes or less than a minute. But once your map is a huge monstrosity, calculation with these settings takes several days on a fast computer. That's still ok as long as you have an extra machine for things like these, but '''here's how you can speed up the rendering like crazy''' (resulting in less good result, of course):<br /> <br /> Add the key &quot;gridsize&quot;, value &quot;1024 1024 1024&quot; to your worldspawn (default would be 64x64x128 as far as I know, and to achieve default, just delete the key again). As far as I know, the gridsize defines the ''volumetric'' lightmap calculation. If you get closer to a bright red spot in the map, your weapon will receive red light. If the gridsize is as coarse as we have set it here, those effects will be less prominent. I could be totally wrong about this. Maybe the gridsize is more about how the raytracing really takes place. In any case: Changing the gridsize has ''huge'' (!) impact on the calculation time. Setting it to this value will make it faster. Deleting the key, so that you're back on the (very good) default value makes it slower. Setting the gridsize to something like 48x48x48 increases the calculation time insanely, and as far as my test results go, it doesn't have any merit. So: For high quality results, you'd use the default setting. For quick and less proper results, you use the 1024 (or an even rougher) one.<br /> <br /> You can also drop the &quot;bouncegrid&quot; option. Bouncegrid means that before every radiosity bounce, the lightgrid (see &quot;gridsize&quot;) is calculated anew, because somethingsomething bounce influence grid somethingbla. Honestly, I didn't test the difference it really makes, but I believe that it's safe to assume that this option increases the light rendering quality even further.<br /> <br /> Change the rendering settings (in &quot;q3map2build&quot; or your batch file) so that the LIGHT phase uses the key &quot;-fast&quot;. This does not change the lighting ''very'' much (but still too much for my taste when I want to make a real proper release), but it insanely reduces calculation time.<br /> <br /> Removing the &quot;bounce&quot; option (&quot;bouncescale&quot; is irrelevant for the time (except in regards of the caused number of iterations) and is bound to &quot;bounce&quot;, so you don't have to touch it here) has strong influence on the lighting. You should try to have a few bounces in your released maps, the light looks considerably more natural. Removing the &quot;bounce&quot; option decreases calculation time, though. Very much even. If the initial pass (not yet bounced) takes 10 seconds, every bounce will also take about 10. If the first took 1 day, guess what. Depending on the bouncescale you used, the amount of bounces will have strong influence on the lighting result. This is something for tweaker guys. Just as the &quot;gamma&quot; option (that I didn't mention yet) in the LIGHT phase is. You should know that these options exist and that it's a good idea to toy with them. Now let's move on.<br /> <br /> Another option that you can add to speed up calculation: &quot;-fast&quot; in the VIS phase. Please don't do this, though, if you want to release the results into the public. And definitely don't release the result if you omit the VIS phase completely - which you can also do to decrease rendering time even more. The VIS phase calculates which spot of the map can be seen from which other spot. This information allows the game engine to draw only the necessary graphics. As far as I know, it also influences the radar functions of helmet and aliens. It's essential for a release, and you should do it without &quot;-fast&quot; for a release.<br /> <br /> '''In short:'''<br /> <br /> '''For fast rendering''', add &quot;-fast&quot; to the VIS phase (or drop it completely), add &quot;-fast&quot; to the LIGHT phase, remove &quot;bounce&quot; from the light phase (or just &quot;bouncegrid&quot;, but I think if you're already doing bounces, you might as well do them properly), remove the &quot;_lightmapscale 0.25&quot; thing from the worldspawn, add &quot;gridsize 1024 1024 1024&quot; to the worldspawn.<br /> <br /> '''For best (slow) rendering''', have a not-fast VIS phase, not-fast LIGHT phase, bouncegrid, bounce 500. Remove &quot;gridsize&quot; from the worldspawn. Add &quot;_lightmapscale 0.25&quot; to the world spawn.<br /> <br /> If you want to see a map that rendered for 112 hours with lightmapscale 0.25 and 11 radiosity bounces (Then it was tuesday morning and I needed the computer :/ Yes, you can abort the calculation at any time. Previous bounces will still be existent, and the current half-done one will also not be visible.) and want to see what the higher lightmap resolution might do to a 128MB graphics card, take a look at [[Gmotw_Skybox]]. I'm not really proud of the rendering result. There should be more shadow cast situations and so forth, but it's the best I have to offer in that regard yet. I think the lightmap can best be enjoyed in and above the pump station.<br /> <br /> ===enjoy the fruits of the clipping labour===<br /> <br /> Inspect the result of your work. It's very useful that you can move the camera to the inside of a wall, making it temporarily vanish from the 3D view.<br /> <br /> While you were working on the clipping, I picked a nice texture to demonstrate the described advantages of clipped walls. The texture browser should still be in the &quot;karith&quot; section, showing the &quot;cement_3&quot; texture (near the top). Scroll a bit further up until you see a broad texture called &quot;base_grooved&quot;. (Well, you might have a hard time finding it if there's another texture with a long name to the left of it, because then, the name on screen is partly overwritten. As I said: Rudimentary tool.) It should be the 8th texture. Press ESC and then click on the texture. At the bottom of the screen, there should be a text saying &quot;textures/karith/base_groove...&quot;. The texture looks like someone used a comb on a gray piece of butter from the left to the right.<br /> <br /> Now, select one of the faces inside the little room, then click on the texture. If you have done everything like I described, you'll see the texture on the wall, but there's something like a split in its middle. What you see are the outer ends of the texture. Textures are always looped on the brushes, so now lets place this texture properly. Press &quot;s&quot; (if the surface inspector was not already visible), then click &quot;Fit&quot; (if there is a 1 in both text boxes beside the fit button, otherwise set the boxes to 1 (or 1.000000, it's the same)). That was easy, wasn't it? Imagine what would have happened without the clipping. The texture would be partly hidden. If you look at the surface inspector and the numbers in it, can you imagine the hassle of adjusting everything until it looks like it does now?<br /> <br /> If you look at the horizontal and vertical stretch, you see something between 0.5 and 1 (and they are different - thank the programmers for the &quot;fit&quot; button). That's kinda ok-ish, but smaller values mean higher texture resolution. Only we can't put the texture in twice because that doesn't look good, either. The &quot;width&quot; and &quot;height&quot; value next to the &quot;fit&quot; button, by the way, define how often the texture is to fit the surface when you click &quot;fit&quot;. Yes, &quot;0.5&quot; etc. works, too.<br /> <br /> Paint all four walls in the described manner. You can do them all at once.<br /> <br /> After that, paint floor and ceiling with the next texture in the list, &quot;base_small&quot;, and fit it in 1 by 1. Again, this wouldn't have worked so easily without clipping. The horizontal and vertical stretch are close to 2, which is much too high. You can already see how blurry and cheap it looks. But keep it for now.<br /> <br /> ===let's add a door===<br /> <br /> Look from the top in the 2D view. Set the grid spacing to 128 (key &quot;8&quot;). Select one of the 4 walls. Just for training, let's use the toggle-selection, so press and hold SHIFT and ALT, then click on one of the 4 walls a few times until it is selected. You don't have to press ESC before this.<br /> <br /> With the wall selected and the clipper tool active, click on the wall. Gridwise, it has 4 sections. Click so that 3/4 of the wall would be cut off. Umm, where to put the second clip point? The grid doesn't allow to put it on the wall! Well, doesn't matter. Just put it a bit further away. Only the direction and position of the line itself must be correct, not its length. If you have made a nice (and non-diagonal) clipping line, press SHIFT and ENTER or select &quot;split selection&quot; from the &quot;brush&quot; menu, submenu &quot;clipper&quot;. You have cut the wall into two segments. Do that again on the other side, so that the middle segment is two grid elements in size. By the way, you can join brushes if the result would &quot;make sense&quot; (convex brush) using menu &quot;brush&quot;, submenu &quot;CSG&quot;, item &quot;CSG merge&quot;. If you try to merge brushes that can't be merged, you'll see an error message in the log area.<br /> <br /> Ok, now deselect everything (ESC). Then '''select the middle part of the split wall. Then, right-click in the 2D view, go to &quot;func&quot; and select &quot;func_door&quot;. You just made an automatic door''' that opens to the side if you get close, complete with sound. Nice, huh? Let's change the angle to &quot;top&quot; by adding the key &quot;angle&quot;, value &quot;-1&quot; in the entity inspector.<br /> <br /> You could actually make a door that uses a sensor that only reacts to someone carrying a lucifer cannon. Or to dretches and dragoons. Then, a sound would play and dark light would go bright (without lighting the environment, though (then again, I think it can be done using a shader with specular lighting)). Bars in front of the door would move to the sides (with sound). Then, the door would ''rotate'' open kinda like a garage door. Later, everything would move back. This can really be done using triggers, delays and so forth. But dude, I'm not gonna guide you through that.<br /> <br /> You can adjust the door in the &quot;entity inspector&quot; (&quot;n&quot;). You can change the sound, the direction into which it opens, how much of it is still visible once it's open, whether its default is open or closed, how much damage it does to you if you stand in its way, how fast it moves and more. The &quot;lip&quot; value is especially useful. You know, a door is just a brush (or a bunch of brushes - yes, '''you can make complex designs and have them move as one unit''') that moves. It has convenient defaults and a sensor. But you don't need to use the sensor. Also, '''you can use huge negative values for the &quot;lip&quot;, making the door move much further than necessary when it opens. And what is that then? A lift! :)''' There is also an extra lift function, but its default sounds are broken, and also it cannot be set to &quot;crusher&quot;, as far as I know. The big lift in skybox is a door, consisting of several brushes. '''Doors are really versatile.''' You know what? I once used doors to make a programmable soundtracker in Tremulous (&quot;gmotw_pianolessons&quot;, named like this because there's also a big piano with black and white keys that you can step on, and guess what, they are all doors). 16 doors would hammer down in a sequence, and their &quot;I'm closed now!&quot; sound wouldn't play if they don't arrive at the closed state, so I just made buildings in their way to program the sound steps. Did I say that doors are versatile yet? A server where you can save the current building layout can then even save the rhythm for later! Problem is, once too many elements are used, the rhythm stumbles a bit. Maybe a faster computer or newer Trem client doesn't have that problem. I used 16 steps and 3 instruments (bassdrum, snare, closed highhat), and it already got a bit stumbly. Another thing you can do with a door is use it as a busy-light that appears from out of nowhere (was hidden in a wall) and vanishes once the busy cycle (lift or whatever) is over. Also, I once made a door that actually consisted of 8 by 8 doors that you had to shoot. It was a pixel-door. If you didn't shoot the pixels away fast enough, they would return and you wouldn't get through. A tyrant (or whatever) filter. A dream if you carry a lucifer gun. That was in skybox, but I had to remove it in later releases because with all the other map elements, it reduced the FPS too much. But the door maze is still in the map. Looks like solid walls, but it is a small 2D maze. No, even 3D.<br /> <br /> Now, press &quot;h&quot; to hide the door and move the camera so that you look at the room from the outside. We'll now paint the frame of the door. Use the texture &quot;base_verts&quot; which comes shortly after the &quot;base_small&quot; that we used for floor and ceiling. Select the two faces at the side of the opening. Click the texture. Click &quot;fit&quot;. If you look at the stretch values, you see that one is 0.5 and the other 0.25, which can look odd, so better enter a &quot;2&quot; instead of the &quot;1&quot; in height (next to the &quot;fit&quot; button) and click &quot;fit&quot; again. The texture is now used 2 times in height, so it is not as streched in that direction. Press ESC. Then select the upper and lower face of the opening. Click the texture. Looks wrong. Now what? Well, it needs to be rotated. If you look at the &quot;rotate&quot; text box, there is a &quot;0&quot; in it. The text boxes on the right side can be changed at any time without influencing the map in any way - they are only an editor tool. The box right to &quot;rotate&quot; should have a &quot;90&quot; right now. If so, click the up or down arrow (doesn't really matter now) of the rotate value, changing it to 90 or -90 degrees. The texture looks better now. Click &quot;fit&quot;. Damn, bad stretching. Change the height preference to &quot;4&quot; and click &quot;fit&quot; again. See? The &quot;height&quot; now means &quot;width&quot; because the texture is rotated.<br /> <br /> If you look now from the inside of the room, you'll see that the wall (not frame) texture is cleanly cut, as it should be. If you would want to apply and fit the texture now, you'd have problems. '''To use &quot;fit&quot; on a surface with the &quot;wrong&quot; size, temporarily resize the wall to an appropriate width, click &quot;fit&quot;, return the size to normal again.'''<br /> <br /> Paint the 3 outer walls with the texture we used on the inside walls (for that, select an inside wall surface and use CTRL and C, which will not just copy the texture settings, rotation and so forth, but will also select that texture in the browser, so you can just click it then instead of using paste). Don't forget to fit (1x1). Paint the two short front walls with the texture &quot;base_v_rigged&quot;. Fit them in (1x1). By now, you'll have realized that the textures are sorted by alphabet. <br /> <br /> Press SHIFT h to get the door back. Press ESC. Select the door. Press i or choose &quot;invert selection&quot; from the edit menu. Press h. Now, only the door is visible, and it obviously needs some texturing. Put &quot;base_small&quot; on the outside and inside (fit 1x1).<br /> <br /> The four outer sides of the door are still unpainted. Let's select them all at once and then apply &quot;base_verts&quot;. Fit them 1x1. There's a problem: Even though the stretch values on the side surfaces are different from the top/bottom surfaces, you only see one number pair. Keep that in mind, also when dealing with the entity inspector while several elements are selected. A common reason would be to copy the values of one door to another. Select the correct door first, the one you want to fill with values as second, and for every value that you want to copy, click it and then press ENTER in the &quot;value&quot; text box to re-apply the key-value-pair to the correct door, which will also copy it to the other(s).<br /> <br /> So, let's do this again properly (and maybe you have already realized that this is all wrong, then follow me without acting, also smile). Press ESC. Select both side surfaces. Click &quot;fit&quot; with 1x2, so both stretch values should become &quot;0.25&quot;. Select the top and bottom, rotate the texture by 90 degrees, fit 1x2. Why not 1x4 like the same surfaces of the room walls? Because the surfaces of the room walls didn't begin/end at the door opening! So, we have a few meters of unnecessarily painted faces there. I don't know if a real pro mapper would now fix that by causing a few more brushes or if they would just ignore the few meters of unnecessary texture. We'll just leave it at this now. Don't tell anyone.<br /> <br /> The door is now painted on the front, back, and on the other 4 sides. Unnecessarily. The reason is that we didn't think enough like a mapper should, instead we were stuck too much in real-world thinking. Since you will never get to see the left, right and top side of the door, we should apply the Caulk shader to them.<br /> <br /> The texture browser has a little drop down menu, too. Go into that &quot;view&quot; menu and click &quot;hide unused&quot;. This hides all textures from the texture browser that are currently not used by the map. Even better: Also select &quot;show all&quot; from the same menu. Now, every texture that you had loaded in this program session (except the unused ones because you just hid those) is in the texture panel. You should memorize this trick, it will make your mapping much easier. For example: The caulk shader is here! Apply it to the left, right, and upper surface of the door. Then press SHIFT h to unhide everything.<br /> <br /> Press ESC. Select the door. Go to the entity inspector. Add the key &quot;lip&quot;, value &quot;80&quot; to the door, because otherwise it would look kinda weird while open. A bit of its lower end would stick out of the ceiling without any apparent cavity or mechanism for the door. With &quot;80&quot;, it sticks out so far that no one will ask questions.<br /> <br /> This, by the way, makes another surface's texture unnecessary. Since I don't plan on toying around with the door some more, let's set that surface to caulk, too. So: Hide the door. Then look from the outside. The upper diagonal surface will be invisible because the door will never reveal that surface.<br /> <br /> ===let's populate the map===<br /> <br /> Add an &quot;info_player_intermission&quot; entity. (I won't tell you how because I already did. If you didn't read the whole truckload of text, use the in-page-search function of your browser.) Move and rotate the entity so that it looks at the door of the little room from the outside, from a bit further away, slightly diagonal so that you can see the side wall of the room, too, and much of the rest of the map.<br /> <br /> Press the &quot;1&quot; key for the highest grid resolution that you can achieve with the keyboard. In the room (top view in 2D), create a &quot;team_human_reactor&quot; entity. Move it around a little. Then press &quot;8&quot; for grid spacing &quot;128&quot;. Move the reactor again. You see that the amount by which it moves is 128, as the grid forces it to. But its position is kinda off (if we're not unlucky). To force the reactor back into a nice x y and z grid position, press CTRL and &quot;g&quot; or use &quot;snap selection to grid&quot; in the &quot;brush&quot; menu. Now, with the 128 grid, move the reactor as far into the corner as possible. I don't care which one, as long as it's not on the door side. Switch the 2D to side view, set the grid to &quot;7&quot; (64), drag the reactor to a reasonable height position. It must not be in or above the ceiling and not in or below the floor.<br /> <br /> Rotate it around the Z axis by 90 degrees until the nice control panel can be seen. You might even want to rotate it arbitrarily by 45 degrees and then in 90 degree steps until it nicely faces the room.<br /> <br /> Also build an armory, a medistation, two nodes and a few turrets. Give them enough space. Especially the armory is tricky. Too few people know that '''the game system only allows square [[Hitbox|hitboxes]]'''. The height can vary, but the shape when seen from top is square. Even the armory? '''Yes, even the armory.''' If you keep that in mind, it will explain every occasion on which the armory or a nearby building didn't appear in the game.<br /> <br /> You should already rotate the turrets so that they face the door. This is not a [[Building|base building guide]], so I'll stop here.<br /> <br /> Don't forget to make a few alien buildings (overmind, SPAWN!, ...) somewhere in the outside hall.<br /> <br /> Then add &quot;player_human_intermission&quot; and &quot;player_alien_intermission&quot; (one of each) and make them look at the human and alien base.<br /> <br /> You can have a look at the map if you want, even though we haven't placed any lights yet. Just omit the LIGHT phase. Everything will be at full brightness. The batch file:<br /> <br /> &quot;C:\Program Files\netradiant-20100214-win32\q3map2.exe&quot; -fs_basepath &quot;C:\Program Files\Tremulous&quot; -fs_game &quot;base&quot; -custinfoparms -info -meta -patchmeta &quot;C:\Program Files\Tremulous\base\maps\scr5_dretchnest.map&quot;<br /> &quot;C:\Program Files\netradiant-20100214-win32\q3map2.exe&quot; -fs_basepath &quot;C:\Program Files\Tremulous&quot; -fs_game &quot;base&quot; -vis -saveprt &quot;C:\Program Files\Tremulous\base\maps\scr5_dretchnest.map&quot;<br /> &quot;C:\Program Files\Tremulous\tremulous.exe&quot; +set fs_basepath &quot;C:\Program Files\Tremulous&quot; +set fs_game base +devmap &quot;scr5_dretchnest&quot;<br /> <br /> ===lighting===<br /> <br /> On second thought, you should definitely look at the map right now. With full brightness, it sucks. Once we've added nice lighting, it will look so much more pleasant. Lighting makes and breaks the mood.<br /> <br /> Just as decorations (which we haven't dealt with yet) are not a burden but a passion to a real mapper, lighting is not something to be dealt with by just throwing strong point lights with no apparent light source (fixture) all over the place. And definitely '''''do not'' use the &quot;_minlight&quot; or &quot;_ambient&quot; features in the worldspawn.''' You might use them sometimes - really rarely - to test something, but a map with proper lighting will, I dare to claim, never have one of these features in use.<br /> <br /> '''There are two possible light sources:''' Point lights (which can be made with the right-click menu) and light textures (or light shaders, same thing, different term). We have already dealt with shaders. It's possible to make shaders with a parameter that makes it emit light. The larger the surface that uses the light shader, the more light is emitted. The advantage of using light shaders is that you always have a &quot;something&quot; that the light is actually coming from. This contributes considerably to the mood, because it is more believable. You can, of course, just build a &quot;something&quot; that might be a light, then add a point light source to it. That works, too. Actually, the main reason people rarely do that probably is that you can't group brushes and point lights together. You see, the &quot;worldspawn&quot; entity is not the only &quot;dead&quot; entity that can hold brushes. '''You can also select a bunch of brushes and then select &quot;func_group&quot; from the right-click menu.''' This creates a new entity of type (or &quot;classname&quot;) &quot;func_group&quot;. You cannot add other entities (like light or a doorbrush) to such a group which is sad, because if you could, people would probably also try to construct light fixtures and then just put a point light into them instead of fiddling with shaders. And what is the advantage of such a group? Well, if you select one of its brushes, you can then use &quot;expand selection -&gt; to whole entities&quot; from the edit menu. You can then conveniently move them around or copy/paste of them - which creates a new func_group with the copied brushes in them. The expand selection function also works for several such things in parallel. Sadly, I haven't yet found out how to add another brush to such a group. &quot;regroup&quot; in the &quot;entity&quot; menu does the opposite of what you'd expect, and I haven't tried the next function, &quot;ungroup&quot; because I suspect that it does what you'd expect.<br /> <br /> ===decorations, structural/detail brushes===<br /> <br /> <br /> <br /> ===create a release file===<br /> <br /> <br /> <br /> [[Category:Mapping]]</div> Tue, 13 Jul 2010 13:52:42 GMT God, maker of the world http://tremulous.net/wiki/Talk:Mapping Mapping http://tremulous.net/wiki/Mapping <p>God, maker of the world:&#32;/* obtain a frontend for q3map2 */</p> <hr /> <div>A [[mapper]] is a person who creates a game [[map]]. He is &quot;mapping&quot;. This article describes how that works in the Tremulous context. For a list of a few existing Tremulous maps, click [[:category:Maps|here]].<br /> <br /> <br /> =mapping crash course=<br /> <br /> I started this article on 2010-06-29, just so you know why it doesn't refer to Tremulous 1.2 etc. I am a Windows user (2000 and XP), so that's the perspective that I use. If you can't translate that into your perspective, then you probably shouldn't use the system you're using.<br /> <br /> There are already several mapping guides out there ([http://tremulous.net/forum/index.php?topic=7497.0 list]), one of the best of which is at [http://tremmapping.pbworks.com/ tremmapping.pbworks.com]. It is easy and very comprehensive. I'll try to write a new one from scratch here based on my experiences - and much more up to date. It will save you some steps that were necessary 3 years ago when the linked guide was made. This article here will not enable you to make good maps, but it will give you a truckload of know-how of the kind you don't find in other mapping guides.<br /> <br /> If you've ever written something like a guide, you know that you'll inevitably get into ramble mode from time to time. I guess you can forgive me that.<br /> <br /> <br /> ==setting up your computer==<br /> <br /> ===Tremulous client===<br /> <br /> Download and install the original Tremulous 1.1.0 client. It can be found [http://tremulous.net/files/ here], but it's all over the Web, just search. Now, you ''could'' use a different Tremulous client, but I suggest that you don't. Reason: The original client is what many people out there still use, and when you test your map, you'd want to see what it looks and behaves like (and if it works at all) in the client all those [[newbie|noobs]] use who wouldn't know how to fix a problem if your map causes it. You want your map to work and to shine in the original client. You don't want it to look great only in the latest client with magical rendering v9.9.999 and bloom effect.<br /> <br /> Maybe also download the [http://tremulous.tjw.org/backport TJW backport] client. It's a slightly updated version of the original client. Not too new to violate what I said in the previous paragraph. This is not a full Tremulous release. It's just the program itself. Put it into the program folder of the above mentioned original client. This client supports [[GUID]] and much faster auto-[[Cl_allowDownload|download]].<br /> <br /> You might already have all this. But consider starting anew in a VirtualMachine or on a new computer. If you're more proficient, you'll be able to maybe clean up all your Tremulous base folders so that you don't have magical conditions that a person using the naked client wouldn't have. If you're not proficient enough in this and don't want to make a clean install, prepare to experience problems like &quot;But the texture wasn't missing on my machine!&quot;.<br /> <br /> ===NetRadiant===<br /> <br /> Now the most important part: Download and install [http://ingar.satgnu.net/gtkradiant/installation.html Ingar's NetRadiant and the Tremulous support files]. That's two downloads. The instructions on the linked page are short and comprehensive, it's easy to do. [[NetRadiant]] is the tool that you actually make the maps with. You probably also heard about &quot;GtkRadiant&quot;. Forget it. It's 99% the same as NetRadiant, but it's no longer developed. Also, installation is more complicated because it is not prepared for Tremulous. Additionally, Ingar's NetRadiant already includes the [[Q3Map2]] program that compiles your .map document to a playable .bsp map file.<br /> <br /> Change the NetRadiant preferences (and learn a few things about them): Start it. You'll probably see a little window offering a game type selection. Choose &quot;Tremulous&quot;. There's also a checkbox to prevent this window from appearing every time you start NetRadiant. Technically, that was all. But please, continue adjusting the preferences: Go into the preferences window, which can be found in the &quot;edit&quot; menu at the bottom. I'll go from top to bottom, not from most to least important.<br /> <br /> '''Textures:''' Later, you might want to change &quot;gamma&quot; to something like &quot;0.8&quot; to make the 3D display of the editor brighter. '''Undo:''' Increase queue size to 128. You'll use undo very often, sometimes to undo shifting textures around, and that's an undo step for every texture shift step even if it was a button autorepeat result.<br /> <br /> '''Brush:''' Definitely activate &quot;Always use caulk for new brushes&quot;. You can also activate &quot;Use alternative texture-projection&quot;, but most people do not do that, so if you want to open their maps, you'd have to turn it back off and restart the program. And there is no way to convert a .map from one setting to the other. If you decompile a playable map you found somewhere (like ATCS etc.), you would need to use the alternative projection to load the result in NetRadiant, so why not completely live in that world? I, however, have not done so. Because I didn't know better when I started mapping. I also don't know if I would ever regret turning this option on to make my own maps, so be careful. Maybe better leave it off.<br /> <br /> '''Grid:''' Set default grid spacing to &quot;32&quot;. That's the smallest room-wall-thickness that you want to use to prevent [[light bleeding]] (though the best measure to prevent light bleeding still is clipping). Once you're an experienced mapper, you might want to set this to &quot;256&quot;, the largest setting. '''Camera:''' Movement Speed 100 is good, but you'll come back later and change this, depending on your mapping situation. (I think NetRadiant should have a control element on the edit window to adjust the camera more quickly.) Smaller value for working on details, larger value if you have to travel a lot with your editor camera. Enable far clip plane: It's best to turn it off for now, you'll see everything then, no matter how far away it is. Enabling this option and setting the far plane to something close (menu &quot;view&quot;, submenu &quot;camera&quot;) would be helpful for selecting stuff with the box selection. Also, depending on your hardware and the map, it can speed up display considerably.<br /> <br /> '''Orthographic:''' Turn on &quot;display size info&quot; which will show you the size of one or more selected objects in the 2D view. Turn off &quot;chase mouse during drags&quot;, it would turn you crazy. '''Clipper:''' Definitely activate &quot;clipper tool uses caulk&quot;. '''Autosave:''' Deactivate it. If you're not a total computer noob, you'll know and use CTRL+S oftentimes anyway, and the autosave feature really gets in the way. The coders don't even reset the autosave timer when you hit CTRL+S (lol), so you're better off without it. Saving can take some time on bigger maps, so you want to be in control here. Also, very important: Make backups! Once you saved your map, go into the folder and duplicate the file (CTRL+C, CTRL+V, or whatever it is on your system). Sadly, the Radiant coders didn't include a save rotation like jEdit has it. You have to do that manually.<br /> <br /> Later, when you've worked a bit with NetRadiant, you might want to change the grid colors in the menu &quot;misc&quot;, submenu &quot;colors&quot;. My &quot;grid major&quot; is &quot;#00DF00&quot; (a big fat green) and &quot;grid minor&quot; is &quot;#ADFFAD&quot; (a very bright green, fading into white). Now, you should go into the &quot;view&quot; menu, submenu &quot;show&quot; and activate &quot;show workzone&quot; which will draw additional line garbage in the 2D view - the stuff you have drawn/selected last will have an additional red line pair around it. Makes it easier to find it. You have no idea how confusing the 2D view will become once your map is a bit more complex. Rule of thumb: Before you find the lines in the 2D view confusing, you shouldn't even think about presenting your map to the community.<br /> <br /> ===create the asset folders===<br /> <br /> '''Manually create folders in the base folder:''' You already know the base folder. You extracted the Tremulous support file here as Ingar's website instructed. Now, manually create a folder called &quot;maps&quot;. Also the folders &quot;textures&quot;, &quot;sound&quot; (NOT &quot;SOUNDS&quot;), &quot;scripts&quot;, &quot;env&quot;, &quot;models&quot;. If you have already seen a [[.pk3]] file from the inside, you'll have realized that the folders in those archives are treated by the game client as if they were really existing. So, you'll have guessed what those folders you just made will be used for: They'll hold the exact same kind of files that you see in the .pk3 map files.<br /> <br /> ===obtain a frontend for q3map2===<br /> <br /> If you're on Windows, definitely download [http://www.bobdev.com/q3map2build.php q3map2build]. The program is not necessary to make a playable map, but it's a big help in compiling. NetRadiant already has a build menu which calls q3map2 with parameters, also you could manually create batch files and just launch them every time you want to compile a map, which makes sense if you need very special settings for a map. For example: I worked on a map where I used q3map2's &quot;gamma&quot; option, quite unusual, so you would probably not reconfigure NetRadiant's build menu for that. You'd instead use a batch file. Or q3map2build. This VisualBasic program is a '''frontend for q3map2'''. It creates batch files and executes them. Depending on what you selected, there will be up to four lines in such a file: The first one compiles the binary BSP file from your MAP ascii document. The second one (&quot;[[VIS]]&quot;) calculates what point on your map can be seen from which other point and optimizes the BSP accordingly. Can be omitted oftentimes when you just want to have a look at your map, but for releases, this is absolutely necessary. It's the difference between 1 FPS and 90 FPS. Among other things. And the third line (&quot;LIGHT&quot;) finally calculates the light maps, so everything looks and feels real - without this phase, everything would be at full brightness which totally destroys the mood. The fourth line starts the Tremulous client with your freshly compiled map. Very convenient. '''After downloading q3map2build, you have to configure it:''' Start it. Go to &quot;directory options&quot;. Set &quot;game executable location&quot; to your tremulous.exe. Set &quot;q3map2.exe location&quot; to the file &quot;q3map2.exe&quot; located somewhere in the NetRadiant folder. Click &quot;save&quot;. Open the &quot;game options&quot; window, check the &quot;base mod dir&quot; box and type &quot;base&quot; into the text box. Click &quot;save&quot;. That was the basic setup of the program. '''While we're at it:''' In the little &quot;'''BSP'''&quot; area, select &quot;custom&quot; and click &quot;options&quot;. Activate &quot;custinfoparms&quot;, &quot;info&quot;, &quot;meta&quot; and &quot;patchmeta&quot;. Click &quot;save&quot;. In the little &quot;'''VIS'''&quot; area, select &quot;custom&quot; and click &quot;options&quot;. Activate &quot;saveprt&quot; and click &quot;save&quot;. In the little &quot;'''LIGHT'''&quot; area, select &quot;custom&quot; and click &quot;options&quot;. Activate &quot;bouncegrid&quot;, &quot;custinfoparms&quot;, &quot;filter&quot;, &quot;patchshadows&quot;, &quot;bounce&quot;, &quot;bouncescale&quot;. Enter a &quot;500&quot; in bounce and a &quot;2&quot; in bouncescale. Remember these two options because you will later come back and deactivate them both, instead you will then (Later, as I said.) activate &quot;fast&quot;. Before you click &quot;save&quot;, let me explain what's going on here: These options define how the lightmaps will be rendered. The option &quot;fast&quot; really really increases the speed of the calculations, and you will use it most of the time because it even doesn't change the lighting drastically. But your first map tests will be of so little complexity that the rendering will be fast anyway. The &quot;bounce&quot; option is for radiosity bounces. So, your surfaces will not just have the light that is cast on them by the light sources. Instead, as in physical reality, your surfaces will also have the light that is reflected by the other surfaces. This is, of course, a question of iterations, because once a surface has received light from another surface, guess what: The next time, the light that comes from the surfaces is different. Realistically, 2 or 3 passes do the trick of giving the right impression. 500 passes will never be reached, all light will be used up at pass 5 or 7 maybe, the program will then stop calculating this. You should definitely use radiosity bounces in the maps you publish (if you have the time to calculate them), because they give a much more natural lighting feeling. For example: Colored surfaces will reflect colored light. You get the picture. Just turn this on for now so that you immediatelly collect data in your mind. The parameter &quot;bouncescale&quot; defines the amplification of the bounced light. Theoretically, this should be set to 1 (and hence just be disabled), but I have made good experiences with amplifying the bounces a bit. This causes more radiosity bounces, of course, because the light will not be used up so quickly. It can even happen that the light will not be used up at all. Hey. This is a crash course, not a &quot;click here and you're done, but you stay uninformed&quot; course.<br /> <br /> You might wonder why I don't just use the &quot;build&quot; features in NetRadiant. Because I want to be in control, and I want to be flexible. This crash course will, for example, deal with &quot;amplified radiosity bounces&quot;, the lightmapscale and somesuch. If I had used the build features as presented, I'd still only work with non-amplified bounces, I wouldn't have dealt with the gridsize or the lightmapscale, I wouldn't have used the &quot;filter&quot; feature. Maybe there's still stuff to discover, but I won't discover it if I use the preconfigured built-in buttons. You don't have to go that way, but I won't spare you the ugly details.<br /> <br /> '''So, until now you have installed the Tremulous client, the NetRadiant map editor, the NetRadiant support files, you have configured NetRadiant a bit, you have hopefully gotten your hands on a good q3map2 frontend, and you have created those folders. That's it, now let's go mapping.'''<br /> <br /> ==NetRadiant crash course==<br /> <br /> In Netradiant, move the mouse to the white area with all the confusing lines. Click and hold the left mouse button. Drag the mouse a bit. Release the left mouse button. You just made a floor. Or a ceiling. '''That thing you just made is called a [[brush]].''' This can only be done in the 2D view. Brushes are the building blocks used to make the map world. They can be changed into different shapes and also be drawn directly in different shapes, but most of the time, you'll draw simple box brushes. If you have done everything in the setup section, the box you have just drawn should have a number pair at its left top (position), a number on the right side and a number on the bottom (dimensions). The unit system used is called &quot;world units&quot;. Rule of thumb (that I heard - can't say that I have really verified it) is: 32 world units = 1 meter. There should also be red lines from all four directions leading to the box brush you made. Click and hold the right mouse button. Move the mouse a bit. Release the button. You have just dragged the whole 2D world. Scroll the mouse wheel to zoom. '''You can now navigate the 2D view.'''<br /> <br /> By the way: When you draw a brush, you obviously control its dimensions in both directions, but what about the third? NetRadiant will make the brush as thick as the gridsize is set - unless your work area (the one we made visible via menu &quot;view&quot;, submenu &quot;show&quot;) says different. So, the last thing you had selected (even if it is now deselected) decides how thick your brush will be. You can of course change the size of a brush afterwards, but now that you know this, you'll some day begin to take this effect into account.<br /> <br /> On the right side, you should see a big gray empty space. That's the 3D view. This one is a bit tricky. I hope you have deactivated the far clip plane in the preferences (&quot;camera&quot;) as I've said. Otherwise, the next steps might take you too far away from the box you just drew, and so you would not get to see it. Right click in the 3D view, and release the mouse button. The mouse cursor should have vanished. When you do that again, the mouse pointer returns to normal. With the mouse pointer locked into the 3D view, press the downwards arrow on your keyboard for about one second. After that, move the mouse around in all directions. If you have done everything as I said, you will find an ugly pink box. Congratulations! You've just discovered the world of the mapper: Ugly pink boxes. Much of the mapping process will take place in your head, not in front of your eyes. Experiment with the arrow keys, the mouse movements, the CTRL and SHIFT key, and the mouse wheel in the 3D view. '''You can now navigate the 3D view.'''<br /> <br /> Time for a few keyboard shortcuts:<br /> <br /> Press the ESC key. The box should now look different in the 3D and 2D view because it is no longer selected. In later situations, you'll have to press the ESC key several times in a row to '''deselect stuff''' because some selection modes go deeper into the structure, and every ESC press takes you a step back until everything is harmlessly unselected. And then it looks like it does now.<br /> <br /> To '''select the box''' again, click on it in the 3D view while holding SHIFT. Most of the time, you will select stuff in the 3D view because it's a pain in the ass to do so in the 2D view. NetRadiant still needs much work. Why they didn't include a box selection mode that only selects stuff that completely fits into the box is beyond me. Don't they use their own software?<br /> <br /> Now that the box is selected again, press the BACKSPACE key. You know, the big leftward arrow above the return key. Whoops, '''box deleted'''. Select &quot;'''undo'''&quot; from the &quot;edit&quot; menu or press CTRL+z to get it back again.<br /> <br /> We will now apply a texture to one of the sides of the box. Well, it already has a texture - the name is '''&quot;Caulk&quot;, that's the most important texture of all''', really. You should have this texture applied to every surface that the player cannot see. So, it's best to start with all-Caulk'd surfaces, and whenever you're working on stuff, keep in mind that every unused surface should be returned to Caulk. This is not a ''must''. But you'll bite your own ass one day if you want to squeeze all possible FPS out of your map, so you'll want to Caulk everything, but didn't take care all the time to prevent unnecessary textures. I've been there.<br /> <br /> Press ESC to deselect the box. Now click on it in 3D, but this time, hold SHIFT and CTRL. '''You just selected a surface.''' The texture browser is right under the 3D view. Doubleclick on &quot;arachnid2&quot;, wait till all textures are loaded, then click on the first texture that you can see: &quot;001metal&quot;. Yay, '''you painted the surface'''. The texture in the texture browser does have a red border now. This means that this is the current texture. Without changing the preferences to &quot;new brushes have Caulk&quot;, every new brush you make would have the red bordered texture. But believe me that you'll later find out yourself that you don't want to go that way. Next to the big texture with the red border, there is &quot;arach_fog_s&quot;, a '''texture with a white border'''. Textures with white borders are [[shader]] textures. Shader textures are not just images, they can even have functions, for example they decide whether a brush textured with them is made of water that you can swim in - or slime/lava that kills you.<br /> <br /> Remember the folders you made in the &quot;base&quot; folder? The pictures you see in the texture browser are stored in the folder &quot;textures&quot; or in one of its many virtual versions - I am speaking of the texture folders in all those .pk3 files. They are treated as if they were really existing folders/files. Which means that it's easy to have a file with the same path and file name existing several times, something impossible in the normal file system (may I remind you that I speak from the Windows perspective). '''You should read the [[.pk3]] article''' because it contains important information on how to deal with this. It's really tricky, and you don't want to go through the process of finding out the hard way. Things that can happen if you fail here: Your map can cause other maps to malfunction. Or your map will be incompatible with older versions of itself. Or it will not function the way it did on your computer. By the way - if you wonder where the textures of all those maps you might have downloaded and played until now are: On my machine (Windows), I have ''several'' &quot;base&quot; folders. One is somewhere in the system user area. If you want to use the textures of those maps, too, move them into the &quot;base&quot; folder where the program is installed. And no, you don't have to unpack the .pk3 files to use their contents in NetRadiant. But if you're a mapping beginner, you shouldn't have other files in your installation &quot;base&quot; folder than the ones that actually came with the Tremulous installation (and the Radiant Tremulous support file). Reason: Later, you'll make a .pk3 release pack, and you have to put all files into it that people will not have from the default installation, so have fun figuring those out when your &quot;base&quot; folder is polluted and you're a beginner.<br /> <br /> In the beginning, you will probably use the textures/shaders/sounds etc. that are part of the original Tremulous 1.1.0 pack. '''You don't have to deliver Tremulous 1.1.0 standard files with your map''' because you can assume that everyone has those. I don't know about the Tremulous 1.2 world that is about to emerge, though. But until now, it's the right way to go, and many people have done so. It's accepted. It keeps your map file small. And it means less file- and folder-hassle for you.<br /> <br /> '''Let's save the map.''' NetRadiant doesn't know a name yet, so it will show you a box where you can enter a name. The folder (&quot;maps&quot;) should already be set. Or did you forget to make the folder? You can leave the name &quot;unnamed&quot;, I mean, why call it &quot;terror castle zero&quot; when you don't even know how to make one. From now on, you can just press CTRL+s to save the map. And from time to time, go to the folder window (outside NetRadiant) and '''make a backup of the map file''' (e.g. by copying and pasting it into the same place). Too much garbage in the folder? Learn to live with it. You don't want to live with lost data. '''Maps can get broken in weird ways.''' If you know how to debug them, good. Otherwise, go to an older version and start over. Example: Maybe you know that a map file is just a human readable text that you can open in any text editor. If you open a more complex map, you'll see that it only consists of [[entity|entities]] which in turn sometimes have parameters and/or brushes. Now, one of the bad things that can happen (because NetRadiant is really just a rudimentary editor that allows to make maps but which is really far from being a reliable pro tool) is that an entity that needs brushes (as for example a door - the brush(es) are the moving door) loses all of them. Such a map would not run in Tremulous. To fix such a situation, you would have to use a text editor, locate the erroneous entity and fix or delete it (which is not hard but also not for beginners). Or you'd go back to a previous map version. And no matter how experienced you'll be one day, there will sometimes be problems that you cannot fix. For example: I had a map once with one telenode. The Tremulous client, though, behaved as if there were two. But there was only one. That's easy to verify because the node can be searched for in the text file. I even searched in the compiled map: Only one telenode. Well, the system is not free from bugs, and this is what can happen. Because I was already so far into the map, I had to test-delete many brushes, compile, run - still one telenode too many. Again. And so forth. After a day, the problem was fixed even though the elements that I finally found out to delete and remake didn't have anything to do with the telenode and also didn't seem broken. Also, the telenode problem was absent in some of my delete runs - even though it was different stuff that I had deleted.<br /> <br /> Another word on backups: If you're not a total computer noob, you use archiving software from time to time. But &quot;ZIP&quot; is not the archive format of choice (except of course to make .pk3 files, those have to be ZIP, but you can create that with other archivers, too). [http://www.win-rar.com/downloadnow.html RAR] is very good (but not free, so there's a nag screen or you have to pay). But the best one currently (even though it doesn't support recovery records - haven't really needed those till today, anyway) is [http://www.7-zip.org/ 7z], and it's free. There are also versions for Linux etc. (search yourself). So, why do I mention all this? Well, if you have a bunch of backup copies of your map file (which will eventually outgrow the 1 mb limit, can even reach 20 mb), you'll quickly have tons of &quot;wasted&quot; space. But don't delete the backups if you're not absolutely perfectly sure that you won't need them any more! Just compress them. They compress very well, to about a 10th of their size. And if you use a ''modern'' archiver instead of ZIP when compressing like 20 backups into one archive, the archiver will not just squeeze down every map backup individually, but it will take into account that most parts of the files are equal. That's called a &quot;solid archive&quot;. Unpacking stuff out of them is a bit annoying because oftentimes, the whole archive has to be calculated through for one file. But who cares. So: Just pack all your backups into one archive from time to time. Instead of 100 mb &quot;wasted&quot; space, you'll only have like 1 mb! And you will have all backups of your map! I do it like this for every map individually: &quot;backups till 2010-06-29.7z&quot; and so forth. Makes you sleep better.<br /> <br /> The last word on backups: It's not enough to just backup the map onto the same machine. That is only for the work process in case something gets broken or you need to copy an object from an earlier version that doesn't exist in the current one. No, you also need to backup your files from your PC to another medium. That doesn't really belong into this article because every serious computer user should do that from time to time anyway. But I'd like to mention that here. What I do (apart from backing up my whole machine onto extra harddisks that I then put away somewhere from time to time): I have all mapping relevant files in the Tremulous install folder. And so, I just make a 7z archive of the whole folder tree once a week or so, and I copy it onto a USB stick. I don't know how reliable those are, but my experiences have been good so far. You'll sleep better if you know that the hundreds of mapping hours are safe somewhere.<br /> <br /> Let's go back to our brush. Press ESC to deselect the surface. Then SHIFT and left-click the brush to '''select it in the 2D view'''. Yes, in the 2D view. You can also hold SHIFT and the left mouse button, drag a box that touches the brush you made, and release both. That's the '''box selection'''. Another thing you can do (but you can't really test now because you only have one element in your map) is to SHIFT and left-click in the 2D view and also hold the ALT key. This selects one of the things that are in the position that you click at, just as the normal SHIFT and left-click does. But if you do this several times, the first selection is deselected, and something else in the same place is selected instead. Very useful function to '''toggle through all the stuff in that place.''' Less useful is the fact that it is buggy - sometimes, you have to move the mouse a bit to make the program allow you to use this function again. Box-selection (SHIFT and left-click, drag, release) is also possible in the 3D view (also the SHIFT-ALT-click toggle-through-stuff function), and only the elements currently in view will be selected - so you'll probably enable far-clip-plane from time to time (preferences, &quot;camera&quot;), adjust its distance (menu &quot;view&quot;, submenu &quot;camera&quot;), enabling you to easily select a group of objects (for example a truckload of lights that you used to slightly paint the light situation without people noticing) in front of you while the things behind them are too far away to be visible or get selected.<br /> <br /> If you have a look at the menu &quot;view&quot;, submenu &quot;filter&quot;, you see that you can '''filter''' the 2D and 3D view for the many different kinds of things and thing-groups that a map can consist of. This will be very useful for selecting. And for not getting distracted/confused. Also, displaying the graphics in the editor is faster if less stuff is being drawn, obviously. If you see anything in the filter list activated right now, select the lowest point &quot;reset filters&quot; which will turn everything off - so that you can see everything that exists in the 2D and 3D view. Another way of '''making stuff temporarily invisible''' is the '''hide function'''. Make sure your brush is selected. Then press the &quot;h&quot; key. Bang, it's gone. You can hide all kinds of elements. If you want everything to be visible again, press SHIFT &quot;h&quot;. Filters and hide have no influence on the map functionality, they are not even stored in the map file. When you close NetRadiant and open it again, the previous filter settings are still active which can be confusing at times. The hidden stuff, though, is visible again. By the way: Did you notice the - - - - - line at the top of the menu? If you click that, the menu will be opened in a window that does not go away when you select something in it. Very useful.<br /> <br /> Another very important function that can be toggled on and off is the &quot;'''texture lock'''&quot; function. There is a button with a lock picture for that somewhere at the top right of the screen. When it's active, it should actually blink and play a loud HONK!-sound all the time or something. And when NetRadiant is closed and opened again, it should be deactivated. But all of this does not happen. So, '''you have to take care whether or not the texture lock function is activated'''. Here is what it does: When it's not on, the textures on a brush seem to scroll around when you move the brush around. That is because the textures are normally locked to the world position. This is very practical, as you will find out with time. Now, the &quot;texture lock&quot; function changes that: When you drag a brush while that function is activated, the textures of the brush will move with it. That is very useful in cases where you have made a brush or several brushes with specific texture work (for example light fixtures), and you want to move those brushes without the design to change. Be aware whether or not the function is activated. You will remember this text here for sure. Because you will at some point see textures in wrong positions, realizing: &quot;Damn, I moved brushes around with texture lock on! Why isn't that function automatically turned off when I start the program?&quot; The texture lock function also changes the behavior of textures when you use the rotate-brush-by-90-degrees function.<br /> <br /> Remember when I called your brush a floor or ceiling? That's because the 2D view shows a view from the top (or bottom, depends on how you think) on the map when the program opens. Press CTRL and TAB. If nothing weird is going on with your input focus and keyboard (which can happen from time to time), the '''2D view was just switched from &quot;top view&quot; to &quot;side view 1&quot;'''. Do that again, and it changes to &quot;side view 2&quot;. Once again, and you're back at &quot;top view&quot;. You can determine what view you're currently on by looking at the little right angle labeled &quot;z&quot; and &quot;y&quot; or &quot;x&quot; and &quot;y&quot;, you get the picture. You'll probably determine that later by rather looking at the map, though. It's helpful/important to learn that the vertical axis is the Z axis. If you can currently see the X and Y axis, you're looking along the Z-axis (meaning: from the top).<br /> <br /> Now, let's finally get to '''how to move and scale a brush:''' Make sure the brush is selected. In the 2D or 3D view, click on the brush, hold the button, move the mouse, release the button. You just moved the brush (if the grid versus the amount of mouse movement didn't prevent this). Moving it in the 2D view makes sure that it is not moved along the axis that is pointing directly towards you. Moving it in the 3D view is comfortable, but can have unwanted results because of the fact that the camera is &quot;never&quot; perfectly aligned with the three space axes. To scale the brush instead of moving it, do the same, but don't click inside of it. Instead, click beside it. Important: Don't scale it too small so that it vanished. I have no idea what happens then. I always hit &quot;undo&quot; in such a situation. Might be a map-breaker.<br /> <br /> '''The grid''' is very important. In most cases, brushes should be perfectly aligned with grid points. Otherwise, have fun debugging your map. To '''change the grid scale''', press one of the number keys from 1 to 9. You can also do that in the grid menu. You'll do that from time to time, because, believe it or not, the grid spacings below 1 are actually used sometimes. The current grid spacing can be seen at the bottom of the NetRadiant window, on the right side. Careful with the key &quot;0&quot;: It toggles the grid from visible to invisible (and back). On a side note: I hope that the NetRadiant developers will be nice and implement a feature that draws the grid with thicker lines (e.g. 3 instead of 1 pixel) because it's simply invisible with all the stuff in front of it on more complex maps, and that sucks considerably.<br /> <br /> '''A word about world units / grid size / reactor and overmind etc.:''' It will take a while until you have memorized all the building and player sizes. Until then, just memorize this: An opening or room with the size '''128x128x128''' (second largest grid setting (&quot;8&quot;)) is just high and certainly wide enough to contain the overmind or reactor (112 would be enough). Tyrants etc. fit through nicely (96 would be enough). Those numbers might not really tell you anything, but any long-time computer user knows the drill: 1 2 4 8 16 32 64 128 256 512 1024 2048 4096 8192 16384 32768 65536 ... You should know those numbers up to 256 to be more efficient with NetRadiant. And 96 is three elements of the size 32, '''96 is just high enough for a tyrant''' to get through. '''64x64x64''' is big enough for a dragoon. A human can still crawl through a height of 32, if I am not mistaken. '''If you want to make a stair, 16 is a nice step height.''' Though 16 might seem a bit big on closer inspection since it's theoretically half a meter.<br /> <br /> Make sure that your brush is selected. Then, press CTRL and C, then CTRL and V, or use the &quot;edit&quot; menu. The '''brush exists now twice in the same place''', a common error that can cause weird map behavior, yet a situation that you will intentionally create many many times, because it's often useful to take an existing brush and copy/paste it somewhere else. At this point I should remind you: Keep everything Caulk'd that cannot be seen by the player. Ok, now press ESC. Yes, keep the two brushes in the one place for now.<br /> <br /> Travel to the side of the brush that shows the &quot;001metal&quot; surface. Select it (SHIFT CTRL left-click). Now go to another texture section. Not &quot;arachnid2&quot; but instead &quot;common&quot;. Most of the '''textures in the &quot;common&quot; group''' are actually shaders, as you know already because you saw the white borders around them. The one called &quot;caulk&quot; is among the first. It should have a green border because the currently open map uses it in at least one place. Click on &quot;caulk&quot;. This applies the caulk shader to the surface you selected. It also gets the red border because it's now the current texture, which is unimportant to us because all our new brushes have caulk, not the current texture. The &quot;common&quot; textures are really useful. There is, for example, a shader called &quot;ladder&quot;. Any vertical surface that you apply this texture to can be climbed. It's really that simple. Well, to make an actual ladder, build something that looks like it can be climbed, then make a brush with the ladder shader around / in front of it. The ladder shader is invisible, but you can't walk though it. There is also a texture called &quot;clip&quot; which you'd sometimes use to invisibly even out too odd wall and floor situations. The dretches will thank you. The players who don't get stuck while running away from the beasts will thank you, too. Some of the textures/shaders of the &quot;common&quot; section can be used without you having to distribute these shaders with your map (like for example the &quot;caulk&quot;, &quot;ladder&quot; and &quot;clip&quot; shaders), but it's best to just add these few bytes to your map file. Better safe than sorry. Ironically, the &quot;invisible&quot; shader, for example, would cause '''&quot;missing texture&quot; optics''' (Missing textures in the game are gray with a big white grid. Hard to miss. Easy to miss, though, if your testing environment is improper, because then you'll not have missing textures, but the players will.) if the Radiant Tremulous support files are not present, so put them into the release file. A .pk3 without those shaders will of course work on your machine - because you have the &quot;data-radiant-1.1.0.pk3&quot; in your &quot;base&quot; folder! Others do not have this.<br /> <br /> '''Get to know the phenomenon called [[Z-fight]] (or Z-fighting):''' Press ESC to deselect. Now, select &quot;the&quot; brush (doesn't matter which one, but just one of them, Wassily), so SHIFT left-click on it. Now for the important part: Move the brush a bit. Not too much. You'll see that the copy (or the original, you never know which one you'll click if there are several in one place) is revealed by you moving the other one. Don't move it too far - they should still overlap. Now, study the area in which the textured face of the one brush and the Caulk'd face of the other brush are drawn in the same place. Move the camera around a bit. If you've done everything right, then you are just observing a Z-fight. Two surfaces want to have the same distance from the observer and fight about it. No one wins, especially not the spectator/player. For historical reasons, the distance an object has from the camera is called the z-distance. You could also read up on the term &quot;[[Z-buffer]]&quot;.<br /> <br /> It is very probable that you will get to see Z-fighting somewhere during one of your many testruns of your maps. You can even find those in finished maps that can be found on many servers. I can remember at least one z-fight in a professional map that came with Tremulous 1.1.0 ([[Nexus6]]). Ironically, right now, there is nothing wrong about your map in that regard. Because one of the two surfaces that are fighting has the Caulk shader - which is defined to be invisible. There would be no z-fighting in your map right now.<br /> <br /> '''Mirroring and rotating:''' Select one of the brushes and toy around with the 6 buttons at the top left of the NetRadiant window. The first one is &quot;x|x&quot; and mirrors the brush along the x axis. I find it irritating that the Radiant developers chose to mirror the brush ''along'' the x axis instead of using the x axis as the, well, mirror axis, but you'll get used to that. The button next to that is the rotate-around-x-axis button, and that actually works like you'd expect it. Depending on the grid-versus-brush situation, the position of the brush gets changed accordingly, too, so later, you'll adjust the grid spacing before rotating a brush around 90 degrees. Mirroring does not care about the grid, just about where the brush begins/ends. If the &quot;texture lock&quot; is active, the textures get rotated and mirrored accordingly. Nice one. But if you rotate a brush using &quot;arbitrary rotation&quot; (menu &quot;modify&quot;), the textures will not be rotated with it, no matter if the &quot;texture lock&quot; was active or not. &quot;arbitrary scale&quot; (same menu), though, scales the textures (if &quot;texture lock&quot; is on).<br /> <br /> Left of the &quot;texture lock&quot; button, there is another (currently selected) button with a rectangle inside of it. If you hover your mouse above it, it'll say &quot;Resize (Q)&quot;. That's your normal brush draw/move/resize tool. Two buttons to the left, there is the &quot;Rotate (R)&quot; tool. Select it and rotate your brush a bit. This is the same as &quot;arbitrary rotation&quot;, only it's handled with the mouse instead of numbers. Don't forget to switch back to &quot;Resize&quot;.<br /> <br /> Now a quick tour of '''dealing with entities''': In the &quot;view&quot; menu, select &quot;entity inspector&quot; (or press &quot;n&quot;). There are several sections in that new window that appeared, and you might have to vertically scale those sections a bit before use. The most important area in that window is the one saying &quot;classname worldspawn&quot;. If there is no such text visible, you probably don't have a brush selected at the moment. Select one (or several, doesn't matter now). If there's still no text &quot;classname worldspawn&quot; in the window, you have to scale and move stuff in the window around a bit. The &quot;most important area&quot; with said text is not the lowest part of the window, but it's the lowest big white box in the entity inspector. Once you've found it, click on the text &quot;classname worldspawn&quot;. You'll see that, once you've selected it, the text &quot;classname&quot; appears below the area in a textbox labeled &quot;key&quot;, &quot;worldspawn&quot; in the &quot;value&quot; box. The '''key-value-principle''' is very important. The area in which you selected the key-value-pair will later have more key-value-pairs. These are the properties of the entity that you've currently selected. Wait, a brush is an entity? Well, if you deselect the brushes with ESC, &quot;classname worldspawn&quot; is no longer visible in the entity inspector window (only as a relict in the &quot;key&quot; and &quot;value&quot; input text boxes). So, every brush is an entity with the text &quot;classname&quot; in it? No. All brushes are one combined entity. The entity's name (And it's better to think of this as a type, not as a name. Later, you will have several entities with &quot;classname&quot; &quot;light&quot;, so it's obviously not just a name but really a type.) is &quot;[[worldspawn]]&quot;, a term mappers toss around oftentimes. Every map has min. and max. one worldspawn. It's the first entity in the .map file (if you look at it with a simple text editor.) The worldspawn can have very important settings regarding the map, for example the amount of buildpoints the teams have, or you can add a little message that is displayed while the map loads. The text area above the &quot;most important area&quot; describes which keys and values can be used for the world spawn. Once you select a different type of entity in the 2D or 3D view (or in the area at the top of the entity inspector, where all possible entity types are listed), the help text changes.<br /> <br /> When dealing with the entity inspector, be careful what you have selected in the map. It's possible to select a brush (usually part of the one &quot;worldspawn&quot; entity) and another entity type, for example a &quot;light&quot;. This flexibility can be useful, but if used improperly, it's a big source for errors. '''Always be aware of what's selected before using any function.'''<br /> <br /> Now, let's use an entity we haven't used before: Select one (or all) of the brushes. Then, right-click in the 2D view. A menu should appear. If it didn't, try again without moving the mouse even the slightest bit. In the menu, go to the item &quot;info&quot;, and from the new submenu, select &quot;info_player_intermission&quot;. This creates a little box of that entity type. Also, the brush(es) that were selected have gone, replaced by the new entity. You better undo that and remember this effect for later, because if you're dealing with a somehow broken map later, it might have been caused by the action that was just demonstrated. But everything should be fine if you use &quot;undo&quot; on such an action. Ok, now press ESC to deselect everything, and then create the entity anew. What is it good for? Well, it defines the position and orientation of the spectator camera when you enter a map or leave a team. '''The &quot;info_player_intermission&quot; entity is absolutely essential. Without it, a map does not work in Tremulous!''' The &quot;info_alien_intermission&quot; and &quot;info_human_intermission&quot; entities have a similar function (camera position and orientation when you're on a team and are currently not alive), but they are not technically necessary. You'll of course place them when you're making a real map.<br /> <br /> You can use the &quot;arbitrary rotation&quot; or the mouse rotate tool to change the direction into which the player_intermission camera is facing.<br /> <br /> Man, I almost forgot THE LOG. Move the mouse to the bottom of the window directly above the status line (that's the area with several texts and horizontal segments). There should be a handle looking like ............ Click and drag it up. You should now see the log. Sadly, you'll have to do that again next time the program is opened. The log shows the actions the program performs (and errors that happened). Have an eye on the log when you map, it'll save you a few map-repair-sessions because you'll see that something you wanted to do didn't work out, or something was done that you didn't expect and so forth.<br /> <br /> There are more NetRadiant explanations in the other sections of this mapping crash course.<br /> <br /> ==making your first (ultra basic) map==<br /> <br /> ===create the map===<br /> <br /> Now that you know how to handle the most important functions of NetRadiant, let's make a map, violating all rules, offending all experienced mappers. In the &quot;file&quot; menu, select &quot;new map&quot;. If a window appears asking you if you want to save the current map, you're doing it wrong because you should have saved the map already a few times with at least one or two backups. Ok, it's a worthless map that you wouldn't really save or backup often, but I want to give you an idea of how to deal with a real map.<br /> <br /> Press CTRL and TAB until the 2D view shows the X and Y axes, so you're '''looking from the top. Press the key &quot;9&quot; to have the largest grid spacing.''' If the grid is invisible, press &quot;0&quot;. If that doesn't make the grid visible, then it probably was not invisible before but just too big for your current zoom (use mouse wheel and maybe &quot;0&quot;). Read on once the grid is visible and also on its largest setting (displaying &quot;G:256&quot; at the bottom of the window).<br /> <br /> '''Create a brush in the 2D view, exactly one grid block in size.''' The numbers on its right and bottom size read &quot;256&quot; if you've done it right. Assuming that 32 world units are one meter, this brush is a nice 8 by 8 meters floor. Which is also 8 meters thick, by the way. But who cares. It's not like we're wasting concrete or something.<br /> <br /> The brush is pink, yes? Otherwise, shame on you. Now, move the camera in the 3D view so that you can see the top of the brush. Select the top face (CTRL SHIFT left-click, don't just SHIFT left-click it or you'll select the whole thing). Go to the &quot;arachnid2&quot; texture section and click the first texture (&quot;001metal&quot;). '''The top surface now has this texture.'''<br /> <br /> Press ESC to deselect everything. Then right click in the 2D view, and select &quot;team_human_spawn&quot; from it. Press ESC again, call the menu again, and select &quot;team_alien_spawn&quot;. Press ESC again, call the menu again, and select &quot;team_player_intermission&quot;. Great! '''Now you have all the three essential elements''' that you need to have a working Tremulous map. But there is a problem: '''If the spawns are not in a proper place''', they might not get created when the map loads. So, move the egg and the node around until they stand somewhere on the box. Make sure that there is enough distance between the two. Also, have a look at them from the side: They must not be too close to the surface of the box or they will not get created when the map loads. You can really place them quite high (Be reasonable.) above the surface. When the map loads, they will be created in that spot and then fall down to the surface (without taking damage). To move the entities around, you have to set the grid to a higher resolution. Just blindly hit one of the left digit keys for a high resolution, which one doesn't matter at the moment. By the way: Too many people ''in the game'' fail to place the spawns in the right rotation. It's easy: The player will spawn to face the position from which you made the spawn. Makes sense: That position can be assumed to be a valid place to go. Making spawns in the right rotation can influence the game flow positively.<br /> <br /> Please check if the surface on which you are trying to put the spawns is the one you have textured. If not, then you did something wrong earlier when texturing it. Spawns cannot be rotated in the editor in the way that they can be put on walls or something, so it's not the spawns that are wrong. By the way, you can '''rotate the spawns''' around the high axis (Z) to define the direction into which the player will look when he spawns. The human spawn, at least the one in the editor, has the aparatus-thingy on the side into which you will spawn. The egg spawns you into the direction the red axis at the egg's center points. The human spawn does so, too, but the aparatus-thingy is easier to see.<br /> <br /> Ok, we have a floor with a texture, both teams have a spawn, and the player_intermission camera does also exist (maybe you want to move and rotate it around a bit until it will probably show something meaningful, but it's not necessary for the map to run).<br /> <br /> What's missing? Light! ESC, 2D, rightclick, '''select &quot;light&quot;'''. A text box appears. Make sure that the number inside of it is &quot;100&quot;. That's the brightness of the light. Click ok or press RETURN. Pressing RETURN is not always advised: The &quot;arbitrary rotation&quot; dialog, for example, will not do anything then. Now move the point light you created until it is in the middle above the box brush. For that, press &quot;8&quot; to set the grid to the second largest spacing. Now it's easy to move the light to the middle. Seen from the top, it must be in the middle. Seen from the side, it must be one grid step above the floor. With setting &quot;8&quot;, that's 128 world units - 4 meters.<br /> <br /> ===build the BSP file and run it===<br /> <br /> If you have not yet saved the map, shame on you. Also, do it now. The name should be &quot;unnamed&quot;. Then, close NetRadiant. '''Because now we'll play the map!'''<br /> <br /> If you're a lucky Windows user, you'll have downloaded and configured q3map2build, I hope. Start that program, select the map &quot;base\maps\unnamed.map&quot; that you've just created, make sure that &quot;Play after build&quot; (left border of the window) is activated - and then click &quot;build&quot;!<br /> <br /> Alternatively, if you are not using this nice frontent for q3map2, you can create a batch file. The program does nothing different, only it's more comfy, and the texts displayed when you hover the mouse above the many switches certainly make things more clear. So, if you don't use the program, create a batch file. That's a normal text file with commands in it that has to be renamed to &quot;somethingsomething.bat&quot;. Sadly, those mega-idiots at Microsoft chose to hide file extensions (stuff like &quot;.bat&quot;) by default, so you can't rename the whole file name, only everything except the extension. For this reason and overall security improvement, Windows users are urged to turn the display of file extensions on. In any file explorer window, go to the &quot;Tools&quot; menu, select &quot;Folder Options&quot;. At the top of that new window, click on &quot;View&quot; and then scroll down until you see the option &quot;Hide extensions for known file types&quot;. Turn it off and click &quot;Ok&quot; at the bottom of the window.<br /> <br /> Here's the text for the batch file:<br /> <br /> &quot;C:\Program Files\netradiant-20100214-win32\q3map2.exe&quot; -fs_basepath &quot;C:\Program Files\Tremulous&quot; -fs_game &quot;base&quot; -custinfoparms -info -meta -patchmeta &quot;C:\Program Files\Tremulous\base\maps\unnamed.map&quot;<br /> &quot;C:\Program Files\netradiant-20100214-win32\q3map2.exe&quot; -fs_basepath &quot;C:\Program Files\Tremulous&quot; -fs_game &quot;base&quot; -vis -saveprt &quot;C:\Program Files\Tremulous\base\maps\unnamed.map&quot;<br /> &quot;C:\Program Files\netradiant-20100214-win32\q3map2.exe&quot; -fs_basepath &quot;C:\Program Files\Tremulous&quot; -fs_game &quot;base&quot; -light -bouncegrid -custinfoparms -filter -patchshadows -bounce 500 -bouncescale 2 &quot;C:\Program Files\Tremulous\base\maps\unnamed.map&quot;<br /> Pause<br /> &quot;C:\Program Files\Tremulous\tremulous.exe&quot; +set fs_basepath &quot;C:\Program Files\Tremulous&quot; +set fs_game base +devmap &quot;unnamed&quot;<br /> <br /> The line &quot;Pause&quot; is not necessary, though it can be useful to have the process wait between calculating and playing. q3map2build has options to insert &quot;pause&quot;, too. I once had the computer calculate a map for four days in a row, and I had &quot;Play after build&quot; unchecked because why should I &quot;burn&quot; my machine uselessly? This means that after calculating, the machine would just have closed the system's console text box without me being able to read the text. This makes the &quot;pause&quot; feature seem much less superfluous all of a sudden. Of course I could have saved the console output into files automatically (by adding &quot; &gt; outputtext1.txt&quot; to the end of the first line, and bla 2 3 4 to the other lines), but then again I wouldn't have been able to have a look at the console text because it would just have been in the files.<br /> <br /> You'll probably have to adapt the batch file text to suit your computer/setup.<br /> <br /> Doubleclick the batch file to start the compile.<br /> <br /> One of the things that will appear in the text window (which is the system's console text output) is &quot;LEAKED&quot;. Well, we didn't give the map a proper shell, we just made a floor. Doesn't matter at the moment, but later, we'll have to improve on that.<br /> <br /> Well. If everything went right, you're playing the smallest map in the world. And everything around your little world is pitch black. Or you see the [[hall of mirrors]] effect around you, really annoying. But it's a working Tremulous map!<br /> <br /> I bet you want to experiment now. Do that. But don't yet make a big map that kinda asks to be published, people are probably not going to like it. You have to learn some more first.<br /> <br /> <br /> <br /> <br /> <br /> ==making your second (more advanced) map==<br /> <br /> ===choose a name===<br /> <br /> You can freely create folders in the &quot;map&quot; folder, doesn't hurt the game system. So, you should make a folder and throw all files into it that have been created so far.<br /> <br /> Now, open NetRadiant (or select &quot;new map&quot; from the &quot;file&quot; menu if it was already open). Save this empty map. Reason: '''We want to give it a name.''' Press CTRL and S (or select &quot;save&quot; or &quot;save as&quot; from the file menu). The name shall be ... wait, what's your nick name? The name you use as a player or in the forums? If it were &quot;God, maker of the world&quot; (which is my nick name), we could make a short version of that, for example &quot;gmotw&quot;. Let's assume that your nick name is &quot;scrollbar5&quot;. A shorter version would be &quot;scr5&quot; or something. Let's stick to that. Back to naming the map: Please save it as &quot;scr5_dretchnest&quot;. If you actually have a nick name that you want to stick to and that can be nicely expressed with a few letters, use that from now on. I'll keep calling it &quot;scr5_...&quot;.<br /> <br /> You see where I'm heading. I called my first map [[Gmotw_Skybox|&quot;gmotw_skybox&quot;]], and this is not mainly about people attributing the map to my person (or so that all my maps would be in one alphabetical place in the huge map repositories that exist, hehehe) but instead so that I could freely choose my map names without having to worry about the name maybe already existing - or someone else taking the same name. I have not yet seen anyone do it like this, but I think this is actually the way it should be done by everyone, and so I tell my helpless scholar prey (Not really.) to do it just like that. '''Add a short version of your nick name with a &quot;_&quot; at the beginning of your map names.''' Keep it short, though. It's good if this prefix &quot;doesn't make sense&quot;, so it's not confused to be a part of the map's real name. So, &quot;gmotw_&quot; (Hey, that's mine.) is better than &quot;stellar_&quot;. By the way, if you look at the screenshot in the skybox article, you read the message &quot;Remove older versions of Skybox to prevent texture problems.&quot; which is really lame. You won't have problems like this since you can read my experiences and conclusions in this mapping guide. Comfy, no?<br /> <br /> If you use these prefixes, by the way, '''NetRadiant will nicely group all your map assets''' in the texture browser instead of spreading them all around the alphabetical map list.<br /> <br /> If you've read the [[.pk3]] article (which you should at some point), you'll already know about the '''filename uniqueness problem''' and about how to deal with it through several release versions of your map. We have halfway solved the uniqueness problem by choosing &quot;scr5_dretchnest&quot; (or whatever your prefix is), which is probably a name not yet taken. Except if 10 people go through with this mapping crash course without choosing a different prefix. But I wonder if anyone's gonna read it at all :/<br /> <br /> A word about &quot;alpha&quot;, &quot;beta&quot;, and &quot;final&quot; releases: BULLSHIT! That was actually just one word. No really: I think it's a meme or an &quot;I'm doing it just like the real guys! I feel like I'm taking a step into a larger world!&quot;-thing that people release their maps as alpha, beta, and final. Well, it has practical reasons, but it also has its problems. To make it short (meaning: I just deleted about 300 words of bla that I was about to save, and that was just the half of it.): Just give your releases a number. So, just add &quot;_001&quot; to the map name. Three digits seems to be much, but you never know. If you increase the release number every time you make a .pk3 and test it with friends or on the server of a guy you know, you'll quickly be above 9, and with all the stuff you have to keep in mind, you don't want to worry about the goddamn number. And once you have chosen to use the path of the &quot;_001&quot;... instead of the &quot;_a01&quot;... &quot;_b01&quot;... &quot;_final&quot;, you'll laugh at all the mappers who have decided to make their maps a &quot;final&quot; too early. &quot;Oh, something's still broken. Damn, already released as 'final'. Can't change it now.&quot; Weird people anyway. I mean, what makes you so sure that you will never add something to the map in a year or so? And then you have the other guys who are more careful. They make their alphas, then you find their betas in the wild... but there is never a &quot;final&quot;. Guess why. The last beta effectively ''is'' the final. Not changed after years. Assimilated by the community. No, you don't want to play that game. '''Just give your releases a number. Just a stupid counter suffix like &quot;_001&quot;.'''<br /> <br /> So, we're about to create a map. The &quot;next&quot; release of it will of course be the first, so its name is &quot;_001&quot;. (I should add that &quot;release&quot; in this context does not mean that you give it to the Mercenaries' Guild Map Repository and brag about it in the forums or something. I am just talking about a proper .pk3 file that you can test on servers.) When people callvote for it, they'd type:<br /> <br /> &quot;/callvote map scr5_dretchnest_001&quot;<br /> <br /> While we're at it: The .pk3 file of this (as can be read in the [[.pk3]] article) would be named<br /> <br /> &quot;map-scr5_dretchnest_001-1.1.0.pk3&quot;<br /> <br /> The name of the .pk3 file has nothing to do with the callvotes. But the name should be kept equal to the real map name for consistency reasons.<br /> <br /> If you're using the batch file solution, please '''edit the batch file just now''' to use &quot;scr5_dretchnest_001&quot; instead of &quot;unnamed&quot;. Reason: So that it hurts if you change the prefix or map name later. Get used to this. Of course, you can theoretically rename a map a hundred times before releasing it the first time, but we want to train here. If you decide to wait with the batch file editing, you're technically making the right choice in case you rename later, but you should experience the name lock, it'll help your mind to get into the real mapper world. Also, all following steps will make use of the map name and cement it some more, and '''you do not want the asset folders and the map to have different names. It's enough hassle as it is, and this would double the file naming work.'''<br /> <br /> By the way, how did I come to the name &quot;dretchnest&quot;? Ok, it's not rocket science, but you'd think that about most map names ''once they exist''. Obviously, I thought of Tremulous elements. What you can do to come up with a map name depends on whether you create it at the beginning, in the middle, or at the end of the mapping process. For example, when I came up with &quot;dretchnest&quot;, I had no idea what exactly the map should be like (other than something with 4 walls that you are supposed to clip diagonally in the corners). I only grabbed a name out of the clouds to complete this section. '''But now that I have a name, it gave me ideas about the map.''' Actually ideas that are ill placed in a beginner's mapping guide, so I'm probably not gonna put them into action here, but here they are: There would be a rectangular (Duh. Beginners always make box maps.) room with a few eggs. The room would be closed from all 6 sides, but there would be openings at the bottom, small enough for dretches to get out. Maybe there would have to be contraptions against crouching humans, maybe that would have to be done by basecamping dretches. If you spawn as granger, you can't get out, so maybe I would have added a trigger that checks if you're granger - and kills you. The ceiling of the room would be something that can be set in motion somehow with a button or by making a building or by reaching a certain spot or by reaching stage 3 etc., and this ceiling would squish the eggs in the room. Since there are no other eggs and grangers cannot get out, the aliens would have lost the game (if the aliens still alive don't win it). This is obviously not a standard Tremulous map, but I digg stuff like this (Trem has enough standard maps, lets bring something new to the table). Read the [[Gmotw_Skybox|skybox]] article if you don't know what I mean. That was my first map, by the way.<br /> <br /> &quot;dretchnest&quot; would have been a fitting name for the above described map. See? '''The name idea resulted in a map idea.''' I believe that it's usually the other way round. But it's improbable that the mapper does not decide for a name until the map is completed, because you'd need to test the map from time to time, and so you'd come up with a name to make a release file. (I repeat: The name you choose once you publish the map should never change, if you can somehow make it so.) Once the name is chosen, the name will probably feedback into the mapping process (e.g. you'd want it to be justified, the least you would do is add fitting decorations).<br /> <br /> '''How you can come up with a map name''': I speak english and german, so when I am thinking about the map that I already created a bit, I think of its prominent building and gameplay elements, enter those terms into a Web translator (like [http://dict.leo.org dict.leo.org]) in english or german, and then I play '''translation ping pong'''. You can also use a Web '''thesaurus''' for that. There are also '''map name generators''' on the Web, probably not Tremulous-specific. You'd rather want to use them for inspiration (and to fuel your translator and thesaurus attempts), not to really make the name for you.<br /> <br /> ===make a shader and a texture===<br /> <br /> Now, go to your Tremulous &quot;base&quot; folder. '''Create a new folder in the folder &quot;textures&quot;.''' Name: &quot;scr5_dretchnest&quot;. Why not &quot;scr5_dretchnest_001&quot;? Because then you'd have to re-assign all textures on every new release because the foldername changes. The project you're working on is &quot;scr5_dretchnest&quot;, and that's the name the asset folders should have. You can also make a folder like this in the &quot;sound&quot; folder, but I currently don't plan on talking about adding a sound. But this is the way it would work for sounds, too.<br /> <br /> If you want to add shaders (which we will do - it's easy if you know how), you have to add the release number again. Reason: The shaders are not several files stored in a new folder, like textures will be. No, the shaders of a map are little text blocks that are all stored in one text file. (You can also make several files, but let's keep this simple.) And '''if you change the contents of the shader file for a new release, you have to give that file a new name.''' Just as if you would have to give a texture a different name that you change from one release to the next. If you don't do this, your map will be incompatible with older versions of itself. You can be lucky with that. But lets do this properly. Use this knowledge. Imagine you had to gather this knowledge by experience which I had to... urgh!<br /> <br /> So, the texture folder is prepared. But '''lets make a shader first.''' Go to your Tremulous &quot;base&quot; folder into the folder &quot;scripts&quot;. Create a new text file called &quot;scr5_dretchnest_001.shader&quot;. If we add a shader into it, it will appear in NetRadiant the next time you start it. Well, you'd think so, but for some reason only the programmers know, you have to add an entry in the &quot;shaderlist.txt&quot; file in the same folder. At the end of that file, add &quot;scr5_dretchnest_001&quot; (without &quot;.shader&quot;), press return, save and close the file. Now open the &quot;scr5_dretchnest_001.shader&quot; file again and put the following text into it, save and close the file:<br /> <br /> textures/scr5_dretchnest/brightglass_001_s<br /> {<br /> qer_editorimage textures/scr5_dretchnest/brightglass_001.jpg<br /> qer_trans .5<br /> surfaceparm trans<br /> surfaceparm solid<br /> cull disable<br /> {<br /> map textures/scr5_dretchnest/brightglass_001.jpg<br /> tcgen environment<br /> blendfunc gl_one gl_one<br /> rgbGen identity<br /> }<br /> {<br /> map $lightmap<br /> blendFunc gl_dst_color gl_src_color<br /> rgbgen identity<br /> }<br /> }<br /> <br /> Close NetRadiant. Open it again and load the empty map file you created. If you look at the texture browser now, you'll see an entry called &quot;scr5&quot;. Now, how did that happen? Oh, the stupid nick name prefix idea! Yes, NetRadiant interprets names with a &quot;_&quot; in it differently. It creates categories. So, all your maps will be under the category &quot;scr5&quot; instead of being spread around like crazy.<br /> <br /> Unfold the category by clicking on the little triangle on its left side. &quot;scr5_dretchnest&quot; appears. It does so for two reasons: 1. You created a folder with that name in the textures folder. 2. You created a shader that in turn created the virtual (= not really existing) file &quot;textures/scr5_dretchnest/brightglass_001_s&quot;, so another reason why NetRadiant would think that the folder exists.<br /> <br /> The texture browser should now show an element called &quot;brightglass_001_s&quot;, something like a blue-black checkerboard, expressing that the image which was to be shown here can not be found. No wonder - we didn't make that one yet. And that's a bit tricky, because I don't intend to explain any graphics software to you now. '''You'll just ''somehow'' have to come up with a .jpg file that has power-of-2 dimensions''' (you know... 1 2 4 8 16 32 64 128 and so forth, computer numbers, as mentioned earlier in this article, though obviously, a texture with ''anything'' on it and the size of 32x32 or smaller hardly makes sense), I'd say 128x128 should be the choice here, that's enough for a simple reflection picture (which this one is). Textures don't have to be quare, by the way, but let's keep this one simple. Also, I think that a texture with an arbitrary size (not power-of-2) would work, too - but what &quot;would work&quot; is not the question. What surely will work in all Tremulous clients and with all graphics cards, that's the question.<br /> <br /> The jpg quality doesn't need to be maximum for a texture. &quot;high&quot; (60) or &quot;very high&quot; (80) (as they are called in Photoshop) is good enough. &quot;medium&quot; is too low in nearly all cases, I'd say. You know what would be nice? An actual screenshot you take yourself in Tremulous. Cropped and sized to 128x128 or bigger, util max. 2048x2048 for a normal texture and, I'd say, max. 512x512 for a reflection texture, but that's plenty. By the way: The bit depth per color channel must be 8, as most existing image files are. You can use 16 and even 32 bit in Photoshop etc., but not in the game. While we're at it: You can also use .tga pictures. If you know when to use gif/png versus jpg, then you know when to use tga versus jpg. Example: If you need a simple color texture (pure red, no other pixels), then .tga is the perfect choice. Tga supports an 8 bit alpha channel (save as 32 bit then, not 24 bit) and also a simple and lossless compression that can be used with Tremulous.<br /> <br /> So, assuming that you have somehow found a suitable .jpg file (.tga (even compressed) would also work, but I think you have to change the shader text then, though I believe that I have seen that the file extension named in the shader is irrelevant, but better safe than sorry), move / rename it to achieve this name: '''&quot;textures/scr5_dretchnest/brightglass_001.jpg&quot;'''.<br /> <br /> Again, close and open NetRadiant and feast your eyes on the new contents of the &quot;scr5_dretchnest&quot; texture browser category. Well, your image should be there now. Twice even. WTF? Well, one instance is from the actual file in the texture folder, and the other one is the shader you created. '''Now you see why the shader ends in &quot;_s&quot;: This prevents the names from colliding.''' (Adding &quot;_s&quot; is the way everyone does it.) See? Naming is a really delicate subject!<br /> <br /> So, before we finally start making the goddamn map, let me explain the shader we've created:<br /> <br /> The first line creates the virtual file by giving it a path and filename. Again, take care of those file names, be they virtual or real. The brackets don't need explanation, I guess.<br /> <br /> The &quot;qer_editorimage&quot; line is irrelevant for the game, but it gives our shader a nice image in NetRadiant. If you apply this shader to a wall, instead of the ugly &quot;no pic!!1&quot; texture, you now see your nice .jpg image. Half transparent even! That is caused by the &quot;qer_trans&quot; line, which is also irrelevant for the game. It's there purely for the editor. And both these lines are not necessary for editing. Later, you can add &quot;//&quot; to the beginning of these two lines, which means that they are &quot;commented out&quot;. Anything behind &quot;//&quot; is arbitrary text until the line ends. I don't know, though, if a comment can be written on the right end of a shader command. If you comment these two lines out later, when you've actually used the shader in the map, and restart NetRadiant, you'll probably realize that they are not technically necessary, but man do you want them to be there.<br /> <br /> &quot;surfaceparm trans&quot; says that the surface is transparent. This does not mean that you can look through it - it only means that ''the computer'' can look through it! Yes, he has to know, too. A later command will make the shader transparent for us humans, too. As the name said: It's a glass shader.<br /> <br /> &quot;surfaceparm solid&quot; says that the surface is solid. You cannot walk/fall/shoot through it.<br /> <br /> &quot;cull disable&quot; means that the opposite side of a brush that is completely painted with this shader will not be invisible, as it would be with a normal texture. &quot;culling&quot; means to temporarily remove elements (objects, faces etc.) that are irrelevant for the current situation. To speed things up. But it is disabled here because it's glass, so you can see the presence/absence of backside faces, so they must be there.<br /> <br /> So far, this was the description of how the surface behaves. I'm not the shader pro, so the following explanations might be a little stumbly.<br /> <br /> The next {}block describes the actual graphics that will be drawn. The {}block after that tells the system to also create a lightmap and overlay it.<br /> <br /> &quot;map textures/scr5_dretchnest/brightglass_001.jpg&quot; obviously makes the shader use your new texture file. &quot;tcgen environment&quot; is short for &quot;TextureCoordinateGeneration&quot; with the parameter &quot;environment&quot;. Man, do I have to explain environment mapping now? In short, this makes the texture appear in a way that is not like a normal 3D shape but instead like it were a reflection in the 3D shape.<br /> <br /> &quot;blendfunc gl_one gl_one&quot; means: The pixels of the source (this shader) will be multiplied by one, then added to the destination pixels (which is whatever's already drawn on screen behind the glass) also multiplied by one. So, this just adds your lightened (Remember that this shader has a lightmap.) environmentmap-glasstexture onto the world graphics. Now you might realize why it's called &quot;brightglass&quot;. If you want something darker, look for &quot;textures/tremor/darkglass3&quot;.<br /> <br /> I don't really know about shaders. I look at how the other guys did it (There are already tons of existing shaders, look in the folder &quot;scripts&quot; in the map .pk3 files.), I read a bit in the shader manual, trial and error testing, etc. For example, I have no idea what &quot;rgbGen identity&quot; really does, but it belongs there. If you want to dive into that yourself, read [http://www.heppler.com/shader/ this comprehensive shader manual]. Also, lets drop the rest of the shader explanation and get into mapping, damned.<br /> <br /> ===start making the map===<br /> <br /> Assuming that you're still in NetRadiant with your named map (that doesn't have any stuff in it) open, set the 2D to view from the top, set the gridsize to &quot;9&quot; (256), and draw a square, 8x8 grid elements in size, so it will be 2048x2048 world units. It's not really important where you do this, but since NetRadiant positions the camera at position 0,0,0 every time you load a map (which can somehow be changed with an entity, but I currently don't remember how, saw it in a decompiled ATCS once), I'd suggest that you draw this brush exactly centered around the coordinate 0,0. After you've done so, press CTRL and TAB to set the 2D to view from the side (doesn't matter which). If the brush isn't exactly one grid block high, drag it smaller so that it is. Then move the whole platform so that its upper side (which is the floor to walk on) is at coordinate 0. Unnecessary to say: The whole thing, every face, should have the Caulk shader, the ugly pink one that you already know.<br /> <br /> Copy and paste the selected brush. Click into it and drag it upwards so that its lower side (which will be the ceiling of the map) is at coordinate 256. That's an 8 meters high map hall.<br /> <br /> Press ESC, then draw a square brush left of the two existing brushes, exactly between them. If you press CTRL and TAB, you see that the depth of this square brush is already as we want it because the last selected brush(es) had this depth. Assuming that you're still in the side view in which you drew the square brush, draw another one, on the right side this time. Did you fall for the &quot;something is currently selected&quot; trap, or did you think of pressing ESC yourself?<br /> <br /> Press CTRL and TAB two times to get back to the top view. Now select the two side walls you made. To do that in the 2D view, it's ok to just use the box select in the currently mostly empty map space that we have. So, press SHIFT and then left-click and drag the mouse to select the unselected wall(s). The ceiling and floor (both visible in one place as a big square) must not be selected now! Once you've done that, copy and paste them, then click on the rotate-90-degrees-Z button (a Z with a blue arrow around 90 degrees of the Z). Now you should have a big room with ceiling, floor, and 4 walls. The wall and floor brushes should be edge-on-edge, that will work properly, don't worry. The brushes must not overlap, though! Admittedly, the walls are a bit thick, but they are the outer map walls, so that doesn't matter. Actually, it's not so bad to have them this thick. Why shouldn't they stand out in the editor as a unique structure.<br /> <br /> If you have done it right (which is more probable with this large grid spacing than it would be with a smaller spacing), you should have a proper shell in which you can go crazy without having to worry about [[leaking]]. The [[void]] is properly locked out. The [[VIS]] calculation can hence be performed. You will not have the [[hall of mirrors]] effect.<br /> <br /> Well, yes, you will have the HOM effect, because everything is still Caulk, but we'll change that now. First, select a proper texture: Select &quot;arachnid2&quot;, then scroll down a bit until you see &quot;cement_1_clean&quot;. Now, select all the 6 surfaces that form the room (CTRL SHIFT left-click, and as a NetRadiant user, you'll have learned to press ESC a few times before this new select action, I guess). Then click on the texture.<br /> <br /> '''Save the map. If this is your first save in this &quot;start making the map&quot; chapter, you're still doing it wrong!''' Also, duplicate the saved map file.<br /> <br /> Actually, the floor and ceiling look just wrong this way. Go to the &quot;karith&quot; texture section, scroll down a bit until you see &quot;cement_3&quot;, select only the floor and ceiling face (Not the whole brush, but I guess I don't have to say that any more.) and apply the texture. Save the map. No new backup this time.<br /> <br /> Nice room. If you fly around in it with your camera, you might get the impression that it's too dark. In that case, open the NetRadiant preferences. Don't worry about a message saying that you'd better save before entering the preferences - in most cases, it doesn't matter. Except that saving is usually fast and in most cases not a problem. And if that dialog appeared just now, you didn't save the map when I said so, sinner! :&gt; Go to the preferences section &quot;display&quot;, subsection &quot;textures&quot;, and set the texture gamma to, let's say, 0.8<br /> <br /> ===about clipping, most underestimated by beginners===<br /> <br /> Assuming that the current situation is the result of your actions in the last chapter, you should still be looking from the top in the 2D view. Gridsize should still be largest (key &quot;9&quot;). Now, draw a new brush, 4 grid elements in size, around the 0,0 coordinate. So, the size should be 512x512. The brush should be inside the map shell room that you built, exactly from floor to ceiling.<br /> <br /> We'll use a little trick now. Set the grid spacing to 32 (key &quot;6&quot;). As I said, 32 is the smallest wall thickness you should use if you want to prevent light bleeding. You can be lucky with smaller values or still unlucky with larger ones, but 32 is a good base to work with. I've read somewhere that a thinner wall risks that objects or players might pass through it when playing on the Internet, but I think that's not true, at least I haven't seen problems like these ''ever'' in the Tremulous world, and there are maps with thinner walls around. Another thing about wall thickness: Even a wall with 64 world units might still let the damage effect of a fully charged [[Lucifer Cannon]] shot through a bit. I wonder how much or how little calculation time / network overhead impact it would have meant to prevent this, because this behavior sucks considerably.<br /> <br /> So, with the grid set to spacing 32 and the new 512x512 brush selected, search for the 5th button right of the 90-degree-Z-rotate button. When you hover over it, it says &quot;Hollow&quot;. Alternatively, go to the &quot;brush&quot; menu, submenu &quot;CSG&quot; and select &quot;Make Hollow&quot;. This function is not widely used, because it motivates box rooms (and other reasons, I guess), but right now it's the best thing in the world because it guarantees that you have a new room with 6 walls, all edges ''overlapping'', wall/ceiling/floor thickness 32. (Side note: Why the &quot;hollow&quot; tool doesn't come with the option to automatically clip the resulting brushes is beyond me.)<br /> <br /> Overlapping brushes should be prevented &quot;at all costs&quot;. We'll do that now, too, which brings us to &quot;clipping&quot;.<br /> <br /> Did I say &quot;save the map&quot;? No, and I won't say that any more.<br /> <br /> While still looking from the top, try to select one of the four walls in the 2D view. It's tricky, isn't it? Now you see why you'll select stuff in the 3D view most of the time. But let's try the 2D view again. Press ESC. Then, box-select the middle part of one of the walls (which will also select other stuff). Then, box-select the center of this new room. Shazam, everything except the wall is deselected. Box-select inverts the current selection where it is in effect. Also, nice that we activated &quot;display size info&quot; in the preferences (&quot;orthographic&quot;) before, because now we can clearly see that all elements of the current selection have the position and size of the wall we wanted - which makes it reasonable to assume that only the wall is selected. Once your maps are a bit more complex, that assumption is not so reasonable. I think that it would save the mappers of the world tons of time if there were a simple but prominent number stating how many elements are currently selected. Well, rudimentary tool, as I said. Instead, you can see how many milliseconds it took the 3D view to redraw.<br /> <br /> Now that one wall is selected, choose a different tool. Currently, the button with the square on it is activated (&quot;Resize (Q)&quot;). Activate the button right from it, the one with the diagonal line (&quot;Clipper (X)&quot;). This tool can be used to cut away parts of brushes or to split them into two brushes. Reminder: The preferences of the &quot;clipper&quot; should be set to &quot;Clipper tool uses caulk&quot;.<br /> <br /> You have to cut away a small diagonal part of the wall in the corner. What we want to achieve is that the four walls do not overlap in the corner but do instead end exactly where the next one begins. Yes, you could just use the resize tool for that, but that's not how a good mapper does it (except when it makes more sense than clipping). Imagine: When the walls are clipped in the way I described it, then not just the outer walls will be perfectly connected, but the inner walls, too. So, when you paint textures on them, you can use the &quot;fit&quot; tool of the &quot;surface inspector&quot; (key &quot;s&quot;) to make the texture fit the wall perfectly while you can mostly forget about all the numbers in that window. Or, if you're dealing with the numbers, you can copy them from other surfaces because the other walls have the same special properties (brush corners clipped).<br /> <br /> Well, if you had drawn the walls edge-on-edge like you did with the outer map walls, painting the inner walls would be exactly as easy as the clipped result will be. But we want to paint the outer walls, too! This will be a room visible from the outside, hence it must be properly built.<br /> <br /> So, let's just try to clip one of the corners of the selected wall now. Choose one end of the wall, then click once on the corner that is outside of the room, then on the one that's inside of the room. Two blue dots (&quot;1&quot; and &quot;2&quot;) should have appeared. The line that connects them should point from the outside room corner to the inside of the room. Also, there is another line (the &quot;perpendicular&quot; or &quot;normal&quot;) beginning at the middle of the clip line. Both lines are not existing objects but just editor tools.<br /> <br /> Press ENTER. So, the brush was divided by that clip line you made, and now one of the two parts of the brush is gone. It's the one that the additional line (the &quot;normal&quot;) went through, that's the rule. Which way the &quot;normal&quot; points depends on the order in which you created the clipper points. Also, you can invert the clipper direction (menu &quot;brush&quot;, submenu &quot;clipper&quot;). Also, the brush part that will stay will have the clip face painted blue in the 3D view (as long as you didn't complete the clip by pressing ENTER).<br /> <br /> Clipper tips: You can drag the clip points around on the 2D view. You can even add a third point. You can change the 2D view from top to side etc. and then still drag the points around. And you cannot remove the clip points by pressing ESC. To remove them, you have to select a different tool (like &quot;resize&quot;) and then switch back to the clipper tool. Or just click again once all 3 clipper points are placed, because that will place number 1 again, removing the other two. Only if you click directly on one of them, you can drag them.<br /> <br /> Very frustrating: While the &quot;undo&quot; can be used to return to the unclipped brush, it does not return you to the situation with existing clipper points, so you have to place them anew.<br /> <br /> Now that you kinda know how to work the clipper tools, clip all 8 wall ends diagonally, so that the walls are perfectly face on face, not overlapping any more. So that the inner walls start and end exactly in the inner room corners.<br /> <br /> Wow, finally done with the stupid clipping. Let's paint and resize a few more blocks, right? No. The clipper tool is one of the most important tools in mapping, and you'll use it much more often than you can imagine right now.<br /> <br /> For example: It's time to clip the ceiling and floor so that they diagonally meet the walls - which, thusly, also have to be clipped. In the end, all 6 walls/floor/ceiling of the little room will be kinda like the bottom ends of pyramids pointing into the room, perfectly face to face which each other. During all this, you should leave the grid spacing on 32.<br /> <br /> Done yet? An experienced mapper needs 1 or 2 minutes to finish this properly.<br /> <br /> You might be wondering why we didn't just delete the ceiling and floor of the little room (after all, there's still the outer map ceiling and floor). Reason one: Using a map shell room like we did is a crutch. Not necessarily a bad one, but also not necessarily the way an experienced mapper does it. Reason two: You'd make yourself dependent on the outer ceiling and floor, and once you get out of the room and map some more, you'll have more dependency-situation-possibilities like this. You don't want to tie it all together and stand in your own way. I had that when making skybox. &quot;Can I texture this wall? No, damned, it's the outer wall again.&quot; Reason three: Lightmaps! I don't know how exactly it is decided how many pixels a lightmap has, but I am pretty sure that a huge brush will have a less high resolution (so, rather stretched) light map. Oh, speaking of which:<br /> <br /> ===_lightmapscale, gridsize, turbo rendering===<br /> <br /> (You can skip this now and go to &quot;enjoy the fruits of the clipping labour&quot;. One day, you should read this, though.)<br /> <br /> I already explained the worldspawn. Press ESC and select any one of the brushes. Since we currently only have simple worldspawn brushes (as opposed to, for example, doors), you could also just box-select a bunch of them. Anyway: Press &quot;n&quot; if the entity inspector was not yet visible. As you know, the second section shows a help text for the currently selected entity type, and since the third section shows &quot;classname worldspawn&quot;, the help text describes the worldspawn. Scroll far down (not to the end) until you see the explanation of &quot;_lightmapscale&quot;. Read it. Then, write &quot;_lightmapscale&quot; and &quot;0.25&quot; into the &quot;key&quot; and &quot;value&quot; textboxes and press RETURN while you're in the value textbox. I thoroughly tested it in a relatively small room: Values smaller than 0.25 don't increase the lightmap resolution any more.<br /> <br /> Setting the lightmapscale to 0.25 will result in a higher lightmap resolution, so you'd have better shadows etc., think of the difference between the thumbnail of a picture and the full size version (only the difference is not that drastic here). The default setting is &quot;1.0&quot; (when the _lightmapscale key is not present). 0.25 also means that the LIGHT phase, in which the lightmaps are calculated, will take much longer. This also means that larger settings than 1 will make it shorter.<br /> <br /> If you've followed this mapping crash course so far, you'll either have prepared q3map2 frontend &quot;q3map2build&quot; or a build batch file, and you will have done so that the light rendering result is very good:<br /> <br /> &quot;fast&quot; is not activated. &quot;bouncescale&quot; is on 2, &quot;bounce&quot; is on 500 (meaning: effectively &quot;6&quot; or something). And to top it off, your map now has the best lightmap scale. The option &quot;filter&quot; is not relevant for the calculation time. It will smooth the resulting lightmap a little so that shadow seams don't look so pixeled. I am not repeating all this from other guides, these are actual experiences that I gathered in many tests over months.<br /> <br /> Now, as long as your map is very small, these settings are ok. Calculation will be done in a few minutes or less than a minute. But once your map is a huge monstrosity, calculation with these settings takes several days on a fast computer. That's still ok as long as you have an extra machine for things like these, but '''here's how you can speed up the rendering like crazy''' (resulting in less good result, of course):<br /> <br /> Add the key &quot;gridsize&quot;, value &quot;1024 1024 1024&quot; to your worldspawn (default would be 64x64x128 as far as I know, and to achieve default, just delete the key again). As far as I know, the gridsize defines the ''volumetric'' lightmap calculation. If you get closer to a bright red spot in the map, your weapon will receive red light. If the gridsize is as coarse as we have set it here, those effects will be less prominent. I could be totally wrong about this. Maybe the gridsize is more about how the raytracing really takes place. In any case: Changing the gridsize has ''huge'' (!) impact on the calculation time. Setting it to this value will make it faster. Deleting the key, so that you're back on the (very good) default value makes it slower. Setting the gridsize to something like 48x48x48 increases the calculation time insanely, and as far as my test results go, it doesn't have any merit. So: For high quality results, you'd use the default setting. For quick and less proper results, you use the 1024 (or an even rougher) one.<br /> <br /> You can also drop the &quot;bouncegrid&quot; option. Bouncegrid means that before every radiosity bounce, the lightgrid (see &quot;gridsize&quot;) is calculated anew, because somethingsomething bounce influence grid somethingbla. Honestly, I didn't test the difference it really makes, but I believe that it's safe to assume that this option increases the light rendering quality even further.<br /> <br /> Change the rendering settings (in &quot;q3map2build&quot; or your batch file) so that the LIGHT phase uses the key &quot;-fast&quot;. This does not change the lighting ''very'' much (but still too much for my taste when I want to make a real proper release), but it insanely reduces calculation time.<br /> <br /> Removing the &quot;bounce&quot; option (&quot;bouncescale&quot; is irrelevant for the time (except in regards of the caused number of iterations) and is bound to &quot;bounce&quot;, so you don't have to touch it here) has strong influence on the lighting. You should try to have a few bounces in your released maps, the light looks considerably more natural. Removing the &quot;bounce&quot; option decreases calculation time, though. Very much even. If the initial pass (not yet bounced) takes 10 seconds, every bounce will also take about 10. If the first took 1 day, guess what. Depending on the bouncescale you used, the amount of bounces will have strong influence on the lighting result. This is something for tweaker guys. Just as the &quot;gamma&quot; option (that I didn't mention yet) in the LIGHT phase is. You should know that these options exist and that it's a good idea to toy with them. Now let's move on.<br /> <br /> Another option that you can add to speed up calculation: &quot;-fast&quot; in the VIS phase. Please don't do this, though, if you want to release the results into the public. And definitely don't release the result if you omit the VIS phase completely - which you can also do to decrease rendering time even more. The VIS phase calculates which spot of the map can be seen from which other spot. This information allows the game engine to draw only the necessary graphics. As far as I know, it also influences the radar functions of helmet and aliens. It's essential for a release, and you should do it without &quot;-fast&quot; for a release.<br /> <br /> '''In short:'''<br /> <br /> '''For fast rendering''', add &quot;-fast&quot; to the VIS phase (or drop it completely), add &quot;-fast&quot; to the LIGHT phase, remove &quot;bounce&quot; from the light phase (or just &quot;bouncegrid&quot;, but I think if you're already doing bounces, you might as well do them properly), remove the &quot;_lightmapscale 0.25&quot; thing from the worldspawn, add &quot;gridsize 1024 1024 1024&quot; to the worldspawn.<br /> <br /> '''For best (slow) rendering''', have a not-fast VIS phase, not-fast LIGHT phase, bouncegrid, bounce 500. Remove &quot;gridsize&quot; from the worldspawn. Add &quot;_lightmapscale 0.25&quot; to the world spawn.<br /> <br /> If you want to see a map that rendered for 112 hours with lightmapscale 0.25 and 11 radiosity bounces (Then it was tuesday morning and I needed the computer :/ Yes, you can abort the calculation at any time. Previous bounces will still be existent, and the current half-done one will also not be visible.) and want to see what the higher lightmap resolution might do to a 128MB graphics card, take a look at [[Gmotw_Skybox]]. I'm not really proud of the rendering result. There should be more shadow cast situations and so forth, but it's the best I have to offer in that regard yet. I think the lightmap can best be enjoyed in and above the pump station.<br /> <br /> ===enjoy the fruits of the clipping labour===<br /> <br /> Inspect the result of your work. It's very useful that you can move the camera to the inside of a wall, making it temporarily vanish from the 3D view.<br /> <br /> While you were working on the clipping, I picked a nice texture to demonstrate the described advantages of clipped walls. The texture browser should still be in the &quot;karith&quot; section, showing the &quot;cement_3&quot; texture (near the top). Scroll a bit further up until you see a broad texture called &quot;base_grooved&quot;. (Well, you might have a hard time finding it if there's another texture with a long name to the left of it, because then, the name on screen is partly overwritten. As I said: Rudimentary tool.) It should be the 8th texture. Press ESC and then click on the texture. At the bottom of the screen, there should be a text saying &quot;textures/karith/base_groove...&quot;. The texture looks like someone used a comb on a gray piece of butter from the left to the right.<br /> <br /> Now, select one of the faces inside the little room, then click on the texture. If you have done everything like I described, you'll see the texture on the wall, but there's something like a split in its middle. What you see are the outer ends of the texture. Textures are always looped on the brushes, so now lets place this texture properly. Press &quot;s&quot; (if the surface inspector was not already visible), then click &quot;Fit&quot; (if there is a 1 in both text boxes beside the fit button, otherwise set the boxes to 1 (or 1.000000, it's the same)). That was easy, wasn't it? Imagine what would have happened without the clipping. The texture would be partly hidden. If you look at the surface inspector and the numbers in it, can you imagine the hassle of adjusting everything until it looks like it does now?<br /> <br /> If you look at the horizontal and vertical stretch, you see something between 0.5 and 1 (and they are different - thank the programmers for the &quot;fit&quot; button). That's kinda ok-ish, but smaller values mean higher texture resolution. Only we can't put the texture in twice because that doesn't look good, either. The &quot;width&quot; and &quot;height&quot; value next to the &quot;fit&quot; button, by the way, define how often the texture is to fit the surface when you click &quot;fit&quot;. Yes, &quot;0.5&quot; etc. works, too.<br /> <br /> Paint all four walls in the described manner. You can do them all at once.<br /> <br /> After that, paint floor and ceiling with the next texture in the list, &quot;base_small&quot;, and fit it in 1 by 1. Again, this wouldn't have worked so easily without clipping. The horizontal and vertical stretch are close to 2, which is much too high. You can already see how blurry and cheap it looks. But keep it for now.<br /> <br /> ===let's add a door===<br /> <br /> Look from the top in the 2D view. Set the grid spacing to 128 (key &quot;8&quot;). Select one of the 4 walls. Just for training, let's use the toggle-selection, so press and hold SHIFT and ALT, then click on one of the 4 walls a few times until it is selected. You don't have to press ESC before this.<br /> <br /> With the wall selected and the clipper tool active, click on the wall. Gridwise, it has 4 sections. Click so that 3/4 of the wall would be cut off. Umm, where to put the second clip point? The grid doesn't allow to put it on the wall! Well, doesn't matter. Just put it a bit further away. Only the direction and position of the line itself must be correct, not its length. If you have made a nice (and non-diagonal) clipping line, press SHIFT and ENTER or select &quot;split selection&quot; from the &quot;brush&quot; menu, submenu &quot;clipper&quot;. You have cut the wall into two segments. Do that again on the other side, so that the middle segment is two grid elements in size. By the way, you can join brushes if the result would &quot;make sense&quot; (convex brush) using menu &quot;brush&quot;, submenu &quot;CSG&quot;, item &quot;CSG merge&quot;. If you try to merge brushes that can't be merged, you'll see an error message in the log area.<br /> <br /> Ok, now deselect everything (ESC). Then '''select the middle part of the split wall. Then, right-click in the 2D view, go to &quot;func&quot; and select &quot;func_door&quot;. You just made an automatic door''' that opens to the side if you get close, complete with sound. Nice, huh? Let's change the angle to &quot;top&quot; by adding the key &quot;angle&quot;, value &quot;-1&quot; in the entity inspector.<br /> <br /> You could actually make a door that uses a sensor that only reacts to someone carrying a lucifer cannon. Or to dretches and dragoons. Then, a sound would play and dark light would go bright (without lighting the environment, though (then again, I think it can be done using a shader with specular lighting)). Bars in front of the door would move to the sides (with sound). Then, the door would ''rotate'' open kinda like a garage door. Later, everything would move back. This can really be done using triggers, delays and so forth. But dude, I'm not gonna guide you through that.<br /> <br /> You can adjust the door in the &quot;entity inspector&quot; (&quot;n&quot;). You can change the sound, the direction into which it opens, how much of it is still visible once it's open, whether its default is open or closed, how much damage it does to you if you stand in its way, how fast it moves and more. The &quot;lip&quot; value is especially useful. You know, a door is just a brush (or a bunch of brushes - yes, '''you can make complex designs and have them move as one unit''') that moves. It has convenient defaults and a sensor. But you don't need to use the sensor. Also, '''you can use huge negative values for the &quot;lip&quot;, making the door move much further than necessary when it opens. And what is that then? A lift! :)''' There is also an extra lift function, but its default sounds are broken, and also it cannot be set to &quot;crusher&quot;, as far as I know. The big lift in skybox is a door, consisting of several brushes. '''Doors are really versatile.''' You know what? I once used doors to make a programmable soundtracker in Tremulous (&quot;gmotw_pianolessons&quot;, named like this because there's also a big piano with black and white keys that you can step on, and guess what, they are all doors). 16 doors would hammer down in a sequence, and their &quot;I'm closed now!&quot; sound wouldn't play if they don't arrive at the closed state, so I just made buildings in their way to program the sound steps. Did I say that doors are versatile yet? A server where you can save the current building layout can then even save the rhythm for later! Problem is, once too many elements are used, the rhythm stumbles a bit. Maybe a faster computer or newer Trem client doesn't have that problem. I used 16 steps and 3 instruments (bassdrum, snare, closed highhat), and it already got a bit stumbly. Another thing you can do with a door is use it as a busy-light that appears from out of nowhere (was hidden in a wall) and vanishes once the busy cycle (lift or whatever) is over. Also, I once made a door that actually consisted of 8 by 8 doors that you had to shoot. It was a pixel-door. If you didn't shoot the pixels away fast enough, they would return and you wouldn't get through. A tyrant (or whatever) filter. A dream if you carry a lucifer gun. That was in skybox, but I had to remove it in later releases because with all the other map elements, it reduced the FPS too much. But the door maze is still in the map. Looks like solid walls, but it is a small 2D maze. No, even 3D.<br /> <br /> Now, press &quot;h&quot; to hide the door and move the camera so that you look at the room from the outside. We'll now paint the frame of the door. Use the texture &quot;base_verts&quot; which comes shortly after the &quot;base_small&quot; that we used for floor and ceiling. Select the two faces at the side of the opening. Click the texture. Click &quot;fit&quot;. If you look at the stretch values, you see that one is 0.5 and the other 0.25, which can look odd, so better enter a &quot;2&quot; instead of the &quot;1&quot; in height (next to the &quot;fit&quot; button) and click &quot;fit&quot; again. The texture is now used 2 times in height, so it is not as streched in that direction. Press ESC. Then select the upper and lower face of the opening. Click the texture. Looks wrong. Now what? Well, it needs to be rotated. If you look at the &quot;rotate&quot; text box, there is a &quot;0&quot; in it. The text boxes on the right side can be changed at any time without influencing the map in any way - they are only an editor tool. The box right to &quot;rotate&quot; should have a &quot;90&quot; right now. If so, click the up or down arrow (doesn't really matter now) of the rotate value, changing it to 90 or -90 degrees. The texture looks better now. Click &quot;fit&quot;. Damn, bad stretching. Change the height preference to &quot;4&quot; and click &quot;fit&quot; again. See? The &quot;height&quot; now means &quot;width&quot; because the texture is rotated.<br /> <br /> If you look now from the inside of the room, you'll see that the wall (not frame) texture is cleanly cut, as it should be. If you would want to apply and fit the texture now, you'd have problems. '''To use &quot;fit&quot; on a surface with the &quot;wrong&quot; size, temporarily resize the wall to an appropriate width, click &quot;fit&quot;, return the size to normal again.'''<br /> <br /> Paint the 3 outer walls with the texture we used on the inside walls (for that, select an inside wall surface and use CTRL and C, which will not just copy the texture settings, rotation and so forth, but will also select that texture in the browser, so you can just click it then instead of using paste). Don't forget to fit (1x1). Paint the two short front walls with the texture &quot;base_v_rigged&quot;. Fit them in (1x1). By now, you'll have realized that the textures are sorted by alphabet. <br /> <br /> Press SHIFT h to get the door back. Press ESC. Select the door. Press i or choose &quot;invert selection&quot; from the edit menu. Press h. Now, only the door is visible, and it obviously needs some texturing. Put &quot;base_small&quot; on the outside and inside (fit 1x1).<br /> <br /> The four outer sides of the door are still unpainted. Let's select them all at once and then apply &quot;base_verts&quot;. Fit them 1x1. There's a problem: Even though the stretch values on the side surfaces are different from the top/bottom surfaces, you only see one number pair. Keep that in mind, also when dealing with the entity inspector while several elements are selected. A common reason would be to copy the values of one door to another. Select the correct door first, the one you want to fill with values as second, and for every value that you want to copy, click it and then press ENTER in the &quot;value&quot; text box to re-apply the key-value-pair to the correct door, which will also copy it to the other(s).<br /> <br /> So, let's do this again properly (and maybe you have already realized that this is all wrong, then follow me without acting, also smile). Press ESC. Select both side surfaces. Click &quot;fit&quot; with 1x2, so both stretch values should become &quot;0.25&quot;. Select the top and bottom, rotate the texture by 90 degrees, fit 1x2. Why not 1x4 like the same surfaces of the room walls? Because the surfaces of the room walls didn't begin/end at the door opening! So, we have a few meters of unnecessarily painted faces there. I don't know if a real pro mapper would now fix that by causing a few more brushes or if they would just ignore the few meters of unnecessary texture. We'll just leave it at this now. Don't tell anyone.<br /> <br /> The door is now painted on the front, back, and on the other 4 sides. Unnecessarily. The reason is that we didn't think enough like a mapper should, instead we were stuck too much in real-world thinking. Since you will never get to see the left, right and top side of the door, we should apply the Caulk shader to them.<br /> <br /> The texture browser has a little drop down menu, too. Go into that &quot;view&quot; menu and click &quot;hide unused&quot;. This hides all textures from the texture browser that are currently not used by the map. Even better: Also select &quot;show all&quot; from the same menu. Now, every texture that you had loaded in this program session (except the unused ones because you just hid those) is in the texture panel. You should memorize this trick, it will make your mapping much easier. For example: The caulk shader is here! Apply it to the left, right, and upper surface of the door. Then press SHIFT h to unhide everything.<br /> <br /> Press ESC. Select the door. Go to the entity inspector. Add the key &quot;lip&quot;, value &quot;80&quot; to the door, because otherwise it would look kinda weird while open. A bit of its lower end would stick out of the ceiling without any apparent cavity or mechanism for the door. With &quot;80&quot;, it sticks out so far that no one will ask questions.<br /> <br /> This, by the way, makes another surface's texture unnecessary. Since I don't plan on toying around with the door some more, let's set that surface to caulk, too. So: Hide the door. Then look from the outside. The upper diagonal surface will be invisible because the door will never reveal that surface.<br /> <br /> ===let's populate the map===<br /> <br /> Add an &quot;info_player_intermission&quot; entity. (I won't tell you how because I already did. If you didn't read the whole truckload of text, use the in-page-search function of your browser.) Move and rotate the entity so that it looks at the door of the little room from the outside, from a bit further away, slightly diagonal so that you can see the side wall of the room, too, and much of the rest of the map.<br /> <br /> Press the &quot;1&quot; key for the highest grid resolution that you can achieve with the keyboard. In the room (top view in 2D), create a &quot;team_human_reactor&quot; entity. Move it around a little. Then press &quot;8&quot; for grid spacing &quot;128&quot;. Move the reactor again. You see that the amount by which it moves is 128, as the grid forces it to. But its position is kinda off (if we're not unlucky). To force the reactor back into a nice x y and z grid position, press CTRL and &quot;g&quot; or use &quot;snap selection to grid&quot; in the &quot;brush&quot; menu. Now, with the 128 grid, move the reactor as far into the corner as possible. I don't care which one, as long as it's not on the door side. Switch the 2D to side view, set the grid to &quot;7&quot; (64), drag the reactor to a reasonable height position. It must not be in or above the ceiling and not in or below the floor.<br /> <br /> Rotate it around the Z axis by 90 degrees until the nice control panel can be seen. You might even want to rotate it arbitrarily by 45 degrees and then in 90 degree steps until it nicely faces the room.<br /> <br /> Also build an armory, a medistation, two nodes and a few turrets. Give them enough space. Especially the armory is tricky. Too few people know that '''the game system only allows square [[Hitbox|hitboxes]]'''. The height can vary, but the shape when seen from top is square. Even the armory? '''Yes, even the armory.''' If you keep that in mind, it will explain every occasion on which the armory or a nearby building didn't appear in the game.<br /> <br /> You should already rotate the turrets so that they face the door. This is not a [[Building|base building guide]], so I'll stop here.<br /> <br /> Don't forget to make a few alien buildings (overmind, SPAWN!, ...) somewhere in the outside hall.<br /> <br /> Then add &quot;player_human_intermission&quot; and &quot;player_alien_intermission&quot; (one of each) and make them look at the human and alien base.<br /> <br /> You can have a look at the map if you want, even though we haven't placed any lights yet. Just omit the LIGHT phase. Everything will be at full brightness. The batch file:<br /> <br /> &quot;C:\Program Files\netradiant-20100214-win32\q3map2.exe&quot; -fs_basepath &quot;C:\Program Files\Tremulous&quot; -fs_game &quot;base&quot; -custinfoparms -info -meta -patchmeta &quot;C:\Program Files\Tremulous\base\maps\scr5_dretchnest.map&quot;<br /> &quot;C:\Program Files\netradiant-20100214-win32\q3map2.exe&quot; -fs_basepath &quot;C:\Program Files\Tremulous&quot; -fs_game &quot;base&quot; -vis -saveprt &quot;C:\Program Files\Tremulous\base\maps\scr5_dretchnest.map&quot;<br /> &quot;C:\Program Files\Tremulous\tremulous.exe&quot; +set fs_basepath &quot;C:\Program Files\Tremulous&quot; +set fs_game base +devmap &quot;scr5_dretchnest&quot;<br /> <br /> ===lighting===<br /> <br /> On second thought, you should definitely look at the map right now. With full brightness, it sucks. Once we've added nice lighting, it will look so much more pleasant. Lighting makes and breaks the mood.<br /> <br /> Just as decorations (which we haven't dealt with yet) are not a burden but a passion to a real mapper, lighting is not something to be dealt with by just throwing strong point lights with no apparent light source (fixture) all over the place. And definitely '''''do not'' use the &quot;_minlight&quot; or &quot;_ambient&quot; features in the worldspawn.''' You might use them sometimes - really rarely - to test something, but a map with proper lighting will, I dare to claim, never have one of these features in use.<br /> <br /> '''There are two possible light sources:''' Point lights (which can be made with the right-click menu) and light textures (or light shaders, same thing, different term). We have already dealt with shaders. It's possible to make shaders with a parameter that makes it emit light. The larger the surface that uses the light shader, the more light is emitted. The advantage of using light shaders is that you always have a &quot;something&quot; that the light is actually coming from. This contributes considerably to the mood, because it is more believable. You can, of course, just build a &quot;something&quot; that might be a light, then add a point light source to it. That works, too. Actually, the main reason people rarely do that probably is that you can't group brushes and point lights together. You see, the &quot;worldspawn&quot; entity is not the only &quot;dead&quot; entity that can hold brushes. '''You can also select a bunch of brushes and then select &quot;func_group&quot; from the right-click menu.''' This creates a new entity of type (or &quot;classname&quot;) &quot;func_group&quot;. You cannot add other entities (like light or a doorbrush) to such a group which is sad, because if you could, people would probably also try to construct light fixtures and then just put a point light into them instead of fiddling with shaders. And what is the advantage of such a group? Well, if you select one of its brushes, you can then use &quot;expand selection -&gt; to whole entities&quot; from the edit menu. You can then conveniently move them around or copy/paste of them - which creates a new func_group with the copied brushes in them. The expand selection function also works for several such things in parallel. Sadly, I haven't yet found out how to add another brush to such a group. &quot;regroup&quot; in the &quot;entity&quot; menu does the opposite of what you'd expect, and I haven't tried the next function, &quot;ungroup&quot; because I suspect that it does what you'd expect.<br /> <br /> ===decorations, structural/detail brushes===<br /> <br /> <br /> <br /> ===create a release file===<br /> <br /> <br /> <br /> [[Category:Mapping]]</div> Tue, 13 Jul 2010 13:48:53 GMT God, maker of the world http://tremulous.net/wiki/Talk:Mapping Mapping http://tremulous.net/wiki/Mapping <p>God, maker of the world:&#32;/* create the asset folders */</p> <hr /> <div>A [[mapper]] is a person who creates a game [[map]]. He is &quot;mapping&quot;. This article describes how that works in the Tremulous context. For a list of a few existing Tremulous maps, click [[:category:Maps|here]].<br /> <br /> <br /> =mapping crash course=<br /> <br /> I started this article on 2010-06-29, just so you know why it doesn't refer to Tremulous 1.2 etc. I am a Windows user (2000 and XP), so that's the perspective that I use. If you can't translate that into your perspective, then you probably shouldn't use the system you're using.<br /> <br /> There are already several mapping guides out there ([http://tremulous.net/forum/index.php?topic=7497.0 list]), one of the best of which is at [http://tremmapping.pbworks.com/ tremmapping.pbworks.com]. It is easy and very comprehensive. I'll try to write a new one from scratch here based on my experiences - and much more up to date. It will save you some steps that were necessary 3 years ago when the linked guide was made. This article here will not enable you to make good maps, but it will give you a truckload of know-how of the kind you don't find in other mapping guides.<br /> <br /> If you've ever written something like a guide, you know that you'll inevitably get into ramble mode from time to time. I guess you can forgive me that.<br /> <br /> <br /> ==setting up your computer==<br /> <br /> ===Tremulous client===<br /> <br /> Download and install the original Tremulous 1.1.0 client. It can be found [http://tremulous.net/files/ here], but it's all over the Web, just search. Now, you ''could'' use a different Tremulous client, but I suggest that you don't. Reason: The original client is what many people out there still use, and when you test your map, you'd want to see what it looks and behaves like (and if it works at all) in the client all those [[newbie|noobs]] use who wouldn't know how to fix a problem if your map causes it. You want your map to work and to shine in the original client. You don't want it to look great only in the latest client with magical rendering v9.9.999 and bloom effect.<br /> <br /> Maybe also download the [http://tremulous.tjw.org/backport TJW backport] client. It's a slightly updated version of the original client. Not too new to violate what I said in the previous paragraph. This is not a full Tremulous release. It's just the program itself. Put it into the program folder of the above mentioned original client. This client supports [[GUID]] and much faster auto-[[Cl_allowDownload|download]].<br /> <br /> You might already have all this. But consider starting anew in a VirtualMachine or on a new computer. If you're more proficient, you'll be able to maybe clean up all your Tremulous base folders so that you don't have magical conditions that a person using the naked client wouldn't have. If you're not proficient enough in this and don't want to make a clean install, prepare to experience problems like &quot;But the texture wasn't missing on my machine!&quot;.<br /> <br /> ===NetRadiant===<br /> <br /> Now the most important part: Download and install [http://ingar.satgnu.net/gtkradiant/installation.html Ingar's NetRadiant and the Tremulous support files]. That's two downloads. The instructions on the linked page are short and comprehensive, it's easy to do. [[NetRadiant]] is the tool that you actually make the maps with. You probably also heard about &quot;GtkRadiant&quot;. Forget it. It's 99% the same as NetRadiant, but it's no longer developed. Also, installation is more complicated because it is not prepared for Tremulous. Additionally, Ingar's NetRadiant already includes the [[Q3Map2]] program that compiles your .map document to a playable .bsp map file.<br /> <br /> Change the NetRadiant preferences (and learn a few things about them): Start it. You'll probably see a little window offering a game type selection. Choose &quot;Tremulous&quot;. There's also a checkbox to prevent this window from appearing every time you start NetRadiant. Technically, that was all. But please, continue adjusting the preferences: Go into the preferences window, which can be found in the &quot;edit&quot; menu at the bottom. I'll go from top to bottom, not from most to least important.<br /> <br /> '''Textures:''' Later, you might want to change &quot;gamma&quot; to something like &quot;0.8&quot; to make the 3D display of the editor brighter. '''Undo:''' Increase queue size to 128. You'll use undo very often, sometimes to undo shifting textures around, and that's an undo step for every texture shift step even if it was a button autorepeat result.<br /> <br /> '''Brush:''' Definitely activate &quot;Always use caulk for new brushes&quot;. You can also activate &quot;Use alternative texture-projection&quot;, but most people do not do that, so if you want to open their maps, you'd have to turn it back off and restart the program. And there is no way to convert a .map from one setting to the other. If you decompile a playable map you found somewhere (like ATCS etc.), you would need to use the alternative projection to load the result in NetRadiant, so why not completely live in that world? I, however, have not done so. Because I didn't know better when I started mapping. I also don't know if I would ever regret turning this option on to make my own maps, so be careful. Maybe better leave it off.<br /> <br /> '''Grid:''' Set default grid spacing to &quot;32&quot;. That's the smallest room-wall-thickness that you want to use to prevent [[light bleeding]] (though the best measure to prevent light bleeding still is clipping). Once you're an experienced mapper, you might want to set this to &quot;256&quot;, the largest setting. '''Camera:''' Movement Speed 100 is good, but you'll come back later and change this, depending on your mapping situation. (I think NetRadiant should have a control element on the edit window to adjust the camera more quickly.) Smaller value for working on details, larger value if you have to travel a lot with your editor camera. Enable far clip plane: It's best to turn it off for now, you'll see everything then, no matter how far away it is. Enabling this option and setting the far plane to something close (menu &quot;view&quot;, submenu &quot;camera&quot;) would be helpful for selecting stuff with the box selection. Also, depending on your hardware and the map, it can speed up display considerably.<br /> <br /> '''Orthographic:''' Turn on &quot;display size info&quot; which will show you the size of one or more selected objects in the 2D view. Turn off &quot;chase mouse during drags&quot;, it would turn you crazy. '''Clipper:''' Definitely activate &quot;clipper tool uses caulk&quot;. '''Autosave:''' Deactivate it. If you're not a total computer noob, you'll know and use CTRL+S oftentimes anyway, and the autosave feature really gets in the way. The coders don't even reset the autosave timer when you hit CTRL+S (lol), so you're better off without it. Saving can take some time on bigger maps, so you want to be in control here. Also, very important: Make backups! Once you saved your map, go into the folder and duplicate the file (CTRL+C, CTRL+V, or whatever it is on your system). Sadly, the Radiant coders didn't include a save rotation like jEdit has it. You have to do that manually.<br /> <br /> Later, when you've worked a bit with NetRadiant, you might want to change the grid colors in the menu &quot;misc&quot;, submenu &quot;colors&quot;. My &quot;grid major&quot; is &quot;#00DF00&quot; (a big fat green) and &quot;grid minor&quot; is &quot;#ADFFAD&quot; (a very bright green, fading into white). Now, you should go into the &quot;view&quot; menu, submenu &quot;show&quot; and activate &quot;show workzone&quot; which will draw additional line garbage in the 2D view - the stuff you have drawn/selected last will have an additional red line pair around it. Makes it easier to find it. You have no idea how confusing the 2D view will become once your map is a bit more complex. Rule of thumb: Before you find the lines in the 2D view confusing, you shouldn't even think about presenting your map to the community.<br /> <br /> ===create the asset folders===<br /> <br /> '''Manually create folders in the base folder:''' You already know the base folder. You extracted the Tremulous support file here as Ingar's website instructed. Now, manually create a folder called &quot;maps&quot;. Also the folders &quot;textures&quot;, &quot;sound&quot; (NOT &quot;SOUNDS&quot;), &quot;scripts&quot;, &quot;env&quot;, &quot;models&quot;. If you have already seen a [[.pk3]] file from the inside, you'll have realized that the folders in those archives are treated by the game client as if they were really existing. So, you'll have guessed what those folders you just made will be used for: They'll hold the exact same kind of files that you see in the .pk3 map files.<br /> <br /> ===obtain a frontend for q3map2===<br /> <br /> If you're on Windows, definitely download [http://www.bobdev.com/q3map2build.php q3map2build]. It's not necessary to make a playable map, but it's a big help in compiling. This VisualBasic program is a '''frontend for q3map2'''. It creates batch files and executes them. Depending on what you selected, there will be up to four lines in such a file: The first one creates a BSP from your MAP. The second one (&quot;[[VIS]]&quot;) calculates what point on your map can be seen from which other point and optimizes the BSP accordingly. Can be omitted oftentimes when you just want to have a look at your map, but for releases, this is absolutely necessary. It's the difference between 1 FPS and 90 FPS. Among other things. And the third line (&quot;LIGHT&quot;) finally calculates the light maps, so everything looks and feels real. Without this phase, everything would be brutally bright. The fourth line starts the Tremulous client with your freshly compiled map. Very convenient. '''After downloading q3map2build, you have to configure it:''' Start it. Go to &quot;directory options&quot;. Set &quot;game executable location&quot; to your tremulous.exe. Set &quot;q3map2.exe location&quot; to the file &quot;q3map2.exe&quot; located somewhere in the NetRadiant folder. Click &quot;save&quot;. Open the &quot;game options&quot; window, check the &quot;base mod dir&quot; box and type &quot;base&quot; into the text box. Click &quot;save&quot;. That was the basic setup of the program. '''While we're at it:''' In the little &quot;'''BSP'''&quot; area, select &quot;custom&quot; and click &quot;options&quot;. Activate &quot;custinfoparms&quot;, &quot;info&quot;, &quot;meta&quot; and &quot;patchmeta&quot;. Click &quot;save&quot;. In the little &quot;'''VIS'''&quot; area, select &quot;custom&quot; and click &quot;options&quot;. Activate &quot;saveprt&quot; and click &quot;save&quot;. In the little &quot;'''LIGHT'''&quot; area, select &quot;custom&quot; and click &quot;options&quot;. Activate &quot;bouncegrid&quot;, &quot;custinfoparms&quot;, &quot;filter&quot;, &quot;patchshadows&quot;, &quot;bounce&quot;, &quot;bouncescale&quot;. Enter a &quot;500&quot; in bounce and a &quot;2&quot; in bouncescale. Remember these two options because you will later come back and deactivate them both, instead you will then (Later, as I said.) activate &quot;fast&quot;. Before you click &quot;save&quot;, let me explain what's going on here: These options define how the lightmaps will be rendered. The option &quot;fast&quot; really really increases the speed of the calculations, and you will use it most of the time because it even doesn't change the lighting drastically. But your first map tests will be of so little complexity that the rendering will be fast anyway. The &quot;bounce&quot; option is for radiosity bounces. So, your surfaces will not just have the light that is cast on them by the light sources. Instead, as in physical reality, your surfaces will also have the light that is reflected by the other surfaces. This is, of course, a question of iterations, because once a surface has received light from another surface, guess what: The next time, the light that comes from the surfaces is different. Realistically, 2 or 3 passes do the trick of giving the right impression. 500 passes will never be reached, all light will be used up at pass 5 or 7 maybe, the program will then stop calculating this. You should definitely use radiosity bounces in the maps you publish (if you have the time to calculate them), because they give a much more natural lighting feeling. For example: Colored surfaces will reflect colored light. You get the picture. Just turn this on for now so that you immediatelly collect data in your mind. The parameter &quot;bouncescale&quot; defines the amplification of the bounced light. Theoretically, this should be set to 1 (and hence just be disabled), but I have made good experiences with amplifying the bounces a bit. This causes more radiosity bounces, of course, because the light will not be used up so quickly. It can even happen that the light will not be used up at all. Hey. This is a crash course, not a &quot;click here and you're done, but you stay uninformed&quot; course.<br /> <br /> You might wonder why I don't just use the &quot;build&quot; features in NetRadiant. Because I want to be in control, and I want to be flexible. This crash course will, for example, deal with &quot;amplified radiosity bounces&quot;, the lightmapscale and somesuch. If I had used the build features as presented, I'd still only work with non-amplified bounces, I wouldn't have dealt with the gridsize or the lightmapscale, I wouldn't have used the &quot;filter&quot; feature. Maybe there's still stuff to discover, but I won't discover it if I use the preconfigured built-in buttons. You don't have to go that way, but I won't spare you the ugly details.<br /> <br /> '''So, until now you have installed the Tremulous client, the NetRadiant map editor, the NetRadiant support files, you have configured NetRadiant a bit, you have hopefully gotten your hands on a good q3map2 frontend, and you have created those folders. That's it, now let's go mapping.'''<br /> <br /> ==NetRadiant crash course==<br /> <br /> In Netradiant, move the mouse to the white area with all the confusing lines. Click and hold the left mouse button. Drag the mouse a bit. Release the left mouse button. You just made a floor. Or a ceiling. '''That thing you just made is called a [[brush]].''' This can only be done in the 2D view. Brushes are the building blocks used to make the map world. They can be changed into different shapes and also be drawn directly in different shapes, but most of the time, you'll draw simple box brushes. If you have done everything in the setup section, the box you have just drawn should have a number pair at its left top (position), a number on the right side and a number on the bottom (dimensions). The unit system used is called &quot;world units&quot;. Rule of thumb (that I heard - can't say that I have really verified it) is: 32 world units = 1 meter. There should also be red lines from all four directions leading to the box brush you made. Click and hold the right mouse button. Move the mouse a bit. Release the button. You have just dragged the whole 2D world. Scroll the mouse wheel to zoom. '''You can now navigate the 2D view.'''<br /> <br /> By the way: When you draw a brush, you obviously control its dimensions in both directions, but what about the third? NetRadiant will make the brush as thick as the gridsize is set - unless your work area (the one we made visible via menu &quot;view&quot;, submenu &quot;show&quot;) says different. So, the last thing you had selected (even if it is now deselected) decides how thick your brush will be. You can of course change the size of a brush afterwards, but now that you know this, you'll some day begin to take this effect into account.<br /> <br /> On the right side, you should see a big gray empty space. That's the 3D view. This one is a bit tricky. I hope you have deactivated the far clip plane in the preferences (&quot;camera&quot;) as I've said. Otherwise, the next steps might take you too far away from the box you just drew, and so you would not get to see it. Right click in the 3D view, and release the mouse button. The mouse cursor should have vanished. When you do that again, the mouse pointer returns to normal. With the mouse pointer locked into the 3D view, press the downwards arrow on your keyboard for about one second. After that, move the mouse around in all directions. If you have done everything as I said, you will find an ugly pink box. Congratulations! You've just discovered the world of the mapper: Ugly pink boxes. Much of the mapping process will take place in your head, not in front of your eyes. Experiment with the arrow keys, the mouse movements, the CTRL and SHIFT key, and the mouse wheel in the 3D view. '''You can now navigate the 3D view.'''<br /> <br /> Time for a few keyboard shortcuts:<br /> <br /> Press the ESC key. The box should now look different in the 3D and 2D view because it is no longer selected. In later situations, you'll have to press the ESC key several times in a row to '''deselect stuff''' because some selection modes go deeper into the structure, and every ESC press takes you a step back until everything is harmlessly unselected. And then it looks like it does now.<br /> <br /> To '''select the box''' again, click on it in the 3D view while holding SHIFT. Most of the time, you will select stuff in the 3D view because it's a pain in the ass to do so in the 2D view. NetRadiant still needs much work. Why they didn't include a box selection mode that only selects stuff that completely fits into the box is beyond me. Don't they use their own software?<br /> <br /> Now that the box is selected again, press the BACKSPACE key. You know, the big leftward arrow above the return key. Whoops, '''box deleted'''. Select &quot;'''undo'''&quot; from the &quot;edit&quot; menu or press CTRL+z to get it back again.<br /> <br /> We will now apply a texture to one of the sides of the box. Well, it already has a texture - the name is '''&quot;Caulk&quot;, that's the most important texture of all''', really. You should have this texture applied to every surface that the player cannot see. So, it's best to start with all-Caulk'd surfaces, and whenever you're working on stuff, keep in mind that every unused surface should be returned to Caulk. This is not a ''must''. But you'll bite your own ass one day if you want to squeeze all possible FPS out of your map, so you'll want to Caulk everything, but didn't take care all the time to prevent unnecessary textures. I've been there.<br /> <br /> Press ESC to deselect the box. Now click on it in 3D, but this time, hold SHIFT and CTRL. '''You just selected a surface.''' The texture browser is right under the 3D view. Doubleclick on &quot;arachnid2&quot;, wait till all textures are loaded, then click on the first texture that you can see: &quot;001metal&quot;. Yay, '''you painted the surface'''. The texture in the texture browser does have a red border now. This means that this is the current texture. Without changing the preferences to &quot;new brushes have Caulk&quot;, every new brush you make would have the red bordered texture. But believe me that you'll later find out yourself that you don't want to go that way. Next to the big texture with the red border, there is &quot;arach_fog_s&quot;, a '''texture with a white border'''. Textures with white borders are [[shader]] textures. Shader textures are not just images, they can even have functions, for example they decide whether a brush textured with them is made of water that you can swim in - or slime/lava that kills you.<br /> <br /> Remember the folders you made in the &quot;base&quot; folder? The pictures you see in the texture browser are stored in the folder &quot;textures&quot; or in one of its many virtual versions - I am speaking of the texture folders in all those .pk3 files. They are treated as if they were really existing folders/files. Which means that it's easy to have a file with the same path and file name existing several times, something impossible in the normal file system (may I remind you that I speak from the Windows perspective). '''You should read the [[.pk3]] article''' because it contains important information on how to deal with this. It's really tricky, and you don't want to go through the process of finding out the hard way. Things that can happen if you fail here: Your map can cause other maps to malfunction. Or your map will be incompatible with older versions of itself. Or it will not function the way it did on your computer. By the way - if you wonder where the textures of all those maps you might have downloaded and played until now are: On my machine (Windows), I have ''several'' &quot;base&quot; folders. One is somewhere in the system user area. If you want to use the textures of those maps, too, move them into the &quot;base&quot; folder where the program is installed. And no, you don't have to unpack the .pk3 files to use their contents in NetRadiant. But if you're a mapping beginner, you shouldn't have other files in your installation &quot;base&quot; folder than the ones that actually came with the Tremulous installation (and the Radiant Tremulous support file). Reason: Later, you'll make a .pk3 release pack, and you have to put all files into it that people will not have from the default installation, so have fun figuring those out when your &quot;base&quot; folder is polluted and you're a beginner.<br /> <br /> In the beginning, you will probably use the textures/shaders/sounds etc. that are part of the original Tremulous 1.1.0 pack. '''You don't have to deliver Tremulous 1.1.0 standard files with your map''' because you can assume that everyone has those. I don't know about the Tremulous 1.2 world that is about to emerge, though. But until now, it's the right way to go, and many people have done so. It's accepted. It keeps your map file small. And it means less file- and folder-hassle for you.<br /> <br /> '''Let's save the map.''' NetRadiant doesn't know a name yet, so it will show you a box where you can enter a name. The folder (&quot;maps&quot;) should already be set. Or did you forget to make the folder? You can leave the name &quot;unnamed&quot;, I mean, why call it &quot;terror castle zero&quot; when you don't even know how to make one. From now on, you can just press CTRL+s to save the map. And from time to time, go to the folder window (outside NetRadiant) and '''make a backup of the map file''' (e.g. by copying and pasting it into the same place). Too much garbage in the folder? Learn to live with it. You don't want to live with lost data. '''Maps can get broken in weird ways.''' If you know how to debug them, good. Otherwise, go to an older version and start over. Example: Maybe you know that a map file is just a human readable text that you can open in any text editor. If you open a more complex map, you'll see that it only consists of [[entity|entities]] which in turn sometimes have parameters and/or brushes. Now, one of the bad things that can happen (because NetRadiant is really just a rudimentary editor that allows to make maps but which is really far from being a reliable pro tool) is that an entity that needs brushes (as for example a door - the brush(es) are the moving door) loses all of them. Such a map would not run in Tremulous. To fix such a situation, you would have to use a text editor, locate the erroneous entity and fix or delete it (which is not hard but also not for beginners). Or you'd go back to a previous map version. And no matter how experienced you'll be one day, there will sometimes be problems that you cannot fix. For example: I had a map once with one telenode. The Tremulous client, though, behaved as if there were two. But there was only one. That's easy to verify because the node can be searched for in the text file. I even searched in the compiled map: Only one telenode. Well, the system is not free from bugs, and this is what can happen. Because I was already so far into the map, I had to test-delete many brushes, compile, run - still one telenode too many. Again. And so forth. After a day, the problem was fixed even though the elements that I finally found out to delete and remake didn't have anything to do with the telenode and also didn't seem broken. Also, the telenode problem was absent in some of my delete runs - even though it was different stuff that I had deleted.<br /> <br /> Another word on backups: If you're not a total computer noob, you use archiving software from time to time. But &quot;ZIP&quot; is not the archive format of choice (except of course to make .pk3 files, those have to be ZIP, but you can create that with other archivers, too). [http://www.win-rar.com/downloadnow.html RAR] is very good (but not free, so there's a nag screen or you have to pay). But the best one currently (even though it doesn't support recovery records - haven't really needed those till today, anyway) is [http://www.7-zip.org/ 7z], and it's free. There are also versions for Linux etc. (search yourself). So, why do I mention all this? Well, if you have a bunch of backup copies of your map file (which will eventually outgrow the 1 mb limit, can even reach 20 mb), you'll quickly have tons of &quot;wasted&quot; space. But don't delete the backups if you're not absolutely perfectly sure that you won't need them any more! Just compress them. They compress very well, to about a 10th of their size. And if you use a ''modern'' archiver instead of ZIP when compressing like 20 backups into one archive, the archiver will not just squeeze down every map backup individually, but it will take into account that most parts of the files are equal. That's called a &quot;solid archive&quot;. Unpacking stuff out of them is a bit annoying because oftentimes, the whole archive has to be calculated through for one file. But who cares. So: Just pack all your backups into one archive from time to time. Instead of 100 mb &quot;wasted&quot; space, you'll only have like 1 mb! And you will have all backups of your map! I do it like this for every map individually: &quot;backups till 2010-06-29.7z&quot; and so forth. Makes you sleep better.<br /> <br /> The last word on backups: It's not enough to just backup the map onto the same machine. That is only for the work process in case something gets broken or you need to copy an object from an earlier version that doesn't exist in the current one. No, you also need to backup your files from your PC to another medium. That doesn't really belong into this article because every serious computer user should do that from time to time anyway. But I'd like to mention that here. What I do (apart from backing up my whole machine onto extra harddisks that I then put away somewhere from time to time): I have all mapping relevant files in the Tremulous install folder. And so, I just make a 7z archive of the whole folder tree once a week or so, and I copy it onto a USB stick. I don't know how reliable those are, but my experiences have been good so far. You'll sleep better if you know that the hundreds of mapping hours are safe somewhere.<br /> <br /> Let's go back to our brush. Press ESC to deselect the surface. Then SHIFT and left-click the brush to '''select it in the 2D view'''. Yes, in the 2D view. You can also hold SHIFT and the left mouse button, drag a box that touches the brush you made, and release both. That's the '''box selection'''. Another thing you can do (but you can't really test now because you only have one element in your map) is to SHIFT and left-click in the 2D view and also hold the ALT key. This selects one of the things that are in the position that you click at, just as the normal SHIFT and left-click does. But if you do this several times, the first selection is deselected, and something else in the same place is selected instead. Very useful function to '''toggle through all the stuff in that place.''' Less useful is the fact that it is buggy - sometimes, you have to move the mouse a bit to make the program allow you to use this function again. Box-selection (SHIFT and left-click, drag, release) is also possible in the 3D view (also the SHIFT-ALT-click toggle-through-stuff function), and only the elements currently in view will be selected - so you'll probably enable far-clip-plane from time to time (preferences, &quot;camera&quot;), adjust its distance (menu &quot;view&quot;, submenu &quot;camera&quot;), enabling you to easily select a group of objects (for example a truckload of lights that you used to slightly paint the light situation without people noticing) in front of you while the things behind them are too far away to be visible or get selected.<br /> <br /> If you have a look at the menu &quot;view&quot;, submenu &quot;filter&quot;, you see that you can '''filter''' the 2D and 3D view for the many different kinds of things and thing-groups that a map can consist of. This will be very useful for selecting. And for not getting distracted/confused. Also, displaying the graphics in the editor is faster if less stuff is being drawn, obviously. If you see anything in the filter list activated right now, select the lowest point &quot;reset filters&quot; which will turn everything off - so that you can see everything that exists in the 2D and 3D view. Another way of '''making stuff temporarily invisible''' is the '''hide function'''. Make sure your brush is selected. Then press the &quot;h&quot; key. Bang, it's gone. You can hide all kinds of elements. If you want everything to be visible again, press SHIFT &quot;h&quot;. Filters and hide have no influence on the map functionality, they are not even stored in the map file. When you close NetRadiant and open it again, the previous filter settings are still active which can be confusing at times. The hidden stuff, though, is visible again. By the way: Did you notice the - - - - - line at the top of the menu? If you click that, the menu will be opened in a window that does not go away when you select something in it. Very useful.<br /> <br /> Another very important function that can be toggled on and off is the &quot;'''texture lock'''&quot; function. There is a button with a lock picture for that somewhere at the top right of the screen. When it's active, it should actually blink and play a loud HONK!-sound all the time or something. And when NetRadiant is closed and opened again, it should be deactivated. But all of this does not happen. So, '''you have to take care whether or not the texture lock function is activated'''. Here is what it does: When it's not on, the textures on a brush seem to scroll around when you move the brush around. That is because the textures are normally locked to the world position. This is very practical, as you will find out with time. Now, the &quot;texture lock&quot; function changes that: When you drag a brush while that function is activated, the textures of the brush will move with it. That is very useful in cases where you have made a brush or several brushes with specific texture work (for example light fixtures), and you want to move those brushes without the design to change. Be aware whether or not the function is activated. You will remember this text here for sure. Because you will at some point see textures in wrong positions, realizing: &quot;Damn, I moved brushes around with texture lock on! Why isn't that function automatically turned off when I start the program?&quot; The texture lock function also changes the behavior of textures when you use the rotate-brush-by-90-degrees function.<br /> <br /> Remember when I called your brush a floor or ceiling? That's because the 2D view shows a view from the top (or bottom, depends on how you think) on the map when the program opens. Press CTRL and TAB. If nothing weird is going on with your input focus and keyboard (which can happen from time to time), the '''2D view was just switched from &quot;top view&quot; to &quot;side view 1&quot;'''. Do that again, and it changes to &quot;side view 2&quot;. Once again, and you're back at &quot;top view&quot;. You can determine what view you're currently on by looking at the little right angle labeled &quot;z&quot; and &quot;y&quot; or &quot;x&quot; and &quot;y&quot;, you get the picture. You'll probably determine that later by rather looking at the map, though. It's helpful/important to learn that the vertical axis is the Z axis. If you can currently see the X and Y axis, you're looking along the Z-axis (meaning: from the top).<br /> <br /> Now, let's finally get to '''how to move and scale a brush:''' Make sure the brush is selected. In the 2D or 3D view, click on the brush, hold the button, move the mouse, release the button. You just moved the brush (if the grid versus the amount of mouse movement didn't prevent this). Moving it in the 2D view makes sure that it is not moved along the axis that is pointing directly towards you. Moving it in the 3D view is comfortable, but can have unwanted results because of the fact that the camera is &quot;never&quot; perfectly aligned with the three space axes. To scale the brush instead of moving it, do the same, but don't click inside of it. Instead, click beside it. Important: Don't scale it too small so that it vanished. I have no idea what happens then. I always hit &quot;undo&quot; in such a situation. Might be a map-breaker.<br /> <br /> '''The grid''' is very important. In most cases, brushes should be perfectly aligned with grid points. Otherwise, have fun debugging your map. To '''change the grid scale''', press one of the number keys from 1 to 9. You can also do that in the grid menu. You'll do that from time to time, because, believe it or not, the grid spacings below 1 are actually used sometimes. The current grid spacing can be seen at the bottom of the NetRadiant window, on the right side. Careful with the key &quot;0&quot;: It toggles the grid from visible to invisible (and back). On a side note: I hope that the NetRadiant developers will be nice and implement a feature that draws the grid with thicker lines (e.g. 3 instead of 1 pixel) because it's simply invisible with all the stuff in front of it on more complex maps, and that sucks considerably.<br /> <br /> '''A word about world units / grid size / reactor and overmind etc.:''' It will take a while until you have memorized all the building and player sizes. Until then, just memorize this: An opening or room with the size '''128x128x128''' (second largest grid setting (&quot;8&quot;)) is just high and certainly wide enough to contain the overmind or reactor (112 would be enough). Tyrants etc. fit through nicely (96 would be enough). Those numbers might not really tell you anything, but any long-time computer user knows the drill: 1 2 4 8 16 32 64 128 256 512 1024 2048 4096 8192 16384 32768 65536 ... You should know those numbers up to 256 to be more efficient with NetRadiant. And 96 is three elements of the size 32, '''96 is just high enough for a tyrant''' to get through. '''64x64x64''' is big enough for a dragoon. A human can still crawl through a height of 32, if I am not mistaken. '''If you want to make a stair, 16 is a nice step height.''' Though 16 might seem a bit big on closer inspection since it's theoretically half a meter.<br /> <br /> Make sure that your brush is selected. Then, press CTRL and C, then CTRL and V, or use the &quot;edit&quot; menu. The '''brush exists now twice in the same place''', a common error that can cause weird map behavior, yet a situation that you will intentionally create many many times, because it's often useful to take an existing brush and copy/paste it somewhere else. At this point I should remind you: Keep everything Caulk'd that cannot be seen by the player. Ok, now press ESC. Yes, keep the two brushes in the one place for now.<br /> <br /> Travel to the side of the brush that shows the &quot;001metal&quot; surface. Select it (SHIFT CTRL left-click). Now go to another texture section. Not &quot;arachnid2&quot; but instead &quot;common&quot;. Most of the '''textures in the &quot;common&quot; group''' are actually shaders, as you know already because you saw the white borders around them. The one called &quot;caulk&quot; is among the first. It should have a green border because the currently open map uses it in at least one place. Click on &quot;caulk&quot;. This applies the caulk shader to the surface you selected. It also gets the red border because it's now the current texture, which is unimportant to us because all our new brushes have caulk, not the current texture. The &quot;common&quot; textures are really useful. There is, for example, a shader called &quot;ladder&quot;. Any vertical surface that you apply this texture to can be climbed. It's really that simple. Well, to make an actual ladder, build something that looks like it can be climbed, then make a brush with the ladder shader around / in front of it. The ladder shader is invisible, but you can't walk though it. There is also a texture called &quot;clip&quot; which you'd sometimes use to invisibly even out too odd wall and floor situations. The dretches will thank you. The players who don't get stuck while running away from the beasts will thank you, too. Some of the textures/shaders of the &quot;common&quot; section can be used without you having to distribute these shaders with your map (like for example the &quot;caulk&quot;, &quot;ladder&quot; and &quot;clip&quot; shaders), but it's best to just add these few bytes to your map file. Better safe than sorry. Ironically, the &quot;invisible&quot; shader, for example, would cause '''&quot;missing texture&quot; optics''' (Missing textures in the game are gray with a big white grid. Hard to miss. Easy to miss, though, if your testing environment is improper, because then you'll not have missing textures, but the players will.) if the Radiant Tremulous support files are not present, so put them into the release file. A .pk3 without those shaders will of course work on your machine - because you have the &quot;data-radiant-1.1.0.pk3&quot; in your &quot;base&quot; folder! Others do not have this.<br /> <br /> '''Get to know the phenomenon called [[Z-fight]] (or Z-fighting):''' Press ESC to deselect. Now, select &quot;the&quot; brush (doesn't matter which one, but just one of them, Wassily), so SHIFT left-click on it. Now for the important part: Move the brush a bit. Not too much. You'll see that the copy (or the original, you never know which one you'll click if there are several in one place) is revealed by you moving the other one. Don't move it too far - they should still overlap. Now, study the area in which the textured face of the one brush and the Caulk'd face of the other brush are drawn in the same place. Move the camera around a bit. If you've done everything right, then you are just observing a Z-fight. Two surfaces want to have the same distance from the observer and fight about it. No one wins, especially not the spectator/player. For historical reasons, the distance an object has from the camera is called the z-distance. You could also read up on the term &quot;[[Z-buffer]]&quot;.<br /> <br /> It is very probable that you will get to see Z-fighting somewhere during one of your many testruns of your maps. You can even find those in finished maps that can be found on many servers. I can remember at least one z-fight in a professional map that came with Tremulous 1.1.0 ([[Nexus6]]). Ironically, right now, there is nothing wrong about your map in that regard. Because one of the two surfaces that are fighting has the Caulk shader - which is defined to be invisible. There would be no z-fighting in your map right now.<br /> <br /> '''Mirroring and rotating:''' Select one of the brushes and toy around with the 6 buttons at the top left of the NetRadiant window. The first one is &quot;x|x&quot; and mirrors the brush along the x axis. I find it irritating that the Radiant developers chose to mirror the brush ''along'' the x axis instead of using the x axis as the, well, mirror axis, but you'll get used to that. The button next to that is the rotate-around-x-axis button, and that actually works like you'd expect it. Depending on the grid-versus-brush situation, the position of the brush gets changed accordingly, too, so later, you'll adjust the grid spacing before rotating a brush around 90 degrees. Mirroring does not care about the grid, just about where the brush begins/ends. If the &quot;texture lock&quot; is active, the textures get rotated and mirrored accordingly. Nice one. But if you rotate a brush using &quot;arbitrary rotation&quot; (menu &quot;modify&quot;), the textures will not be rotated with it, no matter if the &quot;texture lock&quot; was active or not. &quot;arbitrary scale&quot; (same menu), though, scales the textures (if &quot;texture lock&quot; is on).<br /> <br /> Left of the &quot;texture lock&quot; button, there is another (currently selected) button with a rectangle inside of it. If you hover your mouse above it, it'll say &quot;Resize (Q)&quot;. That's your normal brush draw/move/resize tool. Two buttons to the left, there is the &quot;Rotate (R)&quot; tool. Select it and rotate your brush a bit. This is the same as &quot;arbitrary rotation&quot;, only it's handled with the mouse instead of numbers. Don't forget to switch back to &quot;Resize&quot;.<br /> <br /> Now a quick tour of '''dealing with entities''': In the &quot;view&quot; menu, select &quot;entity inspector&quot; (or press &quot;n&quot;). There are several sections in that new window that appeared, and you might have to vertically scale those sections a bit before use. The most important area in that window is the one saying &quot;classname worldspawn&quot;. If there is no such text visible, you probably don't have a brush selected at the moment. Select one (or several, doesn't matter now). If there's still no text &quot;classname worldspawn&quot; in the window, you have to scale and move stuff in the window around a bit. The &quot;most important area&quot; with said text is not the lowest part of the window, but it's the lowest big white box in the entity inspector. Once you've found it, click on the text &quot;classname worldspawn&quot;. You'll see that, once you've selected it, the text &quot;classname&quot; appears below the area in a textbox labeled &quot;key&quot;, &quot;worldspawn&quot; in the &quot;value&quot; box. The '''key-value-principle''' is very important. The area in which you selected the key-value-pair will later have more key-value-pairs. These are the properties of the entity that you've currently selected. Wait, a brush is an entity? Well, if you deselect the brushes with ESC, &quot;classname worldspawn&quot; is no longer visible in the entity inspector window (only as a relict in the &quot;key&quot; and &quot;value&quot; input text boxes). So, every brush is an entity with the text &quot;classname&quot; in it? No. All brushes are one combined entity. The entity's name (And it's better to think of this as a type, not as a name. Later, you will have several entities with &quot;classname&quot; &quot;light&quot;, so it's obviously not just a name but really a type.) is &quot;[[worldspawn]]&quot;, a term mappers toss around oftentimes. Every map has min. and max. one worldspawn. It's the first entity in the .map file (if you look at it with a simple text editor.) The worldspawn can have very important settings regarding the map, for example the amount of buildpoints the teams have, or you can add a little message that is displayed while the map loads. The text area above the &quot;most important area&quot; describes which keys and values can be used for the world spawn. Once you select a different type of entity in the 2D or 3D view (or in the area at the top of the entity inspector, where all possible entity types are listed), the help text changes.<br /> <br /> When dealing with the entity inspector, be careful what you have selected in the map. It's possible to select a brush (usually part of the one &quot;worldspawn&quot; entity) and another entity type, for example a &quot;light&quot;. This flexibility can be useful, but if used improperly, it's a big source for errors. '''Always be aware of what's selected before using any function.'''<br /> <br /> Now, let's use an entity we haven't used before: Select one (or all) of the brushes. Then, right-click in the 2D view. A menu should appear. If it didn't, try again without moving the mouse even the slightest bit. In the menu, go to the item &quot;info&quot;, and from the new submenu, select &quot;info_player_intermission&quot;. This creates a little box of that entity type. Also, the brush(es) that were selected have gone, replaced by the new entity. You better undo that and remember this effect for later, because if you're dealing with a somehow broken map later, it might have been caused by the action that was just demonstrated. But everything should be fine if you use &quot;undo&quot; on such an action. Ok, now press ESC to deselect everything, and then create the entity anew. What is it good for? Well, it defines the position and orientation of the spectator camera when you enter a map or leave a team. '''The &quot;info_player_intermission&quot; entity is absolutely essential. Without it, a map does not work in Tremulous!''' The &quot;info_alien_intermission&quot; and &quot;info_human_intermission&quot; entities have a similar function (camera position and orientation when you're on a team and are currently not alive), but they are not technically necessary. You'll of course place them when you're making a real map.<br /> <br /> You can use the &quot;arbitrary rotation&quot; or the mouse rotate tool to change the direction into which the player_intermission camera is facing.<br /> <br /> Man, I almost forgot THE LOG. Move the mouse to the bottom of the window directly above the status line (that's the area with several texts and horizontal segments). There should be a handle looking like ............ Click and drag it up. You should now see the log. Sadly, you'll have to do that again next time the program is opened. The log shows the actions the program performs (and errors that happened). Have an eye on the log when you map, it'll save you a few map-repair-sessions because you'll see that something you wanted to do didn't work out, or something was done that you didn't expect and so forth.<br /> <br /> There are more NetRadiant explanations in the other sections of this mapping crash course.<br /> <br /> ==making your first (ultra basic) map==<br /> <br /> ===create the map===<br /> <br /> Now that you know how to handle the most important functions of NetRadiant, let's make a map, violating all rules, offending all experienced mappers. In the &quot;file&quot; menu, select &quot;new map&quot;. If a window appears asking you if you want to save the current map, you're doing it wrong because you should have saved the map already a few times with at least one or two backups. Ok, it's a worthless map that you wouldn't really save or backup often, but I want to give you an idea of how to deal with a real map.<br /> <br /> Press CTRL and TAB until the 2D view shows the X and Y axes, so you're '''looking from the top. Press the key &quot;9&quot; to have the largest grid spacing.''' If the grid is invisible, press &quot;0&quot;. If that doesn't make the grid visible, then it probably was not invisible before but just too big for your current zoom (use mouse wheel and maybe &quot;0&quot;). Read on once the grid is visible and also on its largest setting (displaying &quot;G:256&quot; at the bottom of the window).<br /> <br /> '''Create a brush in the 2D view, exactly one grid block in size.''' The numbers on its right and bottom size read &quot;256&quot; if you've done it right. Assuming that 32 world units are one meter, this brush is a nice 8 by 8 meters floor. Which is also 8 meters thick, by the way. But who cares. It's not like we're wasting concrete or something.<br /> <br /> The brush is pink, yes? Otherwise, shame on you. Now, move the camera in the 3D view so that you can see the top of the brush. Select the top face (CTRL SHIFT left-click, don't just SHIFT left-click it or you'll select the whole thing). Go to the &quot;arachnid2&quot; texture section and click the first texture (&quot;001metal&quot;). '''The top surface now has this texture.'''<br /> <br /> Press ESC to deselect everything. Then right click in the 2D view, and select &quot;team_human_spawn&quot; from it. Press ESC again, call the menu again, and select &quot;team_alien_spawn&quot;. Press ESC again, call the menu again, and select &quot;team_player_intermission&quot;. Great! '''Now you have all the three essential elements''' that you need to have a working Tremulous map. But there is a problem: '''If the spawns are not in a proper place''', they might not get created when the map loads. So, move the egg and the node around until they stand somewhere on the box. Make sure that there is enough distance between the two. Also, have a look at them from the side: They must not be too close to the surface of the box or they will not get created when the map loads. You can really place them quite high (Be reasonable.) above the surface. When the map loads, they will be created in that spot and then fall down to the surface (without taking damage). To move the entities around, you have to set the grid to a higher resolution. Just blindly hit one of the left digit keys for a high resolution, which one doesn't matter at the moment. By the way: Too many people ''in the game'' fail to place the spawns in the right rotation. It's easy: The player will spawn to face the position from which you made the spawn. Makes sense: That position can be assumed to be a valid place to go. Making spawns in the right rotation can influence the game flow positively.<br /> <br /> Please check if the surface on which you are trying to put the spawns is the one you have textured. If not, then you did something wrong earlier when texturing it. Spawns cannot be rotated in the editor in the way that they can be put on walls or something, so it's not the spawns that are wrong. By the way, you can '''rotate the spawns''' around the high axis (Z) to define the direction into which the player will look when he spawns. The human spawn, at least the one in the editor, has the aparatus-thingy on the side into which you will spawn. The egg spawns you into the direction the red axis at the egg's center points. The human spawn does so, too, but the aparatus-thingy is easier to see.<br /> <br /> Ok, we have a floor with a texture, both teams have a spawn, and the player_intermission camera does also exist (maybe you want to move and rotate it around a bit until it will probably show something meaningful, but it's not necessary for the map to run).<br /> <br /> What's missing? Light! ESC, 2D, rightclick, '''select &quot;light&quot;'''. A text box appears. Make sure that the number inside of it is &quot;100&quot;. That's the brightness of the light. Click ok or press RETURN. Pressing RETURN is not always advised: The &quot;arbitrary rotation&quot; dialog, for example, will not do anything then. Now move the point light you created until it is in the middle above the box brush. For that, press &quot;8&quot; to set the grid to the second largest spacing. Now it's easy to move the light to the middle. Seen from the top, it must be in the middle. Seen from the side, it must be one grid step above the floor. With setting &quot;8&quot;, that's 128 world units - 4 meters.<br /> <br /> ===build the BSP file and run it===<br /> <br /> If you have not yet saved the map, shame on you. Also, do it now. The name should be &quot;unnamed&quot;. Then, close NetRadiant. '''Because now we'll play the map!'''<br /> <br /> If you're a lucky Windows user, you'll have downloaded and configured q3map2build, I hope. Start that program, select the map &quot;base\maps\unnamed.map&quot; that you've just created, make sure that &quot;Play after build&quot; (left border of the window) is activated - and then click &quot;build&quot;!<br /> <br /> Alternatively, if you are not using this nice frontent for q3map2, you can create a batch file. The program does nothing different, only it's more comfy, and the texts displayed when you hover the mouse above the many switches certainly make things more clear. So, if you don't use the program, create a batch file. That's a normal text file with commands in it that has to be renamed to &quot;somethingsomething.bat&quot;. Sadly, those mega-idiots at Microsoft chose to hide file extensions (stuff like &quot;.bat&quot;) by default, so you can't rename the whole file name, only everything except the extension. For this reason and overall security improvement, Windows users are urged to turn the display of file extensions on. In any file explorer window, go to the &quot;Tools&quot; menu, select &quot;Folder Options&quot;. At the top of that new window, click on &quot;View&quot; and then scroll down until you see the option &quot;Hide extensions for known file types&quot;. Turn it off and click &quot;Ok&quot; at the bottom of the window.<br /> <br /> Here's the text for the batch file:<br /> <br /> &quot;C:\Program Files\netradiant-20100214-win32\q3map2.exe&quot; -fs_basepath &quot;C:\Program Files\Tremulous&quot; -fs_game &quot;base&quot; -custinfoparms -info -meta -patchmeta &quot;C:\Program Files\Tremulous\base\maps\unnamed.map&quot;<br /> &quot;C:\Program Files\netradiant-20100214-win32\q3map2.exe&quot; -fs_basepath &quot;C:\Program Files\Tremulous&quot; -fs_game &quot;base&quot; -vis -saveprt &quot;C:\Program Files\Tremulous\base\maps\unnamed.map&quot;<br /> &quot;C:\Program Files\netradiant-20100214-win32\q3map2.exe&quot; -fs_basepath &quot;C:\Program Files\Tremulous&quot; -fs_game &quot;base&quot; -light -bouncegrid -custinfoparms -filter -patchshadows -bounce 500 -bouncescale 2 &quot;C:\Program Files\Tremulous\base\maps\unnamed.map&quot;<br /> Pause<br /> &quot;C:\Program Files\Tremulous\tremulous.exe&quot; +set fs_basepath &quot;C:\Program Files\Tremulous&quot; +set fs_game base +devmap &quot;unnamed&quot;<br /> <br /> The line &quot;Pause&quot; is not necessary, though it can be useful to have the process wait between calculating and playing. q3map2build has options to insert &quot;pause&quot;, too. I once had the computer calculate a map for four days in a row, and I had &quot;Play after build&quot; unchecked because why should I &quot;burn&quot; my machine uselessly? This means that after calculating, the machine would just have closed the system's console text box without me being able to read the text. This makes the &quot;pause&quot; feature seem much less superfluous all of a sudden. Of course I could have saved the console output into files automatically (by adding &quot; &gt; outputtext1.txt&quot; to the end of the first line, and bla 2 3 4 to the other lines), but then again I wouldn't have been able to have a look at the console text because it would just have been in the files.<br /> <br /> You'll probably have to adapt the batch file text to suit your computer/setup.<br /> <br /> Doubleclick the batch file to start the compile.<br /> <br /> One of the things that will appear in the text window (which is the system's console text output) is &quot;LEAKED&quot;. Well, we didn't give the map a proper shell, we just made a floor. Doesn't matter at the moment, but later, we'll have to improve on that.<br /> <br /> Well. If everything went right, you're playing the smallest map in the world. And everything around your little world is pitch black. Or you see the [[hall of mirrors]] effect around you, really annoying. But it's a working Tremulous map!<br /> <br /> I bet you want to experiment now. Do that. But don't yet make a big map that kinda asks to be published, people are probably not going to like it. You have to learn some more first.<br /> <br /> <br /> <br /> <br /> <br /> ==making your second (more advanced) map==<br /> <br /> ===choose a name===<br /> <br /> You can freely create folders in the &quot;map&quot; folder, doesn't hurt the game system. So, you should make a folder and throw all files into it that have been created so far.<br /> <br /> Now, open NetRadiant (or select &quot;new map&quot; from the &quot;file&quot; menu if it was already open). Save this empty map. Reason: '''We want to give it a name.''' Press CTRL and S (or select &quot;save&quot; or &quot;save as&quot; from the file menu). The name shall be ... wait, what's your nick name? The name you use as a player or in the forums? If it were &quot;God, maker of the world&quot; (which is my nick name), we could make a short version of that, for example &quot;gmotw&quot;. Let's assume that your nick name is &quot;scrollbar5&quot;. A shorter version would be &quot;scr5&quot; or something. Let's stick to that. Back to naming the map: Please save it as &quot;scr5_dretchnest&quot;. If you actually have a nick name that you want to stick to and that can be nicely expressed with a few letters, use that from now on. I'll keep calling it &quot;scr5_...&quot;.<br /> <br /> You see where I'm heading. I called my first map [[Gmotw_Skybox|&quot;gmotw_skybox&quot;]], and this is not mainly about people attributing the map to my person (or so that all my maps would be in one alphabetical place in the huge map repositories that exist, hehehe) but instead so that I could freely choose my map names without having to worry about the name maybe already existing - or someone else taking the same name. I have not yet seen anyone do it like this, but I think this is actually the way it should be done by everyone, and so I tell my helpless scholar prey (Not really.) to do it just like that. '''Add a short version of your nick name with a &quot;_&quot; at the beginning of your map names.''' Keep it short, though. It's good if this prefix &quot;doesn't make sense&quot;, so it's not confused to be a part of the map's real name. So, &quot;gmotw_&quot; (Hey, that's mine.) is better than &quot;stellar_&quot;. By the way, if you look at the screenshot in the skybox article, you read the message &quot;Remove older versions of Skybox to prevent texture problems.&quot; which is really lame. You won't have problems like this since you can read my experiences and conclusions in this mapping guide. Comfy, no?<br /> <br /> If you use these prefixes, by the way, '''NetRadiant will nicely group all your map assets''' in the texture browser instead of spreading them all around the alphabetical map list.<br /> <br /> If you've read the [[.pk3]] article (which you should at some point), you'll already know about the '''filename uniqueness problem''' and about how to deal with it through several release versions of your map. We have halfway solved the uniqueness problem by choosing &quot;scr5_dretchnest&quot; (or whatever your prefix is), which is probably a name not yet taken. Except if 10 people go through with this mapping crash course without choosing a different prefix. But I wonder if anyone's gonna read it at all :/<br /> <br /> A word about &quot;alpha&quot;, &quot;beta&quot;, and &quot;final&quot; releases: BULLSHIT! That was actually just one word. No really: I think it's a meme or an &quot;I'm doing it just like the real guys! I feel like I'm taking a step into a larger world!&quot;-thing that people release their maps as alpha, beta, and final. Well, it has practical reasons, but it also has its problems. To make it short (meaning: I just deleted about 300 words of bla that I was about to save, and that was just the half of it.): Just give your releases a number. So, just add &quot;_001&quot; to the map name. Three digits seems to be much, but you never know. If you increase the release number every time you make a .pk3 and test it with friends or on the server of a guy you know, you'll quickly be above 9, and with all the stuff you have to keep in mind, you don't want to worry about the goddamn number. And once you have chosen to use the path of the &quot;_001&quot;... instead of the &quot;_a01&quot;... &quot;_b01&quot;... &quot;_final&quot;, you'll laugh at all the mappers who have decided to make their maps a &quot;final&quot; too early. &quot;Oh, something's still broken. Damn, already released as 'final'. Can't change it now.&quot; Weird people anyway. I mean, what makes you so sure that you will never add something to the map in a year or so? And then you have the other guys who are more careful. They make their alphas, then you find their betas in the wild... but there is never a &quot;final&quot;. Guess why. The last beta effectively ''is'' the final. Not changed after years. Assimilated by the community. No, you don't want to play that game. '''Just give your releases a number. Just a stupid counter suffix like &quot;_001&quot;.'''<br /> <br /> So, we're about to create a map. The &quot;next&quot; release of it will of course be the first, so its name is &quot;_001&quot;. (I should add that &quot;release&quot; in this context does not mean that you give it to the Mercenaries' Guild Map Repository and brag about it in the forums or something. I am just talking about a proper .pk3 file that you can test on servers.) When people callvote for it, they'd type:<br /> <br /> &quot;/callvote map scr5_dretchnest_001&quot;<br /> <br /> While we're at it: The .pk3 file of this (as can be read in the [[.pk3]] article) would be named<br /> <br /> &quot;map-scr5_dretchnest_001-1.1.0.pk3&quot;<br /> <br /> The name of the .pk3 file has nothing to do with the callvotes. But the name should be kept equal to the real map name for consistency reasons.<br /> <br /> If you're using the batch file solution, please '''edit the batch file just now''' to use &quot;scr5_dretchnest_001&quot; instead of &quot;unnamed&quot;. Reason: So that it hurts if you change the prefix or map name later. Get used to this. Of course, you can theoretically rename a map a hundred times before releasing it the first time, but we want to train here. If you decide to wait with the batch file editing, you're technically making the right choice in case you rename later, but you should experience the name lock, it'll help your mind to get into the real mapper world. Also, all following steps will make use of the map name and cement it some more, and '''you do not want the asset folders and the map to have different names. It's enough hassle as it is, and this would double the file naming work.'''<br /> <br /> By the way, how did I come to the name &quot;dretchnest&quot;? Ok, it's not rocket science, but you'd think that about most map names ''once they exist''. Obviously, I thought of Tremulous elements. What you can do to come up with a map name depends on whether you create it at the beginning, in the middle, or at the end of the mapping process. For example, when I came up with &quot;dretchnest&quot;, I had no idea what exactly the map should be like (other than something with 4 walls that you are supposed to clip diagonally in the corners). I only grabbed a name out of the clouds to complete this section. '''But now that I have a name, it gave me ideas about the map.''' Actually ideas that are ill placed in a beginner's mapping guide, so I'm probably not gonna put them into action here, but here they are: There would be a rectangular (Duh. Beginners always make box maps.) room with a few eggs. The room would be closed from all 6 sides, but there would be openings at the bottom, small enough for dretches to get out. Maybe there would have to be contraptions against crouching humans, maybe that would have to be done by basecamping dretches. If you spawn as granger, you can't get out, so maybe I would have added a trigger that checks if you're granger - and kills you. The ceiling of the room would be something that can be set in motion somehow with a button or by making a building or by reaching a certain spot or by reaching stage 3 etc., and this ceiling would squish the eggs in the room. Since there are no other eggs and grangers cannot get out, the aliens would have lost the game (if the aliens still alive don't win it). This is obviously not a standard Tremulous map, but I digg stuff like this (Trem has enough standard maps, lets bring something new to the table). Read the [[Gmotw_Skybox|skybox]] article if you don't know what I mean. That was my first map, by the way.<br /> <br /> &quot;dretchnest&quot; would have been a fitting name for the above described map. See? '''The name idea resulted in a map idea.''' I believe that it's usually the other way round. But it's improbable that the mapper does not decide for a name until the map is completed, because you'd need to test the map from time to time, and so you'd come up with a name to make a release file. (I repeat: The name you choose once you publish the map should never change, if you can somehow make it so.) Once the name is chosen, the name will probably feedback into the mapping process (e.g. you'd want it to be justified, the least you would do is add fitting decorations).<br /> <br /> '''How you can come up with a map name''': I speak english and german, so when I am thinking about the map that I already created a bit, I think of its prominent building and gameplay elements, enter those terms into a Web translator (like [http://dict.leo.org dict.leo.org]) in english or german, and then I play '''translation ping pong'''. You can also use a Web '''thesaurus''' for that. There are also '''map name generators''' on the Web, probably not Tremulous-specific. You'd rather want to use them for inspiration (and to fuel your translator and thesaurus attempts), not to really make the name for you.<br /> <br /> ===make a shader and a texture===<br /> <br /> Now, go to your Tremulous &quot;base&quot; folder. '''Create a new folder in the folder &quot;textures&quot;.''' Name: &quot;scr5_dretchnest&quot;. Why not &quot;scr5_dretchnest_001&quot;? Because then you'd have to re-assign all textures on every new release because the foldername changes. The project you're working on is &quot;scr5_dretchnest&quot;, and that's the name the asset folders should have. You can also make a folder like this in the &quot;sound&quot; folder, but I currently don't plan on talking about adding a sound. But this is the way it would work for sounds, too.<br /> <br /> If you want to add shaders (which we will do - it's easy if you know how), you have to add the release number again. Reason: The shaders are not several files stored in a new folder, like textures will be. No, the shaders of a map are little text blocks that are all stored in one text file. (You can also make several files, but let's keep this simple.) And '''if you change the contents of the shader file for a new release, you have to give that file a new name.''' Just as if you would have to give a texture a different name that you change from one release to the next. If you don't do this, your map will be incompatible with older versions of itself. You can be lucky with that. But lets do this properly. Use this knowledge. Imagine you had to gather this knowledge by experience which I had to... urgh!<br /> <br /> So, the texture folder is prepared. But '''lets make a shader first.''' Go to your Tremulous &quot;base&quot; folder into the folder &quot;scripts&quot;. Create a new text file called &quot;scr5_dretchnest_001.shader&quot;. If we add a shader into it, it will appear in NetRadiant the next time you start it. Well, you'd think so, but for some reason only the programmers know, you have to add an entry in the &quot;shaderlist.txt&quot; file in the same folder. At the end of that file, add &quot;scr5_dretchnest_001&quot; (without &quot;.shader&quot;), press return, save and close the file. Now open the &quot;scr5_dretchnest_001.shader&quot; file again and put the following text into it, save and close the file:<br /> <br /> textures/scr5_dretchnest/brightglass_001_s<br /> {<br /> qer_editorimage textures/scr5_dretchnest/brightglass_001.jpg<br /> qer_trans .5<br /> surfaceparm trans<br /> surfaceparm solid<br /> cull disable<br /> {<br /> map textures/scr5_dretchnest/brightglass_001.jpg<br /> tcgen environment<br /> blendfunc gl_one gl_one<br /> rgbGen identity<br /> }<br /> {<br /> map $lightmap<br /> blendFunc gl_dst_color gl_src_color<br /> rgbgen identity<br /> }<br /> }<br /> <br /> Close NetRadiant. Open it again and load the empty map file you created. If you look at the texture browser now, you'll see an entry called &quot;scr5&quot;. Now, how did that happen? Oh, the stupid nick name prefix idea! Yes, NetRadiant interprets names with a &quot;_&quot; in it differently. It creates categories. So, all your maps will be under the category &quot;scr5&quot; instead of being spread around like crazy.<br /> <br /> Unfold the category by clicking on the little triangle on its left side. &quot;scr5_dretchnest&quot; appears. It does so for two reasons: 1. You created a folder with that name in the textures folder. 2. You created a shader that in turn created the virtual (= not really existing) file &quot;textures/scr5_dretchnest/brightglass_001_s&quot;, so another reason why NetRadiant would think that the folder exists.<br /> <br /> The texture browser should now show an element called &quot;brightglass_001_s&quot;, something like a blue-black checkerboard, expressing that the image which was to be shown here can not be found. No wonder - we didn't make that one yet. And that's a bit tricky, because I don't intend to explain any graphics software to you now. '''You'll just ''somehow'' have to come up with a .jpg file that has power-of-2 dimensions''' (you know... 1 2 4 8 16 32 64 128 and so forth, computer numbers, as mentioned earlier in this article, though obviously, a texture with ''anything'' on it and the size of 32x32 or smaller hardly makes sense), I'd say 128x128 should be the choice here, that's enough for a simple reflection picture (which this one is). Textures don't have to be quare, by the way, but let's keep this one simple. Also, I think that a texture with an arbitrary size (not power-of-2) would work, too - but what &quot;would work&quot; is not the question. What surely will work in all Tremulous clients and with all graphics cards, that's the question.<br /> <br /> The jpg quality doesn't need to be maximum for a texture. &quot;high&quot; (60) or &quot;very high&quot; (80) (as they are called in Photoshop) is good enough. &quot;medium&quot; is too low in nearly all cases, I'd say. You know what would be nice? An actual screenshot you take yourself in Tremulous. Cropped and sized to 128x128 or bigger, util max. 2048x2048 for a normal texture and, I'd say, max. 512x512 for a reflection texture, but that's plenty. By the way: The bit depth per color channel must be 8, as most existing image files are. You can use 16 and even 32 bit in Photoshop etc., but not in the game. While we're at it: You can also use .tga pictures. If you know when to use gif/png versus jpg, then you know when to use tga versus jpg. Example: If you need a simple color texture (pure red, no other pixels), then .tga is the perfect choice. Tga supports an 8 bit alpha channel (save as 32 bit then, not 24 bit) and also a simple and lossless compression that can be used with Tremulous.<br /> <br /> So, assuming that you have somehow found a suitable .jpg file (.tga (even compressed) would also work, but I think you have to change the shader text then, though I believe that I have seen that the file extension named in the shader is irrelevant, but better safe than sorry), move / rename it to achieve this name: '''&quot;textures/scr5_dretchnest/brightglass_001.jpg&quot;'''.<br /> <br /> Again, close and open NetRadiant and feast your eyes on the new contents of the &quot;scr5_dretchnest&quot; texture browser category. Well, your image should be there now. Twice even. WTF? Well, one instance is from the actual file in the texture folder, and the other one is the shader you created. '''Now you see why the shader ends in &quot;_s&quot;: This prevents the names from colliding.''' (Adding &quot;_s&quot; is the way everyone does it.) See? Naming is a really delicate subject!<br /> <br /> So, before we finally start making the goddamn map, let me explain the shader we've created:<br /> <br /> The first line creates the virtual file by giving it a path and filename. Again, take care of those file names, be they virtual or real. The brackets don't need explanation, I guess.<br /> <br /> The &quot;qer_editorimage&quot; line is irrelevant for the game, but it gives our shader a nice image in NetRadiant. If you apply this shader to a wall, instead of the ugly &quot;no pic!!1&quot; texture, you now see your nice .jpg image. Half transparent even! That is caused by the &quot;qer_trans&quot; line, which is also irrelevant for the game. It's there purely for the editor. And both these lines are not necessary for editing. Later, you can add &quot;//&quot; to the beginning of these two lines, which means that they are &quot;commented out&quot;. Anything behind &quot;//&quot; is arbitrary text until the line ends. I don't know, though, if a comment can be written on the right end of a shader command. If you comment these two lines out later, when you've actually used the shader in the map, and restart NetRadiant, you'll probably realize that they are not technically necessary, but man do you want them to be there.<br /> <br /> &quot;surfaceparm trans&quot; says that the surface is transparent. This does not mean that you can look through it - it only means that ''the computer'' can look through it! Yes, he has to know, too. A later command will make the shader transparent for us humans, too. As the name said: It's a glass shader.<br /> <br /> &quot;surfaceparm solid&quot; says that the surface is solid. You cannot walk/fall/shoot through it.<br /> <br /> &quot;cull disable&quot; means that the opposite side of a brush that is completely painted with this shader will not be invisible, as it would be with a normal texture. &quot;culling&quot; means to temporarily remove elements (objects, faces etc.) that are irrelevant for the current situation. To speed things up. But it is disabled here because it's glass, so you can see the presence/absence of backside faces, so they must be there.<br /> <br /> So far, this was the description of how the surface behaves. I'm not the shader pro, so the following explanations might be a little stumbly.<br /> <br /> The next {}block describes the actual graphics that will be drawn. The {}block after that tells the system to also create a lightmap and overlay it.<br /> <br /> &quot;map textures/scr5_dretchnest/brightglass_001.jpg&quot; obviously makes the shader use your new texture file. &quot;tcgen environment&quot; is short for &quot;TextureCoordinateGeneration&quot; with the parameter &quot;environment&quot;. Man, do I have to explain environment mapping now? In short, this makes the texture appear in a way that is not like a normal 3D shape but instead like it were a reflection in the 3D shape.<br /> <br /> &quot;blendfunc gl_one gl_one&quot; means: The pixels of the source (this shader) will be multiplied by one, then added to the destination pixels (which is whatever's already drawn on screen behind the glass) also multiplied by one. So, this just adds your lightened (Remember that this shader has a lightmap.) environmentmap-glasstexture onto the world graphics. Now you might realize why it's called &quot;brightglass&quot;. If you want something darker, look for &quot;textures/tremor/darkglass3&quot;.<br /> <br /> I don't really know about shaders. I look at how the other guys did it (There are already tons of existing shaders, look in the folder &quot;scripts&quot; in the map .pk3 files.), I read a bit in the shader manual, trial and error testing, etc. For example, I have no idea what &quot;rgbGen identity&quot; really does, but it belongs there. If you want to dive into that yourself, read [http://www.heppler.com/shader/ this comprehensive shader manual]. Also, lets drop the rest of the shader explanation and get into mapping, damned.<br /> <br /> ===start making the map===<br /> <br /> Assuming that you're still in NetRadiant with your named map (that doesn't have any stuff in it) open, set the 2D to view from the top, set the gridsize to &quot;9&quot; (256), and draw a square, 8x8 grid elements in size, so it will be 2048x2048 world units. It's not really important where you do this, but since NetRadiant positions the camera at position 0,0,0 every time you load a map (which can somehow be changed with an entity, but I currently don't remember how, saw it in a decompiled ATCS once), I'd suggest that you draw this brush exactly centered around the coordinate 0,0. After you've done so, press CTRL and TAB to set the 2D to view from the side (doesn't matter which). If the brush isn't exactly one grid block high, drag it smaller so that it is. Then move the whole platform so that its upper side (which is the floor to walk on) is at coordinate 0. Unnecessary to say: The whole thing, every face, should have the Caulk shader, the ugly pink one that you already know.<br /> <br /> Copy and paste the selected brush. Click into it and drag it upwards so that its lower side (which will be the ceiling of the map) is at coordinate 256. That's an 8 meters high map hall.<br /> <br /> Press ESC, then draw a square brush left of the two existing brushes, exactly between them. If you press CTRL and TAB, you see that the depth of this square brush is already as we want it because the last selected brush(es) had this depth. Assuming that you're still in the side view in which you drew the square brush, draw another one, on the right side this time. Did you fall for the &quot;something is currently selected&quot; trap, or did you think of pressing ESC yourself?<br /> <br /> Press CTRL and TAB two times to get back to the top view. Now select the two side walls you made. To do that in the 2D view, it's ok to just use the box select in the currently mostly empty map space that we have. So, press SHIFT and then left-click and drag the mouse to select the unselected wall(s). The ceiling and floor (both visible in one place as a big square) must not be selected now! Once you've done that, copy and paste them, then click on the rotate-90-degrees-Z button (a Z with a blue arrow around 90 degrees of the Z). Now you should have a big room with ceiling, floor, and 4 walls. The wall and floor brushes should be edge-on-edge, that will work properly, don't worry. The brushes must not overlap, though! Admittedly, the walls are a bit thick, but they are the outer map walls, so that doesn't matter. Actually, it's not so bad to have them this thick. Why shouldn't they stand out in the editor as a unique structure.<br /> <br /> If you have done it right (which is more probable with this large grid spacing than it would be with a smaller spacing), you should have a proper shell in which you can go crazy without having to worry about [[leaking]]. The [[void]] is properly locked out. The [[VIS]] calculation can hence be performed. You will not have the [[hall of mirrors]] effect.<br /> <br /> Well, yes, you will have the HOM effect, because everything is still Caulk, but we'll change that now. First, select a proper texture: Select &quot;arachnid2&quot;, then scroll down a bit until you see &quot;cement_1_clean&quot;. Now, select all the 6 surfaces that form the room (CTRL SHIFT left-click, and as a NetRadiant user, you'll have learned to press ESC a few times before this new select action, I guess). Then click on the texture.<br /> <br /> '''Save the map. If this is your first save in this &quot;start making the map&quot; chapter, you're still doing it wrong!''' Also, duplicate the saved map file.<br /> <br /> Actually, the floor and ceiling look just wrong this way. Go to the &quot;karith&quot; texture section, scroll down a bit until you see &quot;cement_3&quot;, select only the floor and ceiling face (Not the whole brush, but I guess I don't have to say that any more.) and apply the texture. Save the map. No new backup this time.<br /> <br /> Nice room. If you fly around in it with your camera, you might get the impression that it's too dark. In that case, open the NetRadiant preferences. Don't worry about a message saying that you'd better save before entering the preferences - in most cases, it doesn't matter. Except that saving is usually fast and in most cases not a problem. And if that dialog appeared just now, you didn't save the map when I said so, sinner! :&gt; Go to the preferences section &quot;display&quot;, subsection &quot;textures&quot;, and set the texture gamma to, let's say, 0.8<br /> <br /> ===about clipping, most underestimated by beginners===<br /> <br /> Assuming that the current situation is the result of your actions in the last chapter, you should still be looking from the top in the 2D view. Gridsize should still be largest (key &quot;9&quot;). Now, draw a new brush, 4 grid elements in size, around the 0,0 coordinate. So, the size should be 512x512. The brush should be inside the map shell room that you built, exactly from floor to ceiling.<br /> <br /> We'll use a little trick now. Set the grid spacing to 32 (key &quot;6&quot;). As I said, 32 is the smallest wall thickness you should use if you want to prevent light bleeding. You can be lucky with smaller values or still unlucky with larger ones, but 32 is a good base to work with. I've read somewhere that a thinner wall risks that objects or players might pass through it when playing on the Internet, but I think that's not true, at least I haven't seen problems like these ''ever'' in the Tremulous world, and there are maps with thinner walls around. Another thing about wall thickness: Even a wall with 64 world units might still let the damage effect of a fully charged [[Lucifer Cannon]] shot through a bit. I wonder how much or how little calculation time / network overhead impact it would have meant to prevent this, because this behavior sucks considerably.<br /> <br /> So, with the grid set to spacing 32 and the new 512x512 brush selected, search for the 5th button right of the 90-degree-Z-rotate button. When you hover over it, it says &quot;Hollow&quot;. Alternatively, go to the &quot;brush&quot; menu, submenu &quot;CSG&quot; and select &quot;Make Hollow&quot;. This function is not widely used, because it motivates box rooms (and other reasons, I guess), but right now it's the best thing in the world because it guarantees that you have a new room with 6 walls, all edges ''overlapping'', wall/ceiling/floor thickness 32. (Side note: Why the &quot;hollow&quot; tool doesn't come with the option to automatically clip the resulting brushes is beyond me.)<br /> <br /> Overlapping brushes should be prevented &quot;at all costs&quot;. We'll do that now, too, which brings us to &quot;clipping&quot;.<br /> <br /> Did I say &quot;save the map&quot;? No, and I won't say that any more.<br /> <br /> While still looking from the top, try to select one of the four walls in the 2D view. It's tricky, isn't it? Now you see why you'll select stuff in the 3D view most of the time. But let's try the 2D view again. Press ESC. Then, box-select the middle part of one of the walls (which will also select other stuff). Then, box-select the center of this new room. Shazam, everything except the wall is deselected. Box-select inverts the current selection where it is in effect. Also, nice that we activated &quot;display size info&quot; in the preferences (&quot;orthographic&quot;) before, because now we can clearly see that all elements of the current selection have the position and size of the wall we wanted - which makes it reasonable to assume that only the wall is selected. Once your maps are a bit more complex, that assumption is not so reasonable. I think that it would save the mappers of the world tons of time if there were a simple but prominent number stating how many elements are currently selected. Well, rudimentary tool, as I said. Instead, you can see how many milliseconds it took the 3D view to redraw.<br /> <br /> Now that one wall is selected, choose a different tool. Currently, the button with the square on it is activated (&quot;Resize (Q)&quot;). Activate the button right from it, the one with the diagonal line (&quot;Clipper (X)&quot;). This tool can be used to cut away parts of brushes or to split them into two brushes. Reminder: The preferences of the &quot;clipper&quot; should be set to &quot;Clipper tool uses caulk&quot;.<br /> <br /> You have to cut away a small diagonal part of the wall in the corner. What we want to achieve is that the four walls do not overlap in the corner but do instead end exactly where the next one begins. Yes, you could just use the resize tool for that, but that's not how a good mapper does it (except when it makes more sense than clipping). Imagine: When the walls are clipped in the way I described it, then not just the outer walls will be perfectly connected, but the inner walls, too. So, when you paint textures on them, you can use the &quot;fit&quot; tool of the &quot;surface inspector&quot; (key &quot;s&quot;) to make the texture fit the wall perfectly while you can mostly forget about all the numbers in that window. Or, if you're dealing with the numbers, you can copy them from other surfaces because the other walls have the same special properties (brush corners clipped).<br /> <br /> Well, if you had drawn the walls edge-on-edge like you did with the outer map walls, painting the inner walls would be exactly as easy as the clipped result will be. But we want to paint the outer walls, too! This will be a room visible from the outside, hence it must be properly built.<br /> <br /> So, let's just try to clip one of the corners of the selected wall now. Choose one end of the wall, then click once on the corner that is outside of the room, then on the one that's inside of the room. Two blue dots (&quot;1&quot; and &quot;2&quot;) should have appeared. The line that connects them should point from the outside room corner to the inside of the room. Also, there is another line (the &quot;perpendicular&quot; or &quot;normal&quot;) beginning at the middle of the clip line. Both lines are not existing objects but just editor tools.<br /> <br /> Press ENTER. So, the brush was divided by that clip line you made, and now one of the two parts of the brush is gone. It's the one that the additional line (the &quot;normal&quot;) went through, that's the rule. Which way the &quot;normal&quot; points depends on the order in which you created the clipper points. Also, you can invert the clipper direction (menu &quot;brush&quot;, submenu &quot;clipper&quot;). Also, the brush part that will stay will have the clip face painted blue in the 3D view (as long as you didn't complete the clip by pressing ENTER).<br /> <br /> Clipper tips: You can drag the clip points around on the 2D view. You can even add a third point. You can change the 2D view from top to side etc. and then still drag the points around. And you cannot remove the clip points by pressing ESC. To remove them, you have to select a different tool (like &quot;resize&quot;) and then switch back to the clipper tool. Or just click again once all 3 clipper points are placed, because that will place number 1 again, removing the other two. Only if you click directly on one of them, you can drag them.<br /> <br /> Very frustrating: While the &quot;undo&quot; can be used to return to the unclipped brush, it does not return you to the situation with existing clipper points, so you have to place them anew.<br /> <br /> Now that you kinda know how to work the clipper tools, clip all 8 wall ends diagonally, so that the walls are perfectly face on face, not overlapping any more. So that the inner walls start and end exactly in the inner room corners.<br /> <br /> Wow, finally done with the stupid clipping. Let's paint and resize a few more blocks, right? No. The clipper tool is one of the most important tools in mapping, and you'll use it much more often than you can imagine right now.<br /> <br /> For example: It's time to clip the ceiling and floor so that they diagonally meet the walls - which, thusly, also have to be clipped. In the end, all 6 walls/floor/ceiling of the little room will be kinda like the bottom ends of pyramids pointing into the room, perfectly face to face which each other. During all this, you should leave the grid spacing on 32.<br /> <br /> Done yet? An experienced mapper needs 1 or 2 minutes to finish this properly.<br /> <br /> You might be wondering why we didn't just delete the ceiling and floor of the little room (after all, there's still the outer map ceiling and floor). Reason one: Using a map shell room like we did is a crutch. Not necessarily a bad one, but also not necessarily the way an experienced mapper does it. Reason two: You'd make yourself dependent on the outer ceiling and floor, and once you get out of the room and map some more, you'll have more dependency-situation-possibilities like this. You don't want to tie it all together and stand in your own way. I had that when making skybox. &quot;Can I texture this wall? No, damned, it's the outer wall again.&quot; Reason three: Lightmaps! I don't know how exactly it is decided how many pixels a lightmap has, but I am pretty sure that a huge brush will have a less high resolution (so, rather stretched) light map. Oh, speaking of which:<br /> <br /> ===_lightmapscale, gridsize, turbo rendering===<br /> <br /> (You can skip this now and go to &quot;enjoy the fruits of the clipping labour&quot;. One day, you should read this, though.)<br /> <br /> I already explained the worldspawn. Press ESC and select any one of the brushes. Since we currently only have simple worldspawn brushes (as opposed to, for example, doors), you could also just box-select a bunch of them. Anyway: Press &quot;n&quot; if the entity inspector was not yet visible. As you know, the second section shows a help text for the currently selected entity type, and since the third section shows &quot;classname worldspawn&quot;, the help text describes the worldspawn. Scroll far down (not to the end) until you see the explanation of &quot;_lightmapscale&quot;. Read it. Then, write &quot;_lightmapscale&quot; and &quot;0.25&quot; into the &quot;key&quot; and &quot;value&quot; textboxes and press RETURN while you're in the value textbox. I thoroughly tested it in a relatively small room: Values smaller than 0.25 don't increase the lightmap resolution any more.<br /> <br /> Setting the lightmapscale to 0.25 will result in a higher lightmap resolution, so you'd have better shadows etc., think of the difference between the thumbnail of a picture and the full size version (only the difference is not that drastic here). The default setting is &quot;1.0&quot; (when the _lightmapscale key is not present). 0.25 also means that the LIGHT phase, in which the lightmaps are calculated, will take much longer. This also means that larger settings than 1 will make it shorter.<br /> <br /> If you've followed this mapping crash course so far, you'll either have prepared q3map2 frontend &quot;q3map2build&quot; or a build batch file, and you will have done so that the light rendering result is very good:<br /> <br /> &quot;fast&quot; is not activated. &quot;bouncescale&quot; is on 2, &quot;bounce&quot; is on 500 (meaning: effectively &quot;6&quot; or something). And to top it off, your map now has the best lightmap scale. The option &quot;filter&quot; is not relevant for the calculation time. It will smooth the resulting lightmap a little so that shadow seams don't look so pixeled. I am not repeating all this from other guides, these are actual experiences that I gathered in many tests over months.<br /> <br /> Now, as long as your map is very small, these settings are ok. Calculation will be done in a few minutes or less than a minute. But once your map is a huge monstrosity, calculation with these settings takes several days on a fast computer. That's still ok as long as you have an extra machine for things like these, but '''here's how you can speed up the rendering like crazy''' (resulting in less good result, of course):<br /> <br /> Add the key &quot;gridsize&quot;, value &quot;1024 1024 1024&quot; to your worldspawn (default would be 64x64x128 as far as I know, and to achieve default, just delete the key again). As far as I know, the gridsize defines the ''volumetric'' lightmap calculation. If you get closer to a bright red spot in the map, your weapon will receive red light. If the gridsize is as coarse as we have set it here, those effects will be less prominent. I could be totally wrong about this. Maybe the gridsize is more about how the raytracing really takes place. In any case: Changing the gridsize has ''huge'' (!) impact on the calculation time. Setting it to this value will make it faster. Deleting the key, so that you're back on the (very good) default value makes it slower. Setting the gridsize to something like 48x48x48 increases the calculation time insanely, and as far as my test results go, it doesn't have any merit. So: For high quality results, you'd use the default setting. For quick and less proper results, you use the 1024 (or an even rougher) one.<br /> <br /> You can also drop the &quot;bouncegrid&quot; option. Bouncegrid means that before every radiosity bounce, the lightgrid (see &quot;gridsize&quot;) is calculated anew, because somethingsomething bounce influence grid somethingbla. Honestly, I didn't test the difference it really makes, but I believe that it's safe to assume that this option increases the light rendering quality even further.<br /> <br /> Change the rendering settings (in &quot;q3map2build&quot; or your batch file) so that the LIGHT phase uses the key &quot;-fast&quot;. This does not change the lighting ''very'' much (but still too much for my taste when I want to make a real proper release), but it insanely reduces calculation time.<br /> <br /> Removing the &quot;bounce&quot; option (&quot;bouncescale&quot; is irrelevant for the time (except in regards of the caused number of iterations) and is bound to &quot;bounce&quot;, so you don't have to touch it here) has strong influence on the lighting. You should try to have a few bounces in your released maps, the light looks considerably more natural. Removing the &quot;bounce&quot; option decreases calculation time, though. Very much even. If the initial pass (not yet bounced) takes 10 seconds, every bounce will also take about 10. If the first took 1 day, guess what. Depending on the bouncescale you used, the amount of bounces will have strong influence on the lighting result. This is something for tweaker guys. Just as the &quot;gamma&quot; option (that I didn't mention yet) in the LIGHT phase is. You should know that these options exist and that it's a good idea to toy with them. Now let's move on.<br /> <br /> Another option that you can add to speed up calculation: &quot;-fast&quot; in the VIS phase. Please don't do this, though, if you want to release the results into the public. And definitely don't release the result if you omit the VIS phase completely - which you can also do to decrease rendering time even more. The VIS phase calculates which spot of the map can be seen from which other spot. This information allows the game engine to draw only the necessary graphics. As far as I know, it also influences the radar functions of helmet and aliens. It's essential for a release, and you should do it without &quot;-fast&quot; for a release.<br /> <br /> '''In short:'''<br /> <br /> '''For fast rendering''', add &quot;-fast&quot; to the VIS phase (or drop it completely), add &quot;-fast&quot; to the LIGHT phase, remove &quot;bounce&quot; from the light phase (or just &quot;bouncegrid&quot;, but I think if you're already doing bounces, you might as well do them properly), remove the &quot;_lightmapscale 0.25&quot; thing from the worldspawn, add &quot;gridsize 1024 1024 1024&quot; to the worldspawn.<br /> <br /> '''For best (slow) rendering''', have a not-fast VIS phase, not-fast LIGHT phase, bouncegrid, bounce 500. Remove &quot;gridsize&quot; from the worldspawn. Add &quot;_lightmapscale 0.25&quot; to the world spawn.<br /> <br /> If you want to see a map that rendered for 112 hours with lightmapscale 0.25 and 11 radiosity bounces (Then it was tuesday morning and I needed the computer :/ Yes, you can abort the calculation at any time. Previous bounces will still be existent, and the current half-done one will also not be visible.) and want to see what the higher lightmap resolution might do to a 128MB graphics card, take a look at [[Gmotw_Skybox]]. I'm not really proud of the rendering result. There should be more shadow cast situations and so forth, but it's the best I have to offer in that regard yet. I think the lightmap can best be enjoyed in and above the pump station.<br /> <br /> ===enjoy the fruits of the clipping labour===<br /> <br /> Inspect the result of your work. It's very useful that you can move the camera to the inside of a wall, making it temporarily vanish from the 3D view.<br /> <br /> While you were working on the clipping, I picked a nice texture to demonstrate the described advantages of clipped walls. The texture browser should still be in the &quot;karith&quot; section, showing the &quot;cement_3&quot; texture (near the top). Scroll a bit further up until you see a broad texture called &quot;base_grooved&quot;. (Well, you might have a hard time finding it if there's another texture with a long name to the left of it, because then, the name on screen is partly overwritten. As I said: Rudimentary tool.) It should be the 8th texture. Press ESC and then click on the texture. At the bottom of the screen, there should be a text saying &quot;textures/karith/base_groove...&quot;. The texture looks like someone used a comb on a gray piece of butter from the left to the right.<br /> <br /> Now, select one of the faces inside the little room, then click on the texture. If you have done everything like I described, you'll see the texture on the wall, but there's something like a split in its middle. What you see are the outer ends of the texture. Textures are always looped on the brushes, so now lets place this texture properly. Press &quot;s&quot; (if the surface inspector was not already visible), then click &quot;Fit&quot; (if there is a 1 in both text boxes beside the fit button, otherwise set the boxes to 1 (or 1.000000, it's the same)). That was easy, wasn't it? Imagine what would have happened without the clipping. The texture would be partly hidden. If you look at the surface inspector and the numbers in it, can you imagine the hassle of adjusting everything until it looks like it does now?<br /> <br /> If you look at the horizontal and vertical stretch, you see something between 0.5 and 1 (and they are different - thank the programmers for the &quot;fit&quot; button). That's kinda ok-ish, but smaller values mean higher texture resolution. Only we can't put the texture in twice because that doesn't look good, either. The &quot;width&quot; and &quot;height&quot; value next to the &quot;fit&quot; button, by the way, define how often the texture is to fit the surface when you click &quot;fit&quot;. Yes, &quot;0.5&quot; etc. works, too.<br /> <br /> Paint all four walls in the described manner. You can do them all at once.<br /> <br /> After that, paint floor and ceiling with the next texture in the list, &quot;base_small&quot;, and fit it in 1 by 1. Again, this wouldn't have worked so easily without clipping. The horizontal and vertical stretch are close to 2, which is much too high. You can already see how blurry and cheap it looks. But keep it for now.<br /> <br /> ===let's add a door===<br /> <br /> Look from the top in the 2D view. Set the grid spacing to 128 (key &quot;8&quot;). Select one of the 4 walls. Just for training, let's use the toggle-selection, so press and hold SHIFT and ALT, then click on one of the 4 walls a few times until it is selected. You don't have to press ESC before this.<br /> <br /> With the wall selected and the clipper tool active, click on the wall. Gridwise, it has 4 sections. Click so that 3/4 of the wall would be cut off. Umm, where to put the second clip point? The grid doesn't allow to put it on the wall! Well, doesn't matter. Just put it a bit further away. Only the direction and position of the line itself must be correct, not its length. If you have made a nice (and non-diagonal) clipping line, press SHIFT and ENTER or select &quot;split selection&quot; from the &quot;brush&quot; menu, submenu &quot;clipper&quot;. You have cut the wall into two segments. Do that again on the other side, so that the middle segment is two grid elements in size. By the way, you can join brushes if the result would &quot;make sense&quot; (convex brush) using menu &quot;brush&quot;, submenu &quot;CSG&quot;, item &quot;CSG merge&quot;. If you try to merge brushes that can't be merged, you'll see an error message in the log area.<br /> <br /> Ok, now deselect everything (ESC). Then '''select the middle part of the split wall. Then, right-click in the 2D view, go to &quot;func&quot; and select &quot;func_door&quot;. You just made an automatic door''' that opens to the side if you get close, complete with sound. Nice, huh? Let's change the angle to &quot;top&quot; by adding the key &quot;angle&quot;, value &quot;-1&quot; in the entity inspector.<br /> <br /> You could actually make a door that uses a sensor that only reacts to someone carrying a lucifer cannon. Or to dretches and dragoons. Then, a sound would play and dark light would go bright (without lighting the environment, though (then again, I think it can be done using a shader with specular lighting)). Bars in front of the door would move to the sides (with sound). Then, the door would ''rotate'' open kinda like a garage door. Later, everything would move back. This can really be done using triggers, delays and so forth. But dude, I'm not gonna guide you through that.<br /> <br /> You can adjust the door in the &quot;entity inspector&quot; (&quot;n&quot;). You can change the sound, the direction into which it opens, how much of it is still visible once it's open, whether its default is open or closed, how much damage it does to you if you stand in its way, how fast it moves and more. The &quot;lip&quot; value is especially useful. You know, a door is just a brush (or a bunch of brushes - yes, '''you can make complex designs and have them move as one unit''') that moves. It has convenient defaults and a sensor. But you don't need to use the sensor. Also, '''you can use huge negative values for the &quot;lip&quot;, making the door move much further than necessary when it opens. And what is that then? A lift! :)''' There is also an extra lift function, but its default sounds are broken, and also it cannot be set to &quot;crusher&quot;, as far as I know. The big lift in skybox is a door, consisting of several brushes. '''Doors are really versatile.''' You know what? I once used doors to make a programmable soundtracker in Tremulous (&quot;gmotw_pianolessons&quot;, named like this because there's also a big piano with black and white keys that you can step on, and guess what, they are all doors). 16 doors would hammer down in a sequence, and their &quot;I'm closed now!&quot; sound wouldn't play if they don't arrive at the closed state, so I just made buildings in their way to program the sound steps. Did I say that doors are versatile yet? A server where you can save the current building layout can then even save the rhythm for later! Problem is, once too many elements are used, the rhythm stumbles a bit. Maybe a faster computer or newer Trem client doesn't have that problem. I used 16 steps and 3 instruments (bassdrum, snare, closed highhat), and it already got a bit stumbly. Another thing you can do with a door is use it as a busy-light that appears from out of nowhere (was hidden in a wall) and vanishes once the busy cycle (lift or whatever) is over. Also, I once made a door that actually consisted of 8 by 8 doors that you had to shoot. It was a pixel-door. If you didn't shoot the pixels away fast enough, they would return and you wouldn't get through. A tyrant (or whatever) filter. A dream if you carry a lucifer gun. That was in skybox, but I had to remove it in later releases because with all the other map elements, it reduced the FPS too much. But the door maze is still in the map. Looks like solid walls, but it is a small 2D maze. No, even 3D.<br /> <br /> Now, press &quot;h&quot; to hide the door and move the camera so that you look at the room from the outside. We'll now paint the frame of the door. Use the texture &quot;base_verts&quot; which comes shortly after the &quot;base_small&quot; that we used for floor and ceiling. Select the two faces at the side of the opening. Click the texture. Click &quot;fit&quot;. If you look at the stretch values, you see that one is 0.5 and the other 0.25, which can look odd, so better enter a &quot;2&quot; instead of the &quot;1&quot; in height (next to the &quot;fit&quot; button) and click &quot;fit&quot; again. The texture is now used 2 times in height, so it is not as streched in that direction. Press ESC. Then select the upper and lower face of the opening. Click the texture. Looks wrong. Now what? Well, it needs to be rotated. If you look at the &quot;rotate&quot; text box, there is a &quot;0&quot; in it. The text boxes on the right side can be changed at any time without influencing the map in any way - they are only an editor tool. The box right to &quot;rotate&quot; should have a &quot;90&quot; right now. If so, click the up or down arrow (doesn't really matter now) of the rotate value, changing it to 90 or -90 degrees. The texture looks better now. Click &quot;fit&quot;. Damn, bad stretching. Change the height preference to &quot;4&quot; and click &quot;fit&quot; again. See? The &quot;height&quot; now means &quot;width&quot; because the texture is rotated.<br /> <br /> If you look now from the inside of the room, you'll see that the wall (not frame) texture is cleanly cut, as it should be. If you would want to apply and fit the texture now, you'd have problems. '''To use &quot;fit&quot; on a surface with the &quot;wrong&quot; size, temporarily resize the wall to an appropriate width, click &quot;fit&quot;, return the size to normal again.'''<br /> <br /> Paint the 3 outer walls with the texture we used on the inside walls (for that, select an inside wall surface and use CTRL and C, which will not just copy the texture settings, rotation and so forth, but will also select that texture in the browser, so you can just click it then instead of using paste). Don't forget to fit (1x1). Paint the two short front walls with the texture &quot;base_v_rigged&quot;. Fit them in (1x1). By now, you'll have realized that the textures are sorted by alphabet. <br /> <br /> Press SHIFT h to get the door back. Press ESC. Select the door. Press i or choose &quot;invert selection&quot; from the edit menu. Press h. Now, only the door is visible, and it obviously needs some texturing. Put &quot;base_small&quot; on the outside and inside (fit 1x1).<br /> <br /> The four outer sides of the door are still unpainted. Let's select them all at once and then apply &quot;base_verts&quot;. Fit them 1x1. There's a problem: Even though the stretch values on the side surfaces are different from the top/bottom surfaces, you only see one number pair. Keep that in mind, also when dealing with the entity inspector while several elements are selected. A common reason would be to copy the values of one door to another. Select the correct door first, the one you want to fill with values as second, and for every value that you want to copy, click it and then press ENTER in the &quot;value&quot; text box to re-apply the key-value-pair to the correct door, which will also copy it to the other(s).<br /> <br /> So, let's do this again properly (and maybe you have already realized that this is all wrong, then follow me without acting, also smile). Press ESC. Select both side surfaces. Click &quot;fit&quot; with 1x2, so both stretch values should become &quot;0.25&quot;. Select the top and bottom, rotate the texture by 90 degrees, fit 1x2. Why not 1x4 like the same surfaces of the room walls? Because the surfaces of the room walls didn't begin/end at the door opening! So, we have a few meters of unnecessarily painted faces there. I don't know if a real pro mapper would now fix that by causing a few more brushes or if they would just ignore the few meters of unnecessary texture. We'll just leave it at this now. Don't tell anyone.<br /> <br /> The door is now painted on the front, back, and on the other 4 sides. Unnecessarily. The reason is that we didn't think enough like a mapper should, instead we were stuck too much in real-world thinking. Since you will never get to see the left, right and top side of the door, we should apply the Caulk shader to them.<br /> <br /> The texture browser has a little drop down menu, too. Go into that &quot;view&quot; menu and click &quot;hide unused&quot;. This hides all textures from the texture browser that are currently not used by the map. Even better: Also select &quot;show all&quot; from the same menu. Now, every texture that you had loaded in this program session (except the unused ones because you just hid those) is in the texture panel. You should memorize this trick, it will make your mapping much easier. For example: The caulk shader is here! Apply it to the left, right, and upper surface of the door. Then press SHIFT h to unhide everything.<br /> <br /> Press ESC. Select the door. Go to the entity inspector. Add the key &quot;lip&quot;, value &quot;80&quot; to the door, because otherwise it would look kinda weird while open. A bit of its lower end would stick out of the ceiling without any apparent cavity or mechanism for the door. With &quot;80&quot;, it sticks out so far that no one will ask questions.<br /> <br /> This, by the way, makes another surface's texture unnecessary. Since I don't plan on toying around with the door some more, let's set that surface to caulk, too. So: Hide the door. Then look from the outside. The upper diagonal surface will be invisible because the door will never reveal that surface.<br /> <br /> ===let's populate the map===<br /> <br /> Add an &quot;info_player_intermission&quot; entity. (I won't tell you how because I already did. If you didn't read the whole truckload of text, use the in-page-search function of your browser.) Move and rotate the entity so that it looks at the door of the little room from the outside, from a bit further away, slightly diagonal so that you can see the side wall of the room, too, and much of the rest of the map.<br /> <br /> Press the &quot;1&quot; key for the highest grid resolution that you can achieve with the keyboard. In the room (top view in 2D), create a &quot;team_human_reactor&quot; entity. Move it around a little. Then press &quot;8&quot; for grid spacing &quot;128&quot;. Move the reactor again. You see that the amount by which it moves is 128, as the grid forces it to. But its position is kinda off (if we're not unlucky). To force the reactor back into a nice x y and z grid position, press CTRL and &quot;g&quot; or use &quot;snap selection to grid&quot; in the &quot;brush&quot; menu. Now, with the 128 grid, move the reactor as far into the corner as possible. I don't care which one, as long as it's not on the door side. Switch the 2D to side view, set the grid to &quot;7&quot; (64), drag the reactor to a reasonable height position. It must not be in or above the ceiling and not in or below the floor.<br /> <br /> Rotate it around the Z axis by 90 degrees until the nice control panel can be seen. You might even want to rotate it arbitrarily by 45 degrees and then in 90 degree steps until it nicely faces the room.<br /> <br /> Also build an armory, a medistation, two nodes and a few turrets. Give them enough space. Especially the armory is tricky. Too few people know that '''the game system only allows square [[Hitbox|hitboxes]]'''. The height can vary, but the shape when seen from top is square. Even the armory? '''Yes, even the armory.''' If you keep that in mind, it will explain every occasion on which the armory or a nearby building didn't appear in the game.<br /> <br /> You should already rotate the turrets so that they face the door. This is not a [[Building|base building guide]], so I'll stop here.<br /> <br /> Don't forget to make a few alien buildings (overmind, SPAWN!, ...) somewhere in the outside hall.<br /> <br /> Then add &quot;player_human_intermission&quot; and &quot;player_alien_intermission&quot; (one of each) and make them look at the human and alien base.<br /> <br /> You can have a look at the map if you want, even though we haven't placed any lights yet. Just omit the LIGHT phase. Everything will be at full brightness. The batch file:<br /> <br /> &quot;C:\Program Files\netradiant-20100214-win32\q3map2.exe&quot; -fs_basepath &quot;C:\Program Files\Tremulous&quot; -fs_game &quot;base&quot; -custinfoparms -info -meta -patchmeta &quot;C:\Program Files\Tremulous\base\maps\scr5_dretchnest.map&quot;<br /> &quot;C:\Program Files\netradiant-20100214-win32\q3map2.exe&quot; -fs_basepath &quot;C:\Program Files\Tremulous&quot; -fs_game &quot;base&quot; -vis -saveprt &quot;C:\Program Files\Tremulous\base\maps\scr5_dretchnest.map&quot;<br /> &quot;C:\Program Files\Tremulous\tremulous.exe&quot; +set fs_basepath &quot;C:\Program Files\Tremulous&quot; +set fs_game base +devmap &quot;scr5_dretchnest&quot;<br /> <br /> ===lighting===<br /> <br /> On second thought, you should definitely look at the map right now. With full brightness, it sucks. Once we've added nice lighting, it will look so much more pleasant. Lighting makes and breaks the mood.<br /> <br /> Just as decorations (which we haven't dealt with yet) are not a burden but a passion to a real mapper, lighting is not something to be dealt with by just throwing strong point lights with no apparent light source (fixture) all over the place. And definitely '''''do not'' use the &quot;_minlight&quot; or &quot;_ambient&quot; features in the worldspawn.''' You might use them sometimes - really rarely - to test something, but a map with proper lighting will, I dare to claim, never have one of these features in use.<br /> <br /> '''There are two possible light sources:''' Point lights (which can be made with the right-click menu) and light textures (or light shaders, same thing, different term). We have already dealt with shaders. It's possible to make shaders with a parameter that makes it emit light. The larger the surface that uses the light shader, the more light is emitted. The advantage of using light shaders is that you always have a &quot;something&quot; that the light is actually coming from. This contributes considerably to the mood, because it is more believable. You can, of course, just build a &quot;something&quot; that might be a light, then add a point light source to it. That works, too. Actually, the main reason people rarely do that probably is that you can't group brushes and point lights together. You see, the &quot;worldspawn&quot; entity is not the only &quot;dead&quot; entity that can hold brushes. '''You can also select a bunch of brushes and then select &quot;func_group&quot; from the right-click menu.''' This creates a new entity of type (or &quot;classname&quot;) &quot;func_group&quot;. You cannot add other entities (like light or a doorbrush) to such a group which is sad, because if you could, people would probably also try to construct light fixtures and then just put a point light into them instead of fiddling with shaders. And what is the advantage of such a group? Well, if you select one of its brushes, you can then use &quot;expand selection -&gt; to whole entities&quot; from the edit menu. You can then conveniently move them around or copy/paste of them - which creates a new func_group with the copied brushes in them. The expand selection function also works for several such things in parallel. Sadly, I haven't yet found out how to add another brush to such a group. &quot;regroup&quot; in the &quot;entity&quot; menu does the opposite of what you'd expect, and I haven't tried the next function, &quot;ungroup&quot; because I suspect that it does what you'd expect.<br /> <br /> ===decorations, structural/detail brushes===<br /> <br /> <br /> <br /> ===create a release file===<br /> <br /> <br /> <br /> [[Category:Mapping]]</div> Tue, 13 Jul 2010 13:43:22 GMT God, maker of the world http://tremulous.net/wiki/Talk:Mapping Mapping http://tremulous.net/wiki/Mapping <p>God, maker of the world:&#32;/* NetRadiant */</p> <hr /> <div>A [[mapper]] is a person who creates a game [[map]]. He is &quot;mapping&quot;. This article describes how that works in the Tremulous context. For a list of a few existing Tremulous maps, click [[:category:Maps|here]].<br /> <br /> <br /> =mapping crash course=<br /> <br /> I started this article on 2010-06-29, just so you know why it doesn't refer to Tremulous 1.2 etc. I am a Windows user (2000 and XP), so that's the perspective that I use. If you can't translate that into your perspective, then you probably shouldn't use the system you're using.<br /> <br /> There are already several mapping guides out there ([http://tremulous.net/forum/index.php?topic=7497.0 list]), one of the best of which is at [http://tremmapping.pbworks.com/ tremmapping.pbworks.com]. It is easy and very comprehensive. I'll try to write a new one from scratch here based on my experiences - and much more up to date. It will save you some steps that were necessary 3 years ago when the linked guide was made. This article here will not enable you to make good maps, but it will give you a truckload of know-how of the kind you don't find in other mapping guides.<br /> <br /> If you've ever written something like a guide, you know that you'll inevitably get into ramble mode from time to time. I guess you can forgive me that.<br /> <br /> <br /> ==setting up your computer==<br /> <br /> ===Tremulous client===<br /> <br /> Download and install the original Tremulous 1.1.0 client. It can be found [http://tremulous.net/files/ here], but it's all over the Web, just search. Now, you ''could'' use a different Tremulous client, but I suggest that you don't. Reason: The original client is what many people out there still use, and when you test your map, you'd want to see what it looks and behaves like (and if it works at all) in the client all those [[newbie|noobs]] use who wouldn't know how to fix a problem if your map causes it. You want your map to work and to shine in the original client. You don't want it to look great only in the latest client with magical rendering v9.9.999 and bloom effect.<br /> <br /> Maybe also download the [http://tremulous.tjw.org/backport TJW backport] client. It's a slightly updated version of the original client. Not too new to violate what I said in the previous paragraph. This is not a full Tremulous release. It's just the program itself. Put it into the program folder of the above mentioned original client. This client supports [[GUID]] and much faster auto-[[Cl_allowDownload|download]].<br /> <br /> You might already have all this. But consider starting anew in a VirtualMachine or on a new computer. If you're more proficient, you'll be able to maybe clean up all your Tremulous base folders so that you don't have magical conditions that a person using the naked client wouldn't have. If you're not proficient enough in this and don't want to make a clean install, prepare to experience problems like &quot;But the texture wasn't missing on my machine!&quot;.<br /> <br /> ===NetRadiant===<br /> <br /> Now the most important part: Download and install [http://ingar.satgnu.net/gtkradiant/installation.html Ingar's NetRadiant and the Tremulous support files]. That's two downloads. The instructions on the linked page are short and comprehensive, it's easy to do. [[NetRadiant]] is the tool that you actually make the maps with. You probably also heard about &quot;GtkRadiant&quot;. Forget it. It's 99% the same as NetRadiant, but it's no longer developed. Also, installation is more complicated because it is not prepared for Tremulous. Additionally, Ingar's NetRadiant already includes the [[Q3Map2]] program that compiles your .map document to a playable .bsp map file.<br /> <br /> Change the NetRadiant preferences (and learn a few things about them): Start it. You'll probably see a little window offering a game type selection. Choose &quot;Tremulous&quot;. There's also a checkbox to prevent this window from appearing every time you start NetRadiant. Technically, that was all. But please, continue adjusting the preferences: Go into the preferences window, which can be found in the &quot;edit&quot; menu at the bottom. I'll go from top to bottom, not from most to least important.<br /> <br /> '''Textures:''' Later, you might want to change &quot;gamma&quot; to something like &quot;0.8&quot; to make the 3D display of the editor brighter. '''Undo:''' Increase queue size to 128. You'll use undo very often, sometimes to undo shifting textures around, and that's an undo step for every texture shift step even if it was a button autorepeat result.<br /> <br /> '''Brush:''' Definitely activate &quot;Always use caulk for new brushes&quot;. You can also activate &quot;Use alternative texture-projection&quot;, but most people do not do that, so if you want to open their maps, you'd have to turn it back off and restart the program. And there is no way to convert a .map from one setting to the other. If you decompile a playable map you found somewhere (like ATCS etc.), you would need to use the alternative projection to load the result in NetRadiant, so why not completely live in that world? I, however, have not done so. Because I didn't know better when I started mapping. I also don't know if I would ever regret turning this option on to make my own maps, so be careful. Maybe better leave it off.<br /> <br /> '''Grid:''' Set default grid spacing to &quot;32&quot;. That's the smallest room-wall-thickness that you want to use to prevent [[light bleeding]] (though the best measure to prevent light bleeding still is clipping). Once you're an experienced mapper, you might want to set this to &quot;256&quot;, the largest setting. '''Camera:''' Movement Speed 100 is good, but you'll come back later and change this, depending on your mapping situation. (I think NetRadiant should have a control element on the edit window to adjust the camera more quickly.) Smaller value for working on details, larger value if you have to travel a lot with yo