mfhelper failed to use portal

[leetzor]

Make Mausoleum runs, and when leader give tp in mausoleum helper stay in town, and than failed to use portal. How can fix it ? Same in pit rush.

[Bozzoo]

Same in a lot of area for me :'( . i use hammerdin and he take tp but bug and switch on vigor and stay motionless .

Edit : i tested to changed ALL delay in Mf helper folder from 1000 to 2000 and atm its ok (maybe zero impact im noob in prog)

Edit2 : In fact i think what is an problem of tp leader locations , specially in pit level and kurast temple . The follower seems miss the first try and retry , enter , but stay motionless

[DarkHorseDre]

Sorry to necro but I have the same issue and haven't seen a fix for it.

I commented the print("Failed to use portal"); lines to include the line number being executed, given the same error is expressed the same in multiple places. e.g. print("Failed to use portal.[216]");

The lines where I've seen failures are: 216 240 275

it does seem to relate to certain scripts, like Mausoleum, cave

my bot enters the tp from town and still says "failed to use..." then it stays there ignoring other commands. I usually use RELOAD to get it to awaken.

Act changes by leader awaken the bot and it attempts the next tp once a command is received. if I intervene and put the bot through tp quick enough, it sometimes starts to attack as it should.

I added delays of 3 seconds as Bozzoo did (give bot a chance to take tps, as it seems to try only once), it has improved things a little but still happens.

Any ideas?

DHD

[gogos-venge]

I was frustrated too by this problem, I took this one step further to debug. I added this at line 230: print("My area: " + me.area + ". Remote area: " + area); It seems the "area" variable isn't getting updated for some reason at line 221. Thus, I changed the if block at line 231: if (me.area === area) into this: if (me.area === player.area) and so far I had no problems. Can anyone confirm this?

[DarkHorseDre]

gogos - awesome! I haven't updated my post, but the bot is defo getting confused before and sometimes after tp, so your approach seems to make sense (nice debug text btw!)

I'm gonna implement what you have and monitor as I havent seen many responses on here recently and my mfhelper is just standing still most of the time!

One thing I see is the bot say it failed to use tp when it actually used it correctly to port - this may be one (of a few) causes to the out of sync area data

[DarkHorseDre]

Hey @gogos-venge do you think these lines: area = player.area; are the scripts attempt to re-sync the area with the players location? I'm wondering why they needed to do this, and if this is done to overcome an issue... and therefore if I need to check to see if we need more of these? (if your idea doesn't solve)

[DarkHorseDre]

@gogos-venge Bro i just saw bot run act 1,2,3 with no issues (with no new issues seen yet) -- seems we have a workaround!

Good work bro

I hope you run into the soso-tele-ontop-of-mobs-and-gets-ass-kicked issue next :)

[gogos-venge]

https://ibb.co/gi366K It's actually a bit complicated. When leader says clearlevel "bla bla", the "bla bla" part is not taken into consideration by the Helper. What it actually does is, holds the area when the Leader says the keyword clearlevel, and then tries to enter the portal in which the leader is located right now. The for loop can last up to 5 seconds if you look closely. During those 5 seconds the leader COULD've actually cleared the area mentioned before (held by area variable) and moved on to the next one. The area variable holds the correct value but unfortunately something happened (gambling? lag? selling stuff?) and Helper found itself in the new location of Leader instead of the old one (area). This must've been done in order to avoid leaving immunes behind by the leader (to be cleared after by the helpers) but introduces this bug. If the leader clears 99% of the area (like most hammerdins do) then it shouldn't be visited by the Helpers and they should just move on to the current one, hence player.area. At least that's what I can figure out.

[gogos-venge]

Indeed it's a workaround, the correct way should be like this: Leader enters area, opens portal and requests clearlevel. If he finished the area he should wait until helpers say "Done" or something similar and then move on to the next one. That would introduce a whole lot of problems tho. I assume the devs just felt leaving it like this to perfect other more important stuff.

[DarkHorseDre]

