Holiday Update and End of Year Projections
over 7 years ago – Thu, Dec 22, 2016 at 09:22:39 PM

Greetings and Salutations,

Owlbear here with a blast update to bring everyone up to speed and onto the same page regarding the D20PRO kickstarter. First off, I'd like to thank everyone for continuing to follow along and your near infinite patience as we march toward the finish line.

I'd also like to take a moment before the deep dive to call out a pretty major event for us. As of today, 12/22/2016, we've officially landed our first major license deal for a game system. We signed with Paizo and will be producing official content for their brand under the D20PRO moniker and marketplace. There is a lot to do to make this as solid an offering as we'd like, so our content folks will be shifting attention toward the Paizo products while the devs to plug away at features and capabilities in the app.

You can read more about the release directly from our blog here. 

I'd also like to thank our marketing and content teams for the bang up job they've been doing to grow awareness of D20PRO and our community. Since August, they've drawn a facebook community of over 8000 users (and climbing) as well as a growing community on twitter! This is a huge shift from the 200-ish, when being kind, we had following D20PRO before GenCon 2016.

Okay, so enough about them and on to the game!

Status Update

I won't sugar coat it. It's been slow going. The core reason for this is simple, coding takes time and some of the things we're doing to meet the Kickstarter goals are very difficult to accomplish without blowing up the system. Now with that in mind, we've been making major progress on Rules and Features (both part of the Unlimited Rules component). 

There are two core portions to the current Rules API and Feature Library systems. I'll describe them both below.

Feature Library (A Visual Overview)

The Feature Library is the core in-app editor for building custom rules and, well, features.

The main components of the Feature Library are the library itself, and the Node Editor. The library hosts all of the features for a campaign and supports import and export allowing for custom features to be moved between campaigns. Eventually we'll provide a full inter-campaign library we're calling the Catalog (since Library was already used). Items saved to the Catalog will be accessible in their saved state from any Campaign. Additionally, you'll be able to set up an association between the Catalog item and a specific Campaign as the "tracked" item. But I digress... Feature Library!

The basic functionality of the Feature Library is to provide definitions for in-game elements which can affect the play space or creatures; Difficult Terrain, a casting of Cloud Kill, or a Barbarian's Rage ability are just a few examples of items ripe for Feature definitions.

The core mission of the Feature Library is to allow for definition of content which is variable based on the "caster" and/or the "target". I don't really have a better term than "caster" for the initiator of a feature so for the purposes of my own sanity, I'll use Caster to refer to a spell caster and feat/feature user alike.

The Feature Library currently looks like this:

The table is searchable, sortable and editable.  Check marks on the left side indicate Features which are active in the game. Uncheck a feature and that feature will not be used by anyone. The green wifi icon allows you to push alterations of a specific feature out to all players and creatures. This is an override and mostly present for debugging purposes, however, it is currently advisable to use the override button when disabling a feature to ensure that no one has one cached.

A GM shares their feature library with their players. Currently the player access to feature editing is extremely minimal to none. We are working on enabling access to a library of features (and other useful items) to players. For now, however, sync is from GM to Player.

Enabled Features auto-link with a class's traits as well as spells and special abilities. Below is an image showing a linked trait and the action button to launch the ability:

The Green icon launches the trait just like a special ability of old -- pops up the decision, and the Red edit icon will open up the node graph to edit the feature.

The Node Graph UI is very, very rough still, but below you can see an example spell configured using a variety of options. Different abilities require different levels of complexity and the node system is self filling -- click on a link and the proper node appears connected to it (going from left to right).

The trap detailed above uses an effect node which has a primary saving throw and a modify target that does 4d6 damage to targets that ENTER the area of effect.

The Map Template produces a 20-foot burst area with a transparent green fill and is NOT visible to players. One of the updates to the template system we added with the Feature Library is the ability to have visible and non-visible templates (from a player perspective). This allows for our trap to sit on the map with it's infinite duration and keep smacking any creature foolish enough to wander in.

In addition to On Enter triggers, we've added a slew of others.

Triggers allow effects to apply based on various conditions. Currently a feature can only have one trigger event per effect, however, this will get updated to support a check box system enabling a single feature to trigger under multiple circumstances.

Additionally, Triggers can be expanded through the Rules API or through javascript embedded in the Node system -- but more on that later.

