Skip to content

Keep one catalog identity per native Workshop element #297

Description

@e54-bot

Goal

The catalog holds only native Workshop syntax: each Workshop element has one identity under its native name. OverPy and OSTW names, spellings and syntax do not enter workshop-rs; source-language names are mapped by the owning implementation (opy-rs, del-rs). Convenience forms exist only in workshop-rs internal APIs, never as catalog identities or aliases.

Context

Comparing the catalog's en-US spellings against the workshop.codes wiki inventory of Workshop actions and values (228 actions, 265 values, one article per element) found that exactly six catalog spellings are absent from it. Five are entries that duplicate a native entry under a non-native name, and the sixth is an extra spelling on setAllowedHeroes. The pinned OverPy 9.7.10 metadata gives the same result, so the two independent sources agree:

Catalog id en-US spelling Native entry in the catalog
forcePlayerHero Force Player Hero startForcingHero (Start Forcing Player To Be Hero)
stopForcingHero Stop Forcing Hero stopForcingCurrentHero (Stop Forcing Player To Be Hero)
forceThrottle Force Throttle startForcingThrottle (Start Forcing Throttle)
stopChasingVariable Stop Chasing Variable stopChasingGlobalVariable / stopChasingPlayerVariable (Workshop has two natives)
isFiringSecondaryFire Is Firing Secondary Fire isFiringSecondary (Is Firing Secondary)

isFiringSecondaryFire is not a Workshop display name: the native value is Is Firing Secondary, and the corpus export uses isFiringSecondaryFire only as its internal key for it. Having both identities made the Bastion zh-CN build differ from OverPy until the spelling was moved (the zh-CN fix in the 0.7.1 release left this entry without a zh-CN spelling).

setAllowedHeroes also carries a second en-US spelling (Set Allowed Heroes) beside the native Set Player Allowed Heroes.

The catalog documentation describes some of these as confirmed legacy identity/GUID mappings, so removal may have a reason that is not visible from the data alone. The five entries are inputs to a decision, not a proven defect.

Scope

Remove the five duplicate identities above (and the extra Set Allowed Heroes spelling) from the catalog. Before removing an entry, check its non-en-US spellings: a spelling that a real Workshop client uses, including an older client version, moves to the native identity as a locale spelling, because parsing real exports must keep working. A spelling that exists only because a source language uses it is deleted. Evidence for keeping a spelling must not come from OverPy-derived data; the workshop-data export is derived from OverPy and does not count. The wiki covers en-US names only, so an independent source for other locales has to be named in this issue before those spellings are kept or removed. Update the catalog digest pin, the source-attribution notes and the tests that name the retired ids.

Consumers reference some of these ids and adopt the change in their own PRs: opy-rs mentions stopChasingVariable and isFiringSecondaryFire in about 28 files each (some as OverPy source names, which are not catalog ids), Wright none.

Non-goals

  • Changing native entries or their spellings.
  • Any change to opy-rs or Wright; consumers adopt the result in their own PRs.

Acceptance criteria

  • Every catalog identity is one native Workshop element; no identity or alias originates from OverPy or OSTW naming.
  • Real Workshop spellings that an independent source confirms still parse.
  • workshop-catalog-gen check fails when a new entry duplicates a native identity or carries an en-US spelling absent from the wiki-backed inventory.
  • Public identity changes are called out in the release notes, since retiring an id is a breaking change to the Rust API.

Dependencies

None. Related: the opy-rs surface gap work tracks only OverPy spelling and assumes this catalog rule.

No activity

Activity on this issue will appear here.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions