Mapping Tips and Useful Links
Quick and slightly useful tip, go into steam, open the properties for portal 2, click on set launch options and type -novid in. This stops the annoying startup videos when the game launches.
I think in terms of boolean variables. Generally, it makes things easier.
The video's are just instead of a loading screen?
Pressing [Space], [Enter] or [Esc] also works 
haha exactly, saves you a button press 
I think in terms of boolean variables. Generally, it makes things easier.
One little tip, one of those little things that hammer has got that makes you not hating it too much:
When you want to create a brush for "envolving" an area or a func_detail or something (for example making a skip/hint or player_clip textured brush around a func_detail), if you previously select that are or func_detail and then select the brush tool in the top 2D view and make the brush on the top 2D view with the size of that func_brush (seen from above), hammer makes by default the same height size than the func_detail selected. It's only a tiny tip but I found it very useful, it saves time resizing the brush, overall for big ares or func_brushes.
useful tools and stuff here on TWP 
[spoiler]
[/spoiler]Useful tip:
You can launch the authoring tools WITHOUT running steam. Just run SDKLauncher.exe, located in Steamsteamappscommonportal 2bin
This means that if you want to do some mapping but dont have access to internet, or just dont want to have steam running in the background, you can.
And if youre really keen, you can go into the folder sdklauncher (also in bin) and mess with medialist.txt to add other programs into the launcher. For instance, mine now gives me the option to launch VTFEdit and GCFScape, etc etc. Its not hard to mess wih it, i know next to nothing about programming and i managed to modify it. Just make sure you save a copy before you start changing things.
I think in terms of boolean variables. Generally, it makes things easier.
trying to upload hack client addon [link removed - Nacimota] msg me if it doesnt work
The following is a from a thread about grate shadows and projected textures. It has been suggested to me that I repost it here, and so I shall. The purpose of the post was/is to clear up some common misconceptions about the Source engine's lighting system (specifically, the differences between static and dynamic lighting).
Original Thread: mapping-help/shadows-of-a-grate-t6808.html
----------
... it is in the general interest fighting the spread of ignorance and misinformation that the following facts shall now be revealed.
First and foremost, lightmap scale has literally nothing to do with projected textures. In Source we essentially have two forms of lighting, static and dynamic (this is also true of many other game engines although the emphasis is on dynamic these days).
Static lighting is calculated by vrad during the map compile and does not change at runtime whereas dynamic lighting is calculated entirely at runtime. Since static lighting doesn't have to be calculated while the game is running, it is significantly cheaper (in terms of CPU time) but isn't able to change the way dynamic lights can (so for instance, you can't illustrate a moving light source with static lights).
vrad's job (in its entirety) is to calculate the static lighting for a map. It does this by generating a special texture called a lightmap for any brush surface painted with a texture that uses the lightmappedgeneric shader*. The lightmap is then additively mixed with the surface texture at runtime.
Let's say you have a room with a few brushes strewn about the place and a static light in the middle:
vrad will calculate the static shadows and draw them to a lightmap**, like so:
The lightmaps are loaded into video memory when the map starts and additively mixed with the surface textures on-the-fly:
Although lightmaps are extremely cheap (computationally speaking) they can very quickly use a large amount of memory both on the disk (as lightmaps are stored in the .bsp file) and in video memory at runtime. Lightmap scaling is introduced to mitigate this problem. The default lightmap scale for a surface in Hammer is 16. What this means is that when vrad generates the lightmap for the surface, said lightmap will be 16 times smaller than (or one 16th of) the original surface size. At runtime, the texture is then scaled back up on-the-fly. This solves the memory issue but causes another: scaled down lightmaps cannot preserve crisp shadows because the loss in image size accompanies a loss in detail. An experienced mapper will balance lightmap scale per surface, creating high resolution lightmaps when detailed, crisp shadows are required; and lower resolution lightmaps to save memory when such detail is not needed.
Projected textures are a form of dynamic lighting. They are not calculated by vrad and they are not saved to the lightmap. Therefore, you can change the lightmap scale on a surface as much as you want; it simply cannot and will not affect the appearance of a projected texture because they have nothing to do with lightmaps.
The -textureshadows switch on vrad will also have no effect on projected textures because, once again, projected textures are unrelated to vrad. Additionally, -textureshadows deals with translucent textures on props and has nothing to do with brush surfaces.
Creating a grid of brushes using tools/toolsblocklight is an old but reliable method of creating static shadows but it also has nothing to do with projected textures or other dynamic lights. Vrad will not cast light through any face textured with tools/toolsblocklight (and will also not bounce light off it during radiosity passes) but these faces are removed when vrad finishes and are not present at runtime (when dynamic light is calculated).
Other suggestions included changing the Disable shadows and Shadows keyvalues on the func_brush which are also static lighting related and have nothing to do with projected textures either.
Basically, the entire compile process is unrelated to projected textures (in fact, projected textures will work in a map with no lights, with mat_fullbright set to either 0 or 1). In that respect, I find it impossible to believe that switching to an expert compile is what actually solved the problem; there's just no reason why this would be the case (especially if you're using the default expert compile, which is exactly the same as a normal compile). This is further proved by the fact that the OP managed to get the projected texture to work in another map without executing an expert compile, which proves that the problem lay elsewhere.
* This is a bit of an oversimplification; vrad also generates lighting data for static props (which generally use the vertexlitgeneric shader) as well as ambient lighting for light_env, but this is outside the scope of this post
** In this example I'm only illustrating direct lighting. Provided there are no leaks in the map, vrad will also calculate global illumination to make the scene much more realistic.
Hello people, I decided to make short, slideshow video from all toxic slime textures, I see this very useful for me and others for choosing goo texture for your map and thought I could share it with you.
This video doesn't include all Underground textures, because some of them looks same.
Reposted here from its own thread.
This video doesn't include all Underground textures, because some of them looks same.
Reposted here from its own thread.
Thanks! That was useful! 