itch.io

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.

Not... sure?
I'm going to need more information that "it always crashes when importing models". What models? Are there any error messages?

Sorry, most of the settings were moved to an actual unreal settings page in the most recent version, so you can find everything in the actual project settings now

Sorry, most of the settings were moved to an actual unreal settings page, so you can find everything in the actual project settings now

Not... sure? 
I mean, it compiles locally with launcher UE4, and has since the very first version, so...
That line number doesn't seem to match with latest source, and you didn't specify *which* UE4 you're trying to build for, so I have no idea where the problem could be...

Anyway, find any public class property that's a UPROPERTY but doesn't have a Category = "<something>" bit in it like all the others, and add one I guess, see what happens?

Hopefully the switch to VTFLib fixes this.

Not... explicitly no, sorry.
Could maybe look into this for the next version.

I'm... unsure.
I know that Valve models sometimes have different names inside of them than the one the map expect, so you might have to look for the closest matching one and copy/rename it?

Hi!
I've updated the default algorithm in the new Back to School update for 4.26 and 4.27, which should hopefully take care of this problem for you.