Amazing, I wasn't expecting it to happen right away you know :) Thanks a lot. Now that I'm looking at the .capx I'm thinking it's no wonder I couldn't figure it out on my own :) Smooth movement logic part is begging to be turned into some kind of plugin. Maybe one day. Also big thanks to Yann. :)

Kyatric

Do you have an ETA on the human readable example capx as a suggestion on how to implement a movement method? The one on this thread isn't for a grid based game and it's hard to follow what to do opening your and Wastrel's example side by side, trying to combine the ideas without some kind of grid-based example.

That must be someone else's bug, I never even used iframe in C2 :)

Also, for the angle, I already thought about that. I could have simply used an instance variable. But it's just a sprite. It's just an object with angle and position. Nobody said you had to use the same object for graphically eye-candy stuff.

Just set the 'Player' sprite to invisible, and just make your character follow the position (and not the angle) of this 'Player' sprite.

That's simple and effective. Didn't think of it due to lack of experience. :)

I'd like to use mouse controls however and were going to attempt merging what I learned here with Kyatric's pathfinder behaviour, moving tile by tile with the data generated by pathfinder but with the time based animation logic you provided but then again I thought I could just use the default 8 direction behaviour with pathfinder now that you gave me the idea above! This is still well above my head so I'll be heading back to forums quite often. Will try to use this thread to keep things tidy. :) Thanks again.

Kyatric

Done!

Please download the example capx and set an event for the "every tick" condition like shown below.

<img src="http://dl.dropbox.com/u/3138530/bug.jpg" border="0">

Afterwards save and close the project. The event will be absent when you load it back. I think it only happens when the instance variable in question is a boolean.

This is discovered in this thread.

I'm using Windows 7 x64

Thank you for the replies. :)

Ok, after looking at you code, I would recoment, that you use the "every tick" event to move the sprite by "x" and check if the desired delta value is reached...

I'm not really sure what you meant but I'm interested to hear more :/

http://dl.dropbox.com/u/23551572/C2/gridMovement.capx

Thanks, that's a very good example and I'll surely make use of instance variables like you did but rotating the sprites unintentionally rotates the pixel data within them and I'll have to find a workaround that doesn't use the angle parameter at all. This is what I mean.

Also if I understood correctly, even if you "Substract speed*dt from move" it may return a negative value and we may need to use the fix you already provided. IMO If there was a way to limit the maximum frame rate without using dt, I'd just drop the dt and all the hassle that comes with it. Inconsistent sprite movement speeds vs. sprite movements that don't stop accurately = I'd take the first one any day. I'm still feeling illiterate about it even after reading the available resources here but I just don't see how dt might come in handy in the case of turn based, non action oriented scenarios. I'm an interface designer, not a programmer, previous flash user and certainly not a flash fan. C2 with its brilliant event system helps me do what flash with all its weird elitist script driven ugly face didn't. Oddly enough timing was never an issue in flash and everything was fps driven. Or at least, it was never the user's responsibility to be bothered with whatever sorcery laid underneath. I know that C2 is new and yet incomplete and I'm not going to be alienated by this; probably learn more in time and keep supporting it but some way of simplifying these kind of issues is kinda required to keep non coders interested especially if they're attracted by "no coding required" slogan. I bet a couple behaviours will appear in some months and C2 will suddenly start catering people like me that aren't coders and are interested in making a 2d game that isn't action related or in real time.

Unrelated bug report for the devs:

I think I've come across an interesting Construct 2 bug on this example. Try creating an action from "textch" on every tick like I did with the other variables and text objects and set its text to the player's instance variable "checked" It'll work, the preview will work but it won't save! Next time you load the file the action will be gone. Looks like boolean instance variables have a problem with saving when called into text objects.

Hi,

I'm planning to make a grid system for a turn based game and searched through the forums to check what was done before, reading all the links in the how-to thread but the most detailed example I were able to find was from the Construct Classic era which is fine as CC turned out to be a familiar experience after using C2:

related topic

The example I linked above was probably before the time tiled backgrounds were implemented and I have no desire to place tons of empty sprites, bogging down cpu resources to create a grid so I'm thinking about moving objects in relative distances from where they were previosly or maybe keep possible x,y values in arrays and move sprites to them using the rex_moveto behaviour. However I prefer the stock behaviours as they might be less prone to bugs as more people use them and fixes are guaranteed to arrive (not that rex_moveto behaviour isn't cool as it is, just forcing myself to do things the intended way).

I'm going for the relative distance approach but having a problem: I'm never able to produce consistent results using custommovement to stop a sprite after moving a set number of pixels (in this case, 84). The result is unpredictable in the runtime and different in every case. I tried to set the x location of the sprite to floor() and int() of itself on every tick but this only removes the trailing digits and doesn't guarantee I'm going to get multiples of 84 every time. I'm assuming this is due to the delta timing features within the custommovement behaviour but I may be wrong on this.

Attached is a .capx that has an event disabled to show what I'm getting normally. Enable that events to see what I'm intending to end up with. I believe my current *fix* of the matter is a dirty hack and is doomed to cause collision related troubles in the long run or maybe I'm just being paranoid and this is how it's supposed to be like. I'd love to hear what experts can say on this matter.

Thanks :)

<font size="1">edit: this post was originally a request for a better formatting of the original post but DiggyDog explained below why there is no need.</font>