Secret

Do you use a proxy when botting? If so, did you use a browser that enables you to set a proxy to ensure you didn't sign into the osrs forums a world away from the location of your proxy? That's about the only thing I can think would have triggered a lock. If they've denied your appeal to unlock the account, not much can be done. You just have to wait and start a new account in the meantime.

I'm not entirely sure where all this can pop up / disrupt scripts, but the interface seems to appear under unknown circumstances on tutorial island. I've attached a screenshot as well. The interface root id: 162 Right now if it comes up, the ChatScreen class doesn't recognize it as an interface to handle. I think just adding the interface id to the "CLICK_CONTINUE_WINDOWS" list should fix this. It's not a priority fix by any means. It makes sense for tutorial island where chat is blocked, but outside of that I can't imagine where it would be an issue. Recreate: The only way I can seem to consistently recreate this is to focus the name field, and press enter while the field is blank. Then you just wait, and it should pop up after some time. Other than that, I've had it randomly pop up as I'm standing around on tutorial island in random places. Any questions, let me know!

The friends I've had who have had successful appeals for hijacking are the ones who mostly play legit on the IP it was created. They will do an extended period of botting if they go on vacation or something from a proxy, and if it gets banned in that small timeframe, they can sometimes get those appeals to go through. I believe they haven't had a single hijack appeal go through on accounts that had a pin set. Which logically makes sense to me. Who is going to hack your account, and conveniently just know your pin and bot the hell out of it? xD Speculation aside, nobody knows the process Jagex has in place for appeals. If it's a system based deny, then the system had enough evidence based on whatever factors they use that it was confident you were botting. If it's manual review based deny, maybe the J-Mod spilled coffee on his keyboard that day and was in a bad mood? You've done what you can by creating the appeal. Not sure there is anything else you can do.

I just wanted to add a couple more things. This doesn't seem to happen if the botting client isn't minimized but is behind other windows. The only scenarios I can recreate this consistently are the ones I mentioned in the main post. Also I do believe this can affect scripts depending on how they coded the mouse interactions. I haven't fully tested this yet, but I think this can cause mis-clicks in scripts that are using .click() instead of .interact("action") when this slowdown happens.

I know this has been mentioned in the discord, but it didn't have a bug report created. I've also been hitting it more, particularly when trying to figure out ways to separate the bots from my normal setup. I'm running Windows 10 upgraded to Windows 11 (unsure if a direct Windows 11 install makes a difference, figured it was worth noting). When I asked about it in Discord, it was mentioned that it was seemingly happening more in Windows 11. I can recreate this issue without fail on my desktop, as well as a laptop running Windows 11. I've found a couple ways to do this so far: minimize the client, and wait a small chunk of time (10-30 seconds). When you maximize it, there is a good chance it will very briefly still be in the 'slow' mode until the virtual mouse starts working properly again. Put the bot client on a virtual desktop and swap away from that desktop. Wait a small chunk of time (10-30 seconds), and switch back. There is a good chance it will very briefly still be in the 'slow' mode until the virtual mouse starts working properly again. Shit quality, but I just used this Microsoft bs to throw out an example quickly: https://clipchamp.com/watch/kHwhP4I1kPF The video is using the second method above. I left the recorder and the client both maximized in the virtual desktop so it could keep recording, and it recorded the behavior. When you see the mouse movement snap back to the 'fast' pace, it's when I switched back to the virtual desktop. When it gets REALLY sluggish again, that's when I've switched out to another V desktop. If it really is a Windows 11 issue, I know they changed a bit of how background processes are handled, so I figured it was a priority issue with the Tribot thread. I've tried setting the Threads to high priority from task manager, which doesn't fix the issue. If the virtual mouse is on its own thread, it could still be a priority issue as I believe threads are created with the same level of priority as the thread that created it. I couldn't find a way to get Tribot to launch the bot client with a high priority, so the mouse thread would always just be normal. Probably not the issue, but it was a thought that came to mind. Edit: I'm testing changes for my local script right now, but this happens in other scripts as well. I use Dentist AIO, and can recreate it with that script too. So I don't think it's a script issue.

Congrats you guys! Encoded always helped keep the client moving in the right direction years ago, so it's great to see him helping out again. Glad to see Nick up here too, maybe we can get a repeatUntil with a lower sleep now? 😉 congrats again guys, no doubt you'll both make more great contributions. 🙂

Gotcha, no worries. It's not a big deal. 🙂

