Descriptive Problem Summary:
Editing the overlays of an atom before / after using a flick() causes the game to wait for the flick() to complete before making the overlay change (for clients atleast).
Numbered Steps to Reproduce Problem:
Code Snippet to Reproduce Problem:
https://dl.dropboxusercontent.com/u/107028026/ShareX/2015/ 11/overlay-flick.zip
Download, compile, run, then click on the machine in the middle.
As you can see, the starting animation plays (although the overlay is added before the flick(), which is example of this bug #1)
I cut off half of the animated overlay, to make it visible that the animated overlay remains even while the flick() for the end state is happening.
Expected Results:
Overlays to be added / removed to / from atoms without waiting on the flick().
Actual Results:
The game waits on the flick() before the overlay change happens.
Does the problem occur:
Every time? Or how often? Every time
In other games? N/A
In other user accounts? Yes
On other computers? Yes
When does the problem NOT occur?
Using a sleep with a value bigger than 0 between editing the overlays and using the flick() call, however this is visible to players.
Did the problem NOT occur in any earlier versions? If so, what was the last version that worked?
Bug is reproducible on 500.1213, not really gonna bother going lower.
Workarounds:
None that I know of, I have tried sleep(-1) or sleep(0) between the overlay change and the flick(), cutting the overlays list before the flick(), moving the flick() around, but no solution other than a noticable sleep(>0).
ID:1981629
 Nov 13 2015, 8:40 am (Edited on Nov 13 2015, 11:31 am)
|
|||||||||||||
Resolved
| |||||||||||||
|
Nov 13 2015, 11:16 am
|
|
Lummox JR
  |
Lummox JR resolved issue (Not a bug)
|
This is intentional behavior with flicks.
| |
This seems very weird behaviour if this is not a bug, it sure as hell isn't mentioned in the BYOND reference.
How should you go about making the example in that code I provided then? | |
lummox, I highly doubt overlay changes being made before the flick being delayed until after the flick is intentional.
| |
I can see it being intentional if the overlay change is being made after the flick(), but definetly not before.
To put it rudely: you just skimmed over the report, didn't you? | |
MrStonedOne wrote:
lummox, I highly doubt overlay changes being made before the flick being delayed until after the flick is intentional. Lummox, just out of curiosity why do you consider this intended behavior? Is it a limitation? Surely this isn't the desired effect. | |
Lummox JR changed status to 'Open'
| |
I did miss the "before" part, yes. After is definitely not a bug; that's fully intended.
If the change you made was just before the flick, I can see why that might be happening: the appearance hasn't had a chance to update on the client end yet when the flick is applied. | |
Yes it was JUST before the flick()
| |
Lummox JR resolved issue with message:
Overlays changed immediately before a flick() sometimes didn't register, depending on timing. (This fix affects both the client and server.) | |