MC百科社群

标题: [CT]开发日志 [打印本页]
作者: InkSoul    时间: 2023-5-24 14:31
标题: [CT]开发日志
本帖最后由 InkSoul 于 2023-7-5 23:15 编辑

CT=CraftTech，即寰缔科技。
一个受GT启发，但与GT不同甚至相反的科技Mod。
需要Arch-Api和ForgeConfigPort作为前置的Fabric/Quilt Mod【Forge支持已经从开发计划中删去了，欢迎fork】。
现在还处于较为初期的开发阶段，目前进度：

- 材料集系统：51%（代办：配方、标签）
- 机器系统：1%
- 世界生成：0%（不包含矿石生成修改）
- 配方 & 玩法设计：5%

源码仓库
（PS：由于GTI和GTCEu的相继移植；导致CT放弃了原定的开发计划，而是转而开发一个按照GT模式但与GT不同的科技Mod）

作者: InkSoul    时间: 2023-5-24 17:46
Gui Api-25%测试Gui Api...


作者: InkSoul    时间: 2023-5-24 19:37
Gui Api 25%

作者: InkSoul    时间: 2023-5-25 16:12
Gui概念图（“格”味十足）


（还有就是，Logo是CT而不是G）
作者: InkSoul    时间: 2023-5-25 17:02
本帖最后由 InkSoul 于 2023-5-25 17:03 编辑

目前计划中的方块/物品：
机器：


大型机器：



物品：



作者: InkSoul    时间: 2023-5-25 19:00
目前的打算：先做完大多数逻辑部分，再去修理渲染问题。
作者: InkSoul    时间: 2023-5-26 22:50
本帖最后由 InkSoul 于 2023-5-26 22:52 编辑

GT式洗矿测试（



作者: InkSoul    时间: 2023-5-28 14:20
把映射换成了Mojang的官方映射（主要是大多数可供参考的代码用的都是Mojang的映射，Yarn真的不方便...），将Porting-Lib（Forge API）以JiJ的方式做为前置）。

看到Forge API里有我需要的东西就直接拿来用了（

以及，修改了原版熔炉的燃烧时间类型，确保更长的燃烧时间不会溢出。
【MI就因为这个事情在注释里破口大骂香草（】

当然，不保证兼容性...

作者: InkSoul    时间: 2023-5-30 23:08
Machine和Pipe完成度 2%（完成了配方树和配方匹配）

其他：将洗矿做成了事件，并且将会发布一个独立的洗矿Api。
作者: InkSoul    时间: 2023-5-31 18:24
正在尝试将Washable移植成Architectury Mod，如果成功了，那么CraftTech也会随之跟进（将会变成三互通Mod——Forge/Fabric/Quilt？）。
作者: InkSoul    时间: 2023-6-3 08:09
目前打算将CT拆成多个小模块进行开发，到最后合并成一个（所以Washable之类的拆分出去是正常的）。
以及...由于种种问题，CT放弃了更加快速的内置渲染（主要是技术问题）。
所以CT的文件大小可能会被data占掉一大半...（事实上这也是完全没有办法的办法...除了原GT好像还真没人敢用...）
作者: InkSoul    时间: 2023-6-5 23:48
由于总所周知的Forge注册难问题，所以CT打算重新制作一个基于nbt的“数据值”系统。
这样不仅可以节约注册表空间，还可以省去一堆不必要的麻烦（需要注册好几个方块实体类型）。
（也就是说会出现/give @s crafttech:material.item 1 {MaterialSet:"golden", MaterialPart:"plate"}这种在高版本看起十分魔幻的东西）

【毕竟开发的第一铁律是能够运行，效率都是是后话了】
作者: InkSoul    时间: 2023-6-6 11:48
CT的材质集主要是按照GT的思路来写的（思路相同但实现不同），目前有如下字段：

MaterialForm即一个材质集中“物品”形式的对应形式（比如说：红宝石的物品形式单质是红宝石【宝石】、铁的物品形式单质是铁锭【固体锭】）

