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 

One can indeed question the quality of this and other contemporary mods, but they actually offer good test material. But one of the maps in ATF is probably the most messed up piece of junk I ever saw.

The mapper must've been completely unaware of the subtle differences between various basic ents, having a func_illusionary as a platform, several solid teleporters, SK door without any SK in the map and teleporters/pushers in the most unexpected places, throwing the player around the map at random ...

Interestingly enough, there are several key objects (e.g. sounds, symbols and archgaunts) in Nehahra that seem to have originated from this mod. 

And I think it is because the author did an -onlyents compile before release and didn't bother to check that half the map broke because of it. (messed up modelindexes, etc)

Anyway, playing that mod feels like getting cancer, AIDS and cerebral palsy at the same time, so I've only played it, like, thrice. 

referring to atfe2m2, which indeed has many model errors when re-lighting it (conflicts between the model and entity lumps, probably due to the -onlyents run or similar). That map actually works without any obvious problems.

The map I was referring to is the one after that, atfe2m3. I have no idea how it could be produced by mistake or corruption.

I've also mowed my way through Fantasy Quake and X-Men recently and there's a lot of unique and un-Quakey material in there. Must've been a lot of work creating it ... 

the atfe2m3 map again, I realize that you're probably right about the messed up entities. If I start to shuffle things around and change modelindexes, the brush ents suddenly start to make sense. Argh ... 

aguirRe can u explain how can i make this work...

http://trinca.no.sapo.pt/03.jpg

;(

Txqbsp.exe
and light.exe work fine but vis give me this error prt fucking file...can u please explain what does that mean? thks in advance! 

Obviously your map has a leak... Find it, fix it. 

Go into your Quake/tmpQuArK directory (or where the compiled map, etc.. are located... normaly the stuff should be there),
Remove all the files..
Relaunch TxQBSP only (from QuArK)
Launch Quake from QuArK
In quake console type pointfile
A doted white lined should appear: follow it and you will find the leak...

BTW, I'm very surprised that QuArK didn't show you the leak by a red arrow before !!

Hope it helps...