Descriptive Problem Summary:
See Title.
Numbered Steps to Reproduce Problem:
Flick an icon state, then change client.pixel_x or client.pixel_y.
It's a visual problem. See this demo on the problem. Moveshake enabled causes client.pixel_x to change from 1 to 0 every step. I put a delay before changing pixel_x to show that it does start flicking.
Double click the steering wheel to drive the boat.
Moving the boat causes the turfs under it to flick their wave state.
Expected Results:
The water flick()s the whole way through.
Actual Results:
With moveshake off, it works.
With moveshake on, the waves disappear and the flick stops.
Does the problem occur:
Every time? Or how often? Every time
In other games? N/A
In other user accounts? yus
On other computers? yus
When does the problem NOT occur?
When not changing client.pixel_x/y.
Workarounds:
None that I know of.
ID:77111
 Jul 21 2009, 8:08 pm
|
|||||||||||
| |||||||||||
From what I can tell somewhere between then and 475 this bug has been fixed.
| |
It's not completely fixed. What happened is that in an earlier release, we changed how the server decides to choose the border regions that it will send to the client. If these have to be reset, it resets the turf flicks; but in newer versions this doesn't have to be reset nearly as often. Eventually I'd like turf flicks not to reset in these instances, but it's kind of tricky, so I'm leaving this open for future reference.
| |
Generally speaking a change to pixel offsets should not affect flicks, so about the only thing I can think of is that the client's turf map is being cleared to make room for the extra scrolling borders required. If that's the case, it's hard to say how easy this will be to fix. But keep in mind I can only go by this assumption as to the cause, so source code would be helpful. In general when you post demos with bug reports it's better to include source code when at all possible.