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. 

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.

This works, definitely but I think level-after-level it would seem obvious or gimmicky. Generally I try to make each room memorable, and put in interesting designs (I mean I've spent how many hours on the tower-hub area, I should be beyond that now). But I'm finding my layouts just lack good scale, and it's not easy to just says "well I'll build bigger!" -- it needs to be thought out well. Everytime I play someone's SP map I think about the little things that contribute to the layout and just how things come together to where - it's not really room/corridor/room to the eye - but essentially parts of it may be just that, but disguised in a nicely flowing layout. 

But I'm finding my layouts just lack good scale, and it's not easy to just says "well I'll build bigger!" -- it needs to be thought out well.

I'm sure you know this already, but I find that good scale is a very elusive concept, and it's never just about building bigger. Most times you can achieve a good scale by expanding the space in just one or two dimensions, not in all three. Or exaggerating one of them. 

to be a little more careful with the z scale (top down for Id game maps) than the x and y because it is easy to screw up your step placement, like in all of my speed maps, even the one I actually like. 

<quote>step placement</quote>
As in "stairs"?

(cause that kinda goes without saying. I was talking more about the space itself, not the features in the space. although of course, they too can be exaggerated in one or more dimensions, should the need arise.) 

fuck