Purus Pasta Client [W14 COMPATIBLE]

[shubla]

FYI, your skybox causes a memory leak by forcing the renderlist to fire nonstop. This is the heap growth over a 60 second period with/without skybox. Figured you'd wanna know.

Skybox :


No Skybox:

I am not sure what you are trying to explain with your images. They don't make any sense to me.
Are you implicating that without skybox, the clients heap is 19 439 objects and with skybox its 626 534 objects within 60 seconds of running? Sounds like quite a lot to me.
The skybox is just copied from salem.

I am not that familiar with the rendering of the game. But with a quick glance, I am pretty sure that renderlist is fired pretty often, even if skybox is not added to it.

I also do not think that there is any memory leak associated with it.

As I said earlier, I have not looked into the rendering system of HnH, but the skybox is the same way as it was done in Salem.

Perhaps you could try to say what you think that the issue is in a bit more clear manner?

[shubla]

Purus Pasta version 3.11.1 has been released!
- Major rework of PBot API
- Added customizable alarms
- Added boundingbox for dry stonewall
- Various minor fixes
- Fix scripts
--------------------
Purus Pasta botting API, also known as PBot-API or just PBot has been reworked a lot! Most of old scripts probably don't work anymore, and must be recoded. Which should be quite easy with the new API!
Changes:
First of all, Nashorn was deprecated and has now been replaced with GraalVM. GraalVM supports much newer version of ECMAScript and is not deprecated.
Currently PBot officially supports only Graal.js, which is a ECMAScript 2017 compliant JavaScript implementation, so all Javascript functions should work.
GraalVM also provides support for many other languages, such as R, Ruby, Python, even C++ and other LLVM-languages. But the support for them is still early in the development and I am not planning on explicitly adding any of these to Purus Pasta.

Many functions have been modified or completely removed, some have been added, and overall structure of the API has been improved.
If you want to suggest features or other changes to the API, please come to Purus Pasta discord channel for easier messaging.

New pathfinder should be more reliable than the old, but it marks tiles with any hitbox in them as inaccessible. So you must design your setups properly so the pathfinder can pathfind in them.

Current issues:
Currently graalvm does not support multithreading, so if you click a button in PBotWindow while the javascript is already running, it will crash.
Thus you cannot stop your scripts at all by clicking the button while they are running for example. May fix if I come up with some good solution to this issue.

If you have any suggestions about how the API could be improved, for example, some functions to add, please tell at the Purus Pasta discord server!

[ffsfiftyseven]

First of all, Nashorn was deprecated and has now been replaced with GraalVM. GraalVM supports much newer version of ECMAScript and is not deprecated.

thank you so much

[Armis]

Thus you cannot stop your scripts at all by clicking the button while they are running for example. May fix if I come up with some good solution to this issue.

if (aboutToCrash){
dont();
}

[shubla]

Thus you cannot stop your scripts at all by clicking the button while they are running for example. May fix if I come up with some good solution to this issue.

if (aboutToCrash){
dont();
}

You can kind of do that already.

[LostJustice]

Current issues:
Currently graalvm does not support multithreading, so if you click a button in PBotWindow while the javascript is already running, it will crash.
Thus you cannot stop your scripts at all by clicking the button while they are running for example. May fix if I come up with some good solution to this issue.

If you have any suggestions about how the API could be improved, for example, some functions to add, please tell at the Purus Pasta discord server!

It does support multithreading. You start the thread on the java side and use the java implementation of it. Issue why it crashes it because you are not creating handling or scheduling for activating the button during the click event. Create thread -> Thread does the actual button click -> schedule and start thread.

[ffsfiftyseven]

It does support multithreading. You start the thread on the java side and use the java implementation of it. Issue why it crashes it because you are not creating handling or scheduling for activating the button during the click event. Create thread -> Thread does the actual button click -> schedule and start thread.

GraalVM enforces the "one thread per js runtime" rule. If you synchronize concurrent access to runtime between threads you will end up with runtime locked in the loop, without a way to access it from another thread and flip the switch stopping the loop.

[shubla]

Current issues:
Currently graalvm does not support multithreading, so if you click a button in PBotWindow while the javascript is already running, it will crash.
Thus you cannot stop your scripts at all by clicking the button while they are running for example. May fix if I come up with some good solution to this issue.

If you have any suggestions about how the API could be improved, for example, some functions to add, please tell at the Purus Pasta discord server!

It does support multithreading. You start the thread on the java side and use the java implementation of it. Issue why it crashes it because you are not creating handling or scheduling for activating the button during the click event. Create thread -> Thread does the actual button click -> schedule and start thread.

You don't understand what I meant.
The issue is that if there is a script running, there is no way of calling function from that script instance. For example, by pressing a button in the client gui. With nashorn this was possible. Yeah there are some stupid workarounds, but they are rather ugly.
Example of how you could do in nashorn:
Run a script, have a button, and when you press the button, it executes a function from the script, changing state of the instance while it is running. Quite handy for stop buttons etc. I guess? Of course, there are possible concurrency issues, but who cares about those 8)
I don't know how other people use the API themselves, like if they used this feature or not.

[Granger]

Why do you push an update that breaks functionality?

[shubla]

Why do you push an update that breaks functionality?

Because I personally didn't have issues with that functionality being removed. And no one has really complained yet that they were using it.
Nashorn didn't support new and cool things from newest ECMAScript standards. So it had to go.
Not worth it using Nashorn for some odd functionality that maybe somebody sometimes uses, which is very thread unsafe anyway.
If you used this functionality and want it back, perhaps we can discuss about possible ways of replacing it with something.