Issue with constrained actor direction facing.

natzuur

Hi guys. I'm having an odd issue with a constrained actor. The actor is constrained to my main movement actor which I use for collisions. I have some logic set up to detect direction based on self.motion.velocity X (> and <) and then a constrain to attribute "MotionX" to keep track of this globally. I then use the "MotionX" to reference the direction for the constrained actors. In this case I have two constrained actors, one for my main characters graphics and animations and one for a weapon. The one for the main character triggers perfectly when I say self.graphics.flip horizontaly true or false based on motion x being negative or positive and when he's not in motion the last image is used, which is perfect. However the logic on the weapon has some issues:


The logic says when MotionX > constrain atribute self.rotation to (10*sin((self.Time *1000)%360))+240 and of course MotionX < constrain atribute self.rotation to (10*sin((self.Time *1000)%360))+100 for opposite rotation constraint direction (angles not exact, dont have project on this comp). For the most part this work great, however when I go back and forth several times really quickly fluctuating from a negative to a positive and then stop it wont consistantly change to the correct direction last used. Motion shows as a 0 every time i stop in display text, but it's hard to tell watching but sometimes it seems like a flux happens after I have stopped moving (shows a number like .0754 or -.0754) for just fraction of a second. However if it was a delay in the triggering, I don't know why this wouldn't effect my other constrained actor as well. Has anyone noticed any inconsistancy like this?

I have also tried limiting the direction detection to -1 and 1 to add a gap in case of a delay, same results. Also used a text attributed called direction to keep track of left and right that changes based on velocity, same problem. I tried replacing the self rotation constraint to a interpolate equivalant, same things. The only solution I can think of would be to create pre-rotated images to use as replacements for when not in motion and change the self.flip.horizontally to true or false based on the motion logic or direction facing type logic.

Does anyone know of a better way to detect last direction that is accurate enough to be on key 100% or anyone have any idea what might be causing this?

MobileRocketGames

Wow that facing code is a bit math heavy.
I've got a simple solution for you:

Set up a simple timer using the built-in clock and the modulus function. Don't use the timer behavior, as its garbage.
Use this timer to set a start and end position and run a check every .1 seconds.
Every .1 seconds the rule should check if the start position is higher than the end position.
If it's higher, then the target is moving right and should be facing that way, if its lower its moving left.

How to do this:
Create 3 real actor attributes (Mod1, StartX, EndX).
Set Mod1 to a value of .05 for now.
Create a rule that says:

( Rule:
Attribute Mod1 > self.Time%0.1

Change Attribute StartX = self.Position.X

)

Put a rule inside a rule to change the direction of the graphic.
Should look something like:

( Rule:
Attribute Mod1 < self.Time%0.1

Change Attribute EndX = self.Position.X

      ( Rule:

      Attribute StartX > EndX

      Change Attribute self.Graphics.Flip Horizontally = true

      Otherwise:

      Change Attribute self.Graphics.Flip Horizontally = false

      )
)

Basically because of the modulus function it will cycle through time in increments of 0.1 seconds. So when one second has passed it will have cycled through 10 times. for the first .05 seconds of the cycle it will set the start position, the last .05 seconds it will set the end position. Each time the end part fires, its going to calculate if the start position is greater than the end position and when it is, it will flip the graphic, when its not it will unflip.
You may want to increase the modulus cycle to preference, as having a .5-1 second delay before it changes directions is more realistic. Heres a link to learn about creating your own timers without the timer behaviors (special thanks to Domenius):

http://forums.gamesalad.com/discussion/44707/timers-are-for-chumps-gs-optimization-tips/p1

Photics

Maybe tables would help? I did a trick on another project recently and it worked out great.

Basically, I would record the X&Y location of an actor in a list. And with unlimited rows of actor history, I could have other actors act accordingly.

That was with Stencyl though... and GameSalad doesn't have loops... but there might be a way to make it work here.

With a timer... every X seconds, you could update the numbers. Then, with each rotation, move the numbers move down a row. (Repeat for as many rows you need.)

However... and this might resolve your zero-motion issue... chuck a rule in there. If the X & Y values (rounded, to get rid of decimals) have not changed, then don't update the table. That will give you the previous X & Y locations, where the collision actor could be positioned accordingly.

If New X is less than Old X, move here
Otherwise... move there.

natzuur

Thanks guys. But I figured it out, it was something really stupidly simple (usually is). I was using contains left or right on some of the rules instead of is for an absolute value, so it was behaving sporadically.

@MobileRocketGames

Thanks for the idea, but the math is not for direction facing but rotating the actual object. This give the illusion that while in motion the constrained weapon is bouncing with the motion. So in this case simply flipping the image would not be enough. Although your modulo tracking system could be used for some other awesome purpose i'm sure, and since self and game timers are super accurate I know i'll figure something to use this for.

@Photics

Hmm that's an interesting idea, I bet this can be used in conjunction with the modulo timer to update a table extremely fast with a ton of data. I appreciate your response.