Did you place the tools inside the bin folder of your game's root folder (where hl2.exe is)?
Look at this, its gonna be amazing if you implement it:
Basically a prop scaler option, just like in CS:GO. Ik its not possible, so heres how to achieve the same thing differently:
When you compile the map, it will look for props which scale was changed, decompile them, and recompile them with the scale value you entered.
Then, it will pack those scaled models in the BSP.
BAM, scaled models in games earlier than CS:GO.
wdyt
Already asked that, its not happening
There seems to be a bug with -ambientocclusion.That if you enable it and have a light_spot pointing onto a displacement it just won't work.
https://files.facepunch.com/forum/upload/296527/85efdb81-7ce3-48c3-ab19-dfdc8d4496f5/Download.jpg
I thought you could disable smartedit and scale dynamic props anyways with a scale parameter.
Any dynamic point entity can be scaled with the "modelscale" keyvalue, he is suggesting it for prop_static
Getting guaranteed crash trying to open the material browser. Anyone know why?
Right now you can't flip an object using the keybinds (CTRL+I/L) if you selected it in the 3D view, you have to select it in a 2D view, and the flipping is only done with respect to the view you selected in.
If possible, make it so the keybinds flip an object depending on which 2D view the cursor is in, similar to how nudging works.
I cannot compile gm_fork after saving the vmf in your modded hammer. This has happened in both hammers (fork supplied by TF2 and your fork). Here is the logs for compiling the original vmf, saving with the old tf2 hammer, and saving with your modded hammer along with old and new compilers used. I'm also supplying the 2 vmfs used in the compile with this post.
forkreghammer.vmf (made with regular tf2 hammer)
forkmodhammer.vmf (made with modded hammer)
Also small question, why isn't this mod open source?
On half of these logs, I see that you have a leak that needs fixing. Use "Load Pointfile" to locate it. On the other half, the engine complains about "max_map_planes". You should google it to see how to fix it.
That's the point. The original gm_fork compiles fine, but when (without modifying the map or moving the camera) I save the map it gives me those errors.
I'll be honest, the hip 90s name got my attention. SLAMMIN'!
So the "modhammer" file is only loaded and resaved?
This is weird.
I've poked around in the data some and mostly found slight property differences that can be explained from defaults given in fgds.
The solid, plane and displacement data seems to be unchanged.
But this here should not have been different, I think:
https://files.facepunch.com/forum/upload/132786/5ce57e11-5fe3-4ade-b04a-df6e601f022f/image.png
Counting "hidden" (one per hidden regular brush or brush in an entity, and one per point or brush entity), I get
10557 entries in the forkreghammer.vmf, and only 3329 entries in forkmodhammer.
Comparing what I think should be "solids" that are hidden, 6279 are hidden in the regular vmf, only 2191 are hidden in the mod vmf. If I see this right, your resaved vmf has 4088 more shown brushes - posing a problem if hidden ones are ignored by the compilation process.
Both of the vmf's are loaded and resaved from the original gm_fork source release (reghammer being unmodded hammer, modhammer being modded). You might wanna compare that as well. I'm not good in vmf trickery, so do explain as I am interested.
To summarize, I've seen a lot of hidden entities and brushes in the original VMF of which only a fraction remained hidden after you've resaved them. They were unhidden during loading or saving, and that probably had an impact on the compile process. If hidden stuff was normally ignored by BSP and suddenly there are a lot more extra brushes to be processed by it, that can explain what happened.
I'm talking about these buttons:
https://files.facepunch.com/forum/upload/132786/6da99fda-ae01-42c8-9f28-0715d8dc6c24/image.png
Here's one idea I have for debugging:
Load the level in the unmodded hammer, select everything by dragging a big selection box, and delete everything that was selected.
Save this as a new file and load it in the modded hammer. Does anything appear out of the blue? That would be content that was originally hidden and was unexpectedly unhidden.
If nothing shows up in the modded Hammer, then it wasn't arbitrarily unhidden this time.
Nothing was arbitrarily unhidden between opening and hiding all in the old hammer and modded hammer, and vice versa. Same thing between same versions.
Yes, the new files do look mostly the same, unlike the files you had posted earlier.
Now the word "hidden" appears 14819 times in both files, <tab>solid 8769 times.
Revisiting the file posted first -- Can you search for the solid with the number 181672 in Hammer? It is hidden in the regular version, shown in the modded version.
https://files.facepunch.com/forum/upload/132786/0e42b58c-130c-4444-803a-d957689eba85/image.png
https://files.facepunch.com/forum/upload/444028/1d7f64d4-b394-4e43-879c-c63b3c92ac07/Capture.PNG
Looks like a normal displacement.
Not sure if I'm being a big dumb, but after installing V1.4, the light_environment entity seems to be broken. I can change the Pitch Yaw Roll values in default hammer, while slammin hammer doesn't display it at all.
https://imgur.com/a/BRyM9qh
If I view a light_environment entity that already has that value filled out, it shows up, but its listed as just "angles".
If I've got something terribly wrong please let me know aha.
You appear to be using an outdated version of my FGD, get the latest one here: ficool2's Overhauled FGD (all entities documentated + icons!) | ..
Awesome, cheers!
Not sure if anyone has had this issue, but my game doesn't run when compiling is complete.
I unticked the "don't run game" box.
How's progress on the proper vertex saving? I have a few projects coming up soon that will really need that feature!
Hello, I come back to talk about my mistake but it's because it's strange! x)
Why do I have the "max vertex" error on your hammer, and not on the garry's mod one?
I went down the lightmap to 32, it works now. x)
Is there a github or something so I can compile my own versions?
Bumping this cause this is kinda urgent! I cannot continue on a project without this!
There is no need for proper vertex saving, since Slartibarty's Hammer precision is already good enough.
I'm also going to clear up a misconception related to Hammerpatch.
As an example, I made a surf ramp and each .vmf was saved and reloaded.
Original brush as reference, before reloading the .vmf:
https://cdn.discordapp.com/attachments/552104214806003712/571274250502012938/unknown.png
Slartibarty's Hammer:
https://files.facepunch.com/forum/upload/111014/8e054e86-12e5-49a7-bae6-fd8d221c27c7/image.png
Stock Hammer without Hammerpatch:
https://files.facepunch.com/forum/upload/111014/015f2c3d-24c0-4d8a-9cf9-5ada427e0a9e/image.png
Stock Hammer WITH Hammerpatch, the .vmf was saved with Hammerpatch and then loaded into Slartibarty's Hammer.
https://files.facepunch.com/forum/upload/111014/512695f2-3444-4eaa-a00f-2d5dab909f86/image.png
As you can tell, Slartibarty's Hammer fared the best of them all in regards to precision. Hammerpatch did absolutely nothing to help
Example number 2 (this one was shown by Slartibarty before)
There's this nice structure.
https://cdn.discordapp.com/attachments/541645073625120789/568850381820395576/unknown.png
After saving and reloading in stock Hammer:
https://cdn.discordapp.com/attachments/541645073625120789/568850443967397890/unknown.png
After saving and reloading in Slartibarty's Hammer:
https://cdn.discordapp.com/attachments/541645073625120789/568850555611381761/unknown.png
Now here is how it looks in Hammerpatch:
https://cdn.discordapp.com/attachments/541645073625120789/568851134178000998/unknown.png
But after loading Hammerpatch's .vmf into Slartibary's Hammer:
https://cdn.discordapp.com/attachments/541645073625120789/568851216101146634/unknown.png
It again, did nothing! Slartibary's Hammer wins again.
Infact, if you tried to compile that mess above, the rounding margin of 0.03 units that VBSP has wouldn't even work here.
You might be thinking that "but Hammerpatch saves .hpverts files... that should help right??". Nope, the compile tools don't read those, effectively making it useless.
If that wasn't bad enough, Hammerpatch deliberately skips invalid solids to hide the fact that it literally doesn't work. Hammer will try to apply a repair operation to the invalid solids, and that causes vertex positions to be moved like a disaster, and Hammerpatch doesn't solve that. Hammerpatch effectively gives a false representation of brushes and should be avoided, Slartibary's Hammer precision already works.
As a bonus, here is an extreme example of how the imprecision that stock Hammer has with or without Hammerpatch.
I made a isosceles triangle that spans the entire length of the Hammer grid.
Stock Hammer:
https://cdn.discordapp.com/attachments/541645073625120789/568857967160459288/unknown.png
Slartibarty's Hammer:
https://cdn.discordapp.com/attachments/541645073625120789/568858035200720943/unknown.png
Stock Hammer managed to get the vertex position 2 units off. Not a great sight.
In conclusion for precision level:
Stock Hammer sucks
Hammerpatch sucks even more
Slartibarty's Hammer wins.
Slapped out a new update, fixed a very strange bug with vrad which meant some commands didn't parse at all. Still not sure how I fixed it.
Replaced -halveao with something more usable, -aoscale, acts as a multiplier for AO, 0.5 = half as much, 2.0 = twice as much.
I know hammerpatch sucks, yes. Still better than normal hammer. And doesn't change the fact that such a feature is necessary for some work I have upcoming.
We are talking about this on Discord, just posting here for Slartibarty to see.
This is a friend making a surf ramp and saving it 5 times in 5.2 of this hammer:
https://files.facepunch.com/forum/upload/821/d08eef6a-54d1-4ec4-b04b-b62d20257996/image.png
This is the same ramp saved 5 times using Momentum Mod's better implementation of hammerpatch.
https://files.facepunch.com/forum/upload/821/2f5d04c8-f4b9-45b9-ae2b-b5a680bd55fd/image.png
Sorry, you need to Log In to post a reply to this thread.