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. 

I think this is such a subjective issue as well. Like when I stated you can't build a map without a good, well thought out layout and progression. Not everyone would agree with that. But it seems to work better that way with me.

I feel like, reworking is more work. When you have a blank canvas, so-to-speak - it's easier to see things come together - rather than this work I'm dissatisfied with. Of course I am bound to hit the wall again, and what am I gonna do - start over again? I'd hope not.

So I see where you're coming from, but I also feel if I put more thought into this, it'll show - and I'll be more satisfied as I build. For me, once I have a layout - the paths are there and it's easy for me to build along it. Whereas without something predefined, I think "what next?" and then I take 2 weeks off thinking about it. 

The main central area that the player keeps coming back to--including the outdoor area and the indoor corridors at the silver key door--were a copy of the incomplete layout I made for the original RPGSP2, which died from QBSP errors when I tried to make the terrain out of tetrahedrons. (Little known fact: it was IKBase, and featured yet another Shambler reference.) The rest of the layout (i.e. inserting a room at each branch of the layout) was built spontaneously.

For serious, layouts are over-rated. After I finished RPGSP1, I built several DM maps and didn't release them because I thought they had dodgy layouts, but when I went back and looked at them a few months ago I didn't think they were that bad.

You act like you might finally make a perfect map--one you're totally satisfied with. It isn't going to happen. People are so superficial that bad layouts really don't make that much of a difference; even to a lot of the people on this message board. And despite all this self-deprecation from you, we still have absolutely no evidence that your SP layouts are bad in the slightest. 

once I have a layout - the paths are there and it's easy for me to build along it. Whereas without something predefined, I think "what next?" and then I take 2 weeks off thinking about it.

Planning out layouts and rooms beforehand is the best way to map. RPGSP1 took 9 months to build because I didn't plan it well. But that's not to say you can't plan out the rest of the map around what you already built.