因为CT现在用了“元数据”……所以物品与物品的区别方式是nbt。
所以尝试获取一个不带nbt的材质部件是不安全的。

至于“元数据”的实现逻辑——
首先，需要数据区分的物品/方块必须要带有nbt（当然，你要乐意覆写原版的metaNbt读写也行，但CT不打算做此类危险操作），
CT中材质部件的两个“元数据”的标签是"MaterialSet"和"MaterialPart"（用于标记这个物品/方块是哪种材质的哪种部件）。

使用“元数据”还有以下几个好处：

只需要注册一些对应纹理的模型，然后用使用一个类（这不比挨个注册物品/方块模型好实现多了）进行渲染（只要我找到了渲染单个模型的方法）即可
理论上可能更节省运行内存（需要要加载的类的数量少了）
很多东西都可以直接写代码里（不用去为每一个物品/方块安排对应的模型）

坏处：

无法模块化（只能把全部的逻辑都堆在一个物品/方块上）
更加消耗运算资源（多了数道判断和获取数据的tick）
兼容性差（除非主动去兼容，否则与其他Mod的同类物品判断方法不通用【因为高版本其他Mod的物品判断实现大多都不考虑其是否附加数据】）
过时、被移除的接口（必须重新造轮子【虽然并不难】）
作者: InkSoul    时间: 2023-6-7 00:34
CT打算像星系一样，先在Fabric/Quilt上制作一个可玩的版本再做对Forge的兼容调整。
作者: InkSoul    时间: 2023-6-7 08:46
目前“元数据”的完成程度（渲染还没做）
虽然目前翻译键崩了（自己的问题）
作者: QQ酱208628    时间: 2023-6-7 09:38
InkSoul 发表于 2023-6-5 23:48
由于总所周知的Forge注册难问题，所以CT打算重新制作一个基于nbt的“数据值”系统。
这样不仅可以节约注册 ...

优先考虑能跑就行肯定是坏的，过分的语法糖和根本不用语法糖只会增加阅读难度，语法糖不细化也会导致很多细节问题。
高版本的Forge的延迟注册确实蛮烦的，但是也不是没办法做分类设计和生成器制造。每次提到生成器就有种ASM的冲动，或许真的越接近底层越有安全感罢（？
作者: InkSoul    时间: 2023-6-7 09:56
QQ酱208628 发表于 2023-6-7 09:38
优先考虑能跑就行肯定是坏的，过分的语法糖和根本不用语法糖只会增加阅读难度，语法糖不细化也会导致很多 ...

但我不会整啊……
最开始的确是因为Forge的问题，但现在似乎是能不能完成的问题了……
Fabric的香草注册方式好整，但Forge我真没什么办法（甚至都不知道该在什么时候注册，每次都因为注册器锁了失败）。
至少先整起来再优化吧，抛开实力谈技术力真的没有意义……

（根本原因就是不会写像GTI/GTCEu那样的模型生成，而datagen一堆文件又太浪费内存【材料一多起来就直接完蛋】，所以就想到把所有物品叠在一个物品上用元数据区分然后一个BlockEntityWithoutLevelRenderer搞定）
作者: QQ酱208628    时间: 2023-6-7 10:06
InkSoul 发表于 2023-6-7 09:56
但我不会整啊……
最开始的确是因为Forge的问题，但现在似乎是能不能完成的问题了……
Fabric的香草注册方 ...

保证你要注册的内容能够在ItemRegister被注册到总线前都在静态变量池中可用，不可以在注册到总线后再注册或者先注册ItemRegister再注册物品这样。换句话说就是因为这个注册是惰性的，只要静态池内可用且不提前调用基本上不太会有大问题这样...  最好的办法就是写到一个类里,会被统一申明。

Fabric的香草注册确实很棒，低版本上来完全没有不适应（

