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

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.

if you use Hammer (or WC even, I think), this should be a non-issue, as you just keep the various LODs in their own Visgroups, and hide which ones you want at compile time. 

That was why I was thinking about it since I use WC myself. I was just expressing pity-support for the rest of the rabble. 

Lunaran has some articles on his site about organizing levels but I think they are oriented towards death match.

This is one way to approach map organization, and this occurs with a lot of Half Life maps in the original game, is build a central confrontation or obstruction in your map and develop the rest of the level as a hub around it.