monkeyhunter

Problem is the contents of your army. Drop trophy is only configured to use of TIER ONE troops to minimize the wasted elixir when reducing trophy count. All high cost troops (such as balloons and any Dark Elixir troops) are considered too expensive to throw away reducing trophy counts. Add a few Barbarians, Archers, or Goblins (maybe even Giants? I forget) and it will drop trophy as desired.

Know problem, read this:

#1 - No, Does not exist. #2 - Current buildings that have been trained/tested by MBR staff has a finding accuracy of 70-90%. Need 99%+ find reliability to have minimal complaints from community. #3 - Adding more buildings that can be found is as easy as: - capture new building images for all levels of each building in all supported emulators, - review images for each level across the different emulators and either pick most common ones, or if very close can merge pixels into single common image (fastest) - Add your bmp images to "images" folder, and add code to use them. - Run code to test your new images for a few days/weeks across all emulators with different internal RAM settings to check for accuracy. - Any image not found reliably requires tweaking match percentage, changing/adding more images; then retest for a few more weeks. - release your new feature MOD #4 - Using the existing building find images is not without certain problems in your application. Specifically issues with consistent repeatable location for each find. Current find image is small group of pixels (maybe 8x8 on average, and with many different shapes and sizes) that can be anywhere with the overall image of the building. The offset between location of image tile trained and actual center of building is not available in current implementation. You would need to this offset to avoid issues placing buildings next to each other, or near edges. Single biggest challenge with building find is search speed. Searching for current list of weak base/CSV targets requires up to 90 seconds on resource limited dual core machine. Adding all buildings would double the number of buildings and likely be much longer to process. More than 1 trained building per level has exponential impact on search time. Mortar find has ~10 images now, and requires 30-40 seconds alone on slow machine. For fastest search speed would need to convert the bitmap images in proprietary MBR XML format. Even with XML images, would expect reliable all building find to require 3-5 minutes to run. AND without XML images, the search time will be 3-5x longer due program design/limitations. It is these reasons that something like this has not already been created in the 3 years since MBR started. Suggest you want to not use the MBR code base, and need to write the code in compiled language like C++ or C# to create a usable feature. This was attempted by another community user last year, and since they chose to charge users to use the program it never became very popular. Best Luck.

If you run one instance, there is not much gain tweaking OS things. With multiple instances, secret to improve bot performance is to reduce resources required by emulator as Android Virtual Machine is single largest drain on PC when running. Tricks for each emulator vary, and that information is found the emulator forum in threads specific for each emulator. There are also several threads on the "Processor/Thread Advanced" settings on the Bot Options tab that help balance how the bit uses resources when running multi-instance.

Only you can learn the actual number? Approximate or estimate can be calculated based on RAM: Need 2GB system RAM for Windows OS, and ~2GB RAM per instance (emulator RAM set to 512-840GB) and 256MB GPU RAM per instance to avoid lag. Your GPU should support 8 instances, but your system RAM will lag with more 5-6 instances running. Another key with max number of instances is available CPU resources. When CPU resource exceeds 90% used, emulators start to lag if try run additional instances. iTools emulator might let you use all GPU ram and have 8 instances running with minor lag? Top Limit is 10 instances for any PC due some OS limitations on heap space and how the MBR GUI is written.

telegram code is in notify.au3, but you will also have to edit the donate code to call and use the new notify code you write. Best Luck.

Been expecting these posts: The 2017 Windows 10 Creators Update is a MASSIVE OS update. 1- If you have ANY emulator (BlueStacks, Memu, Nox, etc) running when the update happens, it can damage your Android Emulator installation. >>Only solution is remove and re-install of emulator. 2- BS is special. It is a "dirty" program in how it hooks into OS to provide minimal lag. Even with BS not running during update process, because of OS file changes - BS can become "broken". BS compatibility with Creators Update has become so bad, that MS has added a BS compatibility warning and their support site has many posts about BS issues. MS claims only the most recent versions of BS (v2.5+) are compatible with Win10 Creators Update, but that is not 100% true. Key issue with older BS versions and the Creators Update is that MS has enabled HyperV support by default. IF HyperV is enabled, even early releases of v3 BS will have problems. Disabling HyperV is easy in control panel if you can find it. Google search will quickly provide links with instructions and pictures on how to "disable HyperV Windows 10". Best luck.

