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.

Join the sections that have weird shadows where they intersect, basically

Do you have non-basic a-z 0-9 (so accented, asian, whatever) characters in the directory names/file names/material names?

Try to use a nodraw material for faces that can't be seen, and grouping the walls together.

The pre-4.16 builds are rather old by now, and even Epic doesn't really support them any longer, officially.
Is there a specific reason you need to use such an old version of the Unreal Engine? If there is, I can *try* to debug it based on your logs and the vmf file, but if it imports fine in a newer version...

Just tested it, and it should import fine.
It does seem to point to  the texture Models/props_c17/fence_alpha, so if it couldn't find that, that might be why?

Ah, yeah, that's a kinda tricky one I keep forgetting to explain/add to the archive.

Basically, to fix this:

1.  download the '1.7.1 alpha for source builds' package
2.  create a Source directory under your HammUEr directory
3.  create a HammUEr and HammUErRuntime under that
4.  copy over just the HammUEr.build.cs file from the package to the HammUEr directory, not the rest of the source files
5.  copy over the entire contents of the HammUErRuntime directory

Compiling and packaging your project shouldn't be a problem any more.

Let me know if you do run into any more things or have questions.

It would require rebuilding the pipeline (since people explicitly didn't want anything to do with UE4's BSP tools), and wouldn't support everything, but I can try and fork a build that does that. 
Wouldn't happen overnight, though, so don't hold your breath.

Don't know anyone that's tried importing SOF2 maps yet, so I wouldn't be able to give a definitive answer, but I know people have imported Jedi Knight Academy maps without too much trouble, so it all depends on how 'vanilla' Raven kept the map format, I guess. 
I could try importing one, if you put it online somewhere?

Have you tried turning on "Round accepted points to nearest integer"? That should be able to help with some of those problems (although it can't really help with larger gaps)

Unfortunately, I don't think itch.io supports paysafecard yet.
https://itch.io/t/92888/paysafecardpayment-methods

Weird. Can you pastebin your import log for the import of a single model?

Are your base materials okay?

Try to open them and see if UE has any warnings about them.

Weird. There are known problems with decompilers writing broken vmf files, though.
Have you tried opening your decompiled maps in Hammer, see if they work there and save them before trying to import them in HammUEr again?
Just checked with an inferno vmf from here, and that imports (mostly) fine, so maybe use those instead of your own decompiles?

...  huh.
Did it really not create any actors for the actual level geometry in your map?
Or are they just not being rendered?
Have you tried clicking the eye icon off and on to force a show all refresh, like in the troubleshooting section of the documentation?

Some of CSGO's files as shipped are, for lack of a better word, corrupted.
However, there is a solution for this: delete the <filename>.vtx file, but make sure you leave <filename>.dx90.vtx in place.
That should let you import them.

While I'm at it, quite a lot of them also have the wrong internal filename that overlaps with another one, and since I'm using that to name them, there'll be "missing" and "wrong" models because of this. The little checkbox to the right forces HammUEr to use the filename instead of the internal one, and should take care of most of them problems. (You might have to re-import the "real" name ones if some of them got overwritten anyway)

Maybe. No promises, tho.