MapTool 1.11.0 Alpha Build 1

[cwisniew]

Warning Alpha Release, please do not use for your regular gaming, or use it to modify maps you don't have a backup of!

What's Changed

• Fixes for several macro functions where name was case sensitive js.eval, js.evalNS, and js.evalURI use case sensitive comparisons for determining which to run #3011 MacroScript Functions that use case sensitive comparisons on function name should be changed to use case insensitive comparisons #3013
• implement terrain VBL Add two-way VBL/terrain walls #2755
• Preference Dialog Fixes Update preferencesDialog.xml #3063
• More error handling / clean up for Universal VTT import Error on importing dd2vtt file #3061
• Disable Direct 3D by default Disable Direct3D use #3065
• Space/Enter will no long advance initiative Update InitiativePanel.java #3066
• show / hide / get visibility of overlay macro functions show/hideOverlay #2431
• Add initial support for Add-Ons Expand Asset class to support things other than Images #1346 Method for storing HTML / CSS/ JavaScript / Audio / etc in campaign #1348 (see also https://rptools-doc.craigs-stuff.net/blog/add-on-libraries)

Full Changelog: 1.10.1...1.11.0-alpha.1

---

This discussion was created from the release MapTool 1.11.0 Alpha Build 1.

[Phergus]

library.getContent returns the following for a .mtlib file:

[
  "mtscript/public/auto_exec.mts",
  "mtscript/public/test1.mts",
  "public/test2.html",
  "mtscript/priv1.mts",
  "mtscript/public/test2.mts",
  "public/test1.html",
  "mtscript/public/CSSTest.mts",
  "mtscript/public/call_priv1.mts",
  "public/test-img.png",
  "mtscript/public/no_auto_exec.mts",
  "public/test1.css",
  "public/test1.js",
  "mtscript/public/myUDF.mts"
]

Should we separate the types out?

[
  "mts": [
    "mtscript/priv1.mts",
    "mtscript/public/auto_exec.mts",
    "mtscript/public/call_priv1.mts",
    "mtscript/public/CSSTest.mts",
    "mtscript/public/myUDF.mts",
    "mtscript/public/no_auto_exec.mts",
    "mtscript/public/test1.mts",
    "mtscript/public/test2.mts"
  ],
  "html": [
    "public/test1.html",
    "public/test2.html"
  ],
  "css": [
    "public/test1.css"
  ],
  "js": [
    "public/test1.js"
  ],
  "images": [
    "public/test-img.png"
  ]
]

[Azhrei]

I'm not sure there's a lot of benefit if you're just grouping by filename extension; scripts can filter by that pretty easily.

Now if you want to group by mime type, that could be useful... maybe?? When grouping by mime type, such as image/jpeg or text/html, maybe the text on either side of the slash should be a key, thus:

"text": {
  "html": [
    "public/test1.html",
    "public/test2.html"
  ],
  "css": [
    "public/test1.css"
  ],
  "js": [
    "public/test1.js"
  ],
  "markdown": [
    "public/docs.md"
  ],
},
"image": {
  "png": [
    "public/test-img.png"
  ],
 "jpeg": [ ... ]
 "svg": [ ... ]
}

That makes it easier to process all text components or all image components, without needing to know what the image types are that are included.

[Phergus]

Functionally the same as sorting by extension but with additional sorting by the higher level designation of "text" or "image". Makes it easier to process by type and sub-type assuming that is something that is likely to be needed. As you said, maybe folks will have reason to do this.

[Azhrei]

Functionally the same as sorting by extension but with additional sorting by the higher level designation of "text" or "image". Makes it easier to process by type and sub-type assuming that is something that is likely to be needed. As you said, maybe folks will have reason to do this.

Not exactly, since image/jpeg includes any JPEG image whether the extension is .jpg, .jpe, .jfif, or .jpeg (see a full list of mime types here). Other static image types mostly have a single filename extension in wide use.

If animations/movies are ever supported, then having a video category might be useful for grouping as well.

[Phergus]

Similar question for lib:tokens. Current output of a lib:token in a campaign with two property sets. As can be seen the Basic properties are also returned. Is there value to this? What about in Campaigns where there are three, four or more property sets?

This also opens the question of should we just define a Property set that includes the already expected lib:token properties:

• libversion
• libauthors
• libwebsite
• libgiturl
• liblicense
• libdescription
• libshortdescription

The current return from library.getContent():

[
  "macro/bobs/your/uncle",
  "macro/Call",
  "property/elevation",
  "property/ac",
  "property/constitution",
  "property/strength",
  "property/libversion",
  "property/hp",
  "property/description",
  "property/libwebsite",
  "property/liblicense",
  "property/charisma",
  "property/intelligence",
  "property/wisdom",
  "property/dexterity",
  "property/libdescription",
  "property/libauthors",
  "property/defense",
  "property/libshortdescription",
  "property/libgiturl",
  "property/movement"
]

Organized?

[
  "macros": [
    "macro/bobs/your/uncle",
    "macro/Call"
  ],
  "properties": [
    "Basic": [
      "property/ac",
      "property/charisma",
      "property/constitution",
      "property/defense",
      "property/description",
      "property/dexterity",
      "property/elevation",
      "property/hp",
      "property/intelligence",
      "property/movement",
      "property/strength",
      "property/wisdom"
    ],
    "LibTokens": [
      "property/libauthors",
      "property/libdescription",
      "property/libgiturl",
      "property/liblicense",
      "property/libshortdescription",
      "property/libversion",
      "property/libwebsite"
    ]
  ]
]

[Phergus]

Basic wiki docs added for:

• library.getContents()
• library.getInfo()
• library.listAddOnLibraries()
• library.listTokenLibraries()

https://wiki.rptools.info/index.php/Category:Library_Function

As the two remove functions may not stay in for release I'll leave documentation for later if needed.

• library.removeAddOn()
• library.removeAllAddOns()