Latest client update has broke scripts

[ZNkr534 1]

Only script I use is SubCZ Zulrah and it will no longer work since latest update of dreambot client according to devs - 

please fix

[Pandemic 2721]

We've only received one report yesterday about that, and it should be working again on 3.19.5 as we've re-allowed the invalid/incorrect mouse events that he's using in his scripts.

The person who reported it tested it and said it was "working 100%", so I'd try that first. If it's still not working after that we'd need more information, or he'll need to update his custom mouse to send proper and valid events to the canvas.

Hope that helps!

[hydroix 1]

Hi

Seems to be working now. Thanks!

[hydroix 1]

Way more deaths/hr since update though..

 

[SubCZ 282]

4 hours ago, Pandemic said:

We've only received one report yesterday about that, and it should be working again on 3.19.5 as we've re-allowed the invalid/incorrect mouse events that he's using in his scripts.

The person who reported it tested it and said it was "working 100%", so I'd try that first. If it's still not working after that we'd need more information, or he'll need to update his custom mouse to send proper and valid events to the canvas.

 

The script only uses DreamBot's API methods to send mouse events. You know this because you have access to the script's code. Perhaps DreamBot should have fixed the "invalid/incorrect" mouse events in its API instead of reallowing them? 

It's unfortunate that many users lost more than 2 days of runtime, and that no responsibility is taken by DreamBot developers. It makes it seem likely that these issues will continue in the future.

[Pandemic 2721]

24 minutes ago, SubCZ said:

The script only uses DreamBot's API methods to send mouse events. You know this because you have access to the script's code. Perhaps DreamBot should have fixed the "invalid/incorrect" mouse events in its API instead of reallowing them? 

It's unfortunate that many users lost more than 2 days of runtime, and that no responsibility is taken by DreamBot developers. It makes it seem likely that these issues will continue in the future.

Your invalid events (sent by calling Mouse#hop while inside the polling condition of Mouse#mouseDownUntil, which is not standard API usage at all) are now being corrected for you.

We had an update out within an hour of the only bug report we received regarding this issue as it only affected your scripts.

[SubCZ 282]

2 minutes ago, Pandemic said:

Your invalid events (sent by calling Mouse#hop while inside the polling condition of Mouse#mouseDownUntil, which is not standard API usage at all) are now being corrected for you.

We had an update out within an hour of the only bug report we received regarding this issue as it only affected your scripts.

1) Mouse movement in the polling condition of Mouse#mouseDownUntil was DreamBot's recommended way to handle drag clicks since DB2, as you can see from threads on this forum. Claiming this is "non standard" is misleading at best.

2) Breaking functionality that existed for over a year, without warning or prior testing, only hurts the users of DreamBot. You're not correcting invalid events "for me", you're correcting for a faulty update that broke a product users paid for. In the end, I'm not affected by untested updates, DreamBot's users are.

[Pandemic 2721]

35 minutes ago, SubCZ said:

1) Mouse movement in the polling condition of Mouse#mouseDownUntil was DreamBot's recommended way to handle drag clicks since DB2, as you can see from threads on this forum. Claiming this is "non standard" is misleading at best.

2) Breaking functionality that existed for over a year, without warning or prior testing, only hurts the users of DreamBot. You're not correcting invalid events "for me", you're correcting for a faulty update that broke a product users paid for. In the end, I'm not affected by untested updates, DreamBot's users are.

1) I'm unsure where you're seeing that, I'd love to see those threads. We've had Mouse#drag since 2015, and Mouse#hop has never supported sending MOUSE_DRAGGED events until a couple client updates ago (which is why you couldn't use it with mouse camera rotates).

2) We can't test every possible combination of API (and/or non-API) calls during our tests, it's not feasible. We rely on bug reports to know if something custom isn't working anymore. We never try to break existing functionality without prior notice (@Deprecated, threads, etc.), but it can happen as people can do just about anything with the API and Java.

[SubCZ 282]

3 minutes ago, Pandemic said:

1) I'm unsure where you're seeing that, I'd love to see those threads. We've had Mouse#drag since 2015, and Mouse#hop has never supported sending MOUSE_DRAGGED events until a couple client updates ago (which is why you couldn't use it with mouse camera rotates).

2) We can't test every possible combination of API (and/or non-API) calls during our tests, it's not feasible. We rely on bug reports to know if something custom isn't working anymore. We never try to break existing functionality without prior notice (@Deprecated, threads, etc.), but it can happen as people can do just about anything with the API and Java.

Mouse#drag did not support custom mouse movement until 2022 (as you know). The solution provided by DreamBot developers was the one used in my scripts.

This is not the complex problem that you're making it out to be. It would be straightforward to release a test build or to run some of the most popular scripts on the SDN before releasing a major update (like mouse movement). You have access to all scripts. This is not being done due to a lack of effort. Its easier to break scripts and have users find the errors, even if it hurts their experience, than giving scripters the time to test updates or testing them yourself. If this is DreamBot's decision, the least users can expect is to not be misled about it. 

[Pandemic 2721]

4 minutes ago, SubCZ said:

Mouse#drag did not support custom mouse movement until 2022 (as you know). The solution provided by DreamBot developers was the one used in my scripts.

This is not the complex problem that you're making it out to be. It would be straightforward to release a test build or to run some of the most popular scripts on the SDN before releasing a major update (like mouse movement). You have access to all scripts. This is not being done due to a lack of effort. Its easier to break scripts and have users find the errors, even if it hurts their experience, than giving scripters the time to test updates or testing them yourself. If this is DreamBot's decision, the least users can expect is to not be misled about it. 

I'm still unsure where you're getting this from, I've searched the forums and Google and can't find anyone suggesting that combination of API calls.

As you are well aware test builds are never actually tested against by scripters (remember that walker alpha that was out for over 6 months with a total of two bug reports?), we've learned that lesson and instead prefer to test it as well as we can using our standard methods. If any customized use cases are broken by an update unintentionally, we do our best to promptly fix any reported issues. If you refuse to report issues to us and force your own users to come tell us (which they rarely do, and even if they do they don't know the code that's broken), how would we know that we've broken anything?

But I've already explained this to you multiple times, and I'm tired of repeating myself. I'm just going to lock this thread now, feel free to PM me if you have anything else you'd like to say or post any bug reports in our bugs channel if you'd like anything fixed on our end.