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:
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.