[CT]开发日志

QQ酱208628 发表于 2023-6-7 10:34
模型？高版本不都是Json控制了咩（
你是说DataGenerator那些咩？如果是完全用工厂生成器产出物品的话就只 ...

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

GTCEu/GTI是把模型生成写在代码里了，就像低版本一样（反正models里面是空的）。而我对这类逻辑一窍不通（又不愿意翻那些绕得像意大利面一样的代码），更何况除了Wiki上基础的教程之外就没有教程了……

InkSoul 发表于 2023-6-7 10:26
啊？我当时竟然没有注意到Client？
（好吧，那是我眼睛的问题了）
但模型生成怎么解决

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

QQ酱208628 发表于 2023-6-7 10:22
为什么注册发生在客户端启动事件里... 以及注册物品至少是服务端上x
客户端概念是游戏的两个线程中的主线 ...

啊？我当时竟然没有注意到Client？
（好吧，那是我眼睛的问题了）
但模型生成怎么解决
（模型渲染是更大的问题，目前除了GT之类的项目就没人敢去碰这个了【反正我只在GT中见到过这样的代码，其他一律用的是datagen】）

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

为什么注册发生在客户端启动事件里... 以及注册物品至少是服务端上x
客户端概念是游戏的两个线程中的主线程，加入世界的时候会开始分主线程客户端和子线程服务端，而Forge的注册发生在游戏启动的时候... 在Minecraft 1.7.10的时候确实是用FMLInitializationEvent系的事件来呼叫启动注册，但是高版本会直接实例化@Mod注解的类，直接分那个@Mod类的构造方法里注册就好。

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())
    );
}

反正行不通。

InkSoul 发表于 2023-6-7 09:56
但我不会整啊……
最开始的确是因为Forge的问题，但现在似乎是能不能完成的问题了……
Fabric的香草注册方 ...

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

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

QQ酱208628 发表于 2023-6-7 09:38
优先考虑能跑就行肯定是坏的，过分的语法糖和根本不用语法糖只会增加阅读难度，语法糖不细化也会导致很多 ...

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

（根本原因就是不会写像GTI/GTCEu那样的模型生成，而datagen一堆文件又太浪费内存【材料一多起来就直接完蛋】，所以就想到把所有物品叠在一个物品上用元数据区分然后一个BlockEntityWithoutLevelRenderer搞定）

InkSoul 发表于 2023-6-5 23:48
由于总所周知的Forge注册难问题，所以CT打算重新制作一个基于nbt的“数据值”系统。
这样不仅可以节约注册 ...

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

目前“元数据”的完成程度（渲染还没做）
虽然目前翻译键崩了（自己的问题）

CT打算像星系一样，先在Fabric/Quilt上制作一个可玩的版本再做对Forge的兼容调整。