我们敬爱你口牙

好好好！大佬！我们敬爱你呀

收藏了

给大佬递活力水

好耶

nb

虽然应该有相当一部分玩家对我应该是比较熟悉的，但我觉得还是有必要证明一下自己的含金量.....总不能说什么东西都没有就跑来写教材，那样没有东西能证明自己的技术力，教程也会失去说服力

代表作品是这个，统计数据如图所示

我也是神州凶兽、预兆母树、石双双、艾叟坡达种系等项目的主程序
我还发布过虐待收容实体、更好的研究列表、手术刀、战地续航、旋风绘卷科技等mod
实际上这是一个几年前就开始更新的教程，由于一些原因一直未转过来
我会在最近将教程内容陆续转至该贴，而后继续更新
再次强调一下3楼的盘内有很重要的东西，有意向学习mod开发的小伙伴请务必获取。

基础篇 第五讲：About文件
About文件
这是个mod的外在属性的管理器，内容包括其作者，mod名，工作版本等。这些属性最常在mod配置器【即mod列表】使用。而该文件即使在mod未被启用时也会加载。所以，写这个文件时要十分注意，它可能会导致一个未被启用的mod报错而彻底迷惑普通玩家。
以下是机甲的about

name：mod名字，为一个字符串【区分大小写，可以使用特殊字符和各种语言】不允许换行，允许与其他mod重名
author：作者名字，为一个字符串
authors：同上，为一个List
packageId：mod的识别id。程序使用这段数据来识别mod，因此不允许与其他mod相同。当你本地mods或steam订阅mod中出现相同id，无论该mod是否被启用均会报错——除非它们一个是本地版，一个是steam版。
它不区分大小写，仅允许出现英文，数字和小数点。我们常用的格式为：
【作者英文名或steam名】.【mod英文名】
以及
【作者英文名或steam名】.【目录】.【mod英文名】
supportedVersions：此处为mod的运行版本，是一个List。若该数据内所有元素均与当前游戏运行版本不匹配，则mod在列表中会变为黄名且后置。
description：介绍，也是填文本，可以直接换行。
modDependencies：非必须内容，依赖mod，即必须在该mod运行的情况下才能启用本mod。内含：
>packageId：依赖mod的识别ID
>displayName：显示的mod名
>steamWorkshopUrl：steam创意工坊链接，为steam://url/CommunityFilePage/【工坊id】
>downloadUrl：下载链接，直接一个HTML超链接。
>以上的steamWorkshopUrl和downloadUrl可以直接不写。
loadAfter、loadBefore：非必须内容，要求该mod的排序在其他mod前/后，为一个List，元素填其他mod的packageId
incompatibleWith：非必须内容，要求该mod不允许与某些mod一起被启用，为一个List，元素填其他mod的packageId
forceLoadBefore、forceLoadAfter：与上面的那俩相似，但其要求更强，游戏会强制满足该排序。
descriptionsByVersion、modDependenciesByVersion、loadBeforeByVersion、loadAfterByVersion、incompatibleWithByVersion：非必须内容，是上面提到的“description、modDependencies、loadAfter、loadBefore、incompatibleWith”的“根据版本变化”的模式，在使用时先打版本数据，再打内容，比如：
<incompatibleWithByVersion>
<v1.3>
<li>CETeam.CombatExtended</li>
</v1.3>
</incompatibleWithByVersion>
意思是仅在1.3版本下与CE冲突

小吧有群号吗？自己看xml和反编译的dll有一堆问题搞不明白

