Constraining to another actor's position killing my instructions?

Everwild

For the last few days, I've been beating my head against a wall trying to do something that seems like it should be very simple. It's a pull-down menu, with buttons on it. When the button is hit, it changes an attribute.

So the game attributes menuX and menuY are constrained to the X and Y position of the pull down menu actor, and constraining my button to menuX & menuY-60, and it sticks there and looks lovely, moving just as I would expect it to. Grand.

That done, in a new rule on the button, I try putting my other instructions on it - when clicked/touched, change attribute Timer1 to 5. (another actor is in charge of timing that back down to 0 if it's > 0, and that works fine... if the attribute can be changed).

For some reason, it just wouldn't work. I rebuilt the mechanism 3 or 4 times from the ground up. It would work, and then not work. So I did a little science, and found that as long as those constraints are on there, keeping it on the menu, the instructions for when it's pushed no longer apply. It does not change the attribute. If I turn off the constraints, or remove them entirely and leave it off of the drop-down function, it works like a charm.

Technically I could get rid of the pull down menu if I must, but it looks awfully smooth and snazzy, I'd hate to ditch it. Is there something obvious I'm overlooking?

SlickZero

Instead of constraining the buttons to the drop down actor, have them with a move behavior that is on time with the drop down menu's speed. Saves having to use system resources for constraints. Which uses a good bit.

That means having another attribute that triggers when you click on the drop down menu.

Everwild

I considered that, but assumed it would be heavier than constraints, and was worried it wouldn't time quite the same way (and end up being disjointed). I am using an interpolate function for it though, and it is pretty smooth with that, so I'll certainly give that a try. Thanks!

SlickZero

My pleasure. You could also try this...Make the menu again, but with the buttons so it's a single image. Then have invisible actors offscreen that will work as the navigation. Once they click the drop down menu, have those invisible actors interpolate from offscreen, and position them where the buttons will be on the menu once it drops down, and have the navigation rules within those invisible actors.

Did that make any sense? It's kinda early...

Everwild

Yeah, that makes sense, and I can probably stash them up where I have my menu going (it comes from off screen as well). I can just stick the same instructions on the buttons as I have for the menu.

The_Gamesalad_Guru

Are you using windows or mac? that must be a bug constrain to a position should not override a touch is pressed. send a report in via support.

Everwild

Will do. I'm on a Mac.