What do these things do?

• On Target - the effect is resolved on the targets initiative
• On Caster - the effect is resolved on the casters initiative
• On Stay - (requires a template) the effect is resolved if a creature ends its turn in the target area
• On Exit - (requires a template) the effect is resolved when the target exits the area
• On Enter - (requires a template) the effect is resolved when the target enters the area
• On Cancel - (requires duration) the effect is resolved with the effect is canceled or ends for any reason

Another crazy cool node in need of some major UI refinement is the Repeat/Multiply Node.  

The core tools in this node are the ability to select classes that the effect repeats or multiplies for -- this can be "all" -- and the ability to set which levels or spell levels the effect is multiplied or repeated. Currently the system is only configured to handle a 3.5 style of per caster level, but through the Rules API this system changes to a per spell slot level used mechanic for 5e. The above image is showing a 3.5 magic missile's repeat node.

We also added in the ability to enable level stacking. This is a highly debated house rule where various levels from various classes can stack for the purpose of throwing around various types of energy. Well, now you can do that too.

And for the really ambitious, the Value Per Level option lets you sent the multiplier value applied for each apply at level tick.

The result is shown below for a repeated effect from a 5e magic missile cast with a 1st level spell slot. 

The Decision panel for the spell is augmented to include an Expand option. Each missile is given it's own Decision UI which is accessible through the expand button but is parented to the original decision. Once expanded, targeting and saves can be changed for each missile thrown. The expand UI is available to the Player and the GM allowing for as much oversight/alternation as necessary.

Clicking expand a second time will contract the decisions and allow the Ok button on the main effect to be pressed thereby committing the spell and resolving its effects.

When used in a multiply fashion, the node takes the effects damage and multiplies the effect. A great example is a Pathfinder fireball which does 1d6 per caster level. Using a effect that deals 1d6 and is multiplied by 1 per level between 1 and 10 you have a variable d6 fireball spell which uses the caster's level to determine potential damage.

As you can see, the Feature System also fully automates the template targeting and template removal based on casting duration -- instantaneous spells only present their template during the targeting and decision phase!

There are still quite a few kinks and bugs to work out before the system goes live, but for now, you can see how this is coming along and why we're putting so much of our time into the Feature Library.

Over the next week I'll be working on documentation and examples for the current Feature Library. Once this is done and ready, we'll push a full beta release out to the KS community.  If folks want an undocumented version before then, just let me know and we'll get a build ready for you sooner.

Other aspects of the library that were not ready today, but will likely be ready tomorrow or Monday are the Save/Challenge types. In order to handle rays and other features which use non-saving throw mechanics, we have a system to allow for interactions based on a two column table.

This new behavior replaces the Saving Throw node you might have spied above with a Challenge Node that allows for management of the above three types and variants thereof.

There is a lot more to the Feature Library that I could go into, however, this is already a mega post. Keep an eye out for the docs as they become ready and feel free to send questions to us either via KS, comments, or through the forums.

The next section is going to be pretty tech heavy although I personally find it enjoyable, it may not be everyone's cup of tea.

If you're looking for the what happens next wrap up, it's below the Rules API section!

Rules API (A technical overview)

The Rules API is a java class system which can be built by the end user and uses the D20PRO.jar that ships with the application to grant access the creature class model and game models.

The core of this library is built and functional, however, we've been expanding the library substantially over the last couple of months and have built in access to several UI components as well as injection points to interrupt/intercept attacks and decisions.

We are engaged in building out the 5e and Pathfinder Rules modules as samples as well as developing a best practices guide and building additional documentation. As this comes to a close, we should be able to release the API to backers for first pass usage, then we'll move to a public release.

The Rules API will release through GitHub by invitation only with public access being enabled when the we deem the system production ready. I apologize for playing this close the the chest over the last few months, the intention had been to release in September/October. Clearly I was mistaken to think so. The documentation task alone forced me to delay the release.

I will say that if there's anyone from the API category who's interested in helping to finalize this aspect of the app, I wouldn't say no to the help.

Above is a class outline for the current 5th edition rules system. The general breakdown of the API is to provide a programmable interface to change various aspects of how game mechanics are handled.

With that in mind, a brief summary of the class list and purpose is as follows: 