@gogos-venge yeah but I think that's a different issue! helper arriving after leader has left the area to town - sometimes already onto the next area or even act! It's most noticeable when the helper starts in another act (last act from previous run) then does housekeeping (it doesn't seem to do much on the fly or during runs) - so starts lagging behind leader.. then it walks to current tp as you say, but leader is already elsewhere. rakinishu + gris is a great example of one tp going up and boss killed within seconds of the 2nd in trist being setup (although bot manages that one quite well). I don't get this "failed to take tp" message with these as the bot usually exits and finds the leader and the new tp.

In my case, the issue is where the bot follows the command and the tp is correct, but it either does not enter, or mostly, it enters but says it fails, so its stood in the pit, mausoleum or other area doing nothing after entering tp.

As it stands, I haven't had any errors in the runs since making the area syncs, whereas i was guaranteed to get the failure on every run on certain boss scripts.

[DarkHorseDre]

as for your suggestion - the game already sends hidden commands (like change act) which the follower follows without problems. I think the leader should issue commands AND wait.. if timeout, continue. if helper crashes or pings out/d/c then continue. I think it could work without slowing down too much. I'd rather slow down than leader killing solo but with increased difficulty!

one thing this bot doesn't seem to account for is trying to get all players in same vicinity so we reduce the no drop chance. mf is all well and good, but no drop (for rune hunting) is important too! only way to improve it is to party up and be in the same area.. but if helper is elsewhere then...

[DarkHorseDre]

me and my big mouth - just saw it fail at rakkinishu.. it was trying to get back to town but stayed there. I put it through manually, then it tried to take the next tp - but it was now 2/3 failures in, so prolly 2/3 scripts behind.

The errors were fired from lines: 275 240 (x3)

[gogos-venge]

Yeah would expect that at a point. To get the bots to unstuck just place this under every print("Failed to use portal."); line. ------> Town.goToTown(); <------- This will at least reduce the chance to zero that your bots are stuck somewhere waiting for nothing.

[DarkHorseDre]

Thanks bro I thought of that but I swear it gets stuck in town too? uff.. I'll try it tho as he was outside town so it will at least reduce even further.

virtual beer for you sir :)

[DarkHorseDre]

Hey @gogos-venge , so I just peeped dude stuck in town in act 3 (travi run i think) - line ~275.. seems he was meant to go through tp to help..

[gogos-venge]

I'm thinking about a different approach where the Producer (MFLeader) must post something (kill, clear, clearlevel as well as the id) and the Consumer (MFHelper) must enqueue these data in a queue to serve when/if possible. So actually, these lads implemented a pseudo multi threading using events (since js is one threaded interpreter, sucks really hard) to read the chat messages of the leader concurrently and then let the main thread execute the last message. What I already implemented (and runs sweet), is exactly that; a Producer - Consumer approach for the clearlevel command.

In the Attacker.js I changed the line 736 into this:

say("clearlevel " + getArea().id);

In the MFHelper.js I changed lots of stuff. Basically it needs a new release maybe I can fork this if I feel like it.

Producer:

var areaQueue = [];

function ChatEvent(name, msg) {
    if (!player) {
        var i,
            match = ["kill", "clearlevel", "clear", "quit", "cows", "council"];

        if (msg) {
            for (i = 0; i < match.length; i += 1) {
                if (msg.match(match[i])) {
                    player = this.findPlayer(name);

                    break;
                }
            }
        }
    }

    if (player && name === player.name) {
        if(msg.match("clearlevel")){
            var tmpArea = msg.split(" ")[1]; //get the area id
            areaQueue.push(tmpArea);

        }

        command = msg;
    }
}

Consumer (inside while of MainLoop, mine starts at 187 line):

if(areaQueue.length > 0){

    area = parseInt(areaQueue.shift(), 10);
    print("My area: " + me.area + ". Requested area: " + area);

    for (i = 0; i < 3; i += 1) {
        if (Pather.usePortal(area, player.name)) {
            break;
        }

        delay(1000);
    }

    if(area === me.area){
        Precast.doPrecast(false);
        Attack.clearLevel(Config.ClearType);
        Precast.doPrecast(true);

        if (!Pather.usePortal(null, player.name)) {
            Town.goToTown();
        }

    } else {
        print("A portal to this area (" + area + ") could not be found");
        if (areaQueue.length <= 0){
            Town.goToTown();
        }
        continue;
    }

}

[DarkHorseDre]

Sweet @gogos-venge ! Whats the upshot of this? no more failing to take tps? I guess my issue is I don't know why they aren't taking the tps - looks like a clicking/movement issue when I observe, as they react to the command and move, but often fail to take tp without retrying.. I don't have an issue with the looping or missing commands: if the leecher turns up late they just say "unit not found" and go back to town.

[gogos-venge]

The basic idea is this: Leader says Kill 125, then says clearlevel 12, then says clearlevel 16 The followers will keep a queue like this [kill->125, clearlevel->12, clearlevel->16] and try to accomplish the request. If the tp for the area is found, then they just enter and try to help, else they dequeue the request and continue to the next one. I want to be optimistic and say this will help the problem with theTPs and mf helpers. I will implement it, throw some tests and report here. But right now, blizz is hot, and I suspect they might do a ban wave, so I'm a bit off. Who knows? Don't wanna risk it tbh.

