FEATURE: Macropacks

[RPTroll]

This concept is much like artpacks except it will allow MapTool GMs the ability to download macro packs and run install macros that set them up.

Thus the Campaign Frameworks would be listed, allowing the user to select and install one for use in games.
Likewise the BoT and other generic dropins could be installed via menu rather than download and install.

I would think that we would want a framework/macro review group - much like our code reviews - to make sure the things actually work and that the frameworks are used. Also testing for compatibility. It probably isn't wise to use multiple frameworks at once nor multiple dropins that call the same event. Perhaps some testing for events and other nuisances is called for with error messages and aborts.

You also might need a way to back out a loaded macropack thus assets thus you might need an asset list.

[Edit 03232015]
Added generic to Macropacks.
Included verbiage about testing for conflicting events.

[wolph42]

note that most (nearly all) 'general' macro tools have been incorporated (with credit to author) in the BoT and having some macro sets double might give complications (stuff failing due to e.g. two onTokenMove macros in one campaign file). That and some packs are incompatible (which is one of the reasons I incorporated so many packs into the bot so they could all work and users have it all with one download. This is thus in contrast with an artpack which usually is compatible with others.

Note that I speak of 'general' macro tools, the other word would be 'agnostic'. Macro packs that clearly support a certain system are left out.

Hence I would much sooner propose some framework and macro pack download tool (similar to the art pack). That covers a much broader area.

[RPTroll]

Updated OP

[wolph42]

clear. I apparently missed the part of the frameworks.

[Jagged]

Would it be too scary a thing to ask for 1.4 to add some kind of code library that didn't have to be attached to a token and a map?

Something that would behave the same way as a token library, with attributes and macros, but nothing else. You wouldn't need to make sure you had the correct ownership rules applied, you wouldn't need to worry about deleting the wrong map They would attach directly to the campaign and could be saved and imported like maps. IMO that would be awesome and perhaps could be seen as a small step in the direction of Maptool 2.0?

[aliasmask]

Would it be too scary a thing to ask for 1.4 to add some kind of code library that didn't have to be attached to a token and a map?

Something that would behave the same way as a token library, with attributes and macros, but nothing else. You wouldn't need to make sure you had the correct ownership rules applied, you wouldn't need to worry about deleting the wrong map They would attach directly to the campaign and could be saved and imported like maps. IMO that would be awesome and perhaps could be seen as a small step in the direction of Maptool 2.0?

Funny, I was just thinking the same thing to disassociate a library from a token.

[wolph42]

in that case I would opt for a system where you have a database of token from which you can pick to drop on a map. But the ones on a map are no more than data-less images. All macros and properties are store in the database and no longer on a map. In this case you can have lib:tokens but no longer tied to a map but to a database.

btw, the reason that it currently works as it works is because players are allowed to 'bring their own macro' to get certain stuff automated. This is also the reason that a lot of functions are 'trusted' to prevent players from cheating. Hence ownership is VITAL for this. As 'owned by player' does not allow trusted macros, while 'owned by gm' does not allow players to edit (unless you check that).

[Jagged]

Having to drop a token onto a map is the bit I want to avoid. I'd still want existing Lib:Tokens to work as they do, for backwards compatibility. But if you still have to place a token on a map, I don't think you will have gained anything.

[wolph42]

Having to drop a token onto a map is the bit I want to avoid. I'd still want existing Lib:Tokens to work as they do, for backwards compatibility. But if you still have to place a token on a map, I don't think you will have gained anything.

perhaps you misunderstood. I was talking about datatokens and placeholders. The datatokens contain the actual data, the placeholders are no more than a graphical representation. This would mean that it would NOT be required to drop a lib:token on the map, but only have it available in the DB. It also would have the advantage that all player tokens would have the same stats.

[JamzTheMan]

How about a Git plugin that allows you to input a GitHib clone URL and it grabs the Macros/Tables/Etc and loads them? Like a framework? Fork it, edit, apply, push it back up. I'm a Git Converter!

Or do we need some sort of "store front" that is a little more user friendly to browse/store/upload/download framework bits? What's the best way to share these "macropacks"?

I like the idea to disassociate (or allow it) macro's from Lib Tokens. Lib tokens should still exist and have purpose. But there isn't really a reason that they need to be on a map and on a token. They could be global objects represented in a Tree form for organization?

And we could possibly start with keeping them as "tokens" in the background (maybe each "token" is a leaf/node on the tree?) so standard properties/macros could be used.?

The idea defiantly ties into the umbrella of "we need a better/friendlier way to share/update/code frameworks".

[RPTroll]

GIT's probably a little much for the average user unless we build some sort of friendly front end that takes care of the details. That said, the steps are pretty easy once you understand them. Getting that understanding takes a bit.

Global objects for frameworks would be grand complete with DB integration for saving tabular data and javascript capabilities so we can slowly move toward something robust with IDE support.

[Jagged]

perhaps you misunderstood. I was talking about datatokens and placeholders. The datatokens contain the actual data, the placeholders are no more than a graphical representation. This would mean that it would NOT be required to drop a lib:token on the map, but only have it available in the DB. It also would have the advantage that all player tokens would have the same stats.

Ah yes, I see what you mean. Its funny how we can't go far into any of these features without pulling in more

That (data holders and place-holder tokens) is definitely a feature I want to see (more than function libraries in fact) but I do see it as a separate feature. The code monkey in me would like to be able to define attribute/variables at the Campaign level and at the Code Library/Macropack level, but I wonder if they should have no attributes of their own at all?. I seem to remember a diagram showing a new campaign hierarchy (which might have been with 2.0 in mind rather than 1.4), I shall have to see if I can find it.

[RPTroll]

Found an article about putting Git into an application.

http://git-scm.com/book/en/v2/Embedding ... d-line-Git

Just putting this here for future reference.