Thursday, November 16, 2017

Mote 1.11 Changelog


What's new:

This version has a ton of internal changes which we'll itemize below. This major release marks the start of the Global Repository (GREP, don't laugh anyone LOL) experiment. "Experiment", because it's future is dependent on Sandstorm's success. That's just reality folks ;)

You can read more about it on our blog post on the subject.

We've also overhauled z-ordering (draw order) in Mote, using an algorithm we cam up with. More details about this can be found on our other new blog post.

Anyway, we hope you all enjoy this release!

  • This is the final client config for Sandstorm. Please test.
  • The active perspective gets saved on exiting the application.
  • Addressed holow area edge case for path finding and MELs, especially when used for unsnapped movement
  • Improved path finding logic. 
  • New hotkeys for when the map has focus. Alt + 1 to 4 selects the active layer
  • Added support for extra mouse buttons (i.e. back and forth). For now, this was only applied to the map.

    New functionalities are:


    • Forward button = Redo last drawn object
    • Back button = Undo last drawn object
    • Shift + Forward button = Go to next map (cycles)
    • Shift + Back button = Go to previous map (cycles)
    • Ctrl + Forward button = Redo last drawn blocking or fog object.
    • Ctrl + Back button = Undo last drawn blocking or fog object.
We forgot to update the context help list prior to making this release. We'll get it on the next one ;)
  • function.define has a new parameter to define a description for what the UDF, returns. For more info, review its auto-completion entry.
  • json.get now defaults to JSON object, when an empty or blank entry is passed by the user.
  • The Sandstorm Login dialog can now be properly canceled and closed via the dialog control (i.e. 'X' window control). Escape to cancel & close, will also work.
  • We added an entry to the Tools menu to force the initial function correction process, which is part of the file conversion when converting an MT campaign or framework to Mote 1.6+. We realized that some users were still using some obsolete methods, even after 1.6+, and couldn't avail of the automated process.
Fixed:
  • Reported issues w/ Window API functions
  • Reported issues w/ Token Bar functions
  • Sandstorm login dialog could not be closed. Now it can be closed, and hitting Escapse, will also close this dialog.
  • User-defined functions created via function.define will now display the its description properly.
  • Erroneous code completion entries.
  • Several minor issues and bugs.
  • Disabled Dynamic Blocking on a previous version. It should be working again.

Sandstorm: Global Repository

The Global Repository (GREP) is an experimental Sandstorm module we've recently completed. It is a feature where users subscribed to Session Hosting on our Sandstorm service, can upload image data found within their framework or campaigns, for Sandstorm to host and disseminate to their players.

Long-time users of Mote know that a repository allows others who connect to a game session to receive game assets a lot quicker. This is because they are able to download these assets directly from an online source, as opposed to getting them from the GM's machine, where the transfer speed is often bottle-necked by the available upload bandwidth of the session's host.

Basically, the system works this way: A subscriber to Session Hosting (usually the GM), has full access to it. They can perform uploads to the GREP, and clients connecting to their game sessions, will be served assets by Sandstorm, if available and as needed.

Beyond just being a content delivery service, the GREP lays the foundation for a browsable library of user-driven, contributed content, that everyone around the world, can access and use for their gaming needs.

Mote 1.11 is the first version of the client, that uses this repository. For a limited time, all users can freely upload image assets, without any size limits. This will allow everyone to test the service as well help us out with ironing out any issues, before Sandstorm goes live.

To begin the process, simply log into Sandstorm via Mote, select any number of tokens as upload candidates, right-click on one of the selected tokens to open the context menu, and select the option to upload the assets to Sandstorm.

Note that all images that are associated to a token, such as the portrait image and the actual token image, will be processed for upload. At the end of the testing period we've set aside for Sandstorm (which is ending soon, by the way), all uploaded content will be purged, and only subscribers to Session Hosting, can avail of this feature for their gaming group. Users should also expect an upload size limit, as well.

