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? 

Thanks aguirRe, I have sent you an e-mail with a sample map showing the problem.

Don't panic, the file is only 9K. 

Yes, same effect in WinQuake.

Small map e-mailed to you showing a row of torches. 

hi.

Phait:
Who was it that said it that you aren't supposed to try to do too realistic stuff in quake because once you start looking at it, everything's out of proportion in the quake universe. Compare the rocket launcher model on the ground to the guy and see that it's probably as tall as him. The buttons are huge. Etc etc.

Quake is like a comic made with heavy wide brush strokes. There's certain things that are functional in that style and some that are not. Probably an almost infinite set of working styles out of the infinite set of all styles.

I think the spaceship cockpit and other stuff you've shown in screenshots look really good but in general they are really lying on the edge - you can't go smaller or more detailed from there. Then you'd have to map for a completely different game and engine etc...

Don't worry too much. Maybe you could use some vacation from mapping or even computers on the whole. Like I did.

Your site seems a bit messed right now... Don't tell me you've deleted everything and started from scratch. Please don't do it! Release stuff and don't worry too much about the evil-sayers. There will always be those and like rpg said maybe you have to release stuff too to learn and not just ponder on your own for too long.

Keep the faith. (pun intended) 

http://community.webshots.com/photo/78584309/78584725YMmLti

Hint where to get some remotely similar texture? (Not the one from lunsp1 / lundead.wad). I'm willing to do some porting. Someone mentioned tribes textures?

I honestly recommend all mappers... or just anyone visiting northern Sweden to check out Storforsen (in Bredsel, near �lvsby, south of Jokkmokk).

Gutta cavat lapidem 

http://rpg.spawnpoint.org/images/maps/rpgdm1_1big.jpg 

Yeah well I've learned this:

you can't build maps without a solid concept and layout. My layouts were completely spontaneous and I hoped for the best. Then I get to building and realize it sucks and well... with the recent inspiration and kick-in-the-face that is RPG's 'and all that could have been', I'm starting over and putting some more thought into this.

The ironic thing is RPG probably built it spontaneously. Am I right RPG? 

DO NOT start over from scratch. One valuable skill you will learn as a mapper is to rework the parts of the map you are not satisfied with until they look good and fit together. Having layout problems? Rip out a part, rework it and put it to use elsewhere in the map. Rince and repeat. Yeah, it seems "so much easier" to just start over but 1) you are less likely to finish the map and 2) you will learn A LOT by reworking your old map.