RPTools.net

On the machine that is asking for the macro to be executed.


Even that is not "secure", depending on your definition of that word. It's possible for the server to be running a hacked version of MT for example (since source code is readily available). Since the JS must be readable to the engine, even if it were encrypted somehow MT would have to decrypt it before giving it to the engine so somebody who wanted to cheat could hack MT to display/modify the code at that point.

This is essentially what GreaseMonkey does for Firefox; it allows a JS programmer to add/change/remove JS code that the web server sends to the browser. I use this for a couple of sites that are broken and need to be fixed to work properly.

MT will only allow the GM to create JS macros, but a player could run a hacked version of MT that allows them to add their own macros. It's not practical for us to obfuscate the process just to discourage such cheaters.

Our primary goal in terms of "secure" is to ensure that the stock MT will not allow access to local files or make network connections to machines other than the server (the same basic kind of "sandboxing" that browsers do) without explicit approval from the user. For the time being we've wanted to avoid having a popup in the middle of the game that says "So-and-so macro wants to create a file in directory such-and-such. Do you want to allow it?" That would get annoying very quickly and users are just going to click OK every single time anyway (which is why UAC is such a failure). So we currently protect them from themselves by not allowing macros to write to local files at all.

At some point we may revisit the "secure" aspects again, but it's always easier to be conservative and loosen the reins later than to be loose and then tighten them.

As a recent adopter of git, this is exciting to me


WAAAY back, when I was actively playing around with Macros, I used to dread this. Now, I'm excited to try to re-build my grand vision using a 'more real' / less frustrating language.

I'm also very excited about:


I'm happy to see MapTool development is continuing along. Maybe not as quickly as some would like, but still familiar enough that I'd be excited to start using it again, assuming I have time after finishing my PhD and getting "a real life".

Keep up the great work!

A feature I would be very keen to see updated for 1.4 is the Chat Log.

Saving and reloading the chat log is a must, but I would also like to see something similar to the way Skype manages past chat. But whereas Skype groups chat by "Call" Maptool would group chat by "Session". Maybe allow the GM to mark the end of one session and the start of another?

So when you scrolled to the top of the chat it looked something like:

And expanding a previous session would effectively open another window, to the previous chat log.

Cool idea. We have plans to add "multi-channel" support to chat to allow for multiple separate chats at the same time (maybe in 1.4, more likely in the next version). Then the problem becomes finding a good way to display the information and allowing the user to interact with it.

For example, each chat message should include both the player name and the character name. That would let the GM see all messages by a certain player or all statements made by a certain character. But it needs to display in a way that is easy to read and easy to use. Some day...

I disagree with this. I don't want to see two names every time someone posts something in chat. The DDI VT does that and it annoys the piss outta me. How about character name for everything except the /ooc command? And character names could have a mouseover that shows the player name. So mousing over Gimli in the chat window would show JonathanTheBlack.

Gimli roars as he leaps down the ledge towards a bloodied orc, his shield leading the way.
Gimli: "This one is mine!"
JonathanTheBlack: ((Gimli will charge the orc on the ledge below him using Tide of Iron to push him over the edge.))

I never said that.

I said that it needs to display in a way that is easy to read. I foresee a table structure with multiple columns in which each column can be turned on/off. Or maybe some kind of tree structure that is collapsible.

What I have in my head should be acceptable to everyone as it will be configurable to what the user wants to see. I just can't describe it adequately. My brain is fried. (I blame it on Friday. )

sooooooo.........its been what.....3 months? any update?

though...i'm VERY happy and content with 1.3 its great! so i will be very patient for 1.4.

Not a lot of news to report on 1.4. I'm been very busy with real life and haven't worked on MT 1.3 at all hardly, and certainly not on 1.4. And I don't see my load lightening much before the end of the year.

Craig has been playing around with some of the basic libraries to see what can be made to work and we've had some technical discussions about various approaches, but there's still a loooonnnng way to go. I wouldn't expect anything to happen for months yet...

But keep in mind that we're not in a super huge hurry either. We want Oracle to release some of the updates they have planned for Java in the next 6+ months so that we can evaluate them for MT. And since this is a volunteer effort (i.e. no one is being paid for this) we'd rather not write a bunch of code and then have to go back and redo it to make use of some new feature.

Thank you for the update, Azhrei. All your efforts are appreciated.