Hm. That's likely the putToken() function that's part of the map object; it gets called whenever a token object is changed, such as it's (x,y) location on the map. It could also be the fog clearing that goes on for each step of the path. I'll take a look.lmarkus001 wrote:Configuration: 9 clients, 1 server
Server (no human interaction on this machine): WinXP-32, recent Java
Clients: Win7-64, Win7-32, Vista-64, Vista-32
When I would move a token on a client, both the client and the server would show the movement path real time, but when I would drop the token to complete the move, the server would take 4+ seconds to register the move.
That doesn't make any sense. At line 1710 of that source file is code that retrieves the MapToolServer object and then tells it to update the server policy. The NPE is because there is no MapToolServer object -- but that can't happen.When I turned on Lock-Player-Movement (GM client connected to the server) I received this error:
Code: Select all
java.lang.NullPointerException at net.rptools.maptool.client.AppActions$50.execute(AppActions.java:1710) at net.rptools.maptool.client.AppActions$ClientAction.actionPerformed(AppActions.java:2691) ...
Heh, no worries. I will check out the "move when it's not your turn" and see if I can reproduce it.Additionally players randomly would get the mouse-move error (this especially occurred if they tried to move their token when it was not their initiative). I thought my players had recorded the error and posted it up for me, but it seems they just gave me lip service... sorry.
I look at differences in the code back to b83 and don't see anything related to the movement locking being changed. Are you saying it was fine in b83 or that it was fine in whatever version you used prior to b84 (such as b81)?Anyway, lock-player-movement continues to be broken (it has been broken for 84 onward, but was fine before that).
Okay, I'll take a look. I remember looking at the code previously and thinking that it was fine.Typing Notification
When I had multiple people tying and running macros, performance got hammered. Once we disabled Typing Notifications performance became MUCH better. This is NOT new to b85.
Well, we're in "no new features"-mode. This is only there because it looked like it was in there originally and I could justify fixing the bug because it was so easy. But there won't be any UI elements added to support it in 1.3.Shift Mousemove
My players really appreciated this feature, but suggested there be an application setting that lets you choose if Shift-Move hides or displays the statsheet, if toggled, then the default would be to hide the statsheet and you would need to hold down Shift to see the statsheets.
I replied to your post in the Bug Reports forum.Very Busy Map / Map-Export-Import
My group is on a very busy map so I exported it, then imported and reset the fog. I then ran with global fog (not individual views). No one noticed particularly bad movement performance. But I did discover errors/oversights in the export-import mechanism.
When a map is exported then imported, the following token properties were lost:
There's no point in using the import feature to clear the fog. You can do that by: (a) deselecting all tokens and then using the fog toolbar to draw fog over the entire map, then (b) selecting all tokens with HasSight and drawing fog over the entire map.
The first one erases any "global fog" that may exist (typically created only when the GM manually exposes fog). The second one erases any token-specific fog and that's why tokens need to be selected. You'll notice a purple glow around the selected tokens when you click the fog toolbar button. Part (b) only works with a server running since that's the only way to turn on Individual Views/Fog.
Doing a test just now I had a problem with how fog was exposed. I'll relay my test to Joe and see what he can come up with.