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
Guys, due to dropbox limiting the access to my scripts, I had to change the script hosting service. In practice, this means that you must change the script code to the one currently above. The old link will expire within one week!
 

wazaah

New Member
Reaction score
0
I can´t get it to work. Only me?

Edit: I got it working by opening the scavenging page first, then running the script.

Thank you.
 
Last edited:

The Quacks

Non-stop Poster
Reaction score
76
I can´t get it to work. Only me?

Edit: I got it working by opening the scavenging page first, then running the script.

Thank you.
Dear @wazaah , there was a bug in the script that prevented it from redirecting you to the scavenge screen if run from outside. This should be now corrected and implemented in the script within the next hour. THank you for your message.
 

The Quacks

Non-stop Poster
Reaction score
76
I had the wrong link in here, it was not targeted at the most recent update. If you want the most recent version, please update to the script in the post.
 

The Quacks

Non-stop Poster
Reaction score
76
And 4 days later, another update. Apparently, this script has been getting a lot of usage, and the host got banned. I will attempt a new host that claims to nadle more traffic. This is a temporary solution until I find a better way to host my scripts.
 

mckaster

New Member
Reaction score
0
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?
 

BabyBoomer

Member
Reaction score
1
And 4 days later, another update. Apparently, this script has been getting a lot of usage, and the host got banned. I will attempt a new host that claims to nadle more traffic. This is a temporary solution until I find a better way to host my scripts.

You know, back in my day, the normal practice was to post the actual code for the script itself, which would preempt this kind of problem from ever happening. Why don't people do this anymore?
 

Shinko to Kuma

Still Going Strong
Reaction score
776
You know, back in my day, the normal practice was to post the actual code for the script itself, which would preempt this kind of problem from ever happening. Why don't people do this anymore?

Cause back in your day, scripts were 5 lines of code and barely did anything. There is a character limit on TW and most of the modern scripts have hundreds, sometimes thousands of lines of code. The only way to use scripts like that is with a script loader
 

BabyBoomer

Member
Reaction score
1
Cause back in your day, scripts were 5 lines of code and barely did anything. There is a character limit on TW and most of the modern scripts have hundreds, sometimes thousands of lines of code. The only way to use scripts like that is with a script loader

Well crikey, no wonder they're causing browser freezes.

I disagree with your premise, though. There were many old scripts that did quite a lot, whereas most of the newer scripts I've been seeing don't seem to actually do much. Many seem to be based on a fundamental over complication of what should be simple matters. And that, like so much of coding nowadays, decays into mental fatigue, leading to end products that take a long time to not be very useful and forcing the user to walk around the problem the long way.

This current script is a good example. Trying to use it, I'm finding that it's entirely useless as designed, as it fails to perform the function it purports to do. Instead, the user has to manually figure out the optimization ahead of time, then simply use this script to input numbers. In the "old days" scripts were designed to do 95% of the work for you. But now, the user has to do the 95%, then use the script to do the remainder.

For the 500+ lines of code I've now found this script to be, this script really does nothing. The user has to first decide a time frame, which is an idiotic requirement. How can I choose a time frame without first doing the manual calculations myself? Sure, after I do all the various calculations, I can then choose which time frame corresponds with the maximal hourly haul and use this script to then generate the number of spears I would now know will correspond to that time frame, by why bother? The need to figure all this out ahead of time is made all the more mandatory because, at the end of the day, all this script does is fill in a number into the field. There's no way for the user to have any idea what to do with that number. Should I be sending that group out for level 1? Was this meant to be level 4? The only way to know is if the user has already calculated the optimal levels themselves.

A useful scavenging optimizer script should do the calculation on behalf of the user, then spit out clear and useful information. Render a display that tells the user "X spears in level 4, Y spears in level 2" etc. Don't ask me for a target time. The whole purpose of using such a script is to maximize productivity, not drag out productivity to match an arbitrary time frame. Automatically filling in the field should be treated as a bonus convenience, not the primary objective.

Okay, the failings of this particular script aside, I think it would still be a best practice to provide the source code for a script and encourage people to host the scripts they like to use themselves. Anyone can do that nowadays for free. Granted, there's a trade off, in that some people may prefer the convenience of instantly enjoying any updates you might make without having to worry about it. But I'm sure others will also prefer being able to know they don't have to be dependent on someone else's hosting for their quick bar to stay active. Not to mention, most people once upon a time learned how to at least do some basic script editing to modify scripts to their preferences or individual needs, which led to better ingenuity back then.
 

