... I also would like to perform these two features without taking into account the buttons switch order.... rather difficult, or not ??? 

Now I understand you a little better. You should set the buttons up individually to trigger the monster teleport traps. Then create individual trigger_relays, with the same names as the teleport traps, which will target the counter.

For example, if you wanted to have a door opened by three buttons, and wanted each button to spawn a group of monsters, you'd need the following entitites:

buttons:
func_button (target="A")
func_button (target="B")
func_button (target="C")

teleport traps:
trigger_teleport (name="A")
trigger_teleport (name="B")
trigger_teleport (name="C")

relays to make the buttons also target the counter:
trigger_relay (name="A" target="counter")
trigger_relay (name="B" target="counter")
trigger_relay (name="C" target="counter")

the counter itself:
trigger_counter (name="counter" target="door" count="3")

If you use the above method, each switch will have its own indiviual group of enemies, and that particular group will spawn when the button is pressed, regardless of the order in which it is pressed. If that's a problem and you'd rather have each button spawn an INCREASINGLY STRONG group of monsters, regardless of order, you could do it with a bunch of separate counters. Your entity set would look something like this:

buttons (with the same target):
func_button (target="A")
func_button (target="A")
func_button (target="A")

counters (to trigger different traps depending on how many buttons have been pressed):
trigger_counter (name="A" target="trap2" count="2")
trigger_counter (name="A" target="trap3" count="3")

teleport traps:
trigger_teleport (name="A")
trigger_teleport (name="trap2")
trigger_teleport (name="trap3")

the door, with the same targetname as the last trap:
func_door (name="trap3") 

Great !! It was exactly what I was looking for !!! I was thinking about the second method, but really didn't know how to implement it... Thank you very much Fern....
Bye.. 

so does *anyone* know what SZ_getspace: 8030 Is > Full Buffer Size means on starting a map? 

Post #3 on this thread is kinda funny now. 

By looking in the engine source common.c I can see that the error message occurs just after the ... overflow without allowoverflow set ... error.

It's in a generic memory allocation function so it's difficult to say what's causing it without a stack trace.

An educated guess could be that it's entity related (what isn't?). 

well, this error happens in all the engines that i have tried, Fitzquake, regular GLQuake and tyr-glquake (which has a super high entity limit)

the thing is, i was just below the limit for bmodels when i compiled the map. so then i added in more ammo and health, and that's when the problem came up... the thing is, i thought ammo and health didn't affect bmodel limit because it's only the first one that counts... 

I don't know much about shaders and I don't really care to learn, I'd just like to get things done. I want to have a beam projecting from a light, but in an orange colour. I can take red_beam.jpg from sfx and modify it, but the sfx shader refers to red_beam.tga which as far as I can tell doesn't exist in pak[0-8]. So does the texture exist for me to screw with or what do I do? 

the shaders refer to a .tga in all instances, whether the corresponding file is in .tga or .jpg format. The engine will search for the file in .tga format; if it doesn't find it, it will search for it as .jpg instead.
So you're all clear to mess with the red_beam.tga shader, though it's obviously wise to c'n'p your own version of the shader ( and image if you itend to modify it ) before messing. I probably didn't need to mention that bit did I?

:P 

It never hurts to mention that bit. 

Here's an obscure question - is it possible to alter the image scale on quake sprites? They obviously default to 1:1 in line with normal quake texture scaling but I'd like something different. 

ok, chaps - i'm about to unleash my long-awaited debut map - Bastion of the Underworld - but as if to spite me, tyrlite has decided it suddenly doesn't like me anymore and refuses to light my map. here's the important bits of the log:

===========================================

** Executing...
** Command: C:\Editing\Quake\tools\BENGT_~1\TREEQB~1.EXE
** Parameters: "c:\editing\quake\maps\bastion3.map"

TreeQBSP v1.95 -- Modified by Bengt Jardrup

Input file: c:\editing\quake\maps\bastion3.map
Output file: c:\editing\quake\maps\bastion3.bsp
---- LoadMapFile ----
----+----+
Title: "Bastion of the Underworld"
34644 faces
5748 brushes
737 entities
74 unique texnames
606 texinfo
4 texture frames added

Building hulls sequentially...
Processing hull 0...
---- Brush_LoadEntity ----
----+----+
5290 brushes
---- CSGFaces ----
----+----+
31809 brushfaces
24830 csgfaces
22375 mergedfaces
---- SolidBSP ----
28762 split nodes
12889 solid leafs
15165 empty leafs
709 water leafs
53805 leaffaces
48311 nodefaces
---- FillOutside ----
4565 outleafs
---- MergeAll ----
20143 mergefaces
---- SolidBSP ----
----+----+
12247 split nodes
6138 solid leafs
5841 empty leafs
269 water leafs
31831 leaffaces
25388 nodefaces
---- Portalize ----
6110 vis leafs
19624 vis portals
---- Tjunc ----
26792 world edges
91489 edge points
19883 edges added by tjunctions
0 faces added by tjunctions
---- MakeFaceEdges ----
----+----+
---- GrowRegions ----
Processing hull 1...
----+----+
----+----+
Processing hull 2...
--\
*** WARNING 08: Point (2784 288 -448) off plane by 5.5
*** WARNING 08: Point (2880 352 -448) off plane by 5.76
*** WARNING 08: Point (2880 352 -232) off plane by 5.76
*** WARNING 08: Point (2784 288 -232) off plane by 5.5
----+----+
----+----+
---- WriteBSPFile ----
9286 planes 185720
35774 vertexes 429288
14125 nodes 339000
606 texinfo 24240
27847 faces 556940
29655 clipnodes 237240
7559 leafs 211652
34463 marksurfaces 68926
129983 surfedges 519932
65861 edges 263444
78 textures 971076
lightdata 0
visdata 0
entdata 72388