作者: InkSoul    时间: 2023-6-7 10:12
本帖最后由 InkSoul 于 2023-6-7 10:15 编辑
QQ酱208628 发表于 2023-6-7 10:06
保证你要注册的内容能够在ItemRegister被注册到总线前都在静态变量池中可用，不可以在注册到总线后再注册 ...

我当时的实现是这样的：public static final DeferredRegister<Block> MATERIAL_BLOCKS = DeferredRegister.create(ForgeRegistries.BLOCKS,
        CT_Main.MOD_ID);
public static final DeferredRegister<Item> MATERIAL_ITEMS = DeferredRegister.create(ForgeRegistries.ITEMS,
        CT_Main.MOD_ID);

public static void init(final FMLClientSetupEvent event) {
    for (var i : MaterialSet.materials) {
        for (var ii = 0; ii < i.regBlocks.size(); ii++) {
            var iii = ((MaterialBlock) i.regBlocks.get(ii));
            i.regBlocks.set(ii, MATERIAL_BLOCKS
                .register(iii.getMaterial().regName[0] + "_" + iii.getType().regName, () -> iii).get());
        }
        for (var ii = 0; ii < i.regItems.size(); ii++) {
            var iii = ((MaterialItem) i.regItems.get(ii));
            var reg = MATERIAL_ITEMS.register(iii.getMaterial().regName[0] + "_" + iii.getType().regName, () -> iii)
                .get();
            i.partItems.put((iii).getType(), reg);
            i.regItems.set(ii, reg);
        }
    }
    // 获取Mod事件总线
    IEventBus bus = FMLJavaModLoadingContext.get().getModEventBus();
    // 将物品与方块扔进总线
    MATERIAL_ITEMS.register(bus);
    MATERIAL_BLOCKS.register(bus);
}

public static List<MaterialSet> materials;
public static Map<Item, MaterialSet> vanilaItemMaterial = new HashMap<Item, MaterialSet>();
public static Map<Tag<Item>, MaterialSet> vanilaTagMaterial = new HashMap<Tag<Item>, MaterialSet>();

// ...

private static MaterialSet register(MaterialSet material){
    materials.add(material);
    return material;
}

public static final MaterialSet IRON;
public static final MaterialSet GOLD;

static {
    IRON = register(
        new MaterialSet("Iron", new Settings(0xffffff))
        .addPart(PartType.BLOCK, Blocks.IRON_BLOCK)
        .addPart(PartType.INGOT, Items.IRON_INGOT)
        .addPart(PartType.NUGGET, Items.IRON_NUGGET)
        .regPart(PartType.values())
    );
    GOLD = register(
        new MaterialSet("Gold", new Settings(0x0f0f0f))
        .addPart(PartType.BLOCK, Blocks.GOLD_BLOCK)
        .addPart(PartType.INGOT, Items.GOLD_INGOT)
        .addPart(PartType.NUGGET, Items.GOLD_NUGGET)
        .regPart(PartType.values())
    );
}

反正行不通。

作者: QQ酱208628    时间: 2023-6-7 10:22
InkSoul 发表于 2023-6-7 10:12
我当时的实现是这样的：public static final DeferredRegister MATERIAL_BLOCKS = DeferredRegister.creat ...

为什么注册发生在客户端启动事件里... 以及注册物品至少是服务端上x
客户端概念是游戏的两个线程中的主线程，加入世界的时候会开始分主线程客户端和子线程服务端，而Forge的注册发生在游戏启动的时候... 在Minecraft 1.7.10的时候确实是用FMLInitializationEvent系的事件来呼叫启动注册，但是高版本会直接实例化@Mod注解的类，直接分那个@Mod类的构造方法里注册就好。
作者: InkSoul    时间: 2023-6-7 10:26
本帖最后由 InkSoul 于 2023-6-7 10:32 编辑
QQ酱208628 发表于 2023-6-7 10:22
为什么注册发生在客户端启动事件里... 以及注册物品至少是服务端上x
客户端概念是游戏的两个线程中的主线 ...

