What do I mean when I say it cannot be enforced? I mean that while you know all of the previous validators have evaluated to false, you don't know if there are any further validators that would run after your current validator that would reduce ambiguity of the state even further. Action ordering can be inferred, but it cannot be enforced, which is very limiting to the author when you realize that each action is decided by a string of validated information, and not just by a single validator. The TaskBot also falls short when you consider action ordering. #Runemate switch between bots fullSo if I'm checking whether or not the inventory is full, I should not have to also check if it is not full too. If you have a boolean condition, by the nature of it, it only has two states. Because it can only perform an action when a validator is true, this simply throws away information. The issue with it though, is that it limits the author by forcing them to over validate situations. The TaskBot was a good attempt at solving the main issue of LoopingBots, that is, it forces the author to perform a single action per loop iteration. Also it just ends up being an implementation of the TreeBot without the nice wrapper and clarity the TreeBot platform provides. While this works, it's not very nice to think about and can be difficult to find exactly what action you are looking for. This means that data gathered should be as close to the action as possible, which can be implemented in a LoopingBot with a massive if/else if/else block as seen here in this loop function:Įxia-Mining-All-In-One/StandardMiner.java at master This will solve the issue to some extent, but you have to remember that even though the decision made by the computer is near instantaneous, it is only "near" and still takes time. Looking at this, you might be like "Fine, I'll just gather all of the information that I need every loop iteration, then make one action". This was all caused by outdated information, which could have been solved by querying for the state of the game before every input. So now your bot has more potential to misclick. (I don't think that NPC does move, but for the sake of example, assume he does). They may in fact find the NPC before clicking the potion, however when they finally get around to clicking the NPC, it's 300ms later and he has moved. To a human this will seem as if it is one or two actions, but from a bot standpoint, it is actually several:Ī novice programmer may try to perform this as one action. For example consider trying to decant potions, to do this, you might use your potion on the NPC. This may not seem like a problem at first, but what you need to consider is the volatile state of Runescape. The issue that many authors run into here, is they try to perform multiple actions during a single loop iteration. While is perfectly possible to implement a working bot on this platform, there is a conflict in how humans think and how the machine thinks. So if you've been debating converting but don't know where to start, or if you had no idea this was even a thing, sit down for a minute and read this, and hopefully by the end you will be ready and wanting to convert your Bots to this new powerful methodology. This thread is meant to not only inform, but also convince you to switch over your current bots to the new API. Hi guys, I looked around the forums but couldn't find any tutorials or even an explanation of the newish TreeBot class and seeing as I wrote it, I figured I might as well write up an explanation of the logic.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |