Isn't that forward/backward or "through"? In Worldcraft in the viewpoints, XY is it top, YZ is side, and XZ is front. Whatever really :P

My biggest priorities in layout is pretty much good connection and flow, with some backtracking and not-always-obvious (but not plain confusing) progression. I just can't seem to get past boring room-by-room/floor-by-floor layouts. 

about how hub design can become repetitive. If you have played Amagon, how that first episode (tech based) is organized can be beneficial to study.

The first level is devided into two sections, a hub centered around a spiral stair case that goes off in three directions at different levels for the first half, and the other is a terrain area with small buildings that eventually come back to the hub.

The second level is organized around two canals,

The third is a one level base area sorrounded by sprawling tunnels and caverns,

The last is almost entirely an over and under interior design seperated into three sections with excalating game play as you move through them.

You just need to examine packs like these and you'll be able to undestand their broader patters.

If you don't have Amagon, check out Mexx 10, Beyond Belief, and, of course, ftp://ftp.sunet.se/pub/games/PC/idgames2/partial_conversions/zerstoerer
which is the essense of smoothly developed variation. 

yeap, but I've made the mistake so often, I thought a little reminder couldn't hurt.

Using '' instead, usually works for me. 

I see what you mean. X/Y shows the top view, but the Z plane is what is extended into when you manipulate the height of the objects.

Using '' instead, usually works for me.

The '' should contain *<*i*>*. See if THAT works 

I just can't seem to get past boring room-by-room/floor-by-floor layouts.

I almost always start with exterior layout first and build the interior sections around the exterior design. Sprawling canals and canyons are
things that I like to see in both nature and level design (helps that I have a passion for hiking and live near some nice places for it).

Build what you you like to see in games and design the game play you would like to subject the player to around it.

Of course, that may be easier said than done. How good are your modeling skills? Your basic problem may not be that you are having a hard time getting out of a pattern corridor -- room -- corridor design, but you are having a hard time building the structures you have in mind

(continued) 

that is the case, then you should go back over some fundamental brush manipulation technique; here is my recommendation,

1. get some prefabs from this site: http://prefabs.gamedesign.net/

There are some nice heliocopter and tank designs that I really like here.

2. Get a bunch of the prefabs that you find most appealing, and
3. place one in your editor, seperate all of the brushes,
4. rebuild each one of the brushes from scratch.
5. put the brushes back together to reform the original design.
6. repeat, wash and rinse until you get the hang of it.

Honestly, there is no reason why you should not be able to create anything you have in mind
in your editor. 

I'm trying to convert all the McGee Alice tex into a .wad for q1 mapping purposes, but all of the .tex are in .ftk format and I cannot open them in any programs I have, including Texmex or Photoshop. I know Biff and Lun have somehow converted them into a workable format, so I'm wondering if there's a program that can open this extension or some other technique I need to do? Thx for any help. 

there are alot of awful prefabs on that site, headthump. its quite sad.
example: A lot of pipes in a room 

the quality varies greatly.

That's why I pointed to the tanks and copters, some are good, esp. the copter used in the Lazarus pack for Quake2 that came from the gamedesign site. 

The first level is devided into two sections, a hub centered around a spiral stair case that goes off in three directions at different levels for the first half

That sounds just like map 2 that I've been working on, actually - spiral staircase/hub. Except inside the column, is a plat the player will access later to another area of the map. 

regarding czg's post... there's an easier way to do it. There in fact are q1 compilers that support hint and detail:

http://quest-ed.sourceforge.net/dl/index.html
http://developer.chaoticbox.com/files/quake/equakeutils.sit

I suspect the tools as they are would not suit your purposes for various reasons (low limits on most variables, mac-only), but the code is there. 

Awesome idea with the compile stuff, dunno if its doable within the Q1 BSP framework, but it'd be sweet if you could do stuff like that.

As for editing and maintaining multiple maps... I don't see why you'd need to. If you were going to haxx0r the qbsp etc tools anyways, you could just use entities in your editor to control what was detail and what was part of the core bsp.

You could just invent a new brush entity or 2 (for example, func_detail or whatever floats your boat), tell QBSP to ignore those brushes during the first pass, and then compile them in the final stage... at least, I think that'd work.

That way, you can see every brush in the editor, and also clearly see what is base map geometry and what is detail. The brush ents (eg func_detail) could just be compiled as normal geometry on top of the core BSP, so by the time the other tools like light get a hold of the BSP, its all just standard geometry. 

