itch.io

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

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.

... 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)

Thanks, got it.

Pre-Source Hammer apparently does something... strange, which I hadn't seen before, and which fucks up the processing because Past Me was an idiot while working on the Classic Quake parser (which is what Valve 220 is, mostly)

I've got a fix in the works that'll go live... eventually (I want to combine it with some other changes I'm doing, since I don't have the bandwidth to do multiple rapid updates, sorry)

In the mean time, to unblock you, you can work around the problem by opening your .map file in Notepad and running Macro/Trim Trailing Space And Save (or doing it manually through Edit/Blank Operations/Trim Trailing Space) before opening it with HammUEr.

Woo!

And yeah, it's also already available in the 5.4 version

Yes please, should be good for it this time.

Give 2.2 a shot.

There's now an option in the Project Settings/HammUEr page to switch UVs between Default (aka half, like it usually is) or Full Precision.

Note that I had to build this with VS2022 because my machine decided to nuke itself last week (like I needed more bullshit, right?) and I had to rebuild my entire system and pipeline from scratch... but Microsoft doesn't offer non-paying VS2019 versions any longer, so I figured I'd give it a shot.

Should be fine, and Works On My Machine™, but... I guess we'll see.

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

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)

I'll try to take a stab at it this weekend.

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.

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?

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

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.

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?

Strange.
Is the HammUEr.uplugin file in [your project directory]\Plugins\HammUEr?

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?

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)

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

The 5.1 build should Just Work for 5.1.1 as well.
(or at least, did in testing)

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.

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.

No, sorry.

This is now in for the 5.2 version, and can be found in the Project Settings/HammUEr/Texture & Material Importing section under "Default texture filter"

This callstack unfortunately doesn't help a lot.
It just says "something went wrong in HammUEr code", which basically tells me nothing...

If you still have this problem, feel free to drop me the offending VMF if you want, so I can add it to my testing group?

You need to import any textures and materials you need separately first, from the TextUEr tab.
(and then restart UE for them to actually show up in the content browser, so they can be found and be linked up correctly when you try to import the VMF)

Hm, that should be doable.
No promises for when it'll be added (and probably only to whatever the next UE version is)

Unfortunately, I don't have a mac.
I also don't really have the time to support two different platforms with different requirements (and I'm pretty sure there's no mac version of vtflib, so that'd be another complication...)

I'm going to have to shelve this under "probably never happening, sorry."

I'm sorry, I'm constrained by what the itch (and gumroad) payment processor(s) accept.

Should now be up.

Sorry it's so late, I've been quite ill.

I'm afraid the code (and general workflow) isn't fast and performant enough to work runtime.
HammUEr comes with the source code for the Unreal Engine facing part, I'm afraid the actual conversion code isn't supplied because it uses some proprietary code I can't distribute.
Sorry.

Hi, general settings were moved to the actual Unreal Engine project settings menu, under Edit/Project Settings/Game/HammUEr.
Sorry for the confusion.

As far as I've been able to ascertain and been told, the secondary UV channel for decals was a CS:GO hack specifically for one single map (nuke), that's... not really relevant for how decals work in UE? 

My bad, there's a silent dependency on a .modules file that I didn't notice _doesn't_ automatically get created when you do a standalone build outside of the editor in UE5 (but it _did_ in UE4...), and if that's missing, unreal engine complains.
Should be fixed now in the 5.0.2 version I just uploaded.

Strange, that shouldn't happen, since those are "this code is wrong and can't compile" errors, and it... compiles fine.
Anyway, I've uploaded a precompiled 5.0.2 version, which should hopefully solve your problem.

Sorry, no.
You *can* convert your materials from UE to Source to some extent to help with visualization, 
but that's it.

HammUEr explicitly doesn't read compiled BSP files, only source files for maps, sorry.

Unfortunately, Source 2 support will never be added.
Sorry.

Thanks.
Yeah, there's no animation support in HammUEr, and I'm guessing this one has no mesh information at all.

Yes, eventually, when there's a "proper" one and no longer release candidates.