I loaded your map into darkplaces, and looked around a bit with r_showtris 1.

1) Those aren't "excess" triangles. QBSP's subdivide size usually defaults to 256, and it appears to me that the massive surfaces of your structure were, for the most part, neatly subdivided into 256*256 blocks, each of which are further divided into two triangles for rendering. It just looks like the subdividing went crazy because your surfaces are so huge. You can change the subdivide size from qbsp's commandline, but I think if you set it really high, like 1024 or so, you'd get other errors besides the malloc/allocblock thing (maybe a subdivideface: didnt split the polygon?)

2) That's vis for you. sucks, doesn't it? You may be able to cut down on that very long visible distance if you put in some periodic retaining walls that radiate out from the center core of the spiral.

3) I ran into this with a similar map. My layman's guess is that some engines just hate large brushes, even if qbsp is supposed to subdivide them. Try breaking those brushes that are the size of the whole available grid into about 4 subsections and see what you get. 

Thanks for the help guys, I have a few more questions.

1) Lightmaps
Would it reduce them if I made more of the textures as sky? That isn't lightmapped, correct? I can also increase the tex scaling by 2 in both directions easily in the floor.

2) Triangelization or however it's written..
Well I'm still not at home and can't post shots, but it seems at times, a 4-sided polygon is taken from one corner and divided into twenty thin triangles or something.

3) How do I increase the subdivide size in qbsp? Didn't find any docs. Aguirre you could really compile even a short list of switches into the readmetree and readmetx files.
-subdivide 1024? 

and/or increased tex scale will help reducing lightmaps. As for subdivide size, you set it with the -subdivide x option, although I definitely do not recommend messing with it.

You can get a brief option list with any of my tools by just running it without any parameters, results end up in the console window and in the log file (if any). 

I increased the floor and roof tex scale to 4 in both directions and now it compiles and runs at full 77 fps in fuh (and 72 in fitz). I also removed some flat areas from the map and further reduced the brush count (151->102)...

Now this
http://skynet.campus.luth.se/~chosen/bam/spir/fitz0098.jpg
still happens, but what can you do... :/

Neatly subdivides into 256 blocks since I was using 256 grid. 8)
The new version is in the dir as zip http://skynet.campus.luth.se/~chosen/bam/spir/sispi7.zip 

checking out the spi7 map, I'd suggest that you try to avoid sky brushes touching solids outside the map. Load up the map in my GLQuake, noclip outside and you'll see what I mean; huge textured faces covered in sky that probably generate a lot of lightmaps.

You should always avoid having visible faces outside a map, especially if they're big. 

I wondered the same too... I only changed them to sky because the map didn't run, i might be able to avoid it now. 

actually i've found a palmtree prefab on fileplanet and the lefs of that palmtree i've tryed to use but when i use say 4 leafs qbsp gives many errors and i have no clue where to actually begin but the map still runs smooth no errors in fuhquake atleast looks nice to it's just that it takes much longer to compile than it's supposed to
heres the error i get so far the first one i understand but the second... well heh no idea
*** WARNING 12: New portal was clipped away in CutNodePortals_r near (-288 -678 347)

*** WARNING 08: Healing point (538 -950 250) off plane by -1.27
^ that one is driving me nuts

anyway it still would be nice with some leaf textures oh and i've actually tryed to use thouse uzul textures but on this map it dosen't fitt :/ 

not fuhquake. i said worked in fitzquake. 

Now it works as intended originally.
http://skynet.campus.luth.se/~chosen/bam/spir/

No messing with sky brushes. Why are they treated differently by qbsp anyway? If a normal brush touches another outside the map, those faces are discarded by qbsp, but if a sky does that, they are not. Why? 

but sky brushes (or rather, leafs) are handled separately by the engine, e.g. for animation/skybox, lightmaps and rocket collision. I guess it would be more difficult for the engine to do this if qbsp didn't also handle and mark them differently.

