When adding image table images with the proper file naming convention to the Source folder, pdc will create a pdt imagetable for it. When you later change/add/remove frames; pdc will not update them. It's great for pdc's speed that it doesn't re-encode existing assets, but some hashing would need to be added to detect updates to source assets. This caught me twice, costing about half an hour to track down.
Workaround: delete an existing pdx and re-run pdc. Or go into that pdx and specifically delete the pdt.
This might affect other assets as well, did not try audio, video, or other files
I did a quick sanity check and it seems like it's working correctly. I didn't actually change the image but the compiler did generate a new output pdt.
dave@Dave Scratch % ls -l Source/chrome-table-100-34.png
-rw-r--r-- 1 dave staff 2006 Sep 15 15:18 Source/chrome-table-100-34.png
dave@Dave Scratch % ls -l Source.pdx/chrome.pdt
-rw-r--r-- 1 dave staff 543 Sep 15 15:18 Source.pdx/chrome.pdt
dave@Dave Scratch % touch Source/chrome-table-100-34.png
dave@Dave Scratch % pdc Source
dave@Dave Scratch % ls -l Source/chrome-table-100-34.png
-rw-r--r-- 1 dave staff 2006 Sep 15 15:19 Source/chrome-table-100-34.png
dave@Dave Scratch % ls -l Source.pdx/chrome.pdt
-rw-r--r-- 1 dave staff 543 Sep 15 15:19 Source.pdx/chrome.pdt
pdc compares timestamps and skips recompiling if the target file isn't older than the source file. I know we've had some trouble getting the correct modification time on some platforms, though.
Aha! You're using separate images with sequence numbers in the name, not the single image with cell size, aren't you? I can reproduce the bug there--it only recompiles the image when the first frame has changed, and doesn't notice added or removed frames. That's not gonna be an easy fix.. Maybe for now I'll just have it recompile those sequences every time.
Yes, I use the sequential approach rather than the matrix. So another workaround is using a matrix I guess.
FYI whenever I see 2 approaches in de docs, I always wonder about performance. It's a bit silly to make assumptions here, as it depends on the implementation. Might be nice to add a few words on that in the documentation along the lines of "When all your frames have the same size; a matrix is slightly more memory efficient and faster too"
In this case there's no mention of performance difference because there isn't any. That's all handled at compile time; there's no difference between an image table created from a single image versus a sequence.
well, okay, it wasn't that hard to fix. I'd forgotten the compiler already has a list of all the files in the sequence at that point. MR is in the queue, will hopefully be included in 1.13