In some maps I get a peculiar FQ message "Backup past 0" when moving in certain areas, what does it mean? 

that QuakeI doesn't support multitextures on single brushes. Never thought it to be a big deal nor necessary though UnReal based games do (Dues Ex, yummmm) support it. And then, just a moment ago I was fiddling around with a decompiled version of Mr Elusive's Start map for Tale of Abbot's Rune, trying to figure out how he set up those staged combats, and I stumble upon this,

{ //brush 2
( -832 8192 8192 ) ( -832 -8192 8192 ) ( -832 8192 -8192 ) sky4 0 -32 0 1 1
( -808 -8192 8192 ) ( -808 8192 8192 ) ( -808 8192 -8192 ) sky4 -40 -32 180 1 1
( 8192 928 8192 ) ( -8192 928 8192 ) ( -8192 928 -8192 ) sky4 -40 -32 0 1 1
( 8192 -8192 32 ) ( 8192 8192 32 ) ( -8192 -8192 32 ) sky4 -40 0 0 1 1
( 8192 8192 64 ) ( 8192 -8192 64 ) ( -8192 -8192 64 ) sky4 -40 0 0 1 1
( -7406 3522 8192 ) ( 7703 -2813 8192 ) ( -7406 3522 -8192 ) sky4 -40 -32 0 1 1
( -4340 7059 8108 ) ( 2034 -8033 8108 ) ( -2856 7686 -8196 ) rock5_2 0 -32 0 1 1
}

And my faith in the sigularity of Quake surfacing is shattered into a million atoms.

I tested this out with an attempt of my own.

// brush 6
{
( 64 256 0 ) ( 64 240 0 ) ( 64 240 -48 ) wiz1_2 0 0 0 0.500000 0.500000
( 128 256 0 ) ( 64 256 0 ) ( 64 256 -48 ) wiz1_1 0 0 0 0.500000 0.500000
( 128 240 0 ) ( 128 256 0 ) ( 128 256 -48 ) wiz1_2 0 0 0 0.500000 0.500000
( 64 192 0 ) ( 128 192 0 ) ( 128 192 -48 ) wiz1_1 0 0 0 0.500000 0.500000
( 64 240 0 ) ( 64 256 0 ) ( 128 256 0 ) wiz1_2 0 0 0 0.500000 0.500000
( 128 256 -48 ) ( 64 256 -48 ) ( 64 240 -48 ) wiz1_1 0 0 0 0.500000 0.500000
}
// brush 7
{
( -64 64 0 ) ( -64 0 0 ) ( -64 0 -48 ) wizmet1_2 0 0 0 0.500000 0.500000
( 0 64 0 ) ( -64 64 0 ) ( -64 64 -48 ) wizmet1_1 0 0 0 0.500000 0.500000
( 0 0 0 ) ( 0 64 0 ) ( 0 64 -48 ) wizmet1_2 0 0 0 0.500000 0.500000
( -64 0 0 ) ( 0 0 0 ) ( 0 0 -48 ) wizmet1_1 0 0 0 0.500000 0.500000
( -64 0 0 ) ( -64 64 0 ) ( 0 64 0 ) wizmet1_2 0 0 0 0.500000 0.500000
( 0 64 -48 ) ( -64 64 -48 ) ( -64 0 -48 ) wizmet1_1 0 0 0 0.500000 0.500000
}
}
And the compiled version did as I expected, no surface textures for the offending sides. So I have come to one canonical conclusion. If you are Mr Elusive, the rule do not apply. 

The decompilation is a faithful reproduction of the QBSP file (I use the Q3 BSPC-GUI for Windows 95/NT which never adds much glut when I decompile my own maps) and not of the map. So the liberties taken are in the compilation process. Whew, my faith is restored unless someone has more to add, 

don't look nice in msgboard format ...

Anyway, having different textures on a brush is absolutely no problem for Q1. As long as they're of the same type (solid/sky/liquid), they won't disappear or otherwise act strangely.

However, if they're of different type (like your example above with sky4 and rock5_2), you might get weird behaviour in the engine. This is probably a bspc (the decompiler) bug that normally needs to be fixed manually.

If you check out my ConvMap tool, you'll find a fixup mode that will help compensating for this bug. 

Good to know and I'll definitely check your tools out. Could the problem with my own attempt be the result of keeping the Q3 .500000 scaling? Perhaps, this is why I have had this misconception for some time. 

However, if they're of different type (like your example above with sky4 and rock5_2), you might get weird behaviour in the engine.

I had a map where I used a lot of brushes with solid and sky textures on them. There wasn't any problem with engine (even with dosquake). Only rockets couldn't pass through such sky textures, they acted like solid textures.

I hope you understand what I tried to explain :) 

to get a liquid brush with solid textures... i'm not quite sure how to do it, but i think as long as the last texture on the brush in the .map file is a liquid, the bsp program will treat it as a liquid of that type.

