I just recalled that JoeQ has a custom filter mechanism; via cvars you can filter out gibs or corpses. I'd assume that if this was enabled, you might get less packet overflows in JoeQ.

Hmm, if I recall correctly, the filter was on the client side and packet overflows occur on the server side ... then maybe it doesn't make a difference after all in this case. 

any cd-ripping program will do, like eac (exactaudiocopy) for example. 

how do I trick the normal AI into believing that (eg.) a grate in the floor can be walked over by a monster? Can I do it when the grate is a func_wall? I tried a clip brush . . . 

If packet overflows are only occuring when you start gibbing things, there are a few easy changes you can make to the progs that will reduce the problem. One is just to reduce the lifetime of the gibs, probably look in ThrowGib to do that. You could also alter the monsters to spawn fewer gibs when they die, or set a higher threshold for gibbing so fewer of them do so. The latter solution is more work though, as you have to alter such settings on a per monster basis.

A more sofisticated method would be to have a cap on the number of gibs there can be in the level, say 20, and remove the oldest one each time a new gib needed to be spawned. This would also be a much more substantial coding effort.

ijed: You can try filling the gaps with "skip" brushes, search through this thread on google or something for some details on how to use them/where to get the skippy program from. The problem with this method is it makes the floor truely solid, so you can't fire through it/drop grenades down the gap. If the grate is quite fine, and you don't need anyone to fire through, you should be alright. But if that's gonna cause problems with the combat, then you may be stuck, I don't know of a real fix for that one. 

...I had a similar problem recently. I eventually populated that area with flying and jumping enemy (scrag and fiend) and that got around the problem to a degree. I contemplated a matrix of monster_jumps but because of the architecture it all looked too meh! If the path to travel is simple enough (single grate and only two directions to travel) the monster_jump might work without looking naff.

On another note, I was pleasantly surprised the other day to find that Death Knights and Knights can cross the continuous moving platforms in DM2 with relative ease. (The moving plats just around the corner from the lava trap room) How can they do this but baulk at some grates that the player has no trouble traversing?

Yes aguirRe I'll send you the .map if you want :) 

Last night I was doing some work on my D3 map and the computer froze up during a compile.

I waited a while in case it unfroze but that didn't happen so I had to hit the reset button.

The .map file was subsequently screwed, however I wasn't too worried as I simply went into the maps directory and pulled out the last .bak file.

It won't load. :(

Gives me this error when I try to load it into the editor:

"ERROR: file C:\Program Files\Doom 3\base\maps\abd3sp1\008_3_bak.map, line 45492: couldn't read expected floating point number"

At this point I start shivering uncontrollably. Due to foolishness on my part I have about two weeks worth of mapping unsaved since the last backup.

Basically, all I am asking is that if I get a text editor that shows you the line numbers, should I be able to simply delete the problamatic lines to get the map to load so I can salvage bits of it? 

After some digging around I found that a chunk of the .bak file is missing as well, a fair bit of geometry information and all the entity listings. Luckily, when I copied and pasted out a few random chunks of the geometry text into a new file I was able to rescue much of what I thought I had lost.

I will have to reinsert all the models and lighting for the newer areas, however that isn't much compared to having to rebuild it all. :) 

Thanks. Got them. 

Preach - I�ll give tyrann�s skip creating program a try - don�t need to shoot through the grate so this should be perfect.

Distrans - I reckon skip�s are the way to go cos I�m using custom monsters and haven�t made one yet that flies. Also, monster jumps will mean that the grate will be a 1 way area for monsters - and my grate�s in the centre of an open gallery type room. 

Can there be any connection between having too many func_walls in a level and packet overflows?

After I think about it, the packet overflow happens mostly after firing a weapon, even if all monsters are already dead. So there are no gibs flying around when the packet overflow occures (Preach sorry for misleading you). Only corpses and heads lying. The level doesn't have too many enemies (about 90 on hard skill), but the whole area could contain more than 1/3 of them.

