spawnFxBetweenPoints on a Hex Map

So I've noticed something When I use spawnFxBetweenPoints in the API, using the x,y of 2 tokens as the coordinates, the fx goes 'off target', ie. not aimed at the actual target tokens x,y However, when used as a macro /fx the fx is 'On target', implying the fx works as originally planned I have verified the tokens x,y (ie. what is used in the spawnFxBetweenPoints command)  using a sendPing command, which puts the pings right where the tokens are, but again, for spawnFxBetweenPoints it is off target ? is there a compensation made for hex maps perhaps I'm missing or something else ? Here's a screen shot made, showing 2 'beams' - one is from the macro with the /fx (using selected and target token_ids) and the other is from spawnFx in the API, plus for good measure I pinged the very point used as the target of the spawnFx (showing the nice yellow circle around the token). The /fx beam goes through the target tokens centre, the spawnFx beam goes below it Also, if the angles from selected to target are 0/90/180/270 degrees, the beams are both on target/same target, the deviation occurs on angles between these If anyone knows why this occurs, I thank you in advance

I think I fixed this in the Experimental Sandbox, can you tell me if that is where you are running this?  I'll go check the code as well.

I confirmed I have fixed this in Experimental, but have not backported the change to the default sandbox.  It's a very small fix, so I just pushed it out.  If you restart your sandbox it should have corrected this issue.

Yes, it works perfectly now! Thank you. I was/am using the Default Sandbox. Out of curiosity, what was causing the deviation? 

There was some very ancient code in there that was applying a dampening factor to the calculated angle as it approached the 45 degree point in each quadrant (45, 135, 225, 315).  It would be as much as 10 degrees closer to the horizontal in that case.  Oddly, it would not clamp on the 45 degree points.  I have no idea what that code was in there for. It's from about 10 years ago, so I speculate it addressed an in issue with skewing in early versions of the VTT rendering, but it's lost to the ages at this point.  =D