The `InventoryTableController` had been split off from the existing
`InventoryController` some time ago, but was never properly factored
not to share common code. This change elimiates it altogether in
favor of the newly re-vamped `InventoryController` which is now
flexible enough to be used in both places.
When unparsing an inventory which contains an item whose unqualified
slug appears in multiple mods (e.g., "steel_ingot" appears in both
Railcraft and Mekanism), the `unparse` method would choose the wrong
fully-qualified slug to use in the resulting string.
This introduces the new crafting page design featuring a new vertical
layout and list display of all crafting steps. It also makes it easy
to move items between the have/need sections and even from each step
into your inventory (causing a new crafting plan to be created which
doesn't plan on making that item).
* Convert the `BaseController.hide` and `show` methods to be much
more robust in the use of CSS transitions (using a timer in case a
transition doesn't actually fire).
* Change `hide`/`show` to use events for communicating animation
state instead of callbacks
* Convert several controllers to fire events for communication with
parent controllers instead of accepting functions.
* Rewrite the `CraftPageController`, `CraftPage` model and related
Jade/SCSS files to implement the new design.
* Alter the `InventoryController` and `StackController` to allow a
variety of action buttons, and for the events from those action
buttons to bubble up to parent controllers
* Add the `StepController` and its related model, template, and style
sheet as part of the new craft page.
* Tweak the `ItemSelectorController` and related files to allow for
a variety of styles for the launcher button
When displaying an inventory list in read-only mode, it was possible
to reset the quantity to 9999 if the value was higher than that by
clicking the field. This accidentally triggered the validations
applied when editing the field even though editing wasn't possible.
Fix a bug in the crafting plan where it would determine the number of
repetitions of the recipe only based upon the primary output even
when the recipe was needed only for a secondary output (e.g., when a
recipe calls for Creosote Oil, which is only produced as a secondary
output).
* Create the SlotController and refactor it into the various places
where a crafting grid or crafting output is displayed
* Update the Recipe model to allow each "input" stack to retain the
count indicated in the data file. This required changing how a few
other classes interact with it in order for them to get the full
stack back again for each input (instead of just getting the item
slug)
* Update the ModVersionParser to allow for full stacks to be given
as input and refactored common code out for handling input/output/
tools stacks
1. All tests have been converted into regular command-line mocha
tests (instead of running in the browser), and the deployment
script has been changed to automatically fail any `--new`
deployment which doesn't pass.
2. Several small class (e.g., `Logger`) have been moved into a common
module, `crafting-guide-common` so that they may be shared between
the client and server.
Any link inside a item detail page's markdown description which does
not have a URL will be assumed to be the name of an item covered by
Crafting Guide and an URL will be added to reference the appropiate
browse page.
Andrew Miner