Cannot decompile 2: the Ichthyoquel

    Logging in with you Steam ID has now been restored ♥

    • Cannot decompile 2: the Ichthyoquel

      Creating a new thread instead of necroing another. Click here for the first thread.
      I am attempting to modify the Ichthyosaur's model, but after recompiling I am left with this:



      I have (more than sorta) determined that this is caused by the animations breaking upon being decompiled. I've searched high and low for an answer, and I have found that this is a relatively unknown issue, but nobody has yet figured out an answer (apart from remaking the animations themselves).

      Just as before, the model was modified in Blender, and Crowbar was used to decompile and recompile the model in question.

      As far as I know, this only applies to npc models that have existed since the mod version, and therefore may be caused by the models being manufactured with an old toolset/workflow unique to Black Mesa during it development as a mod.

      It should be noted that this effect still applies even before modifying the .smd in Blender [read: decompiling and recompiling the model only], which seems to support the theory above.

      AnyACTUAL help would be appreciated.

      Grubert wrote:

      Why is it holding a banana!?
    • First, I'm by no means an expert, but from what I can tell, Crowbar doesn't handle delta animations very well. If you look in the .QC file, you'll find these $animation definitions:

      Source Code

      1. $Animation "a_swimright" "ichthyosaur_anims\a_swimright.smd" {
      2. fps 30
      3. // This subtract line guesses the animation name and frame index. There is no way to determine which $animation and which frame was used. Change as needed.
      4. subtract "icky_delta.smd" 0
      5. }
      6. $Animation "a_swimleft" "ichthyosaur_anims\a_swimleft.smd" {
      7. fps 30
      8. // This subtract line guesses the animation name and frame index. There is no way to determine which $animation and which frame was used. Change as needed.
      9. subtract "icky_delta.smd" 0
      10. }
      11. $Animation "a_swimup" "ichthyosaur_anims\a_swimup.smd" {
      12. fps 30
      13. // This subtract line guesses the animation name and frame index. There is no way to determine which $animation and which frame was used. Change as needed.
      14. subtract "icky_delta.smd" 0
      15. }
      16. $Animation "a_swimdown" "ichthyosaur_anims\a_swimdown.smd" {
      17. fps 30
      18. // This subtract line guesses the animation name and frame index. There is no way to determine which $animation and which frame was used. Change as needed.
      19. subtract "icky_delta.smd" 0
      20. }
      Display All

      What happens here is that the "subtract" lines will subtract the animation in the icky_delta.smd, which contains a reference pose, from the "a_swimright", "a_swimleft", "a_swimup" and "a_swimdown" animations, thus creating deltas for these animations. However, the "a_swimright.smd", "a_swimleft.smd", "a_swimup.smd" and "a_swimdown.smd" files already contain the delta animations, which means the reference pose is being subtracted twice from the original animations!

      Further down, the $sequence definitions that reference these animations also contain subtract commands:

      Source Code

      1. $Sequence "side_to_side" {
      2. "a_swimright"
      3. "a_swimleft"
      4. autoplay
      5. blend "sidetoside" -90 90
      6. blendwidth 2
      7. delta
      8. fadein 0.2
      9. fadeout 0.2
      10. hidden
      11. fps 30
      12. // This subtract line guesses the animation name and frame index. There is no way to determine which $animation and which frame was used. Change as needed.
      13. subtract "icky_delta.smd" 0
      14. }
      15. $Sequence "up_and_down" {
      16. "a_swimup"
      17. "a_swimdown"
      18. autoplay
      19. blend "upanddown" -90 90
      20. blendwidth 2
      21. delta
      22. fadein 0.2
      23. fadeout 0.2
      24. hidden
      25. fps 30
      26. // This subtract line guesses the animation name and frame index. There is no way to determine which $animation and which frame was used. Change as needed.
      27. subtract "icky_delta.smd" 0
      28. }
      Display All
      I'm not sure if the "subtract" commands here have any effect. The $sequence page on the VDC wiki doesn't mention the "subtract" command as being a valid command in a $sequence definition block. In any case, it doesn't make any sense to include them here since they have already been included in the respective $animation definition blocks.

      Crowbar has however correctly inserted the "delta" command in these blocks which states that the referenced animations contain animations that have been subtracted (delta animations), and that these sequences are meant to be played on top of whatever sequence(s) that are currently being played.

      TLDR;

      The solution is to delete (or comment out) all the "subtract" lines from the .QC file.

      I've confirmed that this solves the problem, at least for viewing in HLMV. I haven't tested if it works correctly in-game.

      Another solution would be to numerically add the animation data in "icky_delta.smd" file to the animation data in "a_swimright.smd", "a_swimleft.smd", "a_swimup.smd" and "a_swimdown.smd" files, and keep the "subtract" commands in their respective $animation definition blocks. But I think you would have to write a script or a program to do that.

      A third solution would of course be to recreate the "a_swimright", "a_swimleft", "a_swimup" and "a_swimdown" animations from scratch, using "icky_delta.smd" as the starting point for the animations.
      Files