**REPORTED** Missing resource

Mutisk

Terrarian
Steam or GOG
GOG
Single Player/Multiplayer
Both
Operating System
Linux Other
Terraria Version
1.4.1.2
Controls Used
Keyboard/Mouse
When closing down the game last night I observed another message about missing resource/file not found error. Tried to get Images/Projectile_179.xnb, but filename that exist is called Images/projectile_179.xnb It threw an exception but did not cause any crash. However I lost the exact log message from accidentally closing my terminal, and client-crashlog.txt did not have it.

This is the second mismatch I'm reporting and I'm wondering if not projectile_618.xnb might be another case too? In either case, maybe make a script to compile a lists of resources from sourcecode and one from on-disk filenames, sort and diff to spot and fix all these kind of mistakes in one go?
 
Hey there, thanks for this report.

This looks like an issue that causes crashes ONLY on Linux, and only on some Linux distros at that, so its gone relatively unreported (this would easily be less than 1% of the player base).

We just fixed a similar issue with the Solar Pillar's xnb file, but the concerning issue is that trying to change the file's capitalization is not . . . really noticed very well by Steam. So we are concerned that changes to this might not be properly processed on the user's side, even if we fix it.

With that said, I will report this issue, as its an "easy fix", just not one that populates down to the user very well.
 
The situation is only 'saved' by that windows and mac by default use case-insensitive file systems by default. While that is very unlikely to change or differ, it's used sometimes. Strongly recommend not relying on that and fix it systematic so human errors in capitalization don't occur.

I looked into it a bit and it seems Steam is terrible late at addressing capitalization validation. It's possible to work around with code and exception handling, in pseudo-code:
if the lookup for $resource_file fail;
catch file_not_found exception;
issue case-insensitive search for $resource_file in folder, get $new_resource_file;
log warning "using $new_resource_file instead of $resource_filel", and proceed with $new_resource_file.

...however, if that added effort is worth the edge cases of Steam Linux installations that have been affected is well.. *shrug*
 
Last edited:
This looks like an issue that causes crashes ONLY on Linux, and only on some Linux distros at that,
Every Linux distribution I know of defaults to a case-sensitive FS so they should all be affected. Whether it crash or not is dependent on how the game does exception handling, or in other words how badly it 'needs' the resource.
 
Dont know if you'll revisit this, but ran into another one just now:
ReLogic.Content.AssetLoadException: Asset could not be found: "Images/Gore_240" ---> System.IO.FileNotFoundException: Could not find file "Content/Images/Gore_240.xnb".
 
Hey, thanks for the heads up, I do read these reports, and I've added the Gore texture to the ticket that included the projectiles you mentioned. :)
 
Hey, thanks for the heads up, I do read these reports, and I've added the Gore texture to the ticket that included the projectiles you mentioned. :)
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:
Bash:
[jx@ryz1 T1412]$ ls -1 ./Content/Images/[a-z]*
./Content/Images/fade-out.xnb
./Content/Images/gemChain-2.xnb
./Content/Images/gore_240.xnb
./Content/Images/jellyfishBowl1.xnb
./Content/Images/jellyfishBowl2.xnb
./Content/Images/jellyfishBowl3.xnb
./Content/Images/logo_1.xnb
./Content/Images/logo_2.xnb
./Content/Images/logo_3.xnb
./Content/Images/logo_4.xnb
./Content/Images/logo_5.xnb
./Content/Images/logo_6.xnb
./Content/Images/logo_7.xnb
./Content/Images/logo_8.xnb
./Content/Images/projectile_179.xnb
./Content/Images/projectile_618.xnb

...and notice the projectile couple still are the same too. It does not necessarily mean they're unfixed (because their reference could have been adjusted), however they are the odd ones out considering the other 952 projectile xnbs are with capital 'P' in the file name.

Edit: Was originally reported for 1.4.0.5, but still not fixed in 1.4.1.2
 
Last edited:
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

Code:
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):   projectile_179.xnb

This is from the GOG shell/zip archives.
 
We just fixed a similar issue with the Solar Pillar's xnb file, but the concerning issue is that trying to change the file's capitalization is not . . . really noticed very well by Steam. So we are concerned that changes to this might not be properly processed on the user's side, even if we fix it.

Reposting this thing I said last year; apparently it is still in full force.

We fixed some of these last year. Some of them were NOT fixed, I believe since they are unused (logos 1-8 for sure are no longer used, but I need to check up on a couple of them).

Regardless of that fact, we definitely fixed gore_240 and projectile_179. I've confirmed this in my development build, it's literally there, properly capitalized.

And yet . . . my installation (Steam) build is not fixed. For whatever reason, capitalizing the file name is not considered a substantial enough change for Steam (and GOG???) to truly register it properly, and so it is not reliably "updating" the file from uncapitalized to capitalized. And it doesn't seem as if there is any way to force it to do so on our end. Interestingly, on my Steam build, projectile_618 is also not capitalized either.

I will confer again with Yorai about this; but if we've literally already fixed the issue to the best of our ability on our end, and this is a technical hiccup in the "update store-side repository" side of things, there may not be anything we can do to override it. I will, however, still bring up the currently unchanged files and confirm of any of them do need to be changed (though they will almost certainly run into the same problem as before).

I think this issue would have been noticed much earlier if it hit more users, but it went relatively under the radar for years because it only hits a subset of Linux distros (and to my knowledge, no PC or Mac users at all). But it is a frustrating one.
 
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 store packaging process/repository that weren't operating in case-sensitive modes? (and also not offering a full refresh/restart sync from zero). But it seems very odd that both Steam and GOG fails on handling it. /shrug

...it only hits a subset of Linux distros (and to my knowledge, no PC or Mac users at all). But it is a frustrating one.
Case-insensitive Linux is very exotic so that subset is practically every Linux. Also Linux not a PC operating system now, hm?
But the issue is very subtle save from the unhittable pillar, as all you get is something small 'missing' and a log/commandline output that would be hidden to steam users and everybody launching from menu or icon. Additionally, you only get the output when you encounter them in-game, so you cant 'check' for it in advance. I think those are more relevant factors for why this to stay under the radar.
 
Last edited:
Just wondering, has this issue been fixed yet because until it has been i just can't play tModloader. Because I'm on a crappy mac the folders are impossible to find let alone fix

Also the issue does effect mac, or at least older models
 
Last edited:
Back
Top Bottom