项目素材整理 #883
Comments
BTMuli
added
enhancement
|
|
还有如果顺利的话，3.x 版本之前我会把 角色半身照 给废弃掉，之后所有图像的尺寸就都能做到在分辨率上统一了。从此 |
|
如果增加的仓库体积太多我感觉接受不了，现在资源目录100m @mark9804 你觉得如果改成 webp ，等到七国开完了仓库体积上会有受益么 |
webp 按照我个人经验来说保守压缩模式下能减少 50% 左右的整体大小，但是现在正好开到第四个国家，所以就有点微妙…… |
|
@BTMuli 其实就我个人而言，我不关心 resource 目录是否混乱，因为按照设想根本不用操作这个目录，操作的都是 resource_custom ，我比较关心在仓库体积上，一个修改是否能在未来产生收益 |
|
就体积而言，目前的已经快半个G了，加上npm超过一个G是必然的🤣 |
角色资源不统一的问题确实有影响，#840 ，但是现在这个时间点改的话有点晚了，从我个人角度来说当然希望能够统一成角色 ID 的形式 webp 只有卡池使用的另一个原因是因为需要我们本地转换格式，所以只在收益比较大的卡池图像上面用了 |
|
git 如果只进行资源移动（不删除）的话对于体积的影响大吗，如果不大的话我觉得可以把现在所有的非 webp 文件全部扔到一个垃圾桶文件夹里面去，用新生成的 webp 替代原来图片的位置 |
如果准备全部转到 webp 那么 png 直接删除，但是我觉得这个需要 https://github.com/Mark9804/adachi-resource-assistant 能够处理所有的 webp 才行 get what from where for every char/weapon 如果有一个列表的话，我愿意更新助手，然后实现所有图片的 webp 化，助手改为单一的、读取描述文件的可执行程序入口 |
|
对于下面的信息，我们能做到什么程度的自动化呢，如果程度较高，我愿意全部翻新资源文件，永久性解放以后的版本更新劳动 角色{
"access": "祈愿",
"ascensionMaterials": ["最胜紫晶碎屑", "最胜紫晶断片", "最胜紫晶块", "最胜紫晶", "雷光棱镜"],
"baseATK": 323,
"birthday": "11月20日",
"constellationName": "金紫定垂座",
"constellations": [
"雷楔存在期间再次施放元素战技时，在刻晴消失与出现的位置造成50%攻击力的雷元素范围伤害。",
"刻晴普通攻击与重击命中受到雷元素影响的敌人时，有50%几率产生一个元素微粒。该效果每5秒只能触发一次。",
"元素爆发的技能等级提高3级。至多提升至15级。",
"刻晴触发雷元素相关反应后的10秒内，攻击力提升25%。",
"元素战技的技能等级提高3级。至多提升至15级。",
"进行普通攻击、重击、施放元素战技或元素爆发时，刻晴获得6%雷元素伤害加成，持续8秒。由普通攻击、重击、元素战技或元素爆发引起的效果分别独立存在。"
],
"cv": "谢莹 | 喜多村英梨",
"cvCN": "谢莹",
"cvJP": "喜多村英梨",
"element": "雷元素",
"id": 10000042,
"introduce": "璃月七星之一，玉衡星。对「帝君一言而决的璃月」颇有微词——但实际上，神挺欣赏她这样的人。",
"levelUpMaterials": ["石珀", "骗骗花蜜", "微光花蜜", "原素花蜜"],
"mainStat": "暴击伤害",
"mainValue": "38.4%",
"name": "刻晴",
"passiveDesc": "在璃月执行探索派遣任务时，消耗的时间缩短25%。",
"passiveTitle": "总务土地",
"rarity": 5,
"talentMaterials": ["「繁荣」的教导", "「繁荣」的指引", "「繁荣」的哲学", "北风之环"],
"time": "【周一/四/日】",
"title": "霆霓快雨",
"type": "角色"
}
武器{
"access": "祈愿",
"ascensionMaterials": [
["凛风奔狼的始龀", "凛风奔狼的裂齿", "凛风奔狼的断牙", "凛风奔狼的怀乡"],
["地脉的旧枝", "地脉的枯叶", "地脉的新芽", "史莱姆凝液", "史莱姆清", "史莱姆原浆"]
],
"baseATK": 608,
"introduce": "象征风龙的荣誉的骑士剑，如今失而复得。剑脊上吹息着风之神的赐福，蕴含苍空与长风的力量。",
"mainStat": "元素充能效率",
"mainValue": "55.1%",
"name": "天空之刃",
"rarity": 5,
"skillContent": "暴击率提升<span class=\"desc-number recolor\">4%/5%/6%/7%/8%</span>；施放元素爆发时，获得破空之势：移动速度提升<span class=\"desc-number\">10%</span>，攻击速度提升<span class=\"desc-number\">10%</span>，普通攻击与重击命中时，额外造成<span class=\"desc-number recolor\">20%/25%/30%/35%/40%</span>攻击力的伤害，持续<span class=\"desc-number\">12</span>秒。",
"skillName": "穿刺高天的利齿",
"time": "【周二/五/日】",
"title": "单手剑",
"type": "武器"
}
|
这样我们也能最大限度的写好文档，因为不需要做的事情永远不会写错或者写粗略 |
|
我目前的想法是人工翻新规整化旧资源，而非通过脚本来生成图片，后面的资源更新，json文件采用助手爬取，图片资源还是人工处理，像目前3.0大版本的资源更新，处理起来也没花上多少时间 |
画饼开始咯 角色
武器
|
既然准备全部翻新，就意味着标准（像素长宽）都可以重新定义，我不太能把握在一切重新定义的情况下有多少能够自动化呢 |
我在画设计图的时候都有考虑标准化问题，现在除了立绘之外已经不用开 photoshop 了，所以下一个设计我就打算把立绘给废弃掉 在这之后就可以直接进入工业时代了，全部自动化 |
|
@mark9804 有意向的话画一个摸得着的饼：根据描述文件和助手中的数据，如何去生成一个获取图片的 url，转换后的图片生成到哪里，然后我就开始工业革命 |
|
并非重新定义，只是把一些不符合的图片更换，比如 |
这个其实我们并不在意，分辨率只是为了防止大家拿错了图，事实上比例不对用起来也没有问题，网页都处理了 |
对于分辨率的要求其实没有那么严格，我现在只对比例做出要求（是不是 1:1 的关系）
可以的，除了让脚本自己判断要不要保留透明度信息我不确定之外（保留其实也就多一点大小不那么极限），其他的都可以细化，我这两天开一个 discussion |
|
不过硬要说的话，有一段时间我们圣遗物拿的是内鬼网的图片，内鬼网是有裁切的（也就是资源助手最初写出来干的事情，就是个反裁切的），观感确实不太好，不过现在有了更标准的 ambr ，强迫症如我也可以睡安稳觉了 |
直接在这里回复吧
我考虑了一下，为了使用体验，还是用 js 重写吧，不用额外的助手了，这样统一使用 npm 入口也会避免很多问题 npm run tool-resource -- -c ./resources/Version2/info/docs/*.json用起来差不多是这个感觉 |
|
主要还是个人有点强迫症(T_T)又恰好这段时间有空想起来这个，ambr拿到的图片也可以通过TinyPNG进一步的压缩 |
这个确实可以考虑考虑，API 每个月前五百张免费 |
|
如果我们的自动化做的足够彻底，那么也可以抛弃 update.sh ，彻底和原项目分开了，资源目录也不需要维持两个了，另外也不需要大篇幅的资源制作文档了 |
更进一步的说，也没有必要和原项目维持同样的目录结构了，我个人更倾向简明一些的目录结构 诸如此类 一切都看自动化能实现到何种程度 |
|
资源文件的更新...目前已经可以做到自己更新了吧(•_•) |
目前我们的上游是原项目，这个 issue 提到的自动化是想把上游换成一个原神信息网站 |
不能，还不够自动化，我们两个人可是巴不得这个项目能自己给自己添加新功能自己修 bug 的 |
|
上游数据源的替换跟项目资源人工更新是分开的吧...?单就这个 issue 的资源翻新而言，上游是没有用到的吧 |
没有，上游摆烂了，之前很多版本我们是张着嘴等上游喂一部分资源文件的，这也是你看到为什么会有很多资源文件尺寸不一 |
|
之前版本等上游作为数据源然后跑 |
可以，但是没有必要，因为不能带来足够利益的翻新没有太大的价值，只是为了强迫症没有必要翻新旧文件，这种工作既不会带来用户体验的改变，也不会带来开发过程的改变 |
|
我人麻了(⌐■_■) |
|
Duplicate of #885 |
|
没有必要为了翻新而翻新，我们不是按 commit 数给工资的，翻新的目的是为了之后开发更快乐
这个项目有爬虫的原因是因为我当时只手动改了一个 json 文件就破防了，花不花时间（时间值不值钱）另说，重复操作就挺坐牢的 我自己电脑上自动化脚本和 automator workflow 加起来有几十条，一分钟牢都不想坐 |
|
|
太牛了 |
|
这个已经给整理完了 #885 |
问题描述
下午在传图的时候，以及之前几次pr的时候就注意到了。
项目的图片素材还是挺乱的，文档 里的一些关于图片分辨率跟大小的说明跟实际项目有所差别。
resource_custom目录下的资源跟resource目录下的资源重叠也造成项目文件冗余，有些弃用的图片资源也堆在那边T_T就想着能不能整理一下，顺带翻新一下 文档
当前提交
The text was updated successfully, but these errors were encountered: