VALVe Maps

G

groovyg

Guest
I know this might sound noobish, but... i guess i am noobish at map making lol, is there any way to use the valve made maps? are they in the gcf files or what?

im trying to make some Iraqi Desert Hostage Rescue map and dust/d2 would make great maps to cut chunks from
 
There are some that come in .vmf format with the SDK... but not the dust ones
 
Never decompile anything unless you exhausted your efforts on trying to learn a perticular entitie system. Decompiled geomatry is useless so don't bother thinking you can copy any of it.
 
Ive only decompiled to better understand how a certain feature was built. Or to copy settings for lights.
 
de_dust_pcg.vmf was released by the author some time ago. It's floating around online somewhere though I never looked at it.
 
You will need GFCscape and VMEX.
 
Decompiled maps show you how the originals were created but cannot be compiled again - that means you cant copy and paste, you can only observe.
 
Mess said:
Decompiled maps show you how the originals were created but cannot be compiled again - that means you cant copy and paste, you can only observe.

Hahaha don't make me laugh so hard.

They can be compiled again, you'd just encounter thousands of errors and quite a few leaks to go with it. When the map is compiled in the first place cuts are made in the geomatry. When random coder "n" decides to create a decompiler the outcome is usally that of assumption. The decompiled works will be cut in all manner of directions, and usually all brushes seem like they have been hollowed.

You could copy the retarded decompiled data and use it as a reference if you wished, but why not try to make it yourself? you'd learn a lot more.
 
Kyo said:
They can be compiled again, you'd just encounter thousands of errors and quite a few leaks to go with it. When the map is compiled in the first place cuts are made in the geomatry. When random coder "n" decides to create a decompiler the outcome is usally that of assumption. The decompiled works will be cut in all manner of directions, and usually all brushes seem like they have been hollowed.

It's incorrect to assume what was true for HL1 is true for HL2.

In fact, HL2 maps can be decompiled pretty much back to their original state. In particular, brush-splitting due to the BSP process isn't a problem anymore, since the .bsp contains (almost) all of the original brush information.

The remaining errors in the maps that are produced by my decompiler are relatively minor. A competent mapper can usually fix them fairly easily. An inexperienced mapper who can't read a compile log will generally fail, but I'm not worried about that.

There are some subtle problems that crop up (due to rounding errors, mostly), and occasionally a few brushes get lost altogether, but 99% of most maps will be in a recompilable state.
 
Rof said:
It's incorrect to assume what was true for HL1 is true for HL2.

In fact, HL2 maps can be decompiled pretty much back to their original state. In particular, brush-splitting due to the BSP process isn't a problem anymore, since the .bsp contains (almost) all of the original brush information.

The remaining errors in the maps that are produced by my decompiler are relatively minor. A competent mapper can usually fix them fairly easily. An inexperienced mapper who can't read a compile log will generally fail, but I'm not worried about that.

There are some subtle problems that crop up (due to rounding errors, mostly), and occasionally a few brushes get lost altogether, but 99% of most maps will be in a recompilable state.

Assumption is the mother of all **** ups. I never assumed anything. I've tried a few of the hl2 decompilers from interest and came up with terrible results.
 
Kyo said:
Assumption is the mother of all **** ups. I never assumed anything. I've tried a few of the hl2 decompilers from interest and came up with terrible results.

Wow, I didn't know there was any other than mine (Vmex). Links, please?

If you tried an early version of Vmex, it didn't do a very good job. Later versions are better.
 
Rof said:
since the .bsp contains (almost) all of the original brush information.

Why? Wouldn't it have been easier on the engine for the excess, unneeded brush data to be removed?
 
Raeven0 said:
Why? Wouldn't it have been easier on the engine for the excess, unneeded brush data to be removed?

Not sure. As far as I can tell, the brush data is partly used in the engine for collision detection (unlike HL1, which used clipnodes), and being able to recover the original brushes is just a side effect. That doesn't explain why they can't get rid of at least part of it (say, the void-facing sides). Perhaps it just wouldn't be worth the effort (it doesn't actually take up much space, compared to stuff like the lightmaps) .

It may be eventually possible to re-write a bsp to discard the uneccessary data, similar to what was possible for HL1 using custom compile tools.
 
Back
Top