But why not copy another weapon and rename it - they're all the same apart from name.

The Vermis is

(-64 -64 -448, 64 64 256)

with the 'bulb' being in the centre of that box. It's pretty good at clipping the player with its throw attack, so give it around 256 units in each direction to throw the player; or stick it in the middle of a pit.

Also try and make sure it clips as little as possible with the floor; there's a bug where it can throw the player through walls. 

Thanks :-) 

I got the following message while loading my map:

"Error: Too many static entites"

What am I suppose to remove from the map in order to solve it ?

Thanks in advance... 

torches/flames, illusionaries, globes/bubbles 

Thanks, I loaded the map with aguirRe's engine, and it shown that I exceeded by the limits by 3... I just made a test removing 4 lights: I hope it will work now ;)
In anyway, thanks for the reply: you rock ! 

If you want, you can quite easily modify the qc so that torches have a spawnflag for not being static entities, if you want those three torches back, and have the dynamic entities to spare. 

Bubbles are not static, I think. 

Even simpler: use the info_notnull modelindex hack for dynamic torch models along with three independent light entities. 

.. 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