Backport r435 skillcapes, models and cape emotes

[gradwahl]

Goal

Backport the original late-October-2006 / r435 skillcape set into the 2004 progressive base, including the cape items, worn models, animation frames/skeletons, sequences, spotanims/graphics and server-side emote behaviour.

The requested UX is intentionally slightly different from original 2006 behaviour: while the cape is worn, right-clicking it should expose Play Emote, and selecting that action should send a normal operation to the server. The server validates the equipped cape and plays the correct cape animation/graphics so nearby players see it too.

The detailed implementation/test matrix is committed in SKILLCAPE_BACKPORT_CHECKLIST.md on this branch.

Source / scope

• Freeze one exact r435 cache/client snapshot as the source of truth.
• Build a complete r435 source-ID -> local-ID manifest before importing assets.
• Keep the initial scope pre-Hunter; do not mix later Hunter-era assets into the r435 backport accidentally.
• Decide/document whether Quest point cape is included separately from skill capes.
• Do not replace the 2004 cache wholesale; import only the required assets/configs and dependencies.

Cape set

• Attack
• Defence
• Strength
• Hitpoints
• Ranged
• Prayer
• Magic
• Cooking
• Woodcutting
• Fletching
• Fishing
• Firemaking
• Crafting
• Smithing
• Mining
• Herblore
• Agility
• Thieving
• Runecrafting
• Identify the regular cape, trimmed cape and hood objects actually present in r435 for each skill.
• Identify each cape's complete emote dependency chain.

Objects / equipment

• Add stable object IDs without colliding with existing 2004/custom content.
• Import inventory models and icon camera settings.
• Import male worn models.
• Import female worn models.
• Import hood/head models where required.
• Preserve recolours used by regular and trimmed variants.
• Integrate through the existing equipment/back-slot system.
• Keep Wear/Remove/Drop/Examine behaviour intact.
• Ensure trimmed and untrimmed versions use the same corresponding cape emote.
• Ensure hoods do not expose the cape emote action.

Models / cache compatibility

• Import all cape and emote-prop models required by r435.
• Import models required by skillcape spotanims.
• Verify the 2004 model decoder can read every imported r435 model.
• Convert/down-port unsupported model features rather than changing unrelated cache formats.
• Preserve vertex skin/bone assignments needed by animation.
• Add stable mappings in content/pack/model.pack.
• Verify the same models resolve in Java and web clients.

Animation data

• Identify every sequence used by every cape emote.
• Trace each sequence to all required frame groups.
• Trace frame groups to all required skeleton/base data.
• Import/convert frames and skeletons into a format the 2004 clients can consume.
• Preserve frame order and delays.
• Preserve replay/loop settings.
• Preserve sequence priorities/interruption behaviour.
• Preserve weapon/shield overrides where an emote uses them.
• Add stable mappings in content/pack/seq.pack.
• Verify the player returns to normal idle/walk state after each emote.

Spotanims / graphics

• Identify every r435 spotanim used by skillcape emotes.
• Import each spotanim's model dependencies.
• Import each spotanim's animation dependencies.
• Preserve scale, rotation, recolours, lighting and height offsets.
• Add stable mappings in content/pack/spotanim.pack.
• Record the exact game tick each graphic starts relative to its player animation.
• Support player-attached and map/world graphics as required by each emote.

Right-click Emote interaction

• Confirm how the 2004 Java client builds context menus for equipped/worn items.
• Confirm the equivalent path in the webclient.
• Add Emote to the worn skillcape context menu without replacing existing operations.
• Use one consistent operation index/action for every cape.
• If existing worn-item operations can be reused, use them.
• If the client lacks a suitable worn-item operation, add the smallest compatible packet/interface operation needed.
• Do not hard-code animation playback client-side.
• Client sends an operation request; server remains authoritative.
• Route the operation through the existing script/trigger system (opheldN where appropriate, otherwise the appropriate worn-item/interface trigger).

Server-side emote dispatcher

