CSLoader::createNode 载入资源。
发布一定要在项目的 Resources 根目录下,
如果要发布到的是 Resources 的子目录下,就要 FileUtils::getInstance()->setSearchPaths 这样子搞。
1.6可以随意发布到Resources中的任何子目录,不需要 setSearchPaths ,
只需要在路径中填写完整的相对于 Resources 的相对路径即可。
我想不通,为什么不继承1.6的机制?非要限制在Resources根,或者要 setSearchPaths 。
论坛有多少人问过为什么 CSLoader::createNode 载入资源崩溃了?
他们都是按照以前的使用习惯来使用cocostudio 2.0的,
他们想当然地认为只要填写相对于 Resources 的相对目录就可以了。
这样的问题,以后还会有,新手还会继续在这个莫名其妙地限制上绊倒,
然后花费时间去搜索答案,去提问,你们也要不厌其烦地回答: setSearchPaths , setSearchPaths 。
资源文件夹可能会有一些分类文件夹,方便管理资源。
比如:UI分类,Animations分类等。
这些文件夹都要 setSearchPaths ,非常麻烦。
而且可能大类下还会有细分。再细分的话,又要 setSearchPaths 。。。
有人会说,你所有的设计放到一个cocostudio的工程中做,
然后在工程中建立文件夹,这样来分类,最后发布到 Resources 根不就行了么?
好,那么问题来了。
项目中有人专门做UI,有人专门做动画。
他们要同时进行。他们同时编辑一个项目,会有项目合并的困难。
实际的情况可能是这样:
做UI的人,单独建立一个 cocostudio 项目。
做动画的人,单独建立一个 cocostudio 项目。
单独建立项目是为了互不干扰,并行同时工作。
再细分的情况下,有时候分配任务,可能是:
美术A负责场景1,2,3的UI。
美术B负责场景4,5,6的UI。
他们都会自己建个单独的项目来搞。
他们都发布到 Resources 根下,文件会乱得要死。而且可能名字会有冲突。沟通的成本增大。
如果,他们不发布到 Resources 根,那么我就要各种 setSearchPaths !
有时候分类感觉不合理了,调整资源的物理文件路径,也需要相应地改 setSearchPaths 中的路径。
为什么2.0的设计者会假设资源设计输出应该发布到 Resources 根下?
2.0 不适合在有3个人以上的项目合作。
不支持美术、策划等“高效率地“并行开发。
不是说不支持并行开发,而是要一起同时工作,沟通的成本大,工作繁琐,效率低。
现在我的情况是这样:
1:
要么一个工程包含UI,动画,一次性输出到 Resources 根。
所有人串行工作。
或者并行,但要解决工程文件的冲突。
2:
要么 UI,动画,分别建立自己的工程,然后发布到Resources 下的不同分类文件中,
然后程序 全部 setSearchPaths 。如果要改资源的分类路径,setSearchPaths 的路径也要改掉。
这么耦合、低效的工作流设计,是谁想出来的?
cocostudio业余就业余在各种细节上。好像自己从来没有做过开发一样,各种坑,不完善。
1.6的资源载入,多方便,为什么不继续采用?
说说理由