mehorz

I agree. I think forums should do both, instant reply similar to a community instant messenger where everything is lumped into one category effectively, and normal forum posts that ideally are high quality and no fluff/junk posts. Like guides and troubleshooting works great on a forum platform. Just chatting makes sense to be done in more the social media platform. Long ago a lot of cheating sites had a "shout box" on the main forum listing that helped to bridge the usage patterns to cover both. It wasn't perfect but it did alright. It was possible to make the shout box also act as notifications where it would say x person posted in y section. Of course the shout box was basically like a giant single social media post or IM, I suspect a similar setup to how social media is today and having the forum section would be a better match. @Gunman I agree, jagex's detection methods aren't going to be so much on the client side, it will be more server based where it can't be tampered with. Anyone that has programmed client/server applications knows to never trust the client.

I agree, I personally prefer forums too over the social media instant reply but super low grade reply systems. I don't like people guessing the answers to questions, I just want the real answers or questions to clarify things. I like details though, not surface level answers, give me the why with it and I'm happy. @z10n What all do you think osbot needs for updates? There's a few ideas I have that should be possible, but I haven't dev'ed my own client or anything quite yet so I can't really say if my concepts would work and don't really want to state them publicly for prying eyes to catch that could make the process harder. The only thing right now is a way to load the offline jar file for the game so I can modify it on top of the osbot injections, and also it should load much faster and more reliably. Right now I have a 60 sec timer between each instance to start since they seem to fail to load if started too quickly. It would be great if it would load cached files instead of grabbing live files every time. I'm roughly 70-90% success rate for starting the bots which isn't exactly great. I've made I guess you could call it a client loader, very very early stages of a custom bot client effectively, and I have 100% successful startups and almost instant by loading a local copy of the jar file that I've been poking at some. I have some ideas I'm poking at, one is I want to reduce the cpu usage while the client is waiting for the login server reply for checking accounts for bans. I'm hoping osbot supports this use case, but I suspect it doesn't and probably won't. I guess I'm outgrowing osbot effectively, just hate to have to recreate my bots from scratch with my own custom client that I'd have to maintain. I'm quite new to the process, so it's a slow learning curve, but I've poked at java byte code a bit in the past so I'm not completely new to the idea/concept. I suspect a feature that a lot of people would like is a mobile based bot. I never looked into it to see if it's still java based or not, if it is then it should be somewhat easy to port over, if not then it's probably not so fun to mod.

If the rs client updates, the osbot client can't hook into it or do anything useful till the osbot devs update it, so even if you could force it, it still wouldn't work unless you was able to do the updates your self, which you'd probably be best to be part of the dev team at that point =).

I'm messing around with modifying the rs game client, one of my main goals is to investigate the high cpu spike at login that has recently popped up (in the last 3 or so months). I'd prefer not having to rewrite my scripts, but I'm not sure if osbot can load an already modified jar file. I know my modifications could break the injection code. If it's not supported, then my options are to modify the osbot client too, or rewrite my scripts and use my own "custom client". It would be nice to be able to define the config file too for the rs client, then starting up a lot of bots could be done almost instantly instead of the huge delay (30-60 secs) for each client to download it's settings and 10% or so fail. I'm using a different proxy per bot so have to start several instances of osbot unless there's a way to assign proxy per rs client in osbot now via CLI From what I've gathered so far, it appears like the high cpu spike is in the time the client is waiting for a server reply so I suspect it's a while loop with no sleep or way to give cpu time to other processes. Hopefully this can be done or easily modified into the osbot client, if not my custom client I think I'll be going a bit different direction than what most other bot clients do and of course it would be a private client, not for release, I don't want to compete with osbot, just fix some issues I've seen come up with out throwing more hardware at the problem, electric use, etc.

