Monday, March 19, 2018

Video Hangouts

Subscribers to Sandstorm's Full-feature plan can now host video hangouts in their sessions!

When creating a server, just make sure your logged into Sandstorm, and toggle the Video Conference server setting option. Mote will do the rest.

Clients connecting to your game session, will automatically join your hangout. Everyone will be registered with the player name they registered in Mote.

You can close the conference window at any time. You can rejoin the session, if it's still active, via the new button found in the chat window toolbar (you can't miss it).

The feature will undergo more tweaking and customization, in the future. Do visit this post, from time to time, for updates.

Cheers!

Monday, February 26, 2018

Idle Engine: Javascript for our Virtual Tabletops

We are happy to announce that Idle Engine, our Javascript engine, has been integrated for use in Mote.

It will take some more updates to translate all of the functions of the Motescript API in order for them to work in Javascript, but this shouldn't take too long.

A discussion thread was opened for this feature, where the rolling list of function conversions, can also be found.

Javascript (JS) brings with it faster script execution speeds. It also makes our VTTs more accessible to a large number of users that are versed with the Javascript language. JS is also (arguably) a much easier language to learn over Mote's inherent scripting system, which many say holds a lot of idiosyncrasies not found in "popular" scripting languages. 

Some may say that other languages are more suited for scripting within the JVM (Groovy, for example). But the choice for Javascript was based on its relevance to the heavy use of HTML forms and views (e.g. in character sheets, input forms etc, as well as JSON, which is the main data structure used within our applications.

Like our earlier blog post on HTML5, this post will change over time, as the Javascript feature matures. Do come by from time to time, to keep up with any updates we make :)

How to write and use Javascript macros:



  • Mote's Javascript feature is only available to subscribers of Sandstorm's Full-feature plan. Full-feature users are able to write macros using JS.
  • Clients connecting to sessions hosted by Full-feature subscribers, can run these macros, without needing to be subscribed to the Full-feature plan.
  • You create a JS macro in the usual ways Motescript macros are made; either by making a macro button, or by using script.
  • In order for Mote to know where to send the script, you have to make sure you set the macro content type to "Javascript".
  • This property can be accessed via the Macro Properties Panel, which is integrated into the Macro Editor. You can open this panel up by hitting F5, or by clicking the 1st button, top-left, on the editor's toolbar.
  • Before you start writing your script, do remember to set code completion, appropriately. You can do this by selecting Javascript on the dropdown menu on the editor toolbar. By default, it's set to Motescript.

Things to note:

  • Do not expect JS macros to behave exactly as those written in Motescript. Idle Engine has no relation to the Motescript scripting language and parser.
  • For long-time Motescript writers, JS does not employ any of the delay/deferment tricks of Motescript i.e. context.delay, link.fire/execLink etc.
  • Script events, like onCampaignLoad, have not yet been converted. Rest assured, this will be tackled soon.
  • JS is single-threaded. While it is possible to open up multi-threading, this will not be tackled anytime soon.
  • Invoking other macros, is not yet possible, because the relevant bits that enables this in Motescript, have yet to be converted. This will be tackled soon. 
  • This feature fully functionaly, but is not yet mature, and will need community input, in order to make it the best it can be. We'll also work as fast as the community is interested in this.

Version 1.15

Javascript is here :)

You can read more about it on our blog post, which will be updated, from time to time, to reflect advancements in this feature.

The entirety of the Motescript API will take a few updates to get converted for Javascript use, we appreciate any feedback from the community as to which functions or function groups, to prioritize.

You can join the discussion thread we created, just for this topic.

What's new:
  • Javascript!
  • Macro editor improvements, both for Motescript and Javascript code completion. 
  • Started tackling the monolithic Token data dissemination problem. One beneficiary of this change is that you will notice improvements in the creation of macro buttons, via script.
Fixed:
  • Error reporting presentation
  • Name conflict resolution during the creation of a new map
  • Macro editor dock tab referencing
  • Links that route to areas in the script that cause errors
  • Macro properties panel display using the Macro button context menu
  • Code refactoring
  • Several auto-reported issues