Uploads are tagged, according to the genres selected by the uploader. You will understand what we mean by this, when you first use the feature. An asset will be attributed to the user who first uploads it into the GREP (by way of e-mail address), and will be named or identified, by the file name of the image's source. With these things in mind, do name your uploads (i.e. all associated images) with something thoughtful and/or intuitive, as this will be immutable for the entire time the asset exists in the GREP. Attributions will not be made public, but will rather be used to notify an uploader, of any concerns regarding an upload.

We do want to ask everyone to only upload content that is legally permissible to share. For the sake of everyone who will come to use this service, we also ask people to only upload content that is helpful to the VTT experience. Nothing that is not safe for work (i.e. NSFW), please LOL.

Part of our future-proofing for this service, is to have a takedown process, for any content that is reported to be in breach of copyrights, or any other claims of ownership, and you may experience a sudden loss of access to an upload, if we are told to remove it from the GREP. We will release guidelines and fair usage info, once Sandstorm goes live for public use. We ask users to adhere to these policies, as any violation of them policies, will be met with penalties.

While Mote's version of repositories allows the serving of other Mote-specific files (specifically audio and databases), the GREP can only serve image assets, for now. The "lifetime" of GREP and its expansion to allow the other file types is largely dependent on the success of Sandstorm, as a whole. This holds true for the rest of our developmental branches, so please do help us out in growing Sandstorm's subscriber base :D

New World Order

Most of you know what z-ordering is. For those who don't, in Mote, it simply is the numerical order by which map objects and entities, are drawn, stacked from lowest to highest.

Mote inherited the z-Ordering scheme from MT, which basically used the highest and lowest values of rank, in order to place what's newly added to a map. Drawing order was also determined by which layer the object, background, or entity (e.g token), was on. In this system, even if the z-order value placed a background stamp above, let's say, player tokens, it will always get drawn at the bottom of such entities.

When we made changes in Mote, we inadvertently affected this system, ending up with z-order overruling layer placement. This caused some chaos on imported campaigns and frameworks, where objects and entities suddenly appeared based on what their z-Order told them to be.

Back then, we applied a quick fix, basically still keeping the MT system, and applying some methods to return the relevance of layer placement. Unfortunately, this solution was not comprehensive, and recent user reports exposed its weaknesses. Reverting back to what MT had, is also a no-go. the system has its own flaws as well.

In 1.11, we went back to this part of the code, discussed and implemented what we hope to be, a final solution. Our new algorithm looks like this:

  • Separate backgrounds and map entities into 2 groups. Backgrounds z-ordering will be from 0 and negative "infinity". Everything else will start from 1 to positive "infinity".
  • If something is added to the map, it's z-order will be determined by what it's placed on.

    If it's placed on a vacant part of the map, it will have a z-order rank based on the layer it's on. If it's placed on a stack of other map objects or entities, it will get the highest rank, for that stack. Other components of the stack, will have their z-ordering, adjusted accordingly.
  • Any other stacks, entities, or objects that have some relation to the affected stack, will also have their values adjusted. We term such a collection as a cluster.
We've also upgraded the Fix Map Object and Entity Types action under the Map menu. Apart from setting Token/Object/Background typing according to the layer it is found on, it will set an initial z-order of 0 for Backgrounds, and 1 for everything else.

Users will also be prompted if they want to reset z-order values for everything, using an extension of our new algorithm. This will "compress" stacks and set z-ordering for "standalone" stamps and tokens, to values in the new ordering that are relative to what they originally were in the former ordering.

We hope you these changes are welcome to you all. Note that this will only affect campaigns and/or frameworks, from this point on. Any exsiting values for z-ordering will remain, as long as these are not submitted either through the action mentioned above, or an automatic correction is made, when something is moved in between layers, or an invalid value for z-ordering, is set.

As with all such changes to Mote, we advise that users keep backups of their campaigns/frameworks.

Cheers!


.

Saturday, October 28, 2017

Mote 1.10