啊？我当时竟然没有注意到Client？
（好吧，那是我眼睛的问题了）
但模型生成怎么解决
（模型渲染是更大的问题，目前除了GT之类的项目就没人敢去碰这个了【反正我只在GT中见到过这样的代码，其他一律用的是datagen】）
作者: QQ酱208628    时间: 2023-6-7 10:34
InkSoul 发表于 2023-6-7 10:26
啊？我当时竟然没有注意到Client？
（好吧，那是我眼睛的问题了）
但模型生成怎么解决

模型？高版本不都是Json控制了咩（
你是说DataGenerator那些咩？如果是完全用工厂生成器产出物品的话就只能考虑手写或者借助Gson+自己记物品名称来实现了（X
不然把要用的物品集合到一起通过Registry.getObject()一系列方法从注册表里拿到物品之后物品名放到一个CopyOnWriteArrayList + 多线程整理，用Gson一字排开保证拿到的名称的准确性后借助Gson自己写DataGenerator也不是不行就是了，除了怎么看都是曲线救国（逃
作者: InkSoul    时间: 2023-6-7 10:46
QQ酱208628 发表于 2023-6-7 10:34
模型？高版本不都是Json控制了咩（
你是说DataGenerator那些咩？如果是完全用工厂生成器产出物品的话就只 ...

但物品一多起来就要出事啊（可能整个Mod全是json贡献的大小【见CT的旧开发帖中的源代码，代码量不多，datagen的模型占了一半……】），
虽然现在CT可能并不需要那么多物品，但之后CT的附属需要啊……（需要贯穿整个整合包的内容）

GTCEu/GTI是把模型生成写在代码里了，就像低版本一样（反正models里面是空的）。而我对这类逻辑一窍不通（又不愿意翻那些绕得像意大利面一样的代码），更何况除了Wiki上基础的教程之外就没有教程了……
作者: QQ酱208628    时间: 2023-6-7 10:50
InkSoul 发表于 2023-6-7 10:46
但物品一多起来就要出事啊（可能整个Mod全是json贡献的大小【见CT的旧开发帖中的源代码，代码量不多，dat ...

这可没办法阿，食谱和物品贴图都得用Json管理x
模型还是建议Json吧，如果不是要做动画需求的话BlockBench的Json模型兼容性好
作者: InkSoul    时间: 2023-6-7 11:06
QQ酱208628 发表于 2023-6-7 10:50
这可没办法阿，食谱和物品贴图都得用Json管理x
模型还是建议Json吧，如果不是要做动画需求的话BlockBench ...

配方可以直接写代码里啊（参考迷之炖菜），原版也有模型是内置的啊（参考标准方块）……

如果没有办法解决这个问题的话，那还是用元数据吧（开倒车）……

（更何况我有移植GT6的想法【逻辑并不复杂，只是实现复杂罢了】）
作者: QQ酱208628    时间: 2023-6-7 11:38
InkSoul 发表于 2023-6-7 11:06
配方可以直接写代码里啊（参考迷之炖菜），原版也有模型是内置的啊（参考标准方块）……

如果没有办法解 ...

特殊合成食谱这种理论上会比用Json麻烦一些，但是可以做的事情也会多一些就是了。
如果设备的食谱也都写代码里的话只会给兼容性打折。
作者: InkSoul    时间: 2023-6-7 11:59
本帖最后由 InkSoul 于 2023-6-7 12:02 编辑
QQ酱208628 发表于 2023-6-7 11:38
特殊合成食谱这种理论上会比用Json麻烦一些，但是可以做的事情也会多一些就是了。
如果设备的食谱也都写 ...

Quilt有提供内置json配方的库，Fabric也有移植的RIP，Forge……。
虽然我本来就不打算兼容数据包（）
作者: QQ酱208628    时间: 2023-6-7 12:25
InkSoul 发表于 2023-6-7 11:59
Quilt有提供内置json配方的库，Fabric也有移植的RIP，Forge……。
虽然我本来就不打算兼容数据包（）
...

