Most engines will choke very easily, as your small map clearly demonstrates.

To my surprise, I was not able to provoke any "Packet overflow" messages in Proquake 350 software (!) with Msd's map.

The map was fully playable, the lag was almost unnoticeable. And I have a stone-age system.

It answers my own question I asked earlier: it is very much possible to have lots of enemies onscreen at the same time. Enemy count alone seems to be no problem.

I myself intend to use about 100 Knights. That should be no problem because they only have a melee attack. Right? No particles or projectiles or dynamic lights.

What is the hard-coded limit for this? There must be one. 

hard enough, try throwing a quad grenade in there and see what happens ...

Visible monster count is most definitely a problem, try out my lr/lrb maps that I posted earlier on shub-hub. Even if the monsters haven't seen you or do anything except standing idle, most engines will choke completely on that (if they can even load the map at all, try Easy skill on the smaller map).

Knights are easier as they don't produce new edicts like e.g. HKs or Ogres do.

There are many hardcoded engine limits, some of them don't translate very well to an easy explanation. 

specifically with the last combat, I said I stopped there. I saw the giant doom-style pile of ammo and was a little war-weary by then so I saved and quit.

thanks for the protip. 

i think he was telling golden_boy that he wasn't trying hard enough to generate a packet overflow. 

I was being stupid, should have thought of explosives. Hm. There will be a way though. Who says the player will *fight* them. 

...I'm dabbling in Quoth at the moment, thought I'd better release at least one Quoth map before the update. Anyhoo, when I was placing ammunition and health whilst building Travail, it went/appeared where I damn well put it. This is far from the case with this level build. There is a huge difference between placement in editor and in game, this despite the size/entities definitions being the same for both the Travail and Quoth .fgd file.

aguirRe?...anyone? 

/*QUAKED item_cells (0.0 0.5 0.8) (0 0 0) (32 32 32)
/*QUAKED item_health (0.3 0.3 1.0) (0 0 0) (32 32 32
/*QUAKED item_rockets (0.0 0.5 0.8) (0 0 0) (32 32 32)
/*QUAKED item_shells (0.0 0.5 0.8) (0 0 0) (32 32 32)
/*QUAKED item_spikes (0.0 0.5 0.8) (0 0 0) (32 32 32) 

sorry aguire, that was a totally different thread I thought I was posting in

hee! :( 

Did someone indicate a few weeks ago that it's possible to build Quake maps with Hammer if one happens to be sick and tired of Worldcraft? If so, are there any instructions available on how to set things up, and what possible downsides should I expect? 

Try BspEditor 

Everything you need is on this page: http://www.quakeone.com/qadapter/ 

http://www.quakeone.com/navigator/

go to developer/Map Editors

I prefer QuArK 

I should have explained: my map was saved and compiled just at the point where the packet overflow was becoming acceptable. If you throw the grenades then the packet overflows start a bit because the backpacks drop, which push the poly count over its limits, I think, or it's the gibs. Anyway, I originally had a much taller tower with about four times as many enemies, heh. I just wanted to make a level that had a horrendous amount of gibs going on. 

Are there any limits to what shape a func_door can be?

I have a door which is a 7 sided semi-circle, 8 units wide, (152*76*<128 vertical>) and its supposed to move up into another similar shaped slightly wider brush, but it behaves strangely in that it doesnt trigger even though theres no targetname.

Any clues? 

I came to an even more dire problem with another map I was making -- I tried putting some enemies inside a box of explosive boxes (so that the explosive boxes surrounded in the enemies in a box-like shape, that is), which I thought would be fun to blow up, but Quake only handles about four or five of those boxes and a few enemies in the same room before it crashes -- you're just supposed to use one or two at a time. The barrels in Doom were definitely more fun! 

The exploding box idea is pretty weird =) There used to be this game "C-Dogs" (a top-down 2d shooter) which had some levels with explosives lined around all walls. The trick was to not die (there would be chain reactions etc). I remember it to be really, really funny. It's sad that this would not be possible in Quake then... it was one of the ideas on my mental list.

The mass enemy idea I have is to just spawn in something that looks like an army (Knights are fine) and having the player feel like he's getting totally swarmed. He would not have to fight them though, they would be some distance away. So no chance of gibs etc. occurring. Perhaps some hack to take away his weapons, to make sure... it would be just before the end of the level.

There is an older speedmap (Doom theme?) which has quite a lot of different enemies at the same time (like 30, and then another 30). It was fun and I don't remember packet overflows... although there were ogres , hellknights and vores involved... I'll see if I can find which it was, I'd like to play it again. You get a bunch of weapons at the start (Doom style) and then chaos... 

You could put a transparent "glass" between the monsters and the player. 

Too many explosions at once crash the game because all the particles exceed the active edicts limit, I think. Only limit-removing engines can help here. 

No, it's because of a QC bug that too many of them won't work together; they'll cause a stack overflow in most engines.

This bug and too many others to mention are fixed e.g. in the Warp or Travail progs. With one of them, you should be able to have more boxes (and spawns) without stack overflow.

And particles are not edicts, usually they're controlled engine-side with the -particles option. Having many particles will cause a slowdown in most engines, though.

And poly count doesn't affect packet overflows either, the former is entirely client side and the latter is mostly server side. Gibs (ot other edicts) will definitely increase the risk for overflow, though. 

Weird thing is I have a func_door elevator with loads of brushes, (all 90 degree angles tho) nearby which works fine.

No clues? 

It's not too clear what your problem is, but AFAIK the size or shape of a door affects its function in no way at all, unless you're talking about the lip value.

Doors trigger when a player or monster moves with 64 (?) units or so, if it has a targetname and is next to another door then both need to have their 'door don't link' flag checked in order to work. 

You could put a transparent "glass" between the monsters and the player.

Yep... or I might find a clever way to end the level, and then just have the army shown by the intermission cam. Something like that.

:-) 

Was hoping to find some decent mapping tool that I could use in Linux, as I've been slowly transferring over to using Ubuntu full-time :) Any suggestions are welcome! 

GTKRadiant is probably your best bet for linux mapping. 

...I won't blame WC1.6, as I pointed out the size/entity definitions for the ammo and health are exactly the same in both .fgd files. Yet I can place with pin point accuracy in Travail and by pure guess in Quoth. Any other ideas?