Hey. Nice work! I'm looking into trying to get some old Enemy Territory maps into UE and this looks like what I need. I tried the Not Fucking Dead (best name!) versions on 5.4.4 and 5.5.1 and they seem to mount. I enabled them but no settings appear. No Widget and also no HammUEr button on the toolbar. Can I force it somehow? The output log looks ok and says "mounted"
Just to double-check: after the UI change in UE5, HammUEr (and all my plugins, really) only has the menu option at the bottom of the Window list, which definitely should exist?
I was... annoyed that they changed up the whole toolbar button code with the UI changes and just broke it, but not the menu option, and never really... bothered to try bringing it back, since nobody really seemed to be missing it? (I think there might also not have been like, an example of the New Correct Way in the first version of 5.0, but that might just be my faulty memory)
Sorry. Hopefully that unblocks you, at least. If not, we have... deeper problems.
Maybe I'll re-add it down the line somewhere.
Also: HammUEr doesn't really touch any of the UE BSP stuff (because it has always been a massive pain), everything gets imported as static meshes
Ahh Ok. I wasn't even looking in the Window menu. Sorry. My mistake. I was to strict following the manual. I'm aware of the toolbar issues. I was at Epic during the 5 launch until last year working on engine content, demos and tech talks. After tinkering with it today in 4.27 I realized its static meshes. Got something running which makes me quite happy. As occlusion is a bit of a problem with all the small pieces now, I'm trying to use the old precompiled visibility route before looking into merging more stuff together. I'll test UE5 tomorrow. Thanks for the fast reply!
In my experience, you need to do quite a bit of grouping in Hammer before importing your map, otherwise the default culling can't keep up with all the separate parts. Keep in mind that every brush you import is both a new static mesh actor and a new asset, so optimisation goes out the window if you just import everything separately.
Contrary to what some people might have thought, no, I didn't abandon development.
If and when I eventually decide to stop updating (with UE 6 or whenever Tim decides to turn everything into the Metaverse Circus of Only Fortnite Game Modes), I will explicitly say so and remove the ability to buy the plugin.
The last two years haven't been fun for me. I have multiple chronic medical conditions that have landed me in the hospital, or serious rehabilitation for long stretches. At the end of the day, I'm usually too exhausted or even physically unable to do... anything, even if I want to, so I need to take it one day at a time. That's my new reality. tl;dr: Everything takes a lot more time than it used to.
So, I'm sorry it took this long for me to post the 5.5 update, and that I skipped the 5.4.1+ ones (which I thought I tested with the live 5.4.1 binaries which seemed to work fine at the time and didn't require anything from me, like back with the 5.3.1 on 5.3.2 version, but perhaps I only tested rebuilds. Things got... hazy for a while), but I couldn't give you a timeline for fixes, or promise anything until it was actually done, so... yeah.
Anyway, the new Not Fucking Dead update should fix all the listed problems from the last... 6 months.
Hi NTE, when I saw the response in my Gmail notification and (particularly) the title of the newly updated files, I couldn't help but have a chuckle. Really appreciate the updates as I am sure the cohort of us here are, and a very pleasant surprise it is.
But of course, you needn't apologise for delays, understanding that life has changed a bit for you which is just an unfair predicament that no one should have to go through. As the title you've so fittingly chosen reflects a tenacity that is admirable, and I wish you well.
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 don't think NT Entertainment is working on this plugin anymore. The latest 4.27.2 version doesn't work properly either. The only way I was able to get a hold of him in the past was through some knockoff Twitter platform which has been, unsurprisingly, shut down already.
Thank you for the update; I didn't mean to come off as impatient or anything like that - it's just that I rely heavily on HammUEr for a major project and the fact that I couldn't use the full precision UV import feature you added at my request without breaking texture exporting was rather frustrating. After some quick testing, I can confirm that both features work properly in the new release - and what a time saver this is!
I assume you'll probably want to move away from UE4 at this point anyway (I have considered migrating my project to UE5, but decided against it), so I'll understand if this is the last update for the old engine. However, if you were to continue development for it, there is one last feature that, having spent a lot of time with my HammUEr workflow, I think would be extremely useful: smoothing group import. The angle threshold-based smoothing is not terrible, but I do find it rather limiting. Being able to import smoothing groups from Hammer would eliminate this problem; however, I realise that if this were an easy thing to implement, you probably would have done it already. I just wanted to put it out there that this feature would make the plugin absolutely perfect in my eyes, and I imagine others would concur.
Anyway, thanks again for the fix (I've spotted some of the new options here and there and they are also appreciated) and merry Christmas.
Took a quick look at the code, because I definitely remember reading the smoothing groups. Ran into a "This is a confusing mess for a lot of users causing them to complain about weirdness, so let's just calculate our own and be done with the whole thing" comment, so... Yeah. Maybe if you can give me like a couple of "here's some vmfs, with images of what I want these things to look like" examples, I can do some kind of "no, really, I want to use the smoothing groups" override option down the line? Maybe.
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.
Not sure which video you watched, but you need to import the materials and textures first, as explained in this video (it's for old pre-Source 2 CSGO, but the steps should be the same)
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 :)
Sorry it took so long for me to get back to you on this.
So the problem here was that a decade ago (oh god has it been that long) when HammUEr was created, all my test maps were Proper Quake Maps, which were nicely cut down to a handful of digits after the period, so I was all "oh, cool, I just need to use floats for this".
Enter your test maps, which are Technically Quake Maps But Not Really and have super tiny values like
8.552847072295026e-49
(that's 0.[48 zeroes]8552etc) in them, which float takes one look at and goes "nope".
The new Not Fucking Dead update has been rewritten to use doubles for everything, as it always should have, and loads your crashing maps without problems.
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?
← Return to Unreal Engine plugin
Comments
Log in with itch.io to leave a comment.
Hey. Nice work! I'm looking into trying to get some old Enemy Territory maps into UE and this looks like what I need.
I tried the Not Fucking Dead (best name!) versions on 5.4.4 and 5.5.1 and they seem to mount. I enabled them but no settings appear. No Widget and also no HammUEr button on the toolbar. Can I force it somehow? The output log looks ok and says "mounted"
It shows up in 4.27 tho.
I mean BSPs got neglected in UE5 anyhow. So is it maybe wiser to use a 4.27 project to import and then do some stuff on my end to migrate it to 5 ?
Just to double-check: after the UI change in UE5, HammUEr (and all my plugins, really) only has the menu option at the bottom of the Window list, which definitely should exist?
I was... annoyed that they changed up the whole toolbar button code with the UI changes and just broke it, but not the menu option, and never really... bothered to try bringing it back, since nobody really seemed to be missing it? (I think there might also not have been like, an example of the New Correct Way in the first version of 5.0, but that might just be my faulty memory)
Sorry.
Hopefully that unblocks you, at least.
If not, we have... deeper problems.
Maybe I'll re-add it down the line somewhere.
Also: HammUEr doesn't really touch any of the UE BSP stuff (because it has always been a massive pain), everything gets imported as static meshes
Ahh Ok. I wasn't even looking in the Window menu. Sorry. My mistake. I was to strict following the manual. I'm aware of the toolbar issues. I was at Epic during the 5 launch until last year working on engine content, demos and tech talks.
After tinkering with it today in 4.27 I realized its static meshes. Got something running which makes me quite happy.
As occlusion is a bit of a problem with all the small pieces now, I'm trying to use the old precompiled visibility route before looking into merging more stuff together.
I'll test UE5 tomorrow.
Thanks for the fast reply!
In my experience, you need to do quite a bit of grouping in Hammer before importing your map, otherwise the default culling can't keep up with all the separate parts. Keep in mind that every brush you import is both a new static mesh actor and a new asset, so optimisation goes out the window if you just import everything separately.
It's indeed in the Window menu. Really sorry. I overlooked it.
Fuck it I'll do this as a separate comment.
Contrary to what some people might have thought, no, I didn't abandon development.
If and when I eventually decide to stop updating (with UE 6 or whenever Tim decides to turn everything into the Metaverse Circus of Only Fortnite Game Modes), I will explicitly say so and remove the ability to buy the plugin.
The last two years haven't been fun for me. I have multiple chronic medical conditions that have landed me in the hospital,
or serious rehabilitation for long stretches.
At the end of the day, I'm usually too exhausted or even physically unable to do... anything, even if I want to,
so I need to take it one day at a time.
That's my new reality.
tl;dr: Everything takes a lot more time than it used to.
So, I'm sorry it took this long for me to post the 5.5 update, and that I skipped the 5.4.1+ ones (which I thought I tested with the live 5.4.1 binaries which seemed to work fine at the time and didn't require anything from me, like back with the 5.3.1 on 5.3.2 version, but perhaps I only tested rebuilds. Things got... hazy for a while), but I couldn't give you a timeline for fixes, or promise anything until it was actually done, so... yeah.
Anyway, the new Not Fucking Dead update should fix all the listed problems from the last... 6 months.
Here's to not being dead.
Merry Christmas
Hi NTE, when I saw the response in my Gmail notification and (particularly) the title of the newly updated files, I couldn't help but have a chuckle. Really appreciate the updates as I am sure the cohort of us here are, and a very pleasant surprise it is.
But of course, you needn't apologise for delays, understanding that life has changed a bit for you which is just an unfair predicament that no one should have to go through. As the title you've so fittingly chosen reflects a tenacity that is admirable, and I wish you well.
Merry Christmas.
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 don't suppose there are plans for this to work on 5.5 either?
I don't think NT Entertainment is working on this plugin anymore. The latest 4.27.2 version doesn't work properly either. The only way I was able to get a hold of him in the past was through some knockoff Twitter platform which has been, unsurprisingly, shut down already.
And such a shame that is; it's one of the most useful plugins for Unreal Engine.
A 4.27 version that should work better is now live.
Sorry for the delay.
Thank you for the update; I didn't mean to come off as impatient or anything like that - it's just that I rely heavily on HammUEr for a major project and the fact that I couldn't use the full precision UV import feature you added at my request without breaking texture exporting was rather frustrating. After some quick testing, I can confirm that both features work properly in the new release - and what a time saver this is!
I assume you'll probably want to move away from UE4 at this point anyway (I have considered migrating my project to UE5, but decided against it), so I'll understand if this is the last update for the old engine. However, if you were to continue development for it, there is one last feature that, having spent a lot of time with my HammUEr workflow, I think would be extremely useful: smoothing group import. The angle threshold-based smoothing is not terrible, but I do find it rather limiting. Being able to import smoothing groups from Hammer would eliminate this problem; however, I realise that if this were an easy thing to implement, you probably would have done it already. I just wanted to put it out there that this feature would make the plugin absolutely perfect in my eyes, and I imagine others would concur.
Anyway, thanks again for the fix (I've spotted some of the new options here and there and they are also appreciated) and merry Christmas.
Took a quick look at the code, because I definitely remember reading the smoothing groups. Ran into a "This is a confusing mess for a lot of users causing them to complain about weirdness, so let's just calculate our own and be done with the whole thing" comment, so...
Yeah.
Maybe if you can give me like a couple of "here's some vmfs, with images of what I want these things to look like" examples, I can do some kind of "no, really, I want to use the smoothing groups" override option down the line? Maybe.
5.5 version is now live.
Sorry for the delay.
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
Strange.
That should have worked.
Try the new 5.4.4 build I guess?
Also: same question as here https://itch.io/post/11612065
The menu option at the bottom of the Window list should exist for you
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?
What were you 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.
Try the new 2.6 version builds for 5.4+
Sorry for the delay.
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.
Not sure which video you watched, but you need to import the materials and textures first, as explained in this video (it's for old pre-Source 2 CSGO, but the steps should be the same)
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 :)
Sorry it took so long for me to get back to you on this.
So the problem here was that a decade ago (oh god has it been that long) when HammUEr was created, all my test maps were Proper Quake Maps, which were nicely cut down to a handful of digits after the period, so I was all "oh, cool, I just need to use floats for this".
Enter your test maps, which are Technically Quake Maps But Not Really and have super tiny values like
(that's 0.[48 zeroes]8552etc) in them, which float takes one look at and goes "nope".
The new Not Fucking Dead update has been rewritten to use doubles for everything, as it always should have, and loads your crashing maps without problems.
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?