Jump to content

So I am going back to Modding.


Chibill

Recommended Posts

1.8 to 1.10 isn't that big of a jump. There's a few changes, but they're much easier to handle than the changes from 1.7 to 1.8.

 

I highly recommend grabbing my EasyRegistry classes:

https://github.com/Draco18s/ReasonableRealism/blob/master/src/main/java/com/draco18s/hardlib/EasyRegistry.java

https://github.com/Draco18s/ReasonableRealism/blob/master/src/main/java/com/draco18s/hardlib/client/ClientEasyRegistry.java

(They are effectively CommonProxy and ClientProxy respectively, but handled by a library mod so several mods can utilize it without code duplication).

 

The methods must be called during preInit or things won't work properly (because blocks need to be registered during preInit and renderers have to be registered during preInit).

Apparently I'm a complete and utter jerk and come to this forum just like to make fun of people, be confrontational, and make your personal life miserable.  If you think this is the case, JUST REPORT ME.  Otherwise you're just going to get reported when you reply to my posts and point it out, because odds are, I was trying to be nice.

 

Exception: If you do not understand Java, I WILL NOT HELP YOU and your thread will get locked.

 

DO NOT PM ME WITH PROBLEMS. No help will be given.

Link to comment
Share on other sites

Okay also in the latest release notes I saw there where some new life cycle events added. (Or something like that) Any idea what that is/ they are?

 

I do not.

Apparently I'm a complete and utter jerk and come to this forum just like to make fun of people, be confrontational, and make your personal life miserable.  If you think this is the case, JUST REPORT ME.  Otherwise you're just going to get reported when you reply to my posts and point it out, because odds are, I was trying to be nice.

 

Exception: If you do not understand Java, I WILL NOT HELP YOU and your thread will get locked.

 

DO NOT PM ME WITH PROBLEMS. No help will be given.

Link to comment
Share on other sites

Okay also in the latest release notes I saw there where some new life cycle events added. (Or something like that) Any idea what that is/ they are?

 

RegistryEvent.Register<T>

is fired once for each registry type (e.g.

Block

,

Item

,

Biome

), this is when you should register your objects of that type.

 

ModelRegistryEvent

is fired on the client side when

ModelLoader

is ready to receive registrations, this is when you should register your item models and state mappers.

 

These are both fired before preInit, so you can only subscribe to them using static

@SubscribeEvent

methods in a class annotated with

@Mod.EventBusSubscriber

.

 

For examples of

RegistryEvent.Register

, look at my

ModBlocks

class or my other init classes. For an example of

ModelRegistryEvent

, look at my

ModModelManager

class.

Please don't PM me to ask for help. Asking your question in a public thread preserves it for people who are having the same problem in the future.

Link to comment
Share on other sites

Why are they fired before preInit? Is preInit no longer where you should check like if other mods your compatable with are loaded or get config info?

 

This is getting more confusing as I learn more.

 

I'm not entirely sure why they're fired before preInit; but they're fired right before it (see

Loader#preinitializeMods

), so you have access to all the same data as you would in preInit (excluding stuff from the preInit phases of other mods).

 

The configuration system is currently being reworked to be automatic and annotation-based, this commit added the initial pass. The config is read and the values injected at mod construction, before the registry events are fired.

Please don't PM me to ask for help. Asking your question in a public thread preserves it for people who are having the same problem in the future.

Link to comment
Share on other sites

So basically mod capability is currently harder then back in 1.8/1.7/1.6/1.5. And I will have to do all my file reading and stuff in the registry calls instead of preInit.... Seems really bad...

 

(I am working on a Mod that will load MC:PE add-ons)

Link to comment
Share on other sites

File reading?

You'll have to explain what it is you're doing.  You should be able to do them in preInit just fine. That event is just fired before preInit because that's when it becomes available.  You can still use it after the event

Apparently I'm a complete and utter jerk and come to this forum just like to make fun of people, be confrontational, and make your personal life miserable.  If you think this is the case, JUST REPORT ME.  Otherwise you're just going to get reported when you reply to my posts and point it out, because odds are, I was trying to be nice.

 