Wanted to provide an update on the situation, cpu issue just doesn't go away after updates any more, seems like jagex had code that was changed that kept making it in the updates then later wasn't included. I've been wanting to get into modifying the client and such, so I've done some poking around, I've made an applet loader and have gotten the client to open in my own instance, basically the very basic first steps for building a bot client from scratch. If I find the issue in the bytecode and patch it, is there a way to make osbot load my offline copy of the gamepack.jar file, or will I have to write the bot from scratch effectively in a custom client? I've done some really basic looking into the issue, the packet building process for the login happens quite quickly, the high cpu spike appears to be while the client is waiting for the reply from the server. My guess is some new programmer at jagex removed a small sleep in the while loop that would keep the cpu usage down. If/when I find the related class file and method, it should be a pretty easy patch. I'm quite new with working with the rs client, so steep learning curve, but so far it's not too bad working with bytecode. I initially thought that this update was related to client detection or a way to offset the load from their servers by making the clients do some task. Now I'm thinking it's just an amateur programmer that made a mistake at jagex. @SABadshah Their servers have been slower since this started by about 25% or so. It would be crazy if the same programmer made a mistake on the server side code, but I doubt that since the server doesn't crash with 50-100 logins at the same time granted the delay from server to database server should be very little. osrs is due for an update before long, we have been on client version 209 for quite a while now. Hopefully version 210 fixes the problem, but I'm not expecting it lol. Of course once the new version comes out, I'll have to do my client research and mods all over again. I suspect it shouldn't be too hard to automate this task, I have some ideas on how to do it, and that's the route I started with, but it's a lot faster to test/dev directly editing the bytecode and adding the injection code later. Also a small side note, I recently setup a Linux server and it seems to be able to handle a fair number of bots, around 25-30 with the limitation still cpu. That's with an 8 core amd 4000 series cpu. Been a while since I built it, but finally putting it to use. My old windows base server is running 6-8 to give context and a newer windows based server runs around 12-15 pretty well. Anyway, I doubt the OS is having much effect, but interesting that it seems the Linux machine is working out better for some reason. It's just running Linux Mint.

@MaldestoSame issue here, I don't think the average member has access to change the theme, might be only visible for admins. You should be able to change the theme for all members to the dark one some way, or just remove the bright default theme, the site doesn't look right anyway since everything is based on the darker theme. Really doesn't bother me since I use the forums so little, but a lot of the names and such are too bright with the white background so they are hard to read. Also worth a mention, I loaded the forums not logged in and it also defaults to the white/bright theme.

Figured I'd pop in and mention the cpu issue hasn't gone away. It's really odd though, sometimes it's so bad I can only run 8 bots, some times it's not as bad and I can run like 15. When it goes away which seems to be somewhat random, I can hit 25 or so. Only difference is how much cpu the java.exe's are using during login.

That's interesting. Right after the update I started up the script, all was well for a short time then cpu issues came back. Almost seems like it relates to if jagex's login server is seeing a high load, the clients are doing something extra to make logins take longer. The issue changes a little too, at first I could run around 11 on my server (normally run 25-30), now I'm running 8 and it's almost hitting solid 100% cpu usage. Haven't had time lately, but thinking about trying another botting client to see if the issue exists there and port my code over. I'd assume it would be there, but I heard rumor it's not as bad on some other clients, their low cpu usage mode or something seems to help against the issue. Can't really speculate too much with out actually testing.

Welp, high cpu issue seems to be back. No rs update, it just suddenly went high cpu while running the script (right in the middle of a batch). I wonder if this is jagex's response to lower the load on their login server by making the clients have to do more work in order to attempt to login. Like maybe if their server is being flooded atm, it's a way to slow down the flood so their server doesn't get effectively ddos'ed. I know their login server has been pretty bad at times so I can only assume they are bombarded by a ton of login requests or something.

Yea the bot initialization error is the common one I get. It happens right at script load time, either it's an issue communicating to the osbot servers for the account auth to make sure it's a VIP+ user, or it's failing to load RS from what I can tell. That's why I have to babysit the startup even though CLI shouldn't need to be babysat as it's command line started. I've been having 30-50% failures lately.