SpecialRecipe<IRecipe>, Forge的轮子是够用的
作者: InkSoul    时间: 2023-6-7 12:49
QQ酱208628 发表于 2023-6-7 12:25
SpecialRecipe, Forge的轮子是够用的

1.19.4好像没了，只找到一个net.minecraft.data.recipes.SpecialRecipeBuilder……（并且没有被调用过）
作者: QQ酱208628    时间: 2023-6-7 12:51
InkSoul 发表于 2023-6-7 12:49
1.19.4好像没了，只找到一个net.minecraft.data.recipes.SpecialRecipeBuilder……（并且没有被调用过） ...

看看https://www.mcmod.cn/class/2943.html的三明治的实现吧
作者: InkSoul    时间: 2023-6-7 12:57
本帖最后由 InkSoul 于 2023-6-7 12:58 编辑
QQ酱208628 发表于 2023-6-7 12:51
看看https://www.mcmod.cn/class/2943.html的三明治的实现吧

映射不一样啊……（他的映射是Yarn，我用的是Mojang……【之前纯Quilt版本为了用Porting-Lib改了映射，现在都是依赖Mojang映射，再改回去的话……】）
我猜net.minecraft.recipe.SpecialCraftingRecipe = net.minecraft.world.item.crafting.CustomRecipe？
作者: QQ酱208628    时间: 2023-6-7 13:02
InkSoul 发表于 2023-6-7 12:57
映射不一样啊……（他的映射是Yarn，我用的是Mojang……【之前纯Quilt版本为了用Porting-Lib改了映射，现 ...

可以逝世x
作者: InkSoul    时间: 2023-6-8 08:14
好像发现了什么：net.minecraft.client.renderer.ItemModelShaper中有一个register方法……


但我不知道这个ModelResourceLocation到底要怎么用（如果能用的话就可以废掉元数据了）

作者: InkSoul    时间: 2023-6-8 08:57
这个ModelResourceLocation是直接对应在资源目录中的文件（如new ModelResourceLocatio("minecraft", "trident", "inventory")对应原版的三叉戟模型，但我依然不清楚后面的字段是干什么的），
然后我发现了Model的加载总线……net.minecraft.client.resources.model.ModelManager（顺着ItemRenderer一步步点进去）
理论上来讲，我好像现在只要往上面扔模型就可以废掉元数据了……（是，好像白费了一番功夫）
但要废掉元数据还有待考虑，我可以先将需要渲染的模型扔进去，然后获取相应模型进行渲染（或者再激进些，直接现场new一个）。

只有确定所有实现都不成问题时才能废掉元数据，毕竟还有其他需要考虑的地方（恼人的注册【我不清楚如果注册一个类中的实例字段会发生什么，因为这样可能会导致注册逾期】）
作者: DTFuel    时间: 2023-6-8 12:56
InkSoul 发表于 2023-5-25 16:12
Gui概念图（“格”味十足）

草，一模一样（
作者: DTFuel    时间: 2023-6-8 12:58
InkSoul 发表于 2023-5-25 17:02
目前计划中的方块/物品：
机器：

要不神明之眼就来一个人造黑洞吧[doge]，用霍金辐射发电（
作者: InkSoul    时间: 2023-6-8 13:25
本帖最后由 InkSoul 于 2023-6-8 13:27 编辑
DTFuel 发表于 2023-6-8 12:58
要不神明之眼就来一个人造黑洞吧[doge]，用霍金辐射发电（

CT和GT的关系很微妙（是灵感来源，但CT 1的内容和GT5/6相差甚远【先做一个简单一点的试试水，不敢搞太复杂，不然我也不清楚什么时候能够完成】）

不过你这个提案……放CT2吧，神明之眼这个玩意并不科学，就一纯粹的魔法发电机（核心部件是神明晶眼）

CT 1只会包含4个电压等级和一些实用设备（GT最大的欠缺，有也贵死），看起来像IC2（虽然CT 1电压等级只有4但材料不会少），而更多GT风的内容安排在CT 2。
作者: QQ酱119280    时间: 2023-6-8 16:32
InkSoul 发表于 2023-6-7 12:57
映射不一样啊……（他的映射是Yarn，我用的是Mojang……【之前纯Quilt版本为了用Porting-Lib改了映射，现 ...

