[Wasn't sure whether to put this under Bugs or Development, as this appears to be a development-related bug. Feel free to move it as needed.]
Have run into an odd problem
doing addon work, which is also cropping up
in the T2 module. I've distilled it down to a relatively isolated test case:
The latest official release of my
"Save" Talent/Stat Points addon, downloaded directly from te4.org, works without error on both v1.5.5 and v1.5.8. The attached .teaa file below (renamed .zip, since .teaa is not an allowed attachment type), zipped up myself from AFAICT identical contents, works on v1.5.5 but dies in v1.5.8 before reaching the character creation dialog, with the following stack trace:
Code:
Lua Error: ...dons/savepoints/superload/mod/class/uiset/Minimalist.lua:41: attempt to index a nil value
At [C]:-1 __index
At ...dons/savepoints/superload/mod/class/uiset/Minimalist.lua:41
At [C]:-1 require
At /mod/class/Game.lua:403 loaded
At /engine/GameEnergyBased.lua:39 init
At /engine/GameTurnBased.lua:39 init
At /mod/class/Game.lua:76 init
At /engine/class.lua:147 new
At /engine/Module.lua:1032 instanciate
At /engine/utils.lua:2284 showMainMenu
At /engine/init.lua:191
At [C]:-1 dofile
At /loader/init.lua:217
Line 41 of the superloaded mod/class/uiset/Minimalist.lua is:
Code:
local pf_exp_back = {imageLoader("playerframe/exp_back.png"):glTexture()}
which calls the locally declared imageLoader() function:
Code:
local function imageLoader(file)
local sfile = "/data/gfx/"..UI.ui.."-ui/minimalist/"..file
if fs.exists(sfile) then
return core.display.loadImage(sfile)
else
return core.display.loadImage( "/data/gfx/ui/"..file)
end
end
From testing, it appears that core.display.loadImage() is returning nil for the offending image file, data/gfx/dark-ui/minimalist/playerframe/exp_back.png — which, again, is identical between the two .teaa's AFAICT. The immediately preceding line of Minimalist.lua loads another image in the same manner and is successful for both versions, so I don't think it's in the loadImage() method itself.
Has something changed in the internal compressed file system handling since v1.5.5? I'm pretty sure I'm using the same zip program that I was using before.