Shinko to Kuma

Still Going Strong
Reaction score
776
Well crikey, no wonder they're causing browser freezes.

I disagree with your premise, though. There were many old scripts that did quite a lot, whereas most of the newer scripts I've been seeing don't seem to actually do much. Many seem to be based on a fundamental over complication of what should be simple matters. And that, like so much of coding nowadays, decays into mental fatigue, leading to end products that take a long time to not be very useful and forcing the user to walk around the problem the long way.

This current script is a good example. Trying to use it, I'm finding that it's entirely useless as designed, as it fails to perform the function it purports to do. Instead, the user has to manually figure out the optimization ahead of time, then simply use this script to input numbers. In the "old days" scripts were designed to do 95% of the work for you. But now, the user has to do the 95%, then use the script to do the remainder.

For the 500+ lines of code I've now found this script to be, this script really does nothing. The user has to first decide a time frame, which is an idiotic requirement. How can I choose a time frame without first doing the manual calculations myself? Sure, after I do all the various calculations, I can then choose which time frame corresponds with the maximal hourly haul and use this script to then generate the number of spears I would now know will correspond to that time frame, by why bother? The need to figure all this out ahead of time is made all the more mandatory because, at the end of the day, all this script does is fill in a number into the field. There's no way for the user to have any idea what to do with that number. Should I be sending that group out for level 1? Was this meant to be level 4? The only way to know is if the user has already calculated the optimal levels themselves.

A useful scavenging optimizer script should do the calculation on behalf of the user, then spit out clear and useful information. Render a display that tells the user "X spears in level 4, Y spears in level 2" etc. Don't ask me for a target time. The whole purpose of using such a script is to maximize productivity, not drag out productivity to match an arbitrary time frame. Automatically filling in the field should be treated as a bonus convenience, not the primary objective.

Okay, the failings of this particular script aside, I think it would still be a best practice to provide the source code for a script and encourage people to host the scripts they like to use themselves. Anyone can do that nowadays for free. Granted, there's a trade off, in that some people may prefer the convenience of instantly enjoying any updates you might make without having to worry about it. But I'm sure others will also prefer being able to know they don't have to be dependent on someone else's hosting for their quick bar to stay active. Not to mention, most people once upon a time learned how to at least do some basic script editing to modify scripts to their preferences or individual needs, which led to better ingenuity back then.

Either you have no clue about coding, or you're just basing your entire view on this singular script. Even in the past scripts that had complex calculations or a more user friendly experience, they used a script loader. You can literally view the code if you want by going directly to the url in the loader.

Scripts "freezing" up your browser? Are you using a windows 95 PC with a pentium 2 processor and 64MB of RAM?

Your "suggestion" for letting people "host" the script themselves are silly too. For one, most people would have no clue where to start.

For this script specifically, it asks a target time so people can decide how often they want to recheck when to send. There are plenty other scav scripts out there that spread it differently, but this one aims for highest res per hour considering how long you want them to run.
 

BabyBoomer

Member
Reaction score
1
Either you have no clue about coding, or you're just basing your entire view on this singular script. Even in the past scripts that had complex calculations or a more user friendly experience, they used a script loader.

It seems that you're the one who doesn't know what you're talking about. Because no, that hasn't always been the case. It was once unheard of. When offering a script for use, you posted the actual script. Overly complex scripts were nonexistent. If you couldn't accomplish the job without ten pages worth of code, then you couldn't accomplish the job at all.

I know you think the universe began when you first started playing tribal wars, but there's actually been billions of years that led up to that moment in time. So pull your head out of your rear end.

You can literally view the code if you want by going directly to the url in the loader.

Yes, I know I can view the script by going to the URL. But that does no good if the host goes down. And it would leave the script at the mercy of the hosting party's continued hosting. If it disappears, it disappears forever.

Scripts "freezing" up your browser? Are you using a windows 95 PC with a pentium 2 processor and 64MB of RAM?

