Active Framework Designers

[Lee]

@Xaelvaen Thanks for the support My priority right now, since I've long owed it to the community, is video proof. For the life of me, I just can't get started, as much as I want to. RL invariably comes in with demands, and I use up about 20 of every 24 hours lately

For me, the current quality of the framework isn't as important as the input of those who have experienced building one. One of the primary goals of the initial phase is to make design easier and, hopefully, by discernible margin.

For example, I've started on the idea of snippet/template insertions into the macro editor, since I find myself consistently creating an [h, code:{}] block. I have others drawn up such as a template for delivering macro.return functions, the complementary template for functions expecting a return etc. The experienced input comes in by way of contributions toward forming a snippet/template library callable through key combinations.

Since these tend to be time consuming, I sure could use help with writing skeletons for loop blocks, dialog and frame blocks, generic css, maybe even generic strformat, and more. Also, apart from the wiki, the source information required for syntax assistance and in-line help ala javadoc, also needs authoring, which is why I mentioned a lengthy production process as a significant chunk of this will be devoted to authoring instead of writing code. After all that, or during the process, localization also needs to be addressed

Anyway, thanks again for chiming in. Please continue to provide input when you can The threads for specific topics will be up as soon as I have more time to write them up.

[Jagged]

I would very much like to be involved in any discussion. I can't claim any "real" framework building, although I created A Light-weight framework for Hero System 5ED and produce a small smattering of updates for Rumble's Slim Framework.

I am also very keen on dice extensions. See my submission for changing how Hero System dice work in Maptool

[aliasmask]

I sure could use help with writing skeletons for loop blocks, dialog and frame blocks, generic css, maybe even generic strformat, and more.

As someone has pointed out to me, Notepad++ has the ability to build syntax skeletons. I think you still have to specify shortcut keys to do so, so I don't think it's done like an auto-complete process where you get it started and it assumes the rest. It's something that I didn't really want to research though because I've never really liked using syntax blocks. I don't find the syntax all that hard to type out, but I can see the use for a parser that verifies you put all your ; and closed all your brackets in an easy to decode error code.

I seem to be getting the coding bug again as my interest in an online MMO wanes, so I may be a little more active as I work on projects for old and new stuff.

[Lee]

I get what you mean; the blocks that make the cut, at most, will be the simplest forms that get used frequently. As for verification, it's best done, IMO, as the user writes it; compelling him/her to finish before moving on to something else.

[Lee]

I am also very keen on dice extensions. See my submission for changing how Hero System dice work in Maptool

Sorry, Jagged, I meant to address your post but got mixed up in other stuff.

Thanks for the point-outs, I'd like to throw back a couple of questions regarding this:

• Firstly, the updates you've made to dicelib already address the issues you mentioned, correct? I looked at how you implemented it, and it's simpler to use than the roll expressions provided. So, wouldn't it be easier for Hero system players to just drop your dicelib into their copies of MT?
• Secondly, the ideal of my dice expression builder, and the one MT employs, is to be as system agnostic as possible. To my understanding of MT history, hero dice was included very early on, breaking the idea of "agnosticity". If we were to expand either, in what way can it be done to not only benefit the Hero system, but other systems with similar mechanics? In other words, how can expand the system without putting in special cases for just one rule set?

With regard to point #2, the first idea off of my head is to allow an arbitrary # "trigger" results which affect a die in the roll, or the total itself i.e. a result of 1 gives -1, a result of 6 gives +1.

Up to this point, it is still a general enough approach that can benefit other systems. The part that comes after (described in your thread), however, calls for knowledge of roll details such as # of dice involved, maybe attributes as well etc. etc. which is more suited to a macro. What I can say about that, for now, is that the expression builder saves details of each roll mapped to the dice type involved. These details will be retrievable via macro so framework designers can just parse the details into an output of their own creation. With that in place, we preserve system agnosticity.

