is there any documentation for this program, so far it looks pretty neat but I can't figure out how to do certain things, like set myself as GM or making the type command window bigger. Experimentation is grand but :???: =)
Right now the documentation is all presented on the Home Page: www.rptools.net. We are in the process of reworking some of the home page content and noticed that a few of the links were broken. Here is a direct link to the MapTool documentation.
To set yourself as the GM, do a File->Start Server. It will pop up a dialog.
hmm i have been testing out the networking and it doesn't seem to like me... has problems redrawing the screen and hogs all my bandwidth for minutes at a time when there's no pictures added... pictures dragged onto the screen as tokens don't correctly detect width/height and there's no obvious way to change them.. other than that it looks alot nicer than gameboards =)
If there's one feature it really seems to be missing it's a "write text" button, using a mouse to write is fun at first but gets boring fast. It'd be nice to have some kind of folder where you could just drop files to "preload" them so you don't have to worry about the program not being able to find the files your computers share.
Overall I give it a C+ since it doesn't work over my modem but works great otherwise. I'll keep watching you guys, maybe the networking code will improve somehow.
Could you tell me more about the screen redrawing issues ? Was it that it was drawing really choppy, or that some things weren't being drawn, or that there were artifacts showing up ?
Unfortunately we all use broadband so we haven't had the opportunity to test it over modem. Let us know if you'd like to help us profile a modem connection and we'll set something up. Note that when you add an image to a map, or add a map, it has to send the image to all connected parties, which may take a while if it's either a large image or have several people connected. Typically you will want the server to run on the computer with the most bandwidth. Note also that moving a token around causes updates to be sent to other players, which might account for your bandwidth usage.
As for the text tool, funny you mention it, I just checked in the code last night. It should be available on M6 Alpha on rptools.net later today. It's a very basic implementation, but is easier to use than the mouse :)
Could you describe "preload"ing images ? You can add a directory of images to the left side panel (Image Explorer), which it remembers between runs. And if you add images to a map, then File->Save Campaign, those images get saved into the resulting campaign file.
The token resizing issue takes a bit of explanation. It is working as intended. The map has an implied grid of squares. You can make the grid visible or invisible (there's a toggle button). For each bounded map you can adjust the grid to suit the size and position of the grid lines. Each token by default takes up exactly one square independent of image size. This is so that you don't have to worry about the exact size of your image, it will be rendered the right size according to your grid size. You can change the size of tokens by selecting it, right click, pick Size->whatever. In this way you can use the same image to have different sizes for different tokens. As a related side note, you can turn Snap to Grid off for tokens, just select, right click and uncheck Snap to Grid.
As we're still madly working towards a 1.0 release, we hope you'll stick with us and continue to provide great feedback to help us make this tool totally rock.
the screen redraw issues were generally the kind of issues you get when the program isn't the active window and another window gets on top of it; eg if you resize the window, you get whitespace, if you make the program's window on top, the whitespace is still there. Also there seemed to be a minimum size of the screen, such that if the screen was maximized and then i resized it to a quarter of the screen, the map selector was moved off-screen and so were the slash commands.
The issue isn't with the size of the images being added; it doesn't take 3 minutes to send a 40k file to one person. Gameboards doesn't have this issue, and its pretty clear when you drop an image it doesn't take very long for it to load. Even with the drawing, and dropping pictures on, and other stuff,
It would just start using 90% of my internet connection (which, in itself, is quite impressive!) and the only way to get it to stop was to disconnect from the server and reconnect, which usuallly resulted in about a minute of lagging loading time, and then it worked again.
Also sometiems it would just be locking up after someone added a picture, and my internet utilization would only spike to about 5% and still not let me see anything, which doesn't really make any sense at all but I assume it is somehow related, but since i couldn't really reproduce it reliably (sometimes swapping maps would cause a bandwith spike, sometimes not), its not really clear if that's the problem, but I didn't have any of these problems when I was just using it without being connected to anything, so that must be it.
I would be cool working with making a modem profile or whatever, but I don't really think that after last night anyone in my group is interested in dealing with the program again.
Preloading images would be sending an image to other people in like a zip file, a common set of tokens that are in there at the start. Apparently they are in the campaign file, which I could then email to other people (thought it looked like the campaign file just had an absolute path reference to the actual file on my hard drive), but can they all load it at the same time?
also the problem with dropping images is different, I don't have a problem with it fitting in one square, but if I drop a rectangular image in, it becomes square, maybe you could just add some whitespace or something to the image so it doesn't fill the entire square and keeps the proper dimensions?
anyway i will keep an eye out but I don't know Java =) so there's not a whole lot I can do except congratulate you guys on alot of hard work.
Redraw Issue: What kinda of computer (graphics board, cpu, memory), and operating system are you using ?
Networking Issue: Would you be willing to coordinate a time we can connect up so I can run a debug version against your modem connection ? I'd love to profile that, get it tight :) This would also help me see what the locking up is when adding an image.
The preloading images idea is a really good one. Would certainly help the image distribution issue. We have a tracker issue about creating image repositories. I'll piggy back image preloading on that issue. Thanks for the idea :)
Image Size Issue: Hmm, I see what you mean. Let me get with the lead designer and figure out how we want to handle that.
I super appreciate you taking the time to provide play feedback. Hopefully as we get enough feedback we'll be able to get the tool to the point that your friends will be willing to give it another try :)
> The preloading images idea is a really good one.
> Would certainly help the image distribution issue.
Lemme see if I understand this one. You want to have a "cache" of images, toens, entities, assets, resources, whatever, that the server can send to the client. Then, during game play, when the DM adds an entity to the map, the client grabs it from the local cache.
A. Do you see this as being an automatic function, i.e. when a client logs in, the server automatically sends the cache, or as an on-demand thing such as prior to the game, the DM e-mails a file to the player, who then copies it into the appropriate directory on his local machine?
B. What happens to items that the DM loads after the start of the game? Are they automatically sent, but not displayed until the DM displays, or are they sent JIT for the client to use them?
Currently, when anyone adds an image that hasn't been used before, it gets sent to the server (whoever is hosting it). Then, when the other clients attempts to draw the new image, it requests a copy from the server, while it waits for it, it shows a red question mark. So, new images are distributed out to the other players dynamically. So that's not a problem.
Additionally, MapTool has an internal cache of all images it's seen, kinda like how a web browser caches images. When MapTool attempts to draw an image that isn't already in the loaded images, it looks in its cache on disk. If the image has been seen before it will use the one from its cache. This has particular value when you get disconnected, or (heaven forbid) the client crashes, you can restart the program, reconnect, and all the images it had already loaded don't have to be re-requested.
The original poster's idea was to make it possible to distribute a respository of images before game day, that can either be preloaded into the internal MapTool cache, or in some other way made available, then nobody has to sit around waiting for images to load from the server. This is particularly useful for people on dialup.
I've added a tracker issue to keep images in the proper aspect ratio
I'll get it coded in the next couple of days.
Log in to post a comment.