Wondering if anyone has managed to get this working with 5.4.2 (or the latest 5.4.4)? And if so, any chance they could share what they did, as it would be most appreciated. Seems like NT hasn't been active around here for a while (hope they are alright).
This plugin is most useful because it allows you to not just use Hammer, but also Radiant (which I have used on end for many years, it is my go-to for level geometry). So it is a shame to be a bit stuck for the past few months not able to use it with my project, which I updated to 5.4.2 - something I cannot really back track on now.
I need help! Both "5.4.1" & "5.3.1" versions do not work for me as the HammUEr window does not open right away + the icon/button does not appear in the toolbar for me.
I've followed the steps in both engine versions extracting the plugin in a new "Plugins" folder, enabled them in-engine and restarted Unreal multiple times.
I've read in the comments people have said there are issues but if ANYONE could share if it worked for them or if they ran into the same problems, please let me know!
Why do you think I'm getting "Plugin 'HammUEr' failed to load because module 'HammUEr' could not be loaded. There may be an operating system error or the module may not be properly set up." in UE 5.4.1 with HammUEr 2.5+ for 5.4.1 Spring?
I purchased your tool and I am trying to replicate what you did in your video with a HL2 level, but unfortunately, I have no idea how you got there. I tried using bsp source to convert the bsp to vmf and then importing to UE, but what is imported is essentially just rough block out cubes, no materials or textures are working. Can you please roughly explain the steps it took for you to get there? I bought this tool only for this, I am trying to re-imagine half life 2 environments, and I am very stuck.
Given how effective and appreciated this plug-in is, would be brilliant to get a workable version for 5.4.2!
Also, just for anyone's curiosity or food-for-thought; you can create a simple Actor that has an editor function that automatically parents all relevant imported geometry brushes / curves / groups / entities for a particular .map file (via searching a substring of the map name in each object's name), and then zeroes out the relative offset to the parent Actor. This allows you to manipulate said Actor as the origin point, like a group, and move it around within your Level. This solves having to keep manually re-locating every import, if you wanted to shift the origin point, and helps keep each imported .map grouped under one parented Actor.
Hi, sorry to bother you again, but it appears I've run into an issue that seems to be new to the updated version of the 4.27 release - the one where you improved the UV precision.
All the VTF files I export from textures in Unreal turn out unusable now - VTFEdit says they're corrupted. I'm using the exact same pipeline I did before, exporting to DXT-5, making sure that the resolutions are correct and so on. The name of the updated release is "New VTF Lib", so I assume you've made some changes to the VTF import/export process. Either I need to change my settings in some way I haven't figured out, or the exporting is unfortunately indeed broken.
Edit: After reverting to the "Back To School" release I was using before and leaving the settings unchanged, exporting textures works again. Looks like it really is a problem with the "New VTF Lib" release.
Hello again, With some recent work on a map I have been running into some new crashes. The project i am working on runs on 4.27 but I have also ran into the exact same crash on import in UE 5.2, 5.3, and 5.4.1.
I open the HammUER window, choose file, select the map and when I hit "open file" it will crash.
I tried several changes such as removing some larger geometry and func_detail props as well as grouping into one mesh.Tried removing the texture information from the map file. I also split the map into 3 sections and I noticed 2 areas will crash on import but one of the areas works properly however I haven't been able to determine what geometry or difference in the file could be causing this problem. I provided the 3 maps below with the 2 that guarantee a crash for me, they are pretty simple maps as far as brushes so struggling to determine what could be creating such an issue
Could you take a look at this and let me know if I am handling anything incorrectly or need to adjust my setup at all? Thanks as always for the help and I hope everything is going well :)
Is this plugin built with enough windows-only tools to require a rewrite from scratch for macOS/Linux support or is there not enough demand? just a curiosity as i'm a linux main. if i have to, I'll install windows on my college laptop & a mod to remove all telemetry when i get it. it's a pretty modern one, a Framework 13 at that.
Like I _could_ probably build a version of the HammUEr specific static library for linux on an ubuntu machine or whatever and create a version of the plugin for linux (altho that'd be More Hoops that I'm not really looking forward to), but the VTFLib dependency is kinda hard Windows right now. I've been thinking about resurrecting my old homebrew VTF reader/writer, but there's some weirdness in UE5 with that right now. Yes, I know there's at least one linux port of VTFLib, but the one I saw was incomplete.
You're also the first person that's ever really asked the _linux_ question? (The macOS question has been asked I think, but I don't really feel like giving apple a shitton of money for no good reason? so...)
tl;dr: technically feasible, but in reality... probably not gonna happen because I just don't have the time or spoons, sorry
Sadly, I am not able to get the plug-in to load on any 5.4.2 project. Doesn't matter if it is a brand new project or a project converted from a prior version (replacing the existing HammUEr plugin). Love HammUEr, BTW. Brilliant!
I concur with SurlyBird, it appears 5.4.2 does not load the module for the 5.4.1 plugin, and throws an error on launch / creation of a project. Might you be able to update for 5.4.2?
Considering buying this somewhat soon, but i was wondering if your tool worked with source 2 hammer editor (cs2/alyx) and in the case where it is not currently supported, if there was going to be a point in time where it would be. Im guessing this would depend on VTFLib getting support if it doesnt have it already which would be fair as well. Also was wondering if you have a discord server, best regards.
It's an entirely new engine that's still actively in development (and being sold) by Valve, with a completely different design paradigm and format from the classic brush-based ones supported by HammUEr and a whole bunch of third party level editors out there.
Hi! I'm having trouble importing my level. All the textures are set up the correct way (Half Life 1), all material instances are created. But when I'm importing the mesh, the texture isn't shown on the mesh (the assigned material is the right one though). (actually I guess the texture is shown but somehow misaligned, maybe too dense?)
I'm using the Half-Life 1 SDK on steam, Hammer 3.4 and HammUEr 2.5 for 5.3.1
Yeah, that's an Unfortunate UE Thing where stuff sometimes just... sticks around, if you try to import over an existing map that already has an import.
Anyway, given that your map seems pretty simple (just a bunch of walls), can you drop it on pastebin or something and drop a link here so I can try to debug what's happening here?
btw I recently swapped out the texture for one that is more greenish looking and the exported walls in unreal looked green after that. So I suppose that problem is really that those textures are too dense... Are there any known issues with using a old hammer version like 3.4?
Sorry, it took me a few days before I tried to get the file, and by then, it was already gone from wetransfer apparently? And then Medical Bullshit happened, so I figured I might as well ride it out before asking you to upload it again.
To answer your question:
I don't think there's a problem with older hammer versions? But I haven't really done much testing with anything before 4.X
Hi, I've been using your tool for my game and there's one issue I keep running into. A lot of the time, textures become misaligned after being imported - sometimes the offset is really big; other times, the whole texture becomes visibly warped (so it's aligned properly on one end of a face, but then it's off on the other side). I've been unable to determine what this is caused by, since it doesn't seem to happen all the time. Sometimes it gets really bad and I still can't tell why.
If this is an unknown issue, I can provide screenshots, comparisons and so on.
Got your cohost ask. Unfortunately asks aren't DMs, so the only way to respond to one without blasting it to the timeline is basically send back a new ask to the person if they have asks enabled. Anyway, not relevant to your problem.
Which version of HammUEr on which version of UE4 are you using? What kind of map format are you trying to import? With what kind of texture sizes?
I'm guessing you don't have a repeatable repro case that I can try here, where you have a single map that has misaligned textures every time it's imported...
But yes, screenshots and map snippets would help, but if there's no repeatable thing (even if it's "every 50th time I import this file", that's fine), it's unfortunately going to be very hard for me to try and figure out what's wrong, besides "there's a sneaky error in the math, somewhere" which doesn't really narrow it down.
Sorry if I used cohost incorrectly - frankly, I've never heard of it before. Just wanted to get in touch in case you don't check in here anymore, as this is very important to my project.
I'm using HammUEr 2.2 for UE4.27.2. I create maps in Hammer++ (standard HL2 config), so I import them as vmf files.
Regarding the texture warping, I think I have it partially figured out - it seems that faces that aren't rectangles or triangles (even if they're still neat quads) have a chance of being warped to various degrees. The bigger issue is that putting different shapes next to each other can yield slight discrepancies in the texture scale/alignment, which can become increasingly obvious if they're part of, say, one big floor:
I assume this is still due to the geometry not being simple rectangles and triangles everywhere, but making everything so neat requires a lot of additional vertices, and it's unfortunate that a tradeoff like this needs to be made. Still, this is relatively minor compared to the real issue:
Sometimes, textures are just misaligned for seemingly no reason, even on simple rectangles on basic planes (slanted surfaces might make this worse, but I'm not sure). I can copy the exact same mesh to a different location, import both and get different texturing on both of them. Other times, the texture is just clearly off by a large amount:
This becomes a serious problem on small geometry (say, a 2-6 hu wide beam), where you can end up with the completely wrong part of a texture being visible.
I've checked to see if this is affected by brush grouping, texture alignment options (world/face alignment and decimals in the offset) - nope. I kind of feel like this issue has got worse over time, but I don't know what that means - is it the increasing offset from the center of the map as I build outwards? I can copy a brush that was imported correctly before to a different part of the map and get the issue there. I should also point out that my Hammer textures are just proxies and they have a different size (powers of 2, as opposed to more random values in UE - so my real UE texture may be 200x200, while the Hammer version will be 256x256), but I've tried replacing the UE textures with ones of the same size as the Hammer proxies, and the offset was the same, so I'm pretty sure it's not the conversion between sizes that's the problem.
As for import settings, my scale conversion factor is 41 and I'm not using any of the experimental or legacy options, though I have tried most of them, with no change.
The "good" news is that I most certainly can replicate the problem. I don't know what causes it, but once it's there for a face, it's there for good. I can get rid of it sometimes by changing the offset to some arbitrary different value, but that's about it. I'd like to send you a chunk of my map so you could see the examples I showed yourself, but I don't know how to do it here, as all the textures are fully custom.
Thank you for responding so promptly and I hope we can work this out - other than this one issue, this tool has been immeasurably helpful and it's just that one problem preventing it from being perfect for my needs.
Hey, no apologies necessary, not on you but on their weird design.
That looks... weird and bad, yes. The slight texture warping has been mentioned once before years ago, so I was sort of aware it was a possibility (back then), but that was it. The completely offset stuff is definitely not intended, and needs investigation.
Feel free to send me a Cohost Ask with part of your map (or link to a google drive that has it or something if it's too big), and maybe the dimensions for the problem texture(s) so I can generate something appropriate for testing on my end.
Fair warning, my body is doing Bullshit Things again, so I can't promise anything, but I'll _try_ to take a look at it this weekend if I have your stuff.
I've been doing some more testing and while I'm still not 100% sure about this, I think my hunch about distance from the map centre being a factor may have been correct. In parts of the map that are closer to the origin, the texture alignment seems way better. It's still a bit off on some really narrow faces, but in 90% or so of cases it looks pretty spot on.
If I copy the same textured brush to different parts of the map, then import them, it seems like the texture offset indeed gets worse the further away it is from the centre. Again, I can't confirm it with complete certainty, but I'm quite convinced this could be the source of the problem.
Sorry, I haven't really had any time to look into it much yet because of Medical Bullshit, but after some thinking (which is unfortunately all I can do right now) and asking around, you're basically right?
So the way UVs work in the older engines is that they're contiguous, which I sort of keep... but which leads to problems in Unreal, because it Does Not Like That.
The solution is apparently to go into the static meshes that have problems and check "use full precision UVs"?
(which is and absolute pain right now because there's no bulk way of doing this, but if that solves it for you, I can see about making this the default)
Hello! Does this tool also work games that are not in the steam folder? I am trying to import maps from Soldier of Fortune 2 - Double Helix. I have the bought game in the GOG folder and I also have the SOF2 SDK. Does anybody know?
HammUEr doesn't care about the location the files you're trying to import are in, as long as they're in a format it knows and their relative directory structures are intact
I think it would still be nice to have some form of HammUER for source 2. After about 3 months with new CS2 Hammer editor i can export FBX's and work with them in UE but my biggest troubles is dealing with the texturing. I find the biggest workflow is getting it all auto textured. Not sure how possible it is with everything being a mesh now but its been a lot more tedious editing the textures in the data with Blender plugins. HammUER 2.5 slaps too much to not have but the new Source 2 editor is so good as well. My main project i am keeping on Source 1 to use HammUER but wanted to show my interest in it if it could ever be a possibility in the future (even if thats paying for a new plugin for Source 2 instead of an update)
Hey, I think something changed in Unreal where an error now the base material shows up. (Or I am doing it wrong.) I am using Unreal 5.3.1 and HammUEr 2.5 for 5.3.1.
"[SM6] (Node TextureSampleParameter2D) $bumpmap> Found NULL, requires Texture2D"
When I import my materials from HL2, the base material looks normal, but when I open any of the materials I imported, or try to open the map file in Unreal, it changes to this and no materials or textures are properly loaded and look just like the non-textured blocks.
Hm. The sample materials are ancient by now, so something might have broken.
Open up your HammUErBaseMaterial and make sure the $bumpmap parameter still has the flat_normal texture assigned to it, from the error message it looks like it got unassigned?
Hello, having some trouble getting HammUEr 2.5 for 5.2 Summer to show up in my UE5.2 project. I've followed the instructions, but it doesn't seem to get recognized at all nor does it show up in the plugin list to enable. What am I missing?
As stated multiple times, Source 2 support will never be added. Sorry.
Source 2 Hammer has a completely different workflow, and as far as I know comes with its own "export to FBX" option, so... you shouldn't need anything else?
I really love HammUEr so far <3 Is there any potential to batch export the maps? What I am doing is essentially updating all the maps in trenchbroom with my changes and then i will go into my trenchbroom folder and select each map, they already have texture settings complete, then click GO to reimport the brushes. Would be useful to do this for all maps in the folder.
I've had a similar problem it turned out that it was completely unrelated to the complexity of the brush but rather it was related to the texture information. Try resetting all the texture information on the map and try again. that's what fixed it for me once.
I also noticed i ran into crashes when there were far too many objects that are also having their textures replaced on import. What i did was in my editor I group all objects in the map and then import. This of course means its only going to be one object so you have to make more changes from the editor but i found most of my crashes came from not having them grouped enough. Try experimenting with grouping things you know you won't need to tweak as much.
Hm. Please pastebin or something a map (or at least a couple of brushes of one) that has this crash so I can try to fix this now that I'm finally out of the hospital
Currently when i import this map "LavaFalls.map" from Trenchbroom it will crash about 70% progress through the importing of the meshes. I also tried grouping all the meshes from the map into 1 group and importing that way which has resolved problems for me with other trenchbroom maps but didn't seem to help here.
I wanted to post an update of something i actually found resolved this crash i posted above. I have imported this LavaFalls.map file many times and it has generated the mesh and uses the auto replace existing mesh in the HammUER settings.
It started crashing on me over time of updating the map meshes would make the import process crash. Once i hit open map in the hammUER window i click the X to reset the meshes directory and let it generate the meshes again in this new directory and now the map is no longer crashing. (no changes made to the source map file) Hoping this helps figure out what the problem is. Feel free to DM me on discord if you need any more info
Yeah, I was just going to say "can't be the map itself, since that seems to load fine no matter what options I use"
The callstack makes it seem like it happens when we tell Unreal "Hey, we changed the contents of this package, it's dirty now", so it makes sense that it happens when you've done it a couple of times in the same content directory...
Wonder what I can do about this... hm.
(also, thank you for asking, I'm not really feeling a lot better yet, I've got a long way to go with physical rehab and shit, but hopefully we'll get there... eventually)
Thanks for replying again. Luckily since clicking the X to reset directory seems to solve it, it has worked for me everytime a map has ran into this. My theory is if I add too many or remove too many meshes then it will inevitably occur. (I use the replace existing meshes option but the crash will occur without it as well)
Since I know this avoids the problem its not the worst thing ever but it does kind of suck to have everything crash on import "randomly". Sometimes the map will be importing consecutively and then this pops up. If you need any other kind of information potentially let me know I am always down to help. Even with such a problem I would just like to add that HAMMUER has been game changing for working on Unreal Engine projects and has really changed how i work on level design and even given me a lot of extra motivation to keep working at it. Thanks for building such a great tool <3
i wrote this 4 months ago, but i would really love a community, a discord or someplace where I can ask a couple of question and troubleshoot some issues I am having, lots of love <3
I'm having trouble getting the texture export from UE4.27 to Hammer to work. All the materials just end up showing up as the missing texture chessboard in Hammer.
Strange, I just tried it again with the L4D2 version of Hammer.
I export from HammUEr to my SteamLibrary\steamapps\common\Left 4 Dead 2\left4dead2\materials directory, which creates a HammUEr directory under it. Then when I start the L4D2 tools and Hammer, It Just Works. I can filter by hammuer in the browser, and the textures match their Unreal Engine originals.
Is there a mismatch between the directory you put them in and what the .vmt files reference? Because those include the HammUEr\ prefix, so if you changed the directory name, you might need to edit the .vmt files as well.
Thanks for the reply, but it turned out the problem was my fault. I didn't realise the materials I was trying to export used textures that didn't comply with Source's resolution requirements (they weren't powers of 2). I just had to resize the textures and now everything works fine. On a side note, the manual states that thumbnails in Hammer's texture browser don't work, but they actually do work just fine. The only issue I've noticed so far while working with the tool is that textures on really thin faces (2 units wide or so) get a little broken when imported to UE - part of the texture seems to disappear, leaving a small "gap" near the edge of the face.
HammUEr will never support skeletal meshes by design, sorry. Anything skinned/animated gets imported as a static mesh to allow you to use it to get your measurements right, but that's as far as it will ever go.
← Return to Unreal Engine plugin
Comments
Log in with itch.io to leave a comment.
Wondering if anyone has managed to get this working with 5.4.2 (or the latest 5.4.4)? And if so, any chance they could share what they did, as it would be most appreciated. Seems like NT hasn't been active around here for a while (hope they are alright).
This plugin is most useful because it allows you to not just use Hammer, but also Radiant (which I have used on end for many years, it is my go-to for level geometry). So it is a shame to be a bit stuck for the past few months not able to use it with my project, which I updated to 5.4.2 - something I cannot really back track on now.
I need help! Both "5.4.1" & "5.3.1" versions do not work for me as the HammUEr window does not open right away + the icon/button does not appear in the toolbar for me.
I've followed the steps in both engine versions extracting the plugin in a new "Plugins" folder, enabled them in-engine and restarted Unreal multiple times.
I've read in the comments people have said there are issues but if ANYONE could share if it worked for them or if they ran into the same problems, please let me know!
Running my project via Visual Studio, these errors appear in the log:
LogClass: Error: FloatProperty FHammuerOutput::delay is not initialized properly. Module:HammUErRuntime File:Public/HammUErRuntimeClasses.h
LogClass: Error: IntProperty FHammuerOutput::fireTimes is not initialized properly. Module:HammUErRuntime File:Public/HammUErRuntimeClasses.h
LogClass: Display: 2 Uninitialized script struct members found including 0 object properties
LogAutomationTest: Error: UObject.Class AttemptToFindUninitializedScriptStructMembers will be marked as failing due to errors being logged
LogAutomationTest: Error: LogClass: FloatProperty FHammuerOutput::delay is not initialized properly. Module:HammUErRuntime File:Public/HammUErRuntimeClasses.h
LogAutomationTest: Error: LogClass: IntProperty FHammuerOutput::fireTimes is not initialized properly. Module:HammUErRuntime File:Public/HammUErRuntimeClasses.h
is there any way to get I refund for this? its not really working for what im trying to do
Could you explain what you are trying to do?
42 fucking American brouzouf
Why do you think I'm getting "Plugin 'HammUEr' failed to load because module 'HammUEr' could not be loaded. There may be an operating system error or the module may not be properly set up." in UE 5.4.1 with HammUEr 2.5+ for 5.4.1 Spring?
I suppose this is a version problem, because I can switch to UE 5.3.2 and install HammUEr 2.5 for 5.3.1 without issue.
Hello,
I purchased your tool and I am trying to replicate what you did in your video with a HL2 level, but unfortunately, I have no idea how you got there. I tried using bsp source to convert the bsp to vmf and then importing to UE, but what is imported is essentially just rough block out cubes, no materials or textures are working. Can you please roughly explain the steps it took for you to get there? I bought this tool only for this, I am trying to re-imagine half life 2 environments, and I am very stuck.
Given how effective and appreciated this plug-in is, would be brilliant to get a workable version for 5.4.2!
Also, just for anyone's curiosity or food-for-thought; you can create a simple Actor that has an editor function that automatically parents all relevant imported geometry brushes / curves / groups / entities for a particular .map file (via searching a substring of the map name in each object's name), and then zeroes out the relative offset to the parent Actor. This allows you to manipulate said Actor as the origin point, like a group, and move it around within your Level. This solves having to keep manually re-locating every import, if you wanted to shift the origin point, and helps keep each imported .map grouped under one parented Actor.
Cannot use this plugin until an update for 5.4.2 is released, which was only recently purchased for USD$42.
Hi, sorry to bother you again, but it appears I've run into an issue that seems to be new to the updated version of the 4.27 release - the one where you improved the UV precision.
All the VTF files I export from textures in Unreal turn out unusable now - VTFEdit says they're corrupted. I'm using the exact same pipeline I did before, exporting to DXT-5, making sure that the resolutions are correct and so on. The name of the updated release is "New VTF Lib", so I assume you've made some changes to the VTF import/export process. Either I need to change my settings in some way I haven't figured out, or the exporting is unfortunately indeed broken.
Edit: After reverting to the "Back To School" release I was using before and leaving the settings unchanged, exporting textures works again. Looks like it really is a problem with the "New VTF Lib" release.
Hello again,
With some recent work on a map I have been running into some new crashes. The project i am working on runs on 4.27 but I have also ran into the exact same crash on import in UE 5.2, 5.3, and 5.4.1.
I open the HammUER window, choose file, select the map and when I hit "open file" it will crash.
I tried several changes such as removing some larger geometry and func_detail props as well as grouping into one mesh.Tried removing the texture information from the map file.
I also split the map into 3 sections and I noticed 2 areas will crash on import but one of the areas works properly however I haven't been able to determine what geometry or difference in the file could be causing this problem. I provided the 3 maps below with the 2 that guarantee a crash for me, they are pretty simple maps as far as brushes so struggling to determine what could be creating such an issue
Crash map 1https://gist.githubusercontent.com/jamacanbacn/887ba8a304c146a05db150a41c2851af/...
Crash map 2https://gist.githubusercontent.com/jamacanbacn/f42bd5105bd90d917c48a891ee7cdf89/...
Properly Imported map https://gist.githubusercontent.com/jamacanbacn/7dc7d15338c1b7dd27a76f97397fb9d3/...
HammUER settings ini https://gist.github.com/jamacanbacn/d88fe7cd926ee20d8cb85880c854520c
```
Unhandled Exception: 0xe06d7363
KERNELBASE
VCRUNTIME140
msvcp140
UE4Editor_HammUEr!std::stof()
UE4Editor_HammUEr!MAPLoader::PhaseOne()
UE4Editor_HammUEr!SHammerDialogWidget::RunFirstPhase() [D:\UnrealProjects\VillageKS\Plugins\HammUEr\Source\HammUEr\Private\SHammerDialogWidget.cpp:946]
UE4Editor_HammUEr!TBaseSPMethodDelegateInstance<0,SHammerDialogWidget,0,FReply __cdecl(void),FDefaultDelegateUserPolicy>::Execute() [D:\UE_4.27\Engine\Source\Runtime\Core\Public\Delegates\DelegateInstancesImpl.h:290]
UE4Editor_Slate
UE4Editor_Slate
UE4Editor_Slate
UE4Editor_Slate
UE4Editor_Slate
UE4Editor_Slate
UE4Editor_ApplicationCore
UE4Editor_ApplicationCore
UE4Editor_ApplicationCore
UE4Editor_ApplicationCore
user32
user32
UE4Editor_ApplicationCore
UE4Editor
UE4Editor
UE4Editor
UE4Editor
UE4Editor
UE4Editor
kernel32
ntdll
```
Could you take a look at this and let me know if I am handling anything incorrectly or need to adjust my setup at all? Thanks as always for the help and I hope everything is going well :)
Is this plugin built with enough windows-only tools to require a rewrite from scratch for macOS/Linux support or is there not enough demand? just a curiosity as i'm a linux main. if i have to, I'll install windows on my college laptop & a mod to remove all telemetry when i get it. it's a pretty modern one, a Framework 13 at that.
Both, kinda?
Like I _could_ probably build a version of the HammUEr specific static library for linux on an ubuntu machine or whatever and create a version of the plugin for linux (altho that'd be More Hoops that I'm not really looking forward to), but the VTFLib dependency is kinda hard Windows right now. I've been thinking about resurrecting my old homebrew VTF reader/writer, but there's some weirdness in UE5 with that right now. Yes, I know there's at least one linux port of VTFLib, but the one I saw was incomplete.
You're also the first person that's ever really asked the _linux_ question?
(The macOS question has been asked I think, but I don't really feel like giving apple a shitton of money for no good reason? so...)
tl;dr: technically feasible, but in reality... probably not gonna happen because I just don't have the time or spoons, sorry
Do you have an ETA for an Unreal 5.4 version, or is the 5.3.1 version already compatible?
Cheers.
... oops.
That "4.5.1" I added a month ago should, of course, have been 5.4.1, sorry.
(and yes, it should also work as-is for 5.4.2)
Haha no no problem, thanks for the quick reply and info - much appreciated!
Sadly, I am not able to get the plug-in to load on any 5.4.2 project. Doesn't matter if it is a brand new project or a project converted from a prior version (replacing the existing HammUEr plugin). Love HammUEr, BTW. Brilliant!
I have the same issue, but also on the 5.3 version.
I concur with SurlyBird, it appears 5.4.2 does not load the module for the 5.4.1 plugin, and throws an error on launch / creation of a project. Might you be able to update for 5.4.2?
Yep, same for me.
Considering buying this somewhat soon, but i was wondering if your tool worked with source 2 hammer editor (cs2/alyx) and in the case where it is not currently supported, if there was going to be a point in time where it would be. Im guessing this would depend on VTFLib getting support if it doesnt have it already which would be fair as well. Also was wondering if you have a discord server, best regards.
Source 2 support will never be added I'm afraid.
It's an entirely new engine that's still actively in development (and being sold) by Valve, with a completely different design paradigm and format from the classic brush-based ones supported by HammUEr and a whole bunch of third party level editors out there.
Sorry.
I want this because I love hammer and is learning Unreal Engine but good god $42 sounds unbelievably over-priced.
I might buy it, but like for this price is it really worth it?
I'm having trouble importing my level. All the textures are set up the correct way (Half Life 1), all material instances are created.
But when I'm importing the mesh, the texture isn't shown on the mesh (the assigned material is the right one though).
(actually I guess the texture is shown but somehow misaligned, maybe too dense?)
I'm using the Half-Life 1 SDK on steam, Hammer 3.4 and HammUEr 2.5 for 5.3.1
Also sometimes I'm getting this error. Don't really know why, the .map file only consists of those brushes
Might also be important:
I'm getting this message when selecting a .map file and pressing "Open File" in the HammUEr tab.
Neither Yes or No will change anything about the above mentioned result.
Did you ever fix this?
Yeah, that's an Unfortunate UE Thing where stuff sometimes just... sticks around, if you try to import over an existing map that already has an import.
Anyway, given that your map seems pretty simple (just a bunch of walls), can you drop it on pastebin or something and drop a link here so I can try to debug what's happening here?
Sure! Here it is:
https://we.tl/t-neJyAhtZiU
...and thanks for the super quick response :)
btw I recently swapped out the texture for one that is more greenish looking and the exported walls in unreal looked green after that. So I suppose that problem is really that those textures are too dense...
Are there any known issues with using a old hammer version like 3.4?
Have you found a solution yet?
Sorry, it took me a few days before I tried to get the file, and by then, it was already gone from wetransfer apparently?
And then Medical Bullshit happened, so I figured I might as well ride it out before asking you to upload it again.
To answer your question:
I don't think there's a problem with older hammer versions? But I haven't really done much testing with anything before 4.X
Yes, WeTransfer only saves it a few days.
Should I upload it again now?
Hi, I've been using your tool for my game and there's one issue I keep running into. A lot of the time, textures become misaligned after being imported - sometimes the offset is really big; other times, the whole texture becomes visibly warped (so it's aligned properly on one end of a face, but then it's off on the other side). I've been unable to determine what this is caused by, since it doesn't seem to happen all the time. Sometimes it gets really bad and I still can't tell why.
If this is an unknown issue, I can provide screenshots, comparisons and so on.
Got your cohost ask.
Unfortunately asks aren't DMs, so the only way to respond to one without blasting it to the timeline is basically send back a new ask to the person if they have asks enabled.
Anyway, not relevant to your problem.
Which version of HammUEr on which version of UE4 are you using?
What kind of map format are you trying to import?
With what kind of texture sizes?
I'm guessing you don't have a repeatable repro case that I can try here, where you have a single map that has misaligned textures every time it's imported...
But yes, screenshots and map snippets would help, but if there's no repeatable thing (even if it's "every 50th time I import this file", that's fine), it's unfortunately going to be very hard for me to try and figure out what's wrong, besides "there's a sneaky error in the math, somewhere" which doesn't really narrow it down.
Sorry if I used cohost incorrectly - frankly, I've never heard of it before. Just wanted to get in touch in case you don't check in here anymore, as this is very important to my project.
I'm using HammUEr 2.2 for UE4.27.2. I create maps in Hammer++ (standard HL2 config), so I import them as vmf files.
Regarding the texture warping, I think I have it partially figured out - it seems that faces that aren't rectangles or triangles (even if they're still neat quads) have a chance of being warped to various degrees. The bigger issue is that putting different shapes next to each other can yield slight discrepancies in the texture scale/alignment, which can become increasingly obvious if they're part of, say, one big floor:
I assume this is still due to the geometry not being simple rectangles and triangles everywhere, but making everything so neat requires a lot of additional vertices, and it's unfortunate that a tradeoff like this needs to be made. Still, this is relatively minor compared to the real issue:
Sometimes, textures are just misaligned for seemingly no reason, even on simple rectangles on basic planes (slanted surfaces might make this worse, but I'm not sure). I can copy the exact same mesh to a different location, import both and get different texturing on both of them. Other times, the texture is just clearly off by a large amount:
This becomes a serious problem on small geometry (say, a 2-6 hu wide beam), where you can end up with the completely wrong part of a texture being visible.
I've checked to see if this is affected by brush grouping, texture alignment options (world/face alignment and decimals in the offset) - nope. I kind of feel like this issue has got worse over time, but I don't know what that means - is it the increasing offset from the center of the map as I build outwards? I can copy a brush that was imported correctly before to a different part of the map and get the issue there. I should also point out that my Hammer textures are just proxies and they have a different size (powers of 2, as opposed to more random values in UE - so my real UE texture may be 200x200, while the Hammer version will be 256x256), but I've tried replacing the UE textures with ones of the same size as the Hammer proxies, and the offset was the same, so I'm pretty sure it's not the conversion between sizes that's the problem.
As for import settings, my scale conversion factor is 41 and I'm not using any of the experimental or legacy options, though I have tried most of them, with no change.
The "good" news is that I most certainly can replicate the problem. I don't know what causes it, but once it's there for a face, it's there for good. I can get rid of it sometimes by changing the offset to some arbitrary different value, but that's about it. I'd like to send you a chunk of my map so you could see the examples I showed yourself, but I don't know how to do it here, as all the textures are fully custom.
Thank you for responding so promptly and I hope we can work this out - other than this one issue, this tool has been immeasurably helpful and it's just that one problem preventing it from being perfect for my needs.
Hey, no apologies necessary, not on you but on their weird design.
That looks... weird and bad, yes.
The slight texture warping has been mentioned once before years ago, so I was sort of aware it was a possibility (back then), but that was it. The completely offset stuff is definitely not intended, and needs investigation.
Feel free to send me a Cohost Ask with part of your map (or link to a google drive that has it or something if it's too big), and maybe the dimensions for the problem texture(s) so I can generate something appropriate for testing on my end.
Fair warning, my body is doing Bullshit Things again, so I can't promise anything, but I'll _try_ to take a look at it this weekend if I have your stuff.
I'll try to take a stab at it this weekend.
I've been doing some more testing and while I'm still not 100% sure about this, I think my hunch about distance from the map centre being a factor may have been correct. In parts of the map that are closer to the origin, the texture alignment seems way better. It's still a bit off on some really narrow faces, but in 90% or so of cases it looks pretty spot on.
If I copy the same textured brush to different parts of the map, then import them, it seems like the texture offset indeed gets worse the further away it is from the centre. Again, I can't confirm it with complete certainty, but I'm quite convinced this could be the source of the problem.
Sorry, I haven't really had any time to look into it much yet because of Medical Bullshit, but after some thinking (which is unfortunately all I can do right now) and asking around, you're basically right?
So the way UVs work in the older engines is that they're contiguous, which I sort of keep... but which leads to problems in Unreal, because it Does Not Like That.
The solution is apparently to go into the static meshes that have problems and check "use full precision UVs"?
(which is and absolute pain right now because there's no bulk way of doing this, but if that solves it for you, I can see about making this the default)
Hello! Does this tool also work games that are not in the steam folder? I am trying to import maps from Soldier of Fortune 2 - Double Helix. I have the bought game in the GOG folder and I also have the SOF2 SDK. Does anybody know?
HammUEr doesn't care about the location the files you're trying to import are in, as long as they're in a format it knows and their relative directory structures are intact
I think it would still be nice to have some form of HammUER for source 2. After about 3 months with new CS2 Hammer editor i can export FBX's and work with them in UE but my biggest troubles is dealing with the texturing. I find the biggest workflow is getting it all auto textured. Not sure how possible it is with everything being a mesh now but its been a lot more tedious editing the textures in the data with Blender plugins.
HammUER 2.5 slaps too much to not have but the new Source 2 editor is so good as well. My main project i am keeping on Source 1 to use HammUER but wanted to show my interest in it if it could ever be a possibility in the future (even if thats paying for a new plugin for Source 2 instead of an update)
Hey, I think something changed in Unreal where an error now the base material shows up. (Or I am doing it wrong.) I am using Unreal 5.3.1 and HammUEr 2.5 for 5.3.1.
"[SM6] (Node TextureSampleParameter2D) $bumpmap> Found NULL, requires Texture2D"
When I import my materials from HL2, the base material looks normal, but when I open any of the materials I imported, or try to open the map file in Unreal, it changes to this and no materials or textures are properly loaded and look just like the non-textured blocks.
Before:
After:
I really appreciate your work man <3
Do you happen to have Discord?
Hm.
The sample materials are ancient by now, so something might have broken.
Open up your HammUErBaseMaterial and make sure the $bumpmap parameter still has the flat_normal texture assigned to it, from the error message it looks like it got unassigned?
The materials work now! Thank you so much!
Hello, having some trouble getting HammUEr 2.5 for 5.2 Summer to show up in my UE5.2 project. I've followed the instructions, but it doesn't seem to get recognized at all nor does it show up in the plugin list to enable. What am I missing?
Thanks!
Strange.
Is the HammUEr.uplugin file in [your project directory]\Plugins\HammUEr?
Source 2 please!
we need source2 !
As stated multiple times, Source 2 support will never be added.
Sorry.
Source 2 Hammer has a completely different workflow, and as far as I know comes with its own "export to FBX" option, so... you shouldn't need anything else?
I really love HammUEr so far <3
Is there any potential to batch export the maps?
What I am doing is essentially updating all the maps in trenchbroom with my changes and then i will go into my trenchbroom folder and select each map, they already have texture settings complete, then click GO to reimport the brushes. Would be useful to do this for all maps in the folder.
I'm trying to import some of my Quake .maps, but the plugin just keeps crashing. Anything more complex than a few brushes makes it crash.
I even took one of my maps and got rid of all the func_details that were off grid, but I can't get it to properly import it. I'm at a loss here.
This is the error I keep getting, based on the logs. I tried switching from Dx12 to Dx11 just in case but it didn't help.
==========================================
Unhandled Exception: 0xe06d7363
KERNELBASE!UnknownFunction []
VCRUNTIME140!UnknownFunction []
msvcp140!UnknownFunction []
UnrealEditor_HammUEr!UnknownFunction [] (x4)
UnrealEditor_Slate!UnknownFunction [] (x7)
UnrealEditor_ApplicationCore!UnknownFunction [] (x4)
user32!UnknownFunction [] (x2)
InkObj!UnknownFunction []
atlthunk!UnknownFunction []
=============================================
Any help would be appreciated.
I've had a similar problem it turned out that it was completely unrelated to the complexity of the brush but rather it was related to the texture information. Try resetting all the texture information on the map and try again. that's what fixed it for me once.
As someone else said double check texture info.
I also noticed i ran into crashes when there were far too many objects that are also having their textures replaced on import. What i did was in my editor I group all objects in the map and then import. This of course means its only going to be one object so you have to make more changes from the editor but i found most of my crashes came from not having them grouped enough. Try experimenting with grouping things you know you won't need to tweak as much.
Hm.
Please pastebin or something a map (or at least a couple of brushes of one) that has this crash so I can try to fix this now that I'm finally out of the hospital
Hi! I hope you are feeling better lately :)
Currently when i import this map "LavaFalls.map" from Trenchbroom it will crash about 70% progress through the importing of the meshes.
I also tried grouping all the meshes from the map into 1 group and importing that way which has resolved problems for me with other trenchbroom maps but didn't seem to help here.
I get the following crash from the engine:
```
Unhandled Exception: EXCEPTION_ACCESS_VIOLATION 0x00000000ffffffff
UnrealEditor_Engine
UnrealEditor_Engine
UnrealEditor_Core
UnrealEditor_Core
UnrealEditor_Engine
UnrealEditor_Engine
UnrealEditor_Engine
UnrealEditor_Engine
UnrealEditor_Engine
UnrealEditor_CoreUObject
UnrealEditor_HammUEr_0001!MapFileLoader::ImportBrush() [Z:\_UnrealEngine\RocketCascade\Plugins\HammUEr\Source\HammUEr\Private\MapFileLoader.cpp:2519]
UnrealEditor_HammUEr_0001!MapFileLoader::ImportIntoWorld() [Z:\_UnrealEngine\RocketCascade\Plugins\HammUEr\Source\HammUEr\Private\MapFileLoader.cpp:2696]
UnrealEditor_HammUEr_0001!SHammerDialogWidget::RunConvert() [Z:\_UnrealEngine\RocketCascade\Plugins\HammUEr\Source\HammUEr\Private\SHammerDialogWidget.cpp:1206]
UnrealEditor_HammUEr_0001!TBaseSPMethodDelegateInstance<0,SHammerDialogWidget,1,FReply __cdecl(void),FDefaultDelegateUserPolicy>::Execute() [T:\UE_5.2\Engine\Source\Runtime\Core\Public\Delegates\DelegateInstancesImpl.h:275]
UnrealEditor_Slate
UnrealEditor_Slate
UnrealEditor_Slate
UnrealEditor_Slate
UnrealEditor_Slate
UnrealEditor_Slate
UnrealEditor_Slate
UnrealEditor_ApplicationCore
UnrealEditor_ApplicationCore
UnrealEditor_ApplicationCore
UnrealEditor_ApplicationCore
user32
user32
InkObj
atlthunk
user32
user32
UnrealEditor_ApplicationCore
UnrealEditor
UnrealEditor
UnrealEditor
UnrealEditor
UnrealEditor
UnrealEditor
kernel32
ntdll
https://www.dropbox.com/scl/fi/qrfaunqvdtnc89p7i86q3/HammUER-LavaFalls-CrashDump...```
I wanted to post an update of something i actually found resolved this crash i posted above. I have imported this LavaFalls.map file many times and it has generated the mesh and uses the auto replace existing mesh in the HammUER settings.
It started crashing on me over time of updating the map meshes would make the import process crash. Once i hit open map in the hammUER window i click the X to reset the meshes directory and let it generate the meshes again in this new directory and now the map is no longer crashing. (no changes made to the source map file)
Hoping this helps figure out what the problem is. Feel free to DM me on discord if you need any more info
Yeah, I was just going to say "can't be the map itself, since that seems to load fine no matter what options I use"
The callstack makes it seem like it happens when we tell Unreal "Hey, we changed the contents of this package, it's dirty now", so it makes sense that it happens when you've done it a couple of times in the same content directory...
Wonder what I can do about this... hm.
(also, thank you for asking, I'm not really feeling a lot better yet, I've got a long way to go with physical rehab and shit, but hopefully we'll get there... eventually)
Thanks for replying again. Luckily since clicking the X to reset directory seems to solve it, it has worked for me everytime a map has ran into this. My theory is if I add too many or remove too many meshes then it will inevitably occur. (I use the replace existing meshes option but the crash will occur without it as well)
Since I know this avoids the problem its not the worst thing ever but it does kind of suck to have everything crash on import "randomly". Sometimes the map will be importing consecutively and then this pops up. If you need any other kind of information potentially let me know I am always down to help.
Even with such a problem I would just like to add that HAMMUER has been game changing for working on Unreal Engine projects and has really changed how i work on level design and even given me a lot of extra motivation to keep working at it. Thanks for building such a great tool <3
i wrote this 4 months ago, but i would really love a community, a discord or someplace where I can ask a couple of question and troubleshoot some issues I am having, lots of love <3
I'm having trouble getting the texture export from UE4.27 to Hammer to work. All the materials just end up showing up as the missing texture chessboard in Hammer.
Strange, I just tried it again with the L4D2 version of Hammer.
I export from HammUEr to my SteamLibrary\steamapps\common\Left 4 Dead 2\left4dead2\materials directory, which creates a HammUEr directory under it.
Then when I start the L4D2 tools and Hammer, It Just Works.
I can filter by hammuer in the browser, and the textures match their Unreal Engine originals.
Is there a mismatch between the directory you put them in and what the .vmt files reference? Because those include the HammUEr\ prefix, so if you changed the directory name, you might need to edit the .vmt files as well.
Thanks for the reply, but it turned out the problem was my fault. I didn't realise the materials I was trying to export used textures that didn't comply with Source's resolution requirements (they weren't powers of 2). I just had to resize the textures and now everything works fine. On a side note, the manual states that thumbnails in Hammer's texture browser don't work, but they actually do work just fine. The only issue I've noticed so far while working with the tool is that textures on really thin faces (2 units wide or so) get a little broken when imported to UE - part of the texture seems to disappear, leaving a small "gap" near the edge of the face.
Does it permits to import ragdolls as Skeletal Meshes ?
HammUEr will never support skeletal meshes by design, sorry.
Anything skinned/animated gets imported as a static mesh to allow you to use it to get your measurements right, but that's as far as it will ever go.