Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics

NT Entertainment

A member registered Feb 25, 2016 · View creator page →

Creator of

Recent community posts

I don't think I changed anything in how the model importing code works recently...
You have any more information for me?

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.

This should _hopefully_ be fixed with today's Christmas Fixes, if it's the same problem as REVEL303 had downpage.

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.

(1 edit)

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)

Sorry, no support is planned for exporting anything from compiled versions of Source maps.

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

(1 edit)

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

(1 edit)

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.

(1 edit)

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?