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.

Spam Nugget wrote:
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.

The video's are just instead of a loading screen?
Pressing [Space], [Enter] or [Esc] also works

haha exactly, saves you a button press

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 tip:
You can launch the authoring tools WITHOUT running steam. Just run SDKLauncher.exe, located in \Steam\steamapps\common\portal 2\bin
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.

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.

Seml6aXZ8iU

This video doesn't include all Underground textures, because some of them looks same.

Reposted here from its own thread.

Pitkakorvaa wrote:
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.

Seml6aXZ8iU

This video doesn't include all Underground textures, because some of them looks same.

Reposted here from its own thread.

Thanks! That was useful!

There is an useful tip I'm using recently a lot. Many of you will already know, but some others won't.

You can fire one single output to a bunch of entities named so they share words in their respective names by the use of the asterisk * (the same wildcard use than in Ms-Dos).

For example, if you've got several arms models and the panels parented to them (apart from the corresponding func_clip_physics brushes or placement_helpers), it's possible to name them so they all receive 1 single input. Given the following entities:

**Arm entities' names:**

• chamber1_90_deg_arm01
• chamber1_90_deg_arm02
• chamber1_90_deg_arm03

Parented brushes on top names:

• top_brush_panel01
• top_brush_panel02
• top_brush_panel03

Well, to parent them properly, only one single output fired from the logic_auto is enough:

- OnMapSpawn > top_brush_panel > SetParentAttachmentMaintainOffset > panel_attach / delay 0.25*

Also, to move the arms at the same time will be super easy with the use of just one output... If you need to set them "closed" (folded) at startup via a logic_auto, only 1 output is enough:

- OnMapSpawn > chamber1_90_deg_arm > SetPlaybackRate > -1 / delay: 0.10*

(it is important to set enough time between the complete folding of the arms at startup and the panel_attach parenting in order not to parent the panels to the arms at some intermediary point between the arms' complete folding and their complete extention, since we have to set as default animation '90deg' in this example in order to use the output 'SetPlayBackRate' later; which means that the arms will be spawned as opened or extended)

For a later movement (animation) setting, for example via a couple of logic_relays, the single output would be this one:

**"arms_move_rl_on" **

- OnTrigger > chamber1_90_deg_arm > SetPlaybackRate > 1*

**"arms_move_rl_off" **

- OnTrigger > chamber1_90_deg_arm > SetPlaybackRate > -1*

I hope this is useful to someone Above is just an example, you can take the essence of it and apply the concept elsewhere

Is there any new updates for mapping and help links so far guys?...im looking forward for better change~!

---

To accomplish great things, we must not only act, but also dream; not only plan, but also believe.
Anatole's fantasy knife

very helpful information.

CGTextures is a fantastic site for textures. They have limitations on what non-subscribers can download -- free users have a 15MB/day download limit and can't get the larger versions of texture files -- but they've got a bunch of textures, both tiled and not. Transparent textures for overlays? No problem. More materials to build your maps out of? Sure.

You'll need VTFEdit (naturally) to turn their images into materials for your map, and PakRat to include them for people to see when they're playing, but it's a great way to add a little flavor to your map.

2013-05-20_00001.jpg

This exterior view uses a combination of textures from their site and existing textures -- a tileable asphalt texture for the street itself, a non-tileable storefront, and a few different tileable building textures. (It's also my first experiment with a 3D Skybox.)

Also, be on the lookout for materials in the real world to use in your map design. Most phone cameras have a high enough resolution nowadays to get a good enough image, but a good digital camera would be better.

I've made my own tiling textures before from real things. It's great fun!

If you have a good resolution digital camera then go out and take pictures of your own textures.

Josepezdj wrote:
Never move the entire map without texture lock.

Just in case anyone hasn't found this yet, when working in hammer try using the Go To Coordinates dialog to checkout the co-ordinates 200 -4096 1154

http://css.gamebanana.com/textures/cats/28 for nice skybox textures. Just remove the ignorez keyvalue and replace sky with UnlitGeneric if needed.

http://www.redsorceress.com/skybox.html For some intresting skybox textures. You need to VTF and VMT them yourself.

"""""

Not sure if this has been mentioned anywhere but I recently found out about it by accident.

The length of a light bridge is limited to 4096 units. If it is projected over a distance longer than that, it stops at 4096. If aimed at a portal in this condition, it will create a new bridge part at the other end of the portal, but that part is also subject to the same limit.
So if you have a big-ass room, make sure players can't portal a bridge all the way across

In other light bridge news: you know how there is a brief "stutter" the first time a bridge is activated? It turns out that's because one of the particle systems for it is not preloaded into memory. The classic workarounds are to make it start active and turn it off by logic_auto, or have a bridge permanently active in a closed box outside your map. But there is a cheap, universal solution: put an info_particle_system in your map and set its particle system to "projected_wall_impact". (No need to name it or do anything with it, it just needs to be there.) That will preload the missing particle system and prevent the problem.

HMW wrote:
-Useful Info-

Ouh didnt know about that, well thanks