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. 

a general interest of having access to the old QMap "Mapping Help" thread dating from Jun 2000 to Oct 2002 ?

I have it archived in html format with graphics and could upload it to someone who'd like to host it (metlslime ?).

It's quite big and not in a nice format for the bandwidth limited, but maybe that could be fixed too ? 

Hmm, how many megs is it zipped? 

for a version that only has one html file for all three years (rather difficult for the browser to handle - sucks memory to no end). This variant is not very useful online but OK for a powerful computer offline.

I've also made a separate 3-part version that has one html file for each year which is easier to manage in the browser offline. It will still be difficult to use online, though.

The entire package of both versions is about 1.4 MB. 

Would be cool if you could send me those per mail. I think about putting all the posts into a database and quick code some stuff to search through all the data...