Interesting, but it's not a legit excuse.
First, there is the issue of terrain-type detection, which is basically like this:
FFFFFRRRRRR
FF(P)F(B)RRRR
FFFFFRRRRRR
F = fairway
R= rough
(P) = right-handed player
(B) = ball
Here, clearly, a right-handed player would be standing in the fairway, and if left-handed avatars (LHA) were made, the LHA.would be standing to the right of the ball, in the rough.
If the stencil map is set up in such a way that (P) is sent into a function to return the proper stencil type (rough, weeds, sand, etc.), then that could easily be solved by adding a parameter to the function that would cause the the (P)->(B) translation to be multiplied by -1, at which point (P) would be shifted to the right of the ball, rather than the left.
If no such translation occurs, and it is already baked into a stencil map that uses only the ball's position, then it's still easy to fake this and get the same result:
True terrain:
FFFFFRRRRRR
FF(P)F(B)RRRR
FFFFFRRRRRR
Stencil map (in color; letters = true terrain):
FFFFFRRRRRR
FF(P)F(B)RRRR
FFFFFRRRRRR
(Any ball position in green will automatically send back a fairway terrain-type because, while the ball may be in the rough, the player will still be in the fairway; similarly, any ball position in black will send back a terrain-type of rough since the player will be in the rough.)
FFFFFRRRRRR
FF(P)F(B)RRRR
FFFFFRRRRRR
Here, if the avatar is left-handed, it would pass parameters to the stencil's terrain-type acquisition function (see note below) that would trick it into believing that the ball was at the position of the blue R, and the player was at the position of the red R. This would trick it into returning the terrain-type at the red R, which is where an LHA would stand -- in the rough.
Note: For future reference, we will call the terrain acquisition function "stencilTerrainAcquisition," and here's an example prototype:
enum TERRAIN_TYPE_ { "fairway", "rough", "deep rough", "rough1", "rough2", "weeds", "light fescue", "fescue", "sand", "mulch" }
TERRAIN_TYPE_ stencilTerrainAcquiquisition(COORDS_ coordsBall);
So, now, let's assume that the terrain-type of the red R's location has been correctly detected. There are still other issues to take care of: (1) the stencil is not symmetrical, so it would need to be flipped horizontally, and (2) the stencil placement, as WGTniv has said, is not currently being placed in the correct position.
Step 1: Flip the stencil.
Flip all of the stencils and save them under similar file names. For example, if the rough's stencil is named rough_stencil01.png, then it could be flipped, and the flipped copy could be saved as rough_stencil01L.png. The program would then decide which stencil to load:
switch (stencilTerrain) {
case "rough":
if (player.handed == "right") { stencil_file = rough_stencil01.png; }
else { stencil_file = rough_stencil01L.png; }
break;
case "weeds":
...
}
Now the terrain-type at the players location has been detected correctly, and it has been flipped. The only thing that remains is actually drawing it at the correct location.
Again, the multiplication by -1 trick is an easy way to do this. How does the WGT client currently know where to draw the stencil on the screen? I suspect it works from the ball's position, then moves a certain distance to the left and draws the stencil. This distance could be multiplied by -1, turning it from a "left of the ball" translation to a "right of the ball" translation.
Let's take a worst-case scenario of employing this approach and assume that WGT moves the ball backward/forward in the avatar's stance. I'm not sure it actually does this, but again, this is a worst-case scenario.
F(L.)FFFRRRRR
F(R)F(B)R(R)RR
FFFFFFFR(L)RR
If the translation from (B) to (P) not only moves the stencil to the left, but also forward, then multiplying by -1 would move the stencil to the right and backward... oops!
The fix for this is separating the horizontal and depth components of the translation. If the translation T is 2 ft to the left and 1 forward, then Tx = 2 and Tz = 1. When multiplying by -1, we would leave Tz unaffected and only multiply Tx by -1, and the modification of the translation for left-handed players would be:
Tx = 2;
Tz = 1;
if (player.handed = "left") { Tx = Tx * -1; }
Yielding the result, Tx=-2, Tz = 1, which are the desired values.
Let's also look at another worst-case scenario. What if the terrain is like this?
..........................._(L)___
........................../
__(R)___o__/
In other words, a right-handed player would be level with the ball, but a left-handed player would be elevated above the ball. This is a little tricky to fix, but still doable. We'll have to go back to our terrain-acquistion algorithm, of which I showed two possible implementations, but we'll stick with our "stencilTerrainAcquiquisition" function: TERRAIN_TYPE_ stencilTerrainAcquiquisition(COORDS_ coordsBall);
This would need to be changed in order to also fetch the y displacement of the stencil:
TERRAIN_TYPE_ stencilTerrainAcquiquisition(COORDS_ coordsBall, int& yDisplacement);
When calling the function, we would not only fetch the terrain type, but since yDisplacement is sent by reference, we could also have any modification of its value persist outside of the stencilTerrainAcquiquisition function, e.g.:
int Ty=0;
TERRAIN_TYPE_ terrainStencil;
terrainStencil = stencilTerrainAcquiquisition(COORDS_ coordsBall, Ty);
// after the above line, Ty would no longer be equal to zero, but rather the vertical displacement of the player from the position of the ball
With this modification, we can acquire all of the components of the stencil translation... the lateral component, the depth component, and the vertical component. Multiplying only the lateral component by -1, the flipped stencil would be placed at the correct location.
Now, if WGT were to object, "But that would take up too much CPU-time on the server," first off, I'd have to disagree. They're already doing most of this... all we're adding here is what is necessary to trick the already-existing functionality into working for lefties. However, if this was found to be the case, all of this math (i.e. translation component separation, multiplication by -1]) could be completely cut out of the process if WGT went back and used these methods to bake a second stencil-acquisition map for lefties. If WGT did that, they wouldn't have to change their code at all except for a few conditional statements making checks on player.handed.
Regarding the "rework of avatar [and] club animations," that is false unless you consider a horizontal flip "work."