Do any of your mod's files have capital letters in them? This is especially important for the files in the pak. DOSquake really doesn't like them, and so it might just not be recognising the files because of that. It's quite likely that telejano has this fixed...but of course I could be totally wrong here. Anyway, try making sure all the filenames and extentions are lowercase if they aren't already. 

No, I just get confused while I can't see why it works under D:\ and not under C:\ 

I have a few clipping problems in this map I'm working on, so I tried using -hull 1 -solid -noents on TreeQBSP. Well it seemed to work fine, everything was expanded, but I didn't notice anything that would have been causing the clipping errors. I'm just supposed to look for misaligned surfaces, spaces that are too short, and things of that sort, right? 

guarantee that clipping errors always will become visible when using that option but if you actually *do* see a HOM, it's a safe indication on a brush problem in that spot.

Typical causes are misaligned brushes or sometimes even a nearby pointy brush that somehow "pokes" a hole through the damaged brush.

If you send me the zipped map+wad and a description how to find the spot (or coordinates), I'll take a look and see what I can find out. 

I'll send the message shortly. Gotta put all the textures in one wad. 

forgot to put in the progs.dat and progs.src
now everything runs fine again. 

Great link aquirre, that explains the thing i was missing -- i thought that the qbsp bevelling would be sufficient, but i hadn't thought of the case where the blade of a wedge-shaped brush is running at an angle like that.

After further thought, i don't think xp-cagey's solution actually solves all cases -- he seems to have handled all problems caused by sharp edges, but imagine a sharp point at a weird angle, such as a pyramid with the pointy end in a nonaxial direction -- this still wouldn't be solved by his code becuase he's only looking at edges.

Still, it's an improvement to go from handling all faces and some edges correctly to all faces and all edges. I think a final bit of code to address points as well would finish off the problem for good. 

it's a precision problem rather than a logic problem. 

One of the reasons the map I'm working on has such a huge brush count is my liberal use of triangles, on architectural as well as terrain brushes. I haven't been that aware of the hull expansion issues until now. Bugger. 

As I think I mentioned before, HL seems to have had worse problems than Q1, so at least one of the cases XP-Cagey's describing in the article is already covered by the original Q1 expansion code.

He sent me some map examples that he claims fails in HL and they worked as expected in Q1.

I have a feeling that the problem is a combination of brush expansion, CSGFaces (brush merging), outside filling, SolidBSP (building the final tree) and numerical errors along the way.

Since I doubled the precision (to 64-bit) in my compilers, they work much better than before, so precision is involved but increasing it can only do so much. It's also interesting that doing the same to e.g. vis, doesn't make any difference at all.

Tyrann made a great stab at it in his TyrQBSP and some of the solutions he put in there, I've imported in my versions. Overall, it doesn't really seem to help, it only makes the compiler faster and a bit more consistent.

Kinn: If you don't have any obvious problems, maybe you shouldn't worry too much yet? After all, this isn't a new problem and it's definitely not worse than it was before. 

'As I think I mentioned before, HL seems to have had worse problems than Q1'

I can attest to that after spending a weekend playing the Sweet Half-Life mod (mostly awesome BTW). I seemed that it was possible to get stuck in several areas that I would not even think of needing a noclip brush in within a Quake map. 

the mappers of that HL-mod should try out XP-Cagey's tools, he seems to know lots about this and other tool issues. Since I assume that the original HL-tools were based on the Q1 ones, it's a bit surprising that they are inferior in this aspect. 

HL seems to have had worse problems than Q1

That might simply be becuase of the "normalization" thing he talks about in part 2 ... it sounds like a horrible idea :)

Anyway, i'll try to do some code diving some time in the future and see if i can actually come up with any improvements on this front. 

I finally managed some clipping in Quark64.
But it is rather a brute instrument, it took me half an houre to get the comparing textures right, the stupid thing is working like it has drunk a bottle of XXX.
If I make a same kind of brush, and add it, it is done in a minute!

Isn't there a more clever way to size the grid?
ie. move 16 up or down? 

is there not a slider on the top left corner of the screen to control the grid settings? 

Gentlemen,

Does anyone have any ideas as to why a simple but moderately large q1sp would run fine in winquake but crash out with "Allocblock : full" when run in glquake, macglquake or joequake?

Thanks. 

Did you set memory extension in your glQuakes (like a -winmem 32 command line or something like this )?? It seems you did it with winquake... but not with your glQuakes... :o\ It's why it works fine with WinQuake but not with the other engines... 

Thanks JPL, but that was the first thing we checked. I just changed the "win" to "gl" so all other parameters were the same. :-)

To clarify. If runs in the software version of each engine (win, mac and joe) fine but in the GL version AllocBlock: Full. 

.. I have already "met" this probelm, but I'm unable to remind where it comes from, and how to solve it... sorry... :( ...
Did you made a try with FitzQuake ?? 

at the TooTips at my site http://user.tninet.se/~xir870k , it explains why it (and many other problems) happens.

There is also an enhanced GLQuake engine that most likely will load that bsp. If it doesn't, let me know and I'll look into it. 

I found this in your ToolTips

"AllocBlock: full"
This error is directly related to lightmaps in the engine, but is normally caused by a leaking or
boxed large map. Seal the map or remove box. GLQuake 1.11 or Tomaz/Win/TyrQuake can usually load
this kind of bsp.

Can I have some further explanations please, I'm not sure to clearly understand the source of the problem (the part concerning boxed large map)

Thx 

Thanks, that's a big help. Investigations will continue and I'll report back later :-) 

A "boxed" map is one where the entire leaky structure is wrapped in a huge box (also referred to as a "daiper".) This is generally a desperation measure taken to get a map to work.

While doing this lets the map vis, there's still a performance hit due to visibility calculations being done for the spaces outside the map proper. Also, lightmaps are computed for this "outside" space, bulking up the lightmap data size even more, especially when the box is extremely big.

If you absolutely cannot find a leak, shrink your box as tightly as possible around the region/s in question, like I did in Swamp. 

Thank you very much, now I clearly understand the issue, and I think it's not a good way to build a good quality map...
I'm pretty sure this kind of "turnaround" can be avoided with a lot of care during the map design.. and using a lot of compilation steps... With my first map (Hatchepsout), during the first tries, I found one big leak problem, and I solve this by restarting from a stable point (from scratch here !!!)... Too many copy-paste without textures and brushes re-alignment were involved here.. But I restart with a lot of care and methodology regarding brush and texture issues, etc.. .. and no more this leak problem occurs.. Sure it can be more complicated for huge map, and when the design is almost finished.. In my humble opinion of beginner (I started mapping just since 6 months, more or less.., and I guess pros-mapper should think the same), I really think it denotes a loss of care during map design... I'm not saying the mapper is a bad one, just saying he have to take much more care at what he does... even if sometimes QBSP tools work in mysterious ways... some warnings issues are sometimes very "esotheric" -8o\ ...
Anyway, thanks for the explanations... sure I will try not to do some "huge boxed map" designs...
Bye.. 

Basically what Fatty just said except that normally there's no big performance hit in-game, since vis will [very slowly] discover that the outside isn't very visible from the inside (if the leak isn't very large).

But it most certainly puts an extra burden on all the tools and engine. Vis time can easily be extended 10-100 times by boxing a big and complex map.

Morfans: Was it an old Q1SP map or a new one that you had the AllocBlock error in? I'm always interested in troublesome maps.