I notice you didn't say that to quacks when he said he had to update the script to prevent freezing. So I have to conclude that the only reason you're throwing around that particular ad hominem now is because what I've said has hit a nerve and you're now feeling sensitive.

Your "suggestion" for letting people "host" the script themselves are silly too. For one, most people would have no clue where to start.

Oh get over yourself. It's not difficult in the slightest. Anyone can create their own dropbox and upload a file. Should we get rid of toilet paper too, for people who don't know where to start? Or should we teach them how to wipe their asses themselves? You're just trying to aggrandize yourself by pretending mindlessly simple tasks are somehow beyond most people.

For this script specifically, it asks a target time so people can decide how often they want to recheck when to send. There are plenty other scav scripts out there that spread it differently, but this one aims for highest res per hour considering how long you want them to run.

Do you not hear how insanely stupid that sounds? It maximizes highest resources per hour for when you want a specific time frame? That's like saying you need a script to maximize your driving distance if you want to drive 50 miles an hour for one hour. What's next? Will we see a script that will calculate your maximum haul based on the total number of light cavalry you specify? If you want two hour scavenging runs, then you simply adjust your troops for two hour scavenging runs, starting with the highest available level. There is no "optimizing" for maximum haul per hour when you define a specific time frame, because the haul per hour for each respective scavenging level will always be the same at that designated time frame. If X spears can scavenge Y resources in two hours at level four, then the maximum resources per hour will always be Y/2 when the user designates one hour as the target time frame. There is nothing to optimize.

What you are describing is not optimization in any way, shape, or form. And your explanation is contradicted by the OP himself. He states that the duration will be different for each scavenging level. He is clearly claiming that the script will provide the user with the MAXIMUM PER HOUR.
 

Shinko to Kuma

Still Going Strong
Reaction score
776
It seems that you're the one who doesn't know what you're talking about. Because no, that hasn't always been the case. It was once unheard of. When offering a script for use, you posted the actual script. Overly complex scripts were nonexistent. If you couldn't accomplish the job without ten pages worth of code, then you couldn't accomplish the job at all.

I know you think the universe began when you first started playing tribal wars, but there's actually been billions of years that led up to that moment in time. So pull your head out of your rear end.



Yes, I know I can view the script by going to the URL. But that does no good if the host goes down. And it would leave the script at the mercy of the hosting party's continued hosting. If it disappears, it disappears forever.



I notice you didn't say that to quacks when he said he had to update the script to prevent freezing. So I have to conclude that the only reason you're throwing around that particular ad hominem now is because what I've said has hit a nerve and you're now feeling sensitive.



Oh get over yourself. It's not difficult in the slightest. Anyone can create their own dropbox and upload a file. Should we get rid of toilet paper too, for people who don't know where to start? Or should we teach them how to wipe their asses themselves? You're just trying to aggrandize yourself by pretending mindlessly simple tasks are somehow beyond most people.



Do you not hear how insanely stupid that sounds? It maximizes highest resources per hour for when you want a specific time frame? That's like saying you need a script to maximize your driving distance if you want to drive 50 miles an hour for one hour. What's next? Will we see a script that will calculate your maximum haul based on the total number of light cavalry you specify? If you want two hour scavenging runs, then you simply adjust your troops for two hour scavenging runs, starting with the highest available level. There is no "optimizing" for maximum haul per hour when you define a specific time frame, because the haul per hour for each respective scavenging level will always be the same at that designated time frame. If X spears can scavenge Y resources in two hours at level four, then the maximum resources per hour will always be Y/2 when the user designates one hour as the target time frame. There is nothing to optimize.

What you are describing is not optimization in any way, shape, or form. And your explanation is contradicted by the OP himself. He states that the duration will be different for each scavenging level. He is clearly claiming that the script will provide the user with the MAXIMUM PER HOUR.

You need to get YOUR head out of your ass

Some of the most used scripts in the past:


https://forum.tribalwars.net/index.php?threads/resource-balancer-script.172320/ (this one actually sent you to an entirely different domain to run a python script for you)





Pretty much ALL very powerful scripts since the beginning of time have used script loaders. Just cause you have the memory of Dori from finding nemo, doesn't mean you are correct.

Especially if you start adding html to provide an interface for the script to help out user experience, you run into character limits VERY quickly. But this is my last response to you considering you are either a troll, or someone so convinced of their own correctness they are not open to the thought of potentionally being wrong
 

