Welcome, even if you are just a curious passerby! I will brush things up if needed as time goes on.

You're probably here because now some guns behave strangely, which usually is a sequence order mismatch. If so, you'll have to edit the data file that comes with the script, but first you'll have to bear with me and understand the environment.

To keep everything vanilla-consistent, the script enforces a set duration on every new animation sequence. The se durations are obtained from data-files:

1. "ems\orin\wte_data.txt" if it exists. (Setup process will be discussed later)
   
2. "ems\orin\wte_data_defaults.txt" if the former does not exist or fails to load.

Structurally are individual "blocks" named after weapons. Each entry is an "array": [sequence-id, networked-property]. If you're not sure what the 2nd means, you can ignore changing it.

With the brief technicalities now made known, go start creating the data file dedicated to customisations. You'll need "GCFScape" and also making sure the "ems\orin\" directory exists (make it if it does not). Use GCFScape on WTE's VPK file then extract "wte_data_defaults.txt", rename the file as "wte_data.txt" then move it to "ems\orin\wte_data.txt".

The customisation process isn't possible without some tools, as sequence IDs need to be identified and the data file has to be reloaded. To begin, start your server with the "map" command.. then:

1. Submit "script Convars.SetValue("developer",1)" in console.
   
2. Follow up with a "kill;nb_delete_all;host_timescale 6;wait 500;host_timescale 1".

This should make the script's debug overlays appear in front of you and down below you, and they should inform you of the current animation sequence and what duration was enforced.

I've compiled a full list of commands that you may find helpful:

Total geek stuff not meant for the layman, rather for the average Source savants out there. Because only you warriors know this VScript stands firm atop a ground of clay, it is in no way resilient to the weird Source quirks unless a bit of hard-code is put in place.

The script and its config file is built according to the vanilla weapons, down to the animation sequences, meaning if a weapon mod were to have a mismatched sequence order, this script would totally collapse. The decision to use sequences is for lightweight data, as ACTs can only be attained as strings and also requires the sequence to be attained first.

While the script aims to recreate the behaviour of mods in dedicated servers, there was an attempt to favour those who may want the playback rate sped up, which is already present in the comments. This isn't in the release build because it couldn't be animation specific reliably, as changing the playback rate also causes the animation to travel ahead or back in time.

1. There exists two rarely-used blocks "DurationProps" and "DualiesData". Particularly mysterious is the first, it can't be a child of any weapon block but it's really only for the Shotguns' reload props since they don't accept timestamps.
   
2. The prop "m_flNextAttack" isn't on weapons but rather players, and a little hard-coded rule is responsible. When the script realises aprop isn't from a weapon, it assumes that prop only exists on the player and then enforces the weapon's "m_flNextPrimaryAttack" prop to the same value.