Open ended Macro's

[GreenMan]

Not sure if this has been addressed yet...

I was wondering if there are any plans for open ended macros (meaning macro's that can drop some text into the chat window without executing it.) Example: a "Whisper" macro that will automatically add a "/w" or "/w player name", then wait for me to write the text and have me manually hit enter. (This is especially needed for players with really long and/or unusual names.... )

Or.... so I can build an attack button that waits for me to add that temporary +/- mod for prayer, flanking, dazed, etc so I don't have to type the whole thing each time my "normal" status changes.

[torstan]

Yep, already there

In the main Macros window, when you edit a macro button there is a tick box called auto-execute. Uncheck it and the macro will send the (first-line) of the macro to the caht input and you can append text at your leisure. It doesn't work for token macros yet though.

[GreenMan]

Awesome... the RPTools team is always way ahead of the game... I guess it's just a matter of future documentation and me learning the tricks.

I know alot has been said in the past about documentation... but consider this, Trevor: You've got a great program and have our group sold... we are all using MT now... and even played a game yesterday with players in different states... Now... imagine if we really knew all that it could do... it would jump from "great" to... well... I guess we'd all be speechless.

Keep up the great work.

[RPMiller]

This is an excellent point, and I think that Dorpond may be able to help.

Dorpond, have you considered keeping a log during your demos like trevor does in his games? That way whenever one of the current MT users says something like "I didn't know it could do that!" You could add the feature to your log and when the demo is finished you add it to the documentation. I think that would be a great way to compile docs.

Of course then we would have to have someway to get people to read them.

[Full Bleed]

Dorpond, have you considered keeping a log during your demos like trevor does in his games? That way whenever one of the current MT users says something like "I didn't know it could do that!" You could add the feature to your log and when the demo is finished you add it to the documentation. I think that would be a great way to compile docs.

How about one of those "Tip" pop-ups when people log into the program? (with the ability to turn it on and off, of course) All of these questions regarding features that aren't well-explained in the program could be slowly added to the Tips. And people could sit there and click through the tips to learn stuff in bite size chunks instead of being expected to read a thorough doc that most people won't read. The arrow/thought bubbles/speech bubbles for example, is very typical a feature that people don't learn about for a long time.

[GreenMan]

The Tips idea is great but we'd just have to make sure that it stayed consistent with the manual. I can easily see it getting information that the manual doesn't have then we are back to the same problem.

Perhaps a thread that discusses little known tricks of the trade....?

[Azhrei]

Hmm. There could be a list of FAQ entries that MapTool could pull from the web at startup. They could be per-version, so that they were always up to date. If they were part of a wiki (rptools already has one of these), then others could add tips on how-to-use as well as keystroke or mouse usage.

[trevor]

I don't know about you guys, but the first thing I always do when I see those is turn them off.

Documentation is becoming more of a necessity of late. Once the big features settle down, I'll dig my hands into it.

[dorpond]

I don't know about you guys, but the first thing I always do when I see those is turn them off.

I always leave them up until I know the application, then I turn them off.

Trevor, I would be happy to generate a Q&A list and send it to you in case you implement something like this.

[Full Bleed]

I don't know about you guys, but the first thing I always do when I see those is turn them off.

I turn them off too.

But I wouldn't if I actually had some real issues about not knowing how to use a piece of software that had poor documentation . Usually, I'm not not interested in what tips have to say, so off they go.

What I'm advocating is some way to put repetitive questions and "hidden" features into an in-program and accessible format.

We already know that the documentation will NEVER be up-to-date for MT. First, because MT evolves too quickly. Second, because no one wants to work on documentation. And Third, because people who actually read docs are in the minority.


Every time the question of docs come up I think that people need to have a reality check when it comes to MT (and most other free or small company projects.) The developers are largely going to spend their time doing what's fun. Not doing stuff that feels like "work." Doc work is generally drudge work. Hence, it will almost always have low priority. And in projects that have a lot of high priority stuff on deck, low-priority stuff gets buried.

The Tips idea is great but we'd just have to make sure that it stayed consistent with the manual. I can easily see it getting information that the manual doesn't have then we are back to the same problem.

I don't agree. If you set that as the bar for implementing Tips (or something like it), there never will be Tips (or something like it) because it will just be argued that, "Why do we need tips? It's all in the docs."

Maintaining great docs would be a lot harder than dropping in the occasional tip. So, for the most part, I was just trying to think of some information delivery system that the developers (and users) might actually occasionally use without setting up some documentation goal that more than likely won't be met.

Something is better than nothing.