View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0002557 | The Dark Mod | Coding | public | 20.01.2011 23:14 | 27.10.2011 05:20 |
Reporter | Springheel | Assigned To | greebo | ||
Priority | normal | Severity | normal | Reproducibility | have not tried |
Status | closed | Resolution | fixed | ||
Product Version | TDM 1.02 | ||||
Target Version | TDM 1.04 | Fixed in Version | TDM 1.04 | ||
Summary | 0002557: attach/destroy frame commands sometimes overlap or cause crash | ||||
Description | Edit 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 | ||||
Tags | No tags attached. | ||||
Fixed in code rev. 4512. | |
Reopen to investigate test/attach_test.map | |
Add this line to the anim in question: frame 1 object_call syncLegsWithTorso |
|
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. | |
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. |
|
I'll set this to resolved and transfer your report to another item. | |
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 |