What's new: 
  • Newly reconfigured Sandstorm process. Please help us out and test it out with your group, especially before actual game days. It will help us greatly. Thanks.
  • Adding to the introduction of Movement Event Layers in version 1.9, we are pleased to introduce the next logical feature to complement it: Path finding.
    • Path finding is built on top of the existing (vision) blocking layer system.
    • It's precise, for the most part, although it can be better. The are edge cases involving circular and linear blocks where a section (i.e. cell) of the path will intersect with parts of the block. This has to do with the underlying mathematics and the limitations caused by the inherited map code from MT, where a loss of precision happens.
    • This was written separately from MELs, but is meant to be complementary to each other. Path finding is also meant to synergize with the previously written Dynamic Blocks, though we haven't tested that part as thoroughly was we wanted to.

      TL;DR Expect some growing pains as we fine tune both new features ;)
    • Like MELs, path finding is enabled by default when no server is in session (i.e. design mode). However, like MELs, these need to be enabled manually, via session policy, when a server is started. New options for these are on the dialog for starting a session server.
    • The Measure Tool can be used to visualize path finding, although, for now, it's still limited to paths made by a "medium-sized" (default size) token.
    • Path finding primarily works for snapped-to-grid movement, with some elements, such as movement denial, also available for unsnapped movement. We have earmarked expanding the feature for unsnapped movement, sometime in the future.

       
  • Added some new controls to the UI, for convenience sake e.g. Sandstorm login/logout.
  • Better UI responsivess when interfacing with Sandstorm.
  • General UI improvements
  • Autosave recovery is now optional. You can find an option for it under the Files menu.
Fixed:
  • Timing and ordering of Mote's initiative events e.g. onTurnStart, onTurnEnd, onRoundStart, onRoundEnd
  • More areas in the code that inadvertently revealed the map, due to the changes we made to the map drawing process.
  • Waypoint setting via mouse, while dragging a token.
  • Initiative functions involving token attributes. They now accept token names or ids as arguments, to specifiy the token to process. Please check code completion (i.e. type "initiative." to pull up the group), for more info.
  • Wrong code completion entries.
  • Minor UI bugs and behaviors

Friday, September 29, 2017

Movement in Mote


We're excited to announce several new movement-related features for our Mote application. These features are still in design mode, so do expect bugs here and there, though we've done our best to root out any we could find, prior to the release of version 1.9. As always, help us out by reporting any issue you may find :)

Starting off, we've added a new tool group to add Movement Event Layers (MEL) to the map. In a nutshell, when a token enters a defined MEL area, things happen.

MELs are based off previous tools and inherit all the good stuff we've added to them, such as undo/redo, deletion, grouping, merging (incomplete testing, do at your own risk), and drag relocation. As drawables, MELs can only be seen by GMs 

The most basic event, which triggers automatically, is movement cost. When you want to draw a MEL, you can enter a value for cost, using the upgraded control panel found at the lower right of the map.

You can also set a unique ID for a MEL, here.

New Attributes

To track movement, 2 attributes were added to the token model: Current Movement, and Movement Cap. Each time a token is moved, it's current movement gets updated. Each time a token is picked up and dragged for movement, it's current movement is compared against it's movement cap. 

If a potential path's length (for snapped-to-grid movement) or distance (for unsnapped movement) exceeds the token's set cap, you will get a visual cue in the form of red cells or lines. All movement that exceeds the cap will be automatically denied, should a user set the token down.

To set the values for these new attributes, you can either use the Token Editor dialog, or use the new functions we've added to the Token Properties API (more on this later). Setting a cap will automatically set the current movement to 0. Conversely, blanking out the cap field, will deactivate movement tracking for the token.

To keep with the underlying logical design, a token's current movement is set back to 0, after each initiative round.

Steps vs. Distance

As of this time, we treat movement costs against "steps" instead of how far (distance) a token can travel. Rest assured, the design is still malleable, so this can be changed in the future, once this feature is discussed with the user community.

The main reason for this choice is simplicity. Steps are easier to keep track of, and computations based on them, are easier as well. If the map grid is changed, it will not affect step values.

Of course, one can bind steps to actual distance values, via script, but that's another subject best reserved for another time and with the input of more experienced script writers ;) 

Enforcement

The enforcement of these new movement-related features is active by default.

