Some feature suggestions.

[Evilnames]

From a couple games here are some features I would find interesting. (Also ways to implement them.)

1)Double sided counters - Expand the system to make it marketable to wargamers. Do this by having a double sided counter option. Add a 'right click' menu item that says 'flip.' Ways : Just store it in the class somewhere? Also add a hot key CRTL+A or something. As for how to set it. When you add it into the program in its property menu you could have a image selector, where u could possibly drag the image there? Or a browser box.

2)Hotkeys - These may exsist in some areas. But one area that does need a hot key is the 'facing,' since alot of the time facing takes along time with the right click method. Would be much quicker too do via a hot key. CRTL+B maybe?

3)Set default 'image type' When importing alot of counters each one must individualy be set to 'top down.' It would be nice to have a preference to select the type you could have all things set at. And also one that 'lets the computer choose.'

4)Split dice - An option to roll 4d6 and have it show 1 2 4 5 = 12. (Suggestion via Dirk sry)

[Steel Rat]

I guess I haven't played the kinds of warames you have. What does "flip" do?

[trevor]

Thanks for the feature list Evilnames

1) I'm imagining flip mean to have a hidden side, kinda of like stratego or something. Which really boils down to allowing a token to have multiple images. This is certainly possible, I think one of the tricks (assuming the purpose is to hide one face from others) is how to determine which images are available to be see by which players

2) Agreed. Azhei has made some progress proposing a consistent set of keystrokes, you might get with him and coordinate some options. I'll add the specific case of facing as a tracker

3) MapTool actually makes a guess based on how many transparent pixels it finds. If you have some specific examples, send them over ([email protected], or me directly) I could see about making the algorithm smarter about picking the right type. There has also been a feature request that will allow you to specify properties on all images in a directory in the image explorer. I'll make sure it's noted that more people are interested in that (affects priority)

4) I'll add a tracker for this one, I don't know if I'll get to it before the command shell rebuild, but if it turns out to be pretty easy I'll drop it in during the next couple dev builds.

[Evilnames]

Sry for the crappy quick graphics here. I do actually have examples of real world things but haven't cut them out yet :p. Anyway. The process is if something gets damaged during the game you could just flip it over to its damaged thing. This does a couple things. 1)You do not have to drag a new token into the program 'mid' way through. 2)Easier to set up campigns and stuff... and of course you can write board games and stuff and use them in the program. Alot of wargames come to mind with this. Any time a piece gets attacked or something and has to be 'reduced' it could be flipped. In an RPG setting I thought up a couple useful ideas. If for example you had a coach and then something hit it or something you could have a 'destroyed' counter which is flipped over in its place. A character token which shows damage or something of this sort .

With the coding aspect. Is it not possible to have it be set? And then later on do a function call which just switches the image? (I looked at the code. But I am horrible with Java sorry. I've never been able to get the hang of it. Other wise i'd try my hand at writing it into the software (Still might.))

On #3 - This is a good thing. In fact the program is 'to' good at this . It knows a square when its a square. But a square can also imply a top-down? The way I see it the only thing i've had show up as a top down on the first try was a misshapen space ship (Which was actually side view) Most of the other stuff goes square. An option to allow the program to default set these would be great.

Thanks for responding
-Alex

[trevor]

So is the flip feature just a matter of having multiple images that can be swapped, and doesn't require specifying who can see which images ?

If that's the case, that's pretty easy to do.

[Evilnames]

Yep. Doesn't matter who sees the image. Because the property of the image will still be set to the orginal image if that makes sense? Just a swap function.

[trevor]

Yep. Doesn't matter who sees the image. Because the property of the image will still be set to the orginal image if that makes sense? Just a swap function.

Cool, I'd add a tracker. I expect that I won't be able to do it until the graphic pipeline rebuild since it'll take a restructuring of the way tokens are associated with images.

[Richard Weimer]

As a long-time wargamer myself, you might want to consider not just a "flip" mode, but a "replace with" mode instead. I know of a few wargames where a counter is slowly replaced by not just one "damaged" counter, but a series of progressively-weaker versions. The old Avalon Hill wargame "Anzio" comes to mind (still one of my favorites).

[trevor]

Yeah, that would be good, be able to assign any number of images per token.

[IMarvinTPA]

I had an idea about this this morning, text files in a folder that list the images a token or stamp use.

IE:
[token_name].tok
image1.png
image2.png
image3.png
...

or
[stamp_name].stp
image1.png
image2.png
image3.png
...

All the files listed in the file would represent different "sides" of the pog. This would help in preparing them, and it would be much easier to do than to try to set them up in the gui. There'd still need to be a way to do it in the GUI, but this would be the quickest way to add in the basic feature and build up.

Are stamps snaped like tokens? Could I use a 5x10 token as a door?

IMarv

[trevor]

That's similar to what I had in mind, although I'd zip up all the images together and put the descriptor in with it.

I was thinking of extending TokenTool to support multiple frames, either for animation or multiple image states.

Stamps are nearly identical in form and feature to tokens so you can absolutely create doors, windows, whatever. At some point I'll support setting pivot points on the token so doors will swing on their hinges.

[Evilnames]

Another thing that would be interesting to see is 'User defined variables.' This would be all local client software imo. So the GM could have like...

/Var Turn +1

or something like this. It lets you keep track of local variables needed? Is this already in the program?

[trevor]

Not already in the program, but it planned

[Azhrei]

That's similar to what I had in mind, although I'd zip up all the images together and put the descriptor in with it.

I was thinking of extending TokenTool to support multiple frames, either for animation or multiple image states.

Wow, that's sounds pretty cool!

So will the individual "image state" images be capable of being animated?

I'm thinking of a UI that involves a listbox on one side and an explorer tree on the other side. Images dragged from the tree to the listbox define which images will be used and in what order. The listbox will have strings used to define the image that goes with a particular state.

The listbox might have 6 states in it by default (dead, prone, etc). Dragging the "dead" image and dropping it on top of the row for the "dead" state would cause the two to be associated.

The listbox is then used to determine what to store in the zip file and how to build the manifest file. This technique would allow TokenTool to stay as it is, except for adding frame support so that animations could be created.

[trevor]

Yeah, something like that