"on" the result, rather... 

What I usually do (in Worldcraft) is
- make a cube the size of your room to be.
- make it hollow outwards
- ungroup the thing,so your left with 6 brushes
- copy and paste (special, to same location) a brush 4 times and then shape them to fit a door in, 1 for the door, 1 for the left of the door, and for the right and one for above the door.

It does work that way.
I don't know if it's smart or handy though.
The thing with mapping is that you basically have to learn how to do it yourself.
The tutorials only show you the basics.
I still find it very difficult to find efficient ways to achieve things.
That's why I love this website ... ;) 

You know that combat music in Star Trek when Captain Kirk is battling a Klingon in the arena (with pick axe, spear, and shovel), well that music was playing in my head a few posts up.

I was thinking, HollowMaker sounds like an excellent stand-alone program that could work this way. First you make a cube in any of the editors available. Next, export the cube. Now, import the cube into HollowMaker. It has just 1 button, Hollow_out ! Now export and import into your favorite map editor. Voila ! So easy, and you'll want to do it over and over again.

I feel so hollow... Hey wait! HollowMaker hollowed out my brain.

Where is it?

It's in Quark? But I use BSP...

Spock, help get my brain back!
...my next map title... 

 

have you checked if you're getting any 'too many lightstyles' errors?

hrm, i compiled again to check, and this time it worked okay.. bizarre.

it is something where just because it works correctly one time it doesn't mean it will work all the time? or can i assume that it either compiled correctly or it didn't? 

did you run a -onlyents? remember to run a -onlyents on both bsp and (aguire's) light to reconnect lightstyles with the entities.
-onlyents on bsp breaks that connection (probably cause it can change the order of entities). 

that would be the problem :)

didn't realise there was an onlyents light option.. thanks. will have to add it to your compiler gui 8) 

cool, glad it's been useful! ^_^ 

what's the deal with quake sounds?

I thought they had to be 11kHz 8bit mono, but i just made a 44kHz 16bit mono sound and it loaded in both fitzquake and winquake... so is that okay? Is dosquake the only quake that needs 11kHz 8bit sounds? 

The beta or qtest used 44khz so I think it was a size or performance decision. 