Thursday, February 15, 2018

Version 1.14

As stated on the previous release, HTML5 has been imported into Mote. Read more about it here.
We were supposed to release 1.13, which lays the foundation for Javascript and extended macro editor support, but due to reports that came in prior to its release, and the progress that then came in with regard to HTML5, Mote's version number has been bumped up to 1.14.

What's new:
  • HTML5 Forms and Views
  • The macro editor is better than ever, with enhancements for the other supported content (HTML, XML, Javascript, CSS)
  • Minor update to hotkey mapping for the macro editor
  • Foundation for Javascript, implemented.
Fixed:
  • File saving process
  • Macro editor template insertion behavior e.g. alt+h
  • Error reporting
  • Bugs submitted via auto-reports

HTML5 Views and Forms

HTML5 is now available in Mote :)

Given it's a new feature, and an imported one at that (from Sift), there will likely be some kinks to iron out. This post will change over time, so do come back to check for updates, from time to time.

Things to consider:

  • In order to display HTML5 forms and views, you have to be logged into Sandstorm, and the session host should be subscribed to the full-feature plan.
  • To differentiate HTML5 code from older HTML versions, you must declare the document type at the top i.e. <DOCTYPE html>, which keeps to actual standards for HTML5. 

    If this is not present during runtime, the HTML content will be evaluated using the old HTML standard (3.2)
  • There is no in-form expression evaluation.

    Third I is an independent component and we have no intentions or plans to mimic MT/Mote-style Frames and Dialogs, where script is interspersed within HTML. 

    Contemporary standards for HTML advocate a separation of concerns, and our HTML5 feature provides means to accomplish dynamism, without the need for such expression evaluation.
  • Due to security considerations, Javascript cannot be referenced (i.e. <script src>), either locally, in-app, or externally.

    We are creating a white list where users submit useful and safe "libraries" for evaluation. If they pass muster, users can then reference them for their HTML5 content.

    Scripts bound within the script tag (<script>code</script>), will be allowed evaluation, as well as scripts referenced from library tokens.

