News | Forum | People | FAQ | Links | Search | Register | Log in
Q1 BSP Compilators And Stuff

I'm glued to Hammer 3.4, so the question goes to peeps, who're using it as well (Daz? Dranz? czg? erm?) or who're possesing superior knowledge to answer me.

Is there a possibility to use something except duBSP if I want to map with Hammer?

If no, is there a possibilty to update/fix/upgrade/decompile/hax0r this compilator without disturbing mr Riot? That's because it completely doesn't work in some cases, where other compilators worked fine. What are these cases- I cannot tell you precisely, so I cannot avoid them either, because dubsp is not telling what's fucked up.

No, I'm not going to use Radiant :(
czg what are you using? Old WCraft or Hammer?

That's a pity, you know. Both of us, qurneL and myself, are ready to map, are mapping, are hungry for brushes, have something(s) in progress, but our souls cannot be absoluted because we just can't view our maps in Q1 :E That's why qurneL canceled his nearly finished q1sp map =(

Any ideas? Please?

Another case: would you be so kind to suggest some good program for making Q1 models?

By the way, qurneL gets his site there: so you can see what he is doing =)
First | Previous | Next | Last
Some Programs For Q1 Models 
When I'm making models for quake, I've got a very complicated/convoluted process involving six or seven different programs for making the model, making the skinmap, painting the skin and converting the model to quake 1. Some of the steps aren't required though, so I'll recommend the bare minimum set first.

For making the actual shape of the model, I use as it's simple and intuative to use. If you don't like that, blender( or gmax(

For simple models, I'd skip straight to converting it to a quake model. For this, I'd recommend QMe(
QMe can import .3ds and .dxf files, but gmax will only export to .md3 format. If you use gmax, you can get round this by getting a copy of 3Dexplorer( 3Dexplorer will open .md3 files and export them to 3ds.

Finally, when you've got it in QMe, you can use that to make a skin, animate the model and save it. The skin won't usually work out perfect, but to fix that you need to use a load of plugins and mess about with Gmax a lot. If you want the details of how to make a quake model with a proper, unfolded skin, just ask and I'll type that up. 
Any leads on where to download the full version of QMe? 
I dunno if that still supports Q1 or if it's still free or whatever, but that seems to be a popular modeler. I think they used it to make the CounterStrike models. 
I am using WC3.3
You can use a different compiler to compile the maps; of course. Export them to .map and run whatever compiler you like. The problem is the texture alignment will be completely fucked up. My advice would be, find someone with a compiler you like that's still supporting it, and ask them to include the texture alignment stuff from dubsp.

I've had a problem of this sort too, in which a map is entirely fucked up after compiling it with dubsp (despite the fact that the texture alignment is fine, lol)... missing faces on many brushes, sky going through everything, etc. 
You completely rocks, thankyou!

Tronyn: summa summarum, it will be hax0ring t3h source code of the compiler I'm most familiar with? 
tell qurnel to finish his q1sp, his DM maps are excellent. 
I think Milkshape as a modeler is lacking in certain ways but it has excellent conversion utilities. For Quake I models I use the fallowing set up -- Wings3d, id's ModelGen for converting 3ds files to mdl,
and Quark for generating a skin file. 
I Need Hammer Source Maps 
and corresponding wads (zipped, please, and no rmfs/bsps) to test a quick fix I've just made for my compilers. It looks promising on the few Hammer maps I have.

At this time, it only enables my compilers to interpret the Hammer map files (with its native texture definitions), wads must manually be converted into WAD2s using e.g. TexMex and there's no support for extra hulls or other frills. I hope this is not a big problem.

Since MisYu initiated this issue, maybe you could send me some test material? But anyone with Hammer source maps is welcome to contribute. 
I'll send you everything today, both my and qurnel's stuff. 
You can get full Qme 3.0 here: 
LTH, You Are The MANN!!! 
I'm downloading it now to check it out. I remember making a search for it last year and not being able to find it. BTW, my set up includes Blender as well. You can use its IK tools to position the models cycles pretty easily, though animation is still a pain compared to modeling. I can model a decent monster in 4 hours or so, but animation for even a basic set up (at ease - walk cycle - fight) takes at least a week. 
Wow, Thanks! 
I was gonna try making a program that would add the animation frames from one model onto the end of another, to work around the problem, but this is far FAR better. Also, a quick recommendation I'd make now is to get a copy of the 3.1 demo. It has a program that will upgrade 3.0 full to 3.1 full, which has proper bones, a generally friendlier interface and IK. Thanks again!

(PS, LTH, are you still making tanx? I have a helipad model you might find useful...) 
Converting Hammer Maps 
I just tested and confirmed that it's very possible (and easy) to convert a Hammer map into standard Q1 (or QuArK ETP) format using QuArK 6.3.0 (probably other versions too).

The resulting bsp is very close to the ones I've been producing with my new versions, very few (if any) texture errors.

Just load the map file into QuArK in Q1 mode and save the map and you're done. It will preserve/translate all texture orientation info.

Of course, I still want Hammer source maps to test my compilers so you won't need the extra conversion step using QuArK. 
Preach - that would be great! Could you drop it into my pq mail:

Hammer Support 
(Valve 220 format) is now available at .

Any comments are welcome. 
Where? Which file? Docs? etc. 
Doesn't The Link 
above work? There are files and readmes directly available, what is unclear? 
So To Clarify 
if i want to compile my map I have to switch my HL .wad files with the original quake .wad files to get it to compile without the "wad not found in worldspawn" error (or whatever it was) ? 
Yes, This Is 
different from DuBSP, I've only added the capability to interpret the Valve 220 map file format.

See also post #9 above. 
I'm Currently Looking 
into adding the wad3 support also. However, I'm experiencing problems using the code from DuBSP. It appears as if some wad3 files (produced by TexMex) cannot be read by DuBSP, it aborts with a "ERROR 35: Failure reading from file".

When reading the wad3 file, DuBSP always seems to expect some palette data for each HL texture which doesn't always seem to be there.

Is this a known problem with DuBSP? 
I haven't ever had that problem, but then again I didn't use TexMex to convert my textures, I used wadconv which came with DuBSP. The only real problem with that is limitations, it can't convert a wadfile that has above a certain amount of textures, and some textures are too big to be converted. But other than that it works prefectly. 
well, all i know about half life wads is that they are supposed to contain palette data all the time

it's done this way to get over the palette problem of q1, where some textures look like shit because q1 didn't have the colors in the palette (like greens).
so all hl textures have their own palette info which allows nearly unlimited colors in the engine (why all textures, regardless of colors, look pretty good ingame)
sort of like how Cyan did all the images in Myst with their own palettes, so that they could save space but have 32bit looking images. 
After Some Investigation 
I think I've a picture of what's happening. DuBSP absolutely requires the palette data in the wad3 file, whereas the wad3 format only has it optionally.

This is also why Riot requests on his site that the wad3 files must be created by his wadconv tool (which always appends the palette data). This appears to me as a violation of the wad3 specification. It's also why wad3 files produced by e.g. TexMex don't work with DuBSP.

DuBSP also seems to append some garbage data to the end of each texture so the total texdata size in bsp is bigger than if wad2 had been used. This had me puzzled for a while.

I've tried to clean this up and now my compilers can hopefully read any wad2/wad3 file without any problems.

If anyone knows more of this issue, please let me know. 
Oh... Heh. 
my bad. i thought they needed that palette data. ;) 
First | Previous | Next | Last
You must be logged in to post in this thread.
Website copyright © 2002-2023 John Fitzgibbons. All posts are copyright their respective authors.