社区专页是为用户讨论编辑相关话题设立的。用户也可以在对应页面、用户的讨论页讨论。在发言后请记得添加~~~~签名。
请了解,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 | 关于地物和结构模板使用的问题 | 5 | 4 | KaplanSteve | AblazeVase69188 | 2022年12月6日 (二) 14:20 |
| 2 | 进一步拆分Java版已移除特性 | 6 | 5 | TripleCamera | TripleCamera | 2023年1月18日 (三) 10:59 |
| 3 | 中国版页面收录内容及改写 | 20 | 7 | Minecraforever | Lakejason0 | 2023年1月29日 (日) 18:37 |
| 4 | 统一模板文档页面的格式 | 9 | 5 | XDMC1 | XDMC1 | 2023年1月10日 (二) 15:42 |
| 5 | 补充在Linux系统下的描述 | 11 | 4 | IAmREGE | IAmREGE | 2023年1月12日 (四) 08:50 |
| 6 | 关于“伤害免疫” | 9 | 6 | 2190303755 | siiftun1857 | 2023年1月17日 (二) 17:23 |
| 7 | 关于版本更新后的steve皮肤问题 | 1 | 1 | Zhangzixuan2010 | Zhangzixuan2010 | 2023年1月19日 (四) 01:45 |
| 8 | 关于香港繁体的注音问题 | 2 | 2 | HlDoroWolf | Lakejason0 | 2023年1月22日 (日) 11:52 |
| 9 | 关于改造Inventory slot及Minetip的事宜 | 1 | 1 | Lakejason0 | Lakejason0 | 2023年1月29日 (日) 18:31 |
| 10 | 关于模板页面的建设 | 1 | 1 | Wingsofsky2022 | Wingsofsky2022 | 2023年1月30日 (一) 07:53 |
关于地物和结构模板使用的问题
目前,{{Generated structures}}、{{Environment}}、{{Structures}}三个模板内容存在较大重复,意思混乱,内容杂糅。
因此,个人认为应将三个模板进行拆分,分为“地形特征”、“结构”两个模板,完成后将{{Environment}}模板进行精简(主要是考虑到某些内容不会包括在前两个模板里)。包括生成结构页面也可以移动至“结构”。
我的提议可能有点简单,不过我大概提出了一个思路。以上。--KaplanSteve T/C 2022年9月17日 (六) 08:17 (UTC)
- 建议先考虑同步en的en:Template:Generated structures、en:Template:Environment再考虑是否进行拆分。以及意思混乱、内容杂糅的其实不只是模板,模板里的页面的内容和分类也都存在混乱的问题。--Chixvv(留言) 2022年9月17日 (六) 08:39 (UTC)
- 我认为可以将
Generated structures合并至Structures,并将Environment中结构页面的链接(如独石柱、下界反应器)移动至Structures中。--AblazeVase69188(讨论 | 贡献) 2022年9月17日 (六) 12:10 (UTC)- 我已在个人沙盒中将
Environment中结构页面的链接(如独石柱、下界反应器)移动至Structures(已同步至模板页面),并移除了Generated structures中不存在的页面链接。其中Generated structures以生成器种类为分类方式,Structures以生成结构和地形特征为分类方式,二者内容几乎完全一样,我认为前者的分类方式更好,故计划将Structures合并至Generated structures。不过这样貌似不如将这两个模板分为“地形特征”、“结构”两个模板的做法好,如果要采取这种做法,则需要将“结构生成”和“装饰器生成”的部分内容放入“结构”,其他的放入“地形特征”。具体怎么做还有待各位讨论。顺带一提,en似乎对Generated structures的分类做了调整,个人沙盒中的模板暂时不打算进行同步。--AblazeVase69188(讨论 | 贡献) 2022年12月6日 (二) 14:20 (UTC)
- 我已在个人沙盒中将
进一步拆分Java版已移除特性
众所周知,Java版已移除特性一直以来都属于长页面。2022年9月,有人在社区专页发布话题,希望拆分此页面,最终将此页面的前三个段落分别拆分至独立页面Java版已移除方块、Java版已移除物品和Java版已移除配方中。而最近又有人指出此页面过长,提议拆分此页面,现在希望讨论一下是否进一步拆分这个页面,以及具体的拆分方式:
是否需要拆分?Java版已移除特性当前长度为72000多字节,当前的长度是否会带来很多不便?
| 一般特性 | 已使用 | 未使用 |
|---|---|---|
| 已移除 | 已移除特性 | 已移除未使用特性 |
| 未移除 | 一般特性 | 未使用特性 |
如何拆分?目前出现了两种拆分方法:
- 有人提议把整个“未使用”段落移动至Java版已移除特性/未使用页面。这是因为站在现在的角度看,未使用特性仍然在游戏中,可以被玩家利用。
- 有人提议把“未使用”段落中的方块、物品和配方按类别拆分至Java版已移除方块、Java版已移除物品、Java版已移除配方等。
若有更好的分法,欢迎提出。
(本议题最初在管理群中提出,感谢最初参与讨论的人:Yzy32767、AblazeVase69188、Siiftun1857等。)--TripleCamera(留言) 2022年12月27日 (二) 05:01 (UTC)(最后编辑于2023年1月3日 (二) 08:23 (UTC))
- 补充:已被存档的“关于拆分和优化Java版已移除特性”话题。
- 群内讨论的初步结果是需要将Java版已移除特性#未使用拆分出去,最开始是希望拆分到Java版已移除特性/未使用或者Java版未使用特性/已移除,后来Siiftun1857提出了“与其纠结是不是未使用,还不如直接别分未使用”。目前计划将Java版已移除特性#未使用拆分到Java版已移除方块、Java版已移除物品、Java版已移除配方中。--AblazeVase69188(讨论 | 贡献) 2022年12月27日 (二) 05:17 (UTC)
--Yzy32767-T/C- 2023年1月6日 (五) 03:12 (UTC)
中国版页面收录内容及改写
中国版是原版游戏的衍生版本,目前其页面内容以强调中国版与原版差异及特性对比为主。该行文方式有利于读者快速在原版理解基础上建立对于中国版的认识,但是随着中国版内容的丰富也遇到了局限。
正文内容上,差异/对比段落难以详细表述中国版包括:
- 社区等级、社交群组动态系统、租赁服务器等核心机制,此部分内容可能需列举较多数据;
- 对于重要游戏内容如:联机专区、季度玩法、网络游戏、内置组件等几乎未提及,另有消息指出多款社交/辅助类内置组件已经开始小范围测试;
- 家园系统及装扮系统较为特殊,但4D皮肤、宠物、家园家具这些物品看似繁多总数目却十分有限,类比角色创建器或MCD:皮肤可独立页面全部收集列举,事实上官方4D皮肤数目尚不及MC地下城皮肤;
- 对于开发者内容,目前中国版已有多种开放的开发工具及开发者版游戏,有别于国际版基岩开发版的严格审核和保密要求,上述工具任何玩家仅凭证件即可获取,其使用几乎不受到额外限制,私以为应进行至少的简要介绍(另据考证目前文段中公文包侧载附加物品的途径可能早已失效)。
社区交流中,常遇玩家及内容创作者感叹于wiki内容的严谨详实,同时不免表达对中国版详细内容尚阙的遗憾,其中包含大量中国版独占玩家。以描述差异为主的中国版页面引目的有所收获读者困惑的现状是我在阅读、编辑中的个人感受,亦为相当部分读者的体验。事实上,中国版独占玩家阅读此页面时,他们读到的可能通篇是“...是第一次...”类你知道吗。
最后对于素材等使用时的版权问题,窃特意考证“《我的世界》正式版用户协议”等可查资料,其中网易几乎仅特意声明了其Logo的不可分发性、不可修改性及开发者Logo/创建内容的版权归属问题,现实中的确市场组件经过了严格加密后分发至游戏端,而游戏素材、热更新资源包等均未被加密;社区中2020年初兴起的手游端启动器资源研究至今两年半不足已是蔚然成风,官方频道中大量此类帖子高赞甚至被官方精选,而wiki进行展示公益性、服务性远强于用户自发行为,对于社区的引领建设必将影响深远。 Minecraforever(留言) 2023年1月7日 (六) 12:33 (UTC)(最后编辑于2023年1月7日 (六) 12:48 (UTC))
- 支持收录更多的中国版内容。但是诸如4D皮肤这类装扮我觉得还是暂时没必要将详细的内容写入Wiki页面,对于官方装扮这一类内容,写得太详细恐怕会被误解为“帮网易宣传”,我觉得简单地带过一笔(最多再加一张图片)就行了。--AblazeVase69188(讨论 | 贡献) 2023年1月7日 (六) 12:47 (UTC)
- 个人认为不是意义的问题,而是拆分之后是否有人可以维护的问题。--
Lakejason0(论•功) 2023年1月7日 (六) 12:48 (UTC) - 补充:翻了一下以前的存档,以前有关收录更多中国版内容请求被拒绝的原因主要包括“潜在的法律风险”“不符合关注度原则”(大部分是Add-on,不属于原版玩法)“没人维护、没人同步到en”,参见Minecraft Wiki:社区专页/存档6#需要创建中国版独有特性和Minecraft Wiki:社区专页/存档9#关于中国版缺乏介绍的问题。写的时候记得避坑。--AblazeVase69188(讨论 | 贡献) 2023年1月7日 (六) 13:10 (UTC)
- 有些事情需要明确一下:
- 本wiki没有义务帮助中国版宣传内容,也没有义务引导阅读者去玩中国版。
- 本wiki的正式名称为“中文Minecraft Wiki”,绝对不是所谓的“中国大陆Minecraft Wiki”,意味着所有阅读者或者编辑者并非全部来自中国大陆,尽管目前中文Minecraft Wiki确实主要是由来自中国大陆的用户维护的。
- 本wiki暂时没有大规模收录中国版内容的打算。考虑到中国版的风评并不好,以及中国版增加、更改或删减的内容非常多,恐怕不适合在本wiki已有条目的基础上再建造更多关于中国版的内容。换句话说,开一个新的wiki是一个好的选择。除此之外,诸如加载器Mod这类已经明确不再收录的“不受官方支持”的游戏内容,在中国版并非如此。也就是说一些适用于“国际版”的概念或定义并不一定完全适用于“中国版”身上。
- 维护问题。谁来长期维护这些页面?我不清楚。
- wiki安全和声誉问题。本wiki有许多来自外部的破坏者,专门对中国版这一页面进行破坏(导致其被永久半保护);某些不友好人士喜欢以诸如“wiki没有维护网易开发者的权益”“帮中国版说好话”等借口来对wiki进行诋毁、攻击行为,这一定程度上会影响本wiki的声誉。我不希望因为收录了更多中国版独有内容而使得这些问题被放大,恕管理层无法对此承担过多责任。我们wiki的核心工作内容是对内容的建设,而不是对破坏者进行斗争。
- 综上,我个人是偏向于 反对收录中国版的更多内容。出于对本wiki的管理问题考虑。--Lxazl5770zh.admin(论 ▪ 功) 2023年1月7日 (六) 13:50 (UTC)(最后编辑于2023年1月7日 (六) 14:06 (UTC))
- 个人认为第三点第一句与该议题本身相抵触,本议题就是希望修改这一点的。第三点中“在本wiki已有条目的基础上再建造更多关于中国版的内容”也不是该议题的内容。第五点本身和其他的wiki站点所要承受的情况相同,我认为这段论述不合适。--
Lakejason0(论•功) 2023年1月7日 (六) 14:06 (UTC) - 开新wiki也不一定合适,参照Fandom先前的部分措施,他们更希望将主题相近的wiki合并处理,因为这样能够最大化内容曝光(也就是SEO)。--
Lakejason0(论•功) 2023年1月7日 (六) 14:09 (UTC)(最后编辑于2023年1月7日 (六) 14:10 (UTC)) - 我认为依原版视角观察中国版可能比较“水土不服”,中国版面对国内同量级数万竞品游戏采取了周期性附加玩法的运营模式更类似Minecraft Earth或Minecraft Dungeons赛季/活动等机制,addon和联机玩法是其适应原版游戏所表现出的呈现形式,而诸如基岩版角色创建器付费物品、地下城皮肤/通行证等内容wiki都有大量列举展示,仅作客观描述应该可忽视其广告效应(甚至其中相当部分内容并不需要付费),事实上扩大看来任何对游戏内容的详细描述对其所包含于的版本/使用的平台都有不可避免的宣传作用。法律问题如总段所述之外曾问起过几位网易运营的工作人员,基本对于wiki的运作机制表示肯定,谈到资源版权时稍有含糊,应为“保留解释权力”的意味,私以为如遭版权问题,其他资源可能未必首当神秘框架之冲。维护问题比较容易,中国版更新频率4个月一次大版本,每周五推一次热更新,大版本也以原版改动为主,独特内容相当有限,其内容相较其他版本维护难度可能还要稍低,日常仅需每周同步版本号一次。Minecraforever(留言) 2023年1月7日 (六) 14:10 (UTC)
- 尽管我认为添加中国版相关内容还是值得提倡的,留着这么一个大坑不填并不利于服务广大玩家群体,但是目前个人看来中国版相关视频的评论都是负面评论占了一大块,基本上没人为中国版说话,只能说这件事跟其他“负面评论毕竟是少数,不需要理会少数人的负面评论”的事的性质可能有很大的不同…然而,中国版做的不好跟我们无关,Wiki主要需要避免所谓“宣传中国版”的嫌疑,但只给相关页面加一个
{{Disclaimer}}也许是不够的…--AblazeVase69188(讨论 | 贡献) 2023年1月7日 (六) 14:30 (UTC) - 遭遇攻击为管理工作带来困难深表遗憾,以下我个人观点未必正确。换角度来说攻击者攻击的目标可能正是其立场下对于“差异”的不满等,事实上页面中wiki也没帮中国版说一句好话,反观将屏蔽词、防沉迷等普遍争议性内容放在显眼之处未免“枪打出头鸟”。中国版“风评不佳”成因有着复杂历史社会背景,期间产生的以差异为主的话题wiki悉数罗列,未必不是观点各异的“斗士”欢聚一堂的妙地。中国版存在的问题使得因其导致直接损失的个体为之奔走,同时中国版庞大的核心用户和其生态之下掩于冰山的开发者群体虽在社交平台声量稍逊一筹事实上也无时无刻不在伸张中国版的魅力之处。不接纳的态度及强调差异的叙事手法最终不知有何可能。wiki无需强调任何中国版具有优势的领域,也无需贬低其游戏生态位导致的固有差异,真正客观展现中国版具有独特内容有规避攻击等可能。Minecraforever(留言) 2023年1月7日 (六) 14:38 (UTC)
- 将尝试在个人页下创建一个改写副本,完善后供各位过目。Minecraforever(留言) 2023年1月7日 (六) 15:46 (UTC)
- 个人认为第三点第一句与该议题本身相抵触,本议题就是希望修改这一点的。第三点中“在本wiki已有条目的基础上再建造更多关于中国版的内容”也不是该议题的内容。第五点本身和其他的wiki站点所要承受的情况相同,我认为这段论述不合适。--
- 我的想法是,中国版内容如果要收录的话,全部收录到同一个条目(以及这个条目的子页面)就行了。所有中国版独有特性在此页面及其子页面之外都不要提及。至于皮肤什么的内容,提及名称表示其存在就行,图片都可以不用整的。--siiftun1857[T/C/E] 2023年1月10日 (二) 09:55 (UTC)
- 如果确实是要收录,只能考虑开一个新的命名空间(例如
Minecraft China:)并予以半保护,但是建设速度肯定是跟不上的。我顺便解释一下,“帮中国版说好话”并不是真的指本wiki有意引导内地用户使用中国版进行游戏而抛弃国际版,而是考虑到wiki的“绝对中立”的立场会招致国内某些群体的不喜欢,进而产生破坏本wiki的想法。可以参考维基百科一些政治性较强的条目通常都需要半保护或者全保护。--Lxazl5770zh.admin(论 ▪ 功) 2023年1月12日 (四) 05:44 (UTC)- 根据该议题前面发言的意思,中国版内容只会限制在少数几个页面甚至一个页面中,可能不需要为其准备新的命名空间。对于只是因为Wiki收录了中国版内容就要破坏和诋毁Wiki的少数群体,只能在其他方面上加强对相关页面和整个Wiki的保护。--AblazeVase69188(讨论 | 贡献) 2023年1月12日 (四) 06:02 (UTC)
- 目前已在User:Minecraforever/MCCEedit完成了大约过半的更改,很多核心概念在手游版段落给出介绍,后半部分端游版无需再次重复。家园等次要内容暂时放入其它段落。请各位斧正。Minecraforever(留言) 2023年1月18日 (三) 17:12 (UTC)
- 如果确实是要收录,只能考虑开一个新的命名空间(例如
- 昨天(1月21日)晚上,Star00、SorajimaAsugawa、Miemiemethod、Dianliang233、ENxJIA、Anterdc99、Lakejason0和AblazeVase69188等人在管理群中对此话题展开了讨论。Star00将讨论的结果概括为:“原则上要写,实践上难写。找到读者主要关心的内容,先划分出一部分易编写的部分允许开工,同时对难编写难维护的内容暂时禁止编辑。”具体来说,接下来要做的事情依次是:
- Minecraforever正在个人沙盒中重写“中国版”页面,等待其编写完成,并进行评价。
- 找到易编写、读者主要关心的内容(可以发问卷),并开始编写,写到中国版页面或其他几个中国版有关页面中。同时重写不中立的部分。对难编写难维护的内容(如开发内容)略写、提及或者暂时搁置。
- 长远来看,可以创建计划,并主动邀请有能力的基岩版编者编写难写的内容。当然,不写也是可以的。
- --TripleCamera(留言) 2023年1月22日 (日) 10:50 (UTC)
- 文字部分工作已全部完成,如果大部分内容合适,将随后把图片补充上传。烦请各位评价。Minecraforever(留言) 2023年1月29日 (日) 12:51 (UTC)
统一模板文档页面的格式
目前,Wiki上的模板文档页面格式混乱、表述不清,在一定程度上导致部分用户难以准确使用某些模板。例如:
- 段落标题不统一,有的文档页面甚至没有段落标题。目前本人和Anterdc99正在使用以下格式:
{{documentation header}}
<!-- 文档页面 -->
[模板简介]
== 用法 ==
=== 基本用法 ===
[模板最简单,最基本的用法]
=== 完整用法 ===
[模板的完整用法,一般应一次性体现所有可用的参数]
* [参数1]:[用法]
* [参数2]:[用法]
......
== 示例 ==
* [代码1]:[效果]
* [代码2]:[效果]
......
== 依赖项 ==
[该模板使用的模板]
== 参见 ==
[同类模板]
<includeonly>...</includeonly><noinclude>...</noinclude>
- 但本人深知这样还不够,还请大家集思广益。
- 介绍模板用法时,漏掉参数(比如模板一共有3个参数,却只介绍其中2个)、单个参数介绍不完整(比如某个参数只能填数字却没有说明)、参数之间的关系(比如使用了参数1就不能再使用参数2,不使用参数1就会默认使用参数2,等等)介绍不完整等问题时有发生。在MCW:格式指导/红石#建造结构中使用一种方块来表示一类方块,本人认为可以使用与之类似的方法,比如用红色表示必选参数,用黄色表示可选参数,等等;即使不采用这种简便方法,至少也得介绍清楚,对吧?
- 举例说明时,为了展示代码,有的使用
<code><nowiki>...</nowiki></code>,有的使用<pre>...</pre>,有的使用{{t}},还有的使用{{tcode}}......这4种方式呈现的效果各不相同,让人眼花缭乱。另外,<code>...</code>与{{code}}的用法在编辑手册中写得很清楚,但很少有人遵守,而这种滥用{{code}}模板的现象在文档页面中尤为严重。如何处理这些问题? - 有些模板没有任何分类,分类不正确,或者被分类到了Category:基于Lua的模板这种范围过大的分类。要想找到它们,除了去翻别人写的源代码,恐怕只有去所有页面一个一个找了。因此本人认为几乎所有模板(像
{{talknotice}}之类的除外)都至少需要一个有效的分类(“Category:基于Lua的模板”之类的不算)。(解释一下,之所以把这点放在这里,是因为模板分类通常应该放在模板文档页面的<includeonly>...</includeonly>之间。)
综上,我们有必要统一模板文档页面的格式(由于篇幅关系,这里只列出了最重要的几点)。也许我们会需要MCW:格式指导/模板文档,但为此付出的一切努力都是值得的。--{{{XDMC1|讨论}}} 2023年1月10日 (二) 07:48 (UTC)(最后编辑于2023年1月10日 (二) 15:54 (UTC))
- 1. 举例说明时使用
{{tcode}}吧,不使用{{t}}的原因是模板文档最终会嵌入模板页面,会导致“原地tp”的现象出现;使用{{tcode}}代替<code><nowiki>...</nowiki></code>更能体现模板使源代码简明的作用。 - 2. 对滥用
{{code}}模板的现象直接按照编辑手册所写的内容,修改文档即可。 - 3. 确实有必要为模板添加分类,可以先为放置在“参见”段落中的模板统一添加分类(换句话说,模板A文档的“参见”段落放置了模板B和模板C的链接,那么就需要为将三个模板添加一个统一的分类)。但这样应该是不够的,还存在其他需要添加分类的模板。
- 4. 部分模板的文档页面长期未更新(这导致了介绍模板用法时漏掉参数的问题),未翻译或者甚至未创建。
- 5. 借个楼,有没有必要为模块页面添加文档?
题外话:看到这个话题,我才知道有{{tcode}}这个模板。--AblazeVase69188(讨论 | 贡献) 2023年1月10日 (二) 09:24 (UTC)- 我自己用的模板文档格式可以在Template:AutoDmg和Template:HpRange见到,或许可以参考。--siiftun1857[T/C/E] 2023年1月10日 (二) 09:49 (UTC)
- 信息:模板参数另有
<templatedata>可用,而且写上它有利于可视化编辑器使用正确的格式(比如全部写在一行内或者换行写参数)。MysticNebula70 T 2023年1月10日 (二) 11:44 (UTC)- 感谢,顺便附上该扩展的链接以供参考:mw:Extension:TemplateData--{{{XDMC1|讨论}}} 2023年1月10日 (二) 12:48 (UTC)
- 不建议在议题里面“叫”(加上太多抒情性语句,读起来很累,而且没有实质性作用)。大部分说的都有道理,但是需要注意,由于代码展示的内容很可能包含中文,所以如果使用HTML标签,那么必须以-{}-作为标签内的内容开头以开启转换。至于如果需要使用其他的模板,那么这些模板本身需要对应的开启转换。--
Lakejason0(论•功) 2023年1月10日 (二) 15:12 (UTC)(最后编辑于2023年1月10日 (二) 15:21 (UTC))
- 感谢,已加入字词转换。--{{{XDMC1|讨论}}} 2023年1月10日 (二) 15:42 (UTC)
- 群内的部分讨论提及了模板数据的一些问题(包括只能使用纯文本无法使用wikitext),需要说明的是模板数据内的说明不应该过分的长和详细,需要适当的精简。此外,模板数据也并非用于完全替代传统文档的。对于简单的模板,当然可以直接合并用法的两个段落,只摆一个模板数据就可以。对于复杂的模板,自然也可以保留传统的用法段落,把模板数据置于文档页面的最底部(甚至折叠起来),既可以帮助改善VE对复杂模板的错误调用,也可以保持文档一上来的简洁。--
Lakejason0(论•功) 2023年1月10日 (二) 15:33 (UTC) - 注意:编辑手册中关于“<code>和
{{code}}的区别”的部分经讨论,已被当做过时内容删除。再次感谢大家的宝贵建议!--{{{XDMC1|讨论}}} 2023年1月10日 (二) 15:42 (UTC)
补充在Linux系统下的描述
我是一名使用GNU/Linux操作系统的用户。在此期间,我测试了许多的Minecraft版本,发现了许多的新的特性,其中有大部分是Wiki上没有的(Wiki上大部分写的是Windows的内容,有一部分macOS的,极少有Linux的)。主要表现在三个方面:文件系统(权限、大小写、rm命令即时删除而不考虑占用等)、GUI/输入表现(鼠标指针、键盘及热键、窗口与全屏等)、引擎/驱动(Mesa、显卡驱动、图形库、libcef等)。
我知道这些东西绝大多数属于技术性细节,且GNU/Linux操作系统的用户占比很低。只是想来问一问是否有必要添加/修改这方面的内容以及如何做。
与此同时,Wikipedia上几乎没有关于Linux内核方面的条目。 Manarein(留言) 2023年1月11日 (三) 04:18 (UTC)(最后编辑于2023年1月11日 (三) 04:29 (UTC))
- 请您根据Minecraft Wiki:讨论页方针#签名修改您的签名。Manarein和您的真实用户名IAmREGE的关系极小,难以辨认。如需改名,可以直接修改Fandom用户名(我记得是一个特殊页面)。--
Lakejason0(论•功) 2023年1月11日 (三) 06:21 (UTC)
- 信息:这个特殊页面是Special:UserRenameTool。--{{{XDMC1|讨论}}} 2023年1月11日 (三) 06:32 (UTC)
- 我理解您的请求(我是Arch Linux+KDE用户),不过更希望您能举一个例子(比如某个页面少什么内容,如果您想添加会怎么添加(在沙盒内演示),等等)。就这个议题现有的内容来说,您的要求似乎有些宽泛,不太好系统性的补充。--
Lakejason0(论•功) 2023年1月11日 (三) 06:21 (UTC) - 部分内容如果涉及疑难解答的可能视情况建议您写到ArchWiki等文档去。--
Lakejason0(论•功) 2023年1月11日 (三) 06:26 (UTC)
- 我测试了一个页面User:IAmREGE/Sandbox/教程/不该做的事,发现里面的“任务管理器”仅针对于Windows。并且顺便问一下,在提及到Linux命令是,如果是比如kill或clear这种和Minecraft游戏内命令同名的应该如何做? IAmREGE(留言) 2023年1月11日 (三) 09:28 (UTC)
- 可以使用
{{cmd}}模板直接指代游戏内命令,Linux命令就作特殊标记或说明。--AblazeVase69188(讨论 | 贡献) 2023年1月11日 (三) 09:56 (UTC) - 作为Linux用户我觉得你应该知道一般来说演示文本里会用#和$作为命令的开头。不过就你写的“Linux系统可能要切换到其他tty并使用Linux命令kill”,太琐碎了。再一个,任务管理器不是Windows才有,虽然通常在其他地方他们不会叫这个名字(KDE下类似的应用程序为系统监视器)。如果只是沙盒内的程度的话,我建议不写,因为写出来太琐碎了(macOS?FreeBSD?Windows下也可以通过命令结束进程啊)。你议题中的部分方面还是很有道理的,我建议换个方向举例子(比如已经补上相关内容的Java版世界格式#session.lock格式)。--
Lakejason0(论•功) 2023年1月11日 (三) 10:20 (UTC)(最后编辑于2023年1月11日 (三) 10:27 (UTC))
- 操作系统只列举支持的就好吧。目前macOS和FreeBSD(原版)没有tty,同时还有shell,部分Linux就乐意将PowerShell当默认shell(尽管语法和bash有不同),Windows下结束进程的命令是taskkill.exe或taskkill,不是kill,删除是del或erase,不是rm,清屏是cls,不是clear,Windows下内部命令比较多,而Linux的shell下(PowerShell除外)除了cd、help、export、source之类的都是外部命令。另外FreeBSD还没有成功安装过Minecraft JE(Wine都不行),GNU Hurd连Java都没成功安装过
- 另外,Windows NT本身就是一个GUI系统内核,但是Linux不是,它还是基于teletype的,因此还会出现桌面环境/显示管理器崩了然后回到tty去的情况。一些细节问题,比如说Linux系统中目录是文件的一种,没有盘符,环境变量用
$不用%,ext文件系统区分大小写,删除/移动文件不需解除占用,Alt键叫Meta,Win键叫Super,不由文件扩展名判断文件类型(例如dat或nbt文件,它会识别为gzip压缩文件),默认换行模式是LF等等。甚至还有有问题的桌面环境,按了一下CAD组合键就重启了的情况。 - 还有计量单位。主要是KB与kiB,MB与MiB,GB与GiB,在Microsoft单位下它们都是等价的,但Linux用的是ISO单位,它们不是等价的。 IAmREGE(留言) 2023年1月12日 (四) 05:06 (UTC)
- 您目前提到的(大)部分细节都“过于琐碎”,不应写出,因为这部分不属于游戏内容,而是应当由使用者自行了解的操作系统知识。就依然比如“Linux系统可能要切换到其他tty并使用Linux命令kill”,不如直接改为“或其他方式”,囊括了所有其他情况。对于明确提供了和游戏有关的操作系统外壳命令(命令本身、环境变量)、目录(盘符、目录符号形式)的教程或相关说明(比如.minecraft的位置、服务器启动脚本),则确实应当写出对应操作系统下的表述。按键差异也基本无需写出(更何况您说的有误),毕竟有
{{keys}},其实基本上已经把差异抹除掉了。桌面环境差异也是“不属于游戏内容的操作系统知识”,不应该在此写出,也许可以考虑写到ArchWiki去。基于这样的考虑,我可能会建议您在实际页面的讨论页提出“可能需要补充Linux内容”的议题,因为本议题太过庞杂,而您暂无法明确写出究竟哪些是需要写出的内容,不如每次遇到都问问大家。数据计量单位建议补充到各个格式指导中去,因为也不属于操作系统差异。--
Lakejason0(论•功) 2023年1月12日 (四) 05:19 (UTC)(最后编辑于2023年1月12日 (四) 05:22 (UTC))
- 您目前提到的(大)部分细节都“过于琐碎”,不应写出,因为这部分不属于游戏内容,而是应当由使用者自行了解的操作系统知识。就依然比如“Linux系统可能要切换到其他tty并使用Linux命令kill”,不如直接改为“或其他方式”,囊括了所有其他情况。对于明确提供了和游戏有关的操作系统外壳命令(命令本身、环境变量)、目录(盘符、目录符号形式)的教程或相关说明(比如.minecraft的位置、服务器启动脚本),则确实应当写出对应操作系统下的表述。按键差异也基本无需写出(更何况您说的有误),毕竟有
- 跑偏了。目前的主要问题,我详细说一下:
- 一,文件系统。文件系统主要说文件的新建与删除,读取与写入。前几天在JE1.12.2上发现将极限模式存档的整个目录进行递归的
chattr +i操作之后在进入存档,会让Minecraft崩溃。而chattr命令仅适用于ext/btrfs文件系统,没法用于Windows常用的NTFS/FAT文件系统。还有我已经开的MC-258717,也是针对于Linux文件系统权限(模式)的。同时让Minecraft读取一个断的symlink,读取指向设备文件的symlink都会出现奇怪的问题。创建一个新存档,然后把存档目录下所有文件直接删掉并让目录模式设为000(a-rwx),最后“保存并退出”,会让Minecraft卡住,并且之后恢复目录的权限,Minecraft也不会继续保存存档。把存档目录名改为$'\200\201\202\203'(这是bash转义字符串)会让存档无法被识别,而这是Windows下做不到的。 - 二,输入/GUI。在Linux系统下进入世界,然后按下Esc键暂停,再按一次Esc键继续游戏,鼠标指针有概率不隐藏(但是显示了鼠标指针也不会移动)。并且在Linux系统中进入设置开启全屏并调节“全屏模式”至非“当前分辨率”会让鼠标错位(我的设备上是这样子的)。以及键盘按键延迟(例如一直按住w键然后按下“/”键,则输入框会不断输入“w”,同样适用于告示牌、铁砧、搜索框)。这一点没有多大问题。
- 三,驱动/库。这一点问题也不大。
- 四,其他。就是那些“删除”“结束进程”之类的用户操作。 IAmREGE(留言) 2023年1月12日 (四) 08:50 (UTC)
- 可以使用
- 我测试了一个页面User:IAmREGE/Sandbox/教程/不该做的事,发现里面的“任务管理器”仅针对于Windows。并且顺便问一下,在提及到Linux命令是,如果是比如kill或clear这种和Minecraft游戏内命令同名的应该如何做? IAmREGE(留言) 2023年1月11日 (三) 09:28 (UTC)
关于“伤害免疫”
已知伤害免疫会被重定向到伤害#伤害免疫。在其中,“伤害免疫”被描述为一种受伤后的保护机制。但除此之外,“伤害免疫”还被用于描述无法对某种实体造成特定的伤害的情形,如:
显然,“伤害免疫”一词出现了歧义。
必须指出,两者间存在根本的区别:该次伤害是否拥有能够对目标实体造成伤害的能力。
为了区分二者,在以下说明中,我将使用“受击保护”代指受伤后的保护机制,“伤害免疫”或“免疫”代指某次伤害不具备对目标实体造成伤害的能力。
- 基岩版中可以实现伤害免疫的组件为minecraft:damage_sensor,但minecraft:damage_sensor无法修改受击保护相关内容。
- 在对某种实体使用
/damage造成该实体免疫的伤害时,statusMessage使用的本地化键名为commands.damage.failed;而造成该实体不免疫的伤害时,即使目标实体处于受击保护中且生命值并未改变,statusMessage使用的本地化键名为commands.damage.success。 - minecraft:weapon组件中存在on_hurt_entity和on_not_hurt_entity参数(类型为事件触发器),on_not_hurt_entity参数会且仅会在攻击命中了实体但无法造成伤害时生效(比如目标实体免疫该次伤害)。然而实际测试中攻击命中了不免疫这次伤害但处于受击保护中的实体后生效的是on_hurt_entity参数。
- 当玩家的近战攻击命中了免疫玩家的近战攻击实体时会播放game.player.attack.nodamage;而命中了不免疫玩家的近战攻击但处于受击保护中的实体后播放的是game.player.attack.strong。
综上所述,“受击保护”和“伤害免疫”是两个机制:“伤害免疫”所免除的伤害不具备对目标实体造成伤害的能力,但“受击保护”所免除的伤害具备对目标实体造成伤害的能力。“受击保护”并不能用“伤害免疫”来解释。
因此,应该使用“受击保护”或类似的词语替代笼统的“伤害免疫”来描述受伤后的保护机制。2190303755(T|C) 2023年1月13日 (五) 17:14 (UTC)(最后编辑于2023年1月14日 (六) 05:21 (UTC))
- 提一下,您的签名代码共270个字符,根据讨论页方针,签名代码最多为255个字符。--{{{XDMC1|讨论}}} 2023年1月14日 (六) 01:52 (UTC)
- 请问270个字符是怎么计算出来的?我数了半天也只有254个。 --Chixvv(留言) 2023年1月14日 (六) 02:39 (UTC)
- 我虽然没数,但我猜他把签名后面的日期给带上了。--AblazeVase69188(讨论 | 贡献) 2023年1月14日 (六) 03:31 (UTC)
- 请问270个字符是怎么计算出来的?我数了半天也只有254个。 --Chixvv(留言) 2023年1月14日 (六) 02:39 (UTC)
- 支持修改。但是感觉“受击保护”也不太好,但我也想不出更好的。--Chixvv(留言) 2023年1月14日 (六) 02:39 (UTC)
- 支持修改。我想到一个“伤害保护”的名称,仅供参考。--AblazeVase69188(讨论 | 贡献) 2023年1月14日 (六) 03:31 (UTC)
- 支持修改。如果“受击保护”不太好的话,“受伤保护”或许更加贴近一些?(不过似乎区别不大)—KaplanSteve T/C 2023年1月14日 (六) 06:30 (UTC)
- “伤害免疫”段落原有内容已经删了,新的段落是伤害#受击后伤害免疫。
生物受到伤害被无效化的机制写到了伤害#无懈可击里。--siiftun1857[T/C/E] 2023年1月17日 (二) 17:16 (UTC)(最后编辑于2023年1月18日 (三) 16:21 (UTC)) - 顺便提一下,那句话的断句是
烈焰人对火焰伤害免疫。,而不是伤害免疫。不过这句话读起来也挺奇怪的,已经改掉了。--siiftun1857[T/C/E] 2023年1月17日 (二) 17:23 (UTC)
关于版本更新后的steve皮肤问题
Minecraft 1.19.3中更改了steve皮肤,但我发现还有许多的页面有旧版steve皮肤,可能需要修改。Zhangzixuan2010(留言) 2023年1月19日 (四) 01:45 (UTC)
关于香港繁体的注音问题
本Wiki在过去仅支持大陆简体和台湾繁体,而{{zh pron}}标音也仅加入汉语拼音和注音符号。目前加入了香港繁体,但是其标音仍然为注音符号。介于注音符号为台湾特有的标记系统,香港用户未必能识读。为了香港用户的体验,是否加入专门为香港用户服务的粤语拼音?目前中文维基百科正在使用此方案。--HlDoroWolf(留言) 2023年1月22日 (日) 04:53 (UTC)
- 就本wiki对注音的用例来说,基本都是标注大陆标准下的异读问题。对岸在绝大多数情况下豁免这些问题,而香港地区由于用粤语,实际上压根不是一类情况,因而也无需在该变体下标注。就你提出的内容来说是合理的,但是本wiki没有地方可以用到。--
Lakejason0(论•功) 2023年1月22日 (日) 11:52 (UTC)
关于改造Inventory slot及Minetip的事宜
可再生资源页面因超限而需用{{LoadPage}}拆分。Anterdc99在管理群内认为,{{Inventory slot}}模板的模块实现本身就自带一个展开模板,只要用了,无论如何都会超限,而要解决,则要将Module:Sprite和Module:Inventory slot内的模板调用改掉。由于MysticNebula70提出的“在该页面不使用Sprite,而是变成各自单独的图片”会导致Minetip消失,反而可能给读者造成辨识困难,且即使可以再造悬浮提示,当前Minetip将文本丢入title属性既破坏语义(这个属性内的内容应当可以被忽略,但实际上并不是)也导致字词转换失效(LanguageConverter不会转换HTML属性内的东西),因而最终地去解决问题需要更改本wiki大量使用的代码。
由于我个人没有模块编写的能力,且该事项较为重大,故在社区专页而非管理员告示板提出。不过,由于两位的兴致缺缺(没有认为其态度有任何问题的意思,而是为了“个别页面超限”与“关注度较低的部分”去大动地基确实让人提不起劲),短期内可能还是不会有什么进展的。我个人建议先从Fandom要求审查的JS开始改起,将这份JS做成可以向前兼容(难度可能比较小……?),待应用上后,再去应用模块,以期达成平滑过渡的效果。--
Lakejason0(论•功) 2023年1月29日 (日) 18:31 (UTC)
关于模板页面的建设
新版本加入了盔甲模板和升级模板,但wiki还没有此内容的页面,我本人既不熟悉wiki语法又无法保证自己的页面的质量,所以在此提醒各位有能力建造页面的人补充这个内容 另外,锻造台的GUI也要改Wingsofsky2022(留言) 2023年1月30日 (一) 07:53 (UTC)wingsofsky2022