2 Ways to Display HTML5

  • Directly from a Macro Button - Starting in version 1.14, users can directly launch HTML frames and dialogs, without using scripts. This works for the current HTML feature, as well. You can do this by:
    1. Create a macro button
    2. Enter HTML content. Again, remember to have the document type stated at the very top (<DOCTYPE html>).
    3. Hit F5, or click the 1st button on the macro editor toolbar, to open the Macro Properties panel
    4. Change the Content Type to HTML
    5. This will enable a couple of controls specific to HTML content.
      • Associate CSS - a convenience functionality to associate a macro containing (usually monolithic) CSS, instead of doing it via the usual link tag. In order to be included in this dropdown list, macros containing CSS must gave its content type set to "Cascading Style Sheet"

        For HTML5, all CSS references are collated for use, this includes CSS associated via this control, and CSS content referenced through link tags.
      • HTML Properties - The items in here are self-explanatory, but let's go over them briefly:
        • Width and Height - these values are for the containing window for the HTML form/view, and not for the actual HTML content. You will still have to define such values, in either the HTML content, or any associated CSS.
        • Transparent - HTML5 only. This affects the actual HTML5 form/view. Used mainly for visual effect.
        • Modal - parlance for a "blocking" window. What it does is limit input to the dialog only, preventing interaction with other components of the app's UI.

          Unfortunately, we missed committing the toggle that tells the app whether or not this macro launches a frame or dialog (sorry, we'll get it in on the next release!).
      • User Data - HTML5 only. This is a convenience control to pass data into the HTML form/view.

        Acceptable types of data are strings, numbers, and JSON objects or arrays.

        You can reference this passed data via the reserved variable window.args. Depending on what you passed, you can access its contents just like you would with any other Javascript entity e.g. window.args[0] (JSON array), window.args.key (JSON object), or just window.data (if what was passed was a "primitive" value i.e. number, string).
  • Window API: All the functionality present in macro buttons, are available via window.new(). This includes passing user data and HTML window properties.

    Furthermore, macro.create (known as createMacro in MT) was also expanded to reflect these new additions. Please review code completion, to know more about the changes to these functions. We will update this post further, as this feature matures.

Special Referencing

The following are similar to existing "internal" referencing. Note, these do not pass through the MScript parser (i.e This is not  in-form expression evaluation.):

For script tags (<script src=source>

  • macro@lib:token
  • macro@this - references the token where the running macro is located. In place of this, you can just do macro without the "@this".


For image tags (<img src=source>)
  • this - this gets the image of the token this macro is located on.
  • token.imageId - same as above
  • asset:// protocol - an internal protocol that fetches from the host or image asset cache 
  • image tokens (i.e. tokens named with the prefix "image:" e.g. image:token) - fetches the image of the referenced token.
For link tags  referencing CSS (<link rel="stylesheet" href=source>)

  • <css_macro_id>@this queries the token where this macro is located for the css macro referred to.
  • <css_macro_id>@macro.location() - same as above
  • Directly referencing library tokens e.g. <css_macro_id>@lib:token

The Window Host object

The Host object is a child of the Window object that holds several functions that serve as intermediaries between the HTML5 view and the Mote's underlying Java code. Current functions usable in form Javascript are:
  • window.host.reload() - triggers a page reload
  • window.host.update(html) - updates the view with the passed HTML.
  • wnidow.host.close() - closes the parent window (frame or dialog)

Passing data to the HTML5 view

As mentioned above, data can be passed as window.args, to be used in the HTML view.

Passing data back to the executing macro

When you want to return data back to the executing macro (when modal dialogs are used), or just to Mote, where it exists as data bound to the originating window, you pass it back via window.data.set(value). The usual acceptable data types can be passed i.e. string, numbers, JSON.

In macros, you can then reference this data by using the window.data() function. You can find more information on its usage, by consulting code-completion.

Submitting Form Data

When you want to submit a form, using <input type="submit">, won't do anything. Instead, use <button> tag (or the older <input type="button">), and set its onclick event to process the form's data and return it to the macro execution context.

Every user-created HTML5 window has a Return object, which you is used to send data back, via its set member method. Supported data types are numbers, strings, and JSON arrays or objects.

Here's some pseudo code that encapsulates the idea:

<!DOCTYPE html>
<html>
<body>
<script>
function ret() {   //process data to be returned    window.data.set(data);}</script>


<button onclick="ret()">Submit</button></body></html>

Thursday, January 25, 2018

Mote Version 1.12 Release Notes

Hello everyone :)

Obviously, this version is a major release ;)

This package uses an updated runtime environment so we're asking everyone to uninstall all previous versions of Mote, and use the new installers we've put up on our website.

Sandstorm is now live. Some of you might be seeing notifications when you sign-in using Mote, so do consider formally signing up ;)

This milestone marks the completion of the first Sandstorm module (detailed on its Kickstarter) and the start of our next set of plans., a good part of which, we'll detail below.

Before going there, let's get the usual stuff out of the way.

