Use Vector types instead of tables for Scathis script

[lL1l1]

Description of the proposed changes

Fixes #6524.

• Changes the Scathis's script to use cached Vectors instead of local tables { x: number, y: number, z: number}
  This is more performant and easier to maintain.
  • For performance, the vectors are also accessed with indices instead of hash keys, avoiding a Vector's __newindex call.
• Annotate and explain the Scathis script

Testing done on the proposed changes

There are 3 scenarios for the CreateProjectileAtMuzzle function changed in this PR:

• Firing after unpacking (self.initialaim)
• Firing while unpacked, but changing targets (self.losttarget)
• Firing without changing targets (no special bool)

In all three scenarios the Scathis fires without errors in the log. The fake barrels are misaligned with the real barrel due to a refactoring error fixed in #6525.

Additional context

• How should unit weapon annotations be handled? Classes seem to be global, so the name of the unit weapon class has to be unique. I opted for "[UnitID]_[WeaponName]" here.
• I dislike how the script is designed because it interrupts the standard weapon cycle for its own animations, and would personally redesign it to use the OnStartTracking and OnStopTracking weapon functions.

Checklist

• Changes are annotated, including comments where useful
• Changes are documented in the changelog for the next game version

[Garanas]

The use of tables as a replacement for Vector3(x,y,z) is not uncommon in the codebase. Do you anticipate more of these type of issues?

How should unit weapon annotations be handled? Classes seem to be global, so the name of the unit weapon class has to be unique. I opted for "[UnitID]_[WeaponName]" here.

I think that solution is fine.

I dislike how the script is designed because it interrupts the standard weapon cycle for its own animations, and would personally redesign it to use the OnStartTracking and OnStopTracking weapon functions.

I agree, and I also do not approve of the naming convention that is used 😄 . Feel free to pick this up in a separate pull request.

[lL1l1]

The use of tables as a replacement for Vector3(x,y,z) is not uncommon in the codebase. Do you anticipate more of these type of issues?

As long as the tables are using arrays instead of hash tables the utility functions should work on them; the functions should be written using array accesses.