dreameo

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.

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

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.

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.

URLConnection request = url.openConnection(); request.setRequestProperty("User-Agent", "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:89.0) Gecko/20100101 Firefox/89.0"); request.connect();

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.

you could just write to a file: if the information is not there, go to bank, get info, dump it to file this information will be persistent and can/should be updated each time you have the bank open

tldr: This is all a conditional sleep does: while(timeRunningFor < timeout && !myBooleanCondition){ Thread.sleep(some_small_value_in_ms); }

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

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.

https://osbot.org/api/org/osbot/rs07/event/webwalk/PathPreferenceProfile.html -You can try disabling all the preferences -Don't think there's a list anywhere -use getPositions from WebWalkEvent

You have two different 'bank' objects and only one is being initialized using 'exchangeContext'. What you could do is make those classes singletons and ensure the main class exchange context prior to them being used elsewhere

@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).

You can add key listeners - press the key(s) which triggers the file read. or if you're real lazy -> https://osbot.org/api/org/osbot/rs07/input/mouse/ClientMouseEventHandler.html

@Patrick Using mirror mode produces this -> That's without any script running. (AKA, start mirror mode and those errors will start spewing out right away)

hi can I leech a trial, thanks.

Script works well in Mirror Mode. Would recommend. Provides all options for custom NMZ use. Thanks Token

I've been using this in mirror mode 4.0 and it works pretty well. Even did monkey madness flawlessly.

This could be your problem. Try getKeyboard().pressKey(VK_Z) // z constant

You could print it to the screen itself using graphics. Implement painter and make use of the graphics 2d object from onPaint method.

log

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.

run the jar from terminal: (use your path, below is my example) 'C:\Program Files (x86)\Java\jre1.8.0_221\bin\java -jar osbot.jar'

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.