基础篇 第六讲：Defs文件
该文件夹用于存放defs文件，每个文件内会有一个或多个def数据体，以数据库的形式被程序读取来形成mod的新内容。
Defs数据体有ThingDef，HediffDef，RecipeDef等的区分，不同的def对应不同的新内容，如刚才的三个分别对应新物品，新的健康状态和新的制作配方。
Def的内容依附游戏已有的庞大框架，学习他们就是本教程的主体部分，从此我们将用其不断创造新内容来完成我们的mod。不同def以后会分别详细讲解，此章节我先介绍所有def共有的数据。
<?xml version="1.0" encoding="utf-8" ?>
<Defs>
<DamageDef ParentName="Bomb">
<defName>XFUnused_BombWithDirection</defName>
<label>炸</label>
</DamageDef>
<DamageDef ParentName="Bomb">
<defName>XFUnused_BombWithDirectionSecond</defName>
<label>炸2</label>
<workerClass>MParmorLibrary.Unused.DamageWorker_ExplosionWithDirection</workerClass>
</DamageDef>
</Defs>
第一行是XML固定识别码，不可丢
第二行是Defs，我们所有的def都要被这个东西包住（看第二行与最后一行）
然后中间的就是每一个数据体了
<defName/>
该数据是一个def的基础，表示了一个def的识别名，就像身份证号一样，相同类型的def间defname必须不同，而不同类型间则可以相同。
请注意，这里的单一性不只适用于你的项目，拿thingdef举例，所有已启用的mod中的所有thingdef都不允许重复，当然也不允许与原版的重复——毕竟原版本身就被视为一个mod。
为了解决这种极易出现的bug，所有制作者均会在defname填写时加上一个独特的前缀，如游戏里“钢铁”的defname为”Steel”，那么我得项目里的新钢铁就可以这么写：
<defName>XFMLI_Steel<defName>
其中XF是“旋风”的缩写，MLI是“mod lesson instance”的缩写。
当然，只要你有自己解决重名的方法，如何命名是无所谓的，但整体必须遵循仅由：1.大小写英文（defName是大小写敏感的） 2.数字 3.下划线 组成，且最后一个字不能为数字。而除了程序的这些硬性要求之外，我们还有一些自己的规范：
由于不允许使用空格，在面对多个单词的时候有些人会选择使用下划线：
<defName>XFMLI_Beautiful_flower_for_you</defName>
其实显得过于冗长和散漫，我更推荐用“驼峰命名法”，而下划线应起到类似区分前缀后缀和本体的作用：
<defName>XFMLI_BeautifulFlowerForYou</defName>
将每个单词首字母大写，删去单词间的空格，就成了驼峰命名法。其中首字母大写的为：“大驼峰”，我们使用这种。
首字母小写的为“小驼峰”，大多数的数据名均为这种类型，若制作时报错请检查拼写问题。
<label>flower</label>
<description>A flower for someone you love</description>
以上数据中，label为显示名，description为介绍，两者的填写没有绝对要求，可以使用空格、汉字、特殊字符，但不允许使用{} [] <>。这类文本数据在使用翻译包时将可以被替换，我们会在后面学到。这两种数据允许重名，在部分def中他它们甚至不会被调用。而在需要调用它们的def中，缺少它们将会导致报错。
补充一些没那么常用的
descriptionHyperlinks：一个List，元素有特殊的填写格式，<def的种类>defName</def的种类>，比如路西法合剂：
<descriptionHyperlinks>
<HediffDef>LuciferiumHigh</HediffDef>
<HediffDef>LuciferiumAddiction</HediffDef>
</descriptionHyperlinks>
游戏内效果

modExtensions：泰南注释：Mod-specific data. Not used by core game code.是一个List，作用是填写一些dll留给xml的接口。教程里不会使用这个东西。

我比较想知道贴图大小是怎么实现的，因为不会解包，导致我做的动物贴图替换只能改原版扩展mod

收藏了。

蹲个直播，之前想抄大佬机甲mod里关于无人机的相关代码，没看懂遂不了了之

