Add UI scene / resource bin entry names

[Crauzer]

235 hashes.binentries.txt names, derived rather than guessed.

Many bin entries are named after a path that is already known, so they can be recovered by a dictionary join instead of brute force. Two rules, both run against 16.14.7949266 (421,004 top-level entries across 46,154 bins; 47,243 not yet named here):

A — prefix of a string value. Every UI element's name is <scene path>/<element tree>, so every /-delimited prefix of a string value is an entry-name candidate. Positive control: this regenerates 27,929 names already in this file, and gives correct casing for free.

B — known WAD path. Entries such as UiPropertyLoadable / UiPropertyOverrideLoadable / UiComponent are named after the file they reference, so hashing every path in hashes.game.txt (full and extension-stripped) against unnamed entry hashes recovers them. This reaches the variant stubs rule A cannot — 174 of them contain no objects, so no string exists to take a prefix of.

The rules overlap on 22 entries and agree on the name for all 22.

Rule B gave 233 raw matches, so chance collisions were separated by directory using dictionary size to predict them (paths × forms × targets / 2³²):

top-level	dict paths	expected	observed
clientstates	1,068	0.0	193	kept
ux / loadouts / characters / levels	12,283	0.1	7	kept
assets	2,067,660	26.2	29	dropped
data	190,766	2.4	3	dropped

assets/ and data/ sit on the collision expectation and were dropped wholesale rather than filtered by hand.

Casing is attested, not invented — from names already in this file (UIBase ×57,691, UIMobile ×1,012, TFT ×24,812), from cased strings inside the bins, and from a raw scan of all 841,898 decompressed WAD chunks for the literal. Only UIRTL/UIMobileRTL, UITencent and the Levels/Map10/Scripts/Mutators directory chain rest on convention alone; everything else is attested somewhere in shipped data.

Every entry was checked to occur as an unnamed entry in shipped bins, to reproduce its name under FNV-1a-32, and to be absent from this file. Sorted with LC_ALL=C per tools/hashes-prepare.

Happy to split the convention-only handful out if you'd rather not take them.

Researched and prepared with the help of an LLM; every name was verified against shipped data.

[Morilli]

The approach makes sense and except for the one I noted I believe the results. In general there's a lot of hashes that can be found from existing paths, either bin entries from game hashes, bin hashes from bin entries or by stripping path components (from the right, usually). The annoying part is verifying that you actually get correct results and not just things that look right.

[Morilli]

This one seems wrong.

[benoitryder]

The annoying part is verifying that you actually get correct results and not just things that look right.

Could we filter or validate using the surrounding context? (e.g. owning entry).

[Morilli]

Could we filter or validate using the surrounding context? (e.g. owning entry).

For most of them probably, yes. But that requires the hash guessing infrastructure to connect hashes to their origin and doesn't allow "dumb" iteration over all unknown hashes.