The Quacks

Non-stop Poster
Reaction score
76
Hi @BabyBoomer

Thank you for all the very helpful comments and advice. I and the majority of the others here feel like using a script loader is a much better way to distribute scripts and more importantly keep them updated. Regarding the script itself, I think you missed the point. You do not need to set the hour parameter or do any prior calculations, for the script to work, simply set it to 99999999999 if you don't want to bother with it. This parameter is only there to establish an upper bound on how much is the maximum time you want your troops to be away. If the optimal distribution of troops does not send them away for longer than this parameter, then the script will not care about this parameter, and simply optimize the distribution of troops such that you achieve maximum resources per hour. I sugest next time you go on a rant about this and that to better inform yourself.
 

RedAlert

Senior In-Game Staff
Tribal Wars Team
Senior
Team
Script Moderator
Reaction score
608
Well crikey, no wonder they're causing browser freezes.

I disagree with your premise, though. There were many old scripts that did quite a lot, whereas most of the newer scripts I've been seeing don't seem to actually do much. Many seem to be based on a fundamental over complication of what should be simple matters. And that, like so much of coding nowadays, decays into mental fatigue, leading to end products that take a long time to not be very useful and forcing the user to walk around the problem the long way.

This current script is a good example. Trying to use it, I'm finding that it's entirely useless as designed, as it fails to perform the function it purports to do. Instead, the user has to manually figure out the optimization ahead of time, then simply use this script to input numbers. In the "old days" scripts were designed to do 95% of the work for you. But now, the user has to do the 95%, then use the script to do the remainder.

For the 500+ lines of code I've now found this script to be, this script really does nothing. The user has to first decide a time frame, which is an idiotic requirement. How can I choose a time frame without first doing the manual calculations myself? Sure, after I do all the various calculations, I can then choose which time frame corresponds with the maximal hourly haul and use this script to then generate the number of spears I would now know will correspond to that time frame, by why bother? The need to figure all this out ahead of time is made all the more mandatory because, at the end of the day, all this script does is fill in a number into the field. There's no way for the user to have any idea what to do with that number. Should I be sending that group out for level 1? Was this meant to be level 4? The only way to know is if the user has already calculated the optimal levels themselves.

A useful scavenging optimizer script should do the calculation on behalf of the user, then spit out clear and useful information. Render a display that tells the user "X spears in level 4, Y spears in level 2" etc. Don't ask me for a target time. The whole purpose of using such a script is to maximize productivity, not drag out productivity to match an arbitrary time frame. Automatically filling in the field should be treated as a bonus convenience, not the primary objective.

Okay, the failings of this particular script aside, I think it would still be a best practice to provide the source code for a script and encourage people to host the scripts they like to use themselves. Anyone can do that nowadays for free. Granted, there's a trade off, in that some people may prefer the convenience of instantly enjoying any updates you might make without having to worry about it. But I'm sure others will also prefer being able to know they don't have to be dependent on someone else's hosting for their quick bar to stay active. Not to mention, most people once upon a time learned how to at least do some basic script editing to modify scripts to their preferences or individual needs, which led to better ingenuity back then.

Hello @BabyBoomer ,

I am a scripter and have created a lot of these new scripts you mention to be worthless. Not going to judge that though. Everyone has the right to have his opinions and likes and we value that.

My reply here is because this all started because you say let's have the script itself be shared, instead of, the loader script. A lot of scripts are shared that way and that is legal. For as long as the script follows the rules, it can be shared even like that, nothing wrong with it technically and legally (for as long as the script is not that big that it does not fit into the quick-bar).

But let's keep in mind that we as scripters, create scripts for players, which most of the time don't know how to deal with scripts shared like that. Sometime, they copy only part of the code, sometime they copy all. What this means is that a lot of players won't be able to use the script at all. Surely that is not a good thing. We as scripters can't expect everyone to have same technical knowledge as us, or as you. So we try to make things as easy as possible for the player.

