silver_key-gold_key-exit.

change-feed-sleep.

Now that's a nerd comparison. 

PakExplorer: 'explorer' type view, limited to 8 character filenames. sucks.

PakScape: 'explorer' type view, not limited to 8 character filenames. converts all upper case chars to lower case and progs.dat is case sensitive. sucks.

DZip: not limited to 8 chars. doesn't change char case from upper to lower. is NOT an 'explorer' type view, just a long list of crap so very difficult to organize pak files. (as it's primarily for zipping demos anyway).
sucks.

are there any other pak file programs? one that doesn't limit file chars to 8 or change the case around and that has a proper way of displaying files so as to be able to organize things well? 

That is one thing QuArK can do very well. 

there is a pak plug-in for total commander. It satisfies my needs for exploring pak files. 

i was under the impression that both of those could only open and extract files from paks? 

Nope, QuArK let's you save just fine. 

I have just tested and the tc plugin is creating pak's as well. Very straightforward 

Pakker 

thanks :) i wasn't able to check myself today.
wasn't able to find pakker though, but i should be able to use quark as i've already got that. 

http://www.gamers.org/pub/idgames2/utils/bsp_pak_tools/pakker10.zip 

so, i made a few pathetic textures and im trying to get texmex to put them in a wad, like i did once before i think, but now when ever i try to import it gives me "was ignored" on all the textures

the textures are in .bmp format and i believe they are 8 bit color

...i don't get it any clues? 

i remember that happening, and don't really recall why it did, but i'm pretty sure if you convert your bitmaps into 24bit targas, the problem should go away.

it might have to do with the 8bit bitmaps not having the correct palette (it's not enough for it to be 256 colours, it has to be the correct 256 colours). 

Are the bitmaps compressed? That might be it. 

Your texture, then 'paste image as new mip' in TexMex. 

those both worked :D

... i don't know how to compress bitmaps so i dont think i can decompress them :S 

I'm working on a terrain map. I use triangle shapes to lift the corners to equal heights and then use force to grid 1 to fit the brush.

Sometimes the brush takes the grid on a counter line and it is possible to move the brush back into its original position, gaining a clean, converted brush.

Othertimes it gets out of grid and causes the vieuw to get out of position.
http://members.home.nl/gimli/align.jpg

The first method , without forcing to grid, brings a well compiled map with errors, caused by the compiler with warnings and heling points. But a fitting brush order.

The second , with force to grid and reposition, brings a misaligned map with less errors and a better compile log, and a rather blurry brush fit.

How to avoid the process and which would be best suitable?
I never minded thes misalignements, I'm already glad the compiler takes it. But then again, the small difference could change vistime considerably. 

when i make terrain in qe3, i just do my terrain mapping in 3d view after copying and pasting all the triangular shaped brushes i need.
i keep the grid on 16 (or 8 if i need fine details) and just pull individual vertices up or down depending on what i need in the 3d view.
this usually creates good results for me. 

It would be really ace if editors allowed you to select say, 4 brushes and lock 4 vertices which all interleap with a simple keyboard shortcut, then you just drag the locked vertices into the appropriate position as one, and then "ungroup" them. 

or when you rotate a group of brushes. why do editors persist in snapping vertices to different points when they were initially sharing the same one...

also, why does firefox keep underlining 'vertices' like i'm spelling it wrong. what a bastard. 

As I read, I think my failure is caused by using the 1 grid option in force to grid. It turns out to become a disordered 0.x grid position that hardly can be healed. 

Which editor do you use? I forget..... 

your terrain generator program should automatically snap to grid too, so i don't know why it would change again if you snap to grid in the editor. 

... it could be that, unless you are zoomed into the maximum, your manipulation on the different brushes is just not lining up and not that it is actually off-grid.

I would not go below 8 for snapping unless I was trying to fit the terrain to an object that was not on the same grid reference, and then I would definitely zoom right in.

I use BspEditor and can zoom to 1600%. At that level it needs a very distinct mouse movement to move one unit and snapping acurately is easy. At the standard zoom (75%) it is impossible to line up brushwork in single unit movements even though the editor is 'snapping'. 

I use Quark63. It took quiet long before I could sahape a terrain map.
I don't use a terraineditor. Maybe a silly way I come up with.

I started with a triangle brush. Made it as precise I could. As long nothing happens to the brush it stands on grid with integers.

Then I turn the grid to 1 and force the outcorners to the 1 grid point. Of course the origin of the brush gets disordered so I have to force the whole brush into grid again.
That's my startpoint with terrain mapping and it compiled well.
Now I can make a terrainmap of all the triangle brushes. All goes well untill I lift the outpoints of the brush to level it with another brush.

From there the two outcomes appear in Quark.

Some brushes after distorted flip to a decimal but after resizing the brush with 1 the force to grid puts it exact 1 gridpoint aside. So I can easily rearange it untill it fits its origin.

Others get distorted and will never line up with the others. They will fit on x and y-axe but not in the lenght.

So I was thinking. Maybe I shoul force to grid only on a 8 or 16 grid. 

The wonders of QuArK. This is just normal behaviour from my experience...