.. it's not my cup of tea... and maybe I will have to split the map in order to avoid such problems... I'll see...
Anyway, thanks a lot for helping ;) 

what advantage does an entity actually gain from being static?

i've had the problem before and have noticed the 'makestatic' function in qc.. thinking how simple it would be to remove it altogether. but would that cause problems further down the line? 

They don't ever get sent over the network once the client receives them, which saves bandwidth and protects a little from packet overflow, although since the entities don't change it's not much good. The main advantage is that it saves you a conventional entity slot, and there are only 600 of them. 

Well, the whole thing is academic, since these limits were put in place for PC's made ten years ago.

It's why I prefer to work in AguirRe's engines. 

Windows was put in place for PCs made 10 years ago :-D

It's not good if OS-specific code is introduced into originally multiplatform software, or if projects (including their dependencies) depend on specific OSs. Windows development environments seem to have a tendency to automatically introduce Windows dependencies in the code...

I don't think that is an academic question at all because you can't assume that everybody on the globe uses Windows in the year 2007.

Platform independency == User friendliness! 

Fair enough, I suppose its far from academic if you can't run the stuff yourself.

I've always used windows (Mac a few times) mainly because it's what everyone else has ie. few compatability problems. 

"everybody else has (Windows)"

see? that's the problem. Once someone else is using Linux, you've got a huge compatibility problem.

It's not a law of nature that the Linux user accepts your proprietary .doc files for example. Unix has been around longer than Windows, so I could very well tell Windows users to "read the f* manpage."

I'm really not trying to start an argument, just pointing out that that ("everybody uses Windows") is subjective perception. That was a practical argument in 1998 in most of the USA and western Europe, but it isn't anymore.

I'm not "nobody."

Just the same you could say "everybody has 3D hardware and a recent computer, so we should get rid of software rendering" or "everybody has DSL so we should make Quake demos AVI format."

Same thing; I could imagine a dozen cases where someone has good reasons for not meeting those criteria.

:-) The world is bigger you know. 

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?