/******************************************

Switcheable lights that
turn on and off gradually

Affects all switcheable lights in all maps.

Customization : in light entities, set
"speed" to the speed of the turning on/off
(default 1). Set speed to -1 to recover
the default behaviour.
Armin Rigo
*******************************************/ 

aguires` qbsp removes texture paths if u use q2 map mode 

Sure, but at that point what's the purpose of having Q1 support in an editor? I can use sleepy's mapconv.exe and make the map in qeradiant too. 

Can it be done?

I want to drain an area... 

pox_extras mod... it has moving water volumes. 

exploding barrels! I have just altered my own progs with it! I couldn't delete the bot code,as it started giving errors.

http://members.home.nl/gimli/extras_r4.zip

Another noob question: if I want to spawn a new monster in the explosion of a Vormit,where in the qc should I look? 

Or just make the room the water is in, a func_train... this won't always work well depending what kind/size room. 

Phait - q2 has func_water which assumes it will move pretty much like a func_door, it was later updated by the lazarus mod to include lots of nice features (mud, sine wave bobbing etc.).

but as far as I know nothing exists for water to be killable because of the way quake calculates the world in the vis/bsp process. I'd recommend not allowing the player to touch it and then changing it to a func_wall - it'll be solid and i cant remember if it would animate or be frozen (the texture) but you'd be able to kill it.

also - i remember some discussion on this, but what are the workarounds for enemies + items appearing black when not above a solid brush - ie. floating in the void, typically scrags and other fliers, although i've had problems with func_trains and others. 

The bottom layer should be a brush with any normal texture (scaled up 40 times or something), then a brush with your black sky. You might have to make the sky brush a func_illusionary.
Place a huge light at the bottom to light it all. Hint: make it a spotlight pointing down with a 180 degree cone. This way you avoid spilling light upwards to the rest of the level.

As for trains, they are lit wherever they are built and then moved into the correct position upon map load. If you need to, you can build it in a small room outside the level that is floodlit. 

what are the workarounds for enemies + items appearing black when not above a solid brush - ie. floating in the void

Short version: place a brush inside the bottom skybrush. Light its top surface.

Long version: http://www.celephais.net/board/view_thread.php?id=4&start=4765 

i'd considered a solution like this but wasn't sure how light knew that there was a brush 'outside' the world (inside the bottom skybrush). I'm using sunlight so maybe I won't need to place spotlights on the floor, though as my skybrushes are already with texture size 9999x9999 it wouldn't be too much of a hardship to copy paste. i've also got the lower walls being skybrushes as well, solid geometry doesn't touch the lowest skybrush, so lighting wouldn't be a problem - all brushes are flush to the base, to help VIS, though it does spoil the illusion slightly when the player falls into the void.

cheers! 

I have this Mage/Newboss in a cave, but it shoots missiles from a lower startpoint, than it can hit me. How do I alter its missile, so it shoots from that height straight to me?

http://members.home.nl/gimli/nbase.jpg

First I lowered the mdl file with Quark and set it in the map to a heigher field. But it felt back.
In the qc for Launch_ lava I changed its origin, but then it shoots beside me.

setsize (newmis, '0 0 0', '0 0 0');
newmis.origin = self.origin + '0 0 12';

newmis.origin = self.origin + '0 0 256';
won't do, because then it still launches from the bottom over my head. 

well, after puzzling awhile I found when I change in the Launch_lava:

vec = normalize (vec);
into
vec = normalize (vec - '0 0 164');

it launches straight to me from the right height, only the launch moment has the same muzzle flash on 0 0 12 point.

http://members.home.nl/gimli/nbase0.jpg

I am using the extras_p4 pak, and I seem to get fine results, goodies like exploding barrels, func_watertrain, func_breakable.

When I play the extras game, it seems as if the monster_fish won't attack me (?!). Even when I'm in front of them. Is this a bug? 

How is it done? 

"spawnflags" "1" 

fishes fell out of water_train, so my fault they won't attatck. No bug in extras_p4. 

The map has no leaks and is not boxed. However, I do have some extremely large single brushes (2048 x 1024 x 16) that are not sky-brushes.

Is there any benefit to making these either smaller brushes but taking up the same space, or by making them up with smaller brushes with different textures.

I ask because I remember some previous discussions about 'lightmaps' causing this error and I think that is to do with textures.

(I can't search back through Mapping Help as the Previous link stops working after about 5 or 6 clicks - I just get The Page Cannot Be Displayed type error) 

See my ToolTips, engine section. Increasing tex scale usually helps. I don't know if splitting brushes will help much as qbsp already does that, but it could be worth a try. Different texes shouldn't make any difference.

You can use the command lightmaps in my GL-engines to see the current requirements. 

OK, thanks.

Using your engine I can see that the lightmaps are 64 i.e. at max, in the map version prior to getting the error. The only difference was that in the next version I had added some extra 'normal' size brushes (a corridor) but I do not know whether I added any new textures or not.

I re-scaled one of the largest brushes to x5 and sure enough lightmaps became 63. For the sake of good order, I then changed another to x8 and lightmaps dropped to 60. I also tried all textures the same and it rose to 65 lightmaps, so that didn't help. Finally, I split one of the largest brushes into 16 and the lightmaps stayed at 64.

I think that probably 'proves' the thoery so will look towards rescaling to reduce the lightmaps.

If it is not too difficult, can you describe what a lightmap is and why changing the texture scale should reduce them. Also, does re-scaling downwards have a detrimental effect?

Is there an argument for manipulating the textures in (say) Photoshop so that you can scale-up in the editor to get the texture looking normal in the engine, thereby avoiding the lightmap problem? Or am I trying to be too clever for my own good here:-) 

I also don't know exactly what they are, but think of them as the surfaces of each visible brush face containing information about the current lightlevel in a number of discrete surface points, arranged in a grid and with a density related to the current texture scale (smaller scale means more points). The lightlevel can be not set (i.e. fullbright) or as calculated from the light tool.

Either way, all these surfaces must then be allocated in the engine no matter if they're fullbright or not and they're all in one big memory buffer that in normal engines has a certain fixed size. The allocation strategy is made in a way that may cause inefficient usage of this big buffer and in any case you can't have more than 64.

An engine can then just increase the buffer size (will require quite a bit of memory) or allocate it dynamically, like in my engines or DP. My limit is still set to 1k lightmaps since I still use a small fixed size array, but I could easily increase that if required.

I've never seen any real map require more than about 800 lightmaps, though (a huge leaking map). You could probably easily produce a synthetic test case of course that could exceed even my 1k limit. 

My map suffered the same problem, before I scaled texture.

For my good understanding;

so textures that are out of vieuw,ie backsides,
two brushes against eachother, their textures size does count in the total 64 lightmaps? 

see the textured faces in-game (noclipping or not), the faces count. That is one of the reasons why any volume that the player can't reach (or is used for other purposes) should be filled or opened for the void.

It's also the reason why unnecessary sky should always be shrunk to minimize the outside textured faces. They can be a huge contributor to the total lightmap count. 

but would it possible to run some kind of precompiler or .bat that automatically stretched every sky / clip / trigger texture 9999*9999 ?

it'd be a lazy man's tool (since ultraedit can do the job as well) but would be good if implemented directly into the compiler, though it would remove alot of the necessary thought from texturing, so maybe not such a good idea. 

Sky faces don't get lightmaps, so they aren't part of this calculation. Same with clip.

Trigger, on the other hand, does get lightmapped. So if you have any large triggers, you would benefit from scaling the textures up. Same with Skip. 

I have a looped .wav file that I want to use unlooped. How can I convert it to be unlooped?