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.) 

Thanks for the info, I'll think about it. I've only encountered this problem twice in a huge number of maps, so maybe it's not worth the effort. It's good to know why objects could disappear though. 

It behaves as though the origin is at the "mins" of the bmodel because the QC takes that into account. E.g.

setorigin(self, targ.origin - self.mins);

...and...

SUB_CalcMove(targ.origin - self.mins, self.speed, train_wait); 

ah, i see. 

H:\q1\maps>tyrlite -extra nesp09_q1
----- TyrLite v0.94 -----
extra sampling enabled
BSP is version 29
using minlight value 35 from worldspawn.
1487 entities read, 831 are lights.
WARNING: entity at (0, 0, 0) (trigger_once) has unmatched target
************ ERROR ************
GetFileSpace: overrun

cheked on quakelab, but there's no solution to that problem... help? 

max light data size (MAX_MAP_LIGHTING) which I believe is 1MB in TyrLite 0.94 if you don't use coloured lighting.

Either you'll need to change lighting in a way that you get below the limit or you'll need another light tool with higher limits.

Maybe Tyrann can fix it for you or suggest how to reduce the light data size. 

Use large texture scale (like 2) on some huge distant surfaces to save lightmap space. Should help 

to know how much i've gone over the limit?

this only happens in -extra, and i want to know if it's worthwile for me to go around fixing stuff or just release the map without -extra on light...

is there a way over the limit without changing the map? or is this one of those quake limits that can't be changed without altering the netcode... 

when it reaches the limit, so it can't tell you how much extra you'd require to finish.

As I said, if you don't want to change lighting, you'll need another light tool that has this (and other limits) raised. At http://user.tninet.se/~xir870k you'll find such a tool.

I also have an enhanced version of TyrLite 0.94 that among other things has this limit quadrupled (to 4MB). If you ask Tyrann, he can do the same fix to the official version.

AFAIK, the engines or netcode has no problems with having this limit raised. 

Yep, that's a bug in TyrLite. I meant it to allocate 4MB, but a logic error in LightWorld() screwed things up. I have a few minor changes queued up now, so v0.95 should be along soon. 

yeah try scaling up textures on large rocky walls etc like speed said, for one the lightmaps are smaller on them and 2, I actually think the walls look better with this done to them, makes the walls look huge and massive a bulky and oooooh u know craka!

I ate a fish.