Portal
Since the V7 client has been released, I figure I should clarify my plans for the Tracker. First of all, the Tracker as-is will not support the V7 client because it is COMPLETELY different in terms of is interfaces with 3rd party software. That said, supporting the V7 client IS possible.
However, due to the massive changes that it requires, it would require a near-complete rewrite of the Tracker. My plan as of now is to continue to support the current version of the Tracker with bugfixes/minor changes as long as the V6 clients are supported by Stanford. This does mean that there will be very few if any new features added though.
Now to support the V7 client, I plan on doing a complete rewrite of the Tracker if there is enough interest from users. That said, below is a list of some ideas I have for the new version.
1. Client shutdowns between WUs no longer needed
Thanks to the ability to reconfig the V7 client on-the-fly, the current -oneunit on all clients is not needed to ensure that the clients can be reconfigured between WUs. With V7 it's possible to reconfigure the client while it's running without even restarting it!
2. Per-client name/team/passkey options
This option is again thanks to the simplicity of the V7 client. Since all options can be modified on-the-fly without restarting the client the Tracker can just directly apply settings per-client without any of the overhead of using -configonly clients to change client.cfg.
3. Built-in EOC stats feed
This would just be a simple display like with HFM.NET. It would show your 24 hour PPD average, points today, points last 24 hours, ect. This data would also be exported in status.xml for live signatures. There would also be an option to get your EOCID automatically from your name/team combination, similar to the "Get EOCID" option in the current Tracker config.
4. Hardware monitoring
This is mainly to allow for things like "shutdown GPU0 if temp > X," but I think many users would find it convienient to be able to monitor everything in one place. Hardware monitoring would of course have an enable/disable option if the user prefers to use some other software for this.
Additionally, if Stanford makes it possible to control the FahCore idle time without client restarts it could be used for "Smart Heat Control." Using this you can set a maximum desired temp, and the Tracker will throttle the client as needed to prevent it from exceeding this temp.
5. Leave clients running on Tracker exit
This option would allow you to close the Tracker to update it or simply conserve system resources, without exiting the FAH clients. This is again made possibly by the new interface provided by the V7 client. This isn't possible with the V6 clients because the Tracker needs to watch for client process exit events. This would of course be user-configurable, so users could retain the current behavior of the Tracker stopping all clients before exiting. This also leads me to the next feature:
6. Remote client control
Pretty self explanatory, this option would allow you to control FAH clients on other computers remotely using the Tracker's interface. This is again made possible by the new interface in the V7 clients. You could also use a Tracker on any computer to control any client, there would be no predefined "master" Tracker that other instances have to connect to.
Also, remote client control should be possible from a smartphone app. I am not a smartphone app developer, but I figured I would point out that this is a possibility with the V7 client.
7. Improved Gaming Pause
Currently Gaming Pause uses a list of executables defined in Games.txt to detect running games. The downside of this method is that obscure and new games will not be detected in some cases. The plan would be to add DirectX/OpenGL detection as an option, in addition to the current Games.txt method. The user would have the option to pick which method is used. Additionally, the new V7 interface allows clients to be paused without exiting the client. With the V6 clients the only option was to exit the client and restart it.
8. Better initial setup process
The new setup process would walk users through setting up a name/team/passkey, then list all the hardware in the system capable of running FAH. The user can simply select what they want to fold with, and the default settings that work with that configuration will be used. GPU detection would also be moved to OpenCL, in order to accurately detect both ATI and Nvidia cards.
9. Proper Installer
This redesigned Tracker would also be available as an installer, in addition to the current portable exe. I have seen countless users set up the Tracker by running it straight out of the .zip archive without extracting it. This results in the Tracker setting itself up in a temporary folder that gets purged on reboot. This leaves the user wondering where it went, and is overall just confusing for less tech-savvy users. The installer version would solve this problem. Of course the Tracker would also be available as a standalone exe for those who prefer the portable setup.
10. Open Source
If I do end up redesigning the Tracker to support V7 and include these features, I will release it as an open source project once the basic framework is complete. I have received several requests asking about the Tracker's source code. The main reasons I never made it open source were:
1. It was a way for me to learn programming, so I wanted to overcome challenges on my own.
2. A large portion of my code would be confusing to other developers not familiar with how the Tracker works as a whole
But, since the Tracker has become widely used since its initial release a year ago, I think the FAH community would benefit if other developers could contribute to the project.
If you are a developer and want to contribute to the new version of the Tracker please read this:
https://fahtracker.forumotion.com/t236-looking-for-developers#921
However, due to the massive changes that it requires, it would require a near-complete rewrite of the Tracker. My plan as of now is to continue to support the current version of the Tracker with bugfixes/minor changes as long as the V6 clients are supported by Stanford. This does mean that there will be very few if any new features added though.
Now to support the V7 client, I plan on doing a complete rewrite of the Tracker if there is enough interest from users. That said, below is a list of some ideas I have for the new version.
1. Client shutdowns between WUs no longer needed
Thanks to the ability to reconfig the V7 client on-the-fly, the current -oneunit on all clients is not needed to ensure that the clients can be reconfigured between WUs. With V7 it's possible to reconfigure the client while it's running without even restarting it!
2. Per-client name/team/passkey options
This option is again thanks to the simplicity of the V7 client. Since all options can be modified on-the-fly without restarting the client the Tracker can just directly apply settings per-client without any of the overhead of using -configonly clients to change client.cfg.
3. Built-in EOC stats feed
This would just be a simple display like with HFM.NET. It would show your 24 hour PPD average, points today, points last 24 hours, ect. This data would also be exported in status.xml for live signatures. There would also be an option to get your EOCID automatically from your name/team combination, similar to the "Get EOCID" option in the current Tracker config.
4. Hardware monitoring
This is mainly to allow for things like "shutdown GPU0 if temp > X," but I think many users would find it convienient to be able to monitor everything in one place. Hardware monitoring would of course have an enable/disable option if the user prefers to use some other software for this.
Additionally, if Stanford makes it possible to control the FahCore idle time without client restarts it could be used for "Smart Heat Control." Using this you can set a maximum desired temp, and the Tracker will throttle the client as needed to prevent it from exceeding this temp.
5. Leave clients running on Tracker exit
This option would allow you to close the Tracker to update it or simply conserve system resources, without exiting the FAH clients. This is again made possibly by the new interface provided by the V7 client. This isn't possible with the V6 clients because the Tracker needs to watch for client process exit events. This would of course be user-configurable, so users could retain the current behavior of the Tracker stopping all clients before exiting. This also leads me to the next feature:
6. Remote client control
Pretty self explanatory, this option would allow you to control FAH clients on other computers remotely using the Tracker's interface. This is again made possible by the new interface in the V7 clients. You could also use a Tracker on any computer to control any client, there would be no predefined "master" Tracker that other instances have to connect to.
Also, remote client control should be possible from a smartphone app. I am not a smartphone app developer, but I figured I would point out that this is a possibility with the V7 client.
7. Improved Gaming Pause
Currently Gaming Pause uses a list of executables defined in Games.txt to detect running games. The downside of this method is that obscure and new games will not be detected in some cases. The plan would be to add DirectX/OpenGL detection as an option, in addition to the current Games.txt method. The user would have the option to pick which method is used. Additionally, the new V7 interface allows clients to be paused without exiting the client. With the V6 clients the only option was to exit the client and restart it.
8. Better initial setup process
The new setup process would walk users through setting up a name/team/passkey, then list all the hardware in the system capable of running FAH. The user can simply select what they want to fold with, and the default settings that work with that configuration will be used. GPU detection would also be moved to OpenCL, in order to accurately detect both ATI and Nvidia cards.
9. Proper Installer
This redesigned Tracker would also be available as an installer, in addition to the current portable exe. I have seen countless users set up the Tracker by running it straight out of the .zip archive without extracting it. This results in the Tracker setting itself up in a temporary folder that gets purged on reboot. This leaves the user wondering where it went, and is overall just confusing for less tech-savvy users. The installer version would solve this problem. Of course the Tracker would also be available as a standalone exe for those who prefer the portable setup.
10. Open Source
If I do end up redesigning the Tracker to support V7 and include these features, I will release it as an open source project once the basic framework is complete. I have received several requests asking about the Tracker's source code. The main reasons I never made it open source were:
1. It was a way for me to learn programming, so I wanted to overcome challenges on my own.
2. A large portion of my code would be confusing to other developers not familiar with how the Tracker works as a whole
But, since the Tracker has become widely used since its initial release a year ago, I think the FAH community would benefit if other developers could contribute to the project.
If you are a developer and want to contribute to the new version of the Tracker please read this:
https://fahtracker.forumotion.com/t236-looking-for-developers#921
