在我的日常开发或课程项目中，我常常会把相关联的多个模块放在一个总仓库里来方便开发和推进。
例如在我的 Java 课程作业仓库 (java-courseworks) 里，除了有一些单独的课程作业目录外，
还有一个 practicum 目录，里面是一个完整的学生管理系统实训项目。
在完成后续的维护和展示过程中，我发现把实训项目和课程作业放在一起，虽然方便了初期的开发，但随着时间推移，出现了一些问题：

1. 记录复杂：查看 practicum 相关改动时会被其它目录提交干扰。
2. 边界模糊：实训项目与课程作业是两类资产，其实并不适合放在一起。
3. 发布困难：在其他大型项目中，一个模块想独立维护、打包、发布时，会受父仓库结构影响。
4. 演示麻烦：给他人演示时，单独仓库更易理解与上手。

因此，本次我们将要一步步实现：

• 将 practicum 拆到新目录并初始化独立 Git 仓库；
• 复原指定区间的历史提交（包含提交信息与时间）；
• 解除对父 POM 的依赖，使其可独立构建；
• 配置独立远程仓库地址并推送到 GitHub 。

开始操作

迁移前务必做好以下准备：

1. 确认源仓库工作区干净（避免混入无关改动）。
2. 确认目标目录不存在或可安全覆盖。
3. 确认提交区间正确（尤其是起止 commit）。
4. 准备本地工具：Git。

Step 1：从源仓库导出指定区间的补丁

我们需要先从源仓库导出仅 practicum 路径的补丁文件（保留提交顺序和元信息）。

1
2
3
4
5

$patchDir = "D:\@DEV\java-courseworks\.tmp_patches"
if (Test-Path $patchDir) { Remove-Item $patchDir -Recurse -Force }
New-Item -ItemType Directory -Path $patchDir | Out-Null

git -C "D:\@DEV\java-courseworks" --no-pager format-patch --binary --output-directory $patchDir 7b47ec1755525f05cd76683215dad5ed3585fe6d^..1effd2672b9a396db04668c0b1d9d89043f1aacd -- practicum

注意：这里的文件目录路径 D:\@DEV\java-courseworks、子目录名称 practicum 与 commit 区间均为示例，请根据实际情况替换为所需要数值。

其中，

• format-patch 会按提交生成补丁，保留作者、时间、提交说明；
• --binary 确保图片等二进制文件也可迁移；
• -- <子目录名称> 只提取目标子目录相关改动。

Step 2：创建独立仓库目录并初始化 Git

这里我选择在原仓库同级目录下创建 StudentUI 目录作为新仓库，并初始化 Git：

1
2
3

$target = "D:\@DEV\StudentUI"
New-Item -ItemType Directory -Path $target -Force | Out-Null
git -C $target init

Step 3：回放补丁并去掉子目录前缀

由于目标仓库希望将 practicum 内容作为根目录，需要把路径前缀剥离。这里使用 git am -p2：

1
2

$patches = Get-ChildItem "D:\@DEV\java-courseworks\.tmp_patches\*.patch" | Sort-Object Name | Select-Object -ExpandProperty FullName
git -C "D:\@DEV\StudentUI" am -p2 --committer-date-is-author-date $patches

其中，

• -p2：将 a/practicum/... 或 b/practicum/... 裁剪成 ...；
• --committer-date-is-author-date：使提交时间与作者时间保持一致，最大化还原历史。

Step 4：迁移后处理

此时已经成功迁移了历史提交，剩下的就是针对实际情况的一些后续处理了。

在本项目中，StudentUI 的 pom.xml 需要从“子模块”改为“独立项目”，简单修改一下 pom.xml 即可。

Step 5：配置新仓库远程地址

1
2

git -C "D:\@DEV\StudentUI" remote add origin "https://github.com/CarmJos/StudentUI"
git -C "D:\@DEV\StudentUI" --no-pager remote -v

若已存在 origin，使用 remote set-url 即可。

1

git -C "D:\@DEV\StudentUI" remote set-url origin "https://github.com/CarmJos/StudentUI"

Step 6：验证结果

1
2
3

git -C "D:\@DEV\StudentUI" --no-pager log --oneline --decorate --max-count=20

git -C "D:\@DEV\StudentUI" --no-pager status --short --branch

建议比对点：

• 提交顺序是否与源区间一致；
• 提交时间是否保留；
• 图片等资源是否完整；

Step 7：推送到远程仓库

1

git -C "D:\@DEV\StudentUI" push origin HEAD:main

Done! 现在 StudentUI 仓库已经成功迁移了 practicum 相关的历史提交，并且可以独立维护了。

欢迎参观 StudentUI 仓库，查看我本次迁移后的结果。

归纳总结

为了方便后续复用，这里总结一下核心步骤：

