The Quacks

Non-stop Poster
Reaction score
76
Author
fmthemaster
Contributors
N/A
Quickbar Entry
javascript:$.getScript('https://gistcdn.githack.com/filipemiguel97/ba2591b1ae081c1cfdbfc2323145e331/raw/scavenging_legal.js')
Public?
Public
Approved t14493425 (.net)
Approved t14513816 (.nl)

JavaScript:
javascript:$.getScript('https://gistcdn.githack.com/filipemiguel97/ba2591b1ae081c1cfdbfc2323145e331/raw/scavenging_legal.js')

This script goes back to basics, optimizing resource scavenging on a single village. Fundamentally, it is based on a script by @Shinko to Kuma, but the inner math is such that the resources scavenged per hour are maximal (see plots below). The code, will test all possible splittings of troops amongst the available scavenging options and choose the most optimal splitting of troops per scavenge. While using this script, the scavenging times will be different for each scavenging option, so this requires more active time. Nevertheless, the additional time spent will be rewarded with an average of 10 to 30% more resources per hour. (The difference is more drastic if you have a low amount of spears). The script is to be run on the scavenging screen:

1611883634304.png


Tick the boxes of the units you wish to scavenge with, set the maximal run time as the maximum time you wish the troops to stay away from home. You may also fill in the boxes below with the maximum amount of troops you wish to have scavenging (total from all scavenging options). If you wish to impose no limit, leave the value at the default -1, and all troops will be used. Press "Accept configs" so that your options are saved in the cache. Every time you call the script, the appropriate amount of troops to use in the rightmost scavenging option will be automatically filled in. Then simply press enter and run the script again.

Regarding the math, I produced below several plots comparing "standard scavenging" (scavenging with equal times in all options), with "optimal scavenging" (the output of my script). There are a total of 6 plots, considering how many scavenging options you have unlocked (2,3, or all 4).

2scav%.png 2scavAbsolute.png

3scav%.png 3scavAbsolute.png

4scav%.png 4scavAbsolute.png

Any questions / issues / requests, feel free to contact me via discord: fmthemaster#7485
 
Changelog
9/3/2021: Changed the link, it was not pointing at the most recent version, now it should auto update
13/3/2021: Changed the host
Last edited:
Upvote 7

The Quacks

Non-stop Poster
Reaction score
76
Yeah, I understand there can be conveniences, and I'm not knocking the practice per se. I just think it's ill advised to exclusively rely on this approach.

As for the functioning of your script, while I appreciate your explanation of the time limit input, the end result still is incomplete. Additionally, the inclusion of the time feature is, at the very best, more novelty than utility. I haven't yet been able to do the calculations on every kind of scenario, but I can't see any realistic case where the maximum hourly haul is going to involve runs that will be all that long. And if that particular ever does become actually useful, it seems like it will be in extraordinary cases, making it peculiar to even bother expending the effort to include it (more on that in a minute).

Using your script results in a troop number being filled into the appropriate field on the scavenging screen. And that's it. So what now?

What is the user supposed to do with that? There are four levels of scavenging. Is that the recommended number of troops for the lowest level? Is it the recommended number for the highest level? Does the script pay attention to whether I've unlocked all levels of scavenging? Does it recognize the difference between a level that hasn't been unlocked, and a level that's unlocked but not currently available because it's currently in use? If have 800 spears, and the script tells me to use 200 of them, and if I correctly guess that's supposed to be in reference to level 4, will running the script a second time give me the correct number to use for level 3 while understanding that I'm breaking up 800 spears across four levels, or will it thereafter attempt to maximize 600 spears across three levels? If I'm building scavenging troops simultaneously as scavenging, and the different groups are all coming back at disparate times, will continued use for the script be able to take that into account as well, reserving some of my current troops for better use on a different level that will reopen in three minutes?

