Thursday, October 19, 2017

Change Log: 2.38.785

As the whole world hopefully knows by now, we're getting real close to the Alpha release of The Watcher.

Accordingly, release 2.38.785 is mostly dedicated to tickets related to that: there are no feature/functionality enhancements for the legacy webapp in this one.

Also, if you're interested, we've got a public/world-facing "roadmap" (kanban board) for The Watcher: it's brand new, but as we dig into the Alpha release updates/support, I expect it to improve in quality/clarity.

Finally, I just got my 1.5 box, so I will be upgrading the Manager to support 1.5 rules/assets/etc. starting this weekend!

Thanks for using the Manager!

Corrections and Fixes

  1. Fixed a bug where the set_bleeding_tokens() Survivor method required a 'modifier' param (and should not have). -Khoa
  2. Addressed a mind-bending namespacing bug that expressed itself as an error in the log: updated the API's module to initialize using the 'self.root_module' style of init which should prevent the asset lookup errors.

Application Enhancement

  1. Re-implemented the Survivor Sheet notes application as AngularJS + API and removed all legacy webapp hooks:
    1. Replaced the Survivor Sheet notes controls with an AngularJS app.
    2. Deprecated the legacy webapp methods for representing Survivor Sheet notes controls.
    3. Deprecated get_survivor_notes() and all related methods/calls/support from the legacy webapp.
    4. Removed support from the legacy webapp Survivor class for adding/removing survivor notes.
    5. Refactored the survivorSheet.js methods addNote() and rmNote() to use API calls.
    6. Deprecated the (really shitty) update_survivor_notes() method from the legacy webapp.

API Development

  1. Enhanced the Survivor object to work better with The Watcher UI/UX:
    1. Added a new route called /survivor/set_many_attributes/<oid> for the Survivor object that allows many attributes to be updated in a single call. -Khoa
    2. Documented the set_many_attributes route
    3. Survivor set_attribute() method now supports the 'save' kwarg (for optional saving).
    4. The Survivor set_bleeding_tokens(), add_game_asset() and rm_game_asset() methods also now support the 'save' kwarg.
    5. Added /survivor/set_many_game_assets/<oid> route to the Survivor object and documented it. -Caleb
    6. Returning survivors now have their Bleeding Tokens removed (if they're alive: dead ones keep their tokens).
    7. Adding {'serialize_on_response': true} to any /survivor/action/<oid> route gets you the serialized survivor with your response. -Caleb
    8. Added self.game_asset_keys list attribute to the helper attributes that init with the Survivor object
    9. Added a new route called replace_game_assets() that evaluates an asset type for a Survivor and does adds/removes based on an incoming list of asset handles of that type. -Caleb
    10. Added {"serialize_on_response": true} to the docs. Documented replace_game_assets() as well.
  2. Updated the World's api_response_times() asset to include last 24 hours (which is broken...not sure why) and min response time. Updated the Admin Panel to include. -Caleb
  3. is now split into 'core' and 'expansions' (following the way we've got other assets files organized.
  4. Removed the 'principles' dict from the file and moved it into assets/ (for sanity/organization's sake).
  5. Implemented Survivor Notes control routes in the API:
    1. The add_notes() route/method replaces the legacy webapp version of the same
    2. Ditto the new rm_notes() route
    3. Documented both routes. 
  6. Settlement object's get_event_log() method now supports the 'lines' kwarg, that limits its return to that many lines.
  7. The Settlement object's serialize() method now uses the 'campaign' kwarg in place of the 'groups' kwarg.
  8. Added an element called 'campaign' to the results of the /settlement/get_campaign/<oid> route. -Logan
    1. Settlement 'campaign' element includes last five log lines. 
    2. Added latest survivor birth and death.


  1. Stupid question but how exactly the Watcher will differ from the current KDM manager? I lack knowledge on specific features that will come, are there any summary somewhere?

    1. The bad news is that there is no summary of differences or comparison of features. The good news is that the alpha release will be very soon, so you'll have a chance to see it in action very soon.

      In a nutshell, the main difference between and The Watcher, is that The Watcher is a brand new front-end/user interface that was designed by an actual designer and implemented in React by guys who are develop high-performance user interfaces for a living.

      The Watcher will use the same back-end (i.e. so you will not have to migrate or transfer data), but will have an all new, high-quality/high-performance front-end.

  2. Hi Timothy, I experience heavy lags / performance issues with the current kdm-manager site. For example, a survivor sheet takes good 15-20 seconds to open. Do you expect performance issues to cease to exist with the introduction of a new front-end?

    And thanks for the great job. In fact it is so good, that I can't even think of using "generic" pen-and-paper approach to KD:M bookkeeping.

    1. Yeah, performance has been really sucking since people's 1.5 copies started showing up: we've had a ton of new users this last week, the settlement creation rate is up over 100% and max response times on some of the critical API routes have hit 30 seconds in some cases.

      It's...not good.

      There's a couple of things that are coming up in the 1.5 upgrade release (which will probably come out Wednesday):
      - the Campaign Summary view should load a bit quicker, since we're cutting some API calls that will no longer be required
      - the Settlement Sheet should refresh a little faster for similar reasons: in addition to upgrading the app to support 1.5 rules, the next release will also phase out a lot of slow legacy webapp functionality.

      Finally, to answer your question, one of the main reasons for developing the Watcher in the first place is performance: when it is finally ready and when it eventually replaces the legacy webapp, it will absolutely go way, way faster just by virtue of how it will be deployed and the technology used to render views.

      Thanks again for using the Manager!