It is you. http://zerowing.idsoftware.com/radiant-files/nightly/1.5.0/docs/ 

i hacky way to get monsters to cross gaps in the floor is to make an invisible func_wall entity (like hipnotic's func_togglewall)
that way, you still can't see it, but tracelines *will* impact on it's surface.

the downside is that you can't shoot through the gaps anymore, and gibs will land on them as well...

i suppose it could be possible to make an entity somehow toggle on and off depending on if a rocket was touching it or not, but i doubt that would work well... 

i get allocblock: Full.

now, i know this has to do with lightmaps and sealing the map usuall helps, but this is a little different than normal.

the map is still very small, only 1000 brushes or so. i've had maps that were 3000 or so brushes, unsealed with tons of lights without bothering quake a bit.
this map only has half a dozen or so lights.

also, i noticed the light compile time took much longer than normal. a few versions ago, it was lighting in about 1 sec while on this attempt it took 10 seconds.

aguire: this might be some issue with the actual light utility (or something i did which made an issue with the light utility) so i'm going to be messing around with stuff a bit to see what i can do.

thought you'd like to know or you might know what to do? 

got a Gl_buildlightmaps error: excessive lightmaps 67 (normal max = 64) 

edit2: that error appeared even when i *didn't* light the map at all. how can there be lightmaps when i didn't even have them calculated? 

figured out what was wrong... had one of those huge/infinite brushes, so the face count went crazy. never mind... :P 

Is a brush error. Try to load the .map file in a few different editors to see if some brushes don't load.

If that doesn't work, try to delete any brushes you added recently that have weird manipulations.

Also, look for microscopic OR gigantic brushes in the .map file. (in a text editor) 

Is it possible for you to try to reduce the chance of appearing of HOMs in the next version of your QBSP tools?

Or at least explain me why HOMs appear in places where they haven't been before after I place some more brushes in the room. Or does it have no explanation? 

When a HOM is on the surface of a brush and is not affected by VIS, I've found that it will usually fix the problem if I make sure all the edges and vertices meet perfectly where the HOM occurs. 

This may (or maynot) help you. Have a read of the "tooltips.txt" on AguirRe's site, scroll down to "Portal Problems"
Direct Link to ToolTips
http://user.tninet.se/~xir870k/tooltips.txt

AguirRe's Site
http://user.tninet.se/~xir870k/ 

I assume the first error message was when you were not using any of my engines, the warning you got when using one of my engines, is that right?

The AllocBlock: full error has no relation to whether the map is lit or not or how many lights or brushes there are.

It's only related to having very large visible brush faces (planes) in the map that the GL engines need to allocate space for. Too large and too many of these faces will sooner or later exceed the lightmap array (normal size 64, in my GLQuake it's 512).

Software engines Win/TyrQuake don't have this problem at all. 

what RPG and VoreLord said; check out brush alignment in the area and my ToolTips doc (Portal Problems section).

If you still can't fix the HOMs, please send me the zipped map+wad and I'll take a look at it. 

hehe, should have specified. :P

