Jump to content

dreameo

Scripter II
  • Posts

    410
  • Joined

  • Last visited

  • Days Won

    2
  • Feedback

    100%

Everything posted by dreameo

  1. List<GroundItem> groundItems = getGroundItems().get(myPlayer().getX(), myPlayer().getY()); groundItems.forEach(groundItem -> { if(groundItem != null){ groundItem.interact("take"); // not sure if the interact is 'take' } }); // This will spam and you will have to put a type of sleep that you prefer This is just off my head but this is about it. Maybe a syntax error somewhere but you should be able to fix it.
  2. Notice how most of the actions are booleans? They return true if the action occured and false if the action failed. You only want to do a conditional sleep if an action occurs. So for example if you interact and fail, you will wait for 5 seconds because of the timeout. On the other hand, if you use the conditionals right, if you fail an interact, you wont wait those 5 seconds.
  3. You haven't been using conditionals in the right way at all. // WRONG talkToButler(); new ConditionalSleep(5000) { @Override public boolean condition() { return fetchPlanksWidget(); } }.sleep(); // RIGHT if(talkToButler()){ new ConditionalSleep(5000) { @Override public boolean condition() { return fetchPlanksWidget(); } }.sleep(); } The conditonalSleep should be triggered if the "talkToButler" action is true.
  4. It's much easier to do everything via a HTTP server and REST API.
  5. No, there's a stream or a class that allows you to combine streams into one.
  6. As a server: -Accepting new clients is a blocking event -Reading from a client stream is a blocking event You can combine all client streams into a single stream and listen to that single stream which only requires one thread. In doing so, each message must include data to distinguish one client from another. So that you know who to reply back to as a server. Regarding accepting clients, this has to be done in another separate thread. You just have to make sure that you continue to accept and not block other requests. If not, a timeout will be caused by the client and the connection will fail. You should just play around in an IDE without any kind of bots and just figure out how to do this. Just basic message passing between client(s) and server.
  7. I'm guessing this is hunting - don't really know much about it. I'm not sure the difference between catching and receiving a kebbit. But in any case, you want to create a conditional sleep such that you sleep until you're inventory contains x + 1 kebbits. So you would need a variable representing the previous count, X, and sleep until getCurrentKebbitCount() == X + 1.
  8. Btw, that doesn't actually do anything, it's redundant.
  9. Hmm sorry, I don't have any plans on making any updates. I would recommend using another FM if it's a major issue - definitely a free one.
  10. You could just swapToRandomStyle() after x levels. You don't need a separate thread either to keep track of new levels gained. It can all be done within the same thread. Example: 1-4 Attack 1-3 Def 1-5 Strength 5 - 8 Strength (swapped to the same one) 3 - 7 Def 7 - 10 Def 4 - 8 Attack
  11. I don't really see anything wrong with this. I think most people in this forum are very pessimistic about anti-ban. That's partly due to Alek's own beliefs that spread. But It's better to explore stuff and try it out. Who knows what works and what might not work. Yes, these same things have been tested but not all tests are the same and something new could be discovered. So yeah, just do you and try out new ways of anti-ban.
  12. Is this something that started happening?
  13. It's good noob. (but doesn't support multiple clients on server) @OP, figure out which one you want to do. (HTTP is the much easier route)
  14. Visiting this page has now cursed you for all of eternity.  Bugs will plague you foreba!

    To remove this curse you have to chant the following:

     

    oh czar oh czar

    oh czar oh czar

    undo the bugs

    (Shout) bugs away!

    shimi shimi shimi shimiya

  15. readLine is a blocking call and waits for input. Your issue is that your making multiple reads when you should be just reading the value once at the time of your while loop. msg = in.ReadLine(); if(msg == ..){ } else if (msg == ..){ } else { } You have to make your client and server very ping pong like: If you read, then you must immediately write and vice versa. However, there should only be one read and it should be at the top. You can look at this but it might be a bit confusing: Also make your outputstream autoflash (set true in constructor)
  16. You can use gaussian sleeps to try and achieve a normal distributions. I think ultimately, you will find out that it doesn't make a difference.
  17. Just wanted to show you how simple it can be. Nothing is difficult.
  18. Yes I'm aware of what you said xD. If you look, there exists a thread for each Client Output Stream. To prevent the server from being blocked waiting on input. I'd rather not do this.
  19. That's not really the issue. The issue is, do I really want to create a separate thread for each client connection. Seems a bit excessive. Making calls via REST api and an HTTP server seems easy for everyone.
  20. Yeah I would suggest doing what I said in my edit for now. Need to rework the code to support 1-n connections from server to client. Over looked that. There could be some unneeded complexities due to using a socket client/server. When an HTTP server might be just as efficient and easier. Going to look up some answers.
  21. Here's an example of what i've done before. I had one script and multiple accounts. I would start any number of clients, say 4 osbot clients. Without telling it what to do, the server would tell each client which account to log into. The client would bot and after x random minutes, would log off and tell the server that this account is now going on break mode. The server would put that account now in break mode and not hand it out to any of the clients. The server would send over a new account to the client to start botting. So the server was responsible for telling the client which account to use. The server would be notified however of other details, if the account was banned for instance. The server would remove the account and immediately send over a new account to the client. The script itself was to get from 1-60 WC. So imagine just having a large list of accounts and after a couple days, you would automatically have couple hundred of accounts with just 60wc. But things get a bit more complex if you want to use proxies and stuff. Since then you would need the server to also create processes (start the client from a cmd). The important thing is just communication. You can talk between all your bots when you have a central place to do so. From that point, you can do whatever you like. EDIT: One thing I should point out is that the code only supports a 1 to 1 connection. You would need to modify the server to support talking to multiple people. I wasn't thinking about that last night. An easier way to communicate is making HTTP calls. That way you don't need to worry about multi threading if you aren't familiar. You would still have a server but this time it would be an HTTP server and you wouldn't have sockets. Each client would make an HTTP call to the server with information.
  22. Creating a server allows for a central place of communication. You might want to have several bot instances communicate. Creating a central server that talks with multiple clients is the best way to communicate. Some noobs use a text file to communicate, they are n00bs. The issue with that is, the code generally is ignorant of the external environment. Not knowing who is accessing the file, if it's already open, if a change has been made and it's viewing old data, etc. You could try some hacky things but majority of the time, the hacky things will break (that or you could never scale the size of your project to large numbers). When you speak with a server, the server is aware of the states of the clients and would give you the rights to do X and Y. Communication is one application of client server architecture. You could easily delegate tasks to your server that you wouldn't want to do as a client. Server: Client: IOHandler: IO Interface: I didn't fully test these but it seems to be fine. Usage: Server must always run before the client. Choose any port you like. Server: public class Test { public static void main(String[] args) throws InterruptedException { Server server = new Server(50000); server.listen(); server.write("Hello peasant"); } } Client: public class Test { public static void main(String[] args) throws UnknownHostException { Client client = new Client("0.0.0.0", 50000); client.connect(); client.setReadHandler((s) -> { if(s.equals("Hello peasant")) client.close(); else System.out.println(s); }); client.write("Hi dummy"); } } Everything should be really easy and straight forward. 1. Create a server, choose a port, then listen(); 2. Create a client, for local usage, just use "0.0.0.0" IP and the same port as the server. 3. Optional, you can choose the read behavior when creating a client or server. By default, when receiving any messages. it will print to console. You can override this in by specifying the read behavior in the constructor or by called the setReadHandler method. The ReadHandler is simple a Functional Interface, Consumer<T>. 4. Call connect(); 5. use write(); to freely send messages. Ideally, you would want to create some protocol in the ReadHandler. 6. call close(): to end the connection.
×
×
  • Create New...