Mapping不同可以试试Linkie Shedaniel的一个工具网站 有跨映射表翻译器
作者: InkSoul    时间: 2023-6-8 17:35
QQ酱119280 发表于 2023-6-8 16:32
Mapping不同可以试试Linkie Shedaniel的一个工具网站 有跨映射表翻译器

谢谢，不过已经我猜对了。
作者: QQ酱208628    时间: 2023-6-8 20:07
InkSoul 发表于 2023-6-8 08:14
好像发现了什么：net.minecraft.client.renderer.ItemModelShaper中有一个register方法……

很显然这是用于烘焙模型的，如果你希望用它取代自拟的元数据... 你定制这些元数据不是用来批量注册物品的咩？这和渲染模型没有任何关系吧，以及为物品添加模型是可以直接使用json的，就像方块一样。渲染Obj的话貌似是只能方块？没试过在物品中渲染为Obj。


作者: InkSoul    时间: 2023-6-8 20:27
本帖最后由 InkSoul 于 2023-6-8 20:29 编辑
QQ酱208628 发表于 2023-6-8 20:07
很显然这是用于烘焙模型的，如果你希望用它取代自拟的元数据... 你定制这些元数据不是用来批量注册物品的 ...

……

我现在的思路是：

在代码里生成JsonObject（把所有Material部件的纹理全部注册一个独立模型，因为我找不到动态上纹理的方法，只能从Json模型入手）->直接Mixin扔进注册器->需要时按照MaterialPart的值抽取对应的部件模型进行渲染。

理论上讲应该只需要一个模型，因为唯一的区别是纹理不同，但我没有找到更改BakedModel附带纹理的方法。

也许我绕晕了。
作者: QQ酱208628    时间: 2023-6-8 20:32
InkSoul 发表于 2023-6-8 20:27
……

我现在的思路是：

重写BakedModel或直接渲染到手上，以及能简单就尽量不要绕。
作者: InkSoul    时间: 2023-6-8 20:34
本帖最后由 InkSoul 于 2023-6-8 20:43 编辑
QQ酱208628 发表于 2023-6-8 20:32
重写BakedModel或直接渲染到手上，以及能简单就尽量不要绕。

那要如何渲染一个带纹理的"builtin/generated"模型呢……？
我也没找到直接渲染单个模型的方法啊……

欸，等等……

那如果我预先注册带Json模型的空物品（就是用来占位的模型物品，没有任何作用），然后直接调用ItemRenderer渲染会怎样？

那我是不是只要把所有纹理用对应注册的模型物品托管起来就可以在动态的时候更换模型了？
作者: InkSoul    时间: 2023-6-9 00:28
目前已经确定了会用注册（单纯用来获取模型的）占位模型物品的方式来进行MaterialPartItem的渲染（ItemRenderer可以通过Item寻找模型，因为我没有办法直接获取一个模型【TODO】）。

总感觉这样做蛮危险的（允许获得不应该出现的错误物品）……但，我确实没别的办法。碰到渲染层就晕的我的确不能过头（）
作者: yjy_yzbsx    时间: 2023-6-9 12:00
mcmod→搜索CT→无结果
作者: InkSoul    时间: 2023-6-9 12:21
本帖最后由 InkSoul 于 2023-6-13 18:38 编辑

（撤回）
作者: InkSoul    时间: 2023-6-9 12:26
本帖最后由 InkSoul 于 2023-6-13 18:38 编辑
yjy_yzbsx 发表于 2023-6-9 12:00
mcmod→搜索CT→无结果

（撤回）
作者: InkSoul    时间: 2023-6-10 20:54
InkSoul 发表于 2023-6-8 20:34
那要如何渲染一个带纹理的"builtin/generated"模型呢……？
我也没找到直接渲染单个模型的方法啊……