i was experimenting with this in my most recent map, and i might go for it with an animated texture. the only downside (but this could also be a plus) is that the unliquid textures of the liquid brush are not fullbright, so you need to light them as normal. 

I always knew it was possible in Q2 (with the edition of the surface inspector) and Q3, but I assumed the problems I've run into with Q1 multisurfacing was inherent in the engine. 

@R.P.G. & FaTbOy!: thank you for your feedback. It looks like the latest version of GTKRad-classic hates my system - I tried with version 1.3.13 and it seems to be working well. I've also mailed SleepwalkR and hopefully he'll fix the links, because id's base1 source isn't exactly what I was expecting in terms of build quality. Or am I missing something?

1. Is it worthless to clip brushes that are sticking out of playable area? I mean, doesn't this have a bad effect on performance?

2. I heard sky texture can be used in similar way as caulk in Quake 3. Is this true?

3. Should I care about aligning brushes so they fit perfectly like one should do when making Q3 maps? Is there any big difference between Q2 and Q3-mapping in this aspect?

4. Are there any differences between Q2's and Q3's hint brushes? 

anyone who watched the demo i recorded of xen's latest speedmap will see i had a lot of trouble getting onto the one func_plat in his map.

the way quake works for the func_plat, is it takes the largest coordinates of the brush and makes a cubic trigger roughly the same size of those coordinates. the reason i had trouble getting onto the plat was because the trigger is square while the brush itself was a triangle, thus, the plat was getting triggered too early before i could get onto the plat.

if you plan to do something like that, you should instead use a func_door and make the trigger yourself so you can control the size of it manually. or make a square lift.

cheers!

this small bit of info brought to you by necros... 

1. Clip brushes have no effect on proformance, they only serve to smooth out areas that may be rough navigating.

2. I suppose it could be... but I'd think it'd be better to use some standard textures and apply 'solid' content and 'nodraw' surface properties.

3. You should always align brushes neatly, yes. This applys for all Quake engines, there is very little differance between them in terms of how your brushes are split up in BSP.

4. There's a few differances I believe, http://test.gamedesign.net/book/view/52 shows their use in Q2.


and no, you're not missing anything looking at id's q1 released sources... they really are that bad of mappers... :D 

Looking at the source, that's coming from the function that does line traces through bsps. The comment nearby says "shouldn't really happen, but does occasionally." It's also a dprint.

From my quick glance at the code it appears to mean that a trace impacted a wall just behind the start of the trace. In other words, the distance to impact was slightly negative. 

info, it usually happens in areas with complex brush shapes.

Another question: If I noclip through a map, why does sometimes something push me up very high as if there was a trigger_push (there isn't)? It's repeatable and very annoying if I try to inspect an area of the map.

It's happened in several engines and it's really weird. 

Ahh.. thanks for the tip :)

Thought I could solve it by sticking the button there but it didn't work.. ah well

aguire I've noticed that too.. usually happens above lava, or at least liquids, i've found 

I think that's quake's "jump up out of liquids" code giving you a bump. But, since there's no gravity, you'll coast upwards forever. 

that connection with liquids, but next time I'll look for nearby liquid. My suspicion was that it had something to do with odd-angled brushes (or rather, planes), it think I recall it happening just outside tunnels (in the void).

It also doesn't push forever, it just keeps pushing until it thinks I'm high enough and then my pushing down suddenly starts working again. Hopeless fight though ...

There's also that weird phenomenon when in fly mode, suddenly moving speed gets extremely slow (inside map of course). Normally I have to leave fly mode and then back again to regain normal speed. 

A while back there was a thread here arguing which texture set was better Runic or Base. Ever since then I have been pondering building a ctf/tf map in which the two sides can battle it out. The textures would be original Id with the possible inclusion of some from rogue and hipnotic. I am not sure the bases would be identical for each side, might be interesting to mix it up.

I know most people here are DM or SP players but I thought it might be worth running by everyone. So...what do yall think? 

I'd like to see it. 

Would be funny 

before i go over that 255 entity limit... :P

what exactly counts as an entity? (not talking about edicts here)

i know that:
-each type of monster (if used) will count as one (so either 1 or 100 shamblers count as one)
-each func_ (other whatever bmodel) counts as one (unlike monsters, each iteration counts as one)
-echo misc item counts as one (like monsters) (includes weapons, ammo, health, etc...)

is there anything i'm missing, or do i have some of those wrong? 

i wrote echo instead of each. too much batch file writing i guess. 

have you checked my archived QMap thread? I think there are some explanations of this issue there. 

but ie keeps crashing when it loads the page. actually, ie crashes whenever i load a big page... it will crash if i opened up the GA thread from post 0... 

there are also three smaller pages, one for each year. That's what they're for. My old system also crashed the first time I loaded the whole thread. 

