And I think it is because the author did an -onlyents compile before release and didn't bother to check that half the map broke because of it. (messed up modelindexes, etc)

Anyway, playing that mod feels like getting cancer, AIDS and cerebral palsy at the same time, so I've only played it, like, thrice. 

referring to atfe2m2, which indeed has many model errors when re-lighting it (conflicts between the model and entity lumps, probably due to the -onlyents run or similar). That map actually works without any obvious problems.

The map I was referring to is the one after that, atfe2m3. I have no idea how it could be produced by mistake or corruption.

I've also mowed my way through Fantasy Quake and X-Men recently and there's a lot of unique and un-Quakey material in there. Must've been a lot of work creating it ... 

the atfe2m3 map again, I realize that you're probably right about the messed up entities. If I start to shuffle things around and change modelindexes, the brush ents suddenly start to make sense. Argh ... 

aguirRe can u explain how can i make this work...

http://trinca.no.sapo.pt/03.jpg

;(

Txqbsp.exe
and light.exe work fine but vis give me this error prt fucking file...can u please explain what does that mean? thks in advance! 

Obviously your map has a leak... Find it, fix it. 

Go into your Quake/tmpQuArK directory (or where the compiled map, etc.. are located... normaly the stuff should be there),
Remove all the files..
Relaunch TxQBSP only (from QuArK)
Launch Quake from QuArK
In quake console type pointfile
A doted white lined should appear: follow it and you will find the leak...

BTW, I'm very surprised that QuArK didn't show you the leak by a red arrow before !!

Hope it helps... 

sorry but what means leak :) something like a escape? hole? 

A leak is equivalent as a "hole" in map: if the map is not correctly sealed, you got a leak... So seal the map, and the issue is solved ;) 

this is basic mapping stuff, the manuals have stuff on it.
copy the .pts to the same dir as the .bsp (quark might do this automatically, wc does), load fitz and the map and type pointfile in console and it should show the leak. 

got it thanks guys :) and many thks to JPL that help me out in a hard thing last night ;) 

I didn't know about that "pointfile" command... Thanks!

and many thks to JPL that help me out in a hard thing last night ;)
Got trouble where only a french guy could help, eh? :D 

ehehe no,no at this point was the only one that help me out with no limits... :) vondur refuse to help me... but i kick his ass "sometimes" in dm�s :) to revenge! 

i can't remember the last time i had to use the pointfile - quest's leak detection is sweet. the other editors must have such a function, as well...? 

Racist ! ;P 

I am currenly working on a TDM map, which is a remake of my Q1SP map titled "Apinaraivo / Monkey Rage". I am looking for experienced Q1 TDM players to gather gameplay feedback on the map. If you would like to help, either post here or get in touch via email. 

...the trigger_teleport? when there are multiple teleports at once only one has tfog (or at least not all of them). when the silent flag is set at least one of them makes a sound and has tfog. this sucks.

...aguirre's qbsp? it enables transparent water and sky even if the -transwater and -transsky options are not used. 

use the other (tx vs tree) 

silent flags on teleporters doesn't affect the teleport affect at all, rather, it determines whether the ambient sound is played.

as for flashes not appearing when multiple teleports are in progress, that's an engine limitation. not enough particles to go around.

i think you can change that by adding -particles 50000 or something like that to the command line, but i don't really remember. 

TreeQBSP's default setting is non-transparent (opaque) liquids. If you're seeing something else in-game, the map is probably not vised or you're using a custom engine that disregards vis info.

Both Tx/Tree compilers can be set either way. 

ok, i already suspected the missing flashes to be an engine limitation. nevertheless multiple silent teleporters do make a sound.

my bad about the qbsp thing. i switched to txqbsp at some time (maybe because it has -oldaxis enabled by default = good) and forgot about it. -nowatervis is the key here. in treeqbsp water is indeed opaque without -transwater. the sky, however, is always transparent with both. 

transparent according to vis AFAIK. I don't even know what the -transsky option does. Again, what you might be seeing is probably engine related.

Some engines don't render animated sky leafs properly and others have issues with skyboxes, which is an old Q2 bug. 

transparent sky means that (the sky brush appears non-solid and) projectiles are removed upon touching it. this feature is always determined through qbsp - older versions always made the sky a solid surface (see id levels). so maybe the -transsky option is just a remainder of the time when it this feature was new and its usage had to be carefully considered by the mapper. i don't know... 

but then you're talking about different things. Transparent means you can see through it after vis is run, therefore the sky is always opaque. It's also solid in the sense that most entities collide with it, except e.g. rockets. Even grenades bounce off sky.

However, you're right about older qbsps not setting the CONTENTS_SKY attribute for sky leafs, thereby invalidating sunlight in newer light tools. In my Light you can workaround it by adding the -solidsky option.

And Tree's -transsky doesn't affect the CONTENTS_SKY attribute, I think it tries to set the sky leafs transparent (like liquids), but the engines don't care it seems.

You can however add the -solid qbsp option to remove all liquids and force sky to be "oldstyle" solid again. This can help loading some troublesome maps in normal engines and ease leak hunting. There's also the -noents option to remove all entities except world and players. 

If you load dm3 and noclip/spectate above the map, you can still see the megahealth hill from outside the map. Ie, the sky brushes behave just like solid walls in that they have no "other side" so they are transparent from outside. Same with all id stock maps.

This doesn't happen in ztndm3, the sky brushes block all visibility if you float out. That happens actually in ~any new map.

Why is this?

I'm sorry, I haven't tested at all if this is (vanilla/tx/tree) qbsp's or whatnot's fault (I still don't have net at my own comp and am lazy as hell)

I recently made this big spiral test map and had problems with sky textures causing lots of extra lightmaps and I'm now asking did id actually do stuff originally differently so that there weren't any new lightmaps, and if, why isn't it so anymore? 

as we said, the older qbsps treated sky brushes just like regular brushes, i.e. only the face on the inside is visible.
newer qbsps leave the entire sky brush intact and add the contents_sky attribute. it is then treated like a water brush in some way - at least this is what i think regarding the splash sound when grenades bounce off (...probably nonsense - should have waited for aguirre to anwer)
in fitzquake the sky brushes do not block visibility from the outside btw

aguirre: thanks for clarifying. it should be mentioned, however, that projectiles are removed at the back face of the sky brush (the one at the outside, so to speak). therefore, if the sky brush is not deep enough one can still see the impact of shells and nails. grenades bounce off at that face as well and when they pass the front face again there is the splash sound.

this also makes me wonder why the engine can't recognise a grenade touching a water volume just like that and no only after it has bounced off some wall (splash sound again), but i guess this has already been explained to death. ;)