Game Development Community

missing link

by rennie moffat · in iTorque 2D · 09/06/2011 (7:51 am) · 5 replies

Hi there,
I am working with a few behaviors and have a question...

behaviorE
objectE is hit by objectC, when "hit", objectE changes its state (as I determined). With in this same function I call a schedule to recover (500ms)



behaviorEManager
uses and onUpdate call to manage all states of objectE. When objectE is hit, this behavior should recognise that. When the schedule in the behaviorE is called to "recover" it should also recognize that however what I am getting is perplexing me.



The onUpdate call is only being made after then recover a full 500ms after the initial call. This is perplexing me as the onUpdate is every 33ms.



So to be clear, my console is retruning...
behaviorEManager onUpdate()
behaviorEManager onUpdate()
behaviorEManager onUpdate()
behaviorEManager onUpdate()
behaviorE hit
behaviorE recover
behaviorEManager onUpdate()
behaviorEManager onUpdate()
behaviorEManager onUpdate()
behaviorEManager onUpdate()

In my mind there should be a few behaviorEManager onUpdate()s between the hit and recover.





????



rennie moffat's profile picture
Torque Owner rennie moffat
Renman3000

About the author

My thanks to Garage Games and the Garage Games Community combined with owned determination I got one game up, Temple Racer and I am looking to build more interesting, fun games for the mass market of the iOS app store.

Recent Threads

  • is it just me or is onPositionTarget sketchy?
  • Ben Kenobi
  • Installing Box2D Today
  • An Unknown Error Has Occured
  • object reading others behavior?
    • NextNext Thread
    PrevPrevious Thread
    More from iTorque 2D


    Employee Kyle N. Miller
    #1
    09/09/2011 (12:34 pm)
    Would you please post the script for those two behaviors?

    Torque Owner rennie moffat
    Renman3000
    #2
    09/09/2011 (1:11 pm)
    behaviorEManager
    http://pastebin.com/2F4ERUTG

    behaviorE
    http://pastebin.com/upuU8fvG



    I have included explanations of each at the top of each, how they relate to each other and the issue as I perceive it.

    If you can help, great. If not, don't worry about it.


    Thanks
    Ren



    Employee Kyle N. Miller
    #3
    09/16/2011 (1:02 pm)
    I apologize for the delayed response, Rennie. Where are you scheduling the onUpdate to occur every 33 ms?

    Torque Owner rennie moffat
    Renman3000
    #4
    09/16/2011 (5:05 pm)
    Don't worry about it. I was updating that call every 33ms as it monitors if $EnemyChangeState == true;, if so it allows for what change state has occurred, walk left, right, kick, punch. The function is immediately returned if false, so it proves not noticeable stress on the engine.

    Why?


    Torque 3D Owner Brian Szatkowski
    #5
    09/17/2011 (4:41 pm)
    Hey Rennie;

    I am trying to walk through your code and, from what I see, it plays down like this:

    A "hit occurs" (resulting in either defending or smacked depending on what your randomizer returns). This sets $EnemyChangeState to true, makes the 1.7 second-delayed scheduled call to eRecover, and goes about its merry way.

    In the mean time, your every-33-ms-onUpdate call gets fired and the following occurs:

    • Check to see if $EnemyChangeState is true
    • - - If true, immediately set to false
    • - - If false, just return immediately
    • If $EnemyChangeState was true, onUpdate continues on to check if the enemy had "defended" or was "smacked"


    So, from what I see, once the $EnemyChangeState is set to true by the eHit action, the appropriate animation is played according to %eReaction. Then, a 33ms onUpdate occurs which not only resets $EnemyChangeState to false, but ALSO triggers the same animation (based on the $EnemyDefending/$EnemySmacked flags).

    Then, from that point forward, onUpdate would get called 50 more times before the scheduled call to eRecover gets fired. However, since the initial onUpdate reset $EnemyChangeState, nothing would ever happen during those subsequent calls.

    Finally, eRecover is called, turns collisions back on, and sets $EnemyChangeState back to true. Of course, once onUpdate is called again within the next 33 ms, that will get reset, and the cycle repeats.

    Is this your expected behavior? The double animation calls not only seems redundant but a likely source of potential issues.