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

 

 

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).

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?

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.

I found the commit from when it was added. Looks neat.

 

https://github.com/MinecraftForge/MinecraftForge/commit/7a843760444f99743dc07cdc99cf364f23398e74

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.

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.

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.

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)

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

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?

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.

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!

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).

Okay so just disregard them for now.

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:"

 

 

 

I've posted a bunch of the stuff I encountered when upgrading my mods from 1.8.x to 1.10.2 here: http://jabelarminecraft.blogspot.com/p/minecraft-forge-upgrading.html