Welll, if you have more than one then Quake picks one randomly. 

I didnt know that either!

Infact it took me to this map to realise that you can set a mangle key. Weird tho - the first number (yaw?) seems to be the negative of what it would if it was a light mangle key. i.e. -15 deg = 15 deg.

Either that or i've gone mad
:D 

Coopflags should work correctly on all entities currently in quoth, the main difference between them and normal flags is when the removal occurs. The engine removes things with spawnflags before the spawnfunction for that entity is run. We can't do that for coopflags, because the first time an entity appears to us in QC is when the spawnfunction gets called. So instead, an entity with these flags is removed under two circumstances:
1) If it is made into a static entity - so you can remove torches in coop - although one might ask why you'd bother.
2) At the start of the first frame.

Any kind of entity will be removed if it has these flags, but the difference is the spawn function will already have run, resulting in two pitfalls. So firstly the precaches for all entities will be run regardless of their coopflags. Secondly, any effect an entity has on the game during their spawn function will happen even if they are marked with coop flags. For example, putting NOT_IN_COOP on a info_command_spawn won't prevent the command being sent in coop, as the entity sets the commands during it's spawn function then removes itself. It's fairly rare for an entity to have that kind of effect though. One of the cases that's caught and dealt with is an entity trying to spawn a static sound when it has coopflags, again the wall-torches are a good example.

The precaches thing might sound a bit wasteful, but it only causes a problem if you have some precaches that only ever appear in coop and some different ones that only appear in non-coop. Otherwise it's the one with the additional precaches that runs into the engine limits anyway. Also note that all map bmodels are precached regardless of whether they get used or not, so more thorough coopflags would not help there. 

Im horribly confused on the mangle field myself. Some Quake references say it's a pitch,yaw,roll angle field and others say that it's indicating a location in the world to look at.

Which is it? 

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.