I have a 'no entity in empty space' warning. Usually I simply no_clip around the map and the empty space becomes self-evident, and is easily dealt with.

However, I cannot find this latest one. I know that it is not a major problem but as I am getting close to certain limits e.g. clipnodes, can you tell me what is the overall effect of leaving it? Presumabley, unnecessary clipnodes and marksurfaces? Is there any way to find the area? 

hull(s) you get that warning, qbsp doesn't fill (remove) the outside volumes, which most likely increases #clipnodes. Marksurfaces are only affected by the visible hull.

To fix it, you'll need at least one entity that's sufficiently clear from solids in all directions. Please remember that hulls 1/2 are expanded from the visible one, so they need increasingly more free space.

I don't recall the exact distances, but it sounds like you have pretty cramped quarters. Or all your entities are very close to the walls. You can e.g. just insert an info_null in the middle of a large room.

You're not using any odd qbsp options? 

...I have been joining some large maps (my three have become one) and I have already cleared some true empty space i.e. space completely enclosed without any entites and the player cannot get to.

I am actually using qbsp with only -verbose. It is reported in hulls 1 & 2. The latest one must be so small that I cannot use the noclip method to find it.

Being so small, it can't be generating many clipnodes so I'll ignore it. 

This particular map didn't have any entities in it yet - no lights, no doors; nuffin'. Groan... 

I reformatted my drives yesterday, I did backups of all my work on CD and uploaded to my server.

Both the backup .RMF and uploaded .RMF map sources report "unused keyvalues" in each map, and there are TONS of these reports when I do a problem check in Worldcraft.

I don't get how this happened! I didn't have these problems before the reformat. WTF! 

Y'know all I had to do was use CZG's updated FGD -- which I normally do use! But I thought that it was in my Worldcraft backup .zip, which is what I extracted my current setup from.

Ta. 

but i don't think AguirRe would use the word "sod." 

thanx, removing -fast option seems to help me. The dark strip is still visible but it's much brighter now. I think it'll go away after extra lighting of the map. 

Sorry aguirRe. I was, of course, talking about myself. 

This is a slightly different issue from cracks appearing in pipes and other manipulated stuff, because everything is aligned quite well.

As you can see in-editor, everything on the tower lines up well:
http://www.phait-accompli.com/q/s4/pre/misalign-ed.jpg

But in-game:
http://www.phait-accompli.com/q/s4/pre/misalign.jpg

While these misalignments are quite small that I feel the need to fix them, I still am curious why they happen. 

Corrected: While these misalignments are quite small that I don't feel the need to fix them 

Did you get my last two emails? 

Although the vertices look like they are lined up in the editor, this is misleading because of how the compilers load the map. The vertices are not loaded, the planes of the faces are. The vertices are then recreated by the compiler by calculating the intersections of the planes on the brush.

If your points are on the grid, then the planes will always be defined by nice round numbers, sufficiently so that the intersection points actually line up correctly. If the vertices are not on grid, then there is the chance of rounding errors. Some rounding errors are great enough for different brushes to place the vertices in different locations.

I'm sure somebody else can give you a more technically correct explanation of the process, but that's how it works to the best of my knowledge. 

the "indent" in that core cylinder looks nice, but it looks in the editor that the narrowest part is snapping onto quite a small grid size (around 4 perhaps?). remake the slanty bits so they match up on no less than a grid of 8 or 16 and i bet it would go away. 

Does anyone have an (Worldcraft) FGD definition for a misc_teleporttrain and, while I am asking, a handy tutorial on how to properly set up Shubby's demise?

Gee, thanks. 

it'll explain everything

ftp://ftp.sunet.se/pub/games/PC/idgames2/planetquake/quakelab/shubs.zip 

grab every file listed under QuakeLab, there are quite a few gems in there 

I finally got the spiky ball moving... 

Maybe it's just an aestethic thing, but when a Q1map shows HOM's after vising testlevel4, and fastvis don't, what would be the best thing to do?
Recompile untill all HOM's are gone, or just leave it fastvis.

Also, is it possible to load a wadfile into Deathmatch maker other than the standard?
It gives only *.wlb files, which I can't find compatible. 

Check out my Q1 ToolTips, section Portal Problems. 

What if you could compile multiple .maps of increasing complexity into one .bsp?

Say you have a large map with much detail.
Separate the largest chunks (major walls and boundaries) of the map into a separate map file. Compile a bsp from this map first. This would provide a rough and easy to handle bsp tree for vis to get a good foundation on. Then compile 'into' it the rest of the map, splitting up the nice and chunky nodes of the tree further into the final tree.

Entities could either be kept only from the last map or they could be merged. Light- and vis-data would be discarded.

The effect of this would be quite similar to that which you get from using hint brushes in Q2/Q3 maps. The mapper gets to control where in the map major bsp splits occur, and if he's clever he can reduce vis time (guess by quite a lot) by making sure the larger parts of the map can't see eachother in the 'chunky' map file.

This could be taken further by the mapper separating the map into more .maps with increasing detail, so you could have the equivalent of Q2 detail brushes, that only split up the actual node the brush is in, and not any further.

There could perhaps be some difficulty for mappers in working with this in the editor, since it would be impossible to maintain several different, overlapping map files at once*, and also a hassle to separate out all the brushes at various detail levels for each compile. Perhaps this could only be a usable option for the final compile before release.

Thoughts, please?
Also, implementation... �_�


* Doesn't GTKR support instancing of .map files into the current map via some sort of mapmodel entity? 

I've been thinking about layout issues and what constitutes a good layout that provides fun gameplay.

http://www.phait-accompli.com/q/s4/devlog.txt

I feel like I'm in a rut when it comes to that, and I need some inspiration... so if anyone has some insight I'd love to hear it. 

you are familar with Boroque technique, right? Inverting a theme, playing it backwards, concetating the beginning and end of the riff, shortening and expanding the meter that it is played, and that sort of thing?

Very artificial approach to creativity, but in the hands of a master it can work beautifully. The same approach can be applied to level design.

When I created BloodGates for the Norway pack, I was in a bit of a rut too, so I looked to some of my favorite levels for inspiration. One of the levels that impressed me the most from the original Id pack was the secret level of episode 3 the Haunted Halls because, despite being short of monsters, the action is quick, the set ups are thorough, and the level is complete in and of its self.

I played it several times and redrew the level on graph paper, and then I remapped it a few times more with a number of variations in the design each time. When I had a design I liked, I created Blood Gates with it.

Process sounds a bit mechanical, but if
you have played the map, does anything about BloodGates remind you of Haunted Halls? 

I'll look for it though. I can't say I'm familiar with the Boroque technique, as I don't really consider myself a musician (nor am I educated as one). So, I don't understand your point too well. :(