Your 44kHz sound will still be downsampled to 11kHz, though, unless you set -sndspeed 44100 in the commandline (which doesn't work in Fitz085 as far as I can tell). 

11kHz .wav files are much smaller, so yeah, that will have been the reason. Considering the download speeds of the mid-Nineties, small sound files = good sound files.

Decent engines support -sndspeed 44100, I'm pretty sure it works with FitzSDL / Quakespasm. Under Linux and for me at least.

Still, -sndspeed 44100 will not magically restore Quake's sounds to their original quality. Once downsampled, those ones and zeroes are gone forever.

All that -sndspeed 44100 does is play 44.1kHz .wav files at the correct quality. 11kHz files will be nominally upsampled for playback, but the lost information remains lost. As with dried fruit - you can't magically restore them by putting in water.

id ruined Quake's sounds to save space, which is understandable for the shareware part (download size), but idiotic when you have CDs (and the soundtrack is 44.1kHz anyway).

Also, yes, it is OK. Dunno about Dosquake, but I'd be willing to bet it is OK with that as well.

And just a notice: Mappers and modders who provide 11kHz sounds along with their products are shooting themselves in the foot. There is no benefit to that, only drawbacks.

If you provide 11 kHz 8 bit sounds with your map, and someone plays your (Quoth or otherwise) map under RemakeQuake with -sndspeed 44100, the quality of your sounds will be comparatively (and noticeably) bad, at least if the player has good ears and is wearing headphones. In short, 11kHz sounds are pretty dated and will become obsolete in the future, maybe not with RemakeQuake, but eventually it's inevitable.

Whereas when you don't downsample them, they'll be converted automatically at runtime and fit right in with Quoth etc. 11kHz sounds, so there is no problem at all AND your sounds are future proof. 

> The beta or qtest used 44khz

I think I checked all of those distributions and TMK that was not the case.

If you have a version of id Quake with 44.1kHz sounds, I would like to see (or rather, hear) it. 

i always downsample my stuff to 11khz 16bit and 8bit if the sound has constant volume. if you leave the built in downsampler do the job itself, it does it on a similar level as the image resizer in glquake. (sucks) 

http://web.archive.org/web/20080408013326/http://www.stay.dsl.pipex.com/qsrp.htm

Then search for the filenames. 

I'm surprised how well some sounds and music can be at 11 khz 16 bit. Currently, I'm mixing everything at 44 khz 16 bit stereo, then make a final downsample copy at 22 khz 16 bit mono for glquake. Lower recording levels keep sound quality at par between the different sample rates. I'd say choose 11 khz 16 bit over 22 khz 8 bit though, 16 bit is more important. 

8 bit is really grotty.

I also think that the downsampling is done by the sound card, and hence the quality of that might play a role, but I don't know for sure.

I don't see the small loss by downsampling in realtime from 44 -> 11 kHz as a problem, considering the abysmal quality that comes with 11kHz anyway.

The result of downsampling *always* sucks. 

Ah OK, thanks. But I'm pretty sure I looked at all of the QTest sounds and almost none of them are 44kHz - a fair bit are 22kHz though. 

The result of downsampling *always* sucks.

I figure you'd better make sure your sounds are still acceptable when downsampled. For example if your sound is primarily high-pitched, it will be destroyed by 11kHz downsampling, and you should probably come up with a different sound. If it's mostly low with the high pitch adding just a crisper overall sound, then the people playing with 11kHz mixing will at least hear something appropriate. 

this are basically DSP (Digital Signal Processing) theory: you can over-sample, nor down-sample a signal without interpolation filtering..
For down-sampling it is straight forward as soon as the new sampling rate is a multliple of the original sampling rate (e.g x1/2). Additionally, it is obvious that human ear dynamic range has to be taken into account (that is in [20Hz:20kHz] range)... So sampling a signal @11kHz is quite crappy except if you are almost deaf, at 22kHz it can be acceptable if there are not that much high frequency (i.e above 11kHz)... and 44kHz is the best..
Furthermore, remind that each individual has its own ear dynamic that vary a lot with age: a children has a higher dynamic range than an gran'ma generally...
Anyway, there are no better method than never down-sample a sound under 22kHz if you want an good (or acceptable) sound quality... and also a good soundcard ;) 

how crucial is the 'too many lightstyles on a face' warning? will it crash old engines or just cause stuff to not light properly?

4 is an annoyingly low limit 

Extract from aguirRe's tool tips: http://user.tninet.se/~xir870k/tooltips.txt

"Too many light styles on a face, lightmap point near (x y z), tex, light->origin (x y z)"
Too many styled (torches, flickering etc) lights in the specified area. Reduce # styled lights or their range in that area. You can also try option "-gate #" to limit the range of
attenuated lights.

Actually the limit depends of your light tool, but as explained above it can be easily solved by reducing the number of lightstyle on a face... maybe you should contact aguirRe and ask his advices... and if you are lucky, he could do you a favor by sorting out a new light tool with increased limit regarding lightstyle... who knows ;) 

i don't think it's just a tool limitation or aguirre would have pumped it up higher.

what will happen is that the light on those faces from the extra lightstyles just won't be shwon. this can lead to hard edges between lights.

aguirre's light is better than most and will try to discard the least visible one or prefering to use the minlight/sunlight before anything else.

still, it's something that you should try to avoid.

as for old engines, the problem will look the same as in new engines (unless it's an engine with real time lights of course). 

cheers jpl but it is kinda obvious what it means & how to prevent it ;p just wanted to know what the negative impact on the map was.

what will happen is that the light on those faces from the extra lightstyles just won't be shwon. this can lead to hard edges between lights.

i see.. i usually get it when attenuated lights spill over into the next room and i don't think the effect has ever been noticeable. excessive compile warnings are never nice but until now that's been the only reason i've tried to avoid it.. 

Dumb question but where are those orange textures that I see people shelling L4D and HL2 maps with? Which WAD?