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

sorry but what means leak :) something like a escape? hole? 

A leak is equivalent as a "hole" in map: if the map is not correctly sealed, you got a leak... So seal the map, and the issue is solved ;) 

this is basic mapping stuff, the manuals have stuff on it.
copy the .pts to the same dir as the .bsp (quark might do this automatically, wc does), load fitz and the map and type pointfile in console and it should show the leak. 

got it thanks guys :) and many thks to JPL that help me out in a hard thing last night ;) 

I didn't know about that "pointfile" command... Thanks!

and many thks to JPL that help me out in a hard thing last night ;)
Got trouble where only a french guy could help, eh? :D 

ehehe no,no at this point was the only one that help me out with no limits... :) vondur refuse to help me... but i kick his ass "sometimes" in dm�s :) to revenge! 

i can't remember the last time i had to use the pointfile - quest's leak detection is sweet. the other editors must have such a function, as well...? 

Racist ! ;P