APB Ultimate

[qmancan]

APBU is not retired for sure. I'm having some really hard issues to sort our with working 3 underpayed jobs. APBU was working good enough so it didn't take much of my attention.

The way I've made APBU, you can add any future profession yourself by just making the proper xml. I doesn't need any code whatsoever. This was part of the original design. APBU will parse any additional xml files present in the directory.

That said, I have found some time this week so update is coming. Possibly today

Welcome back! Would love to see the extra assets working Purely selfish reasons of course... have a few accounts I am working leadership on and would love the speed boost ;p

[Spaznetz]

APBU is not retired for sure. I'm having some really hard issues to sort our with working 3 underpayed jobs. APBU was working good enough so it didn't take much of my attention.

The way I've made APBU, you can add any future profession yourself by just making the proper xml. I doesn't need any code whatsoever. This was part of the original design. APBU will parse any additional xml files present in the directory.

That said, I have found some time this week so update is coming. Possibly today

Speaking for myself, I appreciate all the work you have already put into it. Thank you!

That said, I am anxiously awaiting any/every update

[Darxide23]

That said, I have found some time this week so update is coming. Possibly today

I had to check my calendar to make sure it wasn't Christmas already.

[Spaznetz]

After the latest round of Gateway problems, I cannot get APBU to get past Character Select screen.

I can access Gateway via Firefox and Chrome without issue, but APBU fails every time with a timeout error.

Is there a file I can delete so that APBU will have to re-verify my access? (Like it always does with my browsers since I disallow history/cookies on both)

Alternately, is there a way to clear the cache on APBU? I am seeing some people are having issues that go away after clearing browser cache.

I deleted the contents of the Cache directory as well as the Cookie.jar file. Still did not work.

As I went through testing with other browsers (Firefox/Chrome) I noticed that the first connection after verifying was slow but ran okay after.

So I went back through APBU and manually clicked into each character and made sure I could access menus before trying to restart it on auto-pilot.

Now everything works again.

Well, at least until "maintenance" breaks something else

[RottenMind]

It seems work now as before (APBI, Greasemonkey) so all was in gateway, cache clearing helped but not solved problem.

[electropica]

Is there someone that have route to up alchemy to 1 to 20 ?

[BaseN]

0.4.1b:
--Optional assets.
--BlackIce refining
--Refining of experimental network dying detection feature
--Fixed issue with characters with 9 slots (9th slot not working right) that was present in the 0.4.0 internal version.

[electropica]

He is alive !
Thank you for the update.

[IncarnateOfBhaal]

0.4.1b:.

I found a couple of bugs; I haven't used APB Ultimate before so I don't if they are new to his version or not.

Running First Possible, the first task is triggered twice:

09:55:02: Checking slot 6.
09:55:14: Slot 6 is Free. Starting new task. -> Start First Task
09:55:34: Adding task timed out. Slot is still Free. Retrying! -> Start First Task
09:55:54: Adding task timed out. Slot is in First Possible Mode, switching to next task. -> Start Second Task
09:56:04: New task started.

Not all Optional Assets are always used for tasks. I think this occurs when the same asset type is used multiple times in a row, but I'll keep testing.
For example this will work:

    <slot6>
        <mode>2</mode>
        <task>
            <prof>Leatherworking</prof>
            <name>Elegant Leather Pants</name>
            <internal>Leatherworking_Tier3_Leather_Pants_Special</internal>
            <level>19</level>
            <repeat>1</repeat>
            <optional0>Mithral Awl</optional0>
            <optional1>Mithral Shears</optional1>
            <optional2>Mithral Awl</optional2>
        </task>
    </slot6>

But this will cause only one awl to be used:

    <slot6>
        <mode>2</mode>
        <task>
            <prof>Leatherworking</prof>
            <name>Elegant Leather Pants</name>
            <internal>Leatherworking_Tier3_Leather_Pants_Special</internal>
            <level>19</level>
            <repeat>1</repeat>
            <optional0>Mithral Awl</optional0>
            <optional1>Mithral Awl</optional1>
            <optional2>Mithral Shears</optional2>
        </task>
    </slot6>

[Darxide23]

Running First Possible, the first task is triggered twice:

By design, not a bug.

[Methuselas]

I found a couple of bugs; I haven't used APB Ultimate before so I don't if they are new to his version or not.

Running First Possible, the first task is triggered twice:

09:55:02: Checking slot 6.
09:55:14: Slot 6 is Free. Starting new task. -> Start First Task
09:55:34: Adding task timed out. Slot is still Free. Retrying! -> Start First Task
09:55:54: Adding task timed out. Slot is in First Possible Mode, switching to next task. -> Start Second Task
09:56:04: New task started.

This is by design. It will always run the check twice, to make sure it's not a gateway error.

