RPTools.net

Once again, no new features in this build. Instead the focused was primarily on performance gains.

In that regard, we have made some pretty significant gains but it appears that the Individual Fog option may still be too much work for many machines. If you are using Individual Views and Individual Fog and finding that you have a performance lag, please try starting your server without Individual Fog enabled. If that solves the problem you can run without Individual Fog in the future. That's the default mode that MapTool 1.3 has used in the past. (Individual Fog is a relatively new feature -- it's only been around for the last 6-8 builds, in various levels of completeness.)

I would like to spend more time on the performance issue, but my RL schedule is going to preclude me working on MapTool in the manner I have for the last couple of months. So I need to get the source code locked down and checked into Git so that 1.4 can start.

As always, bug reports related to this build should go here. More general problems -- things that have been out there for awhile -- should be posted first in the MapTool forum (and someone will move them to Bug Reports when they've been confirmed).

Thanks for hanging in there, everyone!

P.S.: If you haven't contributed to the Documentation project for 1.3 please see the Documentation forum for the thread. We have decades of experience gathered here on the forums. Writing down that information is like leaving in inheritance for your children -- and you wouldn't want to leave your kids penniless and struggling to survive, would you?

Thanks. Thanks. Thank you very much! ( )

DJuego

and yet again congrats with yet another step closer to the next step. As for the 'document project' those interested, link can be found in my sig. (at least at the time that I write this).

Az, I was wondering, has there have been any performance changes between b82 and b86?? Im still in 82 with my FW and up to now everything works fine. As I mentioned earlier I did accidentally loaded it in b85 once and had a performance issue after 20min or so. That is standalone, vision off, FoW off. I was just working on the framework.

I've tried this new build, as I prepare for tomorrow's game, it seems to run smoothly. I'll use it for the game tomorrow and give IFOW and conic vision a thorough test. As well as the new hex grid movement/vision calculations.

Most of the performance related fixes have revolved around Individual Fog, but as I went through that code I also made minor updates in a lot of other places as well. Many of those other locations are not code paths that are hit very often though, so they are unlikely to impact users during a typical game session.

I haven't updated the ChangeLog for this build (I still need to do that) but the individual changes are so tiny that there will likely be a single entry that says "performance fixes".

I have checked to make sure all source files have the Apache License mentioned at the top of the file. And I started fixing the 700 or so warnings that show up in Eclipse (I only got about 70 of them done). That's going to be a big job and I'm going to leave it for 1.4.


Thanks!

As I've pointed out before, we still don't have movement blocking yet. So the grid movement is simply checking the exit from the current cell and the entry into the final cell to determine if the movement is allowed or not. Hopefully this prevents players from being able to "move into a wall" and then getting stuck. Most players don't know about the MapExplorer so they won't be familiar with using the NumPad keys to get themselves "unstuck".

I'm also going to use it for my Tuesday night game, I think. But I better get a note out to my players about that so they have time to get it downloaded and tested.

Seems to work a treat on my Kelmerane map which used to take a while to draw. Just need to see if it works this well when someone is connected. BTW: Great work!

I'm not sure I understand the lag issue. Does the lag occur on the clients or the server? If it is a weaker PC that is the victim of lag is it the server that is too weak or the client?

In the last few session of running B84 my group has complained about lag but it is only the clients that seem to suffer. I run on the server and don't experience any noticeable lag.

A couple of players who are in different games claim that using Himachi will fix the lag. Is there any possibility they are right?

All work is done on the client (graphics, macros, etc). The only thing the server does is relay what the clients are doing to the other clients. For example, client A drags two tokens at once while client B is dragging a token as well. Obviously there's network traffic involved -- each clients send their drag operations to the server who then relays it back to all (other) clients so that the other clients know how to draw the dragging tokens.


There is a fair amount of network traffic. It's not a problem because of the amount of data, but because a machine on one end has to wait for the result before it can do anything (such as drawing the dragged tokens, above).


I assume you mean "Hamachi". It's unlikely. If anything, using Hamachi will be slower as it adds another layer of software to the networking stack. (Hm. I suppose if your machine's network layer is screwed up in terms of how it buffers packets before sending them, maybe a VPN layer would help. But if that's the case the proper solution is to tune your network stack. See speedtest.net or Google for "window network tuning" for more info.) MapTool turns on TCP_NODELAY so I wouldn't expect that to be a problem.

On this last point I wondered if there's a difference in the way the Numpad works with squares and with hexes. Having made a quick test, not surprisingly it's a mess with hexes

May I suggest a change in the way Numpad is handled in this case, at least in 1.4. Because players evolving on a hex map would have a tough time using it if needed.

This would imply having only six keys working with hexes, as there's only six possible directions.

In the Map Properties panel there's two hexes options, the first I would call horizontal hexes, and the second that I'd call, you guess it, vertical hexes. In the first case I suggest using the upper and lower key lines, which is to say "7,8,9" and "1,2,3". In the second case, the left and right key rows, meaning "7,4,1" and "9,6,3".

thnx for the elaboration! I guess the only way to know how the pie tastes is by eating it.

Heh-heh. Glad you like it...


That's as good a solution as any, I suppose.

Of course, the user can simply use those same keys right now and achieve exactly the same effect. (Well, if it's working the way it's supposed to, anyway. But I never use hex grids so I haven't personally done much testing with them.)

I actually expect that a lot of things grid-related will migrate to the realm of "user-defined". For example, the shapes used by the various token sizes for hex grids, or the centerpoint of rotation when facing is changed for those sizes that are not a single grid cell. But that's a discussion for another thread...

First, thanks for a quick as usual answer Azhrei.


Well it's worse the half second it took me to think of it. Yes, you can believe it, all of a half second !!!


Well, I'm afraid not. That's the quick test I made. Just open any map, empty or not. Put a token on it if there's not already one. Turn the grid to squares and use the Numpad to move the token. All is going perfectly well. Now turn the grid to hexes and ask for the same moves… rock'n roll ! You can now see your token dancing all over the place and almost teleporting some times

OK, I verified this bug and it was introduced in b85.

I pinged Frank on the details. Thanks for the heads up.

Heh, figures. I'll look at it.

It really should be fixed by having the Grid object define what the keystrokes are and which direction they should move the token. But there's no interface for that and the existing code is hard-coded with things like "NumPad7 moves up and left, NumPad3 moves down and right" and so on. But the hex grid already adjusts either the X or Y coordinate depending on which type of grid it is (horizontal or vertical) and that's likely why it's jumping around so much.

But I'll see if there's a quick fix for now.

Well, sorry for the bad news, but thankful for all that's working perfectly well.