Difference between revisions of "Thread:Talk:DrussGT/timeSinceDirChange bug"
m (New thread: timeSinceDirChange bug) |
m |
||
| Line 5: | Line 5: | ||
In the onScannedRobot() method, you override the "lastDirection" variable with the new direction value before updating "timeSinceDirChange". This causes this variable to be incremented at every scan, as you increment it if(lastDirection == direction). So, the normalized version 1/(1+2x) vanishes quickly during the round, which is probably almost the same as having weight 0 for this feature. | In the onScannedRobot() method, you override the "lastDirection" variable with the new direction value before updating "timeSinceDirChange". This causes this variable to be incremented at every scan, as you increment it if(lastDirection == direction). So, the normalized version 1/(1+2x) vanishes quickly during the round, which is probably almost the same as having weight 0 for this feature. | ||
| − | Not sure when you introduced this, but maybe it is worth | + | Not sure when you introduced this, but maybe it is worth fixing it in the future for a possible programmatic tuning round. |
Revision as of 23:14, 30 October 2017
Hey, I was trying to plug Druss' gun into Knight (to do some experiments using my MEA/preciseIntersection/features calculations to see if they break your gun) and I noticed something interesting in the code.
I looked throughout the wiki and found nothing about it being a known bug (and probably performance enchancing?), so I'll put it here anyway.
In the onScannedRobot() method, you override the "lastDirection" variable with the new direction value before updating "timeSinceDirChange". This causes this variable to be incremented at every scan, as you increment it if(lastDirection == direction). So, the normalized version 1/(1+2x) vanishes quickly during the round, which is probably almost the same as having weight 0 for this feature.
Not sure when you introduced this, but maybe it is worth fixing it in the future for a possible programmatic tuning round.