Well, there's an RS update, and long and behold, cpu issues gone again. Osbot didn't update that I saw (using CLI to start). I've been getting a lot of failures to start in the last couple months, could be my proxies though. Oh one got a different error I haven't seen yet. Could be proxy or the osbot server is slow for some reason. Kind of weird though, once the bot is up and running I never have connection issues to rs. Sucks I always have to babysit the startups. Anyway, unrelated to the orig post's problem, hopefully cpu issues stay away for months again.

Yea, I'm hoping the next update it's fixed and they did another mass ban or what ever. If it's only shortly lived it's not a big deal, but super annoying if it lasts longer.

I dug back in some chat logs. Looks like last time I noticed this high CPU usage issue at login was Sept 2nd 2021. It was a while back, but it seems like it came, got fixed, then came back shortly after and it stuck around a week, then dissapeared for a long time. Around 2 weeks ago it showed up and went away shortly after, about the time the mass bans happened for the client detection.

Yea I've thought about that, maybe it's trying to md5 each module in memory or something similar. Whatever it's processing, if it doesn't change it seems like it would be possible to inject the module, let it process through the first time through to get the right answers, then use the cached answer and skip the processing. I've touched into byte code and reverse engineering a tiny bit on JAR's but I'm not far enough to do much more. My method of injecting modules is probably detectable but it worked well enough for my old project I was poking at. I've had the idea of attempting to build a headless client, I suspect the protocol under the hood doesn't change, but the op codes are shuffled every update or something like that. For sure not an impossible task, but there's a lot of work involved. For osbot to do something similar, they'd probably need to inject the client to remove the encryption from the protocol, or at least update the keys to their own and host a man in the middle attack server to monitor messages, then forward to the real server and log replies and such. Basically have a way to test each update before it's pushed out so there's not a mass ban from a tiny change. I think it would be a really awesome route to go, but it's also a lot harder to pull off I think too. One server could run 500-1000 bots I'd think. I know there's some headless clients out there, but I don't think there's anything open for the average botter to get access to. It's clearly something that would probably cripple runescape if it hit mainstream, the login servers have a hard enough time as it is.

One is more modern hardware but has smaller heat sinks so it can't run at 100% cpu or it overheats. The other one with older hardware has plenty of cooling, but of course older hardware isn't as fast which is what I'm mainly basing things on since it's the one that's used the most (24/7 since 2019 basically). It has 32gb ram 6 core phenom 2 amd cpu 3.3ghz black edition (on stock clock). It sucks a good deal of power, but it's what I have on hand. I've been using this server for years, and the script hasn't changed to cause the cpu issues. The only changes are after the cpu spiked the first time I added some extra sleeps in possible areas that could spike cpu usage with no change. Like I said, I can recreate the issue with the official client, it started back up with the cpu problems at the last rs update and it has come and went in the past a couple times or so. The script effected the most by this has barely changed since 2019. I haven't tried other bot clients to see if anyone has detected the issue and figured out a workaround/solution to it. I'm sure it's quite a niche issue that most people don't notice it. If I had more time to learn how a bot client is made, I'd probably be able to figure out what's going on exactly. I know RSA encryption is part of the login protocol, but encrypting a message isn't hard for the cpu and 1000's of messages can be encrypted very quickly. This is more like a wait loop with no sleep in Jagex's code, or they intentionally make it high cpu by performing some useless task like md5 junk data 100k times. It comes and goes with rs updates, so I'm almost positive it's 100% jagex's code side of things. If it's just a bad loop or useless processing, I don't think it would be too hard to skip over the work load or add a small sleep. It could be possible they have a different protocol for login sometimes that requires more work to be done (say the 100k md5 thing, but with the password) and they use that to validate if the password matches what they have pre-processed. When the cpu issue happens, java is using 100% usage of a single cpu core. Before the same area of the login would take around 5-20% (1-4% overall cpu usage vs 17%). I suspect in 1-2 rs updates it will be gone again.