Hi Patrik,
One request in addition to "add to workername" that's already implemented, is the passing of difficulty parameter in a similar fashion
a good number of pools allow passing of the static difficulty parameter (or suggested difficulty) through mostly the password field with (d=xxx), some pools, especially lots of the cryptonight implementations, append them to the worker name field (-u parameter in common miners) via their own defined parameters (some uses "+", some uses "." for the ones I've came across)
I managed to use the [MinerWorker] method to assign worker names, it works perfectly but is also buggy atm:
For example, the pool (Cryptoknight.CC) uses the following format (which I use in the pool setup):
Worker name: WalletAddress.[UserDefinedDifficulty]
Password: [MinerWorker]
if I specify the difficulty with custom delimiter (field left empty), AM will parse the command as follows:
-u WalletAddress.[UserDefinedDifficulty][MinerWorker] -p [MinerWorker]
As you can see, that worker name is being parsed twice and result in pool reading (probably "null") error on the difficulty and I get rejected shares as well as 10min IP ban LoL if I kept this carry on long enough.
If I specify using default "." delimiter in the pool setting, AM parses following:
-u WalletAddress.[MinerWorker] -p [MinerWorker]
This time, [MinerWorker] still gets parsed twice, but the pool in this case will simply give me an auth error and I will not be able to mine as well.
***
Proposal:
1. In pool settings, if [MinerWorker] is defined in the password field, steps are taken to eliminate double parsing the parameter to the Worker field entirely
2. adding new parameter [UserDefinedDifficulty] in the mechanics similar to [MinerWorker] that we can specify for each Miner in the same way as worker name, this sometimes helps when pool's vardiff changes too erratically (say, optimal for 1 AM miner is 150000 in CN-Heavy, the pool shoots it up to 1mil results in no shares found for 10 min till it drops slowly), this is supposedly very useful when rigs/miners have varying hash power but profit switching interval becomes > than share submitted = losing efficiency. Also (haven't tested out yet) ppl say it's good to define a (suggested) static difficulty where pool supports it for chaotic algos like X16R per rig/miner.
Cheers!
