Jump to content

liverare

Scripter II
  • Posts

    1296
  • Joined

  • Last visited

  • Days Won

    3
  • Feedback

    0%

Everything posted by liverare

  1. Just to clarify: You've built your own login event handler that is ran onStart This event is set to asynchronous with a timeout of 5000ms If you fail to login, the script should stop If you successfully login, the script should proceed to the onLoop The onLoop firstly checks to make sure you're logged in If I've got this correct, then I don't think this is the right approach, because the onLoop will be called once onStart has been executed. You could block the onStart to delay the loop, but I would advise against it because onStart is only called once, and if there's a problem in its execution, the entire script would have to be restarted. Instead, I would handle all this within the loop; you can use a combination of boolean checks and timestamps to see where you are and where you should be: onLoop IF logged in DO stuff ELSE IF we have entered in our login details IF we have clicked the login button IF 5 seconds have passed DO stop script ELSE DO click login ELSE enter in login information
  2. I just tried it and it worked for me. Disable fast keyboard as this feature is broken (and isn't native to OSBot), and try again.
  3. Remove onExit and onPaint if you're not using them. Remove anti-ban stuff because it's fairly redundant (unless it's there to avoid logging out). Rework your autocast method so that you pass in the spell you want to select as a parameter. This would halve that block of code easily. I'd caution against using state-based scripts because they can be very limiting and inefficient if improperly used (e.g. if you're searching for an NPC twice). Also, when handling weapon/armour, you should (ideally) only do this once. I would suggest making it so your onLoop function does this check and action once, then when you're certain you're ready, you simply switch a boolean flag and it's never checked again: Your code is looking good - keep it up!
  4. I think it would help if you made it so all your loop method does is run a bunch of checks and makes a bunch of calls to other functions. Don't handle anything else. That way, you'll know precisely what your script is doing: @Override public int onLoop() throws InterruptedException { if (dialogues.isPendingContinuation()) { dialogues.clickContinue(); } else if (isFighting()) { if (isLowOnHealth()) { if (canHeal()) { heal(); } else { runAway(); } } } else if (areBonesPresentInInventory()) { if (!isIdle()) { buryNextBone(); } } else if (lootingEnabled && isLootPresent()) { if (isInventoryFull()) { if (isJunkPresent()) { dropJunk(); } else { goBankStuff(); } } else { loot(); } } else { fight(); } }
  5. Hmm, this is quite an usual problem. You could try the following: Sort items by index The GroundItem API has a GroundItem#getIndex method which vaguely states "getIndex in interface Entity" which could refer to the right-click menu and the index option in that: groundItems.getAll().stream() .filter((item) -> item.getName().equals("Leaping sturgeon")) .sorted((item1, item2) -> Integer.compare(item1.getIndex(), item2.getIndex())) .forEach((item) -> item.interact("Take")); If that doesn't work, you could try sorting using Menu#getMenuIndex like so: menu.getMenuIndex(item, new String[] { "Leaping sturgeon" }, new String[] { "Take" }); Or... Use the interact method without a parameter However, you run the risk of picking up items you don't want because when you don't enter anything in, the bot left clicks. Or... Manually select menu options by strictly using the Menu API That would be more work than it's worth, but if nothing else works then you can do this.
  6. I'd be interest to take a look about, but I've never build a botting client. There's been talk about botting on mobile way before the release and from what I've gathered: Building a bot would require root access to the phone, which most users won't ever do. Injection/reflection is harder and more limited on mobile. More of a hassle when the desktop version works fine. Internet connection is unreliable if you're out and about. These are all fair critiques. However, I'll stick to what I've said in the past: The first botting community to build and support a working OSRS mobile bot client will corner the entire cheating community. Users love innovation and playing OSRS on mobile is a completely different experience. While there are challenges, that doesn't make it impossible.
  7. There goes our last line of communication to the development team. Gl on your new job mate.
  8. If I had to take a guess, the problem could either be: The batch file isn't loading all of the jar files in the /lib/ folder. I believe "lib/*" statement in the batch file would grab them all, but I could be wrong. The jar files aren't being included as dependencies when you compile your scripts. I might take a look into this tomorrow.
  9. Good job on the release! fyi you included the whole of OSBot in your Jar. You may want to fix that - you can manually remove stuff from them like you would zip/rar folders, using the same programs (like WinRAR).
  10. Yesterday, there was a thread discussing auto-clickers and @Alek said the following: I asked him whether OSBot accounts for this and he said: I'm confident with OSBot being a bot built on-top of RS, there are means and methods in place to 'trick' the game into believing which events are real/not real. As for the relative click feature; all clicks recorded using my macro are already relative. When you record clicks, their X and Y positions are relative to the client. Are you asking for a way of slightly offsetting them as is what I think is being asked here?
  11. Red record button = you're recording. Click it again to stop recording. Then you can playback your recording. No file is created when you start/stop recording - it's only when you go file > save are files created. There are 4 controls: Record button - this just starts/stops recording. Click it (or use hotkey) and do what you want to do in-game. Play button - once you've recorded something, you can play it back. Pause button - if you're playing back your recorded macro, you can pause it at any point. Stop button - if your macro is playing/paused, you can completely stop it. I thought the icons were self-explanatory, but what I'll do is perhaps merge the play and pause buttons into one and include this in the guide or something. Some features to come in the future: Randomised delays. Load multiple files and play through them (with the ability to shuffle through them or not), and export all of them into a single file. Draw tile under mouse. Create safe areas on the screen where no mouse clicks/movements will be recorded. In-game paint overlay with controls. Camera locking (not sure I need to add this though). Speed changer. And more.. Right now, I'm reworking how macro files are made as it's currently very inefficient. Even a small recording has a rather big file size, so I need to come up with a way of reducing the file size, compressing it without losing any playback quality. I would like to keep this script free. It may be the case that I release a free 'lite' version and a VIP/premium that has all the extra stuff.
  12. .../osbot/data/<wherever you saved the files> If you saved any files, they'd be in your OSBot folder. That's the only folder scripts are allowed to read from/write to.
  13. mmk leme rephrase are you more or less likely to get banned using my macro recorder, when compared to third-party alternatives out there?
  14. Does OSBot account for this? If so, then my macro recorder is golden!
  15. You need Java version 8 installed to run OSBot. If you have version 8 installed, but it's not being used because you have a newer version installed too, then you can download the batch file I've attached to this post, place it wherever your OSBot file is, then run it. Right-click the batch file and edit it and you'll see the following: The OSBot file must be called "OSBot.jar" and nothing else. This (or a similar) version 8 path must be valid on your computer: Tweak this in your batch file where needed. osbot.bat
  16. You can do quite a lot more with enumerators in Java than that: import org.osbot.rs07.api.map.Area; public enum FishingData2 { SHRIMP(new Area(new int[][] { { 3087, 3226 }, { 3085, 3228 }, { 3085, 3231 }, { 3085, 3232 }, { 3083, 3235 }, { 3085, 3235 }, { 3088, 3232 }, { 3089, 3227 } }), new String[] {"Small fishing net"}, new String[] {"Net", "Bait"}), SARDINE(new Area(new int[][]{ { 3087, 3226 }, { 3085, 3228 }, { 3085, 3231 }, { 3085, 3232 }, { 3083, 3235 }, { 3085, 3235 }, { 3088, 3232 }, { 3089, 3227 } }), new String[] {"Fishing rod", "Fishing bait"}, new String[] {"Bait", "Net"}), ; private final Area fishingZone; private final String[] equipment; private final String[] npcOptions; private FishingData2(Area fishingZone, String[] equipment, String[] npcOptions) { this.fishingZone = fishingZone; this.equipment = equipment; this.npcOptions = npcOptions; } public Area getFishingZone() { return fishingZone; } public String[] getEquipment() { return equipment; } public String[] getNpcOptions() { return npcOptions; } } Then you can do: FishingData2.SARDINE.getEquipment() Also, perhaps read my most recent tutorial. It might help!
  17. API (org.osbot.rs07.script.API) When should you use this class? Well, when you're planning to build that stunning API. Think of it like this: you've got a bunch of thingy-bobs, such as bank, inventory, widgets, players, npcs, objects, etc etc, but there's always something missing! When you're working on something that has a bunch of moving parts that are all kind of related together, then it might be time to build yourself an API. For example, if I were to build a Duel Arena script, I would write an API to handle the bothersome bits of the staking and setup process, and even the duel itself. That way, I keep all my Duel Arena logicy-stuff out of my main script. Other benefits include: SOLID! Your API will have direct access to all those bank, inventory, widget, and other stuffs! Reusable and maintainable. Your upkeep will be down to minimal changes here and there...unless the game goes through a drastic change again. Also, this handy-dandy class has one thing I really like: an abstract method! When you use this class, you have to complete the initializeModule() method. So when might you use this? Well, if you're hooking up listeners (such as MessageListener) to the bot, or if you need to setup some CachedWidgets, and even initialise stuff. "B-but why not initialise on the constructor?!" I hear you ask. Well, there's a chance you may wish to re-run that initialiseModule function twice in the same script. It'd be unusual, but it means you'd be resetting a bunch of stuff. I wrote a hunter tracking API and I frequently recalled that function, because the tracks change entirely and so the API needed 'cleaning'. If you do this, then be sure your second call clears lists and maps, and doesn't add duplicate listeners. Otherwise, things could go wrong. Here's an example: DuelArenaAPI Admittedly, not everything in this API snippet is best practice. That's because my original Duel Arena API is based on the old interfaces and setup. This was an last-minute-adhoc-scrape-together. But it works! However, one thing you should not do is to extend an existing API, like bank. Why? Because OSBot already has an implementation of it. If you're expanding upon the bank API, then make it a separate API and name it accordingly (such as "ExtraBankAPI" or something). This also makes sure you're keeping inheriting to a minimum, so your objects are fine-gained. This is good, because inheriting an inherited inherit can get inheritingly messy! Example Script MethodProvider (org.osbot.rs07.script.MethodProvider) MethodProvider is very similar to API. In fact, API inherits it! So, why not just API? Because MethodProvider is a method provider. If you're not looking to build a custom API but you still need all those juicy methods, then use MethodProvider. For example, if your script design is based on a task/node system, then those tasks and nodes could extend MethodProvider. Your task/node are likely going to have a generic structure whereby no new methods are exposed to the public scope, and all instances of tasks and nodes are treated the same. DuelArenaTask ChallengeZezimaTask Example Script Bot (org.osbot.rs07.Bot) Bot is basically the robot playing the game for you. That "context" can be used in instances where neither an API nor MethodProvider are required. For example, you may want to save a bunch of game data to a file. In this case, we can use a static method, pass the bot through as a parameter, and then extract the values from the bot, and store them. Example Script This isn't the best example and I can't think of a more relevant one, but it's an example nonetheless. If you recall, the exchangeContext for API and MethodProvider requires Bot to be passed in as a parameter so that these objects have access to the current 'robot' playing the game on your behalf. You could do something similar to that and perhaps have a class that doesn't expose any public methods you did not write yourself. I really hope this guide has helped you. Thanks for reading! Note: I may edit this multiple times, especially if the format f**ks up.
  18. With each iteration of your for loop, you're pressing and releasing the [shift] key, which is suspect. There already is InventorySlotDestination which calculates the X and Y for inventory slots. However, I'd always advise to learn how that stuff does what it does, as opposed to just using it. You could build up your inventory dropping function into your own API, and perhaps have the initialiseModule generate up a bunch of Rectangles in an array, then pick whichever you need using the slot. As for your code, it's pretty...spaghetti. I would recommend you break your processes up into separate routines: Two routines to get the row and column indices for the inventory slot. Two routines to convert row and column indices into X and Y coordination points. Then a few helper routines to help break down the analysis and interactions, just to make the main function dropAll look cleaner. Finally, a dropAll function. The result could look something like this: @Override public int onLoop() { // ... if (dropAll("Tuna", "Salmon", "Herring")) { // We successfully dropped junk items } if (dropAll()) { // We successfully dropped all items } // ... } public boolean dropAll(String... names) { boolean success = false; keyboard.pressKey(KeyEvent.VK_SHIFT); IntStream.range(1, Inventory.SIZE + 1) .filter(slot -> isItemPresent(slot, names)) .forEach(this::leftClickInventorySlot); keyboard.releaseKey(KeyEvent.VK_SHIFT); if (names != null) { success = !inventory.contains(names); } else { success = inventory.isEmpty(); } return success; } Then, you'd have all the other code put into a separate class and perhaps wrapped as its own API: // Helper functions listed below private boolean leftClickInventorySlot(int slot) { return mouse.click( getXPointForInventoryColumn(slot), getYPointForInventoryRow(slot), false); } private boolean isItemPresent(int slot, String... names) { Item item = inventory.getItemInSlot(slot); return item != null && (names == null || item.nameContains(names)); } // Static helper functions listed below private static int getInventoryRow(int slot) { return (slot - 1) / 4; } private static int getInventoryColumn(int slot) { return (slot - 1) % 4; } private static int getYPointForInventoryRow(int slot) { int min; int max; int row = getInventoryRow(slot); switch (row) { case 0: min = 215; max = 235; break; case 1: min = 255; max = 275; break; case 2: min = 290; max = 310; break; case 3: min = 330; max = 350; break; case 4: min = 365; max = 385; break; case 5: min = 400; max = 420; break; default: // 6 is max min = 440; max = 445; break; } return random(min, max); } private static int getXPointForInventoryColumn(int slot) { int min; int max; int column = getInventoryColumn(slot); switch (column) { case 0: min = 565; max = 585; break; case 1: min = 610; max = 630; break; case 2: min = 655; max = 675; break; default: // 3 is max min = 695; max = 715; break; } return random(min, max); }
  19. Following on from @FrostBug post, try this: @Override public int onLoop() throws InterruptedException { if (useItemWithAnotherItemOfTheSameName("Strength potion\\([1-3]\\)")) { stop(false); } return 250; } private boolean useItemWithAnotherItemOfTheSameName(String regex) { return IntStream.range(0, Inventory.SIZE) .filter(index -> { Item item = inventory.getItemInSlot(index); return item != null && item.getName().matches(regex); }) .limit(2) .allMatch(index -> inventory.interact(index, "Use")); } Strength potion\\([1-3]\\) will match Strength potion(1) Strength potion(2) Strength potion(3) The \\ used for \\( and \\) allow us to 'escape' the ( and ) characters, because in regex, they're special characters that need escaping if you wish to use them literally. The [1-3] will match the numbers 1, 2 and 3.
  20. Possibly. I wasn't aware Jagex had an API for it - that must be fairly new. You could use a string split regex, to group things by levels. However, I'm not entirely sure on the format until I compare it with the hiscores. You should redo your API using Jagex's API - it'd save so much overhead.
  21. Fair enough. I decided to go ahead and build a lookup using regex just because I find regex challenging. I managed to get the core functionality working. Perhaps you can make it into something nicer? Source:
  22. Get me a bond and I'll give it a go. I ain't paying £7.00 for a months membership even if I can earn that back through sales. That's so fucking expensive! :edit: I can't even sell anything for a bond because all I've got are members items.
  23. Good work! You can achieve the same results using Regex - and you should. JSOUP isn't part of the standard Java distribution and it's not bundled within OSBot, so that means if you wanted to use this API in a script on the SVN, the user would have to download and re-download the entire JSOUP library each time. That's quite a bit of overhead.
×
×
  • Create New...