How do we try to make things as easy as possible for the player?
- By sharing our scripts using a script loader which makes including that script on your quick-bar way faster and minimizes errors compared to when you share the source code (but again the source is visible if you open the script)
- By offering a graphical user interface (a lot of the modern scripts do that). This helps to make the script usable not just for tech-savy players but for everyone who likes to use the script.
- By sharing a script loader you, the player, always will get the latest version of the script automatically, as soon as the scripter publishes it. This saves you time since you wont need to check daily here. With you, I am not referring to you specifically, but to all the players.
- By making sure the script is run on the correct screen game. I have seen scripts which when run do nothing because they are run on the wrong screen (those old scripts you mention to be so good).

How these decisions affect the player?
Well yes, sometime having a script loader is bad because hosting is down but the benefits outweigh the single possible failure IMO.


I wanted to add something about what you called overcomplication.
We don't want to write more code then we should.
I mean we are lazy. scripters are lazy :p

So why do we do that?
To make things as easy as possible for the players, by offering them a user interface to easily interact with the script.
A lot of us writing scripts are professional programmers and we try to bring that experience, those same professional code writing practices even here, as much as we can, as much as we know.
Because on the long run it helps us too (we are humans, we do mistakes, we have lifes outside TW, well some of us do at least :p) to have more maintainable scripts.

