I don't think I changed anything in how the model importing code works recently...
You have any more information for me?
Recent community posts
The Christmas versions should now import your 220 maps without problems.
Sorry for the slightly longer delay, there were a few other fixes I wanted to get in, and then the pandemic got in the way.
Sorry, that's one I've never seen before.
I'm guessing one of your textures is broken, or not supported.
Try checking the log to see where it fails, or try breaking up your texture directory in a couple different ones, and then import them one by one to try and narrow the problem that way.
Thanks, that helped me track down the problem.
I've got a fix that'll go in the next fix drop for 4.25 (around 4.26 release, so hopefully soon).
A workaround that _might_ work until then is to add a "wad" property, so it forces the parser down the classic map path...
As far as I remember, it should autodetect Valve 220 maps, and the Q1 rotation stuff should only be necessary to make things line up as expected, not ungarble UVs completely.
Can you pastebin (a section of) the map with the problem so I can test it locally? (with a list of expected texture sizes)
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.
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.
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?
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...
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?
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.
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.
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?)
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?