Add multiple default campaign property types

[Azhrei]

Currently, MT starts with only a single set of campaign properties. Maybe there should be multiple that are predefined that map to the most common game systems. One for D&D 3.x, one for PF1E (includes CMB/CMD), one for GURPS, and so on. It would give new users a better starting point to add on their ow stuff.

[emmebi]

Is there already a set of properties which can be copied/included?

[Phergus]

There is. When MT starts up there are default token properties plus vision, light, states and a bar. I have never looked to see how those are created at startup. Maybe they are actually loaded from an xml file.

[emmebi]

After some digging (but no experimentation so far), I understand where this comes from. The following is an excerpt from initialize method in CampaignProperties.java

  private void initTokenTypeMap() {
    if (tokenTypeMap != null) {
      return;
    }
    tokenTypeMap = new HashMap<String, List<TokenProperty>>();

    List<TokenProperty> list = new ArrayList<TokenProperty>();
    list.add(new TokenProperty("Strength", "Str"));
    list.add(new TokenProperty("Dexterity", "Dex"));
   ...

The other default seems to be initialized in the same way. Suggested course of action:

• we extract this stuff into a set of (xml ? ) files;
• we modify the code to read the info from those files;
• we provide alternative set of files for various game systems.

For the last point, I would need someone who can provide a set of properties for other gaming systems, if anyone already did that.

Anyway, I can work on this during the week, feel free to assign it to me (unless someone else is already working on it, of course)

[JamzTheMan]

Let the arguing begin lol
Especially where it's popular now to use json inside a property to cover several "properties".

I guess the best we can do is pick "one" for a default.

Also, isn't there already a import/export for properties? I guess they is for well property toes though right?

[Phergus]

I think that is pretty much what needs to be done. A decision about where the files will be stored is needed. The ones supplied with MapTool can be kept in the jar perhaps but if users want to add or modify their own it might be good to have them with the other resources under .maptool-rptools.

XML is probably the way to go for now as there is already code to import/export campaign properties.

[Phergus]

@JamzTheMan My thought would be to focus on "basic" property definitions so that folks new to MapTool aren't immediately faced with arcane macro code just to input the property values. Perhaps each one could have a Game - Basic and a Game - Advanced assuming there is someone wanting to do the advanced.

[emmebi]

To be fair, I am mixing two different features here:

• having more than one set of properties: this just means creating more sets initTokenTypeMap()
• making the set of properties customizable/exportable: this implies storing them on the file system in some way.

I will make a first attempt at just adding more set of properties, and then I will see how I can work on the other.

[Phergus]

Not sure I'm following you. Users can already have multiple sets of token properties. The goal here is to have predefined sets for other rule systems. My take is that they would be loadable and would not always been there in the Token Type list. That list reflects what is saved as part of the campaign file. In other words, they are the property types for tokens in the currently loaded campaign. A new list, that displays available Campaign Properties sets that can be imported would be nice.

Another thing. Right now you can't get rid of the Basic props. You can redefine them but the default property set for tokens is always Basic. So anyone playing a different system has to redefine Basic or else every token that is added has to have the correct property set given to it.

At the bottom of the Campaign Properties dialog are buttons to import and export the properties as an .mtprops file. So a method of saving and loaded is already in place. Note this isn't about just the Token properties but also sight, lights, states and bars.

[cwisniew]

Thinking of (eventually) moving to a grander plan...

Do we want people to say "hey I am playing DnD5e, or hey I am playing Paranoia, or ..." select that and it comes up with a set of starter properties, states, light sources, campaign preferences for grid type, movement metric etc. It could even have some very basic "starter macros", eventually character sheets...

Not saying this issue has to address all of the above but we should at least do it in a way where it can be extended to do the above rather than thinking of it as "just export/import properties", as Jamz says we already have that.

The question then is are we expecting these to -- at least initially -- be hand created/edited files? If so I think storing then as JSON is a better bet than XML (or json with a bunch of .mts for macros or something similar).

The idea being you don't have to use these, but if you are new to MapTool then its at least is less you have to figure out.

[Phergus]

As part of a move to a grander plan, then all of that. For right now, most of it but using mostly existing functionality.

What we have now wrapped up as Campaign Properties: Token Properties (one or more Types), Sight definitions, Light definitions, States (with any associated images), Bars (same) and Repositories.

If you save a Campaign, everything in the Campaign Properties dialog plus macros, maps, tokens and tables goes into the campaign file. If you export Campaign Properties then you just get what's defined in the Campaign Property dialog. This, to me, is the minimum level of support for a game system. What is needed are predefined Campaign Property files for those systems and a change to the Campaign Properties dialog that presents a list of available predefined ones plus the ability to choose a user created one. Currently this capability is already there with the Import/Export buttons but needs to be improved to be more obvious to the user. It's obviously bad when a developer isn't sure that the Import/Export buttons are for everything defined in the dialog.

As mentioned previously, any predefined Campaign Properties should just be there in a list to be selected. Once selected the user should be presented the option to bring in everything as defined or perhaps the user only wants the Token Properties and Sight definitions.

While it would certainly be nice if the Campaign Properties could be hand created/edited - and then I would certainly prefer JSON - I think that we already have the UI in place for editing/adding these properties and that will minimize the effort and risks of bad definitions. Remember that Campaign Properties includes States and Bars which usually require image assets. Hand editing and then bundling is going to be prone to errors.

[Azhrei]

As mentioned previously, any predefined Campaign Properties should just be there in a list to be selected. Once selected the user should be presented the option to bring in everything as defined or perhaps the user only wants the Token Properties and Sight definitions.

There's code in the repo now that starts on this. I had a plan to implement the ability to load/save anything stored within MapTool using a single UI. It presents a JTree with top-level components (like Campaign, Tokens, and Maps), and then each top-level element has subelements.

I don't remember how far I got with it.😐 My plan was to implement a checkbox for every item in the tree so that entire branches could be easily selected. Then the user would click Export to see everything selected dumped to a single file. On import, the tree would display only what was in the file, with any empty branches of the tree greyed out.

[Phergus]

Code from #1213 provides for the ability to select and import one or more predefined

The list is created from the list of files in: C:\Users\username\.maptool-rptools\campaignProps.

This directory is populated initially by those found in the repo under:
maptool\src\main\resources\net\rptools\maptool\model\campaignProps

[Phergus]

The functionality is in place and working. Folks with knowledge of the listed system will need to update those placeholder campaign properties.

Note this is currently undocumented.

Any further work can be done on separate tickets.