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

simple question:

if you have access to the bsp compiler source code, why is anything a mystery? is it just very very complex? 

Is a lightmap allocation problem. If there's too much surface area in your map, there will be too much lightmap data to store in glquake's fixed-size lightmap arrays.

In addition to leaky maps or maps with boxes around them, it's also caused by maps simply being really big. 

you could reduce the lightmap size by strategically scaling up textures in places that can't be seen by the player. 

At least for me it's very complex, there are an incredible amount of float calculations and comparisons that easily can have an adverse effect on the results.

There are also several data abstraction models and 3D-algorithms that can be hard to penetrate.

It's actually pretty easy to write code that offer very complex results; just look at the simple fractal equations that unfold to amazing patterns when translated into graphics. 

for your post #2141, but I'm may overlooked something in the Quark64 program.

A slider on the top left corner?
http://members.home.nl/gimli/quak00.jpg 

that's correct. 

In my QuArK 6.3 version there is like necros said a grid button to the left in the toolbar, you seem to have rather different buttons from my version of QuArK. You might consider to reset the toolbar to default (if it isn't) or add the grid button to the toolbar (if possible).

In any case, you can also set the grid in Options-Configuration-Map-Display-Grid step. 

Why was the text Grid in the last sentence replaced with dots? 

there's a limit on the length of "words" on func, to prevent the page width from being pushed out by long strings of letters with no spaces. One of my to-do items is to redo the html so that individual posts can't push out the entire table.

Hmm, but since hyphens are treated as a word-break in browsers, i should probably have allowed for that in the code. 

I thought it had some similarity to the shortening of URLs. Or possibly the word "Grid" was considered offensive so I'd have to spell "G**d" ...