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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Creator越来越好用,才能走得更远!

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

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

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

只能变通去使用!

1赞

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

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

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

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

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

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

1赞

大家可以继续讨论,我就暂时不跟进这个帖子了,还有好多报告要写。

经过多次探讨之后,问题已经不是关于文件扩展名的问题了,而是引擎为什么不允许同一目录下存在同名却只是扩展名不一样的文件,unity或者UE引擎 是没有这样的限定的。

对于引擎内置资源(比如图片,声音等),有这样的限定,通过引擎官方的说明,我觉得是可以理解的。但是对于非引擎内置资源,也这样去限定的,我觉得就有点过了。

对于文件改个名,引擎官方可以认为不是多大个事,后期一个脚本就搞定了,但是我觉得就是这种认为好多事情不是多大个事的态度,是值得商榷的。

当然引擎官方可以有自己的态度,也可以有自己的坚持,我只是一个使用者,好多只能无奈接受(变通去解决问题)。

最后还是希望Creator能够越来越好用,能够越走越远!

这个问题真心头疼.跨平台应用想节省资源管理也不好整

同名不同后缀资源 1.A(矢量) 1.B(偏移) 就问怎么处理

jare这段说得让人信服
有理有节,态度诚恳。
目前使用3.x虽然有多处不如意
看到这个回贴,感觉creator是会越来越好的

1赞

3.5以后,cc.Asset的几个native相关的api都标为废弃了,所以你们是想让开发者咋处理?

引擎/编辑器 限制文件扩展名 我也觉得很奇怪
今天第一反应是我自己对引擎不熟悉,折腾了半天,发现引擎不支持 :joy: