Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

after splitting and super large mouse and keyboard input stops working #19

Open
mrblah1 opened this issue Jul 13, 2015 · 6 comments
Open
Labels

Comments

@mrblah1
Copy link

mrblah1 commented Jul 13, 2015

I noticed after becoming super large, 2000-4000+ mass and splitting, the input from the mouse and keyboard will sometimes stop working, it probably happens every 1 out of 10 splits. I will often get to the #1 spot and then lose control of my bubble and run into a virus and explode and suddenly it's all over, very frustrating.

It only happens when split and happens whether the feeder bot is turned on or off. While in the no control situation hitting G still shows the large square indicating the bot is active but it simply does not move and no keyboard or mouse inputs will work, the bubble simply continues in whatever direction it was previously moving and I can see other bubbles moving around changing direction so it's not a lag or disconnect issue. Hitting G to deactivate the bot still does not allow mouse or keyboard control, it's only when the bubbles rejoin that control starts working again. I tried disabling the bot script and tried using other bots and could not reproduce this issue so it seems exclusive to this bot.

@RealDebugMonkey
Copy link
Owner

When you hit the 'space' bar are you by chance also accidentally hitting 'm' to turn off mouse control? That's what it sounds like
Maybe i should change that 'M' key to use a modifier.

@Piehthyte
Copy link

It may be on agar.io side that causes the issue to not be able to use your mouse once you split. I have never been bigger than 900 mass but there may be some memory issues when you get that large.

@mrblah1
Copy link
Author

mrblah1 commented Jul 13, 2015

It's not from hitting m because if i just wait until the bubbles rejoin everything works again. I was 7,000 mass earlier with a different script albeit in Firefox and had no issues splitting. I'll try the other script in chrome to see if it's a chrome issue. I love how this script gives jump distances and changes the other bubbles colors based on mass it's an amazing tool but the glitch guarantees eventual death :(

On Jul 13, 2015, at 6:15 PM, Piehthyte [email protected] wrote:

It may be on agar.io side that causes the issue to not be able to use your mouse once you split. I have never been bigger than 900 mass but there may be some memory issues when you get that large.


Reply to this email directly or view it on GitHub.

@RealDebugMonkey
Copy link
Owner

After re-reading the description it would seem that accidentally pressing 'M' is not the cause, as that leads to the cell stopping movement fairly rapidly.

The fact that you regain control once the cells merge indicates that the problem is server side and not with the script.

Technical Explanation: If you stop sending mouse update packets. Your blob will continue moving until it reaches the x/y coordinates indicated by the last packet sent and then just stop. You can test this yourself by zooming out, pointing your mouse at a point so the blob starts moving, then pressing M to disable mouse updates.

Also, if you look at the code you will see that when either of the grazers is activated the normal mouse position packets are all bypassed as the grazers have their own custom function to send mouse position. So if the grazer is enabled it will definitely be sending out position updates

Does the blob keep moving indefinitely until you remerge, or does it eventually stop and just stay still until you remerge?

@RealDebugMonkey
Copy link
Owner

There is a chance that by turning on the new 'Click to lock blob' option this issue might get fixed.

Why? Because before this feature was added all movement directions to the server were sent with 'target' set to '0' which basically means "all my blobs should respond to this command"

When you enable the 'Click to lock blob' option we send separate move commands for every single one of your blobs by specifying it's ID as the target.

Would you mind trying it out and seeing if this helps? you don't have to even click ... just enable the option.

@posixphreak
Copy link
Contributor

I have the same bug as well but without any deterministic way to reproduce the issue, it just happens randomly. Maybe you could suggest a way to debug the issue, as I can't think of any. And unfortunately Click to lock has no effect.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants