Jump to content
  • Announcements

    • Fliegerfaust

      Malicious and Banned Links   10/09/2016

      Please be careful of downloading ANY LINKS that are not originating from a MyBot.Run URL or another trusted URL (such as apkmirror.com, bluestacks, memu, xda-developers, etc).   We have banned ALL telegram links and other verified malicious links we have come across already. Users attempting to do this or get around this ban will be banned permanently.   Please report ANY suspicious links to MyBot Staff or pm me directly
    • monkeyhunter

      MyBot.run V7.3.1 RELEASED!   11/03/2017

      MyBot.run continues the legacy again with release of V7.3.1!!   This release supports the May 22 SC game update & August 4th Graphic Update, and has some new features hidden inside as well   Get your copy in thread below!!   Click here to get to the release thread MyBot.run v7.3.1 Release

HArchH

Donator
  • Content count

    222
  • Avg. Content Per Day

    0.3
  • Joined

  • Last visited

Community Reputation

32 Great

1 Follower

About HArchH

Profile Information

  • Gender
    Male
  • Location
    United States

Clash of Clans

  • My Town Hall Level(s):
    Town Hall 11
  • My number of bots setup:
    11
  • Botting since:
    06/26/2015

Recent Profile Visitors

702 profile views
  1. v7.3 : Window z-order issue?

    Thanks @cosote. Something similar still happens in 7.3.1. Not sure if 7.3.1 included this fix or not. When my MEmu TH11 base is doing an attack it is impossible to keep on top of the overlapping MBR window to watch the attack. MBR seems to put itself on top time and time again during an attack. (All my other bases I run docked now. It's the one undocked based that gives me this trouble. Please let me know if you need any more information to reproduce this.) Regards, HArchH
  2. v7.3 : Window z-order issue?

    Hi @cosote, Is this the same as the fix for 7.3.1 that is called "Fix Android Window hide/show and manual repositioning"? Thanks!
  3. Docked Windows: Text entry on chat rings on every key? Is there some way that I can turn off the ringing noise (maybe you call it a bell?) when I type text into the chat field on a docked window? To reproduce: Enable your Windows sounds / speakers Run MBR with a MEmu window docked Pause MBR Open clan chat in the CoC window Type something in the white chat bar. Each time you press a character key the noise is generated. This is not new in v7.3. This has been the case for as long as I can remember running some bots in docked mode. Thanks!
  4. v7.3 : Window z-order issue? For docked MBRs there is no issue. Works as before. For my two undocked MBRs running with MEmu, usually when I click on the MEmu window the MBR window moves to the top. When I click on the MBR window the MEmu window moves to the top. Since I have the windows overlapping on my desktop this is a bit of a problem. I created a short video showing this issue and have it on my web site for your view. Click here. Thanks!
  5. Failed Eagle Detection Due to Hero Obscuring Hi @cosote. I write you because I think you've been working on improved Eagle detection. I reduced my two Eagle file tolerance in 7.5.2 from 89 to 88 and then to 87. It worked great for awhile. Then for some reason I've hit a bunch of bases where the Eagle detection fails and my LavaLoon attack gets trashed. In almost all cases the reason it fails is because a hero is close to the Eagle, and the Hero walks past the Eagle at the wrong time, and the Eagle bits are masked by the Hero's level and health bar. So my suggestion: If you are scanning a TH11 base and no Eagle is found, search for the Eagle a 2nd time. Since the Hero's move it is likely that if the Eagle was obscured the first time, the Hero will have moved and the Eagle will be clear the 2nd time. Of course, this assumes that the image scanning takes sufficiently long to give the hero time to move a square or two. I don't really know how long it takes to do the scan, so some delay might be required. Thanks! Update: Here is a link to an image of a missed Eagle where the AQ's health bar obscured what would have been an otherwise clear image location.
  6. Thanks for your time @ezeck0001. Note that I still have your 2-line patch in place. In 3 out of 3 trials donating loons to my baby bases DID WORK when I have the image file set to 89 (renamed to Ball_100_89.xml). Also, followed your suggestion to try donating something else, and I found that Giants did work without issue. Funny thing about loons, though, is that they have always worked just fine for bases that CAN take spells. Thanks!
  7. My applied patch code... ;patch sugggested by ezeck00001 to fix not donating to small bases. ;removed the 2nd and 3rd $aDonWinOffColors offset color location values. ;Local $aDonWinOffColors[3][3] = [[0xFFFFFF, 0, 1], [0xFFFFFF, 0, 31], [0xABABA8, 0, 32]] ;Local $aDonationWindow = _MultiPixelSearch(409, 0, 410, $g_iDEFAULT_HEIGHT, 1, 1, Hex(0xFFFFFF, 6), $aDonWinOffColors, 10) Local $aDonWinOffColors[1][3] = [[0xFFFFFF, 0, 2]];, [0xEBEBE9, 0, 208]] ; may 2017 update Local $aDonationWindow = _MultiPixelSearch(628, 0, 630, $g_iDEFAULT_HEIGHT, 1, 1, Hex(0xFFFFFF, 6), $aDonWinOffColors, 10) ; moved to new column to look for top white pixel of window
  8. Hi @ezeck0001, Thanks much. So the fix I am trying to to comment out 2 lines and replace them with the other 2 lines. I believe the rest of your note "which in turn sets the slot location in..." is just instructional. If you want to drop by my clan to do some debugging, I have an engineered clan with only one other human playing and about 8 bases that are too small to take spells. Just PM me and I'll send you or any of the other devs my clan ID. (Just don't tell the other human in the clan why you are there, please.) I'll report on my success with the 2 line change in a minute. The two line change didn't work for me, sadly. Log file around failed donate request. I posted another .PNG of the small donate window. Some folks have been trying to break into my HTTP server so I took my site down, but I put it back up just now.
  9. Thanks @Fliegerfaust. Thanks for looking into this. This problem happens every time for me. Every base will not donate if the requester is unable to request spells. All of my babies are TH3. And my TH8's, and TH11's can't donate to them. You can see a TH8 settings file here. You can see a TH11 settings file here. Following up on the idea that my config.ini file might be the cause, I took my TH8 config file and deleted it and let MBR create a new one. I set it to only donate "loons", put it in Halt Attack mode with Request/Donate Only option, and resumed. (But note that my TH11's that are in farming mode, not Halt Attck mode, still do not donate with the same symptioms.) It still does not donate to my TH8 base that is requesting Loons, but which does not have the ability to request spells. (yes, this is one of my mid-bases rather than a TH3 baby, but he suffers the same problem of not getting any donations filled because of this issue.) I'm using MBR 7.2.5. I use MEmu and I usually have 4 bases running.
  10. Hi @dutchy1985, Thanks for the support. Since both of your bases are asking for spells, I'm not sure your issue is the same as mine. The issue I've found is that if the requestor can not request spells, the Request Troops pop-up menu for the donator is shorter and I think that the ImgLoc() calls are looking in the wrong place for the donate troop slots. Thanks!
  11. No Donations if Requestor Doesn't Take Spells? I have several "baby bases". I feed them donate troops to help them farm. But it seems that if the request does not have a count of spells, that is, the base is too low a level to request spells, the donation is skipped. This is not a new problem with 7.2.5. It has been the way for a few versions. Just with moving to 7.2.5 and still seeing this issue I thought I should report it. Please see this screen shot. It shows 2 requests. Two Requests...one with spells one without spells. The request for 0/20 was not donated to. The request for 20/35 was donated to. Both matched loons. Here are the relevant log file rows. You can see that in the 0/20 (fail) case it sees the 0/20 and it matches a keyword, "loon". But it just ignores the request. It also showed just after that the base has 34 loons available to donate. I see in my profile that I have no spells selected to be donated. I have "Donate Balloons" checked, but not "Donate to All". As I test I changed the donating base to have EQ and Poison set to be donated. But it did not make a difference. The loon donation was still recognized, but not made. I have Donate enabled (of course) and I do not have the "Only during these hours..." checked. (Of course this is not the issue because it did make the donation on the 20/35 request.) I am not using any donate filters, but I am collecting images. I started looking at DonateCC.au3 but is is a very dense piece of code. I couldn't provide any useful information from looking at the code. So I turned on debug and got this more detailed log for the Fail case (I deleted all the Android Suspend / Resume lines): The loons are the only troop available to donate, and are in the top left slot (slot zero?). Not sure why SearchImgloc is returning "gueued" for that slot. Slot 1 and Slot 6 really are empty. I have another base that also won't donate to this failed request, and it has loons in slot 1 (2nd from the left). Thanks. Please let me know if other information would be helpful. >>>>>>> Update: Oh.... I suspect that when the requestor cannot request spells the ImgLoc is looking in the wrong place for slot 0. Since the Donate Troops box is much taller when the requestor can request troops. Here is an image with the short donate window and the loons in slot zero.
  12. I would like to bring this suggestion back up for consideration. At legends level being able to decide to to attack on a risk/reward basis would be very useful. Thanks!
  13. Bot "false attacked" instead of doing something else? I looked a my attack log and see that MBR did an attack some 12 hours ago where it dropped 1 Wall Breaker then did nothing else. The attack ended after 30 seconds, and I lost about 35 cups. Here's a short snip of the log file. I found the right spot by matching the loot reports on the base that was hit in error with my logs. See the two marked search reports for the same base? My guess, and it's nothing more than a guess, is that MBR missed a click and hit the Wall Breaker troop and starting attacking on search 2, instead of going to the next search? Breakers are the left-most troop in the list, opposite the end for the Next Search button. Then it saw the same base displayed on search 3, but there was no "next search" button, it decided it was out of sync and finally pressed the Surrender button and saw the end of the attack screen. Though it didn't record the battle in the MBR attack log. So MBR didn't know that it did the attack, but press the Breaker troop button by mistake. Note that I use a scripted attack, and it didn't (as you can see) do any of the script processing. Any suggestions? I've seen this before and had turned off the "Random Click" check box on the Bot / Options screen. Thanks! I had a thought on what might have causes this.... As you know when staring at clouds every few minutes MBR will open the side bar, as if looking at clan chat, then close it. I wonder if CoC presented a search result and MBR tried to open the side bar at about the same time causing the errant click? The wall breaker was dropped on the bottom left...about 1/2 of the distance between the the left-most corner and the center of the bottom-left side. There is a 2016 Christmas Tree there where the breaker appeared. If there a log entry made when the chat bar is opened?
×