1. 导出补丁：git format-patch --binary --output-directory <补丁目录> <起始提交>^..<结束提交> -- <子目录>
2. 初始化新仓库：git init
3. 回放补丁：git am -p2 --committer-date-is-author-date <补丁目录>/*.patch
4. 配置远程：git remote add origin <远程地址>
5. 验证：查看日志、状态，确认历史与资源完整。

快速脚本

如果你只要一个可快速复刻的版本，只需替换以下命令中的路径、提交区间和远程地址即可：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

$srcParent = "D:\@DEV\java-courseworks"
$srcDir = "practicum"
$target = "D:\@DEV\StudentUI"
$patchDir = "D:\@DEV\java-courseworks\.tmp_patches"
$remoteUrl = "https://github.com/CarmJos/StudentUI"
$startCommit = "7b47ec1755525f05cd76683215dad5ed3585fe6d"
$endCommit = "1effd2672b9a396db04668c0b1d9d89043f1aacd"

if (Test-Path $patchDir) { Remove-Item $patchDir -Recurse -Force }
New-Item -ItemType Directory -Path $patchDir | Out-Null

git -C $srcParent --no-pager format-patch --binary --output-directory $patchDir $startCommit^..$endComit -- $srcDir

New-Item -ItemType Directory -Path $target -Force | Out-Null
git -C $target init

$patches = Get-ChildItem "$patchDir\*.patch" | Sort-Object Name | Select-Object -ExpandProperty FullName
git -C $target am -p2 --committer-date-is-author-date $patches

git -C $target remote add origin "$remoteUrl"

完成后别忘了手动进行后处理，并做一次日志与构建验证。

同时，我还将相关操作整合成了一个可复用的 Python 脚本，方便在类似场景下快速执行，
详见 git-dir-exporter 项目 (欢迎Star~) 。

FAQ（常见问题）

如果有其他问题，欢迎在评论区留言，我会持续更新这个 FAQ。

Q1：为什么这里选择 git format-patch + git am，而不是直接复制目录？

A： 直接复制目录只能拿到“当前快照”，拿不到历史；format-patch + am 可以逐条回放提交，保留提交说明、作者与时间，更适合教学、审计和后续追踪。

Q2：为什么不是用 git subtree split？

A： subtree split 也能完成子目录拆分，且会生成仅包含该子目录的新历史分支。本文选择 format-patch + am 的原因是：

• 更直观展示“迁移区间”和“提交回放”的过程；
• 方便在迁移中插入额外处理（例如路径裁剪、单独补一条 POM 解耦提交）；
• 对教学场景更友好，读者容易理解每一步在做什么。

如果你更偏向“一条命令出结果”，subtree split 也是可选方案。

Q3：git am -p2 里的 -p2 是怎么确定的？

A： 补丁路径通常是 a/practicum/... 与 b/practicum/...。需要去掉两层前缀（a/b + practicum），所以用 -p2
，最终让文件落在新仓库根目录。

Q4：回放补丁时提示冲突怎么办？

A： 常规处理流程：

1. 查看冲突文件并手工解决；
2. git add <冲突文件>；
3. git am --continue 继续回放。

如果发现本次迁移策略不对，可中止后重来：

1

git -C "D:\@DEV\StudentUI" am --abort

Q5：如何确认提交时间是否真的保留了？

A： 可以分别查看源仓库与新仓库日志并对比时间戳：

1
2

git -C "D:\@DEV\java-courseworks" --no-pager log --reverse --date=iso-strict --pretty=format:"%H|%ad|%cd|%s" 7b47ec1755525f05cd76683215dad5ed3585fe6d^..1effd2672b9a396db04668c0b1d9d89043f1aacd -- practicum
git -C "D:\@DEV\StudentUI" --no-pager log --reverse --date=iso-strict --pretty=format:"%H|%ad|%cd|%s"

那是个寻常的礼拜四，我偏就馋那一锅子裹着厚面糊、炸得金黄焦脆的死鸡肉，激情下单一份疯狂的肯德基。

外卖快到时，我恰好内急。便让骑手挂在门把手上。想着左右不过一会儿功夫，索性再洗个澡。水汽氤氲里，我还盘算着待会儿怎么大快朵颐。这一泡屎一个澡，前前后后不过二十分钟。

且等我擦干头发，趿拉着拖鞋，满心欢喜地拉开那扇沉甸甸的防盗门时——迎面只有楼道里的一阵穿堂冷风。

门把手光秃秃的，什么也没有。

没有炸鸡，没有纸袋，连一丝油星子味都没留下。我愣在原地，脚底板那股子凉意顺着瓷砖直往天灵盖上窜。莫不是被保洁阿姨当废纸篓给收了？可谁家好人把热腾腾的饭菜当垃圾？又或是被野猫叼了去？可那么大还封了口的袋子，岂是一只野猫能拖得动的？

急吼吼拨通了送餐小哥的电话，听筒那头全是呼呼的风声和电瓶车的喇叭响，人家早忙得脚不沾地了，哪管得了这等闲事。再联系肯德基餐厅，回话也是冷冰冰的客套，只说东西送到了，丢了，只能报警。

调查

好在门顶上安了个黑乎乎的摄像头。点开手机里的录像，短短的报警片段里，一个身着格子衫、戴着橘黄色头盔的影子，从电梯口滑过来，手腕一勾，提溜起我的“疯狂星期四”，转身便没入楼道的阴影里。

那一刻，心里头真是一股子无明业火腾地烧了起来。这身行头，分明也是个骑手！做着一样风里来雨里去的营生，却干这等偷鸡摸狗的勾当？我甚至趿拉着鞋，跑到上下两层楼去转了一遭，楼道里死寂死寂的，半个袋子的影儿也没见着。本打算联系物业调监控看看能不能找到这个人的身份信息，但细想要调取监控肯定是需要报警的，而报警又需要监控里能清晰地看到这个人的脸才能立案，所以就算报警了也不太可能有结果。

本想就这么算了，当是舍给饿鬼了罢。可那口气堵在胸口，上不去下不来的。

“不对，摄像头是有全天录像的！”我猛地反应过来，耐着性子，又再一点点往回倒腾监控的进度条。

• 17:19 分，穿黄衣的美团小哥把袋子妥妥当当地挂上了门把手。
• 17:26 分，监控里出现了一个身穿黑色衣服、批橙色马甲，戴头盔的人从电梯方向走过来，直接把外卖拿走了，然后迅速离开了。

服饰来看应该是淘宝闪购的骑手。此时其他可能性与排除，也可以确定并非是住户冒充外卖小哥来偷外卖的了。

我眯着眼，再往前倒了倒。17:25分，隔壁的门被敲得哐哐响，“外卖！”，又敲了三声，“外卖到了！” 且就在那光洁的瓷砖地反光里，隐隐约约晃过一抹橙色。

这事儿便全串起来了！

这贪嘴的贼，先是给隔壁送了一份外卖，回头等电梯的当口，一转眼瞅见了我门上挂着的肯德基，腹中的馋虫一作祟，便顺手牵羊了。

我去敲了隔壁的门。开门的大哥倒是个热心肠，一听这等奇事，眼睛都亮了。两人一合计，查了单子。大概下午五点，大哥点了附近的一家“瑞幸咖啡”，详情显示“商家自配送”，17:26分送达。

对上了！ 瑞幸的“自配送”一般都是由淘宝闪购负责配送的，而这个时间点又正好是那个身穿橙色马甲的骑手出现在监控里的时间点，所以基本上可以确定这个人就是偷我外卖的嫌疑人了。但是由于淘宝闪购的骑手信息在美团上无法显示，而平台上骑手的电话又是两次虚拟后的号码（淘宝闪购虚拟号提交到了美团上，美团又虚拟了一次），所以我无法直接联系到这个骑手。而商家呼叫骑手时肯定有骑手的身份信息，可以轻松找到对方。

那么，就是现在了！ 到了这份上，我反倒出奇的平静。我肯定是没有权利要求商家提供骑手的身份信息的，所以让我们有请伟大的人民警察吧！

断案

拨通110报了警，接线员简单了解过后，很快便有一位警官一位辅警上门了解情况。我向他们详细地说明了事情的经过，提供了监控录像和相关订单信息，随机做了笔录。此时距离外卖被偷差不多过去了一个小时。

警察前脚刚走，后脚便来了电话：“诶，诶你好。我们到商家这里拿到骑手信息了，看到骑手现在就在旁边的沙县，人已经逮到了。他自己也知道问题的严重性，意思是要和你沟通一下，方不方便加个微信你们沟通下呢？…”

加上微信的那一瞬，手机震了一下。跳出来个顶着非主流头像的男生，微信名为 “牛马大帝” 。

十九岁。

那人打过语音来，声音还带着点没褪干净的公鸭嗓，怯生生的，又透着点死猪不怕开水烫的滑头：“哥，不好意思拿了你门口的外卖，我错了。对不起哥。”

我没做声。听筒里只有他略显粗重的呼吸。

“我也不想这样啊，实在是饿了，咱们私了吧…”

我也不想把事情闹大，毕竟他还年轻，犯了错误也想要改正。他急忙补上一句：“那哥你给我个支付宝二维码吧，我微信没钱，我支付宝转账…”。

最后，那点可怜的饭钱，他竟是用花呗付过来的。我苦笑着多说了几句，劝他好自为之。

可警察大哥后来在电话里冷笑。

“这小子，是第三回了。”

后记

点开他那朋友圈，花花绿绿的，像是个万花筒。入眼便是张皱巴巴的“退学申请书”照片，往底下翻，全是些让人嘴巴发干的句子：

• “终于成为了小时候羡慕的大人，父母眼中的顶梁柱。”
• “成熟的男孩烟酒入喉，优质的男儿爱字当头。”
• …

在这座由钢筋水泥构筑的城市丛林里，从不乏如浮萍般漂泊的年轻人，我亦如此。
而仓促地合上书本，一头闯进光怪陆离的现实社会，为何口中只念叨着从短视频里拾来的 “江湖道义”，脑海里也只记得编织着兄弟结盟、快意恩仇的虚幻图景？渴望活得体面，渴望成为旁人眼中的 “顶梁柱”，却在生存的重压下，渐渐模糊了基本的价值底线。那句 “优质的男儿” 的自诩，倘若配上用花呗透支、甚至游走在规则边缘换来的一餐温饱，便成了一出令人心酸的荒诞剧 —— 没有嘲讽的余地，只剩无奈的喟叹 。

我看着手机上那笔退回来的款，只觉得手心里那一阵油腻腻的冷汗，怎么也擦不干净了。

一次配置，轻松读取！
一款简单便捷的通用配置文件加载、读取与更新工具，可自定义配置的格式。

项目地址: https://github.com/CarmJos/configured
我的Github账号地址: https://github.com/CarmJos

本视频解答了 BV1kM411X7uA 视频下一些常见的问题，并额外提供了部分建议。

CMakeList文件地址: https://github.com/CarmJos/CWorks
我的Github账号地址: https://github.com/CarmJos

国内访问文件可以尝试使用：cdn.jsdelivr.net/gh/CarmJos/CWorks@master/CMakeLists.txt

—[额外链接]——————————————————
JetBrains官网(中文): https://www.jetbrains.com/zh-cn/
CLion下载地址: https://www.jetbrains.com/zh-cn/clion/download/

优秀的C语言代码通常遵循通用的代码规范原则，以确保代码的可读性和一致性。

虽然这些规则不是强制性的，但遵循它们可以大大帮助保持代码的逻辑可读性和一致性，特别是在团队协作或大型项目中。
不同的项目或团队可能有自己的命名约定，所以最重要的是在一个项目或团队内保持一致性。

基本规范

1. 避免使用保留字和标准库命名:

   • 避免使用C语言的关键字（如 int, return, struct 等）作为变量名。
   • 同样，避免使用可能与标准库函数冲突的名称。

2. 使用简洁且具有描述性的名称:

   • 选择简洁且具有描述性的名称，使其能够清晰地表达变量或函数的用途。例如，使用 calculate_speed() 而不是 cs()。
   • 避免使用无意义的名称，如 a、qwq 或 foo。
   • 选择单词时，首先要保障“贴切”，即词能达意，其次再去考虑长短。
   • 尽量避免使用缩写，除非它们是通用的或广泛使用的。例如，str 代表字符串，len 代表长度。见 通用缩写。

3. 保持一致性：在同一项目或团队中保持文件命名的一致性非常重要。个人或团队内部应该商定并遵守统一的命名规范。

注1: 也有一种命名函数名的风格是 首字母小写,后面单词首字母大写,中间不用连接符, 比如 getMaxValue()。
而类名单词首字母大写不用分隔符,如 class MyDateClass；
类的成员数据和方法的首单词首字母小写后面的单词首字母大写 如 int superValue。

JAVA的代码风格就是大致如此。

特定情况

1. 文件命名

在C语言项目中，文件命名的规范有助于帮助构建项目的整体结构。以下是一些常见的文件命名规范：

1. 使用小写字母：文件名通常全部使用小写字母，以避免操作系统之间的兼容性问题（特别是在区分大小写的系统中）。
2. 使用下划线分隔：单词之间使用下划线（_）分隔，以提高可读性。例如：char_calc.c 或 data_processing.h。
3. 简洁且具描述性：文件名应简洁且能够清楚地描述文件内容。例如，如果文件包含一个实现链表功能的模块，则可以命名为 linked_list.c。
4. 区分头文件和源文件：
   • 源文件（.c 文件）：包含C语言的实现代码。例如：main.c, score_calc.c。
   • 头文件（.h 文件）：包含函数声明、宏定义和类型定义等。与源文件相关联，通常名称相似。例如：utils.h 用于存放工具方法。
5. 避免使用空格和特殊字符：避免在文件名中使用空格和特殊字符，如%, &, *等，因为它们可能导致在某些环境或命令行操作中出现问题。
6. 使用有意义的前缀或后缀：对于大型项目，可以使用前缀或后缀来指示文件属于哪个模块或子系统。例如，使用gui_button.c 来表示该文件为图形用户界面模块中的按钮相关代码。
7. 避免过长的文件名：虽然现代操作系统支持较长的文件名，但过长的文件名可能不便于管理、识别和调用。所以，尽量保持文件名长度合理。

2. 变量与常量

局部变量命名应当 全部使用小写字母，单词之间用下划线分隔 。
局部变量可以简短，因为它们的作用域有限。例如：

• int my_variable;
• void calculate_total();

全局变量应该更加谨慎命名，可以使用前缀以避免命名冲突，例如：

• int g_some_value = 10; 其中 g_ 为前缀，代表 GLOBAL，即全局。

对于常量，可以使用 const 关键字来定义，并采用 全大写下划线 风格例如：

• static const int DENOMINATIONS[] = { 2000, 1000 }; [实例]

而 i, j, k, m, n, x, y, z 等单字母变量普遍被用在索引、循环语句控制、数学函数等处。
这是一种约定俗成的习惯，但是在其他地方使用单字母变量是不被推荐的，且不应当滥用。

3. 方法与函数

针对于方法，我们一般采取 “动词_名词” 的命名方式，且应当 全部使用小写字母，单词之间用下划线分隔 ，例如：

• int get_file();
• int calculate_total();
• int get_max_value();
• int is_valid();

其中“动词” 通常用于表示方法的操作，例如 calculate_total() 计算总数，
“名词” 通常用于表示方法的返回值类型，例如 get_max_value() 返回一个最大值。
该部分是可选的，比如 有些方法不需要返回值，或者返回的内容已经隐藏在动词方法名或模块名中。

4. 类型与结构体

自定义类型（如结构体和联合体）通常使用大驼峰式或全大写下划线风格。例如：

• typedef struct { ... } MyStruct;
• typedef struct { ... } MY_STRUCT;

5. 宏变量与枚举

宏常量和枚举通常全部使用大写字母，单词之间用下划线分隔。这样做是为了与普通变量和函数区分开。例如：

• #define MAX_LENGTH 100
• enum { RED, GREEN, BLUE };

常见操作单词

• add/remove
• begin/end
• create/destroy
• insert/delete
• first/last
• get/release
• increment/decrement
• put/get
• add/delete
• lock/unlock
• open/close
• min/max
• old/new
• start/stop
• next/previous
• source/target
• show/hide
• send/receiver
• source/destination
• copy/paste
• up/down

通用缩写

这里是一些通用的缩写，选择性使用。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61

addition —> add
answer —> ans
array —> arr
average—>avg 
argument —> arg
buffer —> buff/buf
clock —> clk
calculate —> calc
column —> col
control —> ctrl
command —> cmd
compare —> cmp
configuration —> config/cfg
count —> cnt
define —> def
delete —> del
destination—>dst/dest
display—> disp
device —> dev
decode —> dec
division —> div
frequency—>freq
error —> err
environment —> env
encode —> enc
hexadecimal —> hex
header —> hdr
index —> idx
image —> img
initialize —> init
increment —> inc
length—>len
make —> mk
maximum —> max
message —> msg
minimum —> min
multiplication—>multi
memory—>mem
middle—>mid
number —> num
option—>opt
parameter —> para
previous —> prev
pointer —> ptr
register —> reg
receiver—>recv
return —> ret
result—>res
source —> src
stack—>stk
string—>str
subtraction—>sub
semaphore —> sem
statistic —> stat
synchronize —> sync
table —>tab
temp —> tmp
temporary—>tmp/temp
timestamp—>ts
value—>val
width—>wid

本视频适用于使用Jetbrains系开发软件的学生，指导如何申请独属于自己的Jetbrains教育授权，安心使用正版最新开发软件。

—[相关链接]——————————————————
JetBrains官网(中文): https://www.jetbrains.com/zh-cn/
教育授权申请表: https://www.jetbrains.com/shop/eform/students

关于我换掉希铁CFA读卡器入手Sony MRW-G2的这件事。

这一部应该是我这个地区第一个激活的手机。

红米干爆小米！

JetBrains 官网：https://www.jetbrains.com/
开源授权申请：https://www.jetbrains.com/opensource/

我的Github主页: https://github.com/CarmJos

那是哪一年的事？早记不大清了。 只晓得那天电视里正放着什么动画片，叽叽喳喳的声响里，一个小人儿正抱着根同自己半个身子差不多大的鸡腿，啃得满嘴冒油。

我那时人小，肚子里的馋虫却被这光景勾得乱窜，连呼吸里都像凭空生出了一股子肉香。我咽了口唾沫，转头便冲着屋外正忙着劈竹的爷爷嚷嚷：“爷爷，我也要吃大鸡腿！”
爷爷抬头瞥了我一眼，手也没停，也没言语，由着我这没头没脑的叫唤散在风里飘。

到了傍晚，天刚擦黑，饭桌上却突兀地多出个东西，温温的，裹在塑料袋里。

塑料袋摊在碗里，果木炭的焦香混着股浑厚的咸甜味，轰的一下便撞进了鼻腔。是一副红艳艳的烤鸭。那年月，孩孩童哪里懂得什么讲究，管它鸡腿鸭腿，能解馋就是顶好的。爷爷竟不知用了什么法子，那鸭腿被留得格外多。我迫不及待地，一把攥住那只肥大的鸭腿，指尖滑腻腻的，全是烤得焦脆的鸭皮渗出的亮油。我就这么一手举着鸭腿，一手猛扒着碗里的白米饭，腮帮子鼓得不像话。一家人挤在灯泡底下，看着我这狼狈的馋样，都“咯咯”地笑着…

这一晃，十年的水便流去了。

我早像个羽翼渐丰的野鸟，扑腾着飞出了那个青石板铺就的小镇。爷爷奶奶年岁大了，早搬到了楼房里住。长大的日子总是忙碌且生硬，钢筋水泥把人困得像个打转的陀螺，我竟鲜能挤出回家的空档。 可是呀，说来也怪，无论我哪日踏进那扇防盗门，无论外头是个什么季节光景，只要一落座，我的白瓷碗里，总安安稳稳地卧着一只酱红色、泛着肥软光泽的烤鸭腿。

奶奶端着碗从厨房走出来，笑眯眯的，眼角的褶子叠在一起，操着那口老南京话冲我念叨：

“乖乖，留的大鸭腿给你哎！南头斩的，你最欢喜吃个！”

我不做多想，左手夹起腿，大口吞咽，任由那股浓烈的酱香味在舌尖慢慢化开。恍惚间，竟又回到了十年前那个咋咋呼呼的傍晚。

南头，说的是驷马河的南面。从新房走，约莫十五里路。

关于用户体验

这其实是一种个人代码风格的选择，不同开发者的风格也大多不相同。在很早的时候，我和这位朋友一样，对于一个明明功能很简单的插件打包了许多类库这种事情感到十分可笑。但随着我接的各种小单子越来越多，接触的用户越来越多，我发现程序员思维在这里似乎并不适用。

其实这种问题只要做一个核心类库插件就全部解决了。但作为用户来说，相比于要额外安装一个依赖插件，我更喜欢开箱即用的感觉，而非安装一个插件需要额外安装许许多多杂七杂八的类库。举个例子，如果我想使用一个插件，需要额外安装作者的一个类库；如果要使用的插件来自于多个作者，岂不是需要额外安装许许多多的类库？

因此，作为一个插件覆盖面并不广泛的开发者，我选择每个插件都单独打包类库，而让用户无需对此焦虑。

关于高版本接口

这时候又有人想问“为何不使用高版本提供的依赖接口，直接让服务端下载依赖使用，从而减小插件的大小呢？”

其实理由已经出现在问题里了。没错，这个功能需要“高版本”。

相比于为了减小插件体积而使用这个功能，以导致只有高版本才可以使用，我更倾向于让一个插件能够覆盖到更多的版本，从而减少用户的选择成本。

让我们回到用户的视角，面对一个功能需求上很适合自己的插件，却因为版本过低而无法使用，而这的原因仅仅是开发者为了让插件看上去更“轻量化”去使用高版本的依赖接口从而失去了低版本用户的支持，我相信，这个时候用户更希望的是在自己的服务器也能用上这款插件，而不是我们需要的“轻量化”。

总结

总而言之，是否打包类库到插件纯属开发者的个人习惯。有的人喜欢“轻量”而自行挑选重要内容放到自己的插件中，有的人更爱“便捷”而一股脑全塞上，也有的人会为了“用户体验”而做出一点大小上的牺牲。

如果是三年前的我，我会强烈推荐你做一个“依赖库插件”，它能够很好的解决插件实际功能和大小不等的问题同时还能让这个插件在不同的服务器版本中得到支持；
但如果是现在的我，我会推荐你好好考虑，对于单个功能插件，在必要的情况下直接打包依赖库也完全没问题的：虽然需要在“轻量化”上做出一些牺牲，但可以让使用的用户得到更好的体验，在我看来这是一个更好的决定。

文章作者为 @CarmJos ，同时感谢 @nelson 帮助校对文章。

由于想开一个新坑，打算把项目通过Maven生成的的Javadoc使用 Github Actions 自动部署到同项目下 gh-pages 分支，作为该项目 Github Pages 的主页供其他人参考。

操作

1. 配置 Maven 生成JavaDoc

首先在项目的 pom.xml 中添加 Maven Javadoc Plugin ,依赖这个插件，我们可以自动生成JavaDoc。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

<plugins>
    <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-javadoc-plugin</artifactId>
        <version>3.2.0</version>
        <configuration>
            <classifier>javadoc</classifier>
            <detectJavaApiLink>true</detectJavaApiLink>
            <encoding>UTF-8</encoding>
            <charset>UTF-8</charset>
            <docencoding>UTF-8</docencoding>
            <!-- <locale>zh_CN</locale> 可选，使用中文的界面-->
        </configuration>
        <executions>
            <execution>
                <id>attach-javadocs</id>
                <goals>
                    <goal>jar</goal>
                </goals>
            </execution>
        </executions>
    </plugin>
<plugins>

设置过后，我们就可以输入 mvn javadoc:javadoc 命令生成该项目的Javadoc了，生成的路径一般在 target/site/apidoc/ 下。

2. 配置Github项目的Deploy Keys与Secrets

因为我们需要把Javadoc放到同项目下的gh-pages分支，因此在Actions中需要进行认证操作，才可以正常推送。

这里我们打算采用SSH进行推送，并通过 Deploy Keys 进行认证。

a. 生成 OpenSSH 密钥

我们可以访问 Generate SSH Keys Online 在线生成一个密钥。

点击后，在下方会生成对应的私钥(Private Key)与公钥(Public Key)，我们先记下。

b. 添加私钥到 Secrets

复制上一步得到的私钥，添加到项目的Secrets中。

名字(Name)填DEPLOY_PRI,数值(Value)填私钥内容

c. 添加公钥到 Deploy Keys

复制之前得到的公钥，添加到项目的Deploy Keys中。

名字(Title)可以随便填，我这里选择的是JAVADOC_DEPLOY，密钥(Key)填公钥内容。注意一定要勾选 “Allow write access“, 这样才可以被用于推送。

3. 配置 Github Actions

在项目下新建 .github/workflows/javadoc.yml 文件。这个文件会被自动识别为Github Actions配置文件。

内容如下

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72

name: Javadoc

on:
  # 支持手动触发构建
  workflow_dispatch:
  release:
    # 创建release的时候触发
    types: [ published ]
#  push: # 可选，在推送主分支时触发
#    branches:
#    - main
#    - master

jobs:
  apidoc-deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout the repo
        uses: actions/checkout@v2

      - name: Set up the Java JDK
        uses: actions/setup-java@v2
        with:
          java-version: '11'
          distribution: 'adopt'

      - name: Generate docs #生成Javadoc
        run: mvn javadoc:javadoc

      - name: Copy to Location # 复制Javadoc到一个新文件夹，便于进行git操作
        run: |
          rm -rf docs
          mkdir -vp docs
          cp -vrf target/site/apidocs/* docs/

      - name: Generate the sitemap # 可选，生成sitemap
        id: sitemap
        uses: cicirello/generate-sitemap@v1
        with:
          base-url-path: https://carmjos.github.io/userprefix
          path-to-root: docs

      - name: Configure Git # 配置Git
        env:
          DEPLOY_PRI: ${{secrets.DEPLOY_PRI}} # 这里就是刚刚配置的私钥了
          GIT_USERNAME: ${{ github.repository_owner }} #Github用户名，这里用了Actions自带的变量，也可以写死。
          GIT_EMAIL: ${{ github.repository_owner }}@user.github.com # 邮箱,可以写自己的邮箱。
        run: |
          sudo timedatectl set-timezone "Asia/Shanghai"
          mkdir -p ~/.ssh/
          echo "$DEPLOY_PRI" > ~/.ssh/id_rsa
          chmod 600 ~/.ssh/id_rsa
          ssh-keyscan github.com >> ~/.ssh/known_hosts
          git config --global user.name '$DEPLOY_PRI'
          git config --global user.email '$DEPLOY_PRI'


      - name: Commit documentation # 提交文档到Git仓库
        env:
          GIT_URL: "git@github.com:<USERNAME>/<PROJECT>.git" # 项目的地址，注意要用SSH格式的。
        run: |
          cd docs
          git init
          git remote add origin $GIT_URL
          git checkout -b gh-pages
          git add -A
          git commit -m "API Document generated."

      - name: Push javadocs # 推送
        run: |
          cd docs
          git push origin HEAD:gh-pages --force

随后，推送项目，在Actions界面找到该配置，手动触发一次。

等待其正常跑完，即可发现多了一个 gh-pages 分支。

4. 设置 Github Pages

在项目的Settings界面找到 Pages 一栏，选择 gh-pages 分支，点击 Save ，等待片刻即可访问 <用户名>.github.io/<项目名> 看到项目的Javadoc了。

参考文献

• < Github Actions Documentation >
• < Apache Maven Javadoc Plugin >
• < javadoc: publishing to github pages from a public repo >

一开始接触 Git 的时候，默认的分支名都为 master ，包括后续使用的时候也习惯于输入master进行各类操作。

而我最近发现，Github 与 Gitlab 都开始使用 main 取代原先的 master
作为项目的默认主分支了，这是为什么呢？

起源 - “Black Lives Matter”

自2020年六月起，由于“Black Lives Matter”抗议活动持续发酵，而计算机行业中对master与slave这两个词的使用引起了部分人的反感。

在抗议声起、社会动荡加剧之时，更多的人认为这些包含历史文化因素的词汇已经过时，且应当被替换，于是多个开源项目开始采取行动替换冒犯性的术语，其中包括
PHPUnit 和 Curl、OpenZFS 等。

不仅仅是master与slave,还有许多相关的词汇如whitelist与blacklist都被计划更改为allowList与denyList。

正如 ZDNet
所说，继续使用这些带有种族色彩的词汇可能会延长种族歧视。一些学者在 2018 年的期刊上写道，“这些术语不仅反映了种族主义文化，而且还强化、合法化和延续了它。”

而 LinkedIn 的软件工程师 Gabriel Csapo 也在 Twitter 上表示，他也正在提出更新 Microsoft 内部库的请求，并删除任何带有种族歧视色彩的短语。

行动

在此背景下，一位Twitter网友的提议，而这一提议得到了GitHub CEO的支持。

@Una Kravets
我很高兴将 GitHub 的默认分支结构从『master』改成『main』，我希望我们能和 @GitHub 一起以社区为单位来做这件事……
@Nat Friedman
这是个好主意！ 我们正在朝这方面进行改进了！

于是自 2020年10月1日 开始，Github上所有的新库便都开始以 main 命名，并开始逐渐的将原先master为主分支的库修改为以main
为主分支。

鉴于GitHub有4000多万用户、1亿多个存储库以及至少2800万个公共存储库，这是项艰巨的任务。
任何一个规划的失误都会导致Linux内核之类的项目代码无法访问。全球大批企业依赖Linux内核，一旦发生这类事件都可能引发灾难性的后果。

于是，GitHub又做了以下更改以确保万无一失：

• 更新了 GitHub.com
  以直接重定向master分支到新的默认分支！
• 更新了 Github Pages
  以支持从任一分支进行部署
• 添加了用户、组织与企业设定
  以设定默认的分支名与新项目的默认分支名。
  • 需要注意的是，这些设定同时在 GitHub.com
    与 GitHub API 生效。
  • Git 2.28 也添加了一个类似的设定
    init.defaultBranch。
• 我们让重命名已有分支更加方便快捷了

参与

如果还是习惯于使用 master 分支，那么大可不用更改继续使用下去。

若想要支持相关的行动，则可以跟随以下的操作将master分支无损迁移到main分支。

本地修改分支

1. 首先将master分支移到main分支下

   1	git branch -m master main

2. 随后将新命名的分支main推送到远程库中

   1	git push -u origin main

3. 再将HEAD指向main分支

   1	git symbolic-ref refs/remotes/origin/HEAD refs/remotes/origin/main

4. 最后删除远程库中旧的master分支即可

   1	git push origin --delete master

在 GitHub 上修改默认分支

用户、组织和企业可以在以下地址修改默认分支名。

• 用户 https://github.com/settings/repositories
• 组织所有者 https://github.com/organizations/<组织名>/settings/repository-defaults
• 企业管理员 https://github.com/enterprises/<企业名>/settings/member_privileges

参考文献

• < Github Renaming >
• < GitHub to replace ‘master’ with ‘main’ starting next month >
• < Why GitHub renamed its master branch to main >

自己在家里组了一个机柜，有多个服务器设备需要管理。看到 PiKVM 这个项目后觉得非常有趣，很快就搓了一个。

刚搓完的成品就直接固定在一块木板上，随后给木板打了几个孔，直接用螺丝固定在机柜上。
说真的，每次看到那个 PiKVM “板子”，我心里都发虚。虽然功能上完全满足了需求，但那几根红红绿绿的杜邦线在外头晃荡，怎么看也不太安全。

不行，这得改。

我手头刚好有一台创想三维的 CR-6 SE，但现在的我对 3D 设计的认知基本还停留在“画个方块”的水平。

既然有了这个需求，不如趁此机会，就自己设计一个外壳吧。

开始设计

最开始的设计是一个凹下去的盒子和一个盖板，直接把 PiKVM 的主板放在盒子里，然后直接盖上盖板。

然而这个设计的缺点是没有考虑到3D打印的局限性。

切片软件跳出“17小时”那个数字的时候，我就开始挠头了。我所持的是一台开放式的 FDM
打印机，所以在打印过程中很难保证能完全成功的打印一整个盒子，而且如果打印失败了，就只能重新打印整个盒子，浪费时间和材料。

于是我便将盒子的各个面设计成了单独的部件，这样即使某个部件打印失败了，也只需要重新打印那个部件就好了。
各个部件之间用方形点链接，这样就可以保证它们能够正确的对齐并牢固的连接在一起。

出稿，拆件，打印！

那天下午特别闷，房间里全是那种 PLA
耗材熔化后的甜腻味儿。设计的底板件的面积比较大，所以在打印过程中出现了翘边的问题。更绝的是，挤出机那边居然开始打滑，“哒、哒、哒”地干磨。我摸了一下挤出机的电机，烫得手指生疼。

原来是打印时间过长，电机过热，耗材全在里头软成烂泥了。

没办法，我翻出个不知道哪儿拆下来的旧散热片，用硅脂粘在在电机上。
又掏出个小风扇，直接对着电机吹，试图让它降温。虽然这个方法有点土，但至少确实有效了。

拿着失败件先对一下尺寸，才发现尺寸设计的也有误，空位无法完全对齐，而最终导致其他部件也都无法正确的安装在底板上。

修改，再试打印底板。空位确实是对上了，可惜仍然出现了翘边的问题。考虑到材料的浪费和时间的消耗… 将就着用吧。

随后就是剩余部件的打印了。一样的，打印，翘边，再打印，失败，再打印，炒面，打印……总之就是反复的失败和打印，直到最后所有部件都成功的打印出来了。

中途X轴的电机轴居然还断了，得亏还有备用的42步进电机，不然就只能等快递了。
要不然说 3D打印 的本质是修3D打印机呢(

剩下的就是喜闻乐见的最终组装了。由于之前设计的连接点比较牢固，所以组装起来还是比较顺利的。

成品还是不错的。虽然表面还有点拉丝，虽然有点寄出缺陷，虽然有点翘边，虽然一捏就容易变形…
但还是非常满意的。毕竟这是我第一次设计和打印3D模型，能成功的完成已经不错了。

思考与总结

回望这次从 0 到 1 的首次设计，收获远在成品之外：

1. 设计必须服务于工艺。
   在电脑里画出的精美模型，如果无视物理世界的重力、热缩和机械精度，那只能称之为“数字雕塑”。优秀的工程师应当提前在脑海中模拟打印机的每一个动作，根据设备特性去倒推零件的结构，这远比画图本身更重要。

2. 模块化是风险管理的必修课。
   整体式设计虽然美观，但在抗风险能力上极其脆弱。将复杂系统拆解为可替换、可重构的小模块，不仅适用于软件开发中的解耦，在物理制造中同样是节省成本、提高迭代效率的黄金法则。

3. 拥抱“不完美”的勇气。
   工程实践中没有绝对的完美。为了进度而妥协的微小翘边底板、为了强度而增加的粗糙加固筋，都是解决现实问题的勋章。完成优于完美，在不断的反馈循环中迭代，才是技术进化的唯一路径。

如今这机器仍然在我家机柜里默默地工作着，虽然外表看起来只是一个普通的塑料盒子，但它背后却凝聚了我无数次的尝试、失败和改进。这不仅仅是一个作品，更是我第一次3D设计与打印经历的见证。

个人一周使用心得。
视频为主观言论，仅对本人手上的这对耳机负责哦。

希望MIUI尽快更新放出入口叭，太难找了。

YourCraft Team 2021
YC小游戏① 966485310
YC小游戏② 973478638
————————————
该视频在决斗游戏内部测试中录制，该视频录制过程中没有任何动物收到伤害。

YourCraft Team 2021
YC小游戏① 966485310
YC小游戏② 973478638
————————————
该视频在决斗游戏内部测试中录制，该视频录制过程中没有任何动物收到伤害。

如果你想要这个软件的话，可以私信给我你的邮箱，我看到后会尽快发给你哦~

使用aliyun DDNS 支持A记录和AAAA记录，公网IPv6均可正常使用。

--- 2021年11月1日更新
项目最近重构了一次，并公开于github，喜欢的小伙伴可以star一下哦~

项目地址 https://github.com/CarmJos/AliDDNS-Updater
软件下载 https://github.com/CarmJos/AliDDNS-Updater/releases

您好！

一九年的七月二十日，我心血来潮，花了短短的一会时间制作了cn2b2t。令我意向不到的是，这小小的举动竟然引起了许多玩家的响应，让我们这群充满梦想与激情的开发者更有了一丝前进的动力。但有意经营管理经验不足，2020年7月17日，我们无奈的选择关服休整，让所有开发者回归学业，并尽力去打拼自己的未来。

我们不得不向您致歉，我们使大量的玩家失去了过往的汗水与记忆，也失去了部分游戏中的战友，这也令我们难以释怀。好在，还有您愿意从我们手中接走回忆的接力棒，我也相信您也会很好的保留这些美好的记忆，谢谢您。

同时我也须向您致歉，由于服务器数据保存不当，自2020年6月换新服后的数据难以读取，故我拷贝给予您的副本是较老的地图文件，还请您谅解。

Kar Network承载了我们数十位开发者、管理者的游戏梦，如今距关服已有三个月，回首过去，有喜悦，也有遗憾。喜悦在于拥有你们这些支持我们的玩家，遗憾则是我们没有为你们交出完美的答卷。我们会吸取过往的教训，总结成功的经验，并在不久的将来进行新的尝试。我们坚信，唯有用心与坚持，才能抓住新的机会。

我们一直在努力，我们希望您也实现自己梦想的道路上继续坚持。我相信，我们将会在不久的将来，以全新的姿态，与您再会。这条梦想之路，我们与您手牵手，共同前行。

望共勉！

后记

本项目代码已开源，见 cn2b2t-project(Github.com) 。如有需要可自取，希望能对社区有所帮助。

亲爱的玩家，大家好：

自 2015 年首次开服以来，Kar Network 已经陪伴大家五个春秋，得到了广大玩家的支持与厚爱。回顾开服以来我们和各位一起度过了无数个欢乐的日子，由衷的感激大家给予的支持与帮助！

由于运营不当，自2015年起遍入不敷出，至此已无法继续承担高额的维护费用。且由于现有所有服务环境(包括但不限于 服务管理器、开发站、服务器官网、服务器运行环境、构建开发环境)均基于本台主机，，这些环境所花费的金钱、时间和精力无法复制，无法还原，也就直接告示着未来的维护不再可能，我们在MineCraft的路上就此终结。

综上所述，Kar Network、MineCarl 及其附属、相关服务器将在2020年7月20日凌晨00:00停止服务。

借此机会，通知所有使用本团队运行环境的个体、团队，在关服前迁移所有相关数据，如关服后存在数据遗失问题，本团队概不负责，恳请谅解。

最后感谢您的陪伴，希望在往后的日子里能与您共同回忆这段美好时光。也希望能在我们未来开发的其他游戏中再次见到您的身影。

希望国内MineCraft的未来更加美好。若您还在寻找一个适合您的服务器，可以尝试访问 McLists.cn。

祝大家生活愉快。

服务器IP: Kar.RED
直播写的代码！

Kar Network ，中国专业原创MC游戏社区。
青春五年，永不落幕。
服务器地址 Kar.RED (移动 yd.kar.red，联通lt.kar.red)
服务器QQ群 106660674
服务器官网 https://www.kar.red/
-------------------------------------------------------------
制作者： Pinckus
素材来自服务器内玩家，均获得授权。

经过二次计算、润色与优化，kb 3.0正式推出！
这..这也太舒服了吧？？？
果然，多年开发，专业直击PVP领域，不愧是国内元老服务器。

服务器IP: Kar.red

该页面研究的是原版击退算法以及原版击退算法中的各值的作用。

通常我们在调整击退参数的时候，都是靠感觉去调的。Kar团队另辟蹊径，通过数据和代码的方式去理解和调整最合适的击退。为了贯彻我们决心做中国PVP服领头羊的理念，我们决定将我们的研究成果分享出去。

对于代码的分析

EntityLiving类

由于在nms中部分变量经过了混淆，所以只能通过猜测得出这些变量的意义。

在EntityLiving类中，玩家受到伤害时会触发damageEntity函数。

• d0为攻击者位置的X值减去受害者位置的X值，即为从受害者到攻击者的向量的X值。
• d1初始值为攻击者位置的Z值减去受害者位置的X值，即为从受害者到攻击者的向量的Z值。

我们把d0称为x，d1称为z，则

• 若x²+z²<0.0001，则将d1设为一个-1至1之间的随机值*(见下方)，再乘以0.01，同时将d0也进行一次这样的操作。
• 若x²+z²还是<0.0001，则再进行一次，直到不满足这个条件为止。

推测，这可能是两个玩家坐标一样或极度相近的时候，为防止产生0变量，生成一个随机的击退。为验证这个猜测，您可以tp一名玩家，此时您的坐标和这名玩家是一模一样的(其实会产生一点点差别)。接着打他一下，发现击退有时候不在您面前的方向，甚至有时候击退到身后去了。

*编个程统计一下这个随机数，进行100000000次(一亿次)模拟，发现其分布曲线是金字塔形。

它看起来大概是这样：

设该折线的方程为 y = f(x), x∈(-1, 1)
很明显，该随机变量X落在(-x, x),x∈(0, 1)的几率为

函数a中

其中的d0和d1即为上方所提的x和z
设一个变量f1为

即为该向量在水平面上投影的距离

1. 变量f2为0.4，我们把该值称为水平倍数，或者Horizontal
2. 将motX、motY、motZ分别除以2，我们把该值称为Friction
3. 接着将motX 减去 x / f1 \* f2
4. 将motY 加上 f2
5. 将motZ 减去 z / f1 \* f2
6. 如果motY大于0.4，则设为0.4(这就是原版击退100附魔也无法飞天只能击远的原因)。我们把该值称为VerticalLimit。

以上即为当受害者受到伤害时的原始击退算法。详细讲解请看下方对原版击退算法的理解。

EntityHuman类

接着在攻击者的算法中，再次对产生的击退做出修正。

在EntityHuman类中,攻击者攻击别人时，受害者会受到以下击退

其中，i为攻击者手上武器击退附魔的等级，若没有，则为0。
如果攻击者正在疾跑，则i再加1。
但是，在著名服务端mSpigot上，无论攻击者是否在疾跑，i的默认值都为1。

yaw是攻击者的朝向的yaw值(欧拉角警告)，是角度制，所以后面的乘以π除以180是转为弧度制。
entity.g(double motX, double motY, double motZ)函数为

意思为，该实体目前的速度向量加上这三个值，再把成员ai改为true。
回到上面的击退计算，其中MathHelper是一个优化的数学工具人工具类
于是，该操作可写为

完成这些操作后，攻击者的motX和motZ各自会乘以0.6。

由于我们平时在竞技场模式中并不会使用带击退附魔的东西当主武器，所以我们不考虑击退附魔。因此，我们只考虑i为0或1的情况。详细讲解请看下方对原版击退算法的理解
我们把上面的0.5i的0.5称为疾跑水平加成(SprintHorizontalBoost[SHB])，motY加的0.1称为疾跑竖直加成(SprintVerticalBoost[SVB])

猜测与实验

玩家的击退对于攻击者的朝向只跟攻击者的yaw值有关，也就是环顾四周时的方向、水平方向有关，和pitch，也就是上下朝向无关。无论攻击者从上往下还是从下往上攻击，击退的原始数值只跟攻击者的yaw值和攻击者与受害者在水平面上的投影的向量有关，接着才根据玩家是否疾跑、武器有无击退、是否对该数值进行进一步计算。
但是，如果攻击者既不在疾跑手上又没有击退附魔，则击退和yaw也无关。

为了证明这一点，在采用原版击退的情况下，我做了个实验。

先将敌人的坐标和自己的坐标精确控制在整数，以便计算。在所有条件都不变的情况下，攻击受害者，计算击退的大小。

重复3次实验发现，只要条件不变，每次击退都是一样的。

接下来，只改变攻击者的pitch值，其他条件不变。

使用不同的值重复多次实验，发现击退还是一样的。

那么我们只改变攻击者的yaw值，其他条件不变。

神奇的是，yaw值改变后，击退依然不变。

接着，我们给攻击者手上的剑加上击退属性，再进行测试。
同样只改变攻击者的pitch值，发现确实跟攻击者的pitch值无关。

只改变攻击者的yaw值，得出以下结果：

多次实验，发现每次结果都与上表相同。在攻击者手上附魔有击退效果时，击退与攻击者的yaw值有关。

我们多测试了如果是受害者yaw、pitch改变是否会影响击退，结果是受害者的朝向完全不影响击退，实验方式和上面差不多，篇幅原因，在此不列出实验详细过程。

测试攻击者疾跑对击退的影响，为了不改变坐标的值，写个插件欺骗服务器，攻击者在攻击时强制变成疾跑状态。测试结果是，疾跑状态攻击相当于手上拿着击退1的武器的效果。

因此我们可以推测，用击退1的武器疾跑着攻击对方，相当于行走状态或静止状态用击退2攻击对方一样。通过实验，证实了该推测。

我们再次推测，在击退与两个玩家的位置和攻击者的yaw值有关，且如果攻击者不在疾跑且手上武器没有击退附魔时，击退就只跟两名玩家的位置有关(除非去掉if(i>0)代码块使motY+0.1强制生效，许多服务端都有这样做)。

用同样的方式，进行以下测试：

• 测试攻击者与受害者所在位置存在高度差时，击退依然与上面一样，证明击退和高度差无关。
• 测试攻击者与受害者所在位置的距离不同时，击退依然和上面一样。
• 测试攻击者向受害者方向走动时攻击，击退依然和上面一样。
• 测试攻击者跳劈，发现无论是上升状态还是下降状态，击退依然和上面一样。

当受害者在空中时受到攻击，一般击退距离会更远。我们通过编写插件，使玩家站在地上(坐标和上面一样)时欺骗服务器玩家在空中，结果发现击退依然和上面一样。推测因为在空中，在掉落到地面之前有更长的时间在空中滑行，造成的更远击退的感觉。由于方块有Friction属性，也就是当玩家落到地面时速度会迅速降低，而空气的Friction比方块的要低，所以玩家在空中能被击退得更远。

各参数的作用

回到参数上，如果不对原版击退的算法做出改变的话，仅修改算法中的几个参数，我们通常用感觉去判断击退的变化。通过了解上方原版击退的算法后，我们就可以知道那些参数的作用了。

原始击退是指在原始计算中得到的motX、Y、Z的值。目前市面上很多击退插件是在最终击退值上乘以某倍数。

Friction

指在受害者受到攻击时，受到攻击前受害者的速度除以的值，一般大于1，这也是为什么它叫Friction(摩擦)的原因。如果该值等于1，那么此时玩家的速度将会加上击退赋予玩家的速度。如果小于1，则玩家的速度会变大再加上击退赋予玩家的速度。如果大于1，则玩家的速度会先缩短，再加上击退赋予玩家的速度。原版该值为2.0

Horizontal

指原始击退参数的motX、motZ减去值的倍数，原版为0.4

Vertical

指原始击退参数的motY加上的值，原版为0.4

SprintHorizontalBoost, SHB

指最终计算完毕的击退中的motX和motZ在攻击者水平面上所指位置(yaw值所对应位置)加上的，攻击者朝向的向量与x和z轴的投影距离，乘以击退附魔等级+若疾跑加一得到的倍数，再乘以的SHB，即原始数据再加上的击退距离的倍数，原版为0.5

SprintVerticalBoost, SVB

指最终计算完毕的击退中的motY再加上的值，原版为0.1

VerticalLimit

原始击退计算中，最高达到的motY，若超过这个值，则设为这个值。原版为0.4000000059604645

对原版击退算法的理解(硬核慎入)

注意，当玩家静止不动或者站在地面时，他的motY为-0.0784，虽然如此，玩家并没有往下掉，这可能是因为脚下有方块的时候就不往下掉，该值可能是为了制造重力。
这也可以说明，为什么Friction调到很小(如0.01)的时候攻击玩家几乎无击退，因为这时motY除以0.01会变成-7.84，强力压在地上，导致地面对玩家的摩擦力较大，使玩家难以移动。
如果玩家在水中踩到地面，该值为-0.02(也许是重力减去浮力？)

回到一开始，再次看到这个函数

首先受害者受到了攻击者的一次攻击。在计算击退之前，受害者目前的速度除以Friction以缩短目前的速度(见上方Friction)。通常该值只作用于玩家正在移动的过程中，比如疾跑或者正在被击退。如果玩家是静止的，那么motX和motZ都是0。
如果玩家是在下落状态，则motY是负值，如果这个时候玩家受到攻击，motY会缩小，下落速度会变慢，这也是玩家在空中掉落的过程中受到攻击时会顿一下的原因。

我们知道：

• d0为攻击者位置的X值减去受害者位置的X值，即为从受害者到攻击者的向量的X值。
• d1为攻击者位置的Z值减去受害者位置的X值，即为从受害者到攻击者的向量的Z值。
• f1为从受害者到攻击者的向量在水平面投影的长度。

因此将d0和d1都除以f1后，向量(d0/f1, d1/f1)的模为1。
我们可以把一个长度为1的向量称为单位向量，它通常只为了表示方向。我们将把向量除以它的模的过程称为标准化向量，通常我们在只需要表示向量的方向，长度不重要，且要求该向量模为1的时候这样做。
接着两个值再乘以f2，即乘以0.4，表示把向量乘以0.4，也就是说把向量的模改为 根号0.32 。此时，水平面上的击退原始数据就计算完毕了。

至于为什么motX和motZ是减去运算得出的数值，是因为上面算出来的向量是从受害者指向攻击者的向量，我们需要让受害者往后击退，而不是往攻击者飞过去，所以才是减去。

再看到竖直上的击退，直接是目前的motY加上f2。最后，如果motY超过一个限制值(每错，就是那个小数点后老长的)，就设为那个限制值。您可能会问，才加0.4可能会超过吗？确实会，因为上面说过，在受害者再一次受到伤害前，玩家是飞在空中的。如果是combo模式(即玩家受到攻击后的无敌时间很短)，受害者再一次受到攻击时motY还很大，除以Friction后可能依然很大，所以为防止玩家飞起来就设置了一个限制值。

再来看击退修正，

entity.g 这个函数可以理解为原速度加上目标速度，如
entity.g(1, 2, 3)就是entity.motX += 1; entity.motY += 2; entity.motZ += 3;
yaw * π / 180就是将玩家朝向的欧拉角yaw值(角度)转为弧度。
在MC中，yaw的范围是-180~179.9。
也就是说，这里的-sin(yaw * π / 180)和cos(yaw * π / 180)依然是生成一个模为1的矢量。为什么模为1？我们把yaw * π / 180设为θ，由sin²θ + cos²θ = 1可知，该向量模为1。
将该向量乘以i 再乘以0.5，即可得到水平上修正的向量。
其中，i默认为0，如果玩家在疾跑状态则+1，如果玩家手上的物品有击退附魔，则再+击退附魔等级。
最后，motY再加0.1。
在原版中，如果i>0，才会执行这段代码，如果i=0，则该代码不被执行，也就是说，motY也不会+0.1。
在著名服务端mSpigot上，由于i默认为1，且疾跑不影响i的值，所以该代码永远会被执行。
最后，把算到的击退交给事件触发器，由事件再次对向量进行更改(如果有的话)，最终将击退速度发送给客户端。

我们可以看到，在算击退原始数据时，击退的方向是以玩家间的位置关系决定的。而在修正的过程中，却由攻击者的yaw值决定。这是印证了上面的实验。所以，如果有个玩家开挂，拿着击退棒背对着打你(请使用不会转过头去打的祖宗级秒被ban外挂实验并关闭反作弊)，你并不会往后退反而往黑客的方向飞去，也是这个道理。

如何抄袭猜测某服务器的击退

如果该服务器的击退数值不是离散的(在相同情况下，击退总是相同，没有产生随机偏移)，且算法为MC原版算法，那么该服的击退数值将非常好猜。

如果击退数值是离散的，那么可以通过统计算出击退数值的分布，然后根据分布的情况模拟随机的数值。比如上方的Math.random() - Math.random()就是-11中呈金字塔形的分布，如果是Math.random()-0.5就是在`-0.50.5比较均匀的分布。除此之外，还有正态分布(new Random().nextGaussian();`)等常见分布方式。

我们需要的随机偏移一般不能太大，所以再乘以一个数如0.1缩小随机偏移量的范围。最后根据统计得出的分布规律猜测偏移的算法即可。

由于每次击退服务器只会给你发送一个速度矢量，不可能在击退的过程中持续修正你的速度(不然延迟高的话就会乱飘。速度给你造成的位移一般由客户端计算)。所以，我们只要得出在各种情况下每次服务器发来的击退赋予的速度即可反推击退数值。

为了方便获取击退数值，我特意写了一个mod来辅助您获取某服务器的击退。
版本: 1.8.9
请使用最新版本forge运行以保证兼容性(我们使用的forge版本是forge1.8.9-11.15.1.2318)
当然，别对该mod抱有太大期望，比如按f3会挡住啥的
链接: https://pan.baidu.com/s/11BJ3Rtw-4YTDXECzIXWzAg 提取码: 77f3

这个mod看起来是这样的：

什么？你被查端的时候因为这个太像挂端被封了？怪我咯

• Sprint: 你是否为疾跑状态
• Sneak: 你是否为潜行状态
• OnGround: 您是否站在地面
  • 站在地面，指是否落地并站在地面。
  • 如果玩家被击飞、或者跳跃，该值为false。
  • 不过，如果玩家是在飞行状态，即使他的坐标是贴合地面的，OnGround也一定为false。
• MotionX: 您的速度矢量的X值
• MotionY: 您的速度矢量的Y值
• MotionZ: 您的速度矢量的Z值
• Target: 您正在攻击的玩家的名字
• Distance: 您与您正在攻击的玩家的距离
• ShadowDistance: 您与您正在攻击的玩家的连线在水平面上的投影的距离
  • 为什么需要水平面上的投影的距离？如果您有看上方原版击退的算法的话，您就会明白，击退的y值是另算的，玩家之间的位置关系只会决定x和z，y几乎不受玩家间位置影响。
• TargetSprint: 您正在攻击的玩家是否为疾跑状态
• TargetSneak: 您正在攻击的玩家是否为潜行状态
• TargetOnGround: 您正在攻击的玩家是否站在地面

算法区别

你猜测kb的服务器的算法不一定是原版算法，所以当您暴力计算后没得出任何结果的话，您可以再分析总体数据的变化和产生数据对应的情况去猜测算法。即便算法不一定相同，但只要最终算出来的结果是一样的，您的击退和你在抄的服务器的击退就是一样的。

然后您可以写一个算法暴力算出误差小于0.0001的击退。

如何防止自己服的kb被盗

使最终计算出来的kb离散化，加上一些微小的随机的偏移，且使用的随机算法也是随机的(不然容易被使用统计方法算出随机算法)。总之，尽量在不影响kb总体感觉的情况下提高猜测kb的难度。

关于本文档

文档的主要研究者与作者: LSeng

文档编写参与者: CarmJos

作为 真 · 自主开发 服务器，咱的东西有点小问题正常，视频中出现的所有问题都已经被修复。

服务器ip:sea.privatemc.cn 版本1.7-1.14 (最好使用1.8进入)
开发用了大概200个小时吧23333，熬了几夜写的。

感谢内测元老们的支持~
服务器缺一位腐竹，我没时间管理呀233，如果这里有哪位dalao粉丝量大于5000，可以联系哦~

视频中所有使用外挂的都被VAC了。

我是Carm，和朋友三黑。

遇到对面暴力锁头，美其名曰“Skill！” 。

于是...我们这位大哥看不下去了。

“给你脸了？”

自行百度搜索俄语练习本应该就有了叭。
我知道我写字不好看，请弹幕大神和评论大神手下留情，谢谢。

只是为了表达发现新物品的喜悦，见识短浅，手下留情，谢谢。

如果有帮助到你也欢迎给个三连丫。

傻傻的写了一大堆字，嘿嘿↑。

江浦高级中学2019届合唱团纪念一二九合唱比赛录制。

感谢观看。
墨瓷目前由一群初中生、高中生与大学生维护，从使用他人插件到如今完全自主开发，已过六年。
服务器地址为 Mocimc.cn (MineCraft.net正版) 。
如果您是一位盗版玩家，也可以尝试使用“offline.mocimc.cn”进入。
请注意，我们有权拒绝为盗版玩家提供帮助，如果您有能力，请支持正版。
一切详情，尽在Wiki。
https://wiki.mocimc.cn/#!index.md
---------------------------------------------------------------------------
本宣传片由 小伊(IPlayForLover)、六神(668ms)制作，在此致谢。
---------------------------------------------------------------------------
更多墨瓷相关视频：
《【墨瓷】 决心做中国MC服务器领头羊。请君莫辞。【60FPS】》
https://www.bilibili.com/video/av26958593
《玩自己写的UHCMEETUP是一种什么样的感觉？ 》
https://www.bilibili.com/video/av59986485
----------------------------------------------------------------------------
由Glorstal与EX涛制作的墨瓷首曲电音已发布至网易云音乐。
《墨路》 (Progressive House（Edit）/Future House（Edit）)

作词： 杨子睿
Rap：杨子睿
混音后期： 卡姆姬

看到身边的人都是死扣才抠出来米粒，好难受哦。

感谢观看。墨瓷由私人组织制作，因此视频不含商业类型的推广。
服务器地址为 Mocimc.cn (MineCraft.net正版) 。
如果您是一位盗版玩家，也可以尝试使用“offline.mocimc.cn”进入。
请注意，我们有权拒绝为盗版玩家提供帮助，如果您有能力，请支持正版。
更多的消息，您可以访问我们的Wiki查看。
https://wiki.mocimc.cn/#!minecraft-network.md
----------------------------------------------------------------------------
视频制作总时长(包含拍摄与预处理) 约40小时。
仿照Ultra服务器风格，当然，很明显就可以看出这个视频残了。
由 科莫、冬花、Gkz 、KUMR 录制，晨暮进行AE预处理和后期，KUMR善后。
本视频授权多位UP主发布。
----------------------------------------------------------------------------
更多墨瓷相关视频：
《不好意思，我们开服务器的真的可以为所欲为的。》
https://www.bilibili.com/video/av23029607
《拉坯。墨瓷正努力着。 (墨瓷片头) 》
https://www.bilibili.com/video/av22705492
----------------------------------------------------------------------------
由Glorstal与EX涛制作的墨瓷首曲电音已发布至网易云音乐。
《墨路》 (Progressive House（Edit）/Future House（Edit）)

我开始怀疑我自己是托了。