Exception: If you do not understand Java, I WILL NOT HELP YOU and your thread will get locked.

 

DO NOT PM ME WITH PROBLEMS. No help will be given.

Link to comment
Share on other sites

How? I don't think you can control when events are fired... (No way to delay it till after preInit)

 

Like if i had a json that defined what blocks to enable I would have to do that logic in the Event that you "Should" register blocks in.

 

Or should I disregard those and use the old way of doing it?

Link to comment
Share on other sites

Like if i had a json that defined what blocks to enable I would have to do that logic in the Event that you "Should" register blocks in.

 

Yeah that event is called preInit.

Apparently I'm a complete and utter jerk and come to this forum just like to make fun of people, be confrontational, and make your personal life miserable.  If you think this is the case, JUST REPORT ME.  Otherwise you're just going to get reported when you reply to my posts and point it out, because odds are, I was trying to be nice.

 

Exception: If you do not understand Java, I WILL NOT HELP YOU and your thread will get locked.

 

DO NOT PM ME WITH PROBLEMS. No help will be given.

Link to comment
Share on other sites

I know. That is how it was on 1.8 and before.

 

In 1.10 there are new events that have been added to Quote

Add in registry registration events, new subscription events you can use to make sure you're registering things at the "best" time.
Should I not care about those at all?

 

Also from the release post.

LifeCycle events: We have been for a while, and this is another step. Moving twards a data driven modding system. Modders PLEASE use these events to register anything to a registery. So we can keep track of what mod is doing what correctly. And so you can be sure you're doing it in the correct place! No more ambiguity over what events are for what!
Link to comment
Share on other sites

I haven't seen anyone using that event yet, so I don't know.

It seems to me that it's an extra "early" spot in case you need to do stuff before other mods start tossing stuff in during preInit (why, I am not sure).

Apparently I'm a complete and utter jerk and come to this forum just like to make fun of people, be confrontational, and make your personal life miserable.  If you think this is the case, JUST REPORT ME.  Otherwise you're just going to get reported when you reply to my posts and point it out, because odds are, I was trying to be nice.

 

Exception: If you do not understand Java, I WILL NOT HELP YOU and your thread will get locked.

 

DO NOT PM ME WITH PROBLEMS. No help will be given.

Link to comment
Share on other sites

I did some modding with forge back in 1.8. Anything I should know that changed between then and now?

 

Every ItemBlock is now explicit.

 

canConnect method is private.

 

Replace meshing with setCustomResourceLocation (and move it to preInit)

 

set and get RegistryName

 

For items, builtin/generated becomes item/generated

 

Some renderers were rewritten (again). Vertex buffer has a new xface.

 

Vanilla blockstates became more advanced, and some blocks' use of properties became more intelligent (I dropped a *lot* of code from custom walls).

 

Sound effects use a different server-side method. In general, playing sounds is more difficult because server-side impetus and client side rendering are more confusable than ever (the methods all look the same). You may now find yourself calling playEvent with a literal numeric constant (bad design).

 

In general, sounds have evolved from using just ResourceLocation to SoundEvent.

 

BlockDirectional now uses all 3 dimensions, so blocks that rotate on the Y axis need to extendBlockHorizontal.

 

item/generated is now good enough that mods don't need firsthand or thirdhand "display".

 

In blockstates json, resources now default to minecraft domain instead of modid. All custom resources need to be prefixed with "modid:"

 

 

 

