itch.io

Quick update on this, since it's been a while: 

I have a plan, but I didn't manage to get it done before the 5.7.0 update because of my ongoing health situation. I'm pushing the 'vanilla' 5.7.0 update without these changes first, but hopefully I'll manage to get something done for you by end of year.

I'd need to... rearchitect some stuff, and I don't know how soon I'll have time to actually implement it, but... maybe I can do something like that, yes.

Especially given the imminent 5.7 release, which means I'm going to have to try and carve out time to dig into that anyway...

Some of the things you listed will probably still be gone tho, since they're basically stored with the mesh data (definitely the lightmap, maybe some material settings) 

I noticed that someone left a (now deleted) "Hey, the MAP properties thing isn't working in the 5.4 build" comment earlier this week, which is my bad, I did say I'd try to support the last 3 versions, way back when.

This should now be rectified with a Hot Block Summer build for 5.4.4

As was said by stoofphen, the plugin only really supports the old Quake-family derived types specified in the blurb above, with no plans to add any new formats, sorry.

All I do is basically call Unreal's GetTexturesInPropertyChain (aka "hey Unreal, what are the texture parameters in the chain for [output property]") and list its output, so if material attributes fuck with that in some way and block the chain traversal/discovery... 

I'm afraid there's not much else I can think of to do here.

That's... strange. 

I haven't really touched any of that code in... forever? 

The only thing that might be remotely related is that everything now uses doubles under the hood (because of some more modern editors using doubles everywhere)? 

Anyway, do you have like a repro case you could share?

Update on this: 

https://riversalmon.itch.io/ helped figuring out the reason why things weren't building (a filename ending in Classes is apparently... Specialcased even in Plugins now?), so I'm in the process of making sure I've looked into everything people mentioned before release... hopefully sometime this week?

Yes, a 5.6 update is planned.
I've unfortunately run into a... problem, which I'm not sure is on Me, or on Epic, so I've been kinda watching to see if a 5.6.1 was imminent.

Basically, when UHT generates the intermediate files for the Runtime part of HammUEr, the 5.6 UHT generates an empty file...
and then fails to compile because "nothing is defined." 
Like, duh, you're trying to use an empty file, buddy.
An empty file you created, so I'm not sure what you expected to happen there...
There were no code changes, and the 5.5 intermediate files...
correctly reference the file where the classes are defined, so... 
you see why I'm very confused right now. 

I've tried a couple of things already, but it always goes wrong during compilation. There's a hack to "fix" it (by manually editing the intermediate files to point to the right source file)...
but I feel like that's not really something I can expect other people to also have to do on their machines if they want to build their game...

So...
tl;dr: Yes, 5.6 release will happen, hopefully Soon™, but I can't really promise when right now.

Sorry.

PSA: You do NOT need to download the fresh Not Fucking Dead With MAP Developer Properties Fix upload if you're not a developer actively modifying the HammUEr source to integrate it with whatever flow you're trying to build for your project and you're importing some kind of customized MAP format... descendant.

You don't. There's absolutely no changes that are useful to you if you're just importing your levels. You're fine. Go about your business and just ignore that upload.

The only change is that I fixed an oversight where VMF entity properties were queryable during the Load-And-Spawn portion of the HammUEr import so devs could do whatever for their custom extra properties... but I never hooked up the same code for the MAP loader. Which I discovered when someone asked me about accessing properties so they could do something custom with entities, and I went "I vaguely remember doing something for this, can't you just call this functio... oh. Huh. I never hooked that up for MAP files, did I?"

That's all.

(Note that if you're a dev that does want that but isn't on 5.5, you should be able to just take the HammUEr lib and paste that over your existing NotFuckingDead install, rebuild and get this oversight fixed as well)

The fix I mentioned should have gone live with the Not Fucking Dead updates last week.
Let me know if it's still wonky.

Sorry for the delay.

This should definitely (hopefully) be fixed in the Not Fucking Dead updates

No worries, glad you're unblocked now.
Again, sorry it took so long.

Merry Christmas