• Create a data-driven cape -> emote definition mapping.
• Map regular and trimmed versions to the same skill emote definition.
• Store the player sequence plus timed graphic/spotanim/prop information for each cape.
• Avoid 22 copy-pasted independent handlers.
• Reuse the existing anim(sequence, delay) script opcode for the player sequence.
• Reuse the existing spotanim/graphic script operations for effects.
• Use queued/delayed script execution for tick-perfect graphic timing.
• Ensure nearby players receive the resulting player animation/graphic updates.

Validation / anti-spoofing

• Verify the requested cape/object is a supported skillcape.
• Verify the player actually has the expected cape equipped before playing the worn-cape emote.
• Reject spoofed operation packets for capes the player is not wearing.
• Decide whether level 99 must be revalidated at use time or ownership/equipment is sufficient.
• Define behaviour during combat, movement, teleporting, cutscenes, death and other action locks.
• Stop/suspend conflicting actions consistently with other long emotes.
• Prevent rapid repeated clicks from stacking animations/graphics.
• Clear temporary emote state after completion or interruption.

Timing / fidelity

• Record total duration in ticks for every cape.
• Record every spotanim start tick.
• Record temporary model/prop changes.
• Record sound timing if sounds are included.
• Match r435 animation timing as closely as the 2004 engine permits.
• Ensure movement cannot desynchronise player animation and graphics.
• Ensure logout/teleport/interruption cannot leave stale visual or locked state.

Sound (full-fidelity pass)

• Determine which r435 cape emotes use sounds.
• Map/import supported sound IDs.
• Play them at the correct tick/range/volume.
• Document any sound format that cannot be faithfully backported.

Java client

• New object configs decode.
• New models render.
• New sequence/frame data animates.
• New spotanims render.
• Worn cape right-click menu shows Emote.
• Clicking Emote sends the server operation rather than playing locally.
• Full cape animation/graphics play correctly.

Webclient

• New object configs decode.
• New models render.
• New sequence/frame data animates.
• New spotanims render.
• Worn cape right-click menu shows Emote.
• Clicking Emote sends the same semantic server operation as Java.
• Full cape animation/graphics play correctly.

Build/cache pipeline

• Put imported raw assets in the repo's normal cache/build pipeline.
• Make a clean checkout capable of rebuilding/loading the cape assets.
• Update cache indices/versions/CRCs as required.
• Verify fresh clients load the modified cache without stale-version errors.
• Document binary asset provenance and conversion steps.

Testing

For every regular and trimmed cape in scope:

• Inventory icon correct.
• Cape equips/removes correctly.
• Male worn model correct.
• Female worn model correct.
• Colours/trim correct.
• Right-click Emote appears while worn.
• Clicking it reaches the server handler.
• Correct sequence plays.
• Correct spotanims/graphics play.
• Correct temporary props/models appear.
• Timing matches the r435 reference.
• Nearby players observe the same emote.
• Completion restores normal player state.
• Movement/combat/interruption does not corrupt state.
• Repeated clicks cannot stack/break the emote.

Regression checks

• Existing 2004 object IDs are unchanged.
• Existing animation IDs are unchanged.
• Existing spotanim IDs are unchanged.
• Existing equipment interactions still work.
• Existing opheld scripts still dispatch correctly.
• Existing emotes/animations are unaffected.
• Java client still logs in/plays normally.
• Webclient still logs in/plays normally.
• No cache-index/ID-range assumptions are broken.

Ready-for-review criteria

• All in-scope r435 skillcapes and trimmed variants render correctly.
• Every cape's original-era emote assets are mapped and playable.
• A worn cape exposes the intended right-click Emote action.
• The action is server-authoritative and validates the equipped cape.
• Correct animation + graphics are visible to the local and nearby players.
• All emotes finish without leaving the player locked or visually corrupted.
• Java and web clients pass the cape test matrix.
• Existing 2004 content remains intact.
• Source-ID/local-ID mapping and any conversion differences are documented.