more weird bounds behavior in Bug Reports
|
|
Resolved
|
If an obj or mob had its overlays (or other appearance-related information) temporarily changed and sent to output or stat(), then changed back, the client was not informed of the change back and kept the temporarily altered appearance instead.
|
| BYOND Version: | 494 |
| Operating System: | Windows 7 Pro |
| Web Browser: | Chrome 19.0.1084.46 |
| Applies to: | Dream Daemon |
|
| Status: |
Resolved (495)
This issue has been resolved.
|
|
|
Descriptive Problem Summary:
Here is some very very strange behavior with bounds() proc. If the client view is within sight of the big mob, the big mob will not receive an overlay. If the client view is within a tile or two of the big mob but still can't see the big mob, the big mob's bounds check output will contain some empty turfs (missing a name?). I suspect this is the optimization byond makes with map scrolling in some way. At any rate, if you manage to catch a glimpse of him just after this happens, the overlay will be visible for a short period of time (just before Entered() is called again?)
Check the source project:
http://www.joeysturgis.com/boundsbug_src.zip
|
Basically, you're removing overlays on Exited() and adding them on Entered(), and this is happening without pixel movement so Exited() is always being called first. When the big mob is not moving diagonally, it exits two turfs and enters two turfs. The overlay is added during the first enter, but after you print the mob to the output control.
The process of sending the mob to the output control sends its current appearance as well--which as of that time, has no overlay. By the time the mob actually moves, it has one. The server routine that sends the mob info to you looks to see what the mob's appearance was the last time the map was sent--which is the same as it is now, with an overlay. As a result the server does not send an update for this mob until it changes directions, or is first coming into view. Meanwhile the client has received an update--from your output, back when the mob had no overlays. Since it hasn't been told differently, it assumes the mob still has none.
Obviously this is unlikely to come up much, but it could have an impact if overlays are fiddled with during stat() or such. It's a rare case, but it'll be fixed in the next version.