老哥 用了win10的那个方案 还是报那个错呀
老哥，有办法在打包中，使用多线程调用etcpack进行纹理压缩吗
我觉得能，只要这个脚本接到任务后，直接返回成功， 然后自己创建一个线程去压缩纹理， 引擎应该就会触发下一个图片的压缩操作，这样应该就能实现多线程了，就是管理起来要麻烦些， 不过理论上应该可以实现
我这边，尝试去使用，碰见了两个问题，第一：etcpack每次进行纹理压缩，会生成一个临时文件，如果，尝试使用多线程去转换，会导致，转出来的pkm文件缺少。第二：cocos传递参数过去的时候是一个一个传递的，等上一个图片转换完毕，才会传第二个图片，主要是cocos传递完之后，会去对应的目录下寻找转换后的pkm文件，如果没找到，会报某个js错误，问题是那个js是打在 app.asar文件里，我尝试进行反编译，发现是被加密的，导致也无法修改js，所以目前这个优化卡着了
http://docs.cocos.com/creator/manual/zh/publish/custom-project-build-template.html
也可以这样，自己弄个插件， 定制构建流程， 在引擎构建开始时使用多线程去做压缩纹理，等引擎到这步的时候，已经有缓存了就快了
1赞
好的 老哥，我这边将尝试使用该方法进行处理，有效果的话 ，我跟你讲，并分享给你
1赞
老哥，我在使用缓存脚本过程中，发现有的图片压缩失败 返回command failed wiwth return code 1，这是什么原因导致的呢，大部分图片都可以压缩成功，只有极个别会发生这种情况，导致最后打包失败
1赞
而且 res = subprocess.call(["./etcpacktool", fromPath, cacheDir] + sys.argv[3:])
返回 res为 -6
这最好能把失败的图片打包发上来， 才好分析，应该是压缩工具返回的错误码，脚本的确也有点问题， 应该把错误抛出去， 让引擎知道发生了错误
我尝试了 用原本的工具进行压缩这张图片，发现是可以的，但是用python脚本的话，这几张图片就会失败，但是其他图片都可以正常 ，我现在将尝试 使用shell脚本 编写中间层，然后尝试，是否跟python一样 拿几张图片是否失败 老哥等我消息 
更新 引擎从3.3开始又不支持压缩纹理缓存了
那可能是 bug 吧？
感谢提供的思路,我引擎是3.3.1,第一次打包的确很慢,但是后来根据你提供的思路发现了引擎的缓存路径,3.x是支持的,那我就不重复造轮子了
嗯， 2.4 以后都支持了
2.4.6版本，缓存有时有效，有时没用。求问，现在缓存命中的条件是啥？感觉git checkout，debug切换release,打包报错等，相关操作都有可能导致缓存失效，理论上图片一样不就应该用得上。
能不能帮解释一下打包纹理压缩缓存怎么命中，感觉打包就像是拼阳寿。突然行突然不行，命令行打包啥配置都没改。
同问 同问 同问
切换分支以及重新执行批量修改meta文件的脚本（哪怕meta文件内容没有变化），再次构建时缓存都会失效。怀疑缓存机制是与资源的修改时间有关。所以我们在发包前的release分支上构建成功后，就不会再去切分支了，本地克隆两个仓库，有任何修改都通过cherry-pick的方式合过去。
缓存机制肯定是个天坑!!只能用中间件,替换的
老哥，你知道哪里还能下载mali texture compression tool么？