Hey spacedoubt,

So, if I understand correctly, I believe the short answer would be this:

snapX = ( round( mouse.y / 32 ) % 2 = 0 ) ? ( round( mouse.x / 128 ) * 128 ) : ( ( round( ( mouse.x + 64 ) / 128 ) * 128 ) - 64 )

snapY = round( mouse.y / 32 ) * 32

That said, I've also included an explanation of this solution below:

**The math**

What it sounds like you want to do is snap to a diamond shaped grid; basically a rectangular grid with every odd row shifted half a cell length.

Let's start by thinking of the rectangular un-shifted version of the grid.

From your capx, it looks like you want a horizontal snap distance of 128, and a vertical snap distance of 32. Now 32 might sound too small, but remember that as soon as we shift every odd row, it will suddenly *look *like the vertical snap distance is 64, because the vertical separation between tiles will *appear *to skip a row. But it really isn't skipping a row, and it really isn't 64, it's still 32.

```
Unshifted
#---#---#---#
#---#---#---#
#---#---#---#
#---#---#---#
Shifted
#---#---#---#
..#---#---#---#
#---#---#---#
..#---#---#---#[/code:315nwg0m]
Now if we shift every odd row by half a cell width, we'll have a diamond grid that will snap 128 x 64 pixel tiles.
[b]Vertical snap[/b]
So lets start with the vertical snapping since it will be the same regardless of the row.
We need to snap to steps of 32 pixels.
tileY = round( mouse.y / 32 ) * 32
We are squeezing the 32 pixel tile size down to the size of integers, then using round() to chop off the decimal part, then expanding the rounded result back to the 32 pixel tile size.
[b]Horizontal snap[/b]
Next lets do the horizontal snapping, but for simplicity, our first version here will not account for the shifting on odd rows.
It's basically the same as the vertical snapping, but with bigger steps.
tileY = round( mouse.x / 128 ) * 128
Same deal, we squeeze, round, and expand back to normal.
Now that formula works fine for the even rows, but what about the shifted odd rows?
Well lets make a similar, but slightly adjusted version of the formula for the odd rows.
We want to shift the tiles over by half the horizontal step width of 128. So we'll shift by 64.
tileY = ( round( ( mouse.x + 64 ) / 128 ) * 128 ) - 64
So it's basically exactly the same as the even-row formula, except we add a 64 offset to the input "mouse.x", and we subtract it back off after we end.
Why? Well remember that the heart of our snapping system is the round() function. When we shift everything by half a step width (64), and then divide by an entire step width (128), as far as the round() is concerned we are shifting by "0.5"; and since round() will snap to the nearest integer, it will be snapping exactly halfway between the spots we'd get from the even-row formula.
But wait, even though we shifted the input, round() is still just snapping to integers, so shouldn't it just expand back to the same snap points that the even-row formula gave us? Yes, it would [b][i]except[/i][/b], remember that we also un-offset the result by half a step width, which is the "- 64" at the very end.
[b]Picking Even or Odd formula[/b]
Okay, so we have two formulas, but now we have to choose one or the other depending on the row.
We'll need a formula that tells us if we're on an odd or even row.
round( mouse.y / 32 ) % 2
We squeeze the Y coord from counting pixels down to counting rows by dividing, then use round() to chop off the decimal fluff, leaving us with the integer row number. We then mod the row number by 2, meaning we'll get "0" if the row is even, and "1" if the row is odd.
Now we just need to say, IF ( row is even ) THEN ( even formula ) ELSE (odd formula).
You could do this with events, and that would be just fine, but there is a slightly more compact way to handle the IF / THEN / ELSE case, and it's called the "ternary" operator, sometimes called the one-line-IF-statement.
The ternary operator looks like this when used:
( name = "world" ) [b]?[/b] ( "hello world" ) [b]:[/b] ( "hello person who is suspiciously not world" )
and means this:
[b]IF [/b]( name = "world" ) [b]THEN[/b] ( "hello world" ) [b]ELSE[/b] ( "hello person who is suspiciously not world" )
[i](Note: The "ternary" operator is named for the fact that it takes three arguments, where most operators (like "+" and "-") take only two.)[/i]
This is exactly what we want to do.
We just need to plug in the parts we want to use.
[b]IF [/b]( round( mouse.y / 32 ) % 2 = 0 )
[b]THEN [/b]( round( mouse.x / 128 ) * 128 )
[b]ELSE [/b]( ( round( ( mouse.x + 64 ) / 128 ) * 128 ) - 64 )
Using the ternary operator we get this:
( round( mouse.y / 32 ) % 2 = 0 ) [b]?[/b] ( round( mouse.x / 128 ) * 128 ) [b]:[/b] ( ( round( ( mouse.x + 64 ) / 128 ) * 128 ) - 64 )
[b]Final X &Y formulas[/b]
snapX = ( round( mouse.y / 32 ) % 2 = 0 ) ? ( round( mouse.x / 128 ) * 128 ) : ( ( round( ( mouse.x + 64 ) / 128 ) * 128 ) - 64 )
snapY = round( mouse.y / 32 ) * 32
[b]Modulo operator[/b]
The JavaScript Modulo operator (%) is ... tricky, to put it diplomatically.
Unlike the more common operators like plus and minus, there's actually no universal standard definition for exactly how modulo is supposed to work, and so there are a few very subtly different versions of it. The version that JavaScript uses (and by extension Construct 2) is one of the weird ones, which does not behave uniformly for positive and negative numbers.
There's a nice visual comparison of the mod variations on the [url=http://en.wikipedia.org/wiki/Modulo_operation]modulus wiki page[/url].
This is especially a problem when writing snapping formulas that make use of JS's modulo, as it means the snapping behavior will likewise not behave consistently across positive and negative input coordinates. If you are absolutely certain that you will never feed in a negative value then it's safe-ish to use the JS modulo, though if you inadvertently change that later in a project without realizing it, you may introduce some very subtle bugs as a result of its weird behavior. I personally never use it for anything. I instead use an alternate version of the mod function described below.
There is a version of the modulo operator that does behave uniformly, and that's the "floored division" version.
Here is the formula for the "floored division" modulo.
[b]mod([/b] val [b],[/b] div [b])[/b] ... = ... val - ( floor( val / div ) * div )
So if you just used substitution to modify the original even-odd-detector formula we made, we'd go from this,
( round( mouse.y / 32 ) % 2 = 0 )
to this,
( ( round( mouse.y / 32 ) - ( floor( round( mouse.y / 32 ) / 2 ) * 2 ) ) = 0 )
Not very pretty, but it will work. it would be nicer to be able to simply use a floored division mod function like any other function.
Well, you can use C2's Function object to create a custom "floored division" style mod function.
I actually explained how to do this a while back in another post if you're interested, in the subsection [url=https://www.scirra.com/forum/detecting-360-degree-rotation_p883148?#p883148]Getting "floored division" mod into C2[/url] (towards the end of the post).
Hope that helps out.
```