i�m doing the same procedure as 5th. 

There's some discussion about it in the issue tracker and I'd like to roll it into a prefab system. Good to know people do use them, I'll keep that in mind. 

One idea I proposed was to use .map - had no idea portal2 used it though.

It could work really well if used like the entities tab - you see a little preview of each prefab and just drag n drop into your current level. And just saving prefabs into a 'prefab' sub folder...

The complex part with the current workflow would be including entities with prefabs though, since grouping things can only be done through making them into a brush func group entity as of now.

I don't think an instancing support would be required, but I honestly don't know. Maybe it would be incredibly awesome to edit all your doors or whatever by opening a single prefab.map.

All the door frames in my test mod have broken offsets where the door z fights with the frame when open. 

always liked the logo. 

 

If I ever do another map I'm going to keep some kind of log book. I started to work on my map again yesterday after about 4 or 5 months, and I can't remember how things work. I find about 6 very similar versions of a texture and can't remember why I made them or how they're different. I walk through the map and see things and say to myself "Why in the world did I do that?" I'm going to end up wasting a week just figuring this stuff out. 

Use a code-versioning system to check in changes you did on your map with comments. 

to my world, Rick! 

Yes!!! 

Snarkpit website (can't remeber the http..) has also some nice to consider, even though they are CS oriented...
I also found once a website (Mission HQ as far as I remember...) in which there were tons of WW2 prefabs (i.e the Tiger Tank in Fort Driant has been re-built from one of their model)..

So prefabs ! Yes, there are many over the intarweb :) 

I was thinking more for personal clipping, as I don't like using other people's work in my own. Like if I spend a lot of time brushing a cool looking widget, or if I make a cool ceiling design, I could make a "slice 9" version of it and then save those slices as prefabs, so I can paste them and scale/extrude them as needed to make ceilings in a map. 

Why? Surely there is some way to fix this. I don't mean light mapped, just some way to turn the brightness down. I made a custom water texture using only the darkest colors available and it still looks too bright in places. The only thing that seems to help is wateralpha, but transparent water doesn't look right in Quake. 

 

Use wateralpha, and put a very thin (2 units) func_illusionary right under the surface, and then put an all black texture on the top face and skip on the bottom face. 

Use wateralpha, and put a very thin (2 units) func_illusionary right under the surface, and then put an all black texture on the top face and skip on the bottom face.
I have done this with teleporters, lava and water, works a treat! I usually make the lava illusionary brush red and the water one similar base colour to the top texture. 

Interesting idea. Might look funny if the player uses a very transparent wateralpha setting. I don't have any models left and I'm real close to the marksurfaces limit. I might just have to add a little more light to this particular area (it's not a very big part of the map).

On the other hand, I'm beginning to see less and less reason to keep deathmatch stuff and that would free up a number of models. I intend to finish this thing by the end of the year, if not sooner. I'm tired of working on it.

Still, it would be nice if this could be added as an engine feature, kind of like fog. 

That's an engine issue, not a mapping issue. You need to use an engine (like GLQuake, I think) that ignores fullbrights altogether. Personally I think that unless it's *Lava a little transparency can be a good thing in a visual sense. Of course it may also "Break" a map because, for example,in E1M4 (The Grisly Grotto), you can avoid the Skraggs by simply diving in and due to how the old vis worked you would disappear from their view and thus not get shot at from above or perhaps you can see a secret that you missed before. 

You need to use an engine (like GLQuake, I think) that ignores fullbrights altogether.

That won't work. 

I'm pretty sure liquids (including the sky) are treated differently from normal textures. Maybe that's why there is no brightness setting for them, because it would affect all of them equally? 

in terms of allowing the texture to be lit.

He said it wasn't possible, which is a shame because it would be great. I dunno if it is possible in dark places, probably is.

Fullbright water sucks :( 

Requires changes to both the tools and engine. Possible an updated bsp format too, though we could probably work around that. 

I can see why shadows on water (light mapped water) would be a problem, but what about some way to darken the water texture down from full bright? Just the ability to choose 75, 50, 25% brightness or something like that would be a big improvement. Actual shadows are not really needed, though I'm sure some people would think it's great.

A full bright sky is not much of a problem, most people use a skybox anyway, lava seems like it ought to be bright most of the time, but water being full bright often just looks bad. 

how about using an external TGA texture that is really dark? 

I was going by memory. I could swear that there was an engine out there that didn't fullbright liquids... Maybe an early version of TXQuake (OpenGL based) or something else from that era (early 2000's a year or two after the GL source was released) I recall that it looked washed out in general. Then again I might have been thinking of a totally different game altogether, maybe Q2.

It (fullbright liquids) can screw up the look of a level in some places because it stands out so much if you want to go dark and gloomy with a secret area that you need to dive into in order to get to the goodies. There are ways around that with creative brush work but it's still a bit of a pain to light in order to explain away the bright liquid.

Ideally only *Lava(xx) (all versions) would be fullbright with the *water(xx) never fullbright, *04water(xx) always fullbright, *01slime(xx) being never fullbright and *04slime(xx) being fullbright, or some other similar naming convention.

I get why they did it back in the day and it made sense from a hardware point of view but today it can limit options in some small cases. 

If you're already willing to change the look of default Quake, then using DP/FTE and GLSL water isn't a stretch. Pretty sure you can set some parms to the GLSL that would give you less transparent water, such as fog, tint and fresnel. You could try not using normalmaps with the glsl water either, or really flat ones to prevent the water bumping itself...


or write your own glsl water shader for vanilla looking water just slightly transparent but still not able to see much beyond the surface. Fresnel etc.

Real water's transparency depends on depth and the colour of the ground etc, so the dm3 pool shouldn't be fully transparent indeed.

glsl is your friend.