Jump to content

dreameo

Scripter II
  • Posts

    410
  • Joined

  • Last visited

  • Days Won

    2
  • Feedback

    100%

Posts posted by dreameo

  1. 6 hours ago, Czar said:

     

    Turn shots variable into an AtomicInteger :doge: 

    and make sure the shots += 1 is incremented atomically (incrementing an int = multiple instruction sets: iinc and store?)

    That would make it thread safe but programming logic would still be incorrect.

    You wouldn't want to reset the 'shots' counter while you're iterating over the 'projectiles list'.  You would want to wait until that loop is finished and then allow the reset.

  2. On 10/7/2021 at 10:40 PM, Malcolm said:

    I much prefer to create a class that implements the runnable interface. This way it makes it much cleaner (at least imo).

    Here is an example for my V2 slayer cannon shot listener.

    private Thread cannonThread;
    private CannonListener cannonListener;

     

    public void startCannonListener() {
        cannonListener = new CannonListener(this);
        cannonThread = new Thread(cannonListener);
        cannonThread.start();
    }

    and the CannonListener class

    public class CannonListener implements Runnable {
    
        private final Main script;
    
        private int shots = 0;
        private final ArrayList<Integer> loopList = new ArrayList<Integer>();
    
        public CannonListener(final Main script) {
            this.script = script;
        }
    
        @Override
        public void run() {
            script.log("Starting cannon listener...");
            while (script.getBot().getScriptExecutor().isRunning() || script.getBot().getScriptExecutor().isPaused()) {
                if (script.getClassProvider().getFighting().getCombatMaintenance().hasPlacedCannon()) {
                    final List<Projectile> list = script.getProjectiles().filter(f -> f.getId() == 53);
                    for (Projectile proj : list) {
                        if (!loopList.contains(proj.getLoopCycle())) {
                            shots += 1;
                            loopList.add(proj.getLoopCycle());
                        }
                    }
                }
                Timing.waitCondition(() -> false, 100);
            }
        }
    
        public int getShots() {
            return shots;
        }
    
        public void resetShots() {
            this.shots = 0;
        }
    }
    

    This is not thread safe. You need to guard access to 'shots'.

  3. In cases like this, it's negligible even if it did check. However, just know that the java compiler is smart and sophisticated and in a lot of cases, optimizes for situations like this. Where it wont perform a set of executions given the outcome doesn't change anything.

    • Like 1
  4. You have the right idea, just the wrong execution. (You can try reading this but if it doesn't make sense, try some simpler java tutorials - https://javagoal.com/static-and-non-static-variable-in-java/)

     

     

    There's a few different options but here's an easy one:

    static List<Position> path;
    
    static {
     path = new ArrayList<>();
     path.add(new Position(x,y,z));
     path.add(new Position(x,y,z));
     path.add(new Position(x,y,z));
    }
    
    // your onLoop would remain the same. 

     

  5. https://pastebin.com/B7GexCCy

     

    Offers:

    - Thread Safe (same object can be used by multiple threads)

    - Throws lock exception if two or more distinct objects pointing to the same file try to acquire a lock (locks acquired by performing read/write)

     

    (One minor thing: Assumes EOF contains new line - you can put some hack to fix it but I didn't bother)

     

    Notes (from java lib):

    This file-locking API is intended to map directly to the native locking facility of the underlying operating system. Thus the locks held on a file should be visible to all programs that have access to the file, regardless of the language in which those programs are written.

    Whether or not a lock actually prevents another program from accessing the content of the locked region is system-dependent and therefore unspecified. The native file-locking facilities of some systems are merely advisory, meaning that programs must cooperatively observe a known locking protocol in order to guarantee data integrity. On other systems native file locks are mandatory, meaning that if one program locks a region of a file then other programs are actually prevented from accessing that region in a way that would violate the lock. On yet other systems, whether native file locks are advisory or mandatory is configurable on a per-file basis. To ensure consistent and correct behavior across platforms, it is strongly recommended that the locks provided by this API be used as if they were advisory locks.

    • Like 2
  6. 41 minutes ago, Nbacon said:

    I don't think I under stand this fully explain more. Becuase to me they are protocol becuase both sides agree on info that is sent over the sockets. You dont need packets to be mono taskers. But they can keeping a theme in a packet, this is usefull for expandability (for me at least). For my bot at least I have never needed more then 5 "packet",  The bots are kept in the dark about the 30 other packets they cant see but the server can handle all 35.

    This sounds like what it is doing.(I don't Know how you would do this externally)

     

    Both sides don't agree, you have to manually go in and define a new packet for every type of message.

  7. I think there's a bit of over complication here. Instead of defining a 'packet' for every kind of message, just define a protocol. This way, you have a single send and receive. Internally, you decide how you make sense of the data.  I'd also suggest keeping your classes minimal and light.

     

     

  8. @Override
      public void onStart() throws InterruptedException {
      getBot().getMouseListeners().add(new BotMouseListener() {
        @Override
          public void checkMouseEvent(MouseEvent mouseEvent) {
          // on shift + left click
          if(mouseEvent.getModifiersEx() == 1088){
    
          }
        }
      });
    }

     

    Didn't find any documentation but this will do (for win 10 at least).

  9. 3 hours ago, Token said:

    That's a problem with the newest mirror mode version, a new mirror client should be available soon, it's already in testing

    I've been using this in mirror mode 4.0 and it works pretty well.

    Even did monkey madness flawlessly.

  10. Automated farms and an SQL database aren't correlated. 

    With that being said, look into why you need a database and what kind of information needs to be stored. Once you find that out, you can make a decision on the data storage. There are many possibilities each with their own implementation details and some will be easier to implement than others (relative to osbot restrictions). 

    My only piece of advice is that if you want to bypass the limitations of osbot, use a middleman service (an application that is separate from osbot) to act as a proxy.

    • Like 2
  11. 46 minutes ago, troro1 said:

    You are pushing out a defective product and have no made any announcements about modifications to your code. Your product *works* as expected, no doubt about it. However the end result is a ban therefore it ultimately does not work as expected.

    Now I've only used the product on 1-2 week old accouts that have gotten some levels and they've all received a ban. If you want to use this script, use the most liberal amount of breaks that you can think of. As for the script author, you do not have zero responsibility for users getting banned for this script.

    Here's a story:

    • Jimmy buys a knife
    • Jimmy uses the knife to cut things and very much likes the knife
    • One day. Jimmy cut himself! and Jimmy starts to bleed
    • Jimmy starts to complain and says the knife is harmful and blames the maker of the knife
    • Jimmy calls the knife maker and says, "Your product hurt me!"
    • The knife maker replies and says to Jimmy, "On the package and on the knife, it clearly states, 'Use with caution'".
    • The knife maker hangs up and blocks Jimmy

    If you haven't noticed, you're Jimmy.

    The FM works as it should and like all botting, there's a probability of being banned. Botting and bans are inseparable, if you think otherwise, then you're a lost cause.

    One last thing since you're having such a hard time with this concept. The 'product' is a 'bot' that automates a task, in this case, firemaking - nothing more and nothing less. If you wish to reap the benefits of this bot, then also be prepared to also face the consequences.

    • Like 2
×
×
  • Create New...