HammerPatch

This is a program I’ve made that modifies Hammer and removes the precision loss for brush vertices when saving and loading.

It can be viewed here: https://github.com/crashfort/HammerPatch

Some pictures I have on the page:

Click the pictures for a larger version!

Figure 1
Say you have a simple default primitive. This is a cylinder with 32 sides.

https://raw.githubusercontent.com/crashfort/HammerPatch/master/Images/Shape1.png[/T]

Figure 2
In default Hammer, this is what you’d see if you zoom in on such primitive after loading a map of one iteration.

[T]https://raw.githubusercontent.com/crashfort/HammerPatch/master/Images/Shape1_Zoom_Default.png[/T]

Figure 3
Here’s the same shape but when saved and loaded with HammerPatch. It is the exact same vertices as it was created with.

[T]https://raw.githubusercontent.com/crashfort/HammerPatch/master/Images/Shape1_Zoom_HammerPatch.png[/T]

Figure 4
This problem gets more problematic on advanced shapes.

[T]https://raw.githubusercontent.com/crashfort/HammerPatch/master/Images/Shape2.png[/T]

Figure 5
Again, this is what it looks like in default Hammer after one save iteration.

[T]https://raw.githubusercontent.com/crashfort/HammerPatch/master/Images/Shape2_Zoom_Default.png[/T]

Figure 6
The same map as saved and loaded by HammerPatch.

[T]https://raw.githubusercontent.com/crashfort/HammerPatch/master/Images/Shape2_Zoom_HammerPatch.png

As of May 9 2017 I have not yet implemented the same change in VBSP so in game the brushes might get messed up still. But I’m working on it!

Combined with Shrinker42 Lathe tool this is should be amazing!

I love you

your profile picture is how i feel about this :smiley:

It seems like VBSP is different for all games and is not interchangeable so I’ll have to make a generic launcher for that too.

Can you release a compiled executable? Your github source doesn’t compile because it uses headers not included in the source (minhook.h)

Makes me think, why didn’t we have something like this before. Great job. Only if we could get a compiled exe.

I always release a compiled binary when I feel everything is ready. I still want to change some things.

Otherwise, I’m confused about VBSP. I take it you aren’t supposed to replace the existing game compile tools so it’s going to be a little hard to modify their code. At least in this case I have the public 2013 SDK tools as reference.

I haven’t fully worked out yet how VBSP handles vertices. It does the same dumb plane loading as Hammer does but then operates with the plane values instead.

The current Source engine branch Garry’s Mod uses is backwards compatible with all previous source engine branches leading up to it, so you can use older compile tools to make maps, you just lose features as you go farther back in time. There aren’t many differences between the Garry’s Mod Source engine branch and Source 2013 or even Source 2009 (Orangebox.)

You have major feature losses if you go back to the Ep1 engine and Source 2006 before it is more or less the original 2004 Source engine with some tweaks. You however can’t go sideways to other engine branches that are modified offshoots of any of the existing engine branches. One example would be The Ship, it uses a different BSP format.

You’re probably confused because there’s an invisible compile process that used to be present in the HL engine called Constructive Solid Geometry (CSG). Valve integrated this into Hammer and the VMF map format so BSP basically just reads plane data to do binary space partitioning.

It’s also why maps get double corrupted, the VMF format has corruption first and VBSP perpetuates it with rounding errors.

Any idea if there’s an easy way to increase the internal map size limit for hammer?
You can easily increase the max grid size with the “@mapsize” fgd-command, and everything works just fine, until you save the map and try to reload it:

http://sciolyte.com/sharex/hammer_2017-05-14_07-48-42.png

It just removes all geometry outside of the normal bounds (-16384,16384), regardless of the @mapsize value. I know for a fact that the geometry is saved correctly though and I believe it’s just some arbitrary check hammer does when loading a map.

This wouldn’t be that useful for source games, but I wrote a custom compiler for hammer for my own game engine, so this would be pretty damn useful to me.

No, there are lots of hard coded struct sizes in Hammer, which is why Hammer throws errors when you force a map larger than 16384^3. The Sven Coop team found this out the hard way when they tried to “just increase the grid size” for their heavily modified HL engine that massively increased the maximum map size to 262144^3. Their custom Hammer build had severe issues due to the larger map size and caused nasty things like map corruption and things tended to stop behaving properly outside a certain distance from 0,0,0.

You’d be better off trying to adapt another map editor for your engine like Sledge or GTK Radiant because honestly Hammer is cancer. Worldcraft as it was originally named was designed as a Quake map editor, it’s basically 20 years of bolted together hacks that barely allow it to work with Source maps. You can find bits of the original versions of Worldcraft sprinkled about in the code with ugly hacks all around it.

I published a release now: https://github.com/crashfort/HammerPatch.

I’ll have to figure out the whole VBSP thing another time I guess.

This makes me so happy. I opened up my map, and fixed all the vertexes, and when I opened it back up, they weren’t broken again! Thanks mate.

So I am confused, should I be using this or wait until you get VBSP situated. This is a program I have been really needing but if it doesn’t work in game, what’s the point? (Awesome work btw)

I think all source games save for tf2, and the L4D versions of source work with source 2013’s vbsp format. (you’ll be missing some features such as lightmaps, but that’s okay)

It removes an entire layer of corruption as seen in the pictures. It is fully usable right now.

The compile tools for existing games should not be replaced. I have not been looking since my previous post but I remember Valve’s stupid way of doing things with intersecting planes is the core of vbsp so I’ll need more time to look sometime. I have other things to do however.

Is this limited to any specific Hammer versions and/or Source versions?
For example, would this work for CSGO or Black Mesa?

Should do.

Does this problem exhibit itself in every version of Hammer, or is it just the common versions? I remember this issue occurring a lot back on SDK2013, but I can’t seem to reproduce it in my custom build of Hammer (based on the CS:GO version). If it definitely still happens it’d be cool to integrate a fix into Hammer itself for when Portal OI’s SDK gets released.

Tested it. Worked perfectly with Garry’s Mod’s hammer!