ilpersi / BHBot

A bot that automates a game called Bit Heroes
GNU General Public License v3.0
28 stars 32 forks source link

Make the bot use revive potions only on predefined slot(s) #89

Closed RenuzitV closed 5 years ago

RenuzitV commented 5 years ago

The current revive system always revives all characters that died, and in certain cases it could waste a lot of potions that wouldn't help the run at all, for instance running hard/heroic raids with the main character has very low ts/health compared to the team. It would help a lot if we can have a setting to only revive specific slots when checking for members to revive, and ignore the others.

A solution to this could be to add revivePositions x x x x x where x is 0 or 1 depends on whether or not the user wants the character in that position to be revived upon death.

Edit : since the current revive system also supports t/g and expeditions, we would need to separate revivePositions into revivePositionsRaids and revivePositions, or make the first and second slot be front and rear, then the rest will be other positions from left to right.

Fortigate commented 5 years ago

We have a mix of tankPriority and potionLimit to deal with this, I run priority on the tank for raid 7 and potionLimit of 3. This usually revives bait, tank and one dps worst case scenario, if it gets to that point the run is usually a defeat and it skips further revives.

RenuzitV commented 5 years ago

Problem is that tankPriority always uses 100% revive, which can be costly and not needed (ex : getting 1 shot from gorbon’s once per adventure attack), and that may have to be changed. I also thought of an idea to just use revivePotions x x x x x where x is the type of potion you want to use for that position, along with potionLimit. This group up tankPriority and tankPosition and might be easier to use than the current revive system we have now.

Fortigate commented 5 years ago

Yeah I can see that a system for activity and then position+potion type (E.G r 1 3 3 3 2; t 3 3 1; g 3 3 1; e 3 3 3) would be more flexible than the current system. The issue is that this would involve a pretty big rewrite of the current system.

I have some small test changes to try with the current system I'll see how much work it would be to change it while I'm doing that.

Fortigate commented 5 years ago

Closing this for now, changes to the autoRevive system are on my to-do list, but as the current system is functional it's low on my priority list.