Also, note that the default sky presentation in FitzQuake hides the outside sky leafs if not r_oldskyleaf is enabled. Having such leafs will increase engine lightmaps and prolong Light processing time if any ambient lights are used. 

I just set WC up for Quoth, made a test map.
when I tried to run it, things didn't go smoothly. Actually, things didn't go at all.
All the process window said was this:

** Executing...
** Command: Copy File
** Parameters: "C:\QUAKE\ID1\maps\smblood.map" "\smblood.map"

Does anybody know why? I don't. I'm probably just going to go to bed, because I'm too tired to try to figure this out right now.
Thanks. 

That is quite possibly because you are using the map compilation front-end utility found in Worldcraft, which is known to be shit. Try using a *.BAT file. 

"f9" can be bearable at least for speedmaps.
(aguirre's vis defaults to level 4 and the light works reasonably too on default settings) 

where did rorshach's textures go? Can anyone mirror or know the filenames at fileplanet?

The site at planetquake links to quakefiles.com which has a 404 error. 

I have never, in my life, used anything to compile maps except for WC.
How do I use a .Bat file? Any other info I should know about? 

Just to make sure, I fired up WC with the quoth.fgd, built a simple testmap and compiled with the standard WC compile window. No problems.
So if you've always used WC's compile mechanism, I don't understand why it would fail now.

First, and obvious, question: what compilers do you use?
Second: have you altered the setup in the Tools -> Options menus at all, since switching to the quoth.fgd?
Third: have you simply added the quoth.fgd to WC's list, or replaced the old fgds completely?

Using a batch file is not actually that difficult; the proof? I had to start using them when I switched to GtkR. So they must be easy :P
I'd hold off trying that solution atm though. I reckon there's a simpe solution to your current compile problem. 

I recently wrote a fairly in depth guide to getting batch files set up to compile maps :

http://map-center.com/modules.php?name=Forums&file=viewtopic&p=59729&highlight=&sid=a7313da1cf13eb6851bede7fe3e72424#59729

Hope it helps 

Compiling using BAT files is really the way to go. I tend to tweak a lot of command-line options of my Quake compilers (compilation progress bars, skylight, minlight, other light options, transparent water, etc) so I just have 3 BAT templates that have my favourite compiler settings and I can just drop the map filename into the BAT and it works. Why 3 BAT files? For quick test compiles, "medium" and absolutely-best-quality full compiles. 

You can actually do all that from within WC's compile options. Selecting 'Expert' allows you to create a set of compile 'templates', edit them and choose them from a list; it's just editing the batch files from within WC.

I use template batch files now too.

Either way is fine. 

1. is it possible to use the item functions with an info_notnull in order to give the player ammo etc. upon touching a trigger?

2. lights with a 'style' key can't be switched on/off?! can this be circumvented through qc? or is it an engine restraint? 

I use it. It is easy and gives you the possibility to switch of this or light or vis without editing batch files.
You can prepare any configuration you want (similar to creating a batch file) and then you can alter this configuration very easy if you want.
I usually use Alt-B to export changes to map, then press F9 to open the compile window and then I can choose what tools and options I would like to run. I have never encountered any bugs with this. Here is an example.
http://republika.pl/quake_1/WCadvanced.jpg

Drew shouldn't you copy the compiled file to the quoth directory?
** Command: Copy File
** Parameters: "C:\QUAKE\ID1\maps\smblood.ma... "\smblood.map" 

Triggers that give ammo are possible with the notnull trick. Make a brush entity with these fields

classname info_notnull
think InitTrigger
nextthink 0.3
touch ammo_touch
weapon 2
aflag 30
netname nails

Weapon determines the ammo type, 1 to 4 for shells up to cells. Aflag is the amount of ammo to give. Netname is the text that goes after "You got the" that's printed in the top left, it doesn't have to correspond with the usual phrase. If you wanted to print "You got the ammo pack", that would work.

This trigger will only work once. If you want it to be reusable, then you'll need to do a bit more. Add these fields

targetname ammotrigger
use SUB_regen

Then have something target the ammotrigger once it's been used to reset it. You can have a trigger_relay targeted by the ammotrigger that targets it back after a delay to replicate respawning as in deathmatch, for example.


I think you can get around the style toggling restriction with QC if you are careful, but it's not easy. Quake has 64 possible light styles, controlled by a command like so:

lightstyle(3, "aja");

The first number tells the engine which lightstyle to change, and the string defines a kind of "animation" of the light. Each character in the string sets the brightness of the light for one frame, a being the darkest and z lightest. So this command would make any light with style 3 flicker on and off rapidly.

The style key you can set on a light gives it one of a predefined set of styles from world.qc. But any light that you make switchable is also assigned a style from 32 - 62 by the light program. The way the light is toggled is by changing the style between:
lightstyle(self.style, "a");
and
lightstyle(self.style, "m");
So if you were to toggle one light with a predefined style, you'd in fact turn off all lights with the same style. So to get round it, you'd need to make sure that your light gets toggled between off and the correct style.
The way I'd do that is something like:

void() light_use =
{
if (self.spawnflags & START_OFF)
{
lightstyle(self.style, self.netname);
self.spawnflags = self.spawnflags - START_OFF;
}
else
{
lightstyle(self.style, "a");
self.spawnflags = self.spawnflags + START_OFF;
}
};

/*QUAKED light (0 1 0) (-8 -8 -8) (8 8 8) START_OFF
Non-displayed light.
Default light value is 300
Default style is 0
If targeted, it will toggle between on or off.
*/
void() light =
{
if (!self.targetname)
{ // inert light
remove(self);
return;
}

if (self.style >= 32)
{
if (!self.netname)
self.netname = "m";
self.use = light_use;
if (self.spawnflags & START_OFF)
lightstyle(self.style, "a");
else
lightstyle(self.style, self.netname);
}
};

Replace the corresponding bit of code in misc.qc with that chunk of code. Then make the targetable light as normal without setting a style, but set the light's .netname to the sequence of lights you wish to display. You'll probably have to look these up in world.qc, for instance to get style 3 set

netname mmmmmaaaaammmmmaaaaaabcdefgabcdefg

The added bonus is you aren't restricted to the preset styles, you could define a new custom light style in this way, and it could be toggled. 

and does the item trick work with health and armor (possibly artifacts), as well? if it does, how can the different sizes be determined with touch_health and touch_armor? 

The same kinda trick works with health_touch, the important fields are:
healamount 20
healtype 2
noise items/health1.wav

along with the ones for setting up the weapon touch, the think and nextthink ones should be as before. Healamount is the amount of health that should be healed. Healtype 2 means the healing ignores the maximum 100 health, like a megahealth does, and will rot down again afterwards. However, be warned that the entity is now keeping track of when to count the player's health down, so don't allow it to be touched again/do anything else until enough time has passed for the health to rot away, ie 1 second for each hp you give the player plus 5 seconds start time. Setting healtype to anything but 2(including 0) will result in normal healing - none if the player is at full hp. Noise should be a sound that's already precached somewhere else.

Armor_touch cannot be exploited in this way, as the function relies on the classname of the entity, and there's no way round that if you're using an info_notnull. Key_touch is wide open, but doesn't make a lot of sense. Sigil_touch will also work.

Interesting aside...if you set flag one on a trigger_multiple, you can give it a touch field and not have it reset when it spawns. I can't see any obvious advantages of this over just making an info_notnull trigger, except that this doesn't use the think field. But somebody might be able to use this creativly... 

regarding the triggerable trigger_changelevel trick czg posted in the progs.dat thread:
can a similar method also be applied to other triggers? e.g. to activate a trigger_once for a teleport ambush in an area the player has already passed before.