ID:65441
 
Resolved
Fixed in 447
BYOND Version:440
Operating System:Windows XP Home
Web Browser:
Status: Resolved (447)

This issue has been resolved.
Duplicates:id:69423, id:72942
Descriptive Problem Summary:
Icons with movies that are set to loop only once will indeed loop only once.. per session.

Numbered Steps to Reproduce Problem:
1. Create an icon with a movie state; set it to loop only once.
2. Now create an object at runtime with that icon. It will play the animation once as it should.
3. Delete that object and create a new one. Any new objects after the first will not animate even once.

Code Snippet (if applicable) to Reproduce Problem:
mob/verb/test()
var/obj/O = new(loc)
sleep(50)
del O

obj/icon = 'oneloop.dmi'


Expected Results:
Each new object should play its animation once upon being created.

Actual Results:
The first object created animates once. Others do not animate at all.

Does the problem occur:
Every time? Or how often? at least 90% of the time
In other games? yes
On other computers? yes
In other user accounts? yes

When does the problem NOT occur?
Very rarely. Sometimes if you create another object before the first one is deleted, it will work, but even this is unreliable.

Workarounds:
Nothing reliable I've found. It even occurs if the icon is added to the client's screen rather than directly on the map.

Followup:
I do have one more tidbit of info if it helps. I noticed if you output a reference to the obj like so...

mob/verb/test()
var/obj/O = new(loc)
world << "\ref[O]"
sleep(50)
del O

obj/icon = 'oneloop.dmi'


...you will see that whenever the same internal ID is used, the icon fails to animate. I tried setting a unique tag to each new obj, but that had no effect. The problem must be an internal one.

I welcome any suggestions for a workaround as I've still yet to find one.
Confirmed in BYOND 440.1018 on Windows XP Home SP3.

When an atom is used to display an animation set to play for a set number of times and it is deleted, if its reference ID is reused by an atom of the same type and set to play the same animation, the play count will not be reset, and the animation will not play [if the count has already been reached].
I have verified that there is a problem with recycled objects not resetting their creation times in order to properly display an animation loop. This actually has a bearing on some other deferred bugs as well.

For a future release I have a plan for dealing with this issue by giving the client better info as to whether an object ID has been recycled.
New info sent from the server to the client in 447 fixes this bug. A 447 server may well be enough to do it, but running a client on 447 or higher will have optimal results.