Can Snap to Grid be turned off?

[Alarian]

Is there any possible way to turn off Snap to Grid? We don't play D&D 3.x and we all HATE the feature. If we want a grid on the map to use for scale and measurements etc, we seem to be stuck with snap to grid. The main problem lies in that if someone moves down a corridor and the wall next to it isn't revealed, the character will "snap" off the map and the GM has to grab the counter and put it back on. You also have no way to know if your going to snap off the map until you release your token and watch him disappear. You also can no longer walk 2 abreast down a 10' wide corridor because you can only have 1 player in the center of the hall or two people standing in the walls (which then makes them disappear if whats on the other side of the wall isn't revealed. It gets frustrating having your tokens getting moved elsewhere than where you want them. I.e. thief looks around a corner and ends up getting placed in the middle of the hallway instead of just at the edge of the corner.

I know we can technically draw the maps in CC3 or whatever and put a grid on them there, but a lot of the maps I use come from other sources and don't have a grid on them. Plus you then loose out on the measurement tools inside of FG2.

Alarian.

[Griogre]

You can't turn off snap to grid except by turning off the grid. You can set tokens to always show if they get in the mask. I'm afraid FG2 really wants you to use 5 foot spaces so your best bet is to lay down a 5 foot grid if you want the measuring tools.

[joshuha]

You can try this but not sure if it will work.

If you are using a custom ruleset, in the /scripts folder there is a file called imagewindow_image.lua.

Look for the following function:


function onTokenSnap(token, x, y)
if hasGrid() then
return getClosestSnapPoint(x, y);
else
return x, y;
end
end


Just replace it with this:


function onTokenSnap(token, x, y)
return x, y;
end


In theory, even with the grid on it will just return the same coordinates of where the token is so no snapping occurs.

[Alarian]

Thanks for the code snippit. I have been planning on trying my hands at creating my own ruleset for a while now and had waited until v2 came out and then had been waiting some more because of the recommendations to wait until the patches had slowed down a bit. But perhaps it's time for me to start working on my own ruleset so I try and get rid of some of the new D&D only code that seems to have been added to the program with v2.

While I understand wanting to add features to appeal to the D&D market, I really don't understand the removing of some of the original ways of doing stuff in the process, have both. Grid to snap is a perfect example. Why not have it default to on if you want, but have a toggle to turn it off.

[Toadwart]

I'd raise it with the developers as a feature request: ability to turn off/on snap to grid. There are even some of us DnD 3.5 players who would like to turn it off ;)

[Alarian]

Thanks a lot Joshuha for the code, I just created a ruleset and tried it out and it works great.

Alarian.

[joshuha]

You could even make your own toggle. Just have it read a variable you store in the CampaignRegistry that only if its on does it call the getClosestSnapPoint.

[Ged]

Dis-/enabling grid snap is something that has evaded the patches but is not forgotten. We've considered it to be connected to a few other improvements and thus it has remained as is, although for overland maps and systems other than d20, it is an important "feature". Joshuha's code does the trick, but admittedly disabling grid snap should not require any customizations.

[andirving]

Continuing the above code to disable snap to grid, this will allow pointers to be arbitrarily sized + positioned, instead of being limited to 5' increments.

Replace the onPointerSnap function in the same file with:


function onPointerSnap(startx, starty, endx, endy, type)
local newstartx = startx;
local newstarty = starty;
local newendx = endx;
local newendy = endy;

return newstartx, newstarty, newendx, newendy;
end

Also, to allow more accurate token movement (not 5' increments, again), replace the onMeasureVector function (same file again) with:


function onMeasureVector(token, vector)
if hasGrid() then
local diagonals = 0;
local straights = 0;
local gridsize = getGridSize();

for i = 1, #vector do
straights = straights + math.sqrt((vector[i].x * vector[i].x) + (vector[i].y * vector[i].y));
end

local feet = math.abs(math.floor(straights * 5 / gridsize));

return feet .. "\'";
else
return "";
end
end
Of course, ymmv, but it's working well for me.

[NymTevlyn]

You also can no longer walk 2 abreast down a 10' wide corridor because you can only have 1 player in the center of the hall or two people standing in the walls (which then makes them disappear if whats on the other side of the wall isn't revealed.
If you can't place two tokens side by side in a 10' wide corridor, the grid is the wrong size or the scale on the map is wrong.

[andirving]

I think the issue with placing two tokens side by side was that with the grid turned on, the tokens would snap to the center of the nearest grid square. If your grid didn't happen to line up with each and every corridor on your map perfectly, your token would snap into what should be inaccessible space (ie, a wall). You might have half grid square + full grid square + half grid sqaure in your hallway / curving tunnel / whatever, and no ability to easily place two tokens next to each other. You might be able to make the grid several times smaller and thus have more snap points, but then measurements get screwy.

[Azrael Nightstar]

Not to nitpick Ged, but since this is a fairly simple process, why not bump it up the to-do list regardless of the related features? I can see how doing all of them at once makes sense but this is getting asked a LOT, and it seems like even if whatever you do in the future with the related functionality undoes a "stopgap snap-to-grid toggle", you won't have lost much time or effort. I could be wrong, but to us non-programmy types it seems like these fairly simple code changes should equate to fairly simple feature build-ins.

Of course, there's no guarantee that if you put this in now you'll undo it with a future update. Might even be useful to have a basis once you get to the related stuff further down the line :)