• Ability 
  The Ability class provides definitions for creature stats and stat handling. This is generally true for names, values, and any modifier calculations which need to be done.
• AC
  The AC class similarly provides access to control how a creature resists attacks. In 3.5/Pathfinder terms, this includes Normal AC, Flatfooted AC, Touch AC, CMD and Spell Resistance and Psionic Resistance. This extends the Custom Defenses concept built into D20PRO to enable additional defaults.
• Actions
  The actions class is part of the Feature Library system and defines a map of actions which can be used to manage effects.  Core action types are Effect, Condition, and Challenge. This is one of the areas being most heavily altered at the moment as we complete work on the Feature Library, we're finding that some of our concepts need alterations to be functional in the wild -- not everything that looks good on paper holds up when let loose in the wild (of internal testing).
• CreatureClass
  CreatureClass is a broad category that is focused on supplying Rules utilities to the core application. This is a nice way of saying it's a development sandbox where we incubate helper functions which eventually migrate to the appropriate classes in the Rules file, but... I like the first description better!
• D20PreferencesModel_AddOn
  An extension to the preferences model, the D20PreferencesModel_AddOn class provides additional settings to the game system based on Rules. Many of the elements provided here are defaults which can be toggled to enable/disable subsystems in the D20PRO engine. A good example is the 5th Edition Advantage/Disadvantage system. The specific mechanic isn't defined by the preference, just that this rule system uses an action interrupt which can alter the outcome of a die roll. How to handle the interrupt is described in the preference.
• Duration
  Controls game durations such as rounds, turns, seconds, minutes, hours, days, weeks, etc. This allows for complete control over all elements of time and duration of effects in the game space.
• FeatureRecharge
  This one is a bit of an outlier at the moment as it doesn't have a proper home yet. Many modern game systems use a recharge mechanic to abstract bad-guys abilities. Rather than loading down your bad guy with a ton of abilities, they might only have one or two really potent powers which they can reuse under some recharge condition such as a die roll or a period of rest. This class defines those conditions for the current game system.
• Features
  Parent class for the whole Feature Library system. Features attack to specific key types based on a character sheet's layout and organization. As such, this class allows you to alter the connectivity between a Feature and a customized sheet design. At it's base level, this case provides the broad categories and associated classes which define them.  For example, we've currently implemented Traits, Special Abilities and Spells in the Feature Library. As you can see below, we've got some plans for what can be done via the Feature Library. Also, you might note a correlation between the standard tabs of a character sheet and the feature options!

• GameSystem 
  At this point, this enum is mostly just historical. It establishes a list of "compatible" Rules plugins. Since 5e, Pathfinder, 3.5 and 4e are so similar in their creature model, it is very easy to switch between the game system without breaking everything excessively. Values in the Game System enum are used to populate the valid Rule sets you can switch between from the Options->Rules panel. You'd still have to have the correct rules installed for them to show up in the drop down however.
  
  Point of note, Rules plugins are specific to your Judge folder, not your Campaign. This means that if you had Savage Worlds, Fate, and DC Heros installed along side Pathfinder you may find that you can swap between these rules adhoc.
• Grapple 
  Yup, grapple was a thing you could do in 3.5 and Pathfinder that was hardcoded into D20PRO. So... rather than rip it out from the ba-gillion places it's used, we created a Rules based override. Do you need a special attack type that anyone can use? Override grapple and you've got it, otherwise just return null and call it a day. 
• HP 
  Does your game system track health using some system of numbers, tokens or other "countable" element? Then you've likely got a HP system! This class does just what you'd think. It allows for override on Hit Points, calculations, bonuses, penalties, and any other sort of HP related topic you can think of (like temporary hitpoints and non-lethal damage!)
• ModifyTarget 
  Another Feature Library class, this one provides Effects with a list of ModifyTargets. These are things like HP, AC, Stats, Speed, Skils, and the like. If you can damage it or heal it or boost it, it goes in this class.
