FratbroWilliam

I believe there have been some solutions created for having OSBot send updates out to a discord server; hooking a bot into a chat channel and having it distribute the chat log to accounts and parroting off roles mimicking a private chat stream would be even more difficult to detect, in theory. I don't think that the entirety of the internet is being scanned by any means. However, movie scripts and/or song lyrics might get noticed if a human is reviewing things; random threads are a crapshoot; private chat logs would be a minute risk vector.

Using a debian based installation. Saw a random.dat file propagate after using runelite, removed it. Have been using osbot as my client on this PC exclusively thereafter, there is no random.dat being created Within $HOME I can find a [33char].dat file which appears to only be hexadecimal characters in the name, but is an odd number of chars; and jagex_cl_oldschool_LIVE.dat From home i can navigate down jagexcache/oldscool/LIVE/ and therein are 28 files (2 of which are preference.dat files) Am I missing something here? Does the osbot client not generate a random.dat file? Moreover, will that, in and of itself, be flagged as suspicious?

Yeah, it kinda seemed like overkill; especially seeing the countless accounts which clearly are bots that just don't get banned. Bias and anecdotal evidence are fine, it's all that I have for the time being. I think my plan going forward is to use my test-account as is and try to not run money-makers on it extensively outside whatever it would need to fund itself anyway. Try to have it just masquerade as a typical "working-class" player. Hearing that a testAccount survived being afk in place for over 6hrs is pretty funny honestly.

Still fairly new here, hoping this is the correct board. Haven't been botting too aggressively on my development account. However, at this point more of my Total Experience on that account is botted than not. Recently I have noticed talk of a miniNuke coming down and am feeling more confident after seeing my scripts, which I feel are relatively slipshod, not result in an immediate ban-hammer. Not up to a significant enough scale for RWT, it's quite possible that my account is flagged but was ignored this round; purely speculation of course, but it would make a lot of sense to allow an evolving bot to be observed to make it easier to use heuristics to begin fingerprinting various iterations of a script... I might switch to using a new account to test each new iteration of all of my scripts and avoid overlapping- but I am probably overthinking it, right?

Never introduced myself, so hello! I started programming around a decade ago and have been interested in automating games for just as long. Currently work in OpSec and am primarily here for the hobby, a way to exercise my development skills and reminisce in some nostalgia. Looking forward to interacting with the community, y'all seem pretty chill thus far.

Mmm, that would be one way of doing it, thank you! Additionally, something fruitful in the API (specifically regarding waiting until the next gameTick) might be: gameTick = Client.getCurrentTick(); then conditional sleep until (gameTick < Client.getCurrentTick()) and could be adjustable for any number of ticks to have passed, i think; going to play around with it more after work. Idk what margin of error clientTicks can stray from the server itself yet, probably going to need to offset by ping to account for latency as well as do something to account for Processing related variance (frame drops, for any reason not directly related to the Network)

# Looping too Soon -- probably common sense Running a ConditionalSleep until the Player is idle. (ie. not moving AND not animating) Logical flow should be: loop(){ takeAction() waitForIdle() } I noticed that the player seemed to be repeatedly clicking to takeAction() rather than actually waiting until the Action stopped, and thus they were idle, before again taking action. It seemed to happen more frequently when the player had only just arrived at the destination area where the action was to take place. Threw in some appropriate log() lines to help measure time between actions and began tweaking my conditionalSleeps. Discover that conditional sleep tests execute *immediately* and then sleep until true, rather than sleeping once before checking; the script was simply executing faster than the player could begin to takeAction. So I modified the loop. loop(){ takeAction() sleep(someTime) waitForIdle() } By adding a short sleep before testing for idle I greatly reduced the amount of excessive clicking which was occurring, however it leaves something to be desired and I am going to be building around it for a bit. I can theorize a few ways to manually go about getting a script in sync with the game's tick-cycle, however I feel like there's likely something simple in the API which I am overlooking. sleep(600); // ie. sleep for a gameTick, thus you are within the next gameTick (or however many tick you need) when you have started your action Sleeping until the next game tick should be sufficient in most cases, especially low-risk ones; but knowledge is power so I will update as I learn more. As a stickler I'd prefer for my conditionalSleep to start being tested ASAP (after the player has actually begun their action), The next tick starts 1 to 600 ms from <now> and I'd prefer to know as precisely as possible, my theories for manual measurement would suffer in high-latency situations; guess it's time to read a lot of documentation.