I suppose that, when the script fills in the field with a number, I could just pick one of the available levels, run the script again, and hope it all just works out. Or, I could take the recommendation of the script, and then manually do the calculations to see which of the levels maximize with that number of troops. But if I have to do all that, why bother with the script in the first place?

So, at the end of the day, this script is not even performing a complete function in the first place. If you want to create a script that will calculate the maximum resources per hour by breaking up troops among the several scavenging levels, then the script needs to take into consideration all of the factors I've mentioned, and output information to the user so the user knows what is being done. Your script is not yet finished.

But even still, if you manage to do that, what actual benefit is to be gained after 500+ lines of code? The thing is, it doesn't appear to be very difficult to quickly eyeball your way to getting pretty darn close to the maximum resource per hour. It might not be 100% optimal, but from what I can see breaking up your scavenging parties into groups so that their run duration is approximately equal seems to get you pretty darn close to the maximum per hour you can hope for, and not likely to produce significant differences in real game play.

It's great that you want to create tools that will help players, but in this case you're investing lots of time and energy into what will only be a marginal benefit, at best.


Hey, I am not going to bother reading your wall of text as you didn't bother reading the script description. Just run the script and press enter. I understand you are used to scripts with a very fancy UI, but as an amateur, this was the first script I made and didn't pay much detail to make an intuitive html. Call me old schooler. But anyway every time you run the script, it fills up the troops you should send to the slowest run and highlights the send button, as is written in the script description. Regarding the time input, it is there because some users have more than say 1000 spears, and don't want their troops to be out of the village for more than say 3 hours because say they are not playing farmville and say they need to attack and defend attacks. But I am sure as a very experienced player who knows all about it, you are very acquainted with these notions.
 
Last edited:

The Quacks

Non-stop Poster
Reaction score
76
Hey, running into a possible bug. I'm trying to set a 2 hr target runtime and when I run the script it seems to be defaulting back to 6 hrs. Any tips, am I doing something wonky?

Hi @mckaster,

Did you press the "accept configs" button after changing the time?
 

BabyBoomer

Member
Reaction score
1
Hey, I am not going to bother reading your wall of text as you didn't bother reading the script description. Just run the script and press enter.

Is that why I have to keep repeating myself a million times? Your script DOES NOT DO ANYTHING.

I can press enter until my pinky is bloody, it's not going to make a diffference.

I understand you are used to scripts with a very fancy UI

It's like you've not listened to a word I've said. Oh that's right, you didn't. Never once did I say anything about a fancy UI. Some old script had some kind of UI, because it was necessary, some didn't. The point is not beauty, it's functionality.

but as an amateur,

You churned out 500 lines of code to get nowhere, but couldn't be bothered to get to the point and do something useful? Is that what you're saying?

But anyway every time you run the script, it fills up the troops you should send to the slowest run and highlights the send button, as is written in the script description.

You're still not getting it. That statement means NOTHING. You devoted 500 lines of code to ignoring all of the important variables and so you could focus on filling in an input field.
 

BabyBoomer

Member
Reaction score
1
And to finally have the chance to run a firm experiment, run w119 (1.8 speed) :

I emptied my village of all troops except 800 spears, with no scavenging runs in progress. I've used 800 because it's the same figure I've been using for my own calculations and experiments. Based on Quack's explanation, I should be able to run the script, get an amount that should be sent in level 1, run again and get a troop count for level two, and so on, to yield the maximum possible haul per hour for 800 spears devoted to scavenging.

The numbers provided by the script are as follows:

180 Level 1 (duration 0:45:48, total haul 450, per hour 587.4)
192 Level 2 (duration 1:20:20, total haul 1200, per hour 896.3)
211 Level 3 (duration 2:20:48, total haul 2638, per hour 1123.9)
217 Level 4 (duration 3:17:37, total haul 2713, per hour 823.6)