But why do we write such long or big scripts (1k lines of code)?
Because they solve a problem. A problem we might have, a problem players might have, etc. It could be coded in fewer lines of code but still as mentioned above we take some technical decisions because of our own coding experience, as much coding experience as we have.
Because we try to write good code, or what we think is good code (let's remember that each scripter has its own coding experience).
Because we try to catch those edge cases or help redirect a player who is lost and does not know where to run the script (as much as we can based on each scripters experience).

Thank you for your opinions and input on this script.
 

BabyBoomer

Member
Reaction score
1
Hello @BabyBoomer ,

I am a scripter and have created a lot of these new scripts you mention to be worthless. Not going to judge that though. Everyone has the right to have his opinions and likes and we value that.

My reply here is because this all started because you say let's have the script itself be shared, instead of, the loader script. A lot of scripts are shared that way and that is legal. For as long as the script follows the rules, it can be shared even like that, nothing wrong with it technically and legally (for as long as the script is not that big that it does not fit into the quick-bar).

But let's keep in mind that we as scripters, create scripts for players, which most of the time don't know how to deal with scripts shared like that. Sometime, they copy only part of the code, sometime they copy all. What this means is that a lot of players won't be able to use the script at all. Surely that is not a good thing. We as scripters can't expect everyone to have same technical knowledge as us, or as you. So we try to make things as easy as possible for the player.

How do we try to make things as easy as possible for the player?
- By sharing our scripts using a script loader which makes including that script on your quick-bar way faster and minimizes errors compared to when you share the source code (but again the source is visible if you open the script)
- By offering a graphical user interface (a lot of the modern scripts do that). This helps to make the script usable not just for tech-savy players but for everyone who likes to use the script.
- By sharing a script loader you, the player, always will get the latest version of the script automatically, as soon as the scripter publishes it. This saves you time since you wont need to check daily here. With you, I am not referring to you specifically, but to all the players.
- By making sure the script is run on the correct screen game. I have seen scripts which when run do nothing because they are run on the wrong screen (those old scripts you mention to be so good).

How these decisions affect the player?
Well yes, sometime having a script loader is bad because hosting is down but the benefits outweigh the single possible failure IMO.


I wanted to add something about what you called overcomplication.
We don't want to write more code then we should.
I mean we are lazy. scripters are lazy :p

So why do we do that?
To make things as easy as possible for the players, by offering them a user interface to easily interact with the script.
A lot of us writing scripts are professional programmers and we try to bring that experience, those same professional code writing practices even here, as much as we can, as much as we know.
Because on the long run it helps us too (we are humans, we do mistakes, we have lifes outside TW, well some of us do at least :p) to have more maintainable scripts.

But why do we write such long or big scripts (1k lines of code)?
Because they solve a problem. A problem we might have, a problem players might have, etc. It could be coded in fewer lines of code but still as mentioned above we take some technical decisions because of our own coding experience, as much coding experience as we have.
Because we try to write good code, or what we think is good code (let's remember that each scripter has its own coding experience).
Because we try to catch those edge cases or help redirect a player who is lost and does not know where to run the script (as much as we can based on each scripters experience).

Thank you for your opinions and input on this script.

I realize that not everyone will have the same level of knowledge about how to modify a script, and I understand that there could be conveniences for some people to simply hosting a script one's self and letting people simply make a call to it. But there are also key drawbacks. So, as I said, I'm of the opinion that the ideal practice would be to also provide the raw script. I've been trying to search all over the place for the latest scripts, and I've come across multiple instances where the script, once hosted somewhere, is no longer there for whatever reason. Mostly, it seems that someone who no longer plays the game cleared out their dropbox of all their TW related stuff, and now the script they created has been lost in oblivion.

I see no reason to pander to weakness and inability, and that's kind of what you are suggesting. It wasn't so hard once upon a time for players to learn how to use basic scripts and modify them for their particular needs. Do you really believe that you are so magically brilliant that others can't turn the screwdriver as well as you? More often than not, the real issue is that someone's ego is too afraid that if others realize how easy it is to turn the screwdriver themselves, one won't seem so special anymore. The truth is that there's no reason for a script to be so complicated that it can only be handled by a professional programmer. Most of the scripts we used to have were created by hobbyists. Of course, it's great if someone with more advanced knowledge wants to put forth the time and effort to create complex scripts that perform complex tasks. But as the scripts have gotten more complex, the results the render have diminished.

A boss I had as a teenager had a quote he said constantly that I learned was very true: "Laziness is always harder work in the long run." You're quite right about coders being lazy. But more accurately, the problem most of the time is that by exerting so much time and mental energy over complicating things at the beginning, there's little energy left to ever bring it together and finally arrive at a useful conclusion. And to be quite clear, this is a problem not directly focused on those creating scripts. It's a phenomenon reflected in the overall approach to how people seem to play the game nowadays.

What seems to be happening nowadays is that people play this game with complex tactics and simplistic strategies. After spending 1000 calories a day worth of brain power obsessing over how to get the absolute maximum out of the premium exchange, nobody can really be bothered with the broad strategic aspects of building your first village, efficient mass farming, adjusting your farming to the activity level you're able to plan for the day, building a defensible cluster, adjusting your overall plans for the kind of activity you're going to have over the next week or month, cultivating a tribe, etc. The strategic aspect of the game has been replaced with obsessing over whether you should farm 210 spears and scavenge 590, or farm 205 and scavenge 595 and repeat for three worlds so you and 20 co players can buy your way to victory.

But bringing this back to scripts, all the scripts I'm seeing reflect this misguided approach. They seem to be designed for players who are constantly going around the long way to get things done in the first place, and themselves go further around the long way, and it all just ends up being geometrically inefficient. For example, I was looking for a good backtime calculating script, but they don't seem to exist anymore. Once upon a time, you could run a backtime calculator script (one that didn't require being hosted and could be saved directly in your quickbar), and with a couple clicks and about three seconds total elapsed time you would have a list of what time to send attacks of various speeds from the village you had specified. Nowadays? The only things I could find now require you to manually input every last detail, and by the time it was done I had already figured it out the attack speed I needed in my head. And, of course, that script was probably the size of a small novel.

I would love to see some scripts that are as useful as the ones that used to be around. But everything I've found is more difficult to use than doing the job manually.
 

BabyBoomer

Member
Reaction score
1
Hi @BabyBoomer

Thank you for all the very helpful comments and advice. I and the majority of the others here feel like using a script loader is a much better way to distribute scripts and more importantly keep them updated. Regarding the script itself, I think you missed the point. You do not need to set the hour parameter or do any prior calculations, for the script to work, simply set it to 99999999999 if you don't want to bother with it. This parameter is only there to establish an upper bound on how much is the maximum time you want your troops to be away. If the optimal distribution of troops does not send them away for longer than this parameter, then the script will not care about this parameter, and simply optimize the distribution of troops such that you achieve maximum resources per hour. I sugest next time you go on a rant about this and that to better inform yourself.

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.
 

BabyBoomer

Member
Reaction score
1
Some of the most used scripts in the past:

Oh, you newbies are so cute when you think you're old school. By the way, resource balancing scripts suck. Mostly used by weaklings. The correct way to balance your resources is to farm, nuke people, defend, build new troops, and dump everything else into packets/coins. If you're good at it, you'll have relatively low need to move resources between your villages. Most of the time, I always found it easiest to just trade on the open market.
 
Last edited:
Top