That's why I can never get it straight... it's different on lights and info_intermission entities. I guess this is why - here's the specs for the intermission entity:

/*QUAKED info_intermission (1 0.5 0.5) (-16 -16 -16) (16 16 16)
The camera point for the intermission. Use mangle instead of angle, so you can set pitch or roll as well as yaw. 'pitch roll yaw' Quake does a random pick if more than one exists. If no info_intermission entity is set, Quake uses the player start.

Here's the spotlight comments for Tyrlite:

Spotlights can be optionally aimed by specifying yaw and pitch values, instead of targeting an info_null entity. Add a new key in the form "mangle" "# # 0". The first # is the yaw angle, 0 to 360 degrees around the Z-axis. The second # is the pitch angle, 90 to
-90 degrees up to down. The 0 is just a required placeholder. 

What do I need to have my water transparent? 

or is that not helpful? :p 

Assuming you're using his compilers.

http://user.tninet.se/~xir870k/

I think its something like -transparent in txqbsp. 

Mike Woodham r_wateralpha "" change values and set the one you want 

can't you target an info_null from the info_intermission? I thought info_null was specifically for that purpose (along with spotlights).

Having said that, I've never done it, I've always used mangle. 

Dunno, but it sounds like a good method if you can do that.

Also, the viewpos method mentioned previously sounds like a real winner. 

Yeah, I just tried out viewpos in the game and damn if that isn't handy! Winner. 

Me seems to be too stupid to set up radiant, can someone help me please 

So, does that mean that I have to compile with -transwater AND use r_wateralpha in FQ?

In my sequal/prequal to FMB-BDG I have an area that gets flooded when the player enters it (a race-against-time affair). The traditional way to effect this seems to be to move the 'room' through a static water brush. However, due to the fact that I cannot (do not want to) turn this amount of the map into a moving object I am using a moving water brush but have a problem whereby when you are underwater looking up you cannot see the surface.

This does not look right in-game. Has anyone got a solution to this? 

Use opaque water then, or prevent the player from being underwater when the flooding takes place. 

The whole point is that the player will be underwater during the game-play and will drown if they do not do the necessary.

I am not looking for alternatives, I am looking for solutions. 

The water transparency controlled by r_wateralpha does not apply to brush models, only to world brushes. You need some kind of .alpha support to make the moving brush transparent.

Incidentally, this means you can make teleporters with opaque textures in maps with transparent water by making the teleporter brushes func_wall or similar. 

Well, there is no easy solution (that I can think of). Are you using your own progs.dat - didn't hipprogs have some rising water code? 

has that and some other water control functions. 

Yes, most of the code comes from Extras. But with Preach talking about .alpha support, I am lost. 

Ok, I want to be absolutely sure what the problem is here, because I may have got confused. Either:

1) When you look up while in the water you can see a water texture, but it is opaque rather than semi-transparent like normal water.

or

2) When you look up while in the water there is no water texture rendered at all, you can see straight out into the level.


The only solution to 1) is to add
.float alpha;
as a field in your progs, then set
self.alpha = 0.7;
on the func_water entity. This can be set through the map editor as a field on the entity instead. Of course, it will only work in engines that support .alpha, so not fq yet.

The best solution to 2) I can see is to comprise the model for your water of a very thin brush of water just on the surface, and then another larger brush just below that. Leave a gap so that the lower surface isn't clipped away. Turned on it's side it would look like:

| [........]

That way the lower face of the thin brush is visible while you are below the water. 

the pox_extras mod had example maps with water surfaces visible from inside the water model... i think it was made using extra-thin brushes or something, maybe check the map sources or docs. 

I'll play some more today and let you know if I get anywhere. 

A 1 unit func-water brush placed either inside the other brush or abutted against it does give a surface effect.

Now I will have to see if moving the brush still works with the same effect.

I will revert... 

I now have it working.

As Preach suggested, a 1 unit func_water brush abutted but not inside the main func_water brush, works: they both rise at the same time (triggered). From inside the brush i.e. underwater, when you look up you now see the surface. When viewed from above the surface i.e. you have solved the puzzle and escaped, there is no z-fighting. And when moving through the water and breaking the surface, everything looks fine.

By the way, no clipping takes place - is this because they are entities and not ordinary brushes?

Don't know what all the fuss was about ;-) 

I tried the moving water trick with the pox mod and found it quiet hard to make it arise for large brushes along distances. Also the surface isn't animating, although there is an animated texture for it.

I tried the old fashioned way also by making the room a func_train into a cube of water.
It seems you found a good solution for it.

Can you provide a map with an example?
I am really curious to it, as I feel the fuss somewhere I am loosing you're explanation. 

OK to use the registered e-mail for you?

I can send a sample map today. 

I�d be glad to explore. 

Hang on! Don't get carried away. The map I am sending you is not the FMB map the moving water has been designed for.

It is a single room showing the water brush rising and the use of the 1 unit brush to create a visible surface.

So not much to explore :-)