I decided we should start abstracting the major modules from the logic code for the following reasons:
(1) Allows changing the visuals without changing the game logic (ie can transfer an item same but visualize differently)
(2) Allows for more fine-grained yet less repetative updating modules:
ex: If you unequip an item, it should be available to sell, which requires updating the vendor mod. This required checking if the vendor mod was open, checking if you were selling, all that good stuff. And this logic had to appear for unequip, equip, drop, you get the idea.
Enter refreshOpenMods RIP refreshInfo
First off, refreshInfo was a great idea early on. whenever you wanted to update something, call a one stop function... but then
The Problem with refreshInfo
It got to the point that we were calling it ALL the time, updating html, etc. And the kicker was that the html being updated wasn't even always shown!
The Solution
After creating modules (#120), simply add a open property to them, and only refresh a module if its open!
The Bonus
I realized (as discussed earlier) that there were a lot of not-catch-all logic statements in callbacks for inventories, so I made it default for the action buttons (and drop buttons) to call the refreshOpenMods.
Note here that mod_cbs["refresh"] used to be a required function for displaying an inventory, but given that a change in one inventory often effects other open modules (vendor, combat, etc) this seemed the right move to make it the default.
Keeping Game Logic Clean
I think combat is the best example of this. The fight_enemy function was filled with code to make the hero symbol move, the enemy symbol move, the sliders to adjust, etc... it was really hard to even understand what was happening that wasn't visual!
Moving all that logic to the combatmod has the two benefits of:
keeping the fighting logic clean
allowing improvements to the visuals to be made without changing (1), and vice versa!
Fixes #120
HTML Module Separation
I decided we should start abstracting the major modules from the logic code for the following reasons: (1) Allows changing the visuals without changing the game logic (ie can transfer an item same but visualize differently) (2) Allows for more fine-grained yet less repetative updating modules: ex: If you unequip an item, it should be available to sell, which requires updating the vendor mod. This required checking if the vendor mod was open, checking if you were selling, all that good stuff. And this logic had to appear for unequip, equip, drop, you get the idea.
Enter
refreshOpenModsRIPrefreshInfoFirst off, refreshInfo was a great idea early on. whenever you wanted to update something, call a one stop function... but then
The Problem with
refreshInfoIt got to the point that we were calling it ALL the time, updating html, etc. And the kicker was that the html being updated wasn't even always shown!
The Solution
After creating modules (#120), simply add a
openproperty to them, and only refresh a module if its open!The Bonus
I realized (as discussed earlier) that there were a lot of not-catch-all logic statements in callbacks for inventories, so I made it default for the action buttons (and drop buttons) to call the
refreshOpenMods.Note here that
mod_cbs["refresh"]used to be a required function for displaying an inventory, but given that a change in one inventory often effects other open modules (vendor, combat, etc) this seemed the right move to make it the default.Keeping Game Logic Clean
I think
combatis the best example of this. Thefight_enemyfunction was filled with code to make the hero symbol move, the enemy symbol move, the sliders to adjust, etc... it was really hard to even understand what was happening that wasn't visual!Moving all that logic to the combatmod has the two benefits of: