社区专页是为用户讨论编辑相关话题设立的。用户也可以在对应页面、用户的讨论页讨论。在发言后请记得添加~~~~签名。
请了解,Minecraft Wiki在共识系统上运作而不是投票决定,清楚地阐述自己的理由比简单地支持争论的一方更有效。
Minecraft Wiki不是客户服务中心!游戏问题请移步Minecraft帮助中心或者玩家游戏社区。
所有在该页面上发表的无关话题都将被存档至无意义话题处。
语言
- 快捷方式
- MCW:CP
- MCW:PORTAL
- MCW:社区
- 最新Wiki新闻
- 2023年8月31日 - 中文Minecraft Wiki确定将迁移至Weird Gloop(议题原文)。
- 2023年7月4日 - 英文Minecraft Wiki公开发布了关于Minecraft Wiki是否要从Fandom迁移至别的站点的讨论(链接)。
- 2023年6月1日 - 新的巡查员Siiftun1857上任。
- 2023年5月4日 - 中文Minecraft Wiki使用的MediaWiki版本已升级至1.39。
- 2023年1月31日 - 新的管理员Anterdc99上任。
| # | 话题 | 发言条数 | 参与人数 | 发起者 | 最后发言者 | 最后发言时间(UTC) |
|---|---|---|---|---|---|---|
| 1 | 关于首页大段空白的问题 | 29 | 9 | North kun | Yzy32767 | 2022年8月4日 (四) 09:58 |
| 2 | 使用模板的大小写与缩写要求、以及部分模板及其参数的使用规范问题 | 20 | 6 | AblazeVase69188 | McplayerFS | 2022年7月16日 (六) 09:08 |
| 3 | user warning模板拆分事宜 | 5 | 3 | MysticNebula70 | MysticNebula70 | 2022年7月29日 (五) 05:21 |
| 4 | 音乐 | 5 | 3 | Cyron Choi | Anterdc99 | 2022年8月3日 (三) 05:09 |
| 5 | 新手手册编写问题 | ? | ? | ? | ? | 未知日期 |
关于首页大段空白的问题
本人的多个设备以及部分尝试了查看首页的群友在打开首页的时候均会在“Minecraft简介”和“本周页面”底部显示大量空白。这是否是一个需要处理的问题? North kun(留言) 2022年6月18日 (六) 04:12 (UTC)
- 支持:中文表达所需空间比英文要少,套用以前英文版的排版必然会存在空白。不过其实现代汉语的版本还算好,文言版的首页空白那才是惨不忍睹。--Yzy32767【论/功】 2022年6月18日 (六) 04:30 (UTC)
- 之前也不是没讨论过,当时提出来的时候没人理。至于已经停止支持的游戏,我个人的意见是写上去并标注好。至于MCD和Legends,MCD由于在MCD Wiki首页中已经写了,但是在这里不写又不是很合适,所以我建议可以略写一下;Legends也是相同的道理。--KaplanSteve T/C 2022年6月18日 (六) 07:10 (UTC)
- 似乎是为了和旁边的“开始游戏!”对齐。--McplayerFS(讨论 | 贡献) 2022年6月18日 (六) 14:12 (UTC)
- 英文版本的版本信息是放在下面的,这样就无需考虑其高度问题。但同样的,就得考虑其他部分的内容宽度和高度问题。--
Lakejason0(论•功) 2022年6月19日 (日) 13:13 (UTC) - 我不认为这是需要处理的问题。目前没有插入新栏目的打算。--Lxazl5770zh.admin(论 ▪ 功) 2022年6月20日 (一) 02:33 (UTC)
- 并不是“插入”的问题,而是重新整理,重新排版的问题。--
Lakejason0(论•功) 2022年6月20日 (一) 03:01 (UTC)
- 并不是“插入”的问题,而是重新整理,重新排版的问题。--
- 重新排版确实有必要,不过目前暂时没有比较好的设计。有的话可以提出来。MysticNebula70 T 2022年6月20日 (一) 05:30 (UTC)
- 仿效en的排版其实也不错,把你知道吗换成每周页面如何呢?--
Lakejason0(论•功) 2022年6月21日 (二) 04:04 (UTC) - 意见:en的“你知道吗”板块也有留白,然而如果把每周页面替换进去的话,有可能会空间不足。我建议是要么限制一下每周页面的字数,要么把“关于Minecraft”扩写一点。--KaplanSteve T/C 2022年6月21日 (二) 14:38 (UTC)(最后编辑于2022年6月21日 (二) 14:39 (UTC))
- en主页上的版本信息一栏内容所占空间显然比zh的多,如果仿照其把版本信息一栏的宽度扩展到整个页面的做法,其高度将明显减少。虽然我没有具体试过,但观感肯定不好。--AblazeVase69188(讨论 | 贡献) 2022年6月24日 (五) 12:57 (UTC)
- 仿效en的排版其实也不错,把你知道吗换成每周页面如何呢?--
- 留言:浏览首页及相关页面(Minecraft Wiki/style)可知,首页的栏目布局的代码见于MediaWiki:Gadget-mainpage.css,其中与首页栏目布局相关的内容如下:
| 目前的布局 | ultim_0建议的布局之一 | |||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
| |||||||||||||||||||||||||||||
/** Responsive main page layout **/
#main-page.main-page {
display: -ms-grid;
-ms-grid-template-areas: "a" "b" "c" "d" "e" "f" "g" "h" "i" "j";
-ms-grid-template-columns: 1fr;
display: grid;
grid-template-areas: "a" "b" "c" "d" "e" "f" "g" "h" "i" "j";
grid-template-columns: 1fr;
}
@media screen and (min-width:990px) {
#main-page.main-page {
-ms-grid-template-areas: "a a a" "b b c" "d d c" "e f g" "h i j";
-ms-grid-template-columns: 1fr 1fr 1fr;
grid-template-areas: "a a a" "b b c" "d d c" "e f g" "h i j";
grid-template-columns: 1fr 1fr 1fr;
}
}
/* ... */
#fp-1 {
-ms-grid-area: a;
grid-area: a;
}
#fp-2 {
-ms-grid-area: b;
grid-area: b;
}
/* #fp-3到#fp-9同理 */
#fp-10 {
-ms-grid-area: j;
grid-area: j;
}
- 其含义是:当页面宽度较宽(大于等于990px)时,将各栏目按右表1所示的方式进行排版。“Minecraft简介”(
#fp-2)和“每周页面”(#fp-4)对应的就是b和d的位置。 - 综上所述,通过修改MediaWiki:Gadget-mainpage.css的相关内容(已在上文标出),即可在不改变首页源代码的情况下更改页面排版形式。
- 关于重新排版:经本地测试,将布局改为右表2所示可明显避免出现过多空白。
- 但是根据群友(既然北鲲使用了这个称呼,那么用在这里应该也没问题)反映,这会导致“每周页面”在部分宽屏设备上出现排版异常的情形(在下的屏幕只有1366px宽,难以预览大屏幕下的情形),建议一并修改Minecraft Wiki/weekly/style。--ultim_0 ( USER | TALK | WORK ) 2022年6月21日 (二) 16:08 (UTC) (最后编辑于2022年6月25日 (六) 18:39 (UTC))
- 我根据Ultim的提案制作的最终提案如下。
对于首页的CSS:
/** Responsive main page layout **/
#main-page.main-page {
display: -ms-grid;
-ms-grid-template-areas: "a" "b" "c" "d" "e" "f" "g" "h" "i" "j";
-ms-grid-template-columns: 1fr;
display: grid;
grid-template-areas: "a" "b" "c" "d" "e" "f" "g" "h" "i" "j";
grid-template-columns: 1fr;
}
@media screen and (min-width:990px) {
#main-page.main-page {
-ms-grid-template-areas: "a a a" "b b b" "c c d" "e f g" "h i j";
-ms-grid-template-columns: 1fr 1fr 1fr;
grid-template-areas: "a a a" "b b b" "c c d" "e f g" "h i j";
grid-template-columns: 1fr 1fr 1fr;
}
}
对于每周页面的图片:
<onlyinclude>[[File:{{{img|}}}||{{{img-size|}}}|border|center|class=banner-image nomobile]]<div style="line-height:2em;display:table;min-width:25%;">{{{content|}}}
<p class="nomobile">
{{{img-desc|}}}</p></div></onlyinclude>
- 还有一些其他的方案。--
Lakejason0(论•功) 2022年6月22日 (三) 06:07 (UTC)(最后编辑于2022年6月22日 (三) 06:42 (UTC)) - 由于测试过程中发现了一些新问题,在此说明一下问题以及一些新的提案。
- 问题1:首页的每周页面图片有浮动,会把文字挤到一边。这个在上方提案中修改为了居中来解决问题。
- 问题2:版本信息一栏方格下方的列表观感不好,词汇会断开,而且横向列表在列表项目不多时展示效果较差。
- 基于以上发现的两个问题,我又查看了其他语言站点的首页,相关情况如下:
- 英文:版本信息单独出一整个横栏,所有的购买链接和版本号放在一起。
- 西班牙语:重新设计了首页,将版本信息删除。
- 由于版本信息写全似乎冗余,在即时通信软件中部分用户对EN的目前方案给出的意见是负面的。西班牙语目前没有人评论。大概是这样。--
Lakejason0(论•功) 2022年6月22日 (三) 06:48 (UTC)
| 韩国语wiki首页的布局 | ultim_0建议的布局之二 | ||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
| ||||||||||||||||||||||||||||||
- 注意到韩国语wiki相对于en也对首页排版进行了小幅度修改,如右表1所示,其中的“关于外来词”是其独有的栏目,对应zh的“每周页面”,除此之外的各个字母表示的内容与zh相同。根据其样式给出了方案二,如右表2所示,该方案可以避免方案一中“每周页面”栏目因为宽度过小而出现排版异常的情况,因此无需同时修改该栏目的样式。谨供参考。--ultim_0 ( USER | TALK | WORK ) 2022年6月22日 (三) 07:14 (UTC) (最后编辑于2022年6月25日 (六) 18:39 (UTC))
- 我在Editcopy中修改了一部分代码,将购买链接和试玩链接直接添加到了版本信息方格中。这样就可以解决问题2(通过直接删除、转移到版本方格内的方式解决)。由于这样的更改会导致先前的版本号合并不再可行(链接显示会不完整),我暂时先放在那边。--
Lakejason0(论•功) 2022年6月22日 (三) 08:01 (UTC)
- 在处理横向列表的时候发现了EN的一个做法,就是把购买链接写在对应的页面,而不是直接写到首页。这样也更便于维护。--
Lakejason0(论•功) 2022年6月30日 (四) 07:24 (UTC)
- 在处理横向列表的时候发现了EN的一个做法,就是把购买链接写在对应的页面,而不是直接写到首页。这样也更便于维护。--
没有人讨论吗?那我再把方案二需要修改的地方指出来:
/** Responsive main page layout **/
#main-page.main-page {
display: -ms-grid;
-ms-grid-template-areas: "a" "b" "c" "d" "e" "f" "g" "h" "i" "j";
-ms-grid-template-columns: 1fr;
display: grid;
grid-template-areas: "a" "b" "c" "d" "e" "f" "g" "h" "i" "j";
grid-template-columns: 1fr;
}
@media screen and (min-width:990px) {
#main-page.main-page {
-ms-grid-template-areas: "a a a" "b c c" "d d d" "e f g" "h i j";
-ms-grid-template-columns: 1fr 1fr 1fr;
grid-template-areas: "a a a" "b c c" "d d d" "e f g" "h i j";
grid-template-columns: 1fr 1fr 1fr;
}
}
至于版本信息(“开始游戏!”)的处理,个人并无较好的提案,建议将购买和试玩的链接移动到对应页面的{{infobox}}中。
以上。--ultim_0 ( USER | TALK | WORK ) 2022年7月6日 (三) 10:33 (UTC) (最后编辑于2022年7月6日 (三) 12:03 (UTC))
- 然而这个方案里的“Minecraft简介”留的空间太少,个人建议与旁边的“开始游戏”同宽。--Yzy32767【论/功】 2022年7月6日 (三) 10:57 (UTC)
- 其实可以把Minecraft简介改成en的Minecraft video game样式,这样无需改动布局即可填充空白,我会在稍后将代码放至editcopy下。旁边的图片尚未上传,我会先注释掉。--Yzy32767【论/功】 2022年7月15日 (五) 07:28 (UTC)
- 同意Yzy32767的做法,少去了更新布局的麻烦,并且这样也可以避免较多的留白。只是这样的话需要保证每周页面的内容不多不少(本周的烈焰人就是个例子)才能避免留白过多或超出范围。--KaplanSteve T/C 2022年7月15日 (五) 07:38 (UTC)
- 将代码写入editcopy后遇到了以下问题:
- 或许可以借鉴一下德语和西班牙语的首页。有用户提出“重要的东西除了版本号以外都缩在一个角落里,换做谁也不想找。”“版本信息图标过大,和下面的小字相比就是失衡的。”而德语和西班牙语的首页完美解决了这个问题,将重要的页面如交易、酿造,包括MCD的内容都放在了首页,版本信息也使用了小图标。只是如果我们也这么做,可能会涉及到MCD的首页的改动问题(比如把内容合并到主首页或重新布局)。并且这么做的话等于现在为止做的全部都是白费。
- 总之,保留现在的设计也可以,但是要解决Yzy32767提出的问题;也可以推倒重来,做成像德语一样的的首页,只是不需要那么多东西,可以删减一些。如果采用德语的设计,个人建议把版本信息收窄,放到右边(德语的留白太多),然后把“你知道吗”板块改为“本周页面”,并放到5个游戏介绍(或者像西班牙语一样拆开来变成7个)下面。
- 以上是我的提议。--KaplanSteve T/C 2022年7月16日 (六) 05:29 (UTC)
- 问题1已通过
flex-shrink: 0;样式解决。为了让图标在移动端不占据过多空间,对其进行了一定程度的缩小。此举也使得整个“Minecraft游戏”的高度降低,问题2稍有改善。然而考虑到主页的版本区(“开始游戏!”)没有试玩和下载链接,留白较editcopy会更严重,故建议重新设计“开始游戏!”板块。--Yzy32767【论/功】 2022年7月16日 (六) 23:01 (UTC)
使用模板的大小写与缩写要求、以及部分模板及其参数的使用规范问题
我于数月前查看版本634496时,发现该编辑将{{only}}、{{in}}等模板中的英文字母全部改为了小写,并将使用了{{editions}}模板参数的文字进行了缩写(如把java改为了je,bedrock改为了be)。此后,我也养成了在编辑页面时顺手对这些模板进行类似改动的习惯。不过到今天为止,我也不太清楚这么做究竟有什么意义,可能是为了统一格式。
首先,以{{in}}模板的使用为例:区分大小写,我见到过三种用法:{{in}}、{{In}}还有{{IN}},是否应该把它们全部统一为小写?例如,{{IN|BE}}统一为{{in|be}}。我的建议是将其全部统一为小写,模板中的文本不作大小写统一。
值得注意的是,在普通的页面编辑中,提供的模板自动补全功能(例如,可以在编辑页面时的编辑区内输入{{ab,等待数秒就会出现一个以该字符串为开头的模板列表(包含重定向),点击任意一个即可将其自动补全为完整的模板名称)会自动将模板的首字母大写;可视化编辑也有可能在使用模板时将模板首字母大写或全部大写。
其次,部分模板具有其缩写形式,如{{editions}}对应的{{el}}。那么,在使用模板时,应该使用其全拼写形式还是缩写形式?我的建议是全部统一为缩写,以减少编者的负担。同时也需要注意,上文提及的模板自动补全与可视化编辑都会输出完整的模板名称。
第三,上述为例的{{in}}和{{only}}模板均引用了{{editions}}参数,以这些参数中最常用的java和bedrock为例,它们对应的缩写分别为je和be。同上,在使用这些参数时,应该使用其全拼写形式还是缩写形式?我的建议也是全部统一为缩写。与此同时,可视化编辑也可能把这些参数强制转换成完整拼写,可参见版本661837对第244行文本的更改。
第四,{{only}}模板接受short参数,该参数启用时会将对应版本名称缩写,如将[仅基岩版]转换为[仅BE]。那么,此参数存在的意义是什么,应该在什么地方使用?我在这方面暂时没有什么想法,不过在en对于此模板的讨论上,有人提到这个参数(由于我个人所限,我只从里面提取到一句“把版本名称缩短是一个好主意”),其他有能力的用户可以去看看,能不能从那里得到什么有用的观点。
第五,{{Sprite}}相关模板包括{{BlockSprite}}等,其作用是在页面中添加一个特定的“精灵图”。那么,对于在这些精灵图前后的文本,是否应该以一个空格将图片和文本隔开?以{{BlockLink}}为例,使用dirt参数会输出泥土的精灵图、一个空格和泥土的链接,这就向我们展示了一般情况下,这类模板的使用需要在图片后加上一个空格与文本隔开。与之对应,图片的前面如果有文本,是否也应加上一个空格与之隔开?我的建议是,这类精灵图的前后如果有文本,就要加上一个空格与之隔开,如果其前后为标点符号则不需要。
我发起上述议题的原因,主要是看到Wiki上仍然有很多地方的模板使用情况不统一,而又不知道是否应该统一;并且有时候我也对寻找并更改页面中的大小写、缩写和{{editions}}参数感到厌烦,这些工作明明可以交给机器人来完成。但是,正如上文部分地方所提到的,官方提供的模板自动补全功能和可视化编辑的部分输出结果又与我上面所提出的部分建议矛盾,是否应该采用还有待讨论。
以上。--AblazeVase69188(讨论 | 贡献) 2022年7月2日 (六) 09:28 (UTC)
- 首字母大小写个人认为没必要统一吧。不过真的要统一,还是小写好一点,毕竟这样编辑也方便。Sprite前面加个空格会美观一些,但是MCD的装备一类的sprite由于尺寸较大,甚至出现了空格过大的情况,这一点还是需要其他人考虑。至于其他问题我再考虑。—KaplanSteve T/C 2022年7月2日 (六) 09:47 (UTC)
{{IN}}等模板有大小写的原因是英文中有大小写区分的必要,中文则没有。出于方便(搬运进来或者搬运出去)考虑,此类区分大小写的情况下,建议是“翻译成英文的时候需要大写的”大写,反之小写。--
Lakejason0(论•功) 2022年7月2日 (六) 09:48 (UTC)(最后编辑于2022年7月2日 (六) 09:51 (UTC))
- 那么在en那边区分这类大小写,有没有具体规则或格式指导?最好能把这些规则列入到本议案最终的解决方案中。--AblazeVase69188(讨论 | 贡献) 2022年7月3日 (日) 00:50 (UTC)
- 至于是否是要统一拼写,个人认为没必要,用得顺手就行,这不会带来太大的负担,反而是强行统一会失去模板别称的价值。至于Only模板,在Infobox里面我会觉得要缩写,还有一个用例是例如“某某某共有6
[仅JE]/9 [仅BE]个”,像这样的,其他地方写全也不会和英文一样长得太长,改不改都没什么必要。Sprite模板我记得本身也就不应该单独使用,我没有办法讨论这里的用例。强行前置空格会造成源代码观感差。--
Lakejason0(论•功) 2022年7月2日 (六) 09:55 (UTC)(最后编辑于2022年7月2日 (六) 10:06 (UTC))
- 我此处所说的“Sprite模板”是用来泛指包含BlockLink这一类模板的集合的。--AblazeVase69188(讨论 | 贡献) 2022年7月2日 (六) 10:51 (UTC)
- 留言:
- 原则上首字母大小写以及空格与下划线的相互替换并不会影响被调用的模板、页面或者用户(例如user:ultim_0等效于User:Ultim 0),个人建议不做任何更改。
- 而部分模板的参数同时接受大小写(甚至是混合输入),是因为这些模板在处理对应参数时使用了魔术字{{lc:}}来将输入的参数转化为全部小写(如{{lc:Be}}会显示为be),对于这些模板参数的大小写,个人建议也不做任何更改。
- 至于同义参数,个人建议依用户输入习惯而异,与对模板别名的态度一样,也不做任何更改。
- 至于
{{only}}使用参数|short=的情形,个人认为应当在表格等内容拥挤的地方使用,以避免占用过多页面空间影响观感。 - Sprite模板相关:个人认为在文段中,应当在Sprite后以及Sprite之间添加空格,无论是否为了单纯列举Sprite。
- 原则上首字母大小写以及空格与下划线的相互替换并不会影响被调用的模板、页面或者用户(例如user:ultim_0等效于User:Ultim 0),个人建议不做任何更改。
- 以上。--ultim_0 ( USER | TALK | WORK ) 2022年7月2日 (六) 09:59 (UTC) (最后编辑于2022年7月2日 (六) 10:18 (UTC))
- 所以目前大致的共识就是第一至四条没有采用的必要,而第五条仍需讨论。--AblazeVase69188(讨论 | 贡献) 2022年7月2日 (六) 10:53 (UTC)
- 前三条没啥不良影响,没必要改。short的缩写不够标准,不如全称好理解,建议能不用就不用。Sprite的空格应该是这类模板的标志,模板外不用。传入神经元(权限|讨论|贡献|日志) 2022年7月2日 (六) 12:43 (UTC)
- 的确部分读者可能对short参数输出的缩写不是很熟悉。不过在Minecraft Dungeons等较长的版本名称的使用上,显然MCD比Minecraft Dungeons更短,在这些情况下还是可以更多地考虑使用缩写。--AblazeVase69188(讨论 | 贡献) 2022年7月3日 (日) 00:50 (UTC)
- 支持以上1、2、3的观点,事实上我也是这么做的。5的话我不建议加空格。--McplayerFS(讨论 | 贡献) 2022年7月2日 (六) 12:53 (UTC)(最后编辑于2022年7月4日 (一) 04:27 (UTC))
- 请问您是否不慎在此处将“第四点”和“第五点”调换了?--AblazeVase69188(讨论 | 贡献) 2022年7月9日 (六) 13:56 (UTC)
- 目前貌似有部分编者不太理解我所说的第五点的内容,我在这里举个例子:
- “村庄可以在平原生物群系生成。”与:
- “村庄可以在 平原生物群系生成。”的区别。
- {{BlockLink}}等模板中在精灵图和链接文本之间添加了一个空格,因此对应地,如果精灵图前面有文本,那也应该在它们之间加上一个空格。的确,{{BlockSprite}}等只包含精灵图的模板不经常使用,但在使用时仍建议遵循{{BlockLink}}等模板添加空格的做法。不过由于部分情况下精灵图前面没有文本,不需要加上空格,而添加新的参数可能会增加模板使用的复杂程度,因此目前可能只能采取有必要时在精灵图前面加一个空格以将文本与之隔开的做法。--AblazeVase69188(讨论 | 贡献) 2022年7月2日 (六) 15:13 (UTC)
- 这么做的问题仍然是源代码层面的一个不太好看(因为没有其他场合会需要一个额外的空格)。--
Lakejason0(论•功) 2022年7月2日 (六) 15:23 (UTC)
- 这么做的问题仍然是源代码层面的一个不太好看(因为没有其他场合会需要一个额外的空格)。--
- 提醒:一般来说并不建议在正文的文本段落内使用各种sprite链接模板,因为实际上观感并不会比普通文本更好。MysticNebula70 T 2022年7月2日 (六) 16:07 (UTC)
- 既然这样,如果格式指导里面暂未提到相关内容,那是否可以在格式指导中加上一句“不建议在正文的文本段落内使用各种sprite链接模板”,并对Wiki现存的在文本段落内使用的Sprite链接模板进行替换,这样就可以避免此处第五点所提到的情况?--AblazeVase69188(讨论 | 贡献) 2022年7月3日 (日) 00:50 (UTC)
- 需要分情况讨论。如新手手册中有以下的叙述:
- 既然这样,如果格式指导里面暂未提到相关内容,那是否可以在格式指导中加上一句“不建议在正文的文本段落内使用各种sprite链接模板”,并对Wiki现存的在文本段落内使用的Sprite链接模板进行替换,这样就可以避免此处第五点所提到的情况?--AblazeVase69188(讨论 | 贡献) 2022年7月3日 (日) 00:50 (UTC)
- 提醒:一般来说并不建议在正文的文本段落内使用各种sprite链接模板,因为实际上观感并不会比普通文本更好。MysticNebula70 T 2022年7月2日 (六) 16:07 (UTC)
你可以获取的工具基于材料可以有不同的品质,这些工具包括镐、 斧、锹,分别用于挖掘石质、木质和沙土类方块。第四类工具是锄,其略有不同——一般会到后面使用,作为耕种的一部分,不过锄可以用于更快地破坏轻的方块(如树叶)。剑类似于工具,同样可以有不同的品质,但是用于攻击动物和怪物而非破坏方块。六种品质分别是木头、石头、铁、金、钻石、下界合金,但是第一天你通常只能得到木头和石头,或许还有铁。更高品质的工具可以更快破坏方块,且耐久度更高,更高品质的剑可以造成更高的伤害。尤其对于镐,很多方块只有至少特定品质的工具才能收集,否则不会掉落任何掉落物:木镐可以收集石头和煤矿石,但是铁矿石和青金石矿石至少需要使用石镐,更高级的矿物(如金和钻石,第一天也不太可能遇到)至少需要铁镐才能挖掘。金是特例,尽量避免依赖于使用金质的工具、剑或者盔甲,因为金质工具的效率虽然很高,但耐久度却很低。如果你在某些结构中的箱子(如废弃传送门)里发现了金质物品,可以保存起来,以后再使用。如果刚进入游戏就发现了的金,可以仅做临时防御,有好装备(铁质及以上)了之后立刻更换。
- 依上述讨论,现列出解决草案如下:
- 1. 第一点、第二点、第三点不采用,各编者可保留原有使用习惯,不必强制统一。
- 2. 第四点,对于全称过长的Minecraft Dungeons和Minecraft Dungeons Arcade,可以分别缩写为MCD和MCDA。其他的缩写尽量不使用;或只在表格等空间窄小的地方、较短的句子或词组中使用。
- 3. 第五点,可以在格式指导中加上一句“不建议在正文的文本段落内使用各种sprite链接模板”,以避免第五点所提到的问题出现。如果有特殊情况需要在文本段落内使用,在精灵图的前面不需要添加空格。
- 七日后将依新的讨论给出最终解决方案。(六日后我才能再次开始活跃。)--AblazeVase69188(讨论 | 贡献) 2022年7月3日 (日) 09:36 (UTC)
- 现根据最新讨论,给出最终解决方案如下:
- 1. 第一点至第四点的解决方案与草案相同,具体内容见上方。其中第四点的格式标准拟写入{{only}}模板的文档页面。
- 2. 第五点,在格式指导中加上一句“一般不在正文的文本段落内使用各种Sprite链接模板,教程页面除外。在Sprite的前面不需要添加空格”。
- 如有其他意见请在三日内提出。--AblazeVase69188(讨论 | 贡献) 2022年7月11日 (一) 01:51 (UTC)
- 已完成添加上述说明的工作,不过我还有一个建议在此提出:
- 原本我是因为看到了模板中精灵图和文字中间的空格,才采用在Sprite前面添加空格的做法的。既然为了源代码层面的美观而不在Sprite的前面添加空格,那么为了统一是否应该将各种Sprite链接模板中精灵图和文字中间的空格移除?--AblazeVase69188(讨论 | 贡献) 2022年7月16日 (六) 01:33 (UTC)
user warning模板拆分事宜
目前的user warning模板是整合了数个警告类模板而成的一个大模板。如此编辑模板并不利于后期维护,也使得单个模板的长度过长。因此在此考虑拆分模板,仿照中文维基百科的做法,按严重等级和具体警告事宜制作一系列模板。目前需要考虑的问题有:
- 是否照搬中文维基百科的5个严重等级;
- 讨论适合本wiki的具体警告事宜。
欢迎各位提出意见和建议。MysticNebula70 T 2022年7月18日 (一) 14:06 (UTC)
- 支持将uw下的警告信息拆分成多个模板。关于严重等级,我认为过于细分的等级在本wiki上并不实用,建议分成轻微情节警告和严重情节警告两级即可。关于具体警告内容,我认为实用性较大的有破坏、可视化编辑、机器翻译、页面格式、上传文件、乱改乱用译名。--葉月 桐§ 2022年7月20日 (三) 20:13 (UTC)
- 议题没人回复,主要是没法下手。等级的话不清楚该怎么办,也许可以分个三级(提醒、轻微警告、严重警告?)。至于具体的内容,现有都拆开似乎也没问题,毕竟这些内容的添加是因为wiki史上存在过对应的案例。--
Lakejason0(论•功) 2022年7月21日 (四) 10:55 (UTC) - 命名的话,继承EN应该没问题。--
Lakejason0(论•功) 2022年7月21日 (四) 10:56 (UTC)
- 考虑了一下,本wiki分成三档等级(提醒、警告、严重警告)应该足够使用了。关于警告事宜,参照Hatsuki kiri和现有的也暂时够用了。MysticNebula70 T 2022年7月29日 (五) 05:21 (UTC)
音乐
现在,音乐的分类上很有问题,我根据游戏内建重新分类了所有音乐,如此:Special:Diff/672700。希望各位参与讨论,谢谢。Choi Chin Long 2022年8月1日 (一) 08:28 (UTC)
- 感觉部分分类过于分散,例如“绯红森林音乐”“下界荒地音乐”等应该归于“下界音乐”。我 建议将“创造模式音乐”和“菜单屏幕音乐”分类出来,新分类包括“主世界音乐”“下界音乐”“末地音乐”“水下音乐”“创造模式音乐”和“菜单屏幕音乐”。将水下音乐和创造模式音乐分类出来的原因是若条件满足,这些音乐在多个维度中都能播放。--AblazeVase69188(讨论 | 贡献) 2022年8月1日 (一) 09:32 (UTC)
- 资源包上的音乐资料夹是这样的:[1] Choi Chin Long 2022年8月1日 (一) 10:30 (UTC)
- 在
C:\Program Files\WindowsApps\Microsoft.MinecraftUWP_1.19.1101.0_x64__8wekyb3d8bbwe\data\resource_packs\vanilla_music\sounds\music目录下找到的基岩版1.19.11的音乐文件目录如下:
- 在
- 资源包上的音乐资料夹是这样的:[1] Choi Chin Long 2022年8月1日 (一) 10:30 (UTC)
列表 - music
- game(除了文件夹中的音乐,其他均为在主世界中非创造模式下随机播放的音乐)
- creative(仅在创造模式下播放的音乐)
- creative1.ogg
- creative2.ogg
- creative3.ogg
- creative4.ogg
- creative5.ogg
- creative6.ogg
- end(仅在末地或观看终末之诗时播放的音乐)
- boss.ogg
- credits.ogg
- end.ogg
- nether(仅在下界中播放的音乐)
- chrysopoeia.ogg
- nether1.ogg
- nether2.ogg
- nether3.ogg
- nether4.ogg
- rubedo.ogg
- so_below.ogg
- records(音乐唱片)
- 5.ogg
- 11.ogg
- 13.ogg
- blocks.ogg
- cat.ogg
- chirp.ogg
- far.ogg
- mall.ogg
- mellohi.ogg
- otherside.ogg
- pigstep_master.ogg
- stal.ogg
- strad.ogg
- wait.ogg
- ward.ogg
- water(仅在水下播放的音乐)
- axolotl.ogg
- dragon_fish.ogg
- shuniji.ogg
- aerie.ogg
- an_ordinary_day.ogg
- ancestry.ogg
- calm1.ogg
- calm2.ogg
- ...
- piano1.ogg
- piano2.ogg
- piano3.ogg
- stand_tall.ogg
- wending.ogg
- creative(仅在创造模式下播放的音乐)
- menu(仅在菜单屏幕中播放的音乐)
- menu1.ogg
- menu2.ogg
- menu3.ogg
- menu4.ogg
- game(除了文件夹中的音乐,其他均为在主世界中非创造模式下随机播放的音乐)
- music
- --AblazeVase69188(讨论 | 贡献) 2022年8月1日 (一) 11:31 (UTC)
- 基于Java版1.19.1,我制作了一份详细的音乐列表,由于内容过长不便在此展示,可前往User:Anterdc99/Archives/Java版1.19.1音乐树查看。
- 根据上面AblazeVase69188的说法,并根据实际情况,可得出Special:Diff/672700中的分类法有以下问题:
- 机械地以目录为分类依据,不考虑各音乐间的关系。
- 部分分类内容过少,更适合将其按一定规则与其他内容合并。
- 实际来说,就是“沼泽音乐”以及仅播放于下界特定生物群系的音乐是否有必要拆分的问题。
- 对于“沼泽音乐”,其并不需要单独列出。根据其对应的声音事件ID,除了包含
music.menu(播放于菜单屏幕)外,其余ID与其他主世界音乐对应的ID并无用法上的区别。即便是music.menu,根据前例(参见22w16a之更改),在1.20开发过程中也有可能移除。沼泽音乐之所以在目录中单独列出,可能即是根据此(在菜单屏幕外仅在沼泽播放的音乐)而作。因此,这几个音乐只需在第二栏标注播放位置即可,不需要单独列出。 - 对于下界各音乐,其也不需要单独列出。一般的下界音乐
nether1.ogg、nether2.ogg、nether3.ogg和nether4.ogg也可以在绯红森林、下界荒地和灵魂沙峡谷中播放,因此也可以仅在第二栏标注播放位置以示区分,不需要单独列出。
- 对于“沼泽音乐”,其并不需要单独列出。根据其对应的声音事件ID,除了包含
- 基于以上论断,故 支持AblazeVase69188所提出的分类法。
- 当然,如果要将
credits.ogg也列入末地音乐中,则对应段落中的描述需要做相应修改,否则会与实际不符。--
Anterdc99(论·功) 2022年8月3日 (三) 05:09 (UTC)
新手手册编写问题
新手手册内的内容有些都是重复的,但有些写的详细,有些写的不精确,一眼就能看出是多个人写的,极不统一。新手手册是最重要的页面,就打算这样编写?