等等……我找到了能直接渲染一个模型的方法
作者: InkSoul    时间: 2023-6-11 12:49
1.20 Port完成，删除了MaterialSet的Material属性（1.20弃用了好像）。
作者: InkSoul    时间: 2023-6-11 14:01
内置的默认物品模型似乎和这个类有关：net.minecraft.client.renderer.block.model.ItemModelGenerator。
作者: QQ酱119280    时间: 2023-6-11 16:41
每次看到了都很难不点进来（虽然我也在写自己的GT5R就是了）
作者: InkSoul    时间: 2023-6-11 18:21
本帖最后由 InkSoul 于 2023-6-11 18:23 编辑


------
新的Logo（之前一个C和T拼在一起太像G了）。
（把右侧的拉丁字母T换成了克菲字母T）

作者: InkSoul    时间: 2023-6-11 22:06
Mojang的谜之类名……
BlockModel竟然是所有Json模型的父类（包括Item），
搞不懂Mojang当时是怎么想出来的（Yarn在命名方面就处理的不错：JsonUnbakedModel）
【没什么，单纯觉得Mojang的命名很奇怪】
作者: QQ酱208628    时间: 2023-6-12 12:54
InkSoul 发表于 2023-6-11 22:06
Mojang的谜之类名……
BlockModel竟然是所有Json模型的父类（包括Item），
搞不懂Mojang当时是怎么想出来的 ...

你知道的，Item也是可以兼容Json实现模型，基于一个预先准备好的工厂方法就好了。而这个渲染预先是为方块模型准备的，命名为BlockModel就好。JsonUnbakedModel更像是JsonBean,具体怎么理解也和开发者风格挂钩了。
作者: InkSoul    时间: 2023-6-13 21:15
修改了注册器，使用Architectury API提供的跨平台注册方式进行注册。
作者: InkSoul    时间: 2023-6-14 08:32
成功上传到Github。
不过现在有一个奇怪的问题（/give对元数据物品不起作用）：
latest.txt (47.08 KB, 下载次数: 0)



作者: InkSoul    时间: 2023-6-14 09:11
话说Minecraft是没有给物品分单独的纹理页吗？
所以我可以直接在TextureAtlas.LOCATION_BLOCKS页中获取物品纹理？
作者: InkSoul    时间: 2023-6-14 09:19
本帖最后由 InkSoul 于 2023-6-14 09:20 编辑


好像可以直接往BULITIN_MODELS中扔Json模型……？
不过至少我找到了如何将Json模型转换成BlockModel的方法。
也许我只需要注入一下，就可以建立一套更为安全与先进的材质集系统。
作者: InkSoul    时间: 2023-6-14 09:53
理论上应该可以废掉元数据了，不过保险起见还是先建一个分支。
作者: InkSoul    时间: 2023-6-14 16:16
【废弃内容：坩埚】生前影像（水日志）：
[bilibili]BV14X4y1b79F[/bilibili]

单纯说明一下，坩埚不在现CT 1的开发计划中。仅作为废弃内容（原生Fabric版CT最终进度）。
作者: InkSoul    时间: 2023-6-14 18:50
内挂模型完成，加载内置Json模型。
作者: InkSoul    时间: 2023-6-15 09:26
本帖最后由 InkSoul 于 2023-6-15 11:05 编辑



现在配方的Json入口也找到了（内置Json，既方便又快捷，直接扔进RecipeManager），
虽然可以本是可以百分百无Json的，但……
直接生成Json文件是最方便的（懒）
而且比起完全代码化的特殊配方而言，对CrT之类的魔改应该更加兼容（？）。

（不过工具倒是真没办法，不然就没法自带附魔了）
作者: InkSoul    时间: 2023-6-15 13:52
本帖最后由 InkSoul 于 2023-6-22 16:15 编辑

内置模型的方法已经当作教程传到百科了。

仓库。
作者: InkSoul    时间: 2023-6-22 00:49
InkSoul 发表于 2023-6-15 13:52
内置模型的方法已经当作教程传到百科了。