Tried also standard winquake -> lots of packet overflow :(

JPL: I don't have any problems with entity count. Are you sure that using the spawning method you talk about can help with reducing packet overflow?

neg!ke: thanks for your input, probably I won't use it though :) 

Func_walls are brush entites and as such add to the packer overflow limit. If the overflow is constant in an area where nothing dynamic is happening, then you've too many entities in view (typically corpses + other ents like func_walls).

Delayed spawning may not help here if there are no more monsters alive, but corpse removal will help substantially.

If you haven't already, use the r_draworder 1 command in WinQuake to see what the engines renders atm. This will especially reveal the entities in view. 

Yes, CDA's progs.dat has been provided by aguirRe, and allow to make monsters appear, and then remove them when they die... As I understood, this is the "dynamic" entity count that generates packet overflow... As progs.dat It affect entity count, and also decrease what the engine have to render, it then avoid packet overflow if well used.. Ask aguirRe for further informations ;) 

Static entities won't ever cause apacket overflow, as once they are made static the server never updates them. So wall torches are fine, and if you can change any of the func_wall ents to func_illusionary ents then they will also not have an effect. However, by my testing a func_wall shouldn't really cause a packet overflow either.

As an experiment, try putting into seperate large boxmaps 100 knights, 100 func_walls and 100 torches. You should find that the knights cause packet overflows but that the other two don't. There's no simple relationship between number of entities and whether you will get packet overflows. Things like monsters, that will be animating, changing direction and making sounds almost every frame will send lots of messages from the server to the client. A func_wall does almost nothing all the time, and will only generate a message if you trigger it to change its texture or killtarget it.

From what I've heard, it sounds like corpse removal may help you out here. I can't quite explain why a corpse seems to count towards packet overflows while something like a rocket launcher doesn't...but removing the corpses is probably the best way it fix it. 

...will only generate a message if you trigger it to change its texture...

eh? run that one by me again? 

void() func_wall_use =
{ // change to alternate textures
self.frame = 1 - self.frame;
};


I've never actually seen this work, though... 

You need to use +0 and +a textures to make this work, i believe. 

tried it once, and yes, needs to be +0 and +a sequences. will swap between the two and animate them 

Will someone explain to me the logical reasoning why, when selecting a series of files in Windows, I must select the last file first in order to have the files be listed in sequential (alphabetic, numeric, etc) order? Shouldn't new selected files be appended to the end of the list? 

Because windows is a piece of shit.

I noticed that whatever order you select, one file is always out of order. This happens when enqueing files in winamp using the windows dialogue, and pisses me off quite a bit. Normally I get the first song at the end and the last song at the start. Maybe it doesn't happen in current versions, but it definitely used to happen. I blame Windows rather than Winamp.

Actually, someone did explain this to me once, but it was probably a really boring explanation, so I've forgotton now. 

I meant to post it in General Abuse since I was generally abusing Windows.

I can usually get around the selection problem, but sometimes it's difficult when I want to play some songs that start with my favorites and then transition into a certain mood or style. Having to think backwards about it can be difficult sometimes.

The only reason I can think of to do it this way is because by now it's a standard, and it's a standard because Windows made it a standard, and you have to stick with the standard because that's what people are used to, and you can't switch boats mid-stream, even if your boat is sinking and being overtaken by crocodiles and beetles, and about to go over a giant waterfall into a rocky pool where thousands of hungry cannibals are waiting on the shore eagerly anticipating the coming feast. 

I agree.

I also agree that where is SM69 for crying out loud? 

Sorry to keep posting about this here, but if something is badly designed/coded, then a well designed replacement will be easy for people to switch to if they give it half a chance. If Windows Vista fixes it (unlikely!) then I'm sure most people that notice will think, "Thank fuck, they finally fixed it." It's basically buggy behaviour - I'm sure nobody can be such a retard to actually design it that way. 

I agree.

I also agree that have you checked your pants lately? 

Since I am (still) working on a map using Quoth ents and textures, I thought I'd ask a couple of quick questions.

1. Are you guys still planning on releasing more content for Quoth

2. If so, do you reckon it will be ready before QExpo?

3. Is it possible for me to find out about the new content a little bit before release so that I can add any cool new stuff and fixes to my map before QExpo?

4. Do you think it is possible or desirable to increase the range from which the vore will throw fireballs? I find it occasionally annoying that they only have a range of a few hundred units or so.

By the way, my map is split into three large maps now, so I don't think I will have problems with precache models etc. I'm about 70-80% finished with the first map, and 0% on the other two, but I think I can do it before June/QExpo assuming that I don't have too much to do in my new job. 

1. Maybe
2. No
3. I dunno if you can afford our rates.
4. Well, currently all the original monsters have a max range at which they are capped at (1000 units) So they can still shoot when you are fairly far, but they have a low chance of doing so. This was probably made that way so you don't get ganked while fighting close monsters by the farther ones you can barely see.
I'm not sure if changing the firing chance at long range is really the solution.

seriously, about 1 & 3, i can't really say much on that because i haven't seen kell in a while so we haven't really discussed anything about quoth for some time now.
The only thing i'm certain of is that if there is more quoth stuff, it would definatly not be ready for the qexpo this year as there would likely be a lot of stuff, most of which hasn't even been started yet (or just briefly touched upon).