10 warnings

Elapsed time : 5:02

Peak memory used : 33.4 MB

** Executing...
** Command: C:\Editing\Quake\tools\BENGT_~1\RVis224.exe
** Parameters: -fast "c:\editing\quake\maps\bastion3.bsp"

---- Vis 2.24 ---- Modified by Bengt Jardrup

File: c:\editing\quake\maps\bastion3.bsp
6110 portalleafs
19624 numportals
State file out of date, will be overwritten
fastvis = true

average leafs visible: 1387
max leafs visible: 4358 near (800 2176 1056)
visdatasize: 1556 kb compressed from 4558 kb

Elapsed time : 2:12

** Executing...
** Command: C:\Editing\Quake\tools\tyrlite\BEN_TY~1.EXE
** Parameters: -lit -nocount "c:\editing\quake\maps\bastion3.bsp"

----- TyrLite v0.94 -----
colored output format: lit
BSP is version 29
737 entities read, 406 are lights.

Lighting Completed.

lightdatasize: 830341
0 switchable light styles
Writing BSP version 29
************ ERROR ************
File read failure

========================================

does tyrlite have a problem with large maps? - it's at nearly 6000 brushes at the moment. bear in mind this has only just started happening, and the only notable thing i have done since it worked fine is add a few brushes here and there - nothing unusual. also, the bsp will become corrupt or something if tyrlite tries to light it, but if i do just a bsp+vis, without lite, the map loads fine in quake, (although obviously fullbright). tyrlite copes fine when i compile just sections of the map, which leads me to believe it's an issue with the size of the full map.

any help is massively appreciated.

-kinn 

it is sadly not possible to alter the sprite image scale in the standard engines, but most custom engines support the ".scale" field on sprites, which does exactly what you require. 

TyrLite 0.94 cannot handle the large fastvis data size (1.5 MB)that my RVis produces. Try updating to the latest 0.95 from http://www.planetquake.com/tyrann , I believe its vis/light capacity is raised.

Also, the fullvis data size will most likely shrink, but I can't see any reason not to update to 0.95 anyway.

Hmm, after checking the 0.95 source I see that its vis capacity is still only 1.5 MB so it probably won't help.

Maybe you'll have to use my Light tool during testing (fastvis) and TyrLite for the final (fullvis). My Light has not practical limit for vis data.

The fullvis will probably take a while ... 

Just run TyrLite before vis, then it won't see the large fastvis data. 

thanks aguirre, that has solved the problem. i am running light before vis now. the reason i am still using tyrlite 0.94 is because i modified the source code slightly to get better results from "delay 2" lights - i simply altered the attenuation formula so that it doesn't blow up to fullbright at the source. (in my version the light intensity at the source is now equal to the "light" value). i cannot open the tyrlite 0.95 source in VC++, so i am stuck with 0.94 at the moment. for those interested, i altered the "delay 2" attenuation formula by changing the following line in the scaledLight function:

(original tyrlite):
light->light / ((tmp * tmp) / 16384);

(kinn version):
light->light / (((tmp + 128) * (tmp + 128)) / 16384); 

I've been plagued by a "too many lightstyles on a face" warning, although the area in question contains only 3 switchable lights, and no other lightstyles are present. what exactly is the lightstyles limit? i thought it was 4? 

there's another, slightly more hacky way to get a higher resolution on sprites. Make a normal sprite at 1:1 scale that is the size you want the final sprite, in regular quake format. Then make .tga external replacements for each frame of the sprite, at the higher resolution. All implimentations of .tga I've seen scale them down to the size of the original, so if the .tga is higher resolution you get a higher res, more detailed sprite. It does require custom engines again, but I think the support for this extention is slightly wider than that of .scale, although I may be wrong on this. 

The lightstyle limit is 4 but the code in the light utils has always been a bit overcautious since it checks first if the lightstyles are too many, then if this style actually hits the face.

In TyrLite, there are some changes that should reduce this behaviour but it's still not quite right. I've made some additional changes in my Light tool that hopefully should fix the problem.

Also, note that switchable lights also have styles. 

Disregard last sentence. You could try running my Light to see if the same # warnings are printed. 

I faintly remember that map from The Pipeline.. looking forward to it :-) 

Xen - hehe, glad someone remembered it. here's a sneaky peek at the Bastion in its current state:

http://photopile.com/photos/sloochyslooch/auctions/112129.jpg

http://photopile.com/photos/sloochyslooch/auctions/112130.jpg

http://photopile.com/photos/sloochyslooch/auctions/112131.jpg

http://photopile.com/photos/sloochyslooch/auctions/112132.jpg

http://photopile.com/photos/sloochyslooch/auctions/112133.jpg

Hopefully not too long now :) 

aguirre, i'd like to use your light proggy - would you consider adding my "-kinn" attenuation formula as an option? i'm a bit reluctant to move on from my "hacked" version of tyr 0.94, simply because no other program does the same type of attenuation. 

...Q1 enemy, Q2 weapons and Q3 scale?

? 

I've completed the beta of my first full scale Quake1 map today, and, and, you make me want to go back to the drawingboard (or get out the rest of that bottle of Southern Comfort and simmer in my own chaote) That brushwork is really good.