I have a problem with the compiling of my map. It compiles without any errors, but when I launch Quake the map doesn't start. When I've removed all buttons from it the map started. Why does it happen? There were no problems with buttons before, but when the map became quite large (over 2200 brushes) the problems have suddenly appeared. 

pulsar, are there any error messages when you start quake? or is it just a black screen?

and is it only when you remove buttons, and nothing else? (doors maybe?)

check if you've got a funky string in one of your buttons. irrc, you can't use " in your strings... maybe others too... that could break the map... maybe... 

How many brushes define make up an average map? 

Around the 700 mark for DM and 2000+ for SP. There are exceptions of course e.g., coagula style levels. 

Rightly or wrongly, I assume you're talking about Q1. 

I don't know how 'define' got into that previous post. 

Having used this extensively necros it is possible to light a map solely with face lights. CRDM2 had 1 point light, and that was to generate the skylight, all the lighting in the map was done with surfacelights.

When using surface lights you gotta remember that the light is not shinning in all directions (aka a omni point light) but only in the direction the texture is facing. So having a room with loads of lights on the ceiling only will give you a bright floor but a very dark ceiling. The best way to avoid this is to have lights on the floor and ceiling, or bright lights on the walls, so that light is cast in all directions.

Remember also that surfacelights make the texture fullbright, so dont go making a 512x512 texture a surfacelight or is gonna stick out like a sore thumb.

Another thing, generally be generous with the amount of light coming off the textures, as they seem to be roughly half as bright as a omni point light. As a rough guide the little 32x32 light squares on the floors and ceilings in crdm2 had a brightness of 180.

Are you using the -bounce option? If un-specified at the command prompt light will bounce off surfaces and the map will be much brighter but at the expense of contrast, the map can look very washed out with light, its less apparent in a GL engine that supports colored lights (if your using colors) but load it in software and ouch :) For Quake I would use -bounce 0 as it produces the best overall effect ie. More contrast, but it does mean placing more light light emitting textures or making your tex lights brighter still...

Hope this helps. 

There were no error messages. My map sometimes even crashes the system when I try to launch it.
At first I decided that it happens because my very slow machine can't compile the big map right. The I've sent the map to my friend with fast system for compiling. The result was the same: the map haven't started.
The thing is that everything works right til one moment when it stops working without any reasons.
I've just added about 50 brushes (and no entities). All these brushes were normal (I tryied to avoid solids with strange form). The only idea was to remove some entities (that worked fine before). I started from removing buttons and it worked.

I'm very confused with it. Anybody help... 

maybe there are too many edicts? 

thanks for the info, duder. although, i started using q1rad primarily for the bouncing light effect...


-----------

next question: for those of you who take big performance hits when faced with flickering lights, is that a precompiled flickering light, or the light given off by rockets and explosions? 

One time I was making a Q2 map and had setup a func_areaportal with a func_door. I did something wrong (I don't remember what exactly it was) but whenever the door was opened the game would crash. Maybe you have a similar situation.

You said that you started to have the problem when the map became large, so maybe there was something you added recently that is causing this. 

I've built most of the structure of my map, and now I'm placing monsters. I placed a few grunts on the platform you start on, but they're pitch black. I even placed a 200 level light over each one and they remain pitch black. What does it take to light these suckers up? 

quake lights models by drawing a line straight down from each entity until it hits a world polygon. It then uses the brightness value from the lightmap on that polygon to determine how bright the model should be. If they are standing on a func_plat or something, then they will not be lit by the lightmap on that plat, but on the first non-entity poly below it. Which might be pitch black. 

Both. They're done the same way, unless you use gl_flashblend (which stops explosions/muzzleflashes from lighting the world). 

Thanks.

That's an odd scheme. Yes, my monsters are standing on a func_door and below that is sky. Are there any workarounds? 

Hey, I figured it out. Since the game won't light the sky I just made a room you can't get into under the map and lit it apropriatly.

I do see why they went with that scheme, it must be wicked fast to calculate. 

the reason they went with that scheme is that the alternative is calculating light values for empty space. They finally did do this, in the Quake 3 engine. (the "light grid")

It doesn't seem like a big problem (except for the extra disk space / memory use.) But, keep in mind that there really isn't much of a need for it in the original quake levels -- 99% of the time, monsters are standing on lightmapped world polys. 

damn... some people are gonna hate my map...

is it bad to have lights flicker at rates of 0.01? 

If you wish, you can send the zipped map+wad to me, I'll take a look and see what I can find out. 

Well, there's even less than a half of my map ready right now (cuz problems have started) but I may send it to you.
What's your e-mail? 

my forum account info in the People section here http://www.celephais.net/board/people.php .

Just de-obfuscate first ... 

your name in the "#1337 posted by aquiRe" also links directly to your user info page. 

he didn't seem aware of the People feature, I thought I should point it out explicitly. All is well now, I have received the map and will take a look at it. 

I found the reason for problems with func_trains (and any other bmodels) that move a long way.

Due to the way that the Quake network protocol works, entity co-ordinates wrap around at +/-4096. Now, because of the way qbsp works, every bmodel has it's origin at the centre of the map when in it's default position. Therefore, it can only more 4096 units in any direction before it's origin slips off the edge of the map and appears on the other side. At this point, the engine thinks that the model isn't visible, so it is culled.

I can make the problem go away by trading off one bit of precision on entity co-ordinates for a greater range of values, but this changes the network protocol, making netplay and demos incompatible with the original quake.

I suppose you could make qbsp translate the brushes to be centered around the origin before compiling each bmodel and then place the offset needed into it's origin key. Not sure how well that would work - you want to try it aguirRe? This would work around the problem in future maps, but existing maps are stuck with the problem. 

i thought the origin for a brushmodel was at the lower south-west corner of the bounding box? For func_trains to follow pathnodes, it seems that this is the case. But i haven't gone code diving, so this is just based on conjecture (and mapping experience.)