Action Sequence Rotation Extension

● ARCHIVED · READ-ONLY
Started by ATT_Turan 58 posts Page 3 of 3 View original ↗
  1. @alasth Yeah, I was able to reproduce it also, I just haven't had the time to work out what's causing it. As you say, it only happens with certain degrees of rotation, so I don't immediately know why.

    It's on my list of stuff to work on, but probably not this month.
  2. 180 degrees and 50 frames won't work as it's 3,6 (60 would work)
    as wait frames need to be a solid number (1,2,3,4,5,6 etc) without decimal
    and it works correctly.

    not sure if it can be ceil'ed or floor'ed to make it a whole number ;)
  3. ShadowDragon said:
    180 degrees and 50 frames won't work as it's 3,6 (60 would work)
    as wait frames need to be a solid number (1,2,3,4,5,6 etc) without decimal
    and it works correctly.

    not sure if it can be ceil'ed or floor'ed to make it a whole number ;)
    Tonight I'll adjust the numbers and test again, then we can see the result. Thanks for the info :)
  4. I have the same problem on a custom with wait frame.
    so the amount like 6 frames must be x4 in order to work correctly.
    so I assume the rotation as well. x3 (60) or x4 etc.

    but in this case 180 / 60, or 180/30 could work.

    if it is the case with decimal issue, check the wait and see if its a whole number ^^
  5. ShadowDragon said:
    180 degrees and 50 frames won't work as it's 3,6 (60 would work)
    as wait frames need to be a solid number (1,2,3,4,5,6 etc) without decimal
    and it works correctly.
    ...what?
  6. ATT_Turan said:
    ...what?
    180 drees over 50 frames = 3.6 per degrees.
    0.6 cannot be 1 wait as its lower, so it needs to equal 1 as lowest in order to work.
    but this is my guess.

    150 degrees over 50 frames works as its 3.
    180 over 60 frames = 3 too.
    180 over 30 frames = 6 which works too :)

    so as long its divided by a whole number, it works (even 6) as long
    it doesn't have a decimal number between frames =)

    correct me if I'm wrong though =)
  7. ShadowDragon said:
    180 drees over 50 frames = 3.6 per degrees.
    You're saying the math backwards: 180 degrees over 50 frames is 3.6 degrees per 1 frame, not 3.6 frames.

    There's no way the game could be looking at decimal frames unless the user typed in decimal frames.

    And I round the degrees to move per frame, so it should never be looking at decimal degrees.

    But if you're saying that you have an action sequence where rotating 180 during a jump displays correctly, please share the sequence and I'll use it to troubleshoot.
  8. I'm don't have use for it as I use front view if ABS fail, so rotation wont
    work in my end =)

    I'm just saying the frames it performance action over the frame is incorrect
    that might causing the issue :)

    if you have a setup and place 180, 60 and works, and try 180, 56
    you might have the same issue as 180, 50.

    if it has the same issue, you know where to look for, or a way to stop it :)
    I'm no pro savvi yet, probably never will be, but I try to help thinking and
    possible solutions.
  9. after several tests, I can confirm that neither speed nor angle affect sprite offset.

    I've also tried removing all YEP SV Battler parameters (Floating, Sprite scale,...) and that doesn't change anything either.

    At the end of any enemy rotation, regardless of whether it's jumping or floating (even though the effect is even more visible), I get the impression that :

    - during rotation, the CENTER of the sprite is the axis of rotation

    - at the end of the rotation, it's the BASE (bottom center) of the sprite that becomes the rotation center.

    EDIT after testing on .js
    I'm not good at JS but I test things. The piece of code that allows the sprite to turn on itself without turning around the base is this:

    Sprite_Battler.prototype.updateFloat = function()
    (line 187 - 210)
    (I don't know if I was allowed to post the whole code part)
    when I deactivate this part, the sprite rotates according to its base, not center.
    But I have the impression that this part is active during the sprite rotation animation, but no longer on the final render, which creates the offset after the end of the rotation.

    I hope that if I don't have the skills to fix the problem myself, I can help you save time with tests...

    1728012219053.png
  10. This is great
  11. @ChrisTN_SM1 and @alasth

    I've updated with version 1.5 that fixed some sprite and animation placement issues.

    Let me know if this fixes the problems you were having.
  12. hi @ATT_Turan ! thanks for the update!

    I tested the plugin with the update and it crashes with these errors :

    1743845516688.png
    1743845529285.png

    If I put back the previous version, it doesn't crash anymore. but I have again the off-axis rotation issues explained on my previous post :

    Action Sequence Rotation Extension
    (edit : I use MV)
  13. alasth said:
    I tested the plugin with the update and it crashes with these errors :
    I've uploaded a corrected version.

    I have received some reports of movement not working correctly when rotated, so I'm going to have to do some more work with it; but see if this corrects the issues you cared about.

    alasth said:
    (edit : I use MV)
    Thanks for the information, but Yanfly's Action Sequences are only for MV :wink:
  14. ATT_Turan said:
    Thanks for the information, but Yanfly's Action Sequences are only for MV :wink:
    that's when I answer late and tired :stickytongue:

    I tested the plugin, it doesn't crash anymore but there's still this problem of moving the sprite on the axis of its angle instead of moving in Y.

    I detailed it here :

    Action Sequence Rotation Extension
  15. I'm using this!
  16. Just noticed a bit of a bug after updating the plugin to 1.5, but I'm noticeing that trying to apply an animation effect to an actor that's both rotating and jumping seems to have the animation effect bound to what the actor's position would be without the jump sequence as seen below:

    1752376701296.png

    Ideally the flame effect should be centered on the actor's Y position during the jump instead of where it should be without the jump sequence. I've added the relevant code below:

    <setup action>
    eval: $gameMap.QTE(["normal"],150,["right","right","left","right","left","ok"],true)
    if eval:$gameMap.getQTEResult() === "failure"
    break action
    else
    display action
    immortal: targets, true
    end
    </setup action>

    <whole action>
    if eval:$gameMap.getQTEResult() === "failure"
    break action
    else
    perform start

    zoom: 125%, 20
    camera focus: user, center, 20
    wait: 30
    wait: 4
    move user: targets, center, 60, offset y -20
    jump user: 150, 60
    animation 278: user
    rotate user: 0, left, 20
    wait: 20
    rotate user: 0, left, 20
    wait: 20
    rotate user: 0, left, 20
    wait: 20

    action effect
    wait for animation
    wait for movement
    wait: 5
    end
    </whole action>

    <target action>
    </target action>

    Edit: for some reason I didn't think to remove the rotation sequences before but the problem still persists, so I'm convinced its not the plugin that's causing this and I can't see a delete button for the post, as this is better off as its own thread.
  17. Exactly what I was looking for. Thanks Turan.

    Was the LEFT rotation intended to behave as it does? If I do:
    Rich (BB code):
    rotate user: 20, left, 15

    It rotates the battler 340 degrees, almost doing a full circle. I was expecting the battler to rotate counterclockwise slightly by 20 degrees.
  18. TESTOSTERONE said:
    Was the LEFT rotation intended to behave as it does? If I do:
    Yes - per the instructions, the number is always clockwise degrees. So if you want it to turn slightly by 20 degrees, you would enter 340.

    I felt that as I was going back and forth trying different things, it made more sense to always refer to the absolute value, if you will.