IDs conversion : a quest for an "how to" or a "why not"

[FlowerChild]

Rather surprised, but I got a response from Jeb about my question.

It basically amounted to a decidedly cold single-line that can be summed up as "no". He wants the Mojang blocks to occupy < 256.

So yeah, I think I was right about him not liking me. This is probably one of the most reasonable requests possible, would add zero work on their end, is really without reason to refuse, and it strikes me that he arbitrarily declined out of spite.

Good times :)

[Stormweaver]

Rather surprised, but I got a response from Jeb about my question.

It basically amounted to a decidedly cold single-line that can be summed up as "no". He wants the Mojang blocks to occupy < 256.

So yeah, I think I was right about him not liking me. This is probably one of the most reasonable requests possible, would add zero work on their end, is really without reason to refuse, and it strikes me that he arbitrarily declined out of spite.

Good times :)

Sounds like: "We want to support modding! but only mods that are first made using our API."

I wonder if the idea would get more consideration should the same question be posed to dinnerbone/a member of the bukkit team that joined up. Yknow, because they've actually been working with mods all this time.

[FlowerChild]

Ah, nevermind. I decided to write him back and address the problem directly. He responded almost immediately saying he had an initial problem with the mod's name, but he's over it.

Much more amicable in his tone. Hopefully this won't be an issue in the future.

[Sarudak]

But did he change his stance on the ID numbers? I can kinda understand him wanting to keep the vanilla IDs contiguous to prevent confusion later.

[FlowerChild]

But did he change his stance on the ID numbers? I can kinda understand him wanting to keep the vanilla IDs contiguous to prevent confusion later.

Nope.

I really don't see much confusion resulting from such a change either man. That's a bit of a stretch.

[Poppycocks]

Heh, so he wrote you back as well? I shot him a... rather critical e-mail and to my big surprise he actually wrote back.

Speaking of which:

due to a new severe bug (introduced while fixing other bugs) there maaaay be a 1.2.5.

He also assured me they're workin' hard on the api. "Soon".

Nice feller by the way.

[Sarudak]

But did he change his stance on the ID numbers? I can kinda understand him wanting to keep the vanilla IDs contiguous to prevent confusion later.

Nope.

I really don't see much confusion resulting from such a change either man. That's a bit of a stretch.

I don't know... Creative and TMI and NMI all sort by ID right? So you'd end up with a bunch of vanilla blocks, then a bunch of mod blocks, then more vanilla blocks. I can see that being very confusing for some people.

[FlowerChild]

Speaking of which:

due to a new severe bug (introduced while fixing other bugs) there maaaay be a 1.2.5.

<Cocks revolver. Puts to temple>

[Poppycocks]

Speaking of which:

due to a new severe bug (introduced while fixing other bugs) there maaaay be a 1.2.5.

<Cocks revolver. Puts to temple>

I wonder what they'll put as "content" into that one.

Differently colored wooden stairs and slabs perhaps.

[Stormweaver]

I'll support a 1.2.5 release if we get the wood colour variations for slabs, stairs and pressure plates.

Otherwise, if this 'severe bug' is actually severe enough, I'll just roll back to 1.2.3 in the meantime.

[walker_boh_65]

<Cocks revolver. Puts to temple>

I don't care how lucky you think you are feeling, don't pull the trigger.

[Sarudak]

I don't care how lucky you think you are feeling, don't pull the trigger.

Especially not before the big anniversary release!!!

[MoRmEnGiL]

I should have kept my mouth shut. I knew I should have. :/

[morvelaira]

<Cocks revolver. Puts to temple>

I sure hope that's Jens' temple... *worry*

[FlowerChild]

I don't know... Creative and TMI and NMI all sort by ID right? So you'd end up with a bunch of vanilla blocks, then a bunch of mod blocks, then more vanilla blocks. I can see that being very confusing for some people.

I think it exceedingly unlikely that the impact such a change would have on the gui of inventory hack programs would be an even minor consideration for Jeb in this. Such programs could also easily compensate for such a change if they wanted to.

The one possibility that occurs to me that might explain it is if they intended to have specific packet handlers for vanilla blocks that only transmit blockIDs as a single byte to cut down on communication bandwidth.

[TheAnarchitect]

A severe bug caused by the other bugfixes?

Who wants to bet it's the wolf thing that FC already fixed this update?

[FlowerChild]

A severe bug caused by the other bugfixes?

Who wants to bet it's the wolf thing that FC already fixed this update?

Doubt it. I don't think that's the kind of thing they would label as severe considering wolves are a non-essential part of vanilla.

[ialdbaoloth]

Unless they loosen up a bit knowing bigger blocks ids are in the future, it looks like we have a while
to prepare:

Spoiler

Show

By the slope of the trendline, it would be about two years to get from the redstone lamp at 124 up to conflicting with the soulforged steel block at 209 (minus whatever goodness is in 4.0). The minecraft wiki keeps a nice history.

Don't let me stop you if you want to work on a converter - it will eventually be necessary if mojang plans to keep going sequentially up to 255 and beyond.

[TheAnarchitect]

Hmmm... I'm wandering into "I don't know so maybe I should shut up" territory, but wouldn't a block ID conflict resolver solve this issue and more besides? and wouldn't a such a block ID conflict resolver be an integral part of any decent mod API? Or is ID conversion a necessary step for block ID resolution?

