I was agreeing - it's a misconception - 'everyone' 

since these limits were put in place for PC's made ten years ago.

i had a question about that, actually.

iD had self imposed limits on maps (like total texture size), so why did they also have engine limits? if they had made quake to have a max of 5 billion edicts, but only used max 256, would it have mattered? is there some actual programming reason behind it, or was it an arbitrary choice? 

if you use linux you are a pederast 

Small number ranges require less memory. In particular, integers in the range 0..256 will fit in C's unsigned char type, which takes up less memory than short/int/long integer types (on most machines).

If you only have a few megabytes in which to fit everything, cramming numbers into these tiny ranges becomes crucial. For another example, see Quake's wobbly animations - you can clearly see vertices snapping from one value to the next. 

iD had self imposed limits on maps (like total texture size), so why did they also have engine limits? if they had made quake to have a max of 5 billion edicts, but only used max 256, would it have mattered? is there some actual programming reason behind it, or was it an arbitrary choice?

Mainly becuase it's a lot easier to write data handling code if you can assume a fixed limit than if you have to dynamically allocate memory for everything. A lot of stuff in quake is allocated in fixed buffers.

Other limits are imposed by the network protocol, for example 256 models means that you can use a single byte to index them.

And then, some limits are a combination. For example, MAX_EDICTS was 600 in standard quake, and this was becuase all edicts were in a static-sized buffer in memory. Edicts actually take a lot of memory per edict, and quake was designed to run in 8mb of RAM, so this is understandable. Also, looking at the size of the standard id maps, 600 is plenty. But when I added the max_edicts variable in fitzquake, I still had to set a hard limit of 8192, becuase the network protocol imposed its own restrictions on this number (which I can't recall at the moment, but I think has to do with the other bits being used for something else.) 

 

So, i've been using tyrann's skip tool recently, and it's worked fine, and suddenly in the most recent versions of my map (after merging in a couple new rooms from another .map) it stopped working correctly. Now what it does is remove hundreds of random non-skip surfaces from all over the level.

Has anyone else had similar problems? 

Yes, it doesn't work very well on big maps actually... I experimented the same fucking behaviour on SRC when I tried to add glasses... 

I've had the same thing, Tyrann always said it really did that after a while. =\ 

... is not top priority actually... ;P 

I sat down tonight and wrote a new skip removal tool from scratch, which seems to work correctly with my problem map. Only thing it doesn't do right now is remove skip faces from brush entities (did the Tyrann's tool do that?)

Still got to give props to Tyrann for the proof of concept though; I wouldn't have been able to code this so fast if I didn't have a basic idea of how his tool worked. 

The Tyrann skip tool certainly removed faces from brush entities. I can't say for sure if it never caused problems, but I've certainly made a few maps and encountered no problems with this aspect of it. It's very good news that we've got a tool that works for the world model though. 

and it causes a HOM in GL engines. And I have plans for this feature. 

and it causes a HOM in GL engines. And I have plans for this feature.

what makes neg|ke the awesome-est. I would never think of HOM as a feature. 

well, i'll see about adding brush entity support tonight, and generally clean it up so other people can use it.

Oh, and I still have to test it in various engines, since the basis of the tool is a hack that works only because of the way quake renders bsp models. 

he's a hom-osexual 

Going to beat off in front of those mirrors over and over again. 

and it causes a HOM in GL engines. And I have plans for this feature.

Will these plans be ruined if I play with gl_clear 1? 

PLEASE add support for liquid brush types! I need that for my basemap which is having a few problems with Tyrann's tool, but I can't have glass+water if I don't use a skip removal tool. 

right, i forgot about that. So we want removal of *skip as well as skip, basically? 

actually I guess i'd need:

*waterskip
*slimeskip
*lavaskip
*skip

for all three contents types, plus *skip when you don't want the water ambient sound. 

To make ambient sounds disappear ingame, just use aguirRe's vis tool: there are -noambient<lava/water/slime/sky> option that allow to remove them, check http://user.tninet.se/~xir870k/readmevis.txt .. It has been added since rvis 2.30 ;) 

i meant removing ambient sound for certain brushfaces, not the entire map. 

Not necessarily. Since I use gl_clear myself, I will keep that in mind - some trigger_command trickery will probably do the job. Furthermore, software engines might be driven out by clever use of the limits. 

I added entity support and liquid support last night.