I suppose if demand for it is sufficient enough, more flags in the expression can be put in to refer to roll details, and maybe perform mathematical operations too. Though, honestly, this is something the macro system was built to address. Lastly, the priority level for this would likely not be at the top. Once you are privy to the project's roadmap, you'll see that there's a lot of greater stuff to be done

[Jagged]

Sorry, Jagged, I meant to address your post but got mixed up in other stuff.

No problem. It probably is easier for people to drop my updates into Maptool but I was keen to throw Hero System stuff into the mix.

Your intriguing post above talks about campaign architecture and dice extensions so I didn't know if you had some method in mind for creating campaign specific dice rolling schemes. Which would be cool. If it did, the first thing I would try would be Hero System dice.

With regard to Hero System stuff specifically, I understand the agnostic argument, but since Maptool has functions for rolling Hero System dice it seems to me they should work correctly. That's not your issue though

cheers!

[Lee]

Your intriguing post above talks about campaign architecture and dice extensions so I didn't know if you had some method in mind for creating campaign specific dice rolling schemes. Which would be cool. If it did, the first thing I would try would be Hero System dice.

These 2 elements are separate, at least for the moment. Judging how I want to accomplish these goals, the idea is to enthuse users, current and new, to be more productive and contribute. In this context, instead of writing in system specific stuff into the code, other obstacles are instead removed thereby driving the motivation to accomplish design in macro script. This way, one person (e.g. myself) enable others instead of the other way around where a large user base inundates a small developer group with feature requests

[Bone White]

Quite active, though my framework doesn't get released very often. I can see these features, especially the "new campaign" process very good for introducing new users into the nuances of MapTool, especially the "quick character" planned feature.

PM contact is fine as I get email notification anyway.

On the back of wolph42's mention to notepad++, I'd find it especially welcome to have the function auto-completer + tooltip appear inside the macro editor itself. This is a big ask sure, but a long-term one.

3) As long as the "tables" you've quoted are able to be written to and edited much more than their current implementation this is greatly appreciated. If by tables you mean a spreadsheet which can be edited/altered in-program this would be exceptionally useful for all involved. +1 if it can be stored as a recognised table format for other applications e.g. Excel allowing us to build tables in other programs for use in MapTool

4) I would love it if the MapTool window itself had a link to a campaign listing, which would include categories, titles and last updated. A new user would be introduced to this menu via a tutorial popup on first launch, and they could browse the list, or type in a game e.g. Dungeons and Dragons 2nd Edition, which would match tags against all frameworks which had these. Then they can see which is recently updated and be given a link to the forum thread to preview/download it (or a direct download link). This would be a great way to introduce people to frameworks.

[Lee]

Quite active, though my framework doesn't get released very often. I can see these features, especially the "new campaign" process very good for introducing new users into the nuances of MapTool, especially the "quick character" planned feature.

PM contact is fine as I get email notification anyway.

On the back of wolph42's mention to notepad++, I'd find it especially welcome to have the function auto-completer + tooltip appear inside the macro editor itself. This is a big ask sure, but a long-term one.

3) As long as the "tables" you've quoted are able to be written to and edited much more than their current implementation this is greatly appreciated. If by tables you mean a spreadsheet which can be edited/altered in-program this would be exceptionally useful for all involved. +1 if it can be stored as a recognised table format for other applications e.g. Excel allowing us to build tables in other programs for use in MapTool

4) I would love it if the MapTool window itself had a link to a campaign listing, which would include categories, titles and last updated. A new user would be introduced to this menu via a tutorial popup on first launch, and they could browse the list, or type in a game e.g. Dungeons and Dragons 2nd Edition, which would match tags against all frameworks which had these. Then they can see which is recently updated and be given a link to the forum thread to preview/download it (or a direct download link). This would be a great way to introduce people to frameworks.

These are all on the roadmap; several of which are (nearly) fully functional, apart from cosmetic effects and additional features beyond their basic scopes #4 is likely to be implemented last as it requires an accessible point in the cloud to drive it.

[Jagged]

Your intriguing post above talks about campaign architecture and dice extensions so I didn't know if you had some method in mind for creating campaign specific dice rolling schemes. Which would be cool. If it did, the first thing I would try would be Hero System dice.

