changelog
John Waite
10/21/2016
What's new:
Plenty!
An exhaustive list (we hope) is written below, please go over it to be aware of what this version brings.
We've also (finally) implemented several ideas we've left on the back burner for a while now. We've also tackled a slew of things, some of which were suggested on our Snowy Evening list of feature requests. This was obviously a large undertaking, so it is highly likely we've missed logging a minor item or 2 (or several, SORRY!) while getting all this done.
In no particular order:Improved code completion. For example, enclosures (i.e. brackets, braces, and quotes) behave akin to IDE's like Eclipse. More below.
Improved the Dice bar. Single (i.e. unchained) expressions no longer need a terminal semi-colon. MapTool-type dice expressions can now be entered on the expression field and saved, though such expressions cannot be constructed using the Dice box controls. To let Mote know what type of expression it is saving, there is a control right beside the dice expression field to toggle between Mote or MapTool-type expressions.
Also, there are plenty of minor UI tweaks most people will miss if they're not looking. Nothing important, just making the user experience just a little bit better here and there.
Anyway, we're sorry that it took so long to handle this particular request (is anyone even using this?!). Due to this change, the old save file has been switched to JSON, and any existing file will be converted accordingly.
The Macro Properties Window has been retired in favor of the integrated Macro Properties Panel, which is part of every macro editor, except for the Macro Pad. When the editor is in focus, to pull this panel up, or close it, hit F5; if this panel is in focus, hit F4 to close. The difference in key is to avoid triggering the event when focus is transferred between these controls.
Thanks to a report, we sewed up some holes in the lockdown we put on the Player role with regard to macro creation and editing.
Connecting clients will have more information when loading the session's campaign. This is important in light of the recent changes to the campaign structure that includes databases and audio.
Due to the asynchronous nature of getting resources, the little-used window that tracks asset transfers is brought front and center, and informs the user of the assets being received.
This is useful information to relate to GMs because, unlike images where the infamous red question mark ('?') and 'X' icons are used as placeholders, this approach is not feasible for audio and databases, and proceeding with play in the absence of such resources, is a surefire way to trigger unwanted and unexpected behavior in the application. Therefore, it is advised that play should only start once everyone's transfer queues are empty (as denoted by the transfer window).
Also due to the recent changes, we encourage, more than ever, the use of repositories.
To help with this, Mote now automatically exports a campaign's repository whenever it is saved. This behavior can be toggled using the Preferences dialog, under the Application tab, in the Save section.
We have tested repositories in several popular services such as Google Drive and Dropbox, and they work great. Typically, you upload the contents of the exported campaign repository to a publicly accessible location (e.g. shared cloud folder).
What's important to note is that a proper repository URL is a link that points directly to the index.gz file. Please consult your service of choice on how to create direct links. There are numerous sites online that do this automatically for you, once you paste the shared folder link generated by your hosting service of choice.
We made a new and simple debugging tool to toggle the different components drawn on a map, to help find culprits causing poor rendering performance in maps. Access this tool by clicking on the button with the checklist icon under the Quick Actions toolbar.
Deprecated functions in the Token script group related to blocking (i.e. vision, custom), and moved this to its own group (Block), thereby making it a little less verbose, and appropriately feature-centric, as opposed to being lumped into an object's (token) properties.
Deprecated a whole boatload of functions in favor of Mote-flavored ones. Several function groups were thus created. Please consult the Mote wiki for more details.
We now have final version of the Mote Audio system, which is similar to the system used for Sift. Audio assets have been integrated everywhere relevant: Campaign, Macros, and Tables.
To associate an audio asset to the campaign, use the Campaign Properties window. When audio is associated here, the initial alternate ID or display name will be the asset's file name before renaming (renamed to hash code, as was standard for image assets). This ID or display name can be changed by editing the value on the table. This is important because, like in previous versions of the audio system, alternate IDs can be used to reference the audio asset, aside from its hash code.
For macros, the macro properties panel provides a button for it. As for tables, there is a new column to load audio for a particular entry.
All audio assets associated in this way becomes part of the campaign structure itself. If an audio asset is browsed from a location outside the Mote audio cache, an association process begins where information is derived for purposes of caching, saving to files, and disseminating information across the network. Needless to say, tampering with the cache elements in the data folder, will corrupt the entries. Corrupted entries cannot be used, and will be cleared out by the application, whenever feasible.
We believe that this opens up a lot of creative opportunities, and we leave it up to users to explore what these are.
Audio files can also be processed for use in Mote by adding them to the audio cache (data folder -> caches -> audio), either before the app is loaded, or when it is active. There is little difference between the 2, but it's best to do so before any work is done, to give Java a chance to reclaim resources expended to process these audio files.
Note, processing audio files is not the same as associating them. You have to add them via the methods described on the previous bullet, in order for them to saved along with the campaign.
Due to radical changes in the Audio system, both the Audio API and UI have been simplified to reflect this. We've taken out the ability to play audio by specifying a location (e.g. file path, URL, file:// protocol).
Now, in order to use audio, a user must first associate it to make it useful. The process is easy, and we believe more users will adopt audio for use in their campaigns now, more than ever.
We've also marked the following Audio API functions as obsolete: audio.clips, audio.streams, audio.flushCache, audio.clearAsset, and audio.defineSource. Audio playback is now handled by the singular audio.play, combining the functionalities of previous methods audio.playClip and audio.playStream. Please check the wiki and/or code completion for the updated API.
SQL databases are now also part of the campaign structure. Associating them to a campaign will persist them to the save file, and ensure distribution to connecting clients. To associate an existing database, use the Campaign Properties dialog. You can't miss it ;)
Also, when a database is created using the SQL functions, they automatically become associated to the campaign.
More "stateful" asset tracking. Deletion and addition of assets, depending on type, will be noted by the application.
Previously, in the system inherited from MapTool, if a user deletes a registered asset, the application would need to be restarted for it to be aware of the disappearance. Connected clients ended up requesting resources that are no longer there, because the state was never updated.
Now, such occurrences are handled correctly, though there may still be a few use cases we haven't discovered yet. Also a simple reload of a campaign will right things, re-allocating the missing assets, where necessary.
Enabling Fog of War or setting Vision to either Day or Night will now auto-calculate Fog. This does not reset previously revealed areas.
From a Feature Request: Added a new view for Tables, displaying their names on the list, as an alternative to the icon-based view.Enhanced the macro error report with links to the library (if applicable), and code snippet where the error occurred. Clicking on a library link will bring it into focus and select it, whereas a snippet link will open an editor and go straight to the code area in the question.
From a Feature Request: Automatic setting of facing on movement, either through keyed input, or mouse dragging.Expanded the dynamic blocking system to include the Bisection option. This type is suited for doors, where the block is drawn across the center of occupied space, dependent on the angle of facing or rotation.
To complement this change, we've also expanded the Token script group. See wiki and code completion, for more details. For example, a token's cell anchor offsets are now controllable through script. This allows the correct pivoting of a swiveling door. Implementation is left up to the user.
From a Feature Request: Variables are now added to auto-completion. Variables of length > 2 characters will be added, for sanity's sake. A variable is defined as the recipient of an operation e.g. variable = x + y or variable = json.set('{}', age, "25").
A toggle has been placed in the macro editor toolbar to control this feature. While it shouldn't be a problem keeping it always active (as it is, by default), we haven't tested it on more voluminous macros for performance hits.
This feature may have some quirks we haven't found, so please report any issues you find.
User defined functions are now also part of code completion. There are also several new functions, and extensions to old ones like defineFunction() (which is function.define() in Mote), to better manage script execution context. Note that the old functions are considered obsolete and have been removed from Mote's API.
For MapTool functions with Mote counterparts that still exist in the API, these will be marked "Deprecated" over time, and will be removed as obsolete at some point in the future, when the community gets more used to Mote's API.
You can see this marking during code completion, when the description box displays for the selected function. For the most part, Mote functions are more concise. While there are exceptions to this (e.g. Mote functions ending up longer than the original), it makes up for this by way of better organization and intuitiveness.
Consistency in the API will help users learn the "language" better, which more than offsets the inconvenience of learning the replacements to familiar functions. In the event we phase out these old function names, it will make code completion faster due to fewer lookup entries.
From a Feature Request: Implemented a new Application Toggle for a special view to see special overlays such as blocking (e.g. vision, custom), token types, light sources, etc. This is useful for designing maps. This can cause some slowdown, depending on the complexity of the map, so use wisely.
New networking component, for leaner and, hopefully, speedier transmissions. This is in preparation for interfacing with Sandstorm.
Improved the Grid Tool to make it a little easier to match the grid against maps with pre-drawn grid lines. The basic idea is (hopefully) intuitive:Add the map to fit.Switch to the Grid Tool.Measure the size of a cell (i.e. square) on the map. This is easily done by drawing a square over any cell:Click the left mouse button to start.Move the mouse toward the bottom right of the cell.Keep going until the grid aligns perfectly. Trust us, there's only one fit.Don't forget to close the tool to save the changes.Furthermore, we've tweaked the Grid Tool's control scheme as well. Dragging with the left-mouse button (LMB) moves the grid. The mouse wheel zooms in and out, but if you hold the Control key before using the wheel, it will adjust the grid scale instead.
This feature indirectly satisfies this Feature Request.
Light-related functions added to the API. Use these to dynamically create, or delete a light in the campaign. For the lights.create function, and argument exists to assign the created light to a token or a group of tokens.
Yet more improvement on map rendering speed. Feel free to test it out using a map kindly furnished by community member Zayne Webb, found here.
Expanded dice expressions and the functions success() and explodingSuccess(), to check success based on the values equal to or below the specified target number. Use the dice expressions for success rolls, but instead of 's' or 'S' use 'b' or 'B', short for "below" .
New event hooks onSelect, and onGroupSelect. These are distinct from each other, meaning they execute on separate situations, unlike how onTokenMove and onMultipleTokenMove were designed, where these were executed in series.
We are aware there is an event hook called onChangeSelection (IIRC), but the new events are simpler, and script-centric, whereas the one inherited from MapTool involves certain UI components, which sometimes slow down performance.
Implemented a special rule for visibility. Basically, the premise is this: A token is visible to "everyone" i.e. players, by default. By adding a player's name to an exclusion list, this player can no longer see the token, regardless of the other rules such as ownership, the standard visibility property, or being on the Hidden/GM layer.
Script functions to manipulate the elements of this rule have also been added to the Token API group. Please refer to the wiki and/or auto-completion, for more details.
Added a new argument for Sight: Limiter (case insensitive). This came about when the topic of Darkvision and how it interacts with the Daylight, was brought up. Before, a token's sight was clipped because of the smaller range of Darkvision, but this has been fixed so that a token can "see" normally during the day.
But there will be use cases where the range of a token's sight type actually needs to be enforced, such as when a character is inflicted with a status ailment etc. Using the new argument will tell the vision system that it needs to draw sight range according to type, and not according to maximum range, during the day.
Made json.toList into a permissive function i.e. no error thrown on an invalid JSON or plain string value passed. This is for backward compatibility with MapTool frameworks.
Improved fog clearing algorithm for free ("unsnapped") movement.
The latest H2 Database library brought a lot of changes. Some of these changes made existing 3rd party database clients like SQL Workbench/J, incompatible. Therefore, we've integrated calling the H2 web console from the app, to allow operations on Mote databases.
The control for this is the button with the database icon on the toolbar up top. A prompt will appear to type in the name of database you want to view. Once you submit, the connection URL to this database will be placed on the system clipboard, where all you have to do is to paste it on the Connection URL field on the web console that opens up.
Lookup tables can now hold and run "[]"-type scripts. Previously, these tables can only run scripts that start with a "/".
Undo/Redo system for Blocking improved to include erased areas, and expanded to include FoW exposures.
The findToken() macro function was phased out in favor of the superior token.id() function.
Fog of War functions now resolve maps faster and better, accepting map IDs over just the usual name.
The Mote Wiki is now accessible from within the application, through a button on the macro editor.
We've finally gotten around to tackling a very minor, but often requested change. Entries in chat will fully utilize the first line, instead of having a line break after the header. Warning: there may be side-effects with regard to output! You have been warned! This is a very tedious job, for the minor returns it gives. We're not working on it until it fits perfectly for every possible output. Worst case would be to revert to what it was prior to the change.
Phased out JavaFX-based messaging views that were used for IRC channels, and Private messaging (both local and IRC). We really wanted to evolve the JavaFX view. We understand it was very primitive, but we had a lot of plans for it, with Sift in mind. But user feedback was lacking, so we moved development on this feature to being in Sift alone.
In its place, we created a Swing-based alternative that we believe many will be happy with; mainly because each view utilizes the same HTML-based "canvas" used by the main chat output (we'll let that sink in for a moment...).
However, complex routing schemes for macros are left for a future implementation (if ever; maybe never!) For now, macros will only output to the main view. Let's get things stable, where everyone is happy that one-on-one and group PM sessions perform without a hitch (don't forget IRC!). 1-on-1 and group PM sessions are started the same way as they always did, selected from list pulled up from the chat toolbar. Multiple selections on this list is allowed, to initiate group sessions.
A nifty feature we coded in is, each "chat" tab remembers the "persona" of the users involved, at the moment it was created. When a user switches between chat session tabs, he/she assumes the persona assigned for that view. To assist with this, the Members List accessible on the Chat Input toolbar, now also lists all player owned tokens. Tokens with multiple owners, will have multiple entries, at one per owner.
Therefore, a user can generate an encounter or conversation, without asking every player to do an impersonation, beforehand. All that needs to be done is to send a message to the intended recipient. When the recipient switches to that chat view, he/she will assume the character assigned to him for that session.
For example, to start a standard user to user PM session, a user selects the name of another user from either the Member List View accessible through the Chat toolbar, or the Connections Window. The difference between the 2 lists is, the former allows multiple selections to generate Group PM sessions, while the latter can only do single selections, hence is good only for creating one-on-one sessions.
Let's say the GM impersonates Elf #1, opens up the list of connected clients and selects Dwarf #1 owned by Player A to converse with. The GM sends a message, and Player A sees it on chat. Switching to that tab, Player A assumes the role of Dwarf #1 for that conversation. Personas in PM sessions are immutable i.e. you can't switch to other identities, or drop the assigned identity to go back to your player name.
IRC sessions are wired to the active nickname for the IRC server. You can't override this using the Impersonation system. To change this nick, utilize IRC commands such as (/nick <name>)
With the changes to messaging, using the Save control on the Chat toolbar will save the content in all session views.
Impersonation per map. Switching between maps switches to the active impersonation for it, if there is one.
Map context menu now accessible on most tools. Either double-right click or hold Control and right click once.
You are now able to create a list of IRC servers and channels to automatically join. New controls were put into the Preferences Window, under the Application Tab.
To add a server or channel to the list, just type into the text field and hit 'Enter'. There are 3 simple rules to the list. If an entry starts with a "#", it's considered a channel. Anything else is considered a server. There is no validation process for these entries, so do be careful.
Secondly, follow the "Server then Channels" rule. This means that any channels (i.e. entries starting with a "#") that come after a server entry, are considered to be that server's channels. For example, we have list that has "irc.freenode.net", "#test_1", "#test_2", "#test_3", "irc.darkmyst.org", "#rpg_1", "#rpg_2". The channels #test_1 to 3 belong to irc.freenode.net, and will be automatically joined once a successful connection to FreeNode has been made. The same is true for DarkMyst's #rpg_1 and 2. By default, the DarkMyst server is the first server connected to. So, on the list, you can immediately add DarkMyst channels, without having to add irc.darkmyst.org to the list. This is only true if these are the 1st entries on the list. If another server is 1st on the list, you will have to make an entry for DarkMyst, in order to attribute any subsequent channels to it.
Lastly, your channels may have passwords to them. If so, when you make an entry for such a channel, follow the format "<channel name>:<password>". For example, "#rpg_1:my_password". Before you ask, we opted to go this route instead of using a table. Easier for us, easier for you all.
There are some hotkeys to this new section. Hitting Escape on the entry field will clear its content. Ctrl+Up and Ctrl+Down on the actual list, moves an entry up or down the list, respectively. In the event of multiple selections, the entry with the smallest index gets manipulated. Using Delete on the list will remove any selected entries on the list.
The Log Viewer is now better and more responsive than ever. Check it and see for yourselves :)
Overall, lower memory usage, albeit file load times may take longer a bit, since we're trying a more memory-efficient approach.
FYI: With the big changes to the scripting API, there will be instances where previously accessible functions are blocked from use. these functions, for whatever reason, did not have security check, even if they are able to query GM-only data, or perform changes to tokens (e.g. setSize/token.setSize).
This lead to mixed standards of macro code. Ideally, token changes should be performed from trusted sources such as a library token, and should not be written on macros found on a PC/NPC token itself.
Following this guideline will make macro execution more secure. For now, we will keep the new restrictions on, and we'll have a community discussion on the affected functions, and where to go with it.
Understandably, we know that expert script writers don't like breaks during execution that they didn't put in themselves, but we hope that everyone will come to agree that this is a positive step forward toward an improved scripting set.
Data Cleaner is now integrated into the installation package. Linux & Windows users will have an executable they can run, whereas OS X users will have to use an action found under the 'File' menu, to perform the reset.
The latest Mote Wiki is also accessible via app, via a button in the macro editor.
We saved this item for last, we've incorporated a "Donate" link up top, on the menu bar, for people who want to support us in freeing up more time in getting our other projects online sooner.
Our Patreon will also field feature requests we deem fall outside the developmental scope we've set for Mote. There are already some items found on this list, and if you'd like to see any of these get implemented, do consider becoming a patron! ^_^
Fixed:Clients with mismatched versions w/ a server are now served a warning instead of being barred from connecting outright. This was a previous fix that didn't work 100%. Now it does.Longstanding issue with Darkvision not seeing light sourcesCorrect handling of a certain use case for Individual Views and FoW.Improved the floating Map tools pop-up behaviors, making the process more fluid e.g. auto selects the 1st tool when none is yet active, hotkeys etc.