Frameworks should not be the one man job

[bobifle]

Hello,

I'm not a native english speaker, I apologize for the possible weird constructs. I've been using Maptool in my game sessions in person and been lurking on the discord/forum for a while.

And i've seen an insane amount of work and talent put into frameworks (in addition to the base program ofc !). I'm thinking about the bag of tricks, the dnd 5e framework, some ppl are actively maintaining a 4e framework, the Nerps 3.5 cmpgn file plus all the others frameworks for other systems I didn't get the chance to test.

One thing that keep these framework to be truly amazing is their inability to be co-developed by the community (I know some frameworks are compilation from different authors but that not what I mean here).

If frameworks could be source code, placed on gith... whatever online source control site, that would allow ppl to actively develop and share them. Right now frameworks are just a saved campaign file, and unziping them yield a couple of obfuscated xml files. Frameworks are just saved files of in app manipulations. Something that is impossible to review, and co-develop (I may be slightly overstating here).

In the end, a framework is this one man job which dies with the author motivation or available free time.

If we were to rebuild Maptool from scratch right now shouldn't we:

* split campaign and save files
* make campaign files human readable/writable (json ?)

I'd like to hear your take on this.

[Phergus]

I agree with the idea that developing a framework should be something that can be done in a collaborative fashion through a Github or the like. As you suggest, it would require a rewrite of the parts of MapTool that handle things like token properties, macros, states, tables, light and vision such that they could be exported/imported in a format that is more friendly to that concept.

Right now everything goes into one campaign file. This is generally a good thing from the standpoint of portability and being able to quickly throw a single file on a usb stick or a cloud drive such that you can take it with you without worrying about having the latest framework macros that go with it.

As soon as you separate the framework/ruleset from the campaign file that just has maps and tokens there is the chance of having mismatched or missing files. Obviously there are ways to mitigate against this happening such as continuing to have a save format that has everything along with save formats for separate elements.

As for the current situation, someone can pickup and continue on with an abandoned framework but this is often quite challenging due to a lack of documentation and lack of a development environment that can help unravel the myriad of macros.

Technically the current frameworks are in a human-readable format as it is XML inside the campaign file. It would be fair to say it isn't human-friendly though. I suppose someone could create XML transforms to make them more readable. However, the last thing you would want to do is edit that monolithic file directly.

One of the challenges would be dealing with macros that are scattered between the campaign (and possibly global) macro panels and the lib tokens. There may also be other tokens that aren't lib tokens but have macros on them.

All in all, this would be a huge undertaking.

[Full Bleed]

More cooperative framework building would be a huge improvement to how things are typically done around here... but I'd be careful about thrusting a collective of amateur macro builders into a strict "coder" methodology requiring an understanding of advanced, exterior tools. MT's capabilities and features are already quite obscured behind its macroscript and I'd hate to see another level of technical expertise required for people to participate.

[Phergus]

Well, in order to collaborate, they would need to be able to use a cloud-based source-control service like Github. They would need to understand basic practices of software development. Those that couldn't would be limited to editing macros within MT but could participate much as they do now.

[bobifle]

Well let me try some proposals, I'm trying to show that we're not that far from that.

Assuming a framework is just a set of files under a specific directory, and that it's able to ask the user when creating a campaign which framework, if any, he wants to use:

1/ macros

* Token macros: no change, these are not related to the framework
* Campaign macros: defined in a plain text file within a maptool/framework/yyy/macros directory
* Lib tokens: these are an interesting topics. Lib token are in some way a workaround for not being able to easily edit/update Campaign macros. But they are actually part of the framework and should be actually campaign macros. Maybe we'd would just need some kind of namespace mechanism for campaign macros and a way to tell MT to display it or not on the campaign panel. They could possibly still exist and be used, but with the new campaing macros, why bother ?