What's new:


  • This version is the first to be used for Sandstorm Live. We've created a menu and corresponding controls to start, manage, and end a subscription to Sandstorm, at the top of the app.

    Users who've participated in the open testing period can subscribe using this dialog. Controls on this dialog are enabled based on what's appropriate to your current status. For example, you can't subscribe when you're already on one, or you can't cancel a subscription, when you don't have any. You also can only update your payment details, if you've previously transacted with Sandstorm.

    Sandstorm for Mote follows a simple setup for groups, where one user's subscription (most likely the GM), provides all relevant features to the gaming group.

    For example, if a Mote client joins a session hosted by a GM subscribed to the Full Feature plan, then they can see and use everything that's currently available via Sandstorm. Conversely, groups using the Session Listing plan, will only have their session listed in Sandstorm, and nothing more.

    Lastly, for those who have not verified their registered email address, you can do this via the dialog as well. You cannot use Sandstorm, if you have an unverified account.
  • Finalized our Terms of Service and Privacy Policies. You can find these at our registration website.

    For users who've registered during the open testing period, it is implied that you are compliant with these agreements. If you find this disagreeable, please reach out to us, and we will deregister your account for you :)
  • Discontinuing support for 32-bit Linux systems.
  • Updated Cleaner app
  • Added the module foundation for future features we're mulling porting over from our sister VTT project, Sift. More on that below.
  • Finished implementation of color customization for the (Vision) Blocking feature.
  • New JSON API functions: json.toXml, json.fromXml.
  • New Sight API group. Initial functions are: sight.list, sight.get, sight.create, sight. and sight.delete.
  • code cleanup and optimization e.g. deprecated transmitting entire token data in favor of specific attributes or related information, which are smaller and don't require synchronization.
  • Revisited map tools logic and made (what we hope are) improvements to their usage flow.

    The details are lengthy and tedious to explain here. For example, we tackled prioritization when a user is in the middle of drawing an object, and decides to drag out a selection box, and what happens differs on whether the user starts the drag on or away from an object on the map. We also figured in situations based on the status of Eraser mode.

    There were quite a few of those we've written in, so you can see how long it would take to explain all of it. So, we urge users to just go with the motions of using them, to find out what changes we've made.
  • Unsnapped movement now reveals fog on paths with waypoints.
  • Backing preferences for map tools. Mote will save the last state of the control panel for pertinent tools, which are activated when a user toggles a tool group. Note, this is done on the group level, and not on an individual tool level. We think the latter is simply overkill :p
  • Added a toggle to lock or release map panning, for those who do delicate map drawing, using the mouse. Its hotkey is 'P', while the map is in focus.
  • Amendments and additions to application hot keys. Please consult the context help table, for more info. We've added a link to it in our opening messages, for ease of access.
  • Application toggles (e.g. Macro tab locking, face locking, map tool group pinning), now have corresponding hot key, with the exception of the IRC toggle.
  • Retired pure chat mode toggle. This was the button with the keyboard icon, under Application Toggles. Basically, if it's active, typing anything will route immediately to chat input, overriding any in-app hotkey etc.

    We thought it'd be useful for groups who don't do much scripting or other game customizations (e.g. IRC games, gamers only using the map etc.), and for giving users with Player-level permissions a useful feature, after denying them access to everything else :)).

    But, the list of hotkeys and amendments to it, is growing, with more changes to come. Having such a feature will eventually get in the way of players wanting to have access to hotkey convenience, hence the decision to phaseout this feature.
  • Improvements to UI functionality and "look-and-feel" e.g. icon update.
  • General code cleanup, internal library updates, and bump up to Java 8+ standards.
  • Added a preference that controls the interval between when a user releases the (left) mouse button to finalize drawing, and when the app considers the user decided to draw a selection box. This is to support the current usage logic we set for tools that draw on the map.

    This was added because a user observed that the current tool behavior would be tricky (and annoying) for people with shaky hands, who might potentially ruin their drawing, because they did a "drag" while finalizing the drawing.

    The default sensitivity value is set to 10. You can amend this in the Preferences dialog, under Accessibilty.

Fixed:


  • Continuing (and hopefully last) fix for Initiative events synchronization.
  • Logic for merging drawn objects on the map.
  • Revealing fog for snapped movement and related processes.
  • Drawing tools bug that hung the app on some platforms, or made tool groups, unusable.
  • Listeners on VBL color wells, which prevented the user from selecting a color.
  • Regression caused by updating old IO code to Java 8+ standards. 


As always, I might have missed some details while making this write-up :)) but, rest assured, that all of the major points, are in there ;)

With that out of the way...

Sandstorm is Live!

