Dynamic Item/Block ID System

[synquall]

Hello, people of the Minecraft Forge forums.

 

Recently, I compiled my own modpack, and apparently, some IDs clash with mods.

Before you say anything, yes I do know how to configure the mods to use different IDs, however, what about for those who don't?

 

Basically, what I'm trying to say is that Forge should revamp the Item ID distribution. Currently, the mods can select which item IDs to use. This may cause item ID clashes with other mods. What Forge should do is assign the IDs for the mods, instead of the mods coming with pre-assigned IDs.

 

For example, BuildCraft and Forestry.

 

Forestry overrides BuildCraft's Oil and Fuel Buckets, alongside with other items.

 

<---------------------------------------->

 

The main idea of implementation for the dynamic item/block ID system is this:

 

[*]Forge loads the mods.

[*]The mods tell Forge what items they have | Forge gets what items the mods have

[*]Forge compiles the items/blocks into a list.

[*]Forge gives the items/blocks an ID.

[*]Forge tells the mod(s) that X item/block has the ID Y

[*]Forge adds the items to the game.

 

<---------------------------------------->

 

1) Forge loads the mods.

[FML] Loading mods...
[FML] Loading BuildCraft...
[FML] Loading Forestry...
[FML] Loading IC2

 

2) The mods tell Forge what items they have | Forge gets what items the mods have

[FML] Getting 26 items from BuildCraft...
[FML] Getting 127 items from Forestry
[FML] Getting 54 items from IC2

 

3) Forge compiles the items/blocks into a list.

BuildCraft.item1
BuildCraft.item26
Forestry.item21
Forestry.item127
IC2.item19
IC2.item54

 

4) Forge gives the items/blocks an ID.

BuildCraft.item1 = 1001
BuildCraft.item26 = 1026
Forestry.item21 = 1047
Forestry.item127 = 1153
IC2.item19 = 1172
IC2.item54 = 1207

!Forge will automatically give items in the list an ID. Let's say BuildCraft has 26 items, the item IDs will start at 1001. So, 1001 - 1026 will be BuildCraft's item IDs, Forestry has 127 items. It will continue where the item IDs stopped. 1027 will be the starting of Forestry, and 1153 will be the end.!

 

5)Forge tells the mod(s) that X item/block has the ID Y.

 

6) Forge adds the items to the game.

 

Please take into consideration this humble suggestion of mine. I believe it will make a better world for the modders and players alike 

 

[move]THANK YOU~! ありがとうございます！Terima kasih! Gracias! Xie xie ni![/move]

[endershadow]

or Forge could implement a Block/Item ID clash detection system that lets you change it when you run the game. Then you just distribute the config files if you want to share worlds/make a mod pack instead of having problems if you add mods not already in the mod pack or it loads the mods in a different order.

[synquall]

Apparently, Forge already has this. I'm simply SUGGESTING Forge should add my idea.

And that is also what I'm doing now. Maybe you should read my post carefully.

 

Hello, people of the Minecraft Forge forums.

 

Recently, I compiled my own modpack, and apparently, some IDs clash with mods.

Before you say anything, yes I do know how to configure the mods to use different IDs, however, what about for those who don't?

 

Basically, what I'm trying to say is that Forge should revamp the Item ID distribution. Currently, the mods can select which item IDs to use. This may cause item ID clashes with other mods. What Forge should do is assign the IDs for the mods, instead of the mods coming with pre-assigned IDs.

 

For example, BuildCraft and Forestry.

 

Forestry overrides BuildCraft's Oil and Fuel Buckets, alongside with other items.

[endershadow]

I did read your post. but what if you add a mod that forge decides to load in between the mods that were already added. for example lets say you have mod a, b, and c. you first play with mod a and c so it loads a then c. then you decide to add mod b. because it would load the mods in alphabetical order, it would load a then b then c and the IDs would get messed up.

[luacs1998]

If the modder isn't stupid and uses config.getblock/getterrainblock/getitem there is a subset of conflict resolution.

[endershadow]

so your saying that forge itself puts the block IDs in the config file, but the modders don't change how they have their config stuff set up.

[RANKSHANK]

there are a few issues, one of the forge mods has stated before (I think Lex because I remember a response laden with sarcasm) but the issue then becomes.... less than intelligent modders whom hard code thier ids or not use forge(dirty modloader junkies) messing up the ID hiearcy.

then there is save handling, the changes values are bad, and not all chunks are loaded per session, so Thatcher mean the id coorelation would have to be saved per chunk, or load times would increase as all should be unloaded chunks are loaded, processed, and unloaded, and if a tile entity that holds a dynamically id'd item, how will you know to update that during processing. its a pain in the butt, but not much can be done about it...

I don't personally like forges config system(7 separate mods in my environment) so I built an annotation based configuration reader/writer (if any forge dev is interested ill toss some links, otherwise can't be bothered wasting time with setting up for a PR), so how do you account for lazy programmers like me? you cant, try the KD resolver, or make a mod that installs your cofigs from in the mod zip/jar if they don't exist