基础篇 第七讲：翻译包文件
翻译包存放在Language文件夹内，并使用预设好的名字来区分语言。
以下是一些常用的语言的文件夹名：
ChineseSimplified 简体中文
ChineseTraditional 繁体中文
English 英语
Japanese 日语
Russian 俄语
一个翻译包分为两部分：对def内文本的翻译放入DefInjected文件夹，对dll内的翻译放入Keyed文件夹。对dll的翻译被称为Key，基本格式为：
<key>文本</key>
在整个游戏所有已启用的mod中不允许出现重复的key，否则排序靠后的将覆盖排序靠前的。
若游戏使用的语言所对应的翻译包中缺少对应的key，或者干脆没有对应的翻译包，那么会从English包中查找并使用。
由于我们目前不对程序，dll方面展开教学，Key的内容就到此为止，对于def的翻译是本章的主要部分。
与defs不同：
Defs区分一个def的类型是看它在数据库中出现时最外层的参数名，例如现在defs中有这样一个文件：
<?xml version="1.0" encoding="utf-8" ?>
<Defs>
<ThingDef ParentName=”XFMLI_ThingParentA”>
<defName>XFMLI_Flower</defName>
<label>flower</label>
<description>A beautiful flower</description>
</ThingDef>
</Defs>
第一行为识别码，所有xml文件的必需，在作为例子的这个thingdef中，我使用了父对象来省略其他必要的数据填写，这样一来我们就更能将注意力集中在这三项研究对象上。
我们注意到，defs中总是用一个参数名放在最外层来区分类型，显而易见的，此处的例子中的def类型为thingdef
而翻译包并不采用这种形式，在这里我们通过文件夹的命名来区分其中的翻译文件所对应的def类型。对于上文的例子，我们如果要制作翻译，那么应当将文件置于下图的文件夹中：
<?xml version="1.0" encoding="utf-8" ?>
<languages>
<XFMLI_Flower.label>花</XFMLI_Flower.label>
<XFMLI_Flower.description>一朵美丽的花</XFMLI_Flower.description>
</languages>
基本格式为：
<defName.数据路径>翻译文本</defName.数据路径>
其中defname为你要翻译的def的defname。
数据路径指的是从整个数据体最外层向里依次拆分复合数据直到到达翻译对象。一个文本的基本数据每级的参数名之间用小数点连接，再举一例：
<数据体>
<defName>X</defName>
<复合A>
<复合B>
<基本C>this.</基本C>
</复合B>
</复合A>
</数据体>
其对应翻译为：
<x.复合A.复合B.基本C>这个。</x.复合A.复合B.基本C>
特别的在于list型复合数据，因为它拆分后是多个元素。也就是li。我们当然不能在路径中使用li，而应当使用索引器：用一个从0开始依次增加1的整数来依次指代元素。注意其从0开始数意味着第一个元素为0，第二个为1，依此类推。
如：
<list>
<li>A</li>
</list>
即为<list.0>A</list.0>
而除此之外，其实还有其他对list的元素的索引方式，如

翻译文件直接用label来索引，注意索引到的是元素本身，所以依然需要一个label来指向其名字文本数据。

在comps中，也常直接用Class名来指代，当然也可以用comps.0来指代。

值得注意的是，对于父对象的翻译不会作用于子对象上，也就是说，即使子对象在继承后拥有与父对象完全相同的一个文本数据，你仍然要对它们分别翻译，而一个abstract=”true”的数据体其中的任何数据都是不允许被翻译的——当然，在正常情况下这种数据体也不存在defname。
除此之外，原文本中若出现形如 {n}（n为整数）或 “TargetX”（X为大写字母）等，则需要保留他们在翻译文本中。
<stringA>Use this by TargetA.</stringA>
<stringB>The number is {0}.</stringB>
对应的翻译为
<stringA>让 TargetA使用这个。</stringA>
<stringB>数字是{0}。</stringB>
你可以自行安排它们在文本中的位置，在该文本实际出现在游戏中时，它们会自动被程序替换为其他东西。
如果一个def没有找到对应的翻译，将直接使用def中的文本，而不是English翻译包。因此我鼓励大家在制作时以英文书写def中的文本，再用中文翻译来完成中文文本。