Not all Optional Assets are always used for tasks. I think this occurs when the same asset type is used multiple times in a row, but I'll keep testing.
For example this will work:

    <slot6>
        <mode>2</mode>
        <task>
            <prof>Leatherworking</prof>
            <name>Elegant Leather Pants</name>
            <internal>Leatherworking_Tier3_Leather_Pants_Special</internal>
            <level>19</level>
            <repeat>1</repeat>
            <optional0>Mithral Awl</optional0>
            <optional1>Mithral Shears</optional1>
            <optional2>Mithral Awl</optional2>
        </task>
    </slot6>

But this will cause only one awl to be used:

    <slot6>
        <mode>2</mode>
        <task>
            <prof>Leatherworking</prof>
            <name>Elegant Leather Pants</name>
            <internal>Leatherworking_Tier3_Leather_Pants_Special</internal>
            <level>19</level>
            <repeat>1</repeat>
            <optional0>Mithral Awl</optional0>
            <optional1>Mithral Awl</optional1>
            <optional2>Mithral Shears</optional2>
        </task>
    </slot6>

I reported this with the beta. The work around I've found for using tools, not workers, is to not place the same types of tools in succession. In your example, do mithral awl, mithral shears and mithral awl. I haven't tested the new version using 4 tools and if it uses all the tools. I'll also test, via Alchemy, if using 4 types of the same tools causes the same problem.

One other thing of note, Base. I reported this previously, but if you do a job that allows multiple worker assets, such as Deep Wilderness Gathering, if you only have a single worker queued for the job, the bot will time out on the job. If you do a Deep Wilderness Gathering or Refining job that allows multiple worker assets WITH 2 or more workers, the task will be done. It's only if you set it to use one worker, will it time out. I'm gonna have to swap around my workers, but I'll start doing thorough bug testing in a few days.

[IncarnateOfBhaal]

This is by design. It will always run the check twice, to make sure it's not a gateway error.

I reported this with the beta. The work around I've found for using tools, not workers, is to not place the same types of tools in succession. In your example, do mithral awl, mithral shears and mithral awl. I haven't tested the new version using 4 tools and if it uses all the tools. I'll also test, via Alchemy, if using 4 types of the same tools causes the same problem.

One other thing of note, Base. I reported this previously, but if you do a job that allows multiple worker assets, such as Deep Wilderness Gathering, if you only have a single worker queued for the job, the bot will time out on the job. If you do a Deep Wilderness Gathering or Refining job that allows multiple worker assets WITH 2 or more workers, the task will be done. It's only if you set it to use one worker, will it time out. I'm gonna have to swap around my workers, but I'll start doing thorough bug testing in a few days.

Ahh, its a feature All kidding aside, I just wanted to thank BaseN for the app and the community members like Meth and Darxide that have been supporting it.

@Meth, maybe could you clarify further, as I haven't played with it enough to understand how the logic works. When running in first possible mode, does it attempt every task in the list twice, or only the first task in the list twice? I have a number of rare tasks listed in order of preference and trying to account for the expected number of failures so as not to relog prematurely. I have my relog counter set pretty low since I often have networks issues, so its just a matter of finding the right balance.

Edit: Do you also know when the failure counter is reset, is it after a success, per character, etc?

Regarding assets of the same type, I am doing that where possible, such as is my example, but that's not always an option. For instance I only have Iron Engravers for black ice refining. Are there any other workarounds you are aware of?

Thanks again folks, I appreciate the effort everyone is putting in here!

[Methuselas]

Ahh, its a feature All kidding aside, I just wanted to thank BaseN for the app and the community members like Meth and Darxide that have been supporting it.

@Meth, maybe could you clarify further, as I haven't played with it enough to understand how the logic works. When running in first possible mode, does it attempt every task in the list twice, or only the first task in the list twice? I have a number of rare tasks listed in order of preference and trying to account for the expected number of failures so as not to relog prematurely. I have my relog counter set pretty low since I often have networks issues, so its just a matter of finding the right balance.

