Rhindon's Recent Forum Activity

  • .C3P file https://www.dropbox.com/s/xt8w2rywggvvo30/The%20Getaway.c3p?dl=1

    The new Tween behavior recently got added and Ashley is still working on the documentation...

    In the meantime, I was wondering if anyone has had any success in better understanding the nuances of the behavior than I have...

    I'm trying to create a somewhat "dynamic" camera system for a racing game I'm working on.

    The Camera object is pinned to the far end of an object "camera arm" which I've called "Selfie Stick". The Selfie Stick is likewise pinned to the Car object.

    When the Car accelerates, the Selfie Stick extends in length, lerping based on Speed/MaxSpeed of the Car. This begins the set-up of the Camera "leading" ahead of the Car. This part works just fine.

    When the Car turns left or right, the Selfie Stick is to rotate to the Car.Angle +/- 10. Of course, if the Car is not turning, the Selfie Stick "rests" at Car.Angle = 0. This way the Camera also "leads" at angles, too. I want this to be a smooth transition, even if the player quickly alternates between turning left or right or not turning at all.

    I'm trying to use the Tween behavior (assigned to the Selfie Stick) so that it smoothly transitions to the +/-10 value relative to the Car object's angle.

    The problem is when I start turning - even just tap the left/right arrow keys - the Selfie Stick object begins rotating rapidly and will not stop, even after the Car has completely ceased all movement.

    Previous sample projects to test out how the Tween behavior worked resulted in things happening mostly as I thought they should. But I do not understand why the Selfie Stick object overshoots the Car.Angle value and never stops.

    Help, please?

    ========

    EDIT: I did further testing and I discovered something interesting.

    I created a single sprite and set it so that it moves 50 up/down/left/right depending on which keyboard arrow is pressed (event: on pressed). While the sprite is moving its 50 pixels but not yet reached its goal if the key is pressed again in the same direction, it "adds by overlap" (probably not an accurate phrase, but it's the best I can think of to explain it) another 50 pixels to Tween to. The result is that the sprite is now moving faster - or faster for the amount of "overlap".

    This would help explain why my Selfie Stick object begins spinning wildly even after the briefest tap of the left/right arrow keys while turning. For however many ticks passed, that's +/- 10 degrees "overlapping" and so the object continues to Tween until it has finished processing each set of 10. (@Ashley, can you confirm this is more-or-less accurate, please?)

  • Seems I solved my own problem...

    I went ahead and disabled the 8Direction Disable action, Set 8Direction Speed action, and Set angle action.

  • I'm working on a top-down perspective game in which the standard movement is via the 8Direction (8Dir) behavior. Upon pressing the specified "dash button" on the keyboard, the character should briefly dash ahead using the Bullet behavior and then return back to normal movement.

    The Set-Up

    Dash button pressed

    - Stop all momentum from the 8Dir behavior (I found that the momentum was "held over" after re-enabling the behavior when the dash was finished)

    - Enable Bullet behavior and set the Bullet angle of motion to the facing angle of the character

    - Set Bullet speed to 500 because the Bullet behavior deceleration value is -800 (I didn't want a future use of the Bullet behavior to be at 0)

    - Start a self-countdown timer for how long the dash should last

    - Disable 8Dir behavior for the duration of the dash

    When the character timer is up

    - Re-enable 8Dir behavior

    - Set the 8Dir speed to whatever the remaining value of the Bullet behavior speed was (remember, it had a -800 deceleration)

    - Disable the Bullet behavior

    What I'm TRYING to Accomplish

    - Activating the dash should send the character rushing ahead at its given angle.

    - After a 1/4 second, the movement behaviors switch back to normal and the angle of the Bullet motion is set as the character's angle.

    Problem

    When resuming normal 8Dir movement, there is an immediate sudden right "burst" of movement after the Bullet behavior is de-activated.

    I have discovered what I believe the issue to be. Upon re-activating 8Dir, 8Dir's angle of motion value is 0, hence the sudden movement to the right. There are no actions for the behavior to edit this value. I can set the object's angle and its Bullet angle of motion...but not its 8Dir angle of motion.

    https://www.dropbox.com/s/vltqn912290myl5/Sir%20Slash.c3p?dl=1

    I'd appreciate any input on how to resolve this. Thank you!

  • I was not aware of that demo. I'll surely have a look! Thank you for the suggestion.

  • NetOne - Oh man, bugs always bugging ya. Such is the life of a programmer. Heh.

    Sorry for any confusion... I'll try to explain again with more clarity. Bear with me...

    As you see, there are multiple instances of the GhostHunter(Body) objects. (GhostHunter is the visual object that the player will see and GhostHunterBody is intended to be the object that does all the moving about and contains (most of) the behaviors, variables, and other stuff.)

    Taking into account that the "camera" angle (based on how things are drawn and now the actual camera/ScrollTo behavior), the visuals are that of top-down + slightly behind. Much like how Zelda: A Link To The Past was drawn on the SNES. With that visual angle, objects that are higher up on the Y-axis are technically "behind" or "farther away" (from the player's visual reference) than that of objects lower on the Y-axis. Assuming they're all on the same layer (they should be), objects that are "farther away" need to be drawn on the bottom of the layer or at least below objects that are "closer" to the player.

    So when one GhostHunter instance moves down on the Y-axis (closer to the player) they need to be redrawn on the top of the layer when "passing through" other instances of the same GhostHunter object. The current problem most of the time is that it looks as if certain instances on the top of the layer are literally on top of the other instances even though they should be behind them because they're higher up on the Y-axis.

    Further, the problem I'm having with the Z-order action line is that I don't know what the assumed sorting process is. Does it sort ascending or descending? I looked into the manual and couldn't find a clear answer. Is there a way to affect the sorting order? I'm guessing that the variable it's calling upon is used to calculate how it should sort or what it should sort, but again, I'm not finding a clear answer.

    Thanks for your time to help me work this out, too!

  • *sighs* I don't know what's wrong, but even with a family, it's still not working. It occasionally sorts them correctly, but in the end, whichever GhostHunter is on the top of the layer stays on the top... It won't sort to the bottom, or rather below another GhostHunter, when it's at a lower Y-axis value than the others.

  • AH! Okie dokey, then. I'll give that a shot and report my findings. Thanks for all your help, both of you!

  • I double, triple, and quadruple-checked everything - from event/action lines to image points. Everything lines up. I've verified the correct variables get referenced, and everything. I've tried

    A couple other details while you look this over...

    The actual GhostHunter objected is contained with the GhostHunterBody (right now their images look the same but "Body" is invisible at startup).

    The GhostHunter object is pinned to GhostHunterBody object. "...Body" controls all movement and contains 99.9% of all the variables. GhostHunter is using the ZOrder variable, though "...Body" also has the same variable (not used).

    https://www.dropbox.com/s/h2v1joiqaimjgoe/busters%20escape%20v8-3%20.c3p?dl=1

    The event line in question is 18 (Group "Enemy Z-Order").

  • nacra - Well, if that's the case, I don't know what's wrong because any instance of my GhostHunter character that's atop another instance remains on top regardless of its Y-position on the layout. I should add that I don't change the GhostHunter instance variable at all. It's just there so that I can use the Sort action.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

  • I only kinda follow.

    ...I've created an instance variable for my object in question (GhostHunter).

    So far I have a no-condition event line with the two actions:

    (1) GhostHunter set instance variable ZOrder to round(Self.Y)

    (2) System Sort GhostHunter Z Order by GhostHunter.ZOrder

    Similar to the illustrations shared earlier on this thread, my GhostHunter character needs to appear behind other GhostHunters when it is "farther away" from the player (given the top-down/angled behind camera assumption). Thus, any GhostHunter that is lower on the Y-axis needs to appear "behind" other GhostHunter instances.

    If using a For Loop is inefficient (and so far ineffective per my efforts), I'm failing to understand how to make the Sort Z Order action useful. What do I do next or change given what I have so far??

  • Ashley - I went to use the Sort Z Order system action and it's asking me for an instance variable for the object whose instances I want sorted. There's no ascending or descending option. Per the manual, it also does not make any mention of having to use an instance variable.

    For clarity, I selected an event line, pressed A to open the Actions menu, chose System, and then Sort Z Order.

    I've never used this feature before so I'm not sure if there's something I'm missing.

  • I plugged in the actions as you have in your update and it definitely worked as promised. Tests did result in very minor occurrences of the problem while continuing to hold a direction into a wall. I also repeatedly pushed the direction into a wall while already up against it but there didn't seem to be any rhyme or reason as to exactly what triggers the brief about-face.

    However, the problem seems 99% resolved and hopefully doesn't prove to be any kind of significant issue...

    Thanks again!

Rhindon's avatar

Rhindon

Early Adopter

Member since 8 Jan, 2013

Twitter
Rhindon has 2 followers

Connect with Rhindon

Trophy Case

  • 11-Year Club
  • Forum Contributor Made 100 posts in the forums
  • Forum Patron Made 500 posts in the forums
  • Forum Hero Made 1,000 posts in the forums
  • x2
    Coach One of your tutorials has over 1,000 readers
  • Regular Visitor Visited Construct.net 7 days in a row
  • RTFM Read the fabulous manual
  • Email Verified

Progress

18/44
How to earn trophies