Lou Bagel's Recent Forum Activity

  • And if it is the 'animation' jerking too much, not the sprite's location, I would still think it has to do with the origin. Did you check the origin on every frame of the animation?

  • But I'm still not sure what this means exactly:

    ... the animation jerks too much.

    This is your original question/problem and it is still unclear. That's why I suggest posting an animated gif of it—probably easier to see than describe.

  • I'm pretty sure a venus fly trap doesn't move until it is ready to strike...

    So probably just need a few different animations and change the animation when player gets close. Compare X to see which side the player is on.

    Or use separate sprites for head and stem (ignore my ignorance of plant terms). Then set angle of head to player so it is always pointing towards the player and follows him.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • What type of movement behavior? How do you have it setup/what are your events?

    Consider posting screenshot of what is happening and/or your events so it is easier to help you.

  • You are welcome!

    ...and I just realize instead of choose(0, 1)... you can just set state = choose("left", "right")

    Let me know if you have any questions

  • It sounds like the mirrored is what is causing the jerking—is the origin in the middle of the sprite?

    I assume the mirroring is done from the origin, so the closer the origin is to the center of the sprite the smoother the toggling of the mirroring should be.

  • If you are doing system-global variable > instance.variable I don't believe it is picking any of those instances, so all are picked. If you do sprite instance.variable < global variable then I believe it would pick only those instances that are true.

    I would recommend though:

    on layout start

    -for each (menu)

    --if instance variable < etc etc

    ---then animate x

    --else; animate x

    I'm not entirely sure if that is necessary but is usually safer.

  • My guess at the problem, despite very limited information:

    Are you using 'for each'?

    You probably have a 'picking' problem, as in picking all of them. Therefore it is applying it to all of them.

  • I get what you are saying, and that is fine if that is the way you want to do it. What I meant was one should always be disabled, thus not being used simultaneously. When enabling one then disable the other.

    My question still stands though—how familiar are you with path-finding? Disable the bullet behavior and debug the path-finding behavior. Use the debugger and a text box to figure out what is going on there.

  • I would recommend learning how to create a "state-machine" (I believe that is what they are called).

    So you would have an instance variable called "state" and depending on what that is corresponds with what he does. Timer behavior would be needed to go along with this.

    Example:

    If state = "right" then simulate right

    If state = "left" then simulate left

    If state = "idle" then idle animation

    On Timer

    -state = "left" or "right" then state = "idle"

    -state = "idle"

    --Choose(0, 1) > 0 then state = "left"

    --Else state = "right"

    Restart Timer

    This is the basics, if you want more states then just map out the order that they should move through states. For example one I've done for shooting zombies is idle -> aim -> fire -> recoil -> recover(just a pause) -> idle ... but from idle a different chain can occur such as move, reload, etc.

    Jumping at random intervals can be done as a state or separately with a timer. When setting state to left or right start the state timer and also a jump timer (can set to random time). On timer simulate jump.

    Edit: definitely add the "Else" where applicable in above commands

  • I don't believe it is recommended to use two movement behaviors simultaneously—and I don't believe it is usually necessary either.

    Disabling bullet behavior shouldn't affect path-finding. But bullet behavior automatically moves (when enabled, so at the start of the layout or when created, etc). So are you sure you had the path-finding working to begin with? Or was it just moving because of the bullet behavior?

  • —

    Yeah you have the last version on the link so it's the version with no bug :p.

    But like i've said, i'm wondering if it's possible to do that : (Suppr the shift control and change the ship with just ctrl)

    Like when you press control it does one thing if shift is down and another if not?

    If so:

    On Ctrl pressed

    --Sub-Event: if Shift down; then yada yada yada

    --Sub-Event: Else; then yada yada yada

Lou Bagel's avatar

Lou Bagel

Member since 7 Sep, 2015

Twitter
Lou Bagel has 3 followers

Connect with Lou Bagel

loubagel.com

Trophy Case

  • 9-Year Club
  • Jupiter Mission Supports Gordon's mission to Jupiter
  • Forum Contributor Made 100 posts in the forums
  • Forum Patron Made 500 posts in the forums
  • Popular Game One of your games has over 1,000 players
  • Regular Visitor Visited Construct.net 7 days in a row
  • RTFM Read the fabulous manual
  • Email Verified

Progress

16/44
How to earn trophies