Like i said in #tf, this all sounds very rube goldberg. For all that effort it would take to add these crazy hacks, it seems like it would be better to just support detail/hint in the compiler, and use existing detail/hint support in radiant.

Furthermore, if we're not satisfied with the q1 bsp format, it seems like a lot more would be gained by supporting q3bsp in more engines. Then we get the compiler and editor for free. 

Sure. What you said. : )

As far as I understand it though (and I don't understand more than a fraction of one percent of it all), it really isn't as simple as adding Q3 style detail support to the Q1 BSP format/tools. (That's just what I got from discussing the issue with programmers at work, who understand the tools/engine reasonably well).

However, as crazy/convoluted as it may be, czg's proposed method would possibly be feasible and would allow you to achieve at least something remotely like the desired result within the current engine/tools.

Of course, I could be wrong on both counts.

By the way... Q3 source code within a week? Does that include compile utilities, or do we already have that source? *shrug* maybe it would shed some light on the situation. 

Layouts and their scales are entirely over rated. In DM they are very important--no doubt about it. But there are so many SP maps that are linear room-corridor-room layouts that it's not worth fretting about. Obviously, certain themes will not work as well with linear layouts (space ships compared with an artificial tunnel). People really don't pay much attention to the overall layout as long as navigation is straight forward and the map looks nice, and so far you're not having any sort of serious problem with your aesthetics.

The scale of the rooms and their details and their relative scale to each other--now that's important. However, to some extent it depends on your own personal style, and the style of the game--Q3 is known for very wide hallways, and Q1SP can work with either wide or narrow spaces.

I still maintain that one of the most important parts of improvement is to just release stuff. 

I have a line of torches that are in view all at once (leading away from the player). Is there a way to un-sync them as they look a little 'unreal' at the moment? I suppose this will involve setting them to begin their existance at different times to ensure they display different frames visually?

I seem to remember reading something about this but now cannot find the reference. 

flames are already set to NOT sync in the mdl file. Not sure why you're seeing them all sync up, other than bad luck. 

Thanks, yes I can see the flag now and it is set to random. The torch is ID's original but it also happens to a candle.mdl I have nicked from somewhere(?) - it is not random even though the flag is set.

Mmmm, what now? 

That is some encouraging insight that helps me see it from a different perspective. Thanks.

I think for me it's inherently challenging to create a believable environment with Quake's textures. Quake wasn't quite suited towards the little details that help make an area realistic -- the best thing you can do is work with the texture sizes as they are and really let that influence how you build. I was running through Jago's Araivo thinking about that, how the textures fit so well over practically everything. It feels so solid.

But I find so many SP maps while they play nice and look great, alot of them are just brush-spooging - while they may be touted as a particular environment, they come off more as just... cool brush work on a large scale. Maybe that's just me. My point is, trying to create something more practical/real in Quake while possible - isn't necessarily the best way to map in Quake (with default tex sets), and trying to create interesting progression from there makes it that much harder.

On the other hand I just woke up so maybe what I said isn't very coherent. 

Thanks :) 

check out the braziers in Chapters, particularly the ones up the steps in chapter_necros; we had the same bloody problem >_<
I swear, I ticked the Sync/Rand box in qME. And checked it later. And double checked it again. Grrr. 

I tried Fitzquake & GLQuake, and both are sync'd.

Darkplaces is unsync'd, which is what I want but there are other things that I don't want.

I also tried Tremor but that has a nifty 'flare' effect so not what I want although it looks quite good.

So presumably there is some code in DP that takes note of the .mdl random flag, which is being ignored by GLQ and FQ?

Did something get lost between original software Quake and all of the follow-up engines prior to DP?

I'm a bit confused. I certainly can't leave this line of torches as they are: the synconisation draws the eye and hypnotises you into submission!

Bugger!! The map's no masterpiece but bugger anyway. 

On the subject of torches - if there are a lot of torches in a small area, are they all playing the individual fire sound via FireAmbient() or does the engine 'know' that it only needs to play one because all are within earshot?

If they are all being played, is there any advantage to reducing the number that are being played?

We are talking of 20+ torches in a 250 x 250 grid, plus monsters, doors, ammo, health, weapons, player etc; all of which have the potential to make sounds. 

wish and can upload a small zip that exhibits this problem in GLQ, I can take a look at it. I don't know what could be wrong though, but maybe I can spot something. 

if it's a fitzquake bug i'm interested in fixing it.

P.S. have you tried it in winquake?