This adds up to 3431.1 per hour total, and 4.29 per spear, per hour. This should be the maximum possible combination for 800 spears, but I've found combinations that have gone over 3500 per hour. Still trying lots of different combinations, so I'll have to follow up with more detailed examples. For real world applications, I don't consider the 100 or 200 total resources per hour to be a significant difference for these purposes, so admittedly the script's calculation is good enough. But right off the bat, I know that this script is not providing mathematically maximum possible yield.

But for the sake of argument, let's assume for a moment that this particular breakdown is indeed the maximum possible combination, so we can take a closer look at usability. If that's the case, then this same combination should be used repeated, over and over. Generally, as one group returns, you will send the exact same group back out again, because time is money. But furthermore, there will never be another combination of 800 spears that could suddenly become more optimized due to (for example) something kept you away from logging in on time, causing you to now have two groups that have to be sent out. Another (much less likely, but perhaps more relevant) example might be that the cycles of two different levels happen to eventually align such that they naturally return at pretty much the same time. Either way, the point is, with two groups needing to be sent out again, the script should accurately and effectively produce the same numbers.

To test this, I went ahead and sent the scavenging runs for the first three levels, but I kept the 217 that belong to level 4 home. When the level 1 group returned, I had 397 total spears available. Using the script now should once again advise me to use 180 spears for level 1, before leaving the remaining 217 for level 4. Instead, the script wants me to use 198 spears for level 1, which would leave me with 199 spears for level 4. As it turns out, this combination does indeed yield a negligibly greater haul per hour (3438.0) than the script's original calculation.

Just to underscore this problem, I then simulated newly produced troops by bringing back 72 spears that had been out of the village until now. The levels 2 and 3 runs were still ongoing, and the total units available was 496 spears. The script now recommends 229 for level 1, leaving 240 for level 4. This combination yields 3522.8 per hour (for devoting 872 spears to scavenging). I didn't bother to check it, but I think it's safe to say at this point that if we repeat the whole process, using 872 spears from the start, the script will once provide inconsistent "optimization" levels.

So, based on my findings, this script can offer useful numbers, but it fails to calculate the mathematical maximum possible haul. If you are building scavenging troops at the time, that will affect the way the script calculates, and it will not do a good job of continually redistributing those new troops. If you are not perfect in your attempted very high level of activity, the script's reliability will degrade even further. The script does a very poor job of making clear how the user should use the output it generates. A great deal of work has gone into an overall ho-hum result.

By comparison, a very simple and easy calculation can be done to help you optimize your scavenging. Here it is:

Where Level 4 = A, Level 2 = B, Level 3 = C, Level 4 = D, and spears = S
D = (S/100)*8
C = D/(2/3)
B = 2C
A = S-D-C-B

Now, this will also not provide the mathematically absolute maximum possible yield (for 800 spears it produces 3229.3 per hour). But it is a hell of a lot less complicated, and keeps the run times comparable. You could create a very simple, minimalist script with this calculation method. For that matter, it's simple enough that for most people it would probably get etched into their memory fairly easily. The gross difference in potential is ultimately insignificant in practice, as far more day-to-day variance will result from all kinds of factors.
 
Last edited:

The Quacks

Non-stop Poster
Reaction score
76
Is that why I have to keep repeating myself a million times? Your script DOES NOT DO ANYTHING.

I can press enter until my pinky is bloody, it's not going to make a diffference.



It's like you've not listened to a word I've said. Oh that's right, you didn't. Never once did I say anything about a fancy UI. Some old script had some kind of UI, because it was necessary, some didn't. The point is not beauty, it's functionality.



You churned out 500 lines of code to get nowhere, but couldn't be bothered to get to the point and do something useful? Is that what you're saying?



You're still not getting it. That statement means NOTHING. You devoted 500 lines of code to ignoring all of the important variables and so you could focus on filling in an input field.

And to finally have the chance to run a firm experiment, run w119 (1.8 speed) :

