Skip to content
This repository has been archived by the owner on Sep 7, 2024. It is now read-only.

wohaopa/ZeroPointLauncher

Repository files navigation

GTNH Launch

一个GTNH整合包的专用启动器,因为是早期开发阶段,内部识别名为:ZeroPointLaunch (zpl)

因为我不会拿JavaFx写UI,Qt我也写不好看。诚邀好心人帮忙写个UI,本启动器和FFmpeg类似,提供一个命令行前端。可以将指令直接发给core.jar,本启动器也支持文件下载等功能,只需要将交互任务给core.jar就好啦,只是差一个友好的前端交互UI。

zpl基于symlink技术,需要提供管理员权限。本程序完全开源每一行代码,除用于创建symlink外不会有其他任何越权行为!

有以下几个模块

1. 实例

为了实现版本管理及版本升级,zpl设计了一套类似MultiMC的实例机制,与之不同的是:zpl可以共享.miencraft文件夹下的所有内容(包括mods以及config)。

继承

实例之间允许继承,子实例可以在不改变父实例的情况下来修改父实例的属性(如添加/删除mod、修改config等)。实例继承链没有级数限制,子实例会覆盖父实例的同名文件夹/文件。如:我可以安装一个2.3.0的原版实例,在原版实例的基础上安装汉化实例,在汉化实例的基础上创建新实例来添加自己的私货。此时的继承链:原版->汉化->私货。当需要升级为2.3.3时只需要将私货实例的父实例修改为2.3.3汉化版本即可。

(.minecraft)运行文件夹

因为没有对forge进行修改,运行Minecraft依旧需要传统的.minecraft文件夹。每个实例的目录下都会存在一个.minecraft文件夹,对本文件夹的修改不会被子实例继承。

(image)镜像文件夹

该文件夹存放实例的绝大部分信息,可以被子实例继承。此文件夹会作为映射器的输入。

(version.json)实例信息

用于zpl识别读取实例信息的文件。可以在本文件夹中修改来控制mod的加载,同时也会被子实例继承。

2. 分享

一些用于多个实例之间共享文件/文件夹的设计,可以将存档放着于此。也可以将私货放置于此,但不建议怎么做,因为使用继承机制会更好。分享器目前还不支持自定义,以内置了4种分享器(Common:通用所有实例都会使用;Java8:以Java8启动时使用;Java17:以Java17启动时使用;HMCL:使用HMCL启动时使用)HMCL是一个临时的解决方案(我没写正版登录库下载等功能,这不是重点)

继承

分享器也可以继承,所有分享器都在实例执行映射之前执行。

3. 映射

可以根据一些固有规则和自定义规则将一个目录映射到另一个目录,将分享器与实例、子实例链接,也是zpl的核心。

image

作为提供源的目录,一般情况下会根据规则将目录映射到目标.miencraft文件夹。目录内存在一个zpl_margi_config.json文件用于控制映射。

固有映射规则

  1. 将image目录下的文件直接映射到目标文件夹(如:options.txt)
  2. 将image目录下的文件夹内的文件或文件夹直接映射到目标文件夹(如config下的所有内容)我称之为“二级共享”

自定义映射规则

  1. include: 强制使用某个实例的某个文件,其他实例的同名文件将被忽略。
  2. exclude: 排除某个实例的某个文件,其他实例的同名文件奖补受影响。特别的:名为当指定实例名为__zpl_all__时,将排除所有实例的该名文件。若只写实例名将排除整个实例。
  3. shareDir: 用于将原来“二级共享”的文件夹变成一级共享,级不再共享其子目录而直接共享本身(如:libraries在固有规则下将被共享子目录,当设置shareDir后将直接共享本身)

以上 include/exclude,只能控制本实例,shareDir只能控制本镜像。即:include/exclude可以对父实例的映射规则做出调整,而shareDir只能对本镜像文件夹做出调整,而且不可以对父实例的镜像文件夹做出调整。

映射规则的自由度初始设置的十分高,目前这样做是为了降低逻辑复杂度,防止发生逻辑bug。

因为性能以及设计的考量,共享只能选择文件或上层文件夹,在多数情况下,共享二级文件夹即可实现需要的效果。以上各种自定义规则也只能精确到二级目录,汉化等特别情况会补充对应目录的完整内容。

4. 差异

用于升级,迁移等操作。也遵守二级目录的原则

升级

检测两个版本中间的差异来整理需要的文件。将缺失的文件自动补全,将过期的文件自动排除,生成的新版本将会继承原版本。

迁移

检测指定的.miencraft与最原始的版本之间的差异来确定新加的私货,与升级类似,生成私货版本(继承自原版本)。也可以导出差异来手动制作新的实例。

5. 下载

内有多线程下载器,主要用于下载各种网络文件。(如:汉化文件)

下载mod

可以根据下载所有GTNH公开发表过的mod,只需要在version.json修改版本号即可,也可以查看某个mod所有版本。(有没有好心人制作依赖图)

下载GTNH

可以根据版本下载GTNH包,也可以自动下载汉化。

(底层没有设计)服务器自动更新

可以根据远程json来完成客户端的自动更新

6. 启动

启动器没有启动功能就很难受,根据底层设计,本启动器下的所有实例都可以同时启动(请不要同时进入共享的同一个存档)

Java8启动

使用Java8启动

Java17启动

使用Java17启动,无需特别配置,可以直接将Java8的实例用Java17启动。

7. 镜像

用于zpl镜像站生成的工具,instance.json,用于记录所有zpl支持自动下载安装的实例。可以使用实例名在线安装。(不受支持的版本可以提供zip包手动安装)

1. GTNH原始版本

生成加载的mod以及校验文件等:因为官方给的zip内的config并不是最新的,只能做如此操作。将会得到一个image文件夹和一个version.json文件,其中image内安装二级文件夹压缩一个zip的原则进行打包,如果缺失二级文件夹内的某一文件夹将会下载整个二级文件的压缩包。version主要包含文件校验以及加载的mod版本。

2. 汉化包

部分版本的汉化包需要特殊处理。这里将会存放汉化包的。

3. mods

存储所有公开的mod,以及部分版本的官方配置(没啥用)

8. 导出

导出你的实例

常见问题

Q1:如何迁移?

A1:安装你GTNH的最原始的版本的,使用差异来导出你实例,视情况来将需要的文件迁移至指定位置,mod建议新建实例,存档建议共享。

Q2:如何安装新mod/更新mod?

A2:如果是GTNH有的mod(可能来自未来版本、或者以及移除)可以直接在version.json内修改;如果是自己的mod,请视情况放入对应的image(可被继承)/.miencraft(不可继承)文件夹的mods文件夹。放sharer的对应位置也可以,但逻辑上不建议。

Q3:什么时候发布?

A3:什么时候开发完成吧,现在以及完成一半了(1,2,3)基本完成(4,5)也已过半。(6,7,8)还没规划(镜像站不是重点,但没有会很难受)

其他

因为我不是计算机专业的学生,并且最近很忙。启动器更新速度将会极其缓慢。 如果想参与启动器开发,可以在QQ群内联系我:初夏同学(2411829240)