A new project that is named after your game

[greenfire27]

Every project this editor has ever made had a module called BlankGame in it. NewProjectDialog handed CopyModule the same id for source and target, so the engine's rename path never ran: the game module kept the template's name, an empty Author, and the template's description — "A blank game, ready for you to craft into something amazing!" — no matter what was typed into the dialog.

Fixing that turned up two deeper bugs, one of them a data bug that has affected every project ever created on Linux. Three commits, in the order they were found.

---

1. A new project that is named after your game

The dialog asks for six things now — Title, Directory, Game Core, Module Name, Author and Description — each with a tooltip on the caption as well as the input.

• Module Name defaults to the title stripped to identifier characters plus Game (Space Rangers → SpaceRangersGame) and follows the title until you type your own, after which it's yours.
• Game Core is a dropdown of the library templates a project can be built from.
• Description now reaches the game module as well as AppCore, and Author reaches it at all.

Renaming a module is not renaming its ModuleId. The engine calls <ModuleId>::<CreateFunction>, so the id in module.taml and the namespace in the module's script are the same name written twice, and asset ids are that name a third time — <ModuleId>:<assetName>, in script and in every taml that references an asset. Rewrite only module.taml and the module still loads, still reports its new name everywhere the UI looks, and silently does nothing.

So the rename is a pass over the module's own source, in one place — ModuleStamper — called from all three paths that rename a module. The other two were worse than the New Project one because they can be reached repeatedly: New Module from a template and Edit Module changing a name both rewrote ModuleID and stopped there. The substitution is whole-word, because in the Edit Module case the old id is whatever someone called their module and can be a substring of an ordinary word.

The engine has half of this already and it isn't enough: copyModule's TamlModuleIdUpdateVisitor is root-only so a nested asset id is missed, it can't touch .cs at all, and it renames module.taml to <ModuleId>.module.taml — a name nothing else in the editor opens a definition by, with no fileRename bound to script to put it back.

Template is now a flag and Type says what a module is. Type == "Template" was only ever read as an enumeration filter; "leave this module alone" is enforced by the engine's Synchronized field and always was. So BlankGame is Type="Game Core", ArtPack is Type="Art Pack", both carrying Template="1" and a DisplayName.

2. A declared path spelled the way it was written

A project's game module declared Path="Sprites" and Path="Fonts" where the template said sprites and fonts. On Windows nobody notices. On Linux those directories don't exist, so an image dropped into sprites/ afterwards is never scanned and never becomes an asset — silently, with the module.taml sitting there looking correct. AppCore got it too, so this affected every project this editor has made.

Nothing in the path code was wrong. The fields were TypeString, which interns without caseSens, and StringTable's hash is case-insensitive by construction — hashString runs every byte through a to-lower table, so two spellings differing only in case always land in the same bucket, and an insensitive insert returns the first one there rather than the one it was asked for.

TypeCaseString already existed and already does the right thing, so this is a field-type change rather than new machinery.

Deliberately left folded: ModuleId, Group, Type and the create/destroy function names. Those are identifiers, they are compared as string-table pointers — ModuleManager does it in nine places for load order, groups and dependency resolution — and that matching has always been case-insensitive, so a project depending on AppCore=1 resolves against a module spelling itself appCore today. A test asserts ModuleId still folds, so it reads as a decision.

3. The folder a scan names is the folder you can open

BlankGame declared eight asset paths and shipped three, so every new project warned four times on first open about directories the template never had. Adding them — each with a readme saying what belongs there — is the content change. Adding them turned up the rest.

A directory called fonts came back out of readdir as "Fonts". Not sometimes: always, on this platform. Two of the colliding spellings are interned during static initialisation, before any engine code runs — SpriteBatch interns "Sprites" as a taml node name and guiProfileTheme interns "Fonts" as a field group. So sprites and fonts, the two most ordinary names an asset folder can have, were the two that could never survive a scan. That's why directoryDelete couldn't recurse into a folder it had just been told about.

The platform layer now interns what readdir gives it case-sensitively — and so do ResManager::getPaths, the zip and openFileForWrite paths, and ResDictionary's own path normalisation. Those had to move together: the dictionary derives its bucket from the pointer values of path and name and compares by pointer, so a half-applied change doesn't merely compare false, it hashes into the wrong bucket and reports an existing file as missing.

The four editor themes are part of this rather than incidental. Each asked for ^EditorCore/Themes/<name>/Fonts while the directory on disk is fonts, and that's where $GUI::fontCacheDirectory comes from. It worked only because the fold rescued it — guiProfiles.cs asks for the same LabCoat directory in lower case two files away, which is the codebase disagreeing with itself. Left alone they'd have become a real missing-font-cache bug the moment lookups stopped folding.

---

Testing

322 unit tests, 0 failures. 50 of 50 TorqueScript smoke suites.

New coverage:

Suite	What it holds down
stringTableCaseTests	the primitive in both directions, including the hazard the fix introduces — once a bucket holds one spelling insensitively and another sensitively, an insensitive insert can miss the sensitive entry
declaredPathCaseTests	goes through setDataField, the route TAML takes. Carries a control: ModuleId is poisoned and set identically and still folds, which is what makes the six passing cases evidence about the field type rather than about the fixture
directoryScanCaseTests	writes real sprites/readme.md and fonts/readme.md, plants the capitalised spellings by hand so the collision can't be absent by luck, and finishes by deleting the tree the scan just enumerated — the exact step that failed
tests/smoke/newProject.cs	drives the dialog and reads the artifact off disk, case-sensitively; asserts every control ends inside the content pane
tests/smoke/moduleRename.cs	both Project Manager rename paths

Both smoke suites end by loading the renamed module and asserting its gui reached the Canvas, because that is the only thing that proves create actually fired.

Also verified by hand: two projects built through the real UI, both fully renamed, grep -ril blankgame empty across the tree.

Notes for review

• Only Linux is changed in the platform layer. The same intern sites exist in all six back ends and are wrong the same way, but Windows and macOS are case-insensitive at the filesystem so it costs them nothing today, and I could not run their tests. Worth mirroring by someone who can.
• x86UNIXFileio.cc, resourceManager.cc and resourceDictionary.cc are CRLF; the diffs preserve that.
• Rewritten .cs files come out CRLF, because FileObject::writeLine always emits \r\n. Harmless for the lexer and TinyXML, but it shows in a diff.

🤖 Generated with Claude Code