View Issue Details

IDProjectCategoryView StatusLast Update
0002557The Dark ModCodingpublic27.10.2011 05:20
ReporterSpringheel Assigned Togreebo  
PrioritynormalSeveritynormalReproducibilityhave not tried
Status closedResolutionfixed 
Product VersionTDM 1.02 
Target VersionTDM 1.04Fixed in VersionTDM 1.04 
Summary0002557: attach/destroy frame commands sometimes overlap or cause crash
DescriptionEdit 0000002: Ok, now I am truly puzzled. I am getting the "Attaching atdm:prop_wooden_spoon as spoon on hand_r" message twice, then the "WARNING: Cannot find attachment 'spoon01' to destroy in animation." one. But why?

the cards are being spawned but not destroyed. There are regular error messages: "cannot find attachment 'card' to destroy in animation", but no crash (at least not immediately)...the cards just keep overlapping and building up.

edit: There's another similar animation in the same map, that is giving the same error "cannot find attachment X to destroy".

http://modetwo.net/darkmod/index.php?/topic/10924-new-active-prop-playing-cards/page__view__findpost__p__215397
TagsNo tags attached.

Relationships

has duplicate 0002425 closedgreebo animation frame commands doubled or skipped 
related to 0002554 resolved Alerted archer animation is missing an arrow 
related to 0002744 resolvedgreebo Still getting "Cannot find attachment X to destroy" error 

Activities

greebo

greebo

30.01.2011 17:38

administrator   ~0003516

Fixed in code rev. 4512.
greebo

greebo

01.02.2011 06:43

administrator   ~0003523

Reopen to investigate test/attach_test.map
greebo

greebo

01.02.2011 16:15

administrator   ~0003531

Add this line to the anim in question:

frame 1 object_call syncLegsWithTorso
greebo

greebo

01.02.2011 17:40

administrator   ~0003532

Better fix in place with rev. 11534, implemented in the idle anim scripts in ai base script. The above frame command method is still available.
Springheel

Springheel

18.04.2011 17:12

administrator   ~0003808

Last edited: 18.04.2011 17:14

I'm reopening this, as I'm seeing the same behaviour with a new animation that I added. I added "frame 1 object_call syncLegsWithTorso " to it, but it still happens.

The animation is idle_eat_carrot. When I run it in a small testmap, there doesn't seem to be any problems. However, when I run it in my mission, I consistently see at least one "cannot find attachment X to destroy" error after playing around for a minute or two.

Oddly, seeing that error does not guarantee that the AI will have a carrot stuck in his hand when I get to him, as I would expect. If the code isn't destroying the carrot, it should still be there, and sometimes it's not. Don't know what to make of that.

In fact, I would say MOST of the time the AI doesn't have a carrot stuck to him after seeing that error...I was going to ignore it, actually, but last night I did see him walking around with a carrot.

greebo

greebo

29.04.2011 06:32

administrator   ~0003828

I'll set this to resolved and transfer your report to another item.

Issue History

Date Modified Username Field Change
20.01.2011 23:14 Springheel New Issue
20.01.2011 23:15 Springheel Relationship added related to 0002554
30.01.2011 17:38 greebo Assigned To => greebo
30.01.2011 17:38 greebo Status new => assigned
30.01.2011 17:38 greebo Product Version => TDM 1.02
30.01.2011 17:38 greebo Target Version => TDM 1.04
30.01.2011 17:38 greebo Note Added: 0003516
30.01.2011 17:38 greebo Status assigned => resolved
30.01.2011 17:38 greebo Fixed in Version => TDM 1.04
30.01.2011 17:38 greebo Resolution open => fixed
31.01.2011 11:43 greebo Relationship added has duplicate 0002425
01.02.2011 06:43 greebo Note Added: 0003523
01.02.2011 06:43 greebo Status resolved => feedback
01.02.2011 06:43 greebo Resolution fixed => reopened
01.02.2011 06:43 greebo Status feedback => assigned
01.02.2011 16:15 greebo Note Added: 0003531
01.02.2011 16:15 greebo Status assigned => resolved
01.02.2011 16:15 greebo Resolution reopened => fixed
01.02.2011 17:40 greebo Note Added: 0003532
18.04.2011 17:12 Springheel Note Added: 0003808
18.04.2011 17:12 Springheel Status resolved => new
18.04.2011 17:14 Springheel Note Edited: 0003808
29.04.2011 06:32 greebo Note Added: 0003828
29.04.2011 06:32 greebo Status new => resolved
29.04.2011 06:33 greebo Relationship added related to 0002744
27.10.2011 05:20 greebo Status resolved => closed