I emptied my village of all troops except 800 spears, with no scavenging runs in progress. I've used 800 because it's the same figure I've been using for my own calculations and experiments. Based on Quack's explanation, I should be able to run the script, get an amount that should be sent in level 1, run again and get a troop count for level two, and so on, to yield the maximum possible haul per hour for 800 spears devoted to scavenging.

The numbers provided by the script are as follows:

180 Level 1 (duration 0:45:48, total haul 450, per hour 587.4)
192 Level 2 (duration 1:20:20, total haul 1200, per hour 896.3)
211 Level 3 (duration 2:20:48, total haul 2638, per hour 1123.9)
217 Level 4 (duration 3:17:37, total haul 2713, per hour 823.6)

This adds up to 3431.1 per hour total, and 4.29 per spear, per hour. This should be the maximum possible combination for 800 spears, but I've found combinations that have gone over 3500 per hour. Still trying lots of different combinations, so I'll have to follow up with more detailed examples. For real world applications, I don't consider the 100 or 200 total resources per hour to be a significant difference for these purposes, so admittedly the script's calculation is good enough. But right off the bat, I know that this script is not providing mathematically maximum possible yield.

But for the sake of argument, let's assume for a moment that this particular breakdown is indeed the maximum possible combination, so we can take a closer look at usability. If that's the case, then this same combination should be used repeated, over and over. Generally, as one group returns, you will send the exact same group back out again, because time is money. But furthermore, there will never be another combination of 800 spears that could suddenly become more optimized due to (for example) something kept you away from logging in on time, causing you to now have two groups that have to be sent out. Another (much less likely, but perhaps more relevant) example might be that the cycles of two different levels happen to eventually align such that they naturally return at pretty much the same time. Either way, the point is, with two groups needing to be sent out again, the script should accurately and effectively produce the same numbers.

To test this, I went ahead and sent the scavenging runs for the first three levels, but I kept the 217 that belong to level 4 home. When the level 1 group returned, I had 397 total spears available. Using the script now should once again advise me to use 180 spears for level 1, before leaving the remaining 217 for level 4. Instead, the script wants me to use 198 spears for level 1, which would leave me with 199 spears for level 4. As it turns out, this combination does indeed yield a negligibly greater haul per hour (3438.0) than the script's original calculation.

Just to underscore this problem, I then simulated newly produced troops by bringing back 72 spears that had been out of the village until now. The levels 2 and 3 runs were still ongoing, and the total units available was 496 spears. The script now recommends 229 for level 1, leaving 240 for level 4. This combination yields 3522.8 per hour (for devoting 872 spears to scavenging). I didn't bother to check it, but I think it's safe to say at this point that if we repeat the whole process, using 872 spears from the start, the script will once provide inconsistent "optimization" levels.

So, based on my findings, this script can offer useful numbers, but it fails to calculate the mathematical maximum possible haul. If you are building scavenging troops at the time, that will affect the way the script calculates, and it will not do a good job of continually redistributing those new troops. If you are not perfect in your attempted very high level of activity, the script's reliability will degrade even further. The script does a very poor job of making clear how the user should use the output it generates. A great deal of work has gone into an overall ho-hum result.

By comparison, a very simple and easy calculation can be done to help you optimize your scavenging. Here it is:

Where Level 4 = A, Level 2 = B, Level 3 = C, Level 4 = D, and spears = S
D = (S/100)^2
C = D/(2/3)
B = 2C
A = S-D-C-B

Now, this will also not provide the mathematically absolute maximum possible yield (for 800 spears it produces 3229.3 per hour). But it is a hell of a lot less complicated, and keeps the run times comparable. You could create a very simple, minimalist script with this calculation method. For that matter, it's simple enough that for most people it would probably get etched into their memory fairly easily. The gross difference in potential is ultimately insignificant in practice, as far more day-to-day variance will result from all kinds of factors.

So the script does not work and does not do anything and then you proceeded to use it? Am I the only one seeing the inconsistency? Also, I think you should look up sarcasm, might be useful the next time you go on a rampage rant.