What the bot does, is it checks to see if it can do a job, first. If it fails, it checks it a second time, just to make sure that it's not a gateway error. If it fails a second time, it moves on to the next task. So, if you have a bunch of rare jobs to cycle through, you're going to need to set your Max Timeouts to at least twice the number of jobs you have in the queue. (This is the major problem with setting an Alchemy queue to people can breeze through Alchemy, which, provided you have all the source materials and purple workers, is the fastest profession to level to 20. I've done it in 3 days!)

Edit: Do you also know when the failure counter is reset, is it after a success, per character, etc?

BaseN can actually answer this question, for sure, but based on my experiences, the counter continues to tick, til the restart of the loop, but don't quote me on that. I base this off of trying to set a job slot to cycle through 5 levels of Alchemy. Even at 15 Max Timeouts, it would still sometimes timeout, without getting to the next available task. Granted, this was with the 4.0 alpha, but 4.1beta seems a bit more stable with that. I have been swapping my workers around to get all my toons level 20 in all professions, so I'm going to have to wait a bit, before I can start trying to break APBU.

Regarding assets of the same type, I am doing that where possible, such as is my example, but that's not always an option. For instance I only have Iron Engravers for black ice refining. Are there any other workarounds you are aware of?

Thanks again folks, I appreciate the effort everyone is putting in here!

Okay, regarding using multiple workers on jobs. The *BEST* fix I've found for making sure I don't have timeout errors is to make sure I use at least TWO workers, period. Doesn't matter what kind. For example, each of my toons has 8 heroes. The first 6 are used in the first 3 slots, for Destroy Enemy Camp. The last two are used in slots 4 and 5 for either Protect Diamond Shipment or Fight Off Spellplague. The bot will continuously timeout if I only use the heroes, so I tack on an additional footman to each, so it never fails. If you do ANY job that has an optional slot for a worker or tool, the bot WILL timeout, 'cos it will try and load an optional asset, even if you don't use it.

Finally, on slot 9, to keep the bot moving to each toon, set that to do a gather job, which only uses a single asset, like gather high quality ore. Since it only has one slot available, the bot can't time out and moves to the next toon.

I've been doing it this way, for about a month now and it's the only way to keep the bots running "smoothly." I still get the network connection drops, the gateway drops and the memory leak crash, but not nearly as much now, with the 4.1 beta.

Hope that helps.

[IncarnateOfBhaal]

Hope that helps.

Excellent, thanks for all the info!

[BaseN]

Edit: Do you also know when the failure counter is reset, is it after a success, per character, etc?

There are several integer variables at play:

a) There's a global timeout variable (globalTimeout) that is being reset before trying to add a task and is incremented after failing to add it in the function responsible for starting a task. This is compared to the timeout setting value in the main loop logic.

b) There is a variable that is incremented when a navigation action times out (i). This is used in a for loop with conditional comparison to the timeout value option. So it resets when the action succeeds or when logic moves to next slot.

c) The above variable is also used for when a start task action has failed (it's part of the same logic loop) but in the logic it's used along with a boolean variable flag that controls if the adding of the task succeeded or not. If boolean is false add task action will be retried until globalTimeout reaches timeout setting. Why it's done this way will be explained below.

d) There's one more variable (timeout) that is being used in while loops that wait for boolean functions to return if a string was found or not after a specified amount of iterations controlled by the internal timeout setting or after some events fire (has to do with the actual page we're loading and how the gateway is manipulating DOM contents with JS/Ajax). This timeout value is again compared against the internal timeout setting and breaks the while loops if it's reached. This timeout variable is always reset prior to a new while loop.

This complecated logic is required because the mess that is javascript manipulated DOM/Ajax.

To further elaborate:
An action may fail due to these reasons:
1) Network conditions
2) Gateway issues
3) Javascript has not finished manipulating the DOM so the values we're looking for are still not there.

I need to handle all 3 cases as accurately as possible (because they require different handling) but 3 is the one that every method of handling it is hackish in nature because there are no reliable ways to know when the DOM is actually done. You can only know when a page has been downloaded but you can never really know when the DOM is done unless you employ some very hackish tricks that can sometimes fail (under certain conditions). Also speed of javascript DOM manipulation also depends on the web browser JS engine and the performance of the PC running it.

The above d) is what controls this. d) is what lets the logic know if the error COULD be a JS DOM manipulation timeout in which case it retries the action that causes the JS DOM manipulation until the internal timeout is reached. Adding a task is the part where it's more prone to this. So there are two timeouts related to adding a task (a and c). The boolean flag controls if the entire add task action should be retried as a whole because it has passed the JS DOM manipulation parts so it's something network, gateway or configuration(missing assets,wrong queue,etc) related. If the boolean flag is not set but the add task function returns this means that that any of the 1, 2 or 3 conditions may be true so it's being handled in a different way than knowing that only 1 or 2 can be true.

In the case of FP mode, the action is always retried once. This is to make sure (as much as possible without lots of retries) that it actually can't start the task before moving to the next. This single retry is not tied to any of the settings. It's a hardcoded retry and the variable that controls it is always reset after each task in queue has been tried and it is tied to the taskFailed boolean. What can complicate this is when add task fails without the boolean set to failed. In this case a timeout value is actually being increased and is global to the slot queue because if it wasn't FP mode would get into an infinite loop. This has nothing to do with the singular retry per task though. If the strings expected to be read can not be read at all, then it means for certain that something else is wrong and it's certainly not because you don't have assets to start the task. In that case FP mode should fail and it does. This is why it may seem like FP retries are causing a relogging timeout. If a relogging is triggered it means some of those FP retries did not actually fail because of assets but because the expected strings were not found in the DOM.

This is why increasing the internal timeout setting helps people with bad network conditions or slow PCs as it causes those internal functions that wait for a string in the DOM to wait longer and retry more times. The plain timeout option helps with the occasional network hiccup and gateway issue.

I hope that explains it...

Btw, Methusalas, can you PM me a list of those issues? on 0.4.0? As I have a lot of PMs from you and it would take some time to compile them into a buglist I could work with. A singular PM with a list would help me a lot as it would be more time spent debugging than compiling lists