[DarkHorseDre]

ok so some message queuing in a mono interpreter - nice! Would be good to know if it helps or if its something else..

why do you think bnet is hot - people been banned recently?

[gogos-venge]

@DarkHorseDre yeah except the huge warning in the kolton git homepage, I've read in discord chann that some people got banned. (we've went off topic x'D)

[DarkHorseDre]

@gogos-venge lol every bot has that text - if its detectable, you gotta say!

haha ok back on topic - fix the bot for us mkay? xD

[CaryGao]

@gogos-venge Could you share the whole MFHelper.js file to us?

[wbeston]

Any news on this? Seems like its almost more effective to set MFhelper false and just let the bots step on each other in game

[DarkHorseDre]

@wbeston fyi: the workarounds we discussed in this thread work really well - I haven't seen a failure since implementing them. Here's my mfhelper.js with fixes added - search for "dhd" for changes (it also has a change to allow helper to stay to kill dia and baal) https://pastebin.com/hNT2rk9e

[keeilb]

What part in this fixed file has made it so Diablo Helper And Baal Helper no longer work as it use to ? Before followers entered first TP and stuck with the lead all through chaos and baals minions. Now the helpers only join chaos on seal bosses, then returs to town and does that for each seal boss and then join to help with diablo. As for baal, they only join when its time to kill baal

[myceliated]

First off I'd like to say, DEAR GOD this is a beautiful fix and thank you guys for all the work you do! I'm learning tons reading threads just like this one.

Now as for MFHelper during chaos and baal runs... Just as keeilb mentions,

What part in this fixed file has made it so Diablo Helper And Baal Helper no longer work as it use to ? Before followers entered first TP and stuck with the lead all through chaos and baals minions. Now the helpers only join chaos on seal bosses, then returs to town and does that for each seal boss and then join to help with diablo. As for baal, they only join when its time to kill baal

I looked at the Few Fixes #1022 and MFHelper #1851 and could not find the fix how to make the MFhelpers enter the first portal at chaos and baal after applying the fixes to mfhelper.js as mentioned above.

[myceliated]

I may have found the issue these lines were shut off line 177, 178, 179 if ([108, 131].indexOf(player.area) > -1) { //dhd break; // dhd } //dhd testing it now

[myceliated]

it did not work mfhelpers left the game soon after chaos run started, changing it back.

this is my mfhelper.js https://pastebin.com/6486EGqe

[DarkHorseDre]

I may have found the issue these lines were shut off line 177, 178, 179 if ([108, 131].indexOf(player.area) > -1) { //dhd break; // dhd } //dhd testing it now

that was specifically for reversing the termination of mfhelper.js when leader entered chaos and baal throne.

[myceliated]

I may have found the issue these lines were shut off line 177, 178, 179 if ([108, 131].indexOf(player.area) > -1) { //dhd break; // dhd } //dhd testing it now

that was specifically for reversing the termination of mfhelper.js when leader entered chaos and baal throne.

Shortly thereafter I realized that haha I guesss the mfhelpers are perm like that with the fix for now. Thats okay I guess, I have them all stomping over themselves now and turned off chaos and baal.

[DarkHorseDre]

lol Yeah I'm not sure of the status of all this - remember that the code should be downloaded from the new git home: https://github.com/blizzhackers/kolbot

as for commenting out those lines - the intended functionality was that mfhelper stops at dia so that diahelper/baalhelper etc can run as they should be more effective. IIRC mfhelper doesnt do much for you in those areas.

[myceliated]

lol Yeah I'm not sure of the status of all this - remember that the code should be downloaded from the new git home: https://github.com/blizzhackers/kolbot

as for commenting out those lines - the intended functionality was that mfhelper stops at dia so that diahelper/baalhelper etc can run as they should be more effective. IIRC mfhelper doesnt do much for you in those areas.

Yeah, but unfortunately the diahelper and baalhelper never kick on it seems.

It's GREAT for clearing areas for sure! Although, If anyone wants to run chaos and baal with mfhelper I do not suggest using this fix.

[DarkHorseDre]

they wont if you dont stop mfhelper when leader enters those areas ;) It's a choice bro. use it as intended or be prepared to mod!

pay attention to the detail - this thread is about failing to use tps - disabling mfhelper aims to solve a different problem. doing that causes the helpers to not run..