core.display.loadImage() returns nil in newer versions

[Zizzo]

[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: Select all

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: Select all

local pf_exp_back = {imageLoader("playerframe/exp_back.png"):glTexture()}

which calls the locally declared imageLoader() function:

Code: Select all

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.

[Zizzo]

Hmm, interesting: when I re-compress the addon using Perl's Archive::Zip module instead of the command-line 'zip' program (attached below; as before, identical contents according to zipcmp), the error moves to the preceding line 40:

Code: Select all

local pf_saved = {imageLoader("playerframe/saved.png"):glTexture()}

As noted above, that image was successfully loading before, which suggests a path dependence of some sort.

More frustratingly, at one point I was successfully using these self-zipped addons with the 1.6 alpha built from source; but then I updated from git and recompiled, and started getting the same error there too.

[darkgod]

Hum the zlib included in the source was updated to a newer version but I'm not quite sure why that would make it bork this way ...

[Zizzo]

If it helps narrow things down, the 1.6 build that worked for me was from a point when the image file discord.png was missing in the repo. I updated from git after compiling to fix that (but didn't recompile immediately), and things worked for a while; when I started running into other, unrelated trouble after that (trouble that, in retrospect, was probably manifesting from the Lua code rather than the C code, so I really shouldn't have expected recompiling to help), I recompiled from the updated code, and that's when the loadImage() problems reappeared.

[sound F/X: source diving] Hmm, you upgraded from zlib 1.2.3 in 1.5.5 to 1.2.11 in 1.5.8; on a wild guess, is it possible that that much of a change might have led to incompatibility with the lzlib library?

Out of idle curiosity, what are you using to package up addons server-side? I tried using the example 'minizip' program included with the zlib source code, on the theory that that would have the best chance of compatibility, but that got the same error. You've clearly got something on your end that works, though; if I can reproduce it on my end, we could at least bypass the problem.

[darkgod]

I'm just using "zip" command on linux, nothing special. I only set compression level to 0 because I care more about speed than space.

[Zizzo]

I'm just using "zip" command on linux, nothing special. I only set compression level to 0 because I care more about speed than space.

[sound F/X: testing] Aha! Repackaging the addon with compression level 0 removes the problem. It'll make the T2 module bigger, but I can work with that. Thanks.