What's the limit for engines nowadays? 

Personally I prefer the "fuck the limits" option and go for full bsp2 support. Quakespasm is my current favorite for this. Afaik it has no limitation on precaches. 

255 is the maximum that will work in all engines. Lots of leading engines do increase this limit, but because it requires a protocol change it's not trivial to do. This means lots of minor source ports don't have the feature. 

Hey guys,

New to this. I want to use the textures Sock used in his maps. His readme's state that these are modifications of the original textures. Is there such a thing as a Sock wad I can use?

Or do I have to go through all the bsp's, find the directories, filter the textures and somehow create my own wad?

Sorry if asked before. Did a bit of Googling but most things mentioned tools on how to make wads.

Regards,

Sprony 

the textures in his .pak files, you could get something like pak explorer to get the .wad files.
I believe you can also take textures directly from .bsp files using TexMex. 

At the bottom of THIS page is all the links you will need. TexMex will extract textures from BSP files and ADQ will open up PAK files. I do include all source materials with every release, map + wad file.

Once you have extracted all the wad files out of all the different pak files, just put them in the same directory as your map and add them to the wad line on your worldspawn.

Eg - "wad" "common.wad;animated.wad;liquid.wad;zendar.wad" 

Thank you! 

Since I am already taking the ijed approach with respect to map size, I will ijed my precaches too.

Thanks for the tip.

P.S. 255!! Thats pathetic!! 

whether all engines support "alpha" property for the entity? 

99% of them do (100%?) 

I decided to give Trenchbroom a try. It works great. However, I'm wondering if my directory setup is correct because there are so many programs out there.

In my regular Quake folder I got a 'Id1' folder. In there I made a 'textures' folder containing several wads. I also got a 'maps' folder. I added a 'utils' folder as well but when using 'ne_q1spCompilingGui' it needs all my compilers in one folder. So I also made a 'compilers' folder.

The whole compiling story is not clear to me. I've downloaded TYRUTILS and the files by Bengt Jardrup. I'm not sure what the difference is. Also, all compilers come with several files but it seems you only need the .exe's in order for it to work?

Bengt Jardrup also has convmap.exe. Is this the aquirre converter I see mentioned several times? I have to learn Trenchbroom better so I want to make the more complex brushwork in GtkRadiant 1.4 and convert that to Quake. According to the explanation I read I need to make an 'output' and 'workingfolder' directories inside the 'Id1' directory. This doesn't seem to work so I probably misunderstood that.

Any insight into the correct setup would be great. I read the Quake Wiki and I've found useful information using Google as well, but never the complete picture so that's explains the questions above. 

You really only need a the vis, light and bsp .exe files. The other files are probably readmes and source files (for budding programmers).

I just store everything in my trenchbroom folder for mapping, texture wads, compilers and .map files. When you create the .bsp file all your textures are compiled into it so these aren't required to go into your quake directory. (plus it makes your quake directory cleaner).
As for Trenchbroom, I store it inside my drop box folder so that my work is always always always backed up. 

the output folder is the one where you are putting your maps to run.

so if you are making a normal map, the output folder should be /quake/id1/maps

the working folder can be anywhere. this is where the .map file is copied from it's original spot, and then compiled (the compilation process creates a bunch of files that are mainly needed only during compile time).
after the compile is done, the .bsp produced is put in the output folder. 

I was mapping with the extras mod with the func_water lifting.
Now I'm breaking up with the thing called z-buffering.
It means that func_water brush expands out of it size.
So a space left out still gets troubled with the greyness of the func_water.

Is there a solution to this? 

only way is to make two separate water brushes. 

the left one is rectangle, the front one square.
It is the outgreying part where no brush is. 

try using my newskip tool, it has a *waterskip texture you can add to the sides of the water brushes. 

first, do what necros said. Then, use *waterskip on the internal faces of the water brushes. So when inside the square, you can see into the rectangle. 

The volumes will be correct (but can only be rectangles, like triggers) but internal faces you have to cull by hand.

So, uh, what Metl and Necros said... 

To my astonishment breaking both func_water funcions in two separate ones clears out the greying.

Another thing I learned is that a very thin brush above the big one conceals the visible watersurface.

Just trying to change e1m3 with a changeable water level, but the z-buffering wrecked the view in other places.

Skipping tool can work as the sides of the brushes are still breaking up. 

Thanks guys! So it doesn't matter whether I use Tyrutils or Bengt Jardrup his stuff? It just basically a matter of preference?

Convmap from Bengt Jardrup is actually Aguirre's convmap tool? 

Convmap from Bengt Jardrup is actually Aguirre's convmap tool?

I guess you could say that. 

What Mr Useless is not saying is that aguirRe is Bengt Jardrup's nickname. I would recommend using Tyrann's tools as they are actively developed, fast and have great features. Check out http://www.celephais.net/board/view_thread.php?id=60967 

Which compiler you use depends on what features the compiler has. I tend to use Tyr's BSP most of the time and I revert to Bengt's Treeqbsp tool when my geometry microleaks (it rounds vertices to less decimal places, plus I can never get the portal file to work with Tyr's utility). 

Have detail brushes and a load of other handy features.

Detail brushes make your vis time reasonable - recently I heard a case of a map taking half a day reduced to >2 hours by application of detail brushes.