These 2 elements are separate, at least for the moment. Judging how I want to accomplish these goals, the idea is to enthuse users, current and new, to be more productive and contribute. In this context, instead of writing in system specific stuff into the code, other obstacles are instead removed thereby driving the motivation to accomplish design in macro script. This way, one person (e.g. myself) enable others instead of the other way around where a large user base inundates a small developer group with feature requests

I'm sold

Can't wait to hear more details about what you have in mind.

[Dracones]

3- As mentioned, we'll have SQL and tables; not because it is better than what we have now, but because there might be potential users who are more versed with this method, and growing the community of builders is vital. It's at a primitive level right now, but it can already do a lot.

I'd be very interested in testing/working with this. I've been finding the "data on token" model to pretty much fall flat when I start adding in a lot of data. Right now I've gotten around this by using the Nerps variant of Maptool which allows for pulling data over remote URLs and that's been much cleaner when it comes to functionality.

But I'd also be very happy to support SQL if that were implemented.

[Lee]

@Jagged Very soon, my friend. Very soon.

@Dracones This will be a discussion held over an extended period. My current plans for phase 1 is to provide a smoother user experience and, apart from that, it will attempt to be as true as possible to what users expect in 1.3. Phase 2 and onward will see radical deviations, so much so that it will become apparent that it is a different tool altogether under the hood, and behind the driver's wheel.

With regard to REST, without going into too much detail, there will be implementations of it, but it'll likely be abstracted away from users for their own safety; providing services instead of being arbitrarily manipulable.

The data management options will make it in to phase 1 in the forms of the an (slightly) improved version of the current token system, and SQL; the latter designed to either be distributed/embedded (i.e. clients have their own copies of the table, checked either periodically against a master copy, or not at all), or the traditional client-server setup (i.e. clients querying a centralized source).

Changes to the former will come on further phases; work I've already started on by starting the decoupling process where the current token scheme is split into its component parts (i.e. data structure - visual representation). The reason it is not making it into phase 1 is because of the complexities involved in the entire plan, and some of the radical changes I mentioned earlier. (TL;DW). The end result, I hope, will be as performant as I visualize it to be.

Thanks for the offer of help. Your data, like the stuff you've done for Hero Lab, will come in handy

[Dracones]

@Dracones This will be a discussion held over an extended period. My current plans for phase 1 is to provide a smoother user experience and, apart from that, it will attempt to be as true as possible to what users expect in 1.3. Phase 2 and onward will see radical deviations, so much so that it will become apparent that it is a different tool altogether under the hood, and behind the driver's wheel.

That sounds very reasonable. One idea I might want to put in your brain to chew over is that one of the reasons that the current "stick it on a JSON and just grab it" model doesn't work for me is because on my test data set I'm generating over 100k lines of html code taken directly from Hero Lab. So it's really easy for odd characters in that html to completely break JSON on the tokens and it's a nightmare mess to try to track that down.

NERPs works so well for me because the urlrequest addition seems to pretty much just grab the remote url data and shoves it into your macro space. So I can do a frame[ urlrequest(html) ] type macro and get pretty clean results, though even then there's a few things I have to strip which can break the macro'ing in Maptool.

So there may be a couple ways people want to interface with that SQL data. Some people might want Maptool to do a lot of parsing on that data when they fetch it(basically put complex macros in SQL rather on tokens), while people like me just want get at the data and display it in some way without Maptool trying to interpret it and muck things up.

[Lee]

Hmm. I've written a fix for a related issue (Unicode etc.), let's see if it allows for the smooth transference of your HTML data and decide on what to do from there.

As for SQL, it should only be useful for people who know how to use it, or learn it quickly. With that being said, the feature set script-wise covers the basics (e.g. select, insert). To cover everything else, there is an all powerful function to just pass an sql statement/query directly to the engine. To head off a potential question, no, I don't see a need to include a statement/query builder as there are a lot of those out there that do the job well already.