Those aren't rhetorical questions. I don't know, and I'm curious because I want to understand how this would work better.

[Itamarcu]

Hmmm... I'm wandering into "I don't know so maybe I should shut up" territory, but wouldn't a block ID conflict resolver solve this issue and more besides? and wouldn't a such a block ID conflict resolver be an integral part of any decent mod API? Or is ID conversion a necessary step for block ID resolution?

Those aren't rhetorical questions. I don't know, and I'm curious because I want to understand how this would work better.

A block ID conflict resolver only changes the ID for blocks if they are not already in the world. If you change a block's ID value to a different one the originally placed block in your world will not change. So an ID resolver will only work in completely new worlds and in worlds with no mod blocks/items at all - And a lot of people (FlowerChild, Battosay and more) would do everything they can to stay on their world. As far as I remember FC still plays in his old 1.2 world...

What we are trying to do is create a third-party program that manually changes every block in your world to the "new" block, with the new ID.

[DreamsofFury]

Firstly it looks like this guy has the right idea but is having issues.
http://www.minecraftforum.net/topic/366 ... -update-0/

Short blah then a potential tl:dr part.

I have a buddy....he HATES minecraft for some yet still unknown reason as he has never played it, but what we need here is his kinda thing. For those of you that played an old Cavedog game called Total Annihilation (predecessor to supreme commander) and modded it, he is the reason behind the "anti clash" mod for it....for the life of me I cant remember the name of it. I'll see what I can do to get him working to help us out with the potential dilemma.

Now for a long wall.

Reasoning behind my theroy of why this works, has some examples from Total Annihilation along with useing BTW and whatever mod comes to mind when I get to that point. And mind that this comes from me, a person that has limited modding knowledge so correct me if I am mistaken with anything here, its mostly what I had read so far as I am about take up learning how to mod.

Basically TA used a simaler ID system for its buildings as Minecraft uses for blocks, not sure exact numbers but for examples Commanders are ID 1 and 2 the basic infantry units for both factions are 3 and 4, same goes for buildings but those come in after all kbots(infantry) vehicles and aircraft are done, units went up to 93 I believe add buildings and you had around 160. Same concept as minecraft a mod added new units with more IDs, difference being with the TA modding community noone took into account other mods so you ended up with ID clashes everywhere, my friend was highly frustrated with this due to the fact there were around 50-60 units/buildings that all used the same 10-15 IDs he came up with a special program to sort them out and give them all unique IDs.

He could take that same concept and possibly make it so say BTW and BC were not compatible already due to ID clashing a program he could make that could be ingame like the link at the start of this post did or a 3rd party program style and make it so your hoppers don't clash with the pipes by changing the ID within the files ahead of time. This could also be done with vMC to relocate mod IDs and possibly change the already existing ones, from there it would be just an issue with base classes and judging by the programing challenge that would pose I think he could possibly figure out a way to make that work as well.

Based on the limited mod forums I have been to this appears to be the only one concerned with the ID clashing of vMC eventually overtaking the mod so with any luck I might get him to come here to talk about whats going on so he can get more details from you guys. But first to call him and propose the challenge and reasoning behind it BEFORE I tell him what game its for.

[FlowerChild]

Locking before this spirals any further into uninformed speculation.

[FlowerChild]

For posterity, here's the explanation I posted of the issue a few days ago in the news thread:

I've talked about this before, but the problem basically boils down to, if Mojang are adding extra blockIDs to Minecraft, then they will likely start using more block IDs themselves.

That means that the blockID region they currently use will rapidly expand. Now, if they're smart about it, they themselves will start adding new blocks starting with an ID of say, 1000, to avoid messing with existing mods.

I think it much more likely however, that they'll just continue from the current number (137?) and keep expanding upwards, but at an increased rate then before.

In other words, I think it likely that they will start intersecting with the existing block ID range of BTW much sooner than I otherwise would have expected. If I add new blocks now, it forces me to decrease that range even further, meaning that intersection will occur all the sooner.

This is a big potential problem for people that have existing BTW worlds, and we will likely need a utility that goes through a map and replaces all the existing block IDs with new ones. I don't know of any such utility at present, but the longer I can hold off having that happen, the more likely it will be that one will exist by that time (this is bound to be a problem that starts affecting many mods), instead of me having to write one from scratch to deal with these issues.

Putting a blockID-freeze in place right now is just a little preventative medicine on my part in anticipation of potential problems down the road. Once they put the extended block IDs into place, I can start adding new blocks at a number like "2220", unlikely to ever intersect with vanilla.

In other words, to address the last few posts which inspired me to lock the thread:

-I predict Mojang blockID usage will increase in rate. This is supported by the recent aesthetic blocks that have been added, and functionality like slabs on ceilings. To me, it seems obvious they are now thinking in terms of the increased block ID limit as well.

-Block ID resolvers wreck save games or require save-game converters themselves to be useful in this context. Save game convertors were something covered already in this thread. Block ID resolvers are in no way a magic solution to this whole problem. I can easily change the blockID range used by the mod to move it outside of the first 256, the problem is with how to adapt existing saves to that.