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.
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
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.
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.
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.
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)
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?
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.
Yeah, I was just going to say "can't be the map itself, since that seems to load fine no matter what options I use"
The callstack makes it seem like it happens when we tell Unreal "Hey, we changed the contents of this package, it's dirty now", so it makes sense that it happens when you've done it a couple of times in the same content directory...
Wonder what I can do about this... hm.
(also, thank you for asking, I'm not really feeling a lot better yet, I've got a long way to go with physical rehab and shit, but hopefully we'll get there... eventually)
Strange, I just tried it again with the L4D2 version of Hammer.
I export from HammUEr to my SteamLibrary\steamapps\common\Left 4 Dead 2\left4dead2\materials directory, which creates a HammUEr directory under it.
Then when I start the L4D2 tools and Hammer, It Just Works.
I can filter by hammuer in the browser, and the textures match their Unreal Engine originals.
Is there a mismatch between the directory you put them in and what the .vmt files reference? Because those include the HammUEr\ prefix, so if you changed the directory name, you might need to edit the .vmt files as well.