tried it once, and yes, needs to be +0 and +a sequences. will swap between the two and animate them 

Will someone explain to me the logical reasoning why, when selecting a series of files in Windows, I must select the last file first in order to have the files be listed in sequential (alphabetic, numeric, etc) order? Shouldn't new selected files be appended to the end of the list? 

Because windows is a piece of shit.

I noticed that whatever order you select, one file is always out of order. This happens when enqueing files in winamp using the windows dialogue, and pisses me off quite a bit. Normally I get the first song at the end and the last song at the start. Maybe it doesn't happen in current versions, but it definitely used to happen. I blame Windows rather than Winamp.

Actually, someone did explain this to me once, but it was probably a really boring explanation, so I've forgotton now. 

I meant to post it in General Abuse since I was generally abusing Windows.

I can usually get around the selection problem, but sometimes it's difficult when I want to play some songs that start with my favorites and then transition into a certain mood or style. Having to think backwards about it can be difficult sometimes.

The only reason I can think of to do it this way is because by now it's a standard, and it's a standard because Windows made it a standard, and you have to stick with the standard because that's what people are used to, and you can't switch boats mid-stream, even if your boat is sinking and being overtaken by crocodiles and beetles, and about to go over a giant waterfall into a rocky pool where thousands of hungry cannibals are waiting on the shore eagerly anticipating the coming feast. 

I agree.

I also agree that where is SM69 for crying out loud? 

Sorry to keep posting about this here, but if something is badly designed/coded, then a well designed replacement will be easy for people to switch to if they give it half a chance. If Windows Vista fixes it (unlikely!) then I'm sure most people that notice will think, "Thank fuck, they finally fixed it." It's basically buggy behaviour - I'm sure nobody can be such a retard to actually design it that way. 

I agree.

I also agree that have you checked your pants lately? 

Since I am (still) working on a map using Quoth ents and textures, I thought I'd ask a couple of quick questions.

1. Are you guys still planning on releasing more content for Quoth

2. If so, do you reckon it will be ready before QExpo?

3. Is it possible for me to find out about the new content a little bit before release so that I can add any cool new stuff and fixes to my map before QExpo?

4. Do you think it is possible or desirable to increase the range from which the vore will throw fireballs? I find it occasionally annoying that they only have a range of a few hundred units or so.

By the way, my map is split into three large maps now, so I don't think I will have problems with precache models etc. I'm about 70-80% finished with the first map, and 0% on the other two, but I think I can do it before June/QExpo assuming that I don't have too much to do in my new job. 

1. Maybe
2. No
3. I dunno if you can afford our rates.
4. Well, currently all the original monsters have a max range at which they are capped at (1000 units) So they can still shoot when you are fairly far, but they have a low chance of doing so. This was probably made that way so you don't get ganked while fighting close monsters by the farther ones you can barely see.
I'm not sure if changing the firing chance at long range is really the solution.

seriously, about 1 & 3, i can't really say much on that because i haven't seen kell in a while so we haven't really discussed anything about quoth for some time now.
The only thing i'm certain of is that if there is more quoth stuff, it would definatly not be ready for the qexpo this year as there would likely be a lot of stuff, most of which hasn't even been started yet (or just briefly touched upon). 

What could be the reason for your light.exe to crash in windows xp? Too many lights in a map? Everything worked fine until yesterday when I have added some more lights and light.exe crashes now without any message (the last output is: "Using minlight value 15 from worldspawn"). Previous version of the map had 256 lights and it compiled well. Didn't have the time yesterday to make some test with removing lights and now I'm at work :) 

If you're not using the latest Light 1.42, please try that and see if it helps. Otherwise I don't know really, 256 lights are not that much.

If you send me the zipped map+wad, I'll take a look at it. 

If you're not using the latest Light 1.42, please try that and see if it helps. Otherwise I don't know really, 256 lights are not that much.

If you send me the zipped map+wad, I'll take a look at it. 

thanks. Since I have a good and working backup I will start working from this point. I have deleted all the lights I'v added recently but couldn't fix the problem. Strange. 

Maybe this is a stupid question but I have to ask it.
Let's ussume that I use textures from wad1.wad in a map. After this I extract all textures from the bsp file using Texmex and create a new wad2.wad. How is the texture quality ind wad2.wad compared to wad1.wad? In other words is there quality loss when packing/extracting textures from bsp files?
And also do the textures change anyhow if I use wad3 format instead of wad2? 

is loss-less (like bmp), so there shouldn't be any degradation. IIRC wad3 basically adds a palette for each wad instead of just assuming Q1 palette. 

I've noticed that the idGamma tool always seems to destroy the upper half of the greyscale ramp of the Q1 palette (slots 8-15). This can adversely affect textures with a lot of detail in the brighter end (e.g. in kjsp1 or Invein). I've uploaded a file http://user.tninet.se/~xir870k/idgammabjp.7z that contains my standard Q1 palette with the greyscale ramp restored and a modified version that suits kjsp1 very well.

Just put either one of the supplied paks in your id1 directory, making sure you don't overwrite any existing paks (rename to higher number as necessary).

For those using engines that can load external tga textures, here's a tip that might enhance visuals in mods that use a lot of textures in different colours, usually suffering from bad dithering effects. Just load the mod bsp(s) into TexMex and export to tga to the "textures" subdirectory of the mod. Then either use them as they are or put them through e.g. a brightening/contrast filter in an image program (e.g. IrfanView).

Especially the latter can cause interesting effects as the filter works with the full 24-bit tgas, so no palette limitations will interfere. The end result is often much richer colour tones of each texture in-game. Experiment for best results.

