Ah, I see. That's not what I understood when you said 'plugin help page'. I thought you meant the github link off the store page...
Regardless, just wanted to start in the same place as you and we're on the same page now.
I've written a sample and tested it.
My example zips up two PNG files and as you've seen, only the last one is getting stored.
To debug, I added a little more output to see what the listener is seeing:
response table: 03B7F460
The last line gives me a clue. It looks like the indexing is hosed up. See how 'pinky.png' is stored at index 0? That should be 1 or higher. So, if I were to warrant a guess I'd say the indexing code in the zip plugin is not getting initialized and/or incremented so all objects are listed at '0' and the last one is the only one found when it is time to zip.
I think you can submit this as a bug at this point and use the above linked code (download if needed) to submit the bug.
Note however. I think you can get the plugin code and probably find the exact source of this issue:
I would totally understand if you simply filed a bug though and I concur that it is likely a bug.
PS - Additional details for your bug filing. This seems to fail on:
- 2015.2697 for OSes you mentioned
- 2016.2716 for Simulator running under Windows 10 (my current primary setup)
So is may be the 'core' zip code (if there is a common set) as it is showing in multiple places.
Edited by roaminggamer, 19 September 2015 - 11:29 AM.