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? 

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