This can be toggled on the session level. when you start one by hosting a server. Remember, session policies in Mote can be updated on-the-fly, even when the session is ongoing.

Advanced Features

Apart from the basic functionality of MELs, you can also set them to trigger scripts once a token is placed within it's bounds.

Unlike the usual event hooks, we try to make things simpler for designers by:
  •  Predefining what library to have. What this means is, in order for user-defined event hooks to work, you need to have a library token named lib:mel in your campaign/framework. If you don't have one yet, just drop in a new token and name it lib:mel.

    This is where you will place your macro events. If there is no such library token present, Mote will ignore the significance of a token landing on a MEL.
  • You can name your macro events any way you like. To enable their invocation, when you are about to draw a MEL, make sure you associate it with a macro event by typing in the name of the macro on the Event ID field in the control panel. Event IDs are different from MEL IDs, although you can use the same value for both, because, why not?

  • All triggered events will have the following set of helpful variables:(subject to change in the future):
    • layer.id: the ID of the triggered MEL
    • event.id: self-reference for the event associated with the triggered MEL
    • token.id: the primary token that triggered the MEL
    • move.distance: how far the token moved.
    • move.contacts: a JSON array of coordinates where the token intersected the MEL bounds.
  • New script functions for this featuer have been added they are: token.movement, token.setMovement, token.movementCap, token.setMovementCap, token.resetMovement, and token.toggleMovement.
Editing

MELs are limitedly editable, and you can only do so one at a time, even when a group of MELs, is selected (i..e the primary MEL will hold focus). 

To edit a MEL, just click to select the one you want to change. You will see the control panel update its contents. For now, the only editable items are MEL Id, Event ID, and Movement Cost.

Borders

Since the areas of Mote drawables also include their borders, you must take this into consideration when laying MELs. If you don't want the added border area, make sure you set the borderless option (i.e. a white square with a red diagonal line running through it), before you draw.

Closing

We hope you all enjoy this new feature, and we'll be eager to hear if and when you incorporate this into your games :)

Help us improve on it by giving us feedback, either in our forums, or on G+. 

Thanks guys!

Mote 1.9

We have another major update which introduces Movement Event Layers (MEL), and updates to both token movement and map tools, in accordance with this new feature. Check out our dedicated article on Movement, for more details :)

Since this version introduces changes to the map and token models, please make sure to have a backup of your campaign, and other files.
Lastly, we have to apologize but we just didn't have time to update the Mote wiki with all the new changes (and the growing backlog of old ones, as well). To address this issue for the future, we've branched out the update process to allow us to deliver the wiki, without needing to time it with an actual Mote release.

Thank you.

Other new stuff:
  • New event hooks by request: onDeselect and onGroupDeselect
  • Expanded auto-updating process to handle Mote's Wiki separately from the app. This allows us to push updating the wiki at a more flexible date, instead of at the same time with a Mote update.
  • It's hard to explain, but we've tweaked the selection behavior for drawings in the hopes of improving it. Just try it out, to get a feel.
  • Hollow oval and hollow rectangle drawing tools.
  • Expanded map tools with the introductions of the MEL tool group
  • Created a branch in the update process to separate Mote wiki updates from the app itself.
Fixed:
  • Reported issue regarding the block.clearRules() function
  • Optimized Dynamic Blocking code that fixes a reported performance issue.
  • Updated and fixed Total API Conversion process for version 1.8+
  • Icons for map tools

Monday, August 28, 2017

Mote 1.8.2 Change log 

This is released both as an installer and by auto-update, to make it easier for new users. (details below)

What's new:
  • Made the update feature a bit more user-friendly, via startup notifications and links to facilitate auto-updating
  • Relaxed some rules on hosting Sandstorm-assisted sessions, on the same machine.
Fixed:
  • Conficting actions mapped to the Escape key
  • Another discovered issue with map rendering vs. the UI.
  • Code cleanup.
  • Home page redirect from app

Mote 1.11 Changelog What's new: This version has a ton of internal changes which we'll itemize below. This major release marks th...