Pulsar: Clipnodes are simply clip surfaces. Each surface exposed to the inside of a level (not the void) clips the player (he can run into it, over it, etc). In DM maps, people often cover intricate areas (ruined bricks for example) with a wide brush with the clip texture. The clip texture makes a brush using it clip as normal (blocks the player that is), but is invisible in-game. If you're still confused, let me know (My latest maps all original have run over the clipnode limit). I owe aguirRe a lot for helping me out with this.

And, hey: does anyone want to do a bit of work for me modifying weapons models? I'd do it myself, but my qME must be an inferior version or something since all I can do is view, not change anything on the models or alter any animations (argh). 

If a bunch of brushes overlap without any space between them, that doesn't clip since the player can't go there. That's why clipping brushes lower the amount of clipnodes - a surface with 25 tiny little bricks all the same height on the ground, could be covered with one clip brush and would then clip as one brush rather than as the 5 sides exposed on each brick. 

Mail me what you want doing with those models. 

Hello, thanks to those who helped me for my "animated textures" problem yesterday.. Just another thing: when you apply texture to brush, it's possible to choose a scale factor to reduce/increase texture size.. I'm just looking for an easy way to choose this scale factor and anticipate the "game view" thet will performs. Is there someone who can give me some advices conerning this topic ??
Thanks 

don't play with scales too much, use default scale. otherwise the map might look crappy. personally i use slightly scaled textures on some faces that aren't texture size so i have to scale non-tiled texture a bit for it to fit. uder a bit i mean something likt 0.95 or 1.05 scale.
yet huge tex scale is useful when you make sky. it's good idea to use scale of sky texture something like 100. this will reduce polycount of sky surface. 

The default scale is set to 1 in QuArK6.4.0, and it seems to be a little big, because the map look crappy with this size... I mean the texture details are very visible without "putting your nose" on a brush (bit definition of the texture appears...) I made some try with 0.4 up to 0.5, and the map looks better (bit definition of the texture disappears even if you "put your nose" on the brush)... Perhaps the texture scaling is different from one tool to another one... I don't really know how to find an efficient turnaround of this little problem without making many try.. Is there a method, or anything else, that can show me what is the good scaling method (if I decide to change of mapping tool for example) ? 

try looking at the textures in start.bsp, you'll get the idea of default proper scaling... 

OK, there is no real method to anticipate the map looks like otherwise trying and compare the results with existent maps... It's also possible that it misses something else in my tool configuration... I will check this this evening
Thanx 

++++ERROR++++
numtexinfo=MAX_MAP_TEXINFO

where did I raise this bull? 

i'm not sure, but i think that's the error when you have too many textures (as in filesize) the limit is 2mb, so check to see if you are over it. 

MAX_MAP_MIPTEX (originally 2MB), which is the actual size of all textures in bsp. MadFox has hit another limit (originally 4096) which is the max # different texture info objects in bsp.

This number normally increases when you have many different textured faces in different positions/angles and it typically gets pretty high when using QuArK ETP or Hammer Valve 220 map format due to them capable of more complex texture positioning.

MadFox, I assume that you're still using the qbsp256 compiler and apparently it cannot cope with your current map requirements.

If you want to stick with that compiler, you must lower the texinfo requirements. See if you can change map format from QuArK ETP to Classic Quake in the configuration (I'm not sure you can do this in v4.07).

Otherwise you must use a newer compiler with a higher limit. Email me directly if you need more help regarding this issue. 

I lowered the polyhedron count.
I used 1244 polyhedrons, every brush more crashes the compiler.
So I stick to this limit by sharing out brushes and delete stairs etc.

I wish I understood that MipTex Acracadabra
but it is all right, nevermind.
As long as the map compiles. 

and I forgot to thank Tronyn for explanation, it was very useful 

that used to be 2 MB is only "limited" in one of my tools, TxQBSP (16 MB, which should be sufficient for a while ...). All other tools are "unlimited", i.e. theoretically 2 GB. 

Anyone interested in converting some Hexen II enemies to Quake? Specifically, I'm thinking the Hexen II mummy, which would fit in perfectly with the Night Journey's egyptian theme... I mean, uh, I'm not working on the Night Journey... uhm..

And, the Hexen II Skull Wizard would work well in the Arcane/Bookshelf project as well of course.

PuLSaR: No problem, glad to help. 

This issue came up some time ago, have you tried putting a delay 3 light with intensity 100 just above the lava surface as a spotlight, directed straight down and with a cone of 180 degrees?

If used with a slightly flickering style, it has an interesting glowing effect. This doesn't glow upwards of course, but maybe it could be combined with some other lights for better result? 

I have a strange error with QBSP during portalize process..

WARNING:CutNodePortal_r:new portal was clipped away

I currently use QuArK6.4.0, and the tool makes a "hole found in map" error (while hole checking doesn't find one !!!???)... The map is generated, but the PRT file required by VIS tool is not generated due to the portalize process problem.
Is there anyone who can tell me where to look for ??? Or if there is a turnaround to bypass the problem ???

Thanx 

at my Q1 ToolTips at http://user.tninet.se/~xir870k . 

Great !!! It solves the problem: TxQBSP found a misaligned texture... And QuArK locates the problem very easily...
Thanx !!
Bye... 

Is _sunlight affected by the number of sky brushes in use in a map: I am joining several maps where there are many sky brushes used to 'seal' the individual maps (some 30 individual brushes of varying dimensions). These end up in my new map in various height positions lelative to each other e.g. a sky brush may be placed at +1024 units and another at -1024 units, whereas they were create at +2048 and +3072 units.

I suppose I am asking whether or not _sunlight calculates its 'sunshine' from each sky brush and that if sky brushes are at differing heights, is the resulting 'sunshine' going to look different according to the distance between the sky and the ground. As it were... 

Having just hit Submit, I realise that I am probably asking this question of aguirRe more than anyone else. Still, others may be interested? 

of sky brushes are irrelevant. The basic thing that matters is if a certain face can "see" a sky brush, i.e. a straight line can be drawn between the face and any sky brush. This is all that is required for indirect sunlight (sunlight2, outdoor minlight) to hit the face.

For direct sunlight, the line must also have the right angle as specified in sunmangle. 

Got it, thanks. 

I'm looking for a skybox of empty space, nebulas, etc. If you know where I can get one, please help!

Cheers