Not sure which video you watched, but you need to import the materials and textures first, as explained in this video (it's for old pre-Source 2 CSGO, but the steps should be the same)

Also: same question as here https://itch.io/post/11612065
The menu option at the bottom of the Window list should exist for you

Took a quick look at the code, because I definitely remember reading the smoothing groups. Ran into a "This is a confusing mess for a lot of users causing them to complain about weirdness, so let's just calculate our own and be done with the whole thing" comment, so...
Yeah.
Maybe if you can give me like a couple of "here's some vmfs, with images of what I want these things to look like" examples, I can do some kind of "no, really, I want to use the smoothing groups" override option down the line? Maybe.

Just to double-check: after the UI change in UE5, HammUEr (and all my plugins, really) only has the menu option at the bottom of the Window list, which definitely should exist?

I was... annoyed that they changed up the whole toolbar button code with the UI changes and just broke it, but not the menu option, and never really... bothered to try bringing it back, since nobody really seemed to be missing it? (I think there might also not have been like, an example of the New Correct Way in the first version of 5.0, but that might just be my faulty memory)

Sorry.
Hopefully that unblocks you, at least.
If not, we have... deeper problems.

Maybe I'll re-add it down the line somewhere.

Also: HammUEr doesn't really touch any of the UE BSP stuff (because it has always been a massive pain), everything gets imported as static meshes

What were you trying to do?

Try the new 2.6 version builds for 5.4+
Sorry for the delay.

Strange.
That should have worked.
Try the new 5.4.4 build I guess?

Sorry it took so long for me to get back to you on this.

So the problem here was that a decade ago (oh god has it been that long) when HammUEr was created, all my test maps were Proper Quake Maps, which were nicely cut down to a handful of digits after the period, so I was all "oh, cool, I just need to use floats for this".

Enter your test maps, which are Technically Quake Maps But Not Really and have super tiny values like

8.552847072295026e-49 

(that's 0.[48 zeroes]8552etc) in them, which float takes one look at and goes "nope".

The new Not Fucking Dead update has been rewritten to use doubles for everything, as it always should have, and loads your crashing maps without problems.

A 4.27 version that should work better is now live.
Sorry for the delay.

5.5 version is now live. 
Sorry for the delay.

Fuck it I'll do this as a separate comment.

Contrary to what some people might have thought, no, I didn't abandon development.

If and when I eventually decide to stop updating (with UE 6 or whenever Tim decides to turn everything into the Metaverse Circus of Only Fortnite Game Modes), I will explicitly say so and remove the ability to buy the plugin.

The last two years haven't been fun for me. I have multiple chronic medical conditions that have landed me in the hospital,
or serious rehabilitation for long stretches. 
At the end of the day, I'm usually too exhausted or even physically unable to do... anything, even if I want to,
so I need to take it one day at a time.
That's my new reality.
tl;dr: Everything takes a lot more time than it used to.

So, I'm sorry it took this long for me to post the 5.5 update, and that I skipped the 5.4.1+ ones (which I thought I tested with the live 5.4.1 binaries which seemed to work fine at the time and didn't require anything from me, like back with the 5.3.1 on 5.3.2 version, but perhaps I only tested rebuilds. Things got... hazy for a while), but I couldn't give you a timeline for fixes, or promise anything until it was actually done, so... yeah.

Anyway, the new Not Fucking Dead update should fix all the listed problems from the last... 6 months.

Here's to not being dead.

Merry Christmas

Both, kinda?

Like I _could_ probably build a version of the HammUEr specific static library for linux on an ubuntu machine or whatever and create a version of the plugin for linux (altho that'd be More Hoops that I'm not really looking forward to), but the VTFLib dependency is kinda hard Windows right now. I've been thinking about resurrecting my old homebrew VTF reader/writer, but there's some weirdness in UE5 with that right now. Yes, I know there's at least one linux port of VTFLib, but the one I saw was incomplete.

You're also the first person that's ever really asked the _linux_ question? 
(The macOS question has been asked I think, but I don't really feel like giving apple a shitton of money for no good reason? so...)

tl;dr: technically feasible, but in reality... probably not gonna happen because I just don't have the time or spoons, sorry

Source 2 support will never be added I'm afraid.

It's an entirely new engine that's still actively in development (and being sold) by Valve, with a completely different design paradigm and format from the classic brush-based ones supported by HammUEr and a whole bunch of third party level editors out there.

Sorry.

... oops.

That "4.5.1" I added a month ago should, of course, have been 5.4.1, sorry.

(and yes, it should also work as-is for 5.4.2)

Thanks, got it.

Pre-Source Hammer apparently does something... strange, which I hadn't seen before, and which fucks up the processing because Past Me was an idiot while working on the Classic Quake parser (which is what Valve 220 is, mostly)

I've got a fix in the works that'll go live... eventually (I want to combine it with some other changes I'm doing, since I don't have the bandwidth to do multiple rapid updates, sorry)

In the mean time, to unblock you, you can work around the problem by opening your .map file in Notepad++ and running Macro/Trim Trailing Space And Save (or doing it manually through Edit/Blank Operations/Trim Trailing Space) before opening it with HammUEr.

Woo!

And yeah, it's also already available in the 5.4 version

Yes please, should be good for it this time.

Give 2.2+ a shot.

There's now an option in the Project Settings/HammUEr page to switch UVs between Default (aka half, like it usually is) or Full Precision.

Note that I had to build this with VS2022 because my machine decided to nuke itself last week (like I needed more bullshit, right?) and I had to rebuild my entire system and pipeline from scratch... but Microsoft doesn't offer non-paying VS2019 versions any longer, so I figured I'd give it a shot.

Should be fine, and Works On My Machine™, but... I guess we'll see.

Sorry, it took me a few days before I tried to get the file, and by then, it was already gone from wetransfer apparently?
And then Medical Bullshit happened, so I figured I might as well ride it out before asking you to upload it again.

To answer your question: 

I don't think there's a problem with older hammer versions? But I haven't really done much testing with anything before 4.X

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?