• ModifyType 
  So we can modify the target thing, but how do we handle stacking. In most game systems there is a concept of type for effects which grant bonuses. The Modify Type system provides access to this to allow you to control what types can be applied to an effect. Additionally, this class will (but doesn't yet, still to be migrated to Rules) stacking. We've done a lot of work to improve the stacking system in D20PRO enhancing the logic and providing clearer overrides and interrupts, however, it's all going to get migrated from the core classes into the Rules as the variants to are vast.
• Money 
  Your characters collect it, spend it, and adore it. This is the class were you define their fiscal existence.
• MovementType 
  A stub class at the moment. MovementType is related to the token movement rules that are slated for post-Feature Library development. In addition to handling rules regarding where you can move, the MovementType class handles how you can move -- fly, swim, walk, crawl, burrow, etc. Again, the full implementation if not yet ready for this one.
• Save 
  Save is a base "resist thing" class. For D&D and D&D like games, it's a direct saving throw definition and handler class. For other games, Save will handle challenges like Discipline vs. Willpower and such.
• Size 
  Size is a container class for size and space constraints for the current Rule set. Additionally, Size defines human readable names for sizes like Tiny, Large, Huge, etc.
• Skill 
  Again, most game systems have some concept of skills. This class defines how we handle them, what they are and if they can do funky fresh things. Skill examples include Skill ranks, bonuses and such for 3.5 content, Proficiency for 5e and Disciplines for Vampire.
• Spell 
  Dust off the magical ... dust. The Spell class is used to define traits of the current games system. Paired with a SpellCaster_<type> handler, this class allows for retooling of the spell memorization, spell prep and spell usage interfaces. It is designed for use with complex pool systems such as spells per level 
• Type 
  Largely a backup for classes data, the Type category populates the Races/Types element in the Traits panel. Under developed, this will provide a base for a Rule set to provide defaults. It also defines default values for classes and races imported from the Manually Specified folder's classes file. 
  
  Basically, Type is a default values for races and types with overrides living in classes.
• UI 
  This class is definitely still growing. It provides UI overrides for the top menu, creature right click menu's and the main menu. Eventually full overrides will exist for panel layouts and all other aspects of the visual space.
• Usage 
  Handles usage rates for abilities and traits -- At Will; Per Day; Per Init; Charge; Recharge; etc. This class defines the constants and human readable language associated with these constants.
  
  Usage will likely consume the Recharge class above and be used to handle all usage states in addition to the constants.
• FiveRules()
  The root method for the given Rule set. For most Rule sets, this method simply attaches the Rules to the AbstractRules class so they can be loaded and reflected into the application. However, this can be expanded to include any other custom loaders or system calls necessary. Did you build a custom external application you want to attach to the game? This class could be used to call it when the rules are instantiated. Think Unity3D app connectors... oooooh my.
  

Yeah, that's a lot of data and yeah, that was a lot of work! There is still lots to be done here but you can get a fairly good picture of what is possible within the system from the above outline.

What happens next aka where are my features!

We're working on them! I have to apologize for the time it's taking to get everything done. We're putting in all the hours that we can and then some. That being said, I've recently brought on a networking engineer to take some of the load off of my shoulders regarding connectivity and game lobby support.

While not specifically a kickstarter goal and perhaps not useful to those of you looking for local only games, this is a major hurdle in the market for the application and has caused us to lose a fair amount of potential traffic. Running the numbers and polling trial users has indicated this as the number one sore spot for the current application.

The big advantage, from the perspective of the kickstarter, is that I'm not going to be building that part of the project! My expertise is in rules, UI, and graphics. While I've done networking at the super-computing level, I've never built it in Java which increases the time to build something resilient and bug free.

This means that the core team and I can focus on knocking out the API and Feature Library so we can move on to Grids and Token updates.

We prioritized Rules and features over the map updates and campaign updates because, again, market research (and common sense) indicated that we needed to support the current popular game systems. D20PRO was limping along in this regard so these features took a front seat over grids and such.

These features are still on our road map. They will still happen. It will just take time due to coding and human resources.

On a side note, even our CPA is excited about where we're headed from here! And no, he's not a gamer :P

Happy Holidays!

On behalf of the whole Mesa Mundi team, I want to wish you all happy and safe holidays. If you're gaming, game responsibly and GM's, keep the TPK's to a minimum!

I have been attempting to maintain a fairly accurate running "release-notes" page here.  This is not to say that the releases detailed are public, but this should give a sense of progress as we're making it. That being said, I don't always have a session open that lets me update immediately. If you see lag in updates, it's not due to beig idle, it's likely due to not spending time in VI.

The feature library docs are located off of that link as well.  Again, these are WIP so please bare with me.

May you roll many 20's over the holidays!

Owlbear and team

Laying it out on the virtual tabletop
almost 8 years ago – Fri, Oct 07, 2016 at 06:08:00 PM

News First

The last two months have been relatively crazy on the Mesa Mundi and D20PRO front. We've been working hard to stabilize the current production build so those of you currently using D20PRO are able to without concern and error.

Additionally, we've been negotiating with Paizo and helping to draft a generalized Virtual Tabletop policy for their IP.  The result will be that we'll have access to their full library to bring new and exciting content to the application, but more importantly, it opens a door for further licenses (such as the elusive Wizards license).

These are good things. The downside is that development has slowed to a certain extent. We're still working hard on the application and putting in the all the time we can, however, under our current structure, I wear a lot of hats (Owlbear). The result is that my work on the Rules API is very late. For that I want to apologize.

There are some core developments that I want to share regarding where we are in the project and where we're headed. But before that, I need to explain about another major business opportunity we've been engaged in.

For nearly the last month, we've been engaged in a discussion with Trapdoor Technologies to merge our companies. The resulting entity would encompass virtual tabletop technology, mobile character management, and a massive push in the epub/documentation space. Trapdoor produces Playbook for Pathfinder and had previously been engaged with Wizards for DungeonScape. 

The initial discussion was about pure integration -- offering playbook style support for D20PRO. The idea had been to leverage the Rules API to offer expanded support to Playbook for additional systems. However, it quickly became evident that the proper direction was to merge our teams and our resources to create a significantly stronger company and story.

Many of the details are still being hashed out, and many more are completely in the TBD category. As it pertains to us (You, as backers, and myself, as the rep for D20PRO), this deal going through will bring a massive upswing to our space.

Development Status

Merging of two companies is a pain, and very time consuming. However, I'm still committed to fulfilling this kickstarter. Our contractor over at VironIT has been pushing the bytes during the long risk analysis meetings I've been involved in. He's making great headway with our feature engine and rolled an API build for us for today.

While I plan to release the API build through our beta archive this evening. I wanted to highlight some of the updates we're still in progress on and also point out the beta is not for the meek of heart.

The beta release is far from complete. It will allow you to test and play with sheet changes and using plugins, however, what we don't have ready is autoselection of a system through the preference system, nor do we have the API available for the developer group.

We should have both of those components ready early next week and available for Developer Access folks to start tinkering with.

Development Highlights

Feature Flow Diagrams (name TBD)

I know I've briefly talked about the Feature Library in the past. The basic concept of this library is to provide a user friendly way for non-coders to build rules and effects inside the engine. 

To this end, we've built out a flow diagram solution which uses a collection of node types to describe everything from spells to feats to terrain. 

Using these nodes, it is possible to describe spells and such which can have multiple effect types on the environment. This is an expansion on the existing Special Ability system within D20PRO and will exist alongside that system.

Obviously there's a long way to go on this one. The UI is still very crude but the above gif should give you a sense of what we're up to with this and some of what you'll be able to accomplish!

In addition to the existing nodes, the system is designed to allow developers to add new node types using Javascript and a JSON map to the creature template (the root object of all creatures in D20PRO).  This means that it will be possible to access everything from speed to level to description and modify it through a node diagram.

Pretty cool huh?! (I'm extremely excited by this feature in case you couldn't tell!)

Grid updates (Hex and Free)

I started work on Hex and Free grids last week between meetings. The result is a decent step toward producing a hex solution for D20PRO as well as a free grid solution. At this point I have hex's painting on the map as discrete cells. Mapping movement into the cells is the next step for the Hex grid. Free movement will take a little while longer as D20PRO was built using an integer space for it's grid world. This means that there needs to be a translation between the grid space and the arbitrary "free-space" that is needed for the new system.

Basically there are two directions we can go from here since Hex cells can now exist. One is to offer a pseudo-free movement model where creature movement does an intersection test against hexes and grids to determine which cell you're most likely in and use that for range, template and other calculations. This is likely the first method we'll build out.

The second solution is harder and will likely also get built out over time. In this solution, we'd enforce snapping to grids such that a creature is always present in the center of it's hex or square. 

The main reason to support option one first is that it can enable us to offer the range of grids sooner; In addition, option one allows for cells to be of arbitrary shapes, or polygons. Imagine if you could use the Fog of War draw tools to create your grid. this would allow you to build out a "grid" for tokens which is no longer confined to squares and hexes -- like a board game!

Multi Map Views (GM)

As part of the grid work above, we'd like to also update the GM's map view to enable more than one map in the map view scroll pane at any given time. For those of you familiar with Illustrator, think of the document view system where you can see more than one "worksheet" at a time.  

Players will still only see the maps that the GM has pushed to them. However, in the current implementation, if a player is on level 1 of a tower and second player is on level 2, when level 2 is updated by the GM and pushed to players, everyone's view is shifted to the level 2 map -- even if the player isn't present.

With the new Shadowcasting and such, this doesn't mean Player 1 can see the level 2 map specifically, but it can be confusing and annoying. To resolve this, the idea of the multi map view is to allow a GM to selectively push map updates to various players according to the active map or a global override (to push to all players).

This doesn't have a timetable, but is being worked on as part of the grids update. 

Rules Mixing

The Rules API has a very interesting and intentional feature which I wanted to call out here. We've built this system so that it can co-exist with other rules sets. For example, in the above image we have a 3.5 creature (top) and a 5e creature (bottom) open at the same time. In the current build of the Rules API branch, setting a rule set is a global function, however, the intent of the work we've been doing on the Rules system is to allow for simultaneous existence of creatures from different sources.

For D&D like games this can prove to be very handy as it will let you move creatures from the 3.5 SRD to Castles and Crusaders or convert your 5e character to Pathfinder (or vice versa).

When all is said and done, a creature will be able to carry it's game system with it; And so long as the plugin for that system is available, the creature can be accessed and moved between other installed systems.

This feature will not be a full fledged converter, but it will supply a great deal of time saving to those few who might need it.

Voice over IP (VoIP) 

We've been working quietly behind the scenes building out a mumble based voice over IP solution for D20PRO. The service is far from ready, but the initial server build is functioning and our initial tests are proving that mumble is definitely the protocol for us.

This service is part of the "Tavern" initiative we've been working on which will provide game finding and social tools as well as in-app voice over IP and matching services.

The service will be fully integrated into the D20PRO experience while residing in a separate window which can be toggled to "always on top". 

The player and GM experiences are slightly different with the GM setting up a game and choosing to advertise it through the Tavern. An advertised game will get a name, password, number of seats, game system, and description. All of this data would be accessible to a connected player. When a GM hosts their game, we'll pull up a "table" for them in the lobby, i.e. create a new chat room, which carries the above meta data and requires the specified password for entry. 

An interested player would be able to message the GM for access/password before joining them at the table.

For a player, once they have joined a table, they can choose to launch D20PRO immediately. Doing so will auto-configure D20PRO for connection to the host's specification -- selecting game system, preferences, etc.

This work is very early and will likely not be fully function before the end of the year, however, we'll roll out pieces and parts as it comes online -- especially for the purpose of figuring out load requirements and such!

Network Punch-thu

One of the biggest stumbling blocks for D20PRO is the reliance on TCP/IP network and port access. To help with this we've been doing a whole lot of research on various networking solutions which would eliminate this problem going forward. We have a solution we've settled on and will be integrating this into D20PRO over the next few weeks. Additionally, this service ties in as a requirement for the VoIP service listed above!

For those of you interested in trying out the Rules API build I should have it posted this evening before I head out of town for weekend. After all of the above, I need to take a long rest   :P 

Have a great weekend and good gaming!

Owlbear and Team.

3.6.10 update released and a sneak preview of the Feature Library UI
almost 8 years ago – Fri, Sep 30, 2016 at 10:59:22 PM

Hello All,

I opted to release a service and bug fix version today rather than the full System API. We had a few issues in the previous release which I felt needed to be ironed out before we introduced a massive amount of complexity through the separation of the Rules system from the core application.

        Forum Update and Download Links

D20PRO version 3.6.10 released today for public consumption with the following feature/fixes and updates:

• Showing of DEX on the mouse over AC is now fixed. 
• Ability score '-' value can be set using -127 for a value. Also, '-' imports correctly. 
• Hero Lab and other importers have been renamed back to d20ProPlugin_<thing>. 
• CR is not a string field and can accept 1/2 or whatever. 
• Traits Description box now sports a scroll bar for vertical scrolling when needed. 
• EasyFOW manipulation auto selects on FOW menu click if EasyFOW is enabled; otherwise shadow casting is used. 
• Added Race/Type and SubType combo box to the Traits panel. This value can take user entry as well. 
• Fixed Bug where sometimes stats would be changed to "all" 10's when an imported character had a stat altered. 
• Added System properties call to the D20 initializer to automatically use openGL and disable Direct2D. The reason for this is to enhance alpha blending for shadow casting and fog of war. 
• Updated Map Markers to allow syncing of files between players and GM (rather than GM->Player only). In addition it is now possible to add markers to a ManuallySpecified/markers folder and have these items synchronize during game play. UI for this will launch with the next release if all goes as planned; in the meantime, a player cannot sync markers until they reconnect. 

This release cleans up some outstanding issues and paves the way for a clean transition from the hard coded Rules system to the upcoming Rules API.

Okay, so what the plan from this point? The next step is to release the Rules API in BETA to you folks. I'm working on a clean branch which separates the Feature Library from the Rules API and should have that ready early to mid next week.

When I release the Beta, I'll submit a nice detailed update with pretty graphics and the rest.

In the meantime I have a teaser from the Feature Library work (Part of the longer term Rules API).

The UI is very rough still, but the system itself allows for expression of everything from Cloud Kill to Slow Fall. More importantly, With a "Rules-base" it becomes possible to configure rule sets through a visual editor!

Good gaming and talk to you again soon!
Owlbear

Update and Status Report
about 8 years ago – Mon, Sep 19, 2016 at 10:13:46 AM

Greetings Backers,

I wanted to reach out and give you all an update and status report. We're working to clean up some UI and confusion caused by the Rules API. Basically, there was a "too good to pass up" opportunity to clean up some behaviors as part of this update which were brought to my attention near the launch point for this work.

In addressing these long standing issues, we've caused some instability in the API which I want to address before releasing it. I believe we're still on track to release this month, as advertised, however, I wanted to let everyone know that we're still working at it!

In addition to the work on the API, we're working diligently on the Feature Library UI. The Feature Library will supply a system that allows for creation of custom effects and features based on the character sheet model. Using this system it becomes possible to create all manner of game effects from difficult terrain to fireball. The Feature Library is a major part of the user-friendly side of the Unlimited Rules goal. The initial launch of the feature library may be static without user interaction depending on the estimated timeline from the UI development. We're moving away from the traditional "long form" method of UI that Java Swing and D20PRO are perhaps a little too famous (infamous?) for.  My intent is to launch a read only version of this library initially with a stronger, user editable version to launch shortly after that.

I should have an ETA on phase I (read-only) and phase II (user-editable) deployment plans around the same time we launch the Rules API.

As usual, thanks for the continued support and sticking with us as we build out these advanced features!

Regards,

Owlbear

API Delay
about 8 years ago – Wed, Aug 31, 2016 at 06:23:18 PM

Hello All,

Due to a slight misunderstanding between the local team (me) and the remote team (our contractor), we're going to have to push back the Rules API release until next week. Basically the code is moving along wonderfully, however, the client access to said code is not there yet.  i.e. there's no user facing "Interface" in our Application Programming Interface -- le'sigh.

The main reason for this miss is that D20PRO is a closed source application but we're attempting to expose a core interface in such a way as to allow for community developers to build code which can run/inject into the application. The technique being employed is similar to our plug-ins for importers, hotjars. Jar files need to be compiled, which means that several elements need to be present outwardly to allow for compilation of the Rules hotjar.  

Additionally, there is some encryption/decryption that needs to be accounted for allowing for commercial rule sets to be built alongside public rule sets. i.e. 5e, Pathfinder, Thune, Savage Worlds, etc. which would be for-sale rule sets. The system we have now would work for one or the other of these types -- community or commercial but not both.

We don't expect the fix to take very long which is why we're only pushing the release back by a week.

We're still planning to release a bug fix update during the window tomorrow, but major updates, including the Rules engine, will be next week.

Thanks for your understanding and continued patience!

- Owlbear