RPTools.net

I'm looking for some Maptool developers to help answer this. Or at least someone that knows a lot more about Maptool than I do.

This is a summarized version of a discussion I started here on VBL Slowdown: http://forums.rptools.net/viewtopic.php?f=3&t=27349

With Snap to Grid on, the players cannot move. It's like a constant snap back whenever they try. But when StG is turned off, they can move easily.

The details:
Maptool v.1.4.05
Java 64-bit
Windows 7 64-bit
Processor: 2.1 Ghz dual core
Graphics: ATI Radeon 512 MB Dedicated Graphics Card
MaxMem: 2048 (on a 4GB laptop)
StackSize: 4
Vision Range: 120
The campaign file size: 5.66 MB
Grid: Hexagonal
Wireless LAN: ~40 - 50 Mbps, Ping: <20ms (100 Mbps wired connection)

On Server start, Players can Reveal FoW, Auto-Reveal on Move and Individual Views are checked. Individual FoW is not checked or anything else other than the three options listed.

At our last gaming session, we turned off the StG and finished the game that way while using Control+I to reveal the map as the players moved through it. This is an okay workaround but having the option for using auto-reveal on movement would be our preference. So my ultimate question is this: How can we avoid the lag issue and still use auto-reveal?

Snap back could be because the top left corner clipped some vbl. When STG is off then the token move point is calculated from the center of token. For caves and tight spots, turning off STG is best.

Btw, here is an example of how I do vbl for caves: http://forums.rptools.net/viewtopic.php ... 77#p225029

The more points of the vbl, the more lag you'll have. It can't be avoided. Thing that help is clearing the individual views every so often, especially when the lag become unbearable. Also, reduce the map vision distance to 120 or even 60. Less vbl will be processed so shorter times to calculate. I believe not using individual views will also reduce lag since the vbl will be stored only on the server rather than each token. You still may need to clear views to remove old vbl data on tokens even when not using individual views.

aliasmask wrote:Snap back could be because the top left corner clipped some vbl. When STG is off then the token move point is calculated from the center of token. For caves and tight spots, turning off STG is best.

Btw, here is an example of how I do vbl for caves: http://forums.rptools.net/viewtopic.php ... 77#p225029

The more points of the vbl, the more lag you'll have. It can't be avoided. Thing that help is clearing the individual views every so often, especially when the lag become unbearable. Also, reduce the map vision distance to 120 or even 60. Less vbl will be processed so shorter times to calculate. I believe not using individual views will also reduce lag since the vbl will be stored only on the server rather than each token. You still may need to clear views to remove old vbl data on tokens even when not using individual views.

Thanks for the link. I will give that a shot.

How do I clear individual views?

aliasmask wrote:Snap back could be because the top left corner clipped some vbl. When STG is off then the token move point is calculated from the center of token. For caves and tight spots, turning off STG is best.

I do not experience this behavior. If a pc moves into VBL their token might vanish, but they don't snap back. This isn't the OP's problem.

Thing that help is clearing the individual views every so often, especially when the lag become unbearable. Also, reduce the map vision distance to 120 or even 60. Less vbl will be processed so shorter times to calculate. I believe not using individual views will also reduce lag since the vbl will be stored only on the server rather than each token. You still may need to clear views to remove old vbl data on tokens even when not using individual views.

The OP said that they were using Individual Views, not Individual FoW. "Individual Views" are not stored on the token. The clients are just calculating the view from only their token. With individual Views (and *not* individual FoW), the tokens are sharing one, global, FoW.

J.P. wrote:On Server start, Players can Reveal FoW, Auto-Reveal on Move and Individual Views are checked. Individual FoW is not checked or anything else other than the three options listed.

You previously indicated it was only one player who had the problem... is it all of them?

Full Bleed wrote:

J.P. wrote:On Server start, Players can Reveal FoW, Auto-Reveal on Move and Individual Views are checked. Individual FoW is not checked or anything else other than the three options listed.

You previously indicated it was only one player who had the problem... is it all of them?

All of the players are sharing the same computer as the single client. One player has been controlling the group movement for the most part by following the rest of the players' instructions. The problem is not limited to any one specific token.

Can you post the campaign?

One issue I encountered while doing some development was I storing way too much data on a token (I was storing large chunks of text and several images) and I was getting massive lag and tokens snapping back. Moving the data off token to assets helped a lot.

Every move/change to a token causes that token to be transmitted across the network and if the network is poor it could cause snap back (the client/server code doesn't handle out of order requests well).

There could be other reasons to, but posting the campaign may help.

Full Bleed wrote:

aliasmask wrote:Snap back could be because the top left corner clipped some vbl. When STG is off then the token move point is calculated from the center of token. For caves and tight spots, turning off STG is best.

I do not experience this behavior. If a pc moves into VBL their token might vanish, but they don't snap back. This isn't the OP's problem.

If the token can't enter the square, it snaps back to start position. If it can enter the square but STG moves them on to vbl then they disappear. This is usually the case when vbl doesn't follow the grid. This is MT default behavior, but I've been playing with my own movement mod that prevents this and just simply stops the token at the edge of the vbl.

aliasmask wrote:

Full Bleed wrote:

aliasmask wrote:Snap back could be because the top left corner clipped some vbl. When STG is off then the token move point is calculated from the center of token. For caves and tight spots, turning off STG is best.

I do not experience this behavior. If a pc moves into VBL their token might vanish, but they don't snap back. This isn't the OP's problem.

If the token can't enter the square, it snaps back to start position. If it can enter the square but STG moves them on to vbl then they disappear. This is usually the case when vbl doesn't follow the grid. This is MT default behavior, but I've been playing with my own movement mod that prevents this and just simply stops the token at the edge of the vbl.

Not seeing this "snap back" behaviour. Maybe you're not making some distinction... or, at least, I can't replicate it.

VBL does not stop a token from entering a square. Turn off the FoW and you can move into VBL (regardless of how much of the square the token is moving into is covered) without being snapped back.

And while FoW *will* stop a token from moving into an unexposed area, it's not snapping the token back. The token is just stopped at its edge.

Please provide instructions on how to replicate this snap back effect.

You're right. I just recalled where I've seen that behavior before. It was with a framework where if you had vision off and moved an NPC it would snap them back to original position. This probably isn't what's happening with OP. I've also seen this happen when multiple players have ownership of a token. If one person is accessing a token (not sure if selecting counts) then when the other person moves it, then it will snap back when the other person is done accessing. STG shouldn't make a difference, so that probably isn't it either. Is the OP using a framework and if so, which one?

aliasmask wrote:I've also seen this happen when multiple players have ownership of a token. If one person is accessing a token (not sure if selecting counts) then when the other person moves it, then it will snap back when the other person is done accessing.

Yeah, I've seen that when I (GM/Server) was messing with a player's token while they were trying to do something, too. From their perspective the token is snapping back... but I think that's a concurrency issue where conflicting information about where a token is during various updates hits the server at the same time. Network problems can interrupt an update too and create a "snap back" effect (i.e. the player moves the token, but the update doesn't make it to the server, the server pushes an update and the token "snaps back" to where it actually is.)

STG shouldn't make a difference, so that probably isn't it either. Is the OP using a framework and if so, which one?

Going to have to see once they share their campaign... the mystery might be easier to solve when it gets more eyes on it.

aliasmask wrote:You're right. I just recalled where I've seen that behavior before. It was with a framework where if you had vision off and moved an NPC it would snap them back to original position.

Wolph42's Bag of Tricks has that function. So I've seen that behaviour on a few frameworks that use the BoT