Fixed bug with hero levels not loading inventory. (Might not be in line with the performance that 975c6a was going for.)

This commit is contained in:
Nick Winter 2014-09-03 19:19:04 -07:00
parent 35f22e0f8c
commit b1de5e0045

View file

@ -24,14 +24,14 @@ module.exports = class Level extends CocoModel
# Figure out ThangTypes' Components
tmap = {}
tmap[t.thangType] = true for t in o.thangs ? []
o.thangTypes = (original: tt.get('original'), name: tt.get('name'), components: $.extend(true, [], tt.get('components')) for tt in supermodel.getModels ThangType when tmap[tt.get('original')] or tt.isFullyLoaded())
o.thangTypes = (original: tt.get('original'), name: tt.get('name'), components: $.extend(true, [], tt.get('components')) for tt in supermodel.getModels ThangType when tmap[tt.get('original')] or tt.get('components'))
@sortThangComponents o.thangTypes, o.levelComponents, 'ThangType'
@fillInDefaultComponentConfiguration o.thangTypes, o.levelComponents
o
cachedLevelComponents: null
getCachedLevelComponents: (supermodel) ->
@cachedLevelComponents ?= {}
levelComponents = supermodel.getModels LevelComponent
@ -43,7 +43,7 @@ module.exports = class Level extends CocoModel
@cachedLevelComponents[levelComponent.id] ?= @cachedLevelComponents[levelComponent.id] = $.extend(true, {}, levelComponent.attributes)
newLevelComponents.push(@cachedLevelComponents[levelComponent.id])
newLevelComponents
denormalize: (supermodel, session) ->
o = $.extend true, {}, @attributes
if o.thangs and @get('type', true) is 'hero'