I'll make some changes to how HammUEr handles the waaay too short internal names for models in the next build, which should... hopefully go live by the end of the month.
I remember there was a reason why I kept it to the internal name by default, but I don't remember what it was, so...

Think it depends on what your brushes look like, how you used the nodraw options for them and if they're grouped or not. There's also smoothing/normal options on the ConfigUEr tab you could experiment with.
Other things you could try on the UE side is to maybe join the two meshes together, and let UE recompute the normals itself.

Do you mean VMTs?
It should support a subset of them, at least.

If it's your own game and assets, that's down to whatever engine licensing deal you have going on.
If it's not your own game and assets, then... no? Absolutely not? Because that's illegal and this shouldn't even be a question.

HammUEr is a tool to help people that are more comfortable working with old BSP-based level editors still use those in UE4 with its mesh-based workflow, that's it.

More explicit version of the terms of use now prominently on the page.

Unfortunately, besides the fact that I'm not really supporting the 4.16 version any longer since it's over 2 years old, there's not much information in those images, so I can't really help.
Do you have an actual log?

Sorry it took a while, but every Entity class now has a GetOriginalData function that'll return a std::map of the data the plugin read from the VMF file.

Basic two texture blend materials for displacements should be supported

By default, it imports models with the name field stored in the actual model file, but there's a checkbox on the PropUEr tab that imports models with the actual filename as well.

Good catch.
That's what happens when you try to marry two systems that use the same term for opposite things.
Fixed in the 4.22 build.

Most of them should compile from previous source, as long as you disable them before packaging, because UE likes things to be just the way it wants them to

Have you looked at the import logs?
Do you know which textures they are?
Is there something special about them?

This is something you should contact itch.io support for.
There's nothing I can do to help you.

This weekend, possibly.

My apologies, you're right about the info_overlay parsing, and the UVs should be correctly read passed through as floats in the 4.21 build.
Unfortunately, I can't release the source for the lib, and don't really have much time to do active development these days, so I don't see myself doing any major refactor work.
Would a basic thing for unknown entity types (or a separate array for all of them) that'd be a hashset or something that you can parse yourself on the UE plugin side work?

Can you try splitting the source directory up into a couple of smaller ones and importing those one by one?
That should at least help narrow down the problem somewhat, while also remove the need to reimport the same things over and over again.

I have no idea what to tell you, except that I can't reproduce your problem at all.
I just ran a test with a cable materials directory (so just "SplineRope" and a "$basetexture" field), and those all imported fine without needing to change or edit anything in the VMTs, so I have no idea what was going on on your machine. Any unknown types should default to the LightmappedGeneric handler anyway...

Which version of the 4.19 importer are you using? The fixed one?
Also, are you sure your material setup is correct?

I'm afraid not.
HammUEr doesn't exist to import random levels from games, it was created to help level designers that prefer CSG brush editors over more recent model-based level creation workflows to get their work into Unreal Engine.

1) itch.io doesn't always send me emails when people post comments, so apologies for the late reply.
2) vtx files are model-related and have nothing to do with materials and textures
3) "it crashes" doesn't really help me debug your problem. Which version of UE are you trying to use? What does the log say before it crashes?

Animated models only get imported as static meshes, since they're only meant to be references to get your scaling right, and not as a means of using content you don't own the rights to.
For your own animated content, you should have source files that can be imported by normal UE means.

Hm. It's been a while since I actually wrote this, and I don't have my dev setup here with me, but let's go with the usual suspects.
If you hook up a "Are we connected to Steam?" node, does anything happen? It should log some error information, or return true if it finds a connection.
Do you have a valid steam_appid.txt in your game directory?

The COD map formats are heavily modified, unfortunately.

I... don't really understand the question.

Unfortunately, none of the things in this log have anything to do with HammUEr, so I can't really help you with this.
Some of those dll errors seem to refer to intel vtune, but a quick google doesn't seem to give any decent solutions, apart from maybe needing administrative rights when you install/run unreal engine?
Good luck, hope you figure it out.

The plugin should work with 4.19.2 as uploaded, so something might have gone wrong while downloading/extracting it.
Please download the new fixed version and try again.

Are you testing with a standalone play mode?
Playing in Unreal Engine itself will fail to init Steam, which is why the Request leaderboard call returns false.

There was a change to the UE API I wasn't aware of, which led to this problem happening.
I've uploaded a new version, so please download "HammUEr 1.8 for 4.19 fixed" and try again.

Weird, if the others show up, it should show up as well.
If not, there's an example of what it should look like in the manual on page 6 (lower picture), so just build something that looks like that and use it instead.

Unfortunately, there's a lot of data to import, and there's really nothing you can do to make it go faster.
You only need to do it once, tho.

If you look at the actual files the warnings are pointing to, (except for 2) these are all in the actual Steamworks SDK, which isn't my code, so there's nothing I can do about this.

I don't have access to my code archive at the moment, so I can't really check with an actual 4.15 build, but my guess is it's got something to do with the displacements?

(Also, this is a decompile, and decompiles are technically not supported. Maybe try opening it in HammUEr and saving it back to clean up whatever the decompiler did?)

4.19 build has been uploaded

I... have some trouble understanding what you're asking, but files that are imported end up wherever your unreal engine project is (because they need to be converted to something UE understands), which I guess is somewhere on your C drive in your case?

Can you put the vmf on pastebin or google drive or something so I can test it locally?

The 4.15 builds are pretty ancient by now, so hopefully a move to a newer one should fix this.
If not, try moving the brush in hammer and then moving it back into place where it was, or check the texturing and redo it so it looks the same but the values are different (if that makes sense)

Sorry it took a while to get back to you.

If you selected one or more files, please check the log to see if there were any errors while importing.
Also check to see if any files were created in your project folder in windows explorer, because they don't always show up immediately in UE. (Although they should show up the next time you open the editor)

Did you mean .vmf file? 
HammUEr has no support for compiled bsp files.

Sorry it took a while to reply.

Unfortunately, they're quite large (30 megabytes that don't compress all that well, compared to barely 300k for everything else combined), and not everyone needs them.
If you do need them however, it should be easy enough to re-compile the supplied source yourself and use that dll/pdb combination.

That looks like a base material problem. 

Open your base material and check to see if it says anything about errors there, there might be a broken texture reference there you have to fix before it'll actually render.

Hm. Try putting your project in a directory closer to the root of a drive (so c:\projectname or something), see if that helps.