Threads question regarding onMessage, onLoop, onPaint, etc.

[yfoo]

Do the methods onMessage, onLoop, and onPaint execute on seperate threads? If I call do something in onMessage that interacts with runescape (such as drinking an overload when the overload depelation message appears) will it work as if it was called in onLoop?

[Team Cape]

Just set a boolean in onMessage() that signals you to drink an overload, if you want to do it that way. Once you've had the overload or can't drink anymore, then just set the boolean to false.

Realistically though, you can just check the dynamic levels of your strength/attack/defense, and if they're not significantly higher than your static level, then you drink the overload

[battleguard]

on the repaint does run in a seperate thread and should not be used for state logic because it does not run with certain command line arguments that reduce cpu load.

[dreameo]

7 hours ago, PayPalMeRSGP said:

Do the methods onMessage, onLoop, and onPaint execute on seperate threads? If I call do something in onMessage that interacts with runescape (such as drinking an overload when the overload depelation message appears) will it work as if it was called in onLoop?

They all most likely do. However, an easy way to test is to set your onLoop to return a very large value. Then in any of these methods, have it do some action. If it performs the action while onLoop is still waiting to execute, then the methods are executing on a separate thread. 

You can also try playing with 

Thread.activeCount()

 

[FrostBug]

I believe onMessage is executed by the same Script Executor thread that calls onLoop, being invoked by the ScriptExecutor inbetween calls to onLoop.
This will mean that time spent interacting in onMessage will further delay the next call to onLoop, which you most probably don't want.

[Zach]

2 hours ago, FrostBug said:

I believe onMessage is executed by the same Script Executor thread that calls onLoop, being invoked by the ScriptExecutor inbetween calls to onLoop.
This will mean that time spent interacting in onMessage will further delay the next call to onLoop, which you most probably don't want.

I gradually and silently changed that; such that by end of Nov 2017 (and this is how it should be currently):

-Message, config, login code listeners execute on a single "listeners" thread. This checks for changes approximately every 100ms.

-Audio listeners execute directly on the game thread. Next few updates may see audio listeners also moved to that listeners thread mentioned above. We initially hesitated on this due to the potential response times required. But I think we can compensate by lowering the time between checks.

[Butters]

Thanks for the answer.

Dunno if the place to mention this, but exactly at the end of November one of my scripts started failing to get info from message and login code listeners (was working fine until then). I don't think that any other users reported anything similar. Tried debugging a lot but couldn't find the issue.

[Zach]

1 minute ago, nosepicker said:

Thanks for the answer.

Dunno if the place to mention this, but exactly at the end of November one of my scripts started failing to get info from message and login code listeners (was working fine until then). I don't think that any other users reported anything similar. Tried debugging a lot but couldn't find the issue.

Do you remember what the problem was or if it was resolved? I didn't receive any other reports about it either.

[Butters]

14 minutes ago, Zach said:

Do you remember what the problem was or if it was resolved? I didn't receive any other reports about it either.

Started with this release

Short description:

After running the script for about 30~ minutes onMessage() method doesn't fire at all (doesn't catch any new in game messages). Verified this by adding log() call on each call to onMessage().

Additionally, have a custom login handler implemented to track bans. Once onMessage() starts failing - login code listener also stops working.

Failed to find what my script does specifically so that listeners start failing.

Other scripts work fine.

Any way to maybe restart the listener thread?