Recent content by Mutisk

It looks related to your graphics card/driver, but that's only a guess.

Can verify (GOG/Linux). Chests before torches are reachable with gizmo equipped, and behaves correctly. The chest above torches is reachable with gizmo, but closes immediately when mannequin is placed (even off-screen on 1920x1200). Noting that only half of the torch-chest is clickable at...

Might be the case. Last I heard the full support and optimization for linux was on pause until a "Future release", but that official chanelog post has not been updated for the current versions. I run the GOG version with no issues after renaming (or symlinking actually) some game resources to...

As title says, the next achievment icon next to the inventory disappears somtimes as discussed here, even if you have stuff left on the list. You can still see them when accessed through the menu list, it's only the shortcut and display above [coins ammo] that disappears.

The GOG releases are just a kind of self-extracting zip archive, so for those in particular the problem lies in whatever process is used to create them and not something, as quoted, "processed on the user's side". But as I think you say and I also recall from previous discussions, it's some...

You say BSOD but also tag it linux? That seems confusing because as far I know BSOD is a windows kernel panic/crash.

I noticed I had the same issue. Perhaps the achievments.dat got corrupted or marked as 'complete' because when I deleted mine to start over from zero it displays okay again. Edit: I'm pretty sure it happened again now after defeating Moon Lord.

Updating this for v1.4.3.2 I'm stilll seeing error dumps and having to manually add copies into the installation of the two resources Referenced as Content/Images/Gore_240.xnb actual filename (i guess): gore_240.xnb Referenced as Content/Images/Projectile_179.xnb actual filename (i guess)...

Just a reminder - this gore_240.xnb file is still uncapitalized with version 1.4.1.2. I just triggered the assertion again. Upon finding this, I also went to list/check the other uncapitalized xnb resources and got: [jx@ryz1 T1412]$ ls -1 ./Content/Images/[a-z]* ./Content/Images/fade-out.xnb...

I suspect gfx drivers. You have a chance to try a software renderer which is usually correct(er) but incredibly slow if you start the binary with from a console or script with the variable set: LIBGL_ALWAYS_SOFTWARE=1 ./Terraria.bin.x86_64

These are in the game folder for the GOG version and I could choose where to install those. If you are on steam I dont know how it differs, but for all steam games you can access the game files in some way. You can probably google up a decent guide, or try this one unless it has changed.

Well, they've yet not made much progress with fixing bugs for Linux and macos, but It could be of interest to at least mention what graphics card and mesa drivers you're seeing this with. Like the output of glxinfo | grep -P '(string|version)' It could be related to those versions.

Ideally you would want to set it only for Terraria, not globally. Myself I have a start script, calling it like FNA_KEYBOARD_USE_SCANCODES=1 ./Terraria.bin.x86_64 Steam tends to hide stuff with it's GUI launcher, and could potentially source environment variables differently than you expect...

Using a custom layout myself I can confirm terraria has issues with recognizing symbols. There's a workaround that might help if you start the binary with FNA_KEYBOARD_USE_SCANCODES=1 but I don't have the steam version nor do I know where you hook environment variables in steam.

Hm, I do not have any font issues on Fedora32 using the GOG version. AMD radeon 5700xt mesa/DRI opensource drivers. Does it go away if you set the environment variable LIBGL_ALWAYS_SOFTWARE=true It'll be unplayable slow, but might help us understand whether it's a driver issue or something else.