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? 

If you use Goldwave, it's fairly easy. Open the wav file up, and go to Tool -> Cue Points. Select the cue points present in the file and delete them. Then save it again and it will no longer loop. 

Well that was painless, thanks Preach. 

...I'm using Hip's rotate entites and for any single object or a group moving in one direction together, everything is fine - smooth as a whistle. But if I have two seperate objects moving at the same time e.g. double doors opening away from each other, I get 'judder' on one of them.

Is this a known problem and can I do anything about it (apart from making it a single door)?

As always, your help will be appreciated. 

as this method is simpler (if you don't have anything other than soundrec.exe).

open up soundrecorder and make a new wave file. do edit->insert file->your looped file

now resave as a new (or overwrite). voila, no more loopage. :P 

Do I remember a mod from some time ago that put blood splatters on the walls?

(necros: thanks, I'll try to remember that) 

i think SoA had that?

careful though. sprites don't get lit, so blood splatters in dark rooms will look dumb. 

How did you know my rooms were dark ;-)

Thanks, I'll look up SoA. 

Ok, I have a quake map, in the half-life .map format (I made it with Hammer you see), and I would like to somehow get it into DOOMEdit.

I don't care about any of the entities obviously, but it would be nice to have the geometry of brushmodel entities preserved in some way.

Any ideas how I would go about this? 

Just a hipshot here, but could you perhaps run the hammer .map file through mapconv.exe and output it as a standard .map file that you can import into doomedit??

* I am very drunk 

Isn't the brush data stored the same in all WC/Hammer/Doomedit maps? If you didn't care about the texture data then it might be possible to reset all the textures to one texture with one scale/rotation/shift setting, and then find/replace that with Doom3's texture data. 

AFAIK brush formats differ between hl1, q1, q2, d3, etc 

...is some of the numbers at the end, which represent brush flags, surface flags, light values, etc. And I think HL has a different texture alignment format. But the brush geometry itself is the same across all of them, I think. 

is some of the numbers at the end, which represent brush flags, surface flags, light values, etc.

Yeah, that's certainly the difference between Q1 and Q2/3 .map format. That's as explained in the older mapconv tool readme.
I'm not sure what the particular flags/info in the HL format .map are, but ages ago I successfully opened some Q1 .maps in WorldCraft 2/3 without any conversion. The texture info was indeed lost, but the brush info required no translating. 

cheers for the replies - here's some info which might be useful. I tested in gtk, creating a "map" consisting of one 128x128 brush centered on the origin. This is the Q1 .map

// entity 0
{
"classname" "worldspawn"
// brush 0
{
( 64 64 64 ) ( 64 -64 64 ) ( -64 64 64 ) NULL 0 0 0 1 1
( 64 64 64 ) ( -64 64 64 ) ( 64 64 -64 ) NULL 0 0 0 1 1
( 64 64 64 ) ( 64 64 -64 ) ( 64 -64 64 ) NULL 0 0 0 1 1
( -64 -64 -64 ) ( 64 -64 -64 ) ( -64 64 -64 ) NULL 0 0 0 1 1
( -64 -64 -64 ) ( -64 -64 64 ) ( 64 -64 -64 ) NULL 0 0 0 1 1
( -64 -64 -64 ) ( -64 64 -64 ) ( -64 -64 64 ) NULL 0 0 0 1 1
}
}

Note that the half-life version would be very similar to the Q1 version, but GTK wasn't playing nice with me in HL mode for some reason, so I couldn't test. The only difference between HL and Q1 afaik are some extra texture alignment properties. The way it stores brush geometry is the same. The HL .map format is detailed here:

http://collective.valve-erc.com/index.php?go=map_format

and this is the same "map" again, remade in D3 mode:

Version 2
// entity 0
{
"classname" "worldspawn"
// brush 0
{
brushDef3
{
( 0 0 1 -64 ) ( ( 0.03125 0 0 ) ( 0 0.03125 0 ) ) "_emptyname" 0 0 0
( 0 1 0 -64 ) ( ( 0.03125 0 0 ) ( 0 0.03125 0 ) ) "_emptyname" 0 0 0
( 1 0 0 -64 ) ( ( 0.03125 0 0 ) ( 0 0.03125 0 ) ) "_emptyname" 0 0 0
( 0 0 -1 -64 ) ( ( 0.03125 0 0 ) ( 0 0.03125 0 ) ) "_emptyname" 0 0 0
( 0 -1 0 -64 ) ( ( 0.03125 0 0 ) ( 0 0.03125 0 ) ) "_emptyname" 0 0 0
( -1 0 0 -64 ) ( ( 0.03125 0 0 ) ( 0 0.03125 0 ) ) "_emptyname" 0 0 0
}
}
}

As you can see, even the syntax for the brush coordinates are stored differently. Here's as much as I could find regarding the D3 map format (I didn't look very hard, mind):

http://www.modwiki.net/wiki/MAP_%28file_format%29

Getting from HL -> Q1 is something i've done before. SPoG once made a quick build of GTK for me that opened a HL .map and saved a Q1 .map. I've lost this unique build ever since I had to reformat my laptop; SPoG, I don't suppose there's a chance you've still got it saved somewhere?

Daz: I thought mapconv.exe only worked for swapping between Q1 and Q2/3, or is there another version around?

I hear that getting from Q3->D3 is possible too, something about DOOMEdit will import a Q3 map that's been saved in "brush primitives mode". If true, then HL -> Q1 -> Q3 -> D3 might be achievable with existing tools, but I'm currently still stuck on the first stage... 

can do several (if not all) of those formats natively and usually you can also choose between several output formats for a specific game. I can e.g. get it to output a Valve 220 (Hammer) format map from a Q1 source directly.

I've also used it for converting from Hammer format maps to BSP editor format. The only obvious problem then is the lost extra tex info. There might of course be accuracy losses as well if it's a big and complex map. 

I have a gold key that targets other events e.g. spawn a monster. I collect the gold key and sure enough, the monster spawns in.

In another map, I have exactly the same set-up but the monster doesn't spawn in. In the editor I can see that the key is linked to the monster, and target and targetnames are correct.

Why would it work in one map and not in the other? 

Wait, so the key is targetting the monster itself? Does that mean you're using a modified progs like spawn64, where you set a flag on a monster to spawn it? It's possible that custom code would behave oddly. Otherwise I can't see any reason why a key would fail to target something if you replace it with, say, a button with the same target. 

... more haste, less speed.

I hadn't vis'd the map. The monster was there, I just couldn't see it. Ho hum! 

Wasn't ignoring you, our messages overlapped.

And yes, I'm using your 'style 1' idea and it all works just fine. It's just that Qbsp takes 3.5 minutes and Vis takes another 3, so I don't use it (or Light) when I'm only doing quick checks.

As I say, everything is all right. I might even post some screenies sometime.