Which resourceis actually winning?

Streaming assets are addressed by filename, and the namespace is flat. It does not matter which resource a file sits in, how deep the folder is, or what the folder is called — two files named hei_hw1_02_0.ybn are two claims on one name, and only one claim can be honoured.

There is no merge step and no warning. The loser is not disabled, quarantined or reported; it simply never becomes the file the game uses. This is why map conflicts feel so unlike normal bugs: nothing failed, so nothing was said.

The part everyone repeats

Search this problem and you will be told the game resolves it alphabetically, and that you should rename your resource folder with a zzz_ prefix to win. People say this because it works, often — which is a much worse situation than it being simply wrong.

What actually decides the outcome is the order resources start in. The last resource to register a claim on a filename is the one whose file is used. Alphabetical naming is not the rule; it is a lever that happens to move the rule, because when you start a bracketed folder the resources inside it are picked up in directory order — so renaming a folder does frequently change start order, and therefore does frequently change the winner.

Treating the side-effect as the mechanism is fine until it stops working: the moment your two resources are started explicitly from different lines of your config, or one is started by another resource’s dependency, the letters in the name stop mattering and the advice collapses. The reader then concludes the problem is exotic, when they have simply hit the edge of a rule of thumb.

If your fix is “rename it with more z”, you have changed the answer without learning the question. That is fine once. It is a problem the third time, because you now have three resources named after the fix.

Where start order actually comes from

Three things determine it, in roughly this priority:

1. The order of the lines in your server config. Each ensure starts what it names, in the order it is read. This is the lever you actually control, and it is explicit.
2. Directory order within a bracketed folder. Starting [maps] starts everything inside it, and their relative order comes from the folder listing. This is where the alphabetical folklore comes from.
3. Dependencies. A resource can require another, which pulls that one in earlier than its position in the file would suggest.

The practical consequence: if two map resources are both inside [maps] and you need a specific one to win, the reliable fix is to stop starting it as part of the group and start it explicitly on a later line. That is a decision written down in a file, which is worth considerably more in six months than a folder called zzz_final_real_fix.

Proving it rather than assuming it

You can reason about start order all day and still be wrong, because the config you are reading may not be the config that ran. So prove it.

Step one — find every claimant

List the stream folder of every map resource and look for the same filename appearing more than once. Until you have the full list of claimants you do not know how many resources are in the argument, and it is very often more than two — the third one is usually a compatibility patch somebody added a year ago for an unrelated conflict.

Step two — change one thing

Stop one claimant, restart, and look. Not because stopping it is the fix, but because it answers the question: if the symptom changes, that resource was supplying the file. If it does not, it was already losing and was never involved.

Step three — clear the client cache before you believe anything

This is the one that wastes the most time. The client caches streamed assets, so after a server-side change you can be looking at the previous file and concluding your change did nothing. Any test where you did not clear the cache is not evidence. Half of “it randomly fixed itself” and effectively all of “it works for me but not for them” is this.

What to do once you know

Knowing the winner turns the problem into a choice, and there are three honest options:

• Pick one deliberately. Set start order explicitly and accept that the loser’s edit is gone. Fine when one resource’s version is simply better.
• Remove the duplicate. If one resource ships a vanilla file it never actually modified — which is common, because packaging tools sweep up whole folders — deleting that copy ends the contest with no loss at all. Check this first; it resolves a surprising number of conflicts outright.
• Merge them. Correct when both resources genuinely edited different parts of the same file. Whether that is true is a question with a real answer, and it is the subject of the bank and casino case file.

What none of those is: renaming things until the symptom moves. That is not a fix, it is a coin toss you have to re-flip every time you install anything.