 |
Related to 1796 ? |
 |
Possibly. My theory is that either at the start of the weapon's "drop", or on its way down, it hits something and stops. Since it never continues the drop at a future time, whatever it hit stays there. An errant clipmodel could do this. Also, whatever it hit is invisible, and that also suggests a clipmodel. |
|
|
At spawn time, map items marked ‘dropToFloor = true’ will drop straight to the floor (or surface) beneath them. Attachments are also marked this way, so when they are freed from a knocked out or killed AI, they go immediately to the floor. Testing where the floor is starts with a test to see if the attachment origin is in a solid, probably to handle the case where the mapper sank the item slightly into what it was sitting on. If the origin of the dropped attachment is inside the dropping AI at the moment this ‘in solid?’ test is made, the attachment comes to rest immediately, leaving it hanging in the air. The fix is to mark an attachment as ‘dropping’ when it’s released from a knocked out or killed AI, and to not try to force it to the floor immediately. Physics then takes over and the attachment falls naturally. |
 |
Wow, you mean this is fixable?? I thought this was one of those bugs we'd have to live with until the source was released. :O |
|
|
Yup, fixed. Will be in 1.05. |
 |
Good find. They were supposed to just release and activate physics from their current position. I didn't realize they were flagged "drop to floor," and I've never seen them teleport straight down to the floor like other things flagged "drop to floor," but if un-setting it fixes this issue, that's great! |
|
|
I revisited the "teleport" situation because I didn't remember seeing instant appearance of the weapon on the ground. What's happening is that an attachment dropped by a knocked out or killed AI is marked "dropToFloor", so the first check is to see if it's in a solid. Since the attachment's origin is still in the AI's hand, it's in a solid, so it comes to rest immediately in mid-air. No instant translation to the floor. The "dropToFloor" flag is turned off, since its job is done. A subsequent collision (most likely with the same AI as it falls) dislodges the attachment from the "at rest" state and allows physics to take over. The attachment then falls naturally. When a subsequent collision doesn't take place (the AI misses the resting attachment as the AI goes down), the attachment continues to rest in mid-air. The solution is the same: pay no attention to the "dropToFloor" flag if you're an attachment dropped by a knocked out or killed AI. This skips the initial mid-air rest and allows physics to have its way immediately. |
|
|
Rev. 4627: physics_rigidbody.cpp ai.cpp physics_af.cpp afentity.cpp entity.cpp entity.h |
|
|
Hmm, I just had a case where I hit a sitting, card-playing guard with a gas arrow, and his row of cards stayed hovering in the air after he fell. |
|
|
I'll see if I can reproduce this. |
|
|
Verified. If I hit him from the back, he doesn't drop the cards. Debugging shows cards aren't normal attachments, so they don't go through the "drop me" code. I'll have to figure out what they are and deal with them somewhere else. |
|
|
re: The cards aren't normal attachments. They are just def_attached, the same as most weapons as far as I'm aware. |
|
|
That's what I thought. In the code that drops attachments, it goes through a list of attachments and detaches them from the AI. The cards don't show up on that list. So either they were detached earlier elsewhere, or they're kept in some other list. I've had them hover in the air in one instance, and drop into his lap in the next. It'll probably be tonight before I can get back to this. |
|
|
I filed issue 0002686 to cover this problem. The solution probably won't be the same as applied here, and probably won't be ready by 1.05 code freeze. |
- Anonymous
