viewpos in the console and it'll give you a loadout or where you are and which direction you're looking in (its the second one). Use this with noclip to get good intermissions.

intermissions do have a weird angle setup, different from all the others, but there you go. 

It's definitely a pitch,yaw,roll angle field and not a specific world position to look at.

It's still confusing though - I'm pretty sure some entities handle it differently to others (as in sometimes it's yaw,pitch,roll instead, or whatever). I could be wrong here, but I definitely never fully made sense of it.. I always seem to have to trial and error it when I set up an info_intermission or something. 

a light pointing north, tilted down 45 degrees towards the ground would be 90 -45 0, the third number required for no reason whatsoever (!?)

One pointed east, perpendicular beam to the ground would be 0 0 0

One pointed straight up or down would be 0 90 0 or 0 -90 0


This sort of explanation would hopefully help with lights (get you pointed in the right direction), but I've tried a mangle key with info_triggered_lightning (or whatever the quoth entity was) and had no success, and the first number of the three for an info_intermission seens to be the polar opposite of what it would be if it were a light....

:-/ 

Polar opposite is the wrong term.

I mean a value of 45 0 0 would be a light with its beam perpendicular to the ground pointing north east. If it was an intermission with the same value it would be pointing south east. 

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 ;-)