I'm pretty sure the "is interface open" logic is broken within the bot.
I'm writing some more bots today, I will try and verify and pass the information on to Klik.
Able to add a variable delay? Like instead of the usual "flat" delay, maybe a range of delay? Example, delay:100ms to 8000ms (randomly pick a delay between the range). I think this would allow for a safer bot to be scripted which is tasked to do very repetitive task like say wood cutting. Logically, no one would pay 100% attention on RS and immediately or after a relatively similar delay, click on the next tree
So maybe 2 request if possible? The second is an upgrade to the first and I'll explain why.
1. Random delay from chosen range.
2. Allow to set Min, Average and Max delay.
The average will allow for more realistic randomisation of delay, but why?
Logically if I'm afk tasking, I'd still try to respond asap, maybe usually within 1 second after the last action, but there are times when i totally forgot and left it afk for 3mins OCCASIONALLY. (Refer to eat logic on alpha fighter, just that instead of health, it's delay here.)
Hopefully this is possible!
Without looking at Trello, I believe this is on the TODO list. I have suggested this before, but it's also not the most critical update to the bot right now. Klik will add more features like this as the bot becomes more stable.
See the only reason i have the key press and the delay is the interact with interface wasnt working for me. It would find the lectern and click it then if the key press wasnt off the same action as the interact with object it would just cycle through. It was only when i added the key press to it that it actually worked but i ran into the problem of it not delaying.
And the way i learned if/else statments was like true/false
If condition a is true do this action
else if its false do a different action.
Where as the interact with object the key press and the delay should all be on the same condition something along then lines of a then statement
If condition A is true then move to condition A.1 then once that is true move to condition A.2.
Sent from my iPhone using Tapatalk
Everyone seems to be having an issue with the "Is Interface Open" logic in the bot. This is probably why you were having that issue.
You're mostly right when it comes to If/Else as True/False. However you're looking at it from a procedural point of view. The reason why you want one action per logic decision is because you want the bot to loop through your state logic over and over until it completes the task required and switches states. So if you have nested If/Else then the logic you're looking at is:
Is 1: True, 2: True, 3:True, 4:True, 5:false (Now we do the next single step to make step 5 true)
Then on the next cycle through your bot's state will look like this:
Is 1: True, 2: True, 3: True, 4: True, 5: True, 6: False (Now we do one more single step to make step 6 true)
So if the interface is not open, then the only action you want to take is opening the interface. Then when the bot cycles through the logic tree again, it reaches the next step which is to select what you want to make, or to hit the MAKE button on the interface. This gives you a robust bot that will always work, regardless of the initial conditions or human interaction present.
As your bot stands, if you interrupt the bot by clicking elsewhere on the screen, the bot cannot easily resume without performing unnecessary actions. It also cannot tell if you are already in the middle of a process "IE opening the interface and hitting MAKE" if you string the actions together. So the bot has potential to bug out and do something strange, such as repeatedly trying to click the Lectern because it doesn't know the interface is open and currently blocking the view of the Lectern. This bug might not be major, but in specific circumstances it could cause the entire bot to stop. It can also cause your bot to act extremely "bot-like" as humans wouldn't perform an action that wasn't required by anything other than ignorance or mistake. So if your bot clicks on the Lectern multiple times, resulting in the interface window being redrawn a few times, it's likely the Jagex anti-bot systems can pick up on that.
Procedural thinking doesn't work when coding Runescape bots. The game environment can change while your bot is attempting to perform the instructions it was given, so we have to code our bots to handle this variability in the game.
This is also the same guidelines given by Runemate executives on how to code bots for Runemate. If you want to discuss this with Runemate developers in real time, I suggest joining the Runemate Slack group and heading over to #Development. Whether or not you are writing the bot in Java/Kotlin or using a Build-Your-Own bot like Architect, the design requirements are identical.
(Just don't say you're a developer in #Developer if you only "code" Build-Your-Own bots)