Another simple trick is to convert all the textures into greyscale (still 24-bit); this will let you experience Quake in a b/w setting. All entities will still have colours, though. 

make those void maps.

Noob question...

I reckon in a "coagula" style map, the whole shit is put into a giant box, which is covered in some black texture. On the inside of the box floor and sides, there are trigger_hurts for the gibbing effect.

Is that about right?

What is the best way to build the outer box, just a giant cube? Does its shape and brushcount impact r_speeds, vis time and such, or does it not matter? Should it be made of sky brushes (i.e. using some black sky texture)?

Way up in this thread, I read about the brightness of monster models being related to the brush beneath it. In the void scenario, this is pitch black. Someone suggested putting a brighter solid brush under the black sky brush so scrags in the void would be properly lit. But later someone else said that you should not have any brushes outside of the map. Who is right? Or should one just not place scrags out in the void?

hope you can bear my n00b-ness. 

...the whole shit is put into a giant box, or in some cases boxes.

Usually only the bottom of the box(es) are covered in trigger_hurts. Best to use three or so for each box; stacked but with small gaps horizontal.

The simpler the shape of the outside box the better. Shape does effect r_speeds in a complex relationship that is best explained by real better than I. Size is probably more of an issue for vis time with coagula maps. That's why some mappers cunningly break their coag maps into smaller sections (necros for instance).

The limit box should be made of sky brushes and painted with sky_void texture extracted from one of the coag maps. For even better performance, see if Kell will let you bundle his sky_void skybox with your map.

For monster in void lighting, put a spotlight in the centre of your map directly under the structure you build. Make it a spotlight with mangle 0 -90 0, then add an 'angle' field to the spotlight and give it a value of 180 (this increases the spotlight cone from the 60 degree default). You will need to cover (replace?) the bottom sky brush with a plain black brush.

One should definitely place hordes of scrags in the void, and one should definitely have fiends a plenty to trick into suicide. 

what distrans said and don't forget to fit one sky texture to the one side of the sky cube, thus you'll make polycount less. you can check polys with r_showtris 1 command in fitzquake. 

Is polycount less if you make just one face of the sky brushes sky tex (the one facing inwards of course) and others plain tex... since the plain tex faces are anyways discarded of during qbsp (if there are no leaks of course).

Aguirre's utils don't discard the other 5 faces if they are sky, although fitzquake maybe does this in the client then? (fuh doesn't, and you can't see through the sky if you float up in the map, contrary to id stock maps where you can see since the compiler was different, but the sky acts differently too. In fitz it's always correctly transparent from void.)
Also, faces that touch the skybrush are not removed in qbsp, even if they would be if the skybrush was normaltex instead ( => higher polycount with skytex).

What about lightmaps?

Can you upscale textures on sky brushes? If yes, what does that help besides lightmaps? 

nico: dunno about distrans' solution, but it sounds strange to me to have proper sky brushes on all sides but a solid bottom...
as for the trigger_hurts - upscale their texture (to 99) to reduce light times.

vondur: huh? sky faces, at least in sky cubes, are only split into two polys anyway, so what's that trick about?

bambuz: sky textures are not affected by scaling iirc. the outside faces are always solid, shoot at the sky with the shotgun and showtris on. making only one face sky texured destroys the transparency. being able to look through sky brushes from the outside is a feature of fitzquake (thus client related).
there was a similar discussion before - better read the corresponding posts by aguirre some ## above. 

Thanks distrans, vondur and neg!ke for the hints (vondur is taking time out from world domination to speak to me, wow).

oh mighty one, can u explain what you meant by "fit one sky texture to the one side of the sky cube"? use sky texture only for the inside? or scale them?

neg!ke of the speedmappery, how would you go about the lighting of scrags in the void if you dunno about distrans' spotlight solution?

anyway, I hope to be mapping away soon. I just learned how to copy and paste properly and as a result nearly shot myself (lucky I "don't have a gun"). arrgh. so much time wasted.

when u guys speedmap, just how excessively do you use copy and paste? do you grab some brush that looks approximately like what you need, c and p it and just modify it slightly? Or are most of the brushes in your maps newly created, innocent brushes?

and I suppose when terrain mapping, obscene amounts of copy and paste are used?

also when speedmapping, do you pick a standard wall texture first or do you create the architecture now and texture later? or do u texture as u go?

a side note: oh metlslime, func_msgboard sometimes gives internal server errors like "maximum process count for uid xxxxx reached" or so. just fyi. 

just to make one texture fit entire face of the cube (inner sides of it). but as nek!ge said it might had no difference if you use modern compilers... but i'd fit it anyway ;) 

...I'm not 100% certain, but I believe one needs a solid non sky brush on the bottom for the monster-in-void-spotlight-trick to work.

If it's not required... even better performance! Easy to check & fix once the map is built though. 

Make the bottom brush that actually seals the map area a normal skybrush. Then make another brush that's about as wide as the skybrush, but place it so it's top surface is just below the top surface of the skybrush.
What I did in Chapter's "He Falls Like Lucifer" was to make the skybrushes 64 thick, then make the "black" textured brush 32 thick, and place it inside the bottom skybrush with a gap of 16 all the way around in all three axes.

Light the top of the black brush with spotlights that are set to have a cone less than 180 degrees ( this is so the light they emit only hits the top of the black brush, and doesn't seep up the sides of the actual architecture ).

Overscale the black texture on the inner brush by a lot, and do the same to all the sky texture too.