i was using fitzquake when it crashed with the error, so i loaded it up with your [aguire's] quake engine. man, i love that engine. ^_^

.
i didn't know that about the lightmaps. i just assumed if there wasn't any lighting, that the lightmap would be zero (making quake default to fullbright)

also, is it possible to make your vis and light start with different priorities like your qbsp does? it'd be nice to make light and vis always use 'belownormal' priority. :) 

I only added that possibility to qbsp since it's normally so fast that you don't have time to manually use Task Manager to change the priority of the process.

I have a small utility that you can use to start any Win32 console program with a specified priority and optionally with a timeout to wait for completion. After the timeout expires, it will kill the child process (useful when it might get stuck).

I'll email you this small utility. 

Could someone please explain to this dimwhitted australian, how I am to get the textures to show up (Quake). I mean, nothing shows up in the texture menu, so I can't load any textures. I can however type the texture name in the surface inspector and have it applied to the face I have selected. but I refuse to beleive that this has to be done all the time. Everything works fine when I load GTK 1.5 for Quake 3, or DooM3, but for Quake, well I can't seem to get it.

Please, anyone, anyone ? 

Just in time to, I was about to see how much of a mess a 21" monitor would make after being hit by a high speed mouse. 

When a HOM is on the surface of a brush and is not affected by VIS, I've found that it will usually fix the problem if I make sure all the edges and vertices meet perfectly where the HOM occurs.

It really helps. I've splitted the brush into two ones so that edges and vertices were exactly where HOM took place and it has gone. 

I am looking into making an elevator in quake3 but HOW is it done? i used the func plat and it moves up about 1 block and not any higher....how do i set the height it moves up or just make a simple elevator
??? 

Is your planetquake email address OK or should I use another? I heard Tyrann had a lot of problems with his. 

i have no idea, but apparently, i didn't get anything. :\ pq mail has never been very reliable...

send it directly to necros -AT- rogers.com, that should be fairly reliable. 

Evening....
I am having problems getting a few enitys to work in my start map..ie: setskill, etc.
Anyway does anyone have a tut for starting sp mapping, with a list of all the spawnflags and such... i am trying GTK 1.50 nightly...
The spawnflags don't seem to all be there.
I also need to know how to define an episode beginning to end... also is 'print' a valid spawnflag as in q2?
Thanks in advance.
-water 

I sent a copy today to that address too but got some weird warning about "delayed email" in return.

Anyway, you can get the file from http://user.tninet.se/~xir870k/priority.zip .

Please let me know when you've got it. 

Rising platform the player can ride to reach higher places. Plats must always be drawn in the raised position, so they will operate and be lighted correctly but they spawn in the lowered position. The plat will stay in the raised position until the player steps off. There are no proper sounds for this entity, only beep noises. It will spawn in the game and work properly but it sounds silly (see Notes).
-------- KEYS --------
speed : determines how fast the plat moves (default 150).
lip : lip remaining at end of move (default 16). Has no effect if "height" is set.
height : if set, this will determine the total amount of vertical travel of the plat.
dmg : damage to inflict on player when he blocks operation of plat (default 4). Plat will reverse direction when blocked.
targetname : if set, the trigger that points to this will raise the plat each time it fires. The plat raises and comes back down a second later if no player is on it.
...
<snip> <snip> <snip>
...
-------- NOTES --------
By default, the total amount of vertical travel of a platform is implicitly determined by the overall vertical size of the brushes of which it's made minus the lip value. But if the "height" key is used, then the total amount of vertical travel of the plat will be exactly that value regardless of the shape and size of the plat and regardless of the value of the "lip" key. Using the "height" key is the best method for any kind of platforms and the only possible one for thin plats which need to travel vertical distances many times their own thickness. Setting the origin key is simply an alternate method to using an origin brush. When using the model2 key, the origin point of the model will correspond to the origin point defined by either the origin brush or the origin coordinate value.

...
<snip> <snip> <snip>

This should help you out. Basically, the func_plat follows a formula to determine how high it moves. X - L = H. X is the overall height of the func_plat entity, L is the "lip" value, and H is the height the func_plat will move when the player steps on it. So if the func_plat is 64 units tall, and the "lip" is set to "8", then it only moves up 56 units. You can override this by setting the "height" key. If "height" is set to "256", then the func_plat should move 256 units up.

Also, you should make sure you set the direction of the func_plat to "up". 

i got the email.

i couldn't get the thing to work though.

in my batch file i was using priority below vis %1 %2 %3 %4 %5

but it didn't seem to do anything. is it that hard to make priority settings available in vis.exe itself? 

You'll need a Quake1 entities.def for making Q1SP maps. I'm not sure where you can get one online right now.

I'll see if I can get SPoG to start reading this thread, since there are some GTKRadiant 1.5 questions that he would be most suited to answering.

Episodes are pretty much only defined as a looping set of maps. I.E. at the end of each map, have a trigger_changelevel that has a "map" "nextmapname" key/value pair. If you want to have full out episodes like Quake did, then you'll need a start map with func_episodegates blocking off various episode teleporters, and the appropriate spawnflags for each episodegate. Then each map links to the next in the trigger_changelevel, and at the end of each episode you need an item_sigil with one of the spawnflags checked. And the trigger_changelevel in last map of each episode should link back to the start map.

I don't remember a "print" spawnflag for any Q1 entities.