Here is a screenshot of the unhandled login message, and the Client Debug: [03:40:21] Starting client. [03:40:45] Randoms Thread disabled for this script [03:40:45] Script Started: Secrets script. I copied the Bot Debug to it's own document because it's around 1100 lines of the unhandled message. What are the requirements to submit pull requests for this type of thing? If they aren't too steep, I could look at submitting one for this to save you some time. Bot Debug.txt

I am randomly getting this login message while running a bot on World 1. I can't find a way to reproduce this, it just seems to happen randomly. I imagine it's when a jagex world is getting a large amount of sign in requests, this is what is pushed to clients. That is just speculation though. When it does happen, the bot debug just repeats the message below. The first timestamp is the top of the log, and the last timestamp is the bottom. There are 1046 debug lines with only this message in-between those two timestamps. [21:42:23] Un-handled login message: This world is already busy. Please use a different world. [21:48:21] Un-handled login message: This world is already busy. Please use a different world. I think adding this to the LoginMessage enum should fix the error preventing the login handler from working in this scenario. I've already fixed the occurrence this time, but I'll grab a screenshot next time it happens.

I decided to put this together over the course of a couple hours one afternoon to alleviate the pain of manually checking proxies before using them to ensure that they were not already blocked by Jagex. I'm not a Python person, so it probably won't contain project conventions that you would typically see in such a project. This tool will validate the list of proxies that you provide, and generate two files with the results. One file is a csv containing all of the valid proxies in the list provided, formatted to be imported directly into Tribot. The other file is a report type analysis file, letting you know which proxies were valid and which proxies were blocked by Jagex. Right now it only validates authenticated proxies, and only supports reading one proxy string format. It's saved me a ton of time when rotating large numbers of proxies. Every rotation I export the proxies from the site, copy them into the proxies file, run the program and I know immediately which ones are the dead proxies to avoid. I figured it might be handy for anyone else looking to validate a large number of proxies against Jagex servers in a short period of time. The GitHub contains a README explaining how to setup / run the program with some other information. Let me know if there is anything unclear, and I'll help out where I can. https://github.com/SecretScripting/proxy-validator

Yeah, I suppose that's what I meant when I mentioned 'identifying' each other. If your instance connects to something on a port, send a message that only an instance of itself would know how to respond to. If it gets the correct response back, it indicates there is an instance running. I think the easier solution is to pick a port not typically used by anything though. Like you said, chances of collision are pretty low.

This is really cool, and seems like a pretty simple way to lock down your application. Could you eliminate the listed flaw by giving your application a method of identifying each other, allowing you to 'scan' a range of ports and using the first available if you haven't found another instance in port range?

Haha I think you're probably explaining things okay. I'm just asking questions to make sure we are both on the same page here. This is also just a good opportunity to interface with the community a bit, and get a better understanding of something we all enjoy. So I included all of the code above, but I only actually ran one set at a time. I ran one test using only the SingleThreadExecutor hitting the executor.execute as often as the conditional would allow, and one test creating a new thread as often as the conditional would allow. While one test was running, I commented the code out for the other. That said, I would expect that only the test that is creating/disposing of new threads would be the one filled with garbage as seen in the logs. Which is why I got confused when I saw the memory prints looking really similar when I ran the SingleThreadExecutor test, which shouldn't be creating/disposing of a bunch of threads.

I thought ExecutorServices got rid of the cumulative overhead of creating / destroying threads by returning them to a pool? In the test without the ExecutorService, ~ 125k threads were created, which is a ton of memory in the 9 seconds it ran. I don't know what resources it takes to keep the single thread alive in the pool, so maybe in this instance it just balanced each other out? While the overhead of a single thread isn't large, I expected the overall memory dumps to the log to be quite a bit better on the test using the ExecutorService due to my understanding of them. The logging wasn't overly verbose, but the behavior of both tests (available memory / used memory / GC runs) looked like they were almost identical for each step.

It wasn't that it looked like it was using less memory, more so that it looked like both were producing nearly identical results. I know I wasn't using the SingleThreadExecutor in a way that would make it 'shine', but I did expect it have a little less overhead in the memory department than what I saw in the prints. That is why I started looking into them for this in the first place. It seems that the SingleThreadExecutor shines better in and environment where I can queue up tasks without caring about when the currently executing task is finished and if the queued tasks were still valid. I opted for the quick n dirty to get some quick numbers to give me some approximate data to make a decision on. Then I thought maybe I did something wrong when I saw it haha.