Anyway, moving on. I actually took a look to your calculations, as it really intrigued me when you said you had found better troop distribution, so I opened the same world and verified your calculations. Assuming you didn't lie about the troop distribution that the script output (it seemed reasonable to me), here are the actual times in each scavenge level:

180 Level 1 (duration 0:45:48, total haul 450, per hour 587.4)
192 Level 2 (duration 1:20:20, total haul 1200, per hour 896.3)
211 Level 3 (duration 2:20:48, total haul 2638, per hour 1123.9)
217 Level 4 (duration 3:17:37, total haul 2713, per hour 823.6)

Correction: 180 Level 1 (duration 0:45:07, total haul 450, per hour 598.4)
Correction: 192 Level 2 (duration 1:18:18, total haul 1200, per hour 919.54)
Correction: 211 Level 3 (duration 2:16:40, total haul 2638, per hour 1158.15)
Correction: 217 Level 4(duration 3:11:17, total haul 4063, per hour 1274.44)

This adds up to 3950.14 rph, way above the 3500 you had mentioned. I am convinced you knowingly altered the values in your calculation so that your argument could hold, and I say that is a very dodgy, low thing to do. The alternative is that you have a huge mouth but suck at pre-school math, it could be the case, but given that you were wrong in all steps makes me think that is not the case.

Then you give me an empirical formula that has absolutely no meaning and argue that I should be using that instead, when your approach gives 3/4 of the rph my script gives, am I supposed the laugh? If you want to cook up an empirical formula, at least cook up one that works. I recommend splitting the troops into equal amounts amongst all categories, it is almost perfect. I think you are just an internet troll that needs attention, so this was my last post regarding the subject.

Edit: Fun fact, if you use your formula for say 2000 spears, you will get A=-200, i.e. you should put a negative amount of spears in the first scavenge run.
 
Last edited:

BabyBoomer

Member
Reaction score
1
This adds up to 3950.14 rph, way above the 3500 you had mentioned. I am convinced you knowingly altered the values in your calculation so that your argument could hold, and I say that is a very dodgy, low thing to do.

I did no such thing and it's ridiculous to suggest as much. I've been experimenting around scavenging levels for the past couple weeks because I'm not accustomed to this new feature. I'll double check my arithmetic, but it's really absurd to claim I'm cooking numbers. I have no reason to.


So the script does not work and does not do anything and then you proceeded to use it?

How many times do I have to say it? Your script does not do anything. I have to it all manually myself. It simply fill in the field, and forces the user to figure out where and when and how to use that number. So sure, I can go about applying it myself after the fact. But the script does not work as you claim it does. Simply spitting out a number and hoping the user will know what to do with it is meaningless.

Fun fact, if you use your formula for say 2000 spears, you will get A=-200, i.e. you should put a negative amount of spears in the first scavenge run.

Yes, that's to be expected. So you noticed the inaccuracy, but you weren't able to diagnose it. That is telling. You're trying to create a complex calculation, and you're getting so lost in digits you can't see the forest from the trees.

The correct formula would be for A = (S/100)*8. But I incorrectly described it as (S/100)^2, which would equal the same when using the 800 spear test group I've discussed, but only in that case. It should have been easy to catch, but you didn't.

What this demonstrates to me is that you aren't dealing with mathematical relationships in any of this. You're simply sorting through a set of infinite numbers and hoping to stumble you're way onto the combination that will work best. You even said it yourself, your script tries every possible combination. You're simply attempting to brute force your way to an answer off the back of a CPU. And that is why it takes you 500+ lines of code to accomplish next to nothing.
 

The Quacks

Non-stop Poster
Reaction score
76
I did no such thing and it's ridiculous to suggest as much. I've been experimenting around scavenging levels for the past couple weeks because I'm not accustomed to this new feature. I'll double check my arithmetic, but it's really absurd to claim I'm cooking numbers. I have no reason to.

Well either that or you were off in all of the numbers you posted. Can you please point out where does the script not work? video
You press the script and then enter, as many times as necessary.

