Jump to content

liverare

Scripter II
  • Posts

    1296
  • Joined

  • Last visited

  • Days Won

    3
  • Feedback

    0%

Everything posted by liverare

  1. Okay, so the enum isn't the problem. What about exchanging the bot context with the MethodProvider?
  2. MethodProvider You've got a variable for what I assume is the MethodProvider. You need to make sure that, before you use it, you call: mp.exchangeContext(bot) With the "bot" being passed in from the script. Herb enum Can you post your enum code? On the one hand, you have: h.getCleanHerbPrice() But on the other hand you're also doing: h.cleanName h.cleanId So it would be good to check to make sure you're calling stuff correctly. Script loop v.s. for-loop Your script already loops over and over again. It's safer to pick one herb per loop cycle and to just deal with that. That way, you avoid problems like having the bot try to drop a bunch of items in one go, only to then end up trying to drop an item that no longer exists.
  3. It appears to be using BooleanSupplier which is mostly syntax sugar. That way, instead of doing: new ConditionalSleep(1000) { @Override public boolean condition() throws InterruptedException { return myPlayer().isUnderAttack(); } }.sleep(); His Sleep class wraps it up and reduces it down to just: new Sleep(myPlayer()::isUnderAttack, 1000).sleep(); Or similarly if you call the static methods in the Sleep class.
  4. You're absolutely right about what the problem is. You've got two solutions: Write your own function that finds the farthest NPCs you're after, or... Write your own function that filters out NPCs within a defined Area. @Czar idea would work, however I think a better solution would be to simply order the list by distance in descending order and return the first result: public NPC getFarthestNPC(String name) { return npcs.getAll().stream() .filter(npc -> name.equals(npc.getName())) .sorted((npc1, npc2) -> { double distToNpc1 = map.distance(npc1); double distToNpc2 = map.distance(npc2); return Double.compare(distToNpc2, distToNpc1); }) .findFirst() .orElse(null); } Then you can do: NPC cow = getFarthestNPC("Cow"); However, just always remember this will return the farthest NPC irrespective of whether or not you can reach it. It'll work fine if you don't need to physically reach a tile, but should you need to then you can tweak around with the code to include filtering for distance/real distance, by areas, etc. :edit: I have just realised that you WILL need to cache the farthest NPC and re-use and re-check it until it stops existing. Why? Because if you keep trying to find the farthest fishing spot, then your in-game player will be running about like a mong.
  5. I'll continue supporting it when it breaks. Please notify me if this script is broken.
  6. Partially agree. If you calculate how long you would expect to have to wait and you have a conditional sleep look out for things that might distract the fish gutting process, then it can work quite well. However, your point still stands; the thing that I believe gets people banned is an unresponsive player. That period of unresponsiveness might be the tell tale sign of a botter.
  7. I'm guessing the issue has something to do with your from-boat-to-Void-Knight logic. I say that because you're using both a state-based system and a task node system, which has made your script difficult to follow. I wrote an ad-hoc alternative that might help:
  8. Hi Irwtonrs1, I've been working on cleaning up the UI code so that I can accommodate for more features. However, admittedly, I've been quite lazy and slow and only really started working on it today actually. I'm thinking I might re-do the entire script and release it as a premium alternative with all the goodies I have mentioned in a previous post. That would certainly motivate me more.
  9. Nice work. Also, you don't need to use getFrame when you can do: Window w = SwingUtilities.getWindowAncestor(bot.getCanvas()); JFrame f = (JFrame) w; f.setTitle("TEST");
  10. k just make sure you only use it on the surface Wilderness, cus it won't work in Clan Wars or downstairs in the fire giants spawn in deep wildi
  11. Hi Edward, There's an issue with OSBot where you have to refresh your script list before running this script. Otherwise, for some strange reason, the bot doesn't type anything out even though it it's told to. Sorry for the inconvenience.
  12. The API is horribly undocumented when it comes to internal stuff like this, so it's pretty much guess work. Try something like this: /* * ConditionalLoop isn't documented in the API. * Parameters: * 1. Bot * 2. Some random unspecified integer that's perhaps the number of cycles * before the loop ends. 0 = infinite? */ new ConditionalLoop(bot, 0) { @Override public int loop() { // your code here... return // probably -1 or 0 to stop, then anything else = sleep time? } }; Hopefully, by specifying the 'bot', the conditional loop will pause/suspend/die when the script does too, because you can find that out from the bot: private boolean isScriptRunning() { return bot.getScriptExecutor().isRunning(); }
  13. I used Map because I wanted to construct something in parts, which I find to be more readable. Your change is more efficient, but now you're left with a constructor that has more than 3 parameters. I was persuaded in a coding video to value readability over efficiency, because I've all too often made the mistake of trying to hit the highest performance marks, yet the resulting code grows unwieldy and unmaintainable. Also, this oracle is dependent on RSBuddy not messing with their summary.json, which means the code has to be structured in a way that makes it easy to change parts that may break in the future. And we're only talking 1 second, which I don't think is a problem unless you're writing a GE investor script. I used long values because an int overflow is to be expected when dealing with price * quantity, for example, if you were making a bank calculator, your bank value could exceed the highest int value and so the developer would have to cast from ints to longs retrospectively. I also did it because it coincides nicely with OSBot's own ItemContainer#getAmount too. As for preferring to use names; be aware that some items share the same names. Although, none of the duplicate item names appear to be for any item with any significance, this could potentially be a problem in the future. I'm glad you're changing it - it's why I put it out there. Make it your own.
  14. If I recall, Strings aren't cleared up by the garbage collector because the values are stored separately and as constants (because strings can be stupidly long and so memory intensive, so it's best to reuse wherever possible). I used WeakHashMap because "it discards entries when the key is no longer strongly reachable from live code" which helps manage memory, which is important when you've got like 4K entries and you're not going to be using them all. However, I forgot strings don't get removed, so the Map<String, ...> might as well be a HashMap.
  15. Strange. I ran your tests without having changed the oracle in any way, and my results are: If you're getting null, it could perhaps be a caching issue, connection issue, or something else. Try again with Eclipse.
  16. Sorry, it's New Years and I'm pretty tired lol. I'm not sure why you only got 254 mapped entries when I got the following: System.out.println("JSON_BY_IDS.size() = " + JSON_BY_IDS.size()); System.out.println("JSON_BY_NAMES.size() = " + JSON_BY_NAMES.size()); Which resulted with: I was able to get prices for items with ids 434 and 512. However, the discrepancy between the number of result in the two maps is because JSON_BY_NAMES stores Strings as keys and there are multiple items sharing the exact same names: Thanks for highlighting this problem, you've definitely found a bug. However, fixing this would either require a data restructure or query restructure, which is either more complicated or less efficient. Also, as long as you can continue to get items by IDs, then I'm not too worried.
  17. Try replacing it with a HashMap.
  18. I wouldn't sleep until the ore is regenerated, because you risk blocking your entire script for an unspecified amount of time. That's risky, especially if you're surrounded by hostile foes. Consider leveraging the script loop instead. Each loop cycle is a brand new chance for you to assess and re-assess where you are, what you're doing, then to figure out what you're going to do next. That way, if you're waiting on ore but you're suddenly attacked, your script can go into a completely different state of behaviour where it focuses on mitigating the danger before resuming its mining task.
  19. I'm guessing this is for ironmen? The key for this would be to not only look for loot where the monster was killed, but to also go through the items you want 1-by-1 to check whether you can loot it, and to remove it from the list if you can't. import java.util.LinkedList; import java.util.stream.Collectors; import java.util.stream.Stream; import org.osbot.rs07.api.map.Position; import org.osbot.rs07.api.model.GroundItem; import org.osbot.rs07.api.model.NPC; import org.osbot.rs07.script.Script; import org.osbot.rs07.utility.ConditionalSleep; public class test extends Script { NPC target; Position targetTile; LinkedList<GroundItem> loot; GroundItem nextLoot; @Override public int onLoop() throws InterruptedException { target = npcs.closest("Something..."); targetTile = target.getPosition(); { // once target is dead loot(); } return 0; } private void loot() { if (loot == null) { // let's find some loot loot = getGroundItems(targetTile, "Iron arrows", "Bronze arrows", "Bone bolts"); } else if (loot.isEmpty()) { // can't loot anything else loot = null; } else if (nextLoot != null && nextLoot.exists()) { // next loot ready for the taking if (takeItem(nextLoot)) { // check inventory to make sure we picked it up... // tally up a counter.... // price check..... // etc...... } nextLoot = null; } else { // need to get the next loot in the queue nextLoot = loot.poll(); } } private boolean takeItem(GroundItem item) { boolean taken = false; ConditionalSleep sleepyTimesUntilWePickupItem; if (item != null && item.exists()) { sleepyTimesUntilWePickupItem = new ConditionalSleep(2500) { @Override public boolean condition() throws InterruptedException { // item exists in memory, but not in game return item != null && !item.exists(); } }; if (item.interact("Take")) { taken = sleepyTimesUntilWePickupItem.sleep(); // assume we picked it up } } return taken; } private LinkedList<GroundItem> getGroundItems(Position tile, String... names) { return groundItems.get(tile.getX(), tile.getY()) .stream() .filter(item -> Stream.of(names).anyMatch(item.getName()::equalsIgnoreCase)) .collect(Collectors.toCollection(LinkedList<GroundItem>::new)); } } Untested btw.
  20. I don't think a listener is necessary: IF trade window = OPEN IF trade window = ACCEPTED WAIT ELSE IF trade items = VERIFIED DO trade accept ELSE IF trade is taking fucking ages DO trade decline You could have a counter tally up the amount of times you've hit 'accept' for somebody who's trying to scam you, then forcefully decline the trade and blacklist that player so that your bot doesn't spend 10 hours trying to deal with the same guy.
  21. The complexity lies in the client in how it determines what packets to generate and process. You can look into some of the 317 protocols here to see the sorts of information being passed around for the older clients. However, the client and servers likely work in-tandem to make sure that when a packet is expected, bad things happen if they aren't received. There are anti-cheat packets you need to be aware of, and they are likely generated after a certain number of interactions in-game and then generated at timed intervals. Mess with those and you might set off some red flags at Jagex HQ.
  22. I've fixed the RSBuddyExchangePrice.java, as it was missing a toString method.
×
×
  • Create New...