How do I get a unique blockID/itemID that no other mod is using?

I don't see it in the code anywhere...

 

 

There is no code to handle that.

There is a finite number of items and nothing prevents a mod from using them all.

In other words, there is no such thing as unique item id.

If you are looking for unused item id, you can check for

Item.itemsList[id] ==  null

.

You can also use Forge methods, like Configuration#getItem(args).

That's what I thought.

And therein lies the problem.

You see, FORGE PROMISED to make this problem go away about A YEAR AGO.

It was the reason that I selected forge for my modding platform.

It is/was one of the primary reasons that Forge exists.

WHY IS IT NOT FIXED?

 

Nothing personal here, and my comments are probably not directed at any of the nice folks

replying here... But FORGE as a whole, deserves this:

 

(close your eyes if this does not apply to you)

 

GET THE F*** OFF YOUR A**ES AND FIX THE G*DD*MNED PROBLEM!

 

(ok, open your eyes now)

 

It is NOT difficult.

I can do it in a day.

 

public int registerThisItem(Modname+itemname)

 

it returns a unique integer.

How?

It reads an itemIDs.cfg file in the World directory that the player is connecting to.

If it finds Modname_itemname in the file, then it returns the unique number that

was saved and associated with it. If it does not find that entry, it picks a new unique

number, assigns it, and writes it back into the config file.

Easy as shit.

 

You will have to change loading mods. Mods cannot be loaded until the user selects a World.

Why? Because each world has it's own set of unique item ids. Why? Because I want to be able

to take my world directory and copy it to a different machine with different mods, and still

have it run.

 

I'm sure MC will happily extend their block and item arrays a bit to make more room.

That's a no-brainer. But still, with thousands of mods out there, and a unique id for each

and every item, you're going to run out of ids. Easy problem. Check the desired mod list

vs the ids in the file, and remove the unneeded ids from the file automatically. Or give the

user a list of mods that have ids in the file and ask them which ones should be removed.

Either way, it does SOMETHING rather than just crash the game.

 

But why bother? What's all the fuss?

BECAUSE PLAYERS DON'T WANT TO HAVE TO LEARN JAVA JUST TO RESOLVE CONFLICTS

AND PLAY A FREAKING MOD! It's like telling my grandma she has to learn all about computer

security and viruses. Not gonna happen. IT MUST BE INVISIBLE.

Let's remember our target audience here. It's 10 year old boys, NOT computer experts.

It should all just work.

 

Live up to the @%$#!^%$#@&^%! promises you made to us modders/players a year ago,

and MAKE IT HAPPEN!!!!!

 

Yes. I am furious.

And you all deserve a good reaming.

 

I want automagic non-conflicting itemids and blockids.

No more excuses.

 

BECAUSE PLAYERS DON'T WANT TO HAVE TO LEARN JAVA JUST TO RESOLVE CONFLICTS

 

Because:

 

block {
    I:DeathCrystal=1574
    I:LifeCrystal=1573
    I:DenseFog=1572
    I:Fog=1571
}

 

Is totally Java.

@TheyCallMeDanger

Nice idea. But think about servers.

And...

I'm sure MC will happily extend their block and item arrays a bit to make more room.

This had me laughing so hard.

...

Sadly. 

4000 item/blockids is more than enough.

You can do it. I know you can.

Even if MC won't add a few extra item slots.

 

SERVERS are no problem at all, since the client ONLY loads item/blockids

for the mods on the World it connects to. In other words, the server determines

the itemids in use. These are easily sent to the client.

 

Personally, I've got a couple hundred (3 hundred+) item/blockids I actually use.

I've lost count. But even that leaves roughly 3000 itemids, or room for 6 more

monstrous mods, or a whole shitload of little ones.

 

Stop making excuses.

Players are pissing at me because of itemid conflicts.

I've got a config file, and I tell them to change the range,

but I SHOULD NOT HAVE TO DO THAT.

It should just work.

The PLAYERS are hating mods because they don't get along, AUTOMATICALLY.

 

Do it.

 

 

 

but I SHOULD NOT HAVE TO DO THAT.

It should just work.

The PLAYERS are hating mods because they don't get along, AUTOMATICALLY.

 

 

Now tell them to go here:

http://www.minecraftforum.net/topic/1597274-tool-block-id-conflict-resolver/

If there is a conflict resolver to do this,

then certainly the code masters at Forge can do this too...

AND make it simpler and easier...

 

 

If there is a conflict resolver to do this,

then certainly the code masters at Forge can do this too...

AND make it simpler and easier...

 

My conflict resolver does NOT assign IDs, it simply flags conflicts and says, "Hey user, this is conflicting, you need to fix it."

 

AND it's not 100% reliable.  It's simply the best I could do with the access that I had.  Its a known issue that RedPower2's config is not parsed properly, but I am unable to fix it.

 

The problem with automatically assigning IDs has to do with mod load order.  Yes, the server should be able to tell the client what IDs go where, but Minecraft (vanilla, that is) was never built that way.  If you have a mismatch, the client will TRY to do something, but the server will go "wait, what?" and revert the change.  If its two blocks that are functionally identical (say birtch logs and oak logs) with swapped IDs on the client, then the server won't give two shits.  It'll place down oak, your client places down birtch.  Things get weird (or could) if the blocks have vastly different functions, for instance soul sand vs. sand.  The server will slow you down because it's soul sand, but the client will think its regular sand and display it as such, and you'll get some rubber banding as you try to walk across it.

 

This can be easily demonstrated by installing a mod on your client (like Mystcraft or IC2) and not on a server.  You can join the server, you can attempt to craft the blocks/items, the client will show a valid result.  You won't be able to pick it up.

 

And because items and blocks are referred to by ID number alone there is no guaranteed method to synch the client and server's ID listings.  Forge can detect mismatches and changes, but only because it goes out of its way to save block/item names (as unlocalized strings) into the world save file, so that if a mod is removed it can alert you to the fact that some block/item was detected that is in disparity between the current mod set and what was last known for that save.

But that's not the point, is it.

 

You get SOURCE CODE from mcp.

Patch it.

I know you can.

I see patches fly by the screen all the time.

Make those block/item/whatever arrays a LOT longer.

And give us auto-conflict-resolution.

I know you can!

 

C'mon....

You can do it...

Go for it!

Be a hero and make everyone's headaches go away!

"No more item conflicts! Hurray for Forge! Hip hip Hooray!"

 

Seriously. Quit dawdling around and fix it.

 

'Nuff said.

 

Good luck!

 

 

There is a suggestions forum for a reason.