但由于我的时间不多了……所以……

二号仓库
作者: InkSoul    时间: 2023-6-22 16:17
本帖最后由 InkSoul 于 2023-6-22 16:18 编辑


如果使用了不适宜的工具，则无法挖掘某个方块。
这意味你将不再能徒手砍树（后面会修改原木的挖掘等级），也不能空手加连锁开山。
作者: InkSoul    时间: 2023-6-25 22:46
本帖最后由 InkSoul 于 2023-6-25 22:53 编辑

物品注册搞定（

由于使用的是Arch Api提供的方法，所以这个注册实现支持全平台（很赞）
虽然配方还没整，但基本完成了。



作者: MBYL_InkAndSoul    时间: 2023-7-2 14:57
活整的差不多了，回来继续更新（
高版本才是首要目标（
作者: MBYL_InkAndSoul    时间: 2023-7-2 23:39
注入成功！
配方也可以动态生成了（）

（虽然我添加的是一个空配方，但注入成功了）
作者: MBYL_InkAndSoul    时间: 2023-7-3 00:18
当文本出问题时：



“铁 板 锭”。
不知道为什么I18n不生效（）
作者: MBYL_InkAndSoul    时间: 2023-7-3 12:56
渲染钩子（
虽然我清楚render进程上的逻辑太多容易造成卡顿，
但我还是打算整（）
作者: MBYL_InkAndSoul    时间: 2023-7-3 13:18
真正意义上的元数据（）

作者: MBYL_InkAndSoul    时间: 2023-7-3 17:38
我可算调好把它调好了（）



（别问为什么有铁锭【】问的就是忘了禁用铁材质生成锭的flag【】）
作者: MBYL_InkAndSoul    时间: 2023-7-3 18:18


GT6同款材料物品页（
作者: MBYL_InkAndSoul    时间: 2023-7-3 22:47


着色
作者: MBYL_InkAndSoul    时间: 2023-7-3 22:56


更好的效果图（
作者: MBYL_InkAndSoul    时间: 2023-7-4 01:35
以后索性把更新内容挂B站上算了（）
[bilibili]BV1ss4y1k7N3[/bilibili]
作者: MBYL_InkAndSoul    时间: 2023-7-4 14:05
由于Forge的接口非常难用，所以Forge实现是最后考虑的。
并且意味着，Forge版本不受支持（不会刻意去修复任何兼容问题）。
Forge顶多只会让CT能勉强运行，不会有过多的可能性，
并且我也不打算修复任何因为Forge限制导致的问题。
作者: MBYL_InkAndSoul    时间: 2023-7-4 14:15
并且更令人窒息的是，Forge和Mojang一样喜欢乱改底层。
我甚至找不到能用的实现可以参考……
作者: MBYL_InkAndSoul    时间: 2023-7-5 21:53
虽然不知道会不会出问题，但机器的叠加层应该可以直接用BlockEntityRenderer叠一个模型上去。
偷工减料ProMax（）
作者: MBYL_InkAndSoul    时间: 2023-7-5 22:50
这样吧，因为CT的整合在Fabric上，所以CT不兼容Forge好像也没什么关系（）
反正会留一些方便兼容Forge的接口，具体内容由其他人实现去吧。
作者: MBYL_InkAndSoul    时间: 2023-7-6 01:22
拆分通用代码，组建CT-API
作者: MBYL_InkAndSoul    时间: 2023-7-6 12:04
拆分后的第一次测试，成功。顺带把材料的注册空间改成了CT-API（虽然CT-API并没有提供材料【】）


作者: MBYL_InkAndSoul    时间: 2023-7-8 12:03
修正版本号，摒弃冗余实现。
拆分与调整部分功能、方法以更好地“兼容”Forge（当然，跑不跑得起来我也不知道，因为Forge不受支持）。



欢迎光临 MC百科社群 (https://bbs.mcmod.cn/) MC百科|最大的MineCraft中文模组百科