Count *is* at 2. 

What can I use as a barrier that will allow monsters through but block players 

Never mind. Opened mouth without engaging brain. Got it sorted now.

(took me longer to ask the question than find the answer) 

have you checked what you are targetting with the trigger_counter? maybe the triggered entity is broke? 

OK, I know what the implications are but what about if I remove 'makestatic (self);' from a couple of the lighting models? I have done this on several of them and my Too Many Ents crash goes away and the map seems to run normally.

But what effect am I having on other things i.e. why do some of the lighting models have this entry anyway? e.g. large flames, small flames, wall torches etc 

i think one of the reasons is to reduce internet traffic when your playing net games. i think the makestatic tells the server to completly ignore that entity and never send it to any clients and let the clients handle it.

also, if you remove it, that makes that entity take up an edict. remember you have a 600 edict limit to work with, so be mindful of that. if your map is small, and only for SP, than you could probably get away with it. 

... what's the trick to pulling down a file from the old ftp.cdrom.com? 

It's like that site doesn't exist anymore. I've had much luck usually at some .SE site though, like sunset or sun something... 

... there's some trick of replacing part of the url that makes the files accessible, I just can't remember what it is. 

ftp://ftp.sunet.se/pub/pc/games/idgames2/ 

This might be nothing new to some of the editing veterans on the board who may have encountered this, but it caught me off guard a bit.

http://blitz.circa1984.com/curves.gif

I was messing around with some "hand made" (everything aligns on a 4 unit grid) curves, when I noticed a) the void sparklies in the 3D window b) the fact that when I zoomed all the way in on the XY view, none of the brushes actually aligned properly!

So, I dragged up the outside "circle" of it as a wall to seal it off, and copy+pasted the floor for the ceiling to test if dmap would leak if they were sealing brushes, and as I thought, it [i]didn't[/i] leak. In addition, the "sparklies" were not visible in the map.

My question is, why does D3edit render them as not joining together correctly? 

Well, AFAK when you make a copy paste of a brush, and then rotates it, the coordinates floating part of each points sometimes are not aligned on grid anymore, and then zooming closely, you will find a "hole" at the joining faces... o_O ...
I had the same disappointing effect in QuArK, just try to force to grid each points, it would be enough to solve the issue in the editor at least... 

I did the same exact method in GTKRadiant and when zoomed into the max, everything still lines up, and it doesn't have the "sparkly" effect in the 3d window either.

So it's something with D3edit I think... 

but I guess
1) the 3d renderer just isn't so precise in that.
2) The compiler must be.
3) the engine has the benefit of using the compiled maps where these surfaces probably share coordinates/vertices (they were combined in the compile phase)

?)But somebody (aguirre?) said earlier that in q1 at least, faces are at some point stored as not vertices but as planes with a surface normal somehow and then if you have very small slope adjustments in small grid (like say, a 1001 in 1002 units slope, 44.999 deg) then it can get fucked (because it gets stored as 1001/1001, 45.000 deg), and that's why you should stick to big grids in non-perpendicular architechture. 

yeah, i see that in d3edit often too. i think it has to do with the dynamic light stuff, because when it's off, the sparklies go away.

i just tend to ignore any problems until they start showing up in the game. :P 

Did you get my email reply to your hull 2 leak issue? I've sent it three times now. 

Thanks heaps! That is exactly what I needed. 

...received at both latrobe and gmail, thankyou. I'm trying some of your suggestions (and some from Jack). I'll get back once I've definitively succeeded or failed. 

Do you know why having a Q1 entity selecting its mdl by random in the spawn function will cause later reloaded savegames to mix up the models in-game? Typical symptoms are monsters replaced by ammo boxes or similar. The mixed up models is a problem that has occurred in several paks (e.g. SoE), but I've never quite understood why it happens.

I've now an old pak (After The Fall) that has this problem immediately in the first map after reloading a savegame. There are some func_rock entities that can have one of two mdls, selected in the spawn function by the random() built-in. If I replace this logic with one that will always select the same mdl for this particular entity (based on its origin key), the messed up models problem seems to disappear.

I've added warnings for this issue in the engine loadgame function to make it more obvious when it happens, but I still don't understand exactly why it occurs. I suspect it's related to the engine model lists (precached or otherwise) that go out of sync with the edict order in the savegame file, but I haven't been able to pinpoint it.

Any ideas? 

The list of models is built in the order they get precached, and I'm guessing that these models will get precached in a random order depending on which one gets generated first in the map. Is it possible that when the map gets reloaded both get precached at once? this would bump any model that's precached between the first rock and the second one model up. This bug more frequently occurs(rather understandably) when you use a new patch for mod with an old save game, and the patch adds things to the precache list.

One thing you might want to test is precaching both rock models in worldspawn, regardless of whether there are rocks in the map. Then see if the same model bug occurs with a new save game. Of course, this will break all previously saved games under the old patch whether they had rocks or not, so might be best to do it with a copy of the mod...
If that doesn't fix it, I'll admit I'm not entirely sure what's going on. You might have more luck asking people on inside3d, no doubt Frik or Lord Havok will have a solution. 

comments. I don't think both mdls can be precached simultaneously, there's no such parallelism in the engine that I know of. And I know the issue with invalidating savegames when modifying progs.

It's easy to test as it happens immediately in the first playable map (atfe1m1). When reloading the savegame, I either get:

1. No problems
2. Mixed rock mdls (not very visible)
3. Many mixed mdls (very visible)

I'll try the worldspawn precaching to see if that makes any difference. 

I didn't quite explain what I meant by simultaneous there. What I meant was that both models might get precached within the same single spawn function one after the other. Like when the map loads, maybe rock 1 gets precached, then some other entities get their models precached, then rock 2 gets precached for another rock later on. But when the game gets reloaded from the save, it just precaches both rocks one after the other as soon as it loads the first entity from the save game. I don't know why it would behave like that, ignoring the if/else statements in the random part of the function to reconstruct the model list, but it would be an explanation for the behavior. 

The stable worldspawn precaching seems to cure the problem, too (I now restored the random mdl logic again). This might lead to the theory that any conditional spawn precaching might cause the messed up models in savegames ...

I still have another ATF issue as well; sometimes it triggers a progs validation fault while running, accessing an invalid edict. I don't think it's related to the other issue, though. 

If you don't want the models precached in worldspawn, but only when the rocks are actually used in a map, you could precache both models at the start of the spawn function, before you randomise them. That should work just as well. It does mean you have a wasted precache if none of the entities generate one of the rocks, but I can't see any way round that without breaking save games, at least until we know for sure what causes it. 

Even in code, ATF is pure evil