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

Freeze and eventually crash when "There is no way." #840

Open
Steini64 opened this issue May 5, 2017 · 4 comments
Open

Freeze and eventually crash when "There is no way." #840

Steini64 opened this issue May 5, 2017 · 4 comments
Labels

Comments

@Steini64
Copy link

Steini64 commented May 5, 2017

Steps to reproduce (include any configuration/script required to reproduce)

  1. Click on any unreachable tile (for example house) or island with no walkable way fast / multiple times. When it displays "there is no way" the client heavily freezes and sometimes even crashes when you keep spamming leftclick on that tile.

Environment

OS: Windows 10
Protocolversion in use: 10.77
I use a mostly unmodified, default code (maybe two months old) with slight, for this bug non-relevant changes.

The only relevant change applied to the code is the Idle-walkanimation fix for Protocolversion >= 10.10
@see #642

@iryont iryont added the Rework label May 6, 2017
@iryont
Copy link
Collaborator

iryont commented May 6, 2017

It happens because A* algorithm tries to calculate the path until it hits the limit. In general it is not a bug, but since those calculations are quite heavy it takes a while for A* to come up with a result.

The general fix to parallelize A* calculations is not a trivial task. I will leave it open until someone rewrites it though.

@Steini64
Copy link
Author

Steini64 commented May 6, 2017

Hmm that makes sense, thats for the explanation!

I have another idea, wouldn't it help to write a handler that only permits one A* Calculation at a time and other attemts will be rejected or better said the action will be canceled? (Similar to the next-action-delay in the server)?

The calculation goes afaik only for the path-find of the own player when you click somewhere on the map right? So there is maybe no need for full asynchronous execution / handling because you have no use of multiple paths at the same time anyway. You can only follow one path at once.

I will try what I can accomplish and eventually contribute my results later.

@gesior
Copy link
Contributor

gesior commented May 15, 2017

@iryont

  1. Why A* executes so long? On server it executes findPath very often and it all goes in main thread of server without any lag.
    Is it because there are black tiles and A* search until limit of complexity?
    Maybe some 'check % of black tiles in square fromPos to toPos and reduce maximum complexity' hack would work?

  2. Why client freezes? Is it because GUI somehow queue mouse clicks or 'findPath' calls while other 'findPath' is running? Is client freezed for time of execution of findPath?
    Maybe there is a way to detect these multiple calls and show some message in client, not call findPath so often?


Question to some pro: Is GUI (LUA) in other thread then 'findPath' calls?

@iryont
Copy link
Collaborator

iryont commented May 16, 2017

Game server does calculate the path within the creature view only, so it is hardly a demanding task. However, in the game client we do calculate a lot more outside the visible rectangle. The growth of tiles is exponential, so it becomes a problem.

The only reason we do calculate path beyond visible rectangle is to know whether the path is findable in the first place. The game client doesn't use all of those calculated tiles later on, in fact, it discards every tile beyond visible rectangle or it limits them to 127 tiles if those tiles were seen before and it calculates the path again with the same mechanism over and over again until we hit the destination.

The game client is frozen until the calculations are complete.

I suppose a few tricks would be enough to make it work much better, but I haven't thought about it yet.

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

3 participants