Purus Pasta Client [W14 COMPATIBLE]

[ffsfiftyseven]

If you used this functionality and want it back, perhaps we can discuss about possible ways of replacing it with something.

Adding a button near every script in the list to stop it's thread?
Easier(?) take: one button in the scriptlist window to stop all running script threads.
I think we only used missing functionality to stop our scripts anyway.

[shubla]

If you used this functionality and want it back, perhaps we can discuss about possible ways of replacing it with something.

Adding a button near every script in the list to stop it's thread?
Easier(?) take: one button in the scriptlist window to stop all running script threads.
I think we only used missing functionality to stop our scripts anyway.

Just forcing threads to stop like that is not very good idea.

[Granger]

If you used this functionality and want it back, perhaps we can discuss about possible ways of replacing it with something.

Adding a button near every script in the list to stop it's thread?
Easier(?) take: one button in the scriptlist window to stop all running script threads.
I think we only used missing functionality to stop our scripts anyway.

Just forcing threads to stop like that is not very good idea.

You should be able to raise an exception inside the thread, IIRC.

[LostJustice]

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.

It a port over from java you can create variables on the java side that are threads extends your “one” thread and interacts with these threads. So still not convinced. Using proper thread access you wouldn’t need to synchronize for most situations and not sure why you would for a scripting api.

[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.

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.

Yes you would build a controller on the java side to handle the script changes and plugin threads and then when you want to change the state you call hose methods to handle it. You do not handle the threads and ect on the js side. Rather build a clever way to create and manage your own threads in java on that side that is api calls for the js.

[shubla]

Yes you would build a controller on the java side to handle the script changes and plugin threads and then when you want to change the state you call hose methods to handle it. You do not handle the threads and ect on the js side. Rather build a clever way to create and manage your own threads in java on that side that is api calls for the js.

Yeah but I think it would be rather ugly. I'd rather not have something like that.
Especially as there is really no demand for it.
You can still interact with running script via gui labels, text fields etc., just not invoke functions from it.

[Granger]

Yes you would build a controller on the java side to handle the script changes and plugin threads and then when you want to change the state you call hose methods to handle it. You do not handle the threads and ect on the js side. Rather build a clever way to create and manage your own threads in java on that side that is api calls for the js.

Yeah but I think it would be rather ugly. I'd rather not have something like that.
Especially as there is really no demand for it.
You can still interact with running script via gui labels, text fields etc., just not invoke functions from it.

The ability to terminate a running script from the UI (even, and especially, in case of it being uncooperative) is a basic need.

[shubla]

Yes you would build a controller on the java side to handle the script changes and plugin threads and then when you want to change the state you call hose methods to handle it. You do not handle the threads and ect on the js side. Rather build a clever way to create and manage your own threads in java on that side that is api calls for the js.

Yeah but I think it would be rather ugly. I'd rather not have something like that.
Especially as there is really no demand for it.
You can still interact with running script via gui labels, text fields etc., just not invoke functions from it.

The ability to terminate a running script from the UI (even, and especially, in case of it being uncooperative) is a basic need.

I am not sure if the solution was presented here, but you can close the window in client, and then check if it has been closed in the script and then stop the script if it has been closed.
And that works quite well I think.

[shubla]

Purus Pasta version 3.12.0 has been released!
- Added more FEP info to foods
- Added some PBot functions
- Re-implemented PBot destroyer
- Re-implemented PBot farmer
- Fixed defaultalarm config
- Mirrored everything
- Various minor bugfixes

[erzh1987]

And how i must use this *** mirrored client?! THANKS A LOT. DELETE PP