Creator 资源加载对文件扩展名限定的疑惑！！！

Creator 3.x
#23

Unity 没有这个限制，可是也不支持使用扩展名进行加载，因此如果重名的话文件就加载不到了。
UE 用的是 soft path，这个 path 也是不带扩展名的。当然你可以用，但是如果这个扩展名在导入前后发生变更，一样容易会坑到自己。

#24

name+ext 说到底只是对一个资源进行索引的一个key(也就是通常说的路径) 现在你们是使用name+你们定义的type去查找你们处理后的资源了 如果你们改为name+ext再加上你们定义的type去查找 是完全没有问题的

#25

看看前面小兄弟说的，开发者为什么要关心美术用的是什么格式的资源？fbx 就不能换成 gltf？png 就不能换成 jpg？

#26

这个见仁见智吧，在你看来 ext 是 key，在我看来是一个 path，而且是一个极其容易改变的 path。

#27

name+ext 是一个path 可是对于你们处理后资源来说 name+ext 就变成一个key了 你们使用name去查找处理后的真实资源路径

对于引擎内置一些资源，比如图片，模型，声音等 你们可能考虑到开发过程中资源会变换格式，这样对于已经做好的预制来说，使用name去索引，预制是可以不需要修改的。

但是对于非引擎内置资源，却没有类似的需求或者说是依赖关系。对于不能识别的文件资源，为什么也不允许放在同一目录下呢？ 比如我上面示例中的自定义格式的文件 *.map *.objs *.grass文件。

#28

只要支持用扩展名加载，所有人都会带上扩展名。API 上无法提现出这个差异，大家只能尽可能保守使用。
然后就会影响到容易变换格式的资源，一旦格式变换，又会有人像你一样跳出来，说出类似的话：

实在是不理解：为什么引擎层要武断地认为资源扩展名不需要修改
我不知道你们在自信什么？
看看市面上的引擎， unity也好，unreal也好 都不带扩展名

#29

你们不是提供了一个 loadRemote吗？ 可以通过传入扩展名去访问资源
只是你们不允许同一目录下，存在同名却扩展名不一样的文件

creator中预处理机制是没有问题的 对于引擎内置的资源，使用name去加载也是没有问题的
但是对于非引擎内置资源，希望可以放开这个限制 我想是不难的。

引擎内置的资源，我想你们是可以在官方文档中作出说明的：
比如:图片支持那些类型的文件，这些文件在同一目录下是不能存在同名文件的，比如1.png和1.jpg是不能在同一目录下的

#30

一个接口搞不定，就多一个接口出来呀
给不同需求的开发者使用

#31

loadRemote 加载的是 url 啊，不经过编辑器处理的

API 的区分会造成使用的不便，实现成本过高了。

前面解释过了，核心不是是否能同名，而是后缀会变，构建后的后缀也会变

#32

都说到这个份上了，你们还是执念自己心中的理念，作为使用者的我也只能表示无奈了。
一个引擎或者说工具包容性越来越小的时候，也就是离梦想越来越远的时候。

我只是希望Creator能够越来越好用，别无其它！

#33

感觉争论引擎的底层设计是否合理没有什么意义，关键是让官方协助你解决问题

#34

关键是官方认为这不是问题

#35

不要说让别人怎么改，底层设计不会随便改的，问问官方有什么变通的方法解决你的需求才是正解

#36

这就是我表示无奈的原因，只能通过变通的方式去解决。
但是我觉得Creator作为一个引擎或者工具，不能老是让使用者通过各种变通的方式去解决问题，这其实就是变相增加使用者的负担，相当于要让使用者多做事情，这也是大家觉得Creator不好用的原因之一。

Creator不应当想着有各种变通的办法去解决使用者遇到的问题而不对引擎底层可能存在的问题进行思考和优化。

希望Creator能够越来越好用，也是广大使用者的心声！

Creator越来越好用，才能走得更远！

#37

cocos一直在进行底层架构的优化的，这不是短时间做到的，耐心一些，先把你的实际问题解决了先，建议有很多想法的人，可以朝着进入Cocos引擎开发团队的方向努力，为Cocos做的更好贡献自己的力量

#38

loadRemote 加载一切资源。resources我都不用。 不过你如果依赖cocos creator的编辑器的话，应该不适合你。 我是用了其他ui编辑器。

#39

我下午试验了下 通过 assetManager.downloader.register() 注册一个自定义扩展名的加载器，使用loadRemote去加载是可以行得通的。

只能变通去使用！

1赞
#40

我们不是不思考，正因为进行了充足的，长时间的思考和权衡才做出了这样的设计。我前面已经多次指出这样的弊端和混乱，只是你觉得我们要解决的问题对你来说不是问题。

在我看来你遇到的不是问题，仅仅是你觉得“这样设计最开放”。我们是一个工业产品，开放不是我们的首要追求，开放需要建立在不牺牲工业化的基础上。如果单纯追求开放我们继续发展 2d-x 就好了。

在你用观点反驳而不是用事实反驳的情况下，我只能盲猜支撑你做出这个决策的信息量其实是比引擎组少的，因此决策质量通常不可能比我们还高。（从你随口拿 UE 和 Unity 想打脸结果反被打就能看出来）

我们做的是一个 framework，不是一个 SDK。 希望一个产品功能可以无限伸缩，又不引入其它副作用，抱歉确实有点理想化了。任何设计都是有代价的，没有银弹，我们只能平衡。众口难调，不断满足所有人，最终只会得到平庸的设计和平庸的引擎。所有 API 都有前提，都有限制，引擎绝对不可能用新增 API 的方式解决所有喜好问题，且不说我们维护兼容性代价会有多大，那样也只会带来“懒政”。

代码里面不用写扩展名，或者把自定义的文件名从 abc.objs 改成 abc.objs.bin，让大家多做了很多事情吗？你不肯给文件加个 .bin 后缀，我们也拦不住你想舍近求远使用 loadRemote。

还是谢谢反馈，让 Creator 越来越好用，是我的核心目标。也欢迎继续跟我反馈工作中遇到的痛点，让我们更清楚用户需要完成什么任务。

1赞
#41
#42