The debugger is a powerful and necessary tool in any IDE, so learn how to use it. You'll be able to tell us more and get better help here if you investigate your runtime problems in the debugger before posting.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Announcements



  • Recently Browsing

    • No registered users viewing this page.
  • Posts

    • They were already updated, and just to double check I even did a cleanup and fresh update from that same page. I'm quite sure drivers are not the problem here. 
    • i tried downloading the drivers but it says no AMD graphics hardware has been detected    
    • Update your AMD/ATI drivers - get the drivers from their website - do not update via system  
    • As the title says i keep on crashing on forge 1.20.1 even without any mods downloaded, i have the latest drivers (nvidia) and vanilla minecraft works perfectly fine for me logs: https://pastebin.com/5UR01yG9
    • Hello everyone, I'm making this post to seek help for my modded block, It's a special block called FrozenBlock supposed to take the place of an old block, then after a set amount of ticks, it's supposed to revert its Block State, Entity, data... to the old block like this :  The problem I have is that the system breaks when handling multi blocks (I tried some fix but none of them worked) :  The bug I have identified is that the function "setOldBlockFields" in the item's "setFrozenBlock" function gets called once for the 1st block of multiblock getting frozen (as it should), but gets called a second time BEFORE creating the first FrozenBlock with the data of the 1st block, hence giving the same data to the two FrozenBlock :   Old Block Fields set BlockState : Block{minecraft:black_bed}[facing=east,occupied=false,part=head] BlockEntity : net.minecraft.world.level.block.entity.BedBlockEntity@73681674 BlockEntityData : id:"minecraft:bed",x:3,y:-60,z:-6} Old Block Fields set BlockState : Block{minecraft:black_bed}[facing=east,occupied=false,part=foot] BlockEntity : net.minecraft.world.level.block.entity.BedBlockEntity@6d1aa3da BlockEntityData : {id:"minecraft:bed",x:2,y:-60,z:-6} Frozen Block Entity set BlockState : Block{minecraft:black_bed}[facing=east,occupied=false,part=foot] BlockPos{x=3, y=-60, z=-6} BlockEntity : net.minecraft.world.level.block.entity.BedBlockEntity@6d1aa3da BlockEntityData : {id:"minecraft:bed",x:2,y:-60,z:-6} Frozen Block Entity set BlockState : Block{minecraft:black_bed}[facing=east,occupied=false,part=foot] BlockPos{x=2, y=-60, z=-6} BlockEntity : net.minecraft.world.level.block.entity.BedBlockEntity@6d1aa3da BlockEntityData : {id:"minecraft:bed",x:2,y:-60,z:-6} here is the code inside my custom "freeze" item :    @Override     public @NotNull InteractionResult useOn(@NotNull UseOnContext pContext) {         if (!pContext.getLevel().isClientSide() && pContext.getHand() == InteractionHand.MAIN_HAND) {             BlockPos blockPos = pContext.getClickedPos();             BlockPos secondBlockPos = getMultiblockPos(blockPos, pContext.getLevel().getBlockState(blockPos));             if (secondBlockPos != null) {                 createFrozenBlock(pContext, secondBlockPos);             }             createFrozenBlock(pContext, blockPos);             return InteractionResult.SUCCESS;         }         return super.useOn(pContext);     }     public static void createFrozenBlock(UseOnContext pContext, BlockPos blockPos) {         BlockState oldState = pContext.getLevel().getBlockState(blockPos);         BlockEntity oldBlockEntity = oldState.hasBlockEntity() ? pContext.getLevel().getBlockEntity(blockPos) : null;         CompoundTag oldBlockEntityData = oldState.hasBlockEntity() ? oldBlockEntity.serializeNBT() : null;         if (oldBlockEntity != null) {             pContext.getLevel().removeBlockEntity(blockPos);         }         BlockState FrozenBlock = setFrozenBlock(oldState, oldBlockEntity, oldBlockEntityData);         pContext.getLevel().setBlockAndUpdate(blockPos, FrozenBlock);     }     public static BlockState setFrozenBlock(BlockState blockState, @Nullable BlockEntity blockEntity, @Nullable CompoundTag blockEntityData) {         BlockState FrozenBlock = BlockRegister.FROZEN_BLOCK.get().defaultBlockState();         ((FrozenBlock) FrozenBlock.getBlock()).setOldBlockFields(blockState, blockEntity, blockEntityData);         return FrozenBlock;     }  
  • Topics

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.