Inconsistent "Move To" behavior!?

rebump

[CodeMonkey where are you? ;-) ]

You would think that you could throw in a sequence of "move to" behaviors for an actor and have the actor follow the path(s) in sequence as long as each "move to" was conditionally ran by a conditional based on a counter (i.e. say a shape "side" counter from 1 to some number where each step coincided with one of the sides of the shape - thusly a rectangle would have for steps/rules for the counter values 1 to 4).

I try this with a rectangle (and an arbitrary starting point on one side of the rectangle but that shouldn't matter as long as I start with the correct "side" counter starting value) and the rectangle is traversed by the actor but it doesn't repeat even when setting the "side" counter back to the value for "side" 1. Timers don't make sense for this and I don't want to setup multiple invisible wall actors.

I also try a simple horizontal back-and-forth motion actor with "move tos" and a toggle value for direction. This time it seems to repeat but doesn't travel the full distance of the intended motion. It just shakes almost in place and will sometimes move one way once. I don't want to use two invisible wall actors to bounce off of at the end points.

Finally, I take the back-and-forth actor and add a timer and it works but again a timer really doesn't make sense in this case.

It seems as if the "move to" behavior is inconsistent/buggy.

I haven't tried just a "move" but I didn't really want to setup a bunch of conditionals that are a bit more involved than testing for a "side" counter (in the case of the rectangle moving actor).

A demo project is here: http://gamesalad.com/game/play/33793

JGary321

I use move-to for a few things in my game. I haven't noticed ANY bugs on the Viewer. However, if there is ANY lag when running it in on the iPhone it will sometimes overshoot in the unknown abyss, never to be seen again.

For instance, I have a spellbook button & when you touch it a menu slides from off screen into place where it needs to be. When there was multiple things moving, sometimes it would never stop where it was supposed to. This only happens when the game starts lagging.

rebump

Is your "Move To" at the root level of your spellbook's behavior list (i.e. not embedded in anything other than a conditional like "ShowSpellBook = true" or do you have it tied to a timer or some other construct).

I'm not doing anything fancy in that demo project link in my first post in this thread...especially the horizontal back-and-forth actors.

JGary321

Well mine is a bit different. I have several spell page possibilities. So the actors rule would look more like...

When game.SpellPage = 1

Timer: After 1 sec
Move To X, Y
Speed 500

Otherwise
Move To X, Y

Like I said, mine works perfect. Only the lag messes with it.

rebump

I guess it comes down to how do you consistently loop a "move to" or more specifically loop a sequential set of "move to" statements for an actor.

I just want an actor to move in a rectangular path repeatedly and without a ton of wall actors to constrain it or a bunch of conditional logic to test for surpassing an X or Y bound of the rectangle (why? those methods seem like they would eat up more resources and impede performance).

rebump

After playing around and reading more I think I have confirmed that a set of "move to" behaviors will perform in any order unless they are forced into an order based on some attribute...which is why I set up the "square" movement actor (the grey actor) in the aforementioned demo project to do so from the start. The correct order is forced but only executes once even though I set the attribute back to '1' to start over. It is as if the "move to" still only execute once even with that logic in place. If I throw a timer in there, things get erratic not to mention I want the movement around the square constant (i.e. no periodic pauses for timing gaps between iterations and actual time to complete the "move to" sequence).

scitunes

I tried to use move to for some more complex movements and it was a real hot mess. So then I just created an invisible actor and placed it where I want the change direction to take place. then in the player

rule
when overlaps with turnobject
change velocity (put new direction)

so it moves in a straight line (set the initial velocity) until it hits the object and then it turns. Then keep doing this (with separate turn actors - 4 for a rectangular movement)

For pacing back and forth I found this method to work the best too. Instead of change velocity i do a change attribute (linearmotionX to -linearmotionX)

scitunes

I tried to use move to for some more complex movements and it was a real hot mess. So then I just created an invisible actor and placed it where I want the change direction to take place. then in the player

rule
when overlaps with turnobject
change velocity (put new direction)

so it moves in a straight line (set the initial velocity) until it hits the object and then it turns. Then keep doing this (with separate turn actors - 4 for a rectangular movement)

For pacing back and forth I found this method to work the best too. Instead of change velocity i do a change attribute (linearmotionX to -linearmotionX)

JGary321

For my TD game, I use 4 invisible actors. These guys take up negligible memory. They have 0 rules!

One is called Move Left, Move Right, Move Up, & Move Down.

In your moving actor just put when collides with:

Move Left change velocity to 180.
Move Right change velocity to 0.
Move Up change velocity to 90
Move Down change velocity to 270.

Easy & takes up very little resources.

rebump

It may come down to using that method but it seems much cleaner and less resource intensive if "move to" sequences could be repeated reliably...which I think was the intent for such a behavior. Although I suspect using that method with 5, 6, 7, an 8 sided figures would be inaccurate to loop over and over.

Mainly wanting CodeMonkey to say one of three things:

1) "move to" is not to be used how you intended
2) this is how you do it using "move to" sequences (hurray!)
3) it is a known bug and we are working on it

I really hope I am either doing it wrong or it is a known bug that they are working on. I really don't want to get four (or eight? could probably hack with four) actors per each rectangularly moving actor. I was wanting to replicate this movement scheme to five, six, seven, and eight sided paths for various levels and what not and may be able to come up with some parameterized actor that could handle them all.

This is a deal breaker on a couple of games I have in mind and the platform side-scroller is a bit in the air too as I cannot get near enough to quality Mario-esque player movement no matter how much I fiddle (but I only spent several hours on it).

I really want GameSalad to fly and use it as a paying member but I don't want to delve in if things are still a bit too flakey (lots of projects on the site blow up randomly in different ways...don't know if it is the underlying projects and/or the viewer). I think it is a great product but just needs some tuning. It seems a bit of luck on project selection and just luck-of-the-draw on whether your app will be stable enough but then again, I have only been playing with it a few days. I may just have to change my project decisions to fall inline with what is currently stable and working.

rebump

I guess a triggered "move to" with a small actor trigger appropriately placed would yield results nearly accurate as sequential "move to"s.

Still would like CodeMonkey's feedback on all this though since it seems things are a bit amiss and/or I'm missing out on something.

CodeMonkey

a little of number 3.
We'll try to pinpoint the cause and eliminate it.

rebump

Thanks CM!

If you look at that demo project (that works in the Preview but it seems to die alot of the time in the web viewer), the number displayed on the two gray moving rectangles is the "side" counter variable. It doesn't seem to update no matter what "side" it is on. It should go from 1 to 2 to 3 to 4 back to 1. Another odd thing is for side 4, I have the "side" counter variable set back to 1 but sometimes it reverts, in the behavior dialogue, back to 0!? So if you see 0 in there, it was not from me. Almost as if your behavior storage structure is somehow getting compromised. Lots of weird things. I even tried a fresh project with simpler versions of the same actors and the same results.

TwistedMech

In my new game I have a few actors "New Game", "Credits" etc which scroll onto the first scene menu. (http://gamesalad.com/forums/topic.php?id=2328). Having put the project to the iPhone and watching the MoveTo problem appear so often (flying past its stopping point), this really needs to be addressed as soon as possible because it makes the command unusable. I really do not want to keep creating constant work-arounds for things which should work.

If you need people to upload the developers example projects to show the problems, please let us know.