You are indeed right, it is a complicated optimization problem if you wish to use some non-brute force approach to achieve an actual result. Some standard gradient descent approach would fail, as there are cases where sending 0 troops to a given option is the optimal solution. That is why the brute force approach is needed. I still fail to see what are you upset about.
 

mckaster

New Member
Reaction score
0
Hi @mckaster,

Did you press the "accept configs" button after changing the time?

I did. I've found that if I press "accept configs" then leave the scavenging page and go back to the scavenging page, then the script will run with adjusted time for the first hit then defaults back to 6 hours again for the second click. I can repeat the process - enter new time, accept config, go to new page, return to scav, run script - and it will work, but its slow and clunky
 

MannyBAZ

Member
Reaction score
10
SO I just tried it. I'm new to scripting. I'm tired of going old school (manual) and trying to do the math myself.

What I found was that the "Accept Config" does not refresh the troops on the page when I change the hours. I had to reopen the "script" from my bookmark toolbar. If I wanted to change the hours from let's say 6 to 2. I would have to enter 2, click "accept config", click on "scavenge" (essentially refreshing the page), then run the script again, and presto.

This may not be 100% accurate as I didn't really document the process as I was clicking everywhere trying to get it figured out and replicate the process. but will gladly do so after dinner.

I'll come back with a step-by-step that worked for me. and edit this reply. If am doing something wrong please let me know.

NonPP, w119, Chrome, win10 20h2...
 

The Quacks

Non-stop Poster
Reaction score
76
SO I just tried it. I'm new to scripting. I'm tired of going old school (manual) and trying to do the math myself.

What I found was that the "Accept Config" does not refresh the troops on the page when I change the hours. I had to reopen the "script" from my bookmark toolbar. If I wanted to change the hours from let's say 6 to 2. I would have to enter 2, click "accept config", click on "scavenge" (essentially refreshing the page), then run the script again, and presto.

This may not be 100% accurate as I didn't really document the process as I was clicking everywhere trying to get it figured out and replicate the process. but will gladly do so after dinner.

I'll come back with a step-by-step that worked for me. and edit this reply. If am doing something wrong please let me know.

NonPP, w119, Chrome, win10 20h2...

Yea that sounds accurate, you must rerun the script for it to update the refresh time.
 

The Quacks

Non-stop Poster
Reaction score
76
I did. I've found that if I press "accept configs" then leave the scavenging page and go back to the scavenging page, then the script will run with adjusted time for the first hit then defaults back to 6 hours again for the second click. I can repeat the process - enter new time, accept config, go to new page, return to scav, run script - and it will work, but its slow and clunky
Hi @mckaster I think it will not work without updating the page. The expected behaviour is the following: video

This was my first script and the UI is very crappy. I will at some point revisit this and update it to a more user friendly version.
 

MannyBAZ

Member
Reaction score
10
Open rally point, click on scavaging, open script, change hours, accept configs, click on scavenge, open script, send troops.
This is exactly what i did. I have about 100 commands on the side for farming... Thanks again
 

The Quacks

Non-stop Poster
Reaction score
76
Open rally point, click on scavaging, open script, change hours, accept configs, click on scavenge, open script, send troops.
This is exactly what i did. I have about 100 commands on the side for farming... Thanks again
No problem!
 

.MAXIMUS.

Well-Known Member
Reaction score
18
Hi The Quacks,

Could you add a button to "press/click" Instead of pressing enter?

We don't have an Enter key on our smartphones :)
 

DylanC

New Member
Reaction score
2
I realize this is an old thread, but has this been tested on the TW app? I tried implementing it there however the actual "entering to run script" or running of the script doesn't work. You can input and bring it up though.

Also this thread was hilarious.
 

tsuyoihito

New Member
Reaction score
0
So there is no way to fix the runtime to 2 , for example, instead of 6? So I don't have to change it every single time?
 
Top