We are pleased to announce that Sandstorm subscriptions are now open. There are a few things we will need to explain.

For users that registered during the open testing period, we want to inform you all that we have added formal documents for Terms of Service and Privacy Policies. You can find these on the website you used to register for Sandstorm. If you've read them and disagree with what these entail, please email us and we will duly deregister your details for you. Our policy on this is, if you do not make such a request, you are retroactively bound to the terms and policies detailed therein.

Users who haven't registered yet will now go through an added step wherein they can make a choice to either continue on as a free user, which is appropriate for a player in a gaming group, or to avail of our existing subscription options.

Of these, there are 2 types: actual plans, and variable period activation. Actual subscription plans, are there for convenience, where the system handles recurring periodical payments, automatically. There are only 2 periods in the service: month-to-month and annually.

Variable period activation are for those who prefer to pay upfront (i.e. prepaid). A user simply decides on how many months they'd like to have access to the service, and will not have any recurring activities done on their account (i.e. periodical charges), after.

We do have a refund policy. In essence, it's prorated, for both subscription plans and variable period activation.

Access level within the service for Mote are  categorized as player (which is free), session listing (i.e. others get to see your session listed on Sandstorm, for ease of access), and full access (i.e. hosting, listing, connectivity assistance, and all relevant features currently available, and coming in the future). Pricing is available on the subscription portal, which is available either during the registration process for new users, or within Mote, via the management controls mentioned above (you can't miss it).

Users who are already registered in Sandstorm, can process their subscription by first logging into Sandstorm through Mote, and opening the management dialog, under the Sandstorm menu, where you will easily find the option to subscribe.

Note, please choose wisely. Once a plan is started, or a variable period is activated, and you want to change your mind, you would have to cancel your existing subscription (also available in the management dialog), before being able to start on a new one.

The Road to Sift

When Java 8 was released, we didn't receive the good news we wanted. We were part of a diverse group of teams and solo developers that asked for a means to natively integrate OpenGL projects with JavaFX. Throwing more water into the fire, any consideration toward this request was indefinitely pushed down the road. In essence, Oracle wants to push Java's built-in capabilities, over any any 3rd-party mediation. Anyone who wants OpenGL to work within the confines of JFX, will have to do the implementations themselves, which is a huge amount of work.

On the other side of the fence, developers that make Java bindings for OpenGL, have progressed just fine without picking up JavaFX. After all, they already have their own UI toolkits that suit their purposes just fine (e.g. simulations, gaming)., So they too see no urgency in tackling this request.

This poses a dilemma for us, as our desktop design for Sift relies primarily on a JavaFX UI scheme for command and control, with an OpenGL-powered engine for visuals. After steady work on this project, we do have both: a UI interface leveraging the best of what Java has at the moment, and an interactive presentation layer,which most of you will consider the "map".

We also have several options to integrate these 2 halves, but we do not have the intermediary to make such a union, seamless. Each option within our reach. comes with its own unacceptable drawbacks. For example, the best of these options that joins both halves, is also the slowest performing. Performance is measured in frames-per-second (FPS), and after all the tweaks we made, does not rise above the range of 15-20 fps. While that may be acceptable to some users, it is not for us. With so much potential for amazing visuals, it would be counterproductive to have it hampered by poor display.

Alternate Plans

Of course, while we waited for news on the official release for Java 8, we pursued a couple of contingency plans in the event we would not get what we hoped for. Once we made our decisions, we then started to amend our existing plans and work on things that can help with their success e.g. bumping up Sandstorm's availability.

Unlike the initial options we were hoping to become available, the majority of these alternate plans require more significant financial investment

Plan A is all about rolling up our sleeves and tackling the integration problem ourselves. This will effectively take us out of the picture for an indefinite period of time, which is something that we cannot afford to do.

Plan B engages with 2 of the teams that made and maintain the Java bindings for OpenGL (i.e. JOGL, LWJGL), making contributions and doing collaborations toward getting them to write code for what we need to have. The advantage of this approach is that we can leverage their front-line expertise, which we'll need to tackle such an important endeavor.

Plan C licenses promising technologies that we can use to solve the integration problem. Unfortunately, these licenses do not come cheap, but this plan is actually the one we prefer, since it keeps our team independent, and will cost us less, in the long run.

Regardless of whether we choose plan B or C, they're both out of our reach right now. We have decided not to do further crowd-funding runs, at least for the immediate future. We believe that development time and growing the user community, are better items to focus on, after this release.

Therefore, the immediacy of what will depend on Sandstorm and its success. The team has had a lot of talks about it and we've updated our plans to try and generate subscription interest. We are well aware that some of these decisions may not sit well with some of our current users, but we hope everyone will eventually understand our choices.

First, at some point in the future, we might be serving in-app advertising. All we can say right now is that we promise to make it as unobtrusive and tasteful, as possible. Anyone interested in this can get in touch with us for the details.

As for Sandstorm, in order to generate greater interest, we're working to import several features slated for Sift, into Mote. These features will then be made available, for Sandstorm subscribers to use (i.e. requires the user to sign-in to activate). I guess most people will know this as a form "freemium" model. 

The guys and I have discussed this topic exhaustively, and we believe our decisions on what to implement for free (e.g. path finding), and what to offer to users looking for something more, are fair, based on the intended designs, for both Mote and Sift.

We made this plan based on observations and analysis of Sandstorm's beta testing period. Our community, while solid, is simply too small to sustain our forward momentum, and most of our members ( you guys ;) ) are savvy enough that you don't need Sandstorm's current capabilities. This will likely hold true of anyone who comes over from using MapTool. With that in mind, in order to attract users of other VTT apps or services, we will need to make a compelling offer. 

Features under consideration:

Owing to the modular nature of Sift, here's the initial list of what we'll be (potentially) porting from it over to Mote:
  • HTML5 Forms: Subscribers will get to use Sift's HTML5 viewing module (dubbed Third I) for their forms and sheets, opening up a ton of benefits and possibilities that we won't go into detail here. 

  • Javascript bridge - If executed, components of Sift's JS engine that we deem relevant or compatible with Mote design, will be wired to Mote's existing script engine and API.

  • Video conferencing - Sandstorm integrated a video-conference bridge intended for Sift users. Subscribers will now have access to this service via Mote.
Other features have already (quietly) made their way into Mote e.g. path finding. More will be considered, as we go along.

The rule of thumb we're sticking to is, if a feature relies on Sandstorm delivery, it requires subscription for access; if a feature is an alternative to an existing and reliable feature in Mote (e.g. Third I and current Mote dialogs, frames and displays), these features will also require access via subscription; if a feature builds on something that's been present in Mote in versions 1.11 and below, it won't require access.

In essence, we'd like to make offerings that people who want something extra, to be excited about, while at the same time, have the rest of our users happy with what they freely get out of the box.

Current Reality

Sandstorm is built to scale on top of industry-leading cloud infrastructure, and we in a continuous process of making it as reliable as it can be made. However, such resilience comes with costs, and, because of how all of this started, it's something we can't keep up indefinitely, without help.

Also, to satisfactorily solve Sift's integration issue, investments would need to be made to acquire what's needed, which is something we can't do on our own.

With the support of a robust community, we can continue the development of all of our projects. so we ask everyone, both current members of this community and those who have are interested in joining, to please consider subscribing to Sandstorm, and to also help us grow the community at a faster clip. Invite people, write something to draw interest, or share what we already have for others to try; we'll appreciate any such efforts made :)

For those who aren't interested in subscribing but still want to extend your support, we do have a Patreon page.


If you like what you see, and love what you use, we look forward to your participation in making our idle ideas, become real.

We appreciate your continued support and we will always welcome constructive feedback. Thank you!

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.

Video Hangouts

Subscribers to Sandstorm's Full-feature plan can now host video hangouts in their sessions! When creating a server, just make sure you...