Ultimately the only required dev is for MT to be able to source the external macro files and add them in its campaign macro scope (I don't know if such thing exists)


2/ campaign properties, lights, states and possibly other MT configurations

* No change to the gui for being able to edit those
* MT could source at the creation of the campaign (and possibly source it later for update) a set of file to internally define all states lights and properties.

Here's a preview of what a framework would look like:

Code: Select all

framework/dnd5e/
                |--- macros/
                |            |--- misc/
                |                      |--- sheet.mtmacro
                |                      |--- attack.mtmacro
                |--- assets/
                |           |--- state1.png
                |           |--- state2.png
                |           |--- table_item1.png
                |--- states.json
                |--- lights.json
                |--- props.json
                |--- tables.json
                |--- cfg.json

Everything is plain text, human readable, editable from external text/code editors, github-able, mergable etc...

It's a lot of work, but compared to feature like VBL and others, technically easy (I'm sure you're gonna prove me wrong on that ).

[Phergus]

A couple issues.

Lib token are in some way a workaround for not being able to easily edit/update Campaign macros.

Nope. Not even close.

Lib tokens are very much the core of frameworks. Some of this is because of limitations in the current way macros are stored in either Campaign, Global or Tokens. Because macros are presented as buttons in the UI the Campaign/Global macro panels can quickly become extremely cluttered with macro buttons even though many of them are not directly usable but are instead the equivalent of subroutines in more traditional programming. The solution was to put them on tokens but have those macros callable from other macros on or off of the Campaign panel. Security and trust factors also played into how this came about and how macros on Lib:Tokens may be called. To change this such that macro code, which is currently stored on lib:tokens, is put somewhere else would be a major undertaking.

The other issue is that storing frameworks in a loose configuration of directories and text files will be very fragile and prone to problems. In order to share a framework this would require bundling the whole directory tree into a zip file. Two opportunities to mess things up; creating the zip and extracting it. It's been seen time and time again here on the forums that if there is a way to screw up something as straightforward as extracting a zip file that it will happen. A lot. Some of this could be mitigated by having MT handle the bundling/unbundling for the user.

Something that I haven't mentioned is that the various MT structures you see in the content.xml file are written/read by existing JAVA libraries. To change this to a different format would also require new code to be written, maintained and bugs squashed.

All of this is doable and I agree with the basic premise that it should be easier to create, edit and collaborate on frameworks. However, it isn't as simple as it sounds.

[bobifle]

First thanks for taking the time answering my nonsense. I'm trying not to make this thread a back and forth question answer argument, as it often lead to ppl camping their position and not listening to what others say. But I guess this is how discussion work in a forum... Anyway...

Nope. Not even close.

And right after you explained why lib token have been introduced: to circumvent limitations of the campaign and global scope where the would naturally belong in the first place. That's why I don't get it why you disagree with my statement.

The other issue is that storing frameworks in a loose configuration of directories and text files will be very fragile and prone to problems. In order to share a framework this would require bundling the whole directory tree into a zip file. Two opportunities to mess things up; creating the zip and extracting it. It's been seen time and time again here on the forums that if there is a way to screw up something as straightforward as extracting a zip file that it will happen. A lot. Some of this could be mitigated by having MT handle the bundling/unbundling for the user.

hmmm to be honest I don't see this as a major issue, alright you can have MT zip unzip for the user. And you can also have MT clone a github repo containing the framework this would make keeping the framework integrity real easy.

Something that I haven't mentioned is that the various MT structures you see in the content.xml file are written/read by existing JAVA libraries. To change this to a different format would also require new code to be written, maintained and bugs squashed.

There's no need to change anything to the way MT serialize its data. Frameworks would not be a serialized version of in application manipulations. They would be external data sourced (yes that would need some extra code, but nothing fancy, basically importing macros and json).

There's a lot of work to implement my proposal, but there's no complexity. And I think the benefit is really great and outweight by a large factor the few issues to be solved. However I'm not the one that will do it, and I can see how out of the few resource available to develop MT, there's no one available or willing to tackle this. In the end if I didn't spark anything on the dev side, it probably means that my idea is not as great as I think it is and yes it should be supported by the major framework contributors to be actually useful.

Feel free to slap me in the face with a "stop bothering us with that". I often need this to move on

[Jagged]

There is a plan to be able to save campaigns in an open directory format.
Craig is the one to talk to about that.

[Phergus]

As Jagged says, there has been discussion (back at the beginning of the year I think) related to your idea in the dev channels and is related to a pretty significant overhaul of much of the underpinnings of MT.

But your still wrong about why lib:tokens were added. Has nothing to do with how easy it is or isn't to edit/update campaign macros.

In any case, something like what you have proposed will likely show up at some undetermined point in the future. Adding a goal of making the writing of and collaboration on frameworks easier as part of it will be good.

[Jagged]

also, if you want to work on macros that you can share with other people, I would recommend prefixing everything with a standard name.

I prefix most of my stuff with my initials "dsr_"