Then you might have found a BUG that needs to be reported to developers.

Hmm... SmartWait should automatically include hero heal time into total idle waiting time WHEN you enable wait for heroes on Search tab of each attack type?

@adeee Weak Base filter has always been unreliable. Average accuracy detecting different building types averages 70-95%. @trlopes was working on image find code improvements to improve reliability, but it is slow/painful work. Does not help that community likes to constantly complain about building find errors in bug report section, but NEVER posts any images of bases that cause errors. Without actual images where errors happen, no can be tested or improved. Anyone posting "Me too" posts in this thread should be ashamed for not helping with proper debug data and images ..... @Ariarnoko @scorer @goldenmaths @Ho Trong Hieu

Do you have TH snipe option(s) enabled as part of attack plans? TH snipe attacks use a partial army. To avoid training wrong troops, and then being forced to delete them and waste elixir returning from each attack, bot can not queue the next attack army with TH Snipe enabled. Believe this was a hidden feature of the training code revamp due December 2016 game update? I never use TH snipe as external TH are very rare due all game changes since that feature was first created.

hmm... What is "Smart Wait"? Smart wait is intended to help bot act more human, as it allows log off while waiting for troops - like human might do while playing normally. Smart Wait will not change the timing of forced personal breaks. It does not reduce number of attacks per day, only idle time spent running CoC app. If you desire to reduce number of hours bot farms resources in CoC per day, or number of attacks per day; need to use the "Attack Schedule" regardless of "Smart Wait" settings. Recommended Breaks? When Fair Play punishments started long ago; there were whispers by SC insiders that two of the many suspected bot like behavior patterns were number of hours online per day, and number of attacks per day. If someone exceeded "normal" app use, would raised red flag for human review of the account to confirm bot activity. The leaked red flag thresholds were 8-10+ hours/day attacking and/or 15-20+ attacks/day. Based on minimal number of ban reports by community it appears that users exceeding limits are only banned if someone reported your account for bot use, meaning SC wasn't actively seeking bot users exceeding these two limits. It also appears that actual threshold were bot users were banned was 12+ hours/day, and/or 25+ attacks per day. But with very limited data, this is purely a guess. Since SC can data mine more than these two parameters if alerted to bot use; suggest that the best recommendation for bot use time is better determined by avoiding ANYONE suspecting you use a bot at all. Goal being to reduce the chance a fluffy bunny vigilante (in your clan, or opposing war clan) is watching your base for signs of bot use, and reporting you for cheating? Bottom Line: SC can find most all bot users if they choose to spend money on server side data collection & mining. There is no "safe" recommendation = If you do not want to be banned, do not use bot.

Looking at debug data, you have a really strange series of events happening? Can see where code detects TH location, but all of the OCR captures for reading names are BLANK. These would only be blank if: - Capture location was wrong due problem with auto zoom out & centering, or - Issue with bot clicks reaching emulator, or extra clicks inside emulator before name is read; due overlapping window issue with emulator. Based on image posted above, can also see that debug data captures of your emulator window are shifted down. This would happen if there is an issue with size of your emulator window, or the zoom & center process is adding wrong offsets. My best guess is problem with zoom out & centering; assuming that nothing is overlapping the emulator window? There are many extra log files in the data posted, and I do no use Memu; so hard for me to trace problem down. BUT I can see logs where bot is having issues with zoom out and keeps trying to re-center and change zoom. What may be happening is you have an obstacle (tree, bush, trunk, etc) at one of corners that is hiding/interfering with objects used for auto zoom & center code? There have been some other posts claiming zoom out issues where obstacles may have also been issue. Clean you yard of obstacles and see if that fixes the issue? @cosote is wizard for village zoom & centering for clean yard still fails.

Already Exists? Code/images for finding drill location and level has been same since v5? Image search returns the level of the drill building found, then the code makes assumptions regarding amount of DE available based on DE information available. There are as many opinions on how to optimize drill zap as there different types of attack armies, and each has pro/con. This guide might help: