Worried about block ID's

[Damion Rayne]

Flower,

I really have to state that I like everyone else here, have had so much fun with your mod it's not even funny. You have given us so much, and allowed us to create and move forward and build things vMC would never let us do. But as vMC has used 96 block ID's already, some that can't be obtained in any legit fashion and 1.8 will add more...well,

Forgive me for this, but I'm worried. I don't understand java and minecraft coding and I am certain you know what you are doing, but are you worried you may eventually run out of block ID's? Or that Notch may use up tons more with updates? I'm really honestly and truly not trying to piss you off or upset you, I've just come to adore your work to the point that I worry about the future of the mod while vMC moves forward. It irritates and worries me that Notch may accidentally destroy our ability to mod minecraft and enjoy mods by sucking up block ID's.

So can you maybe talk about this if you have the time?

If not cool, and If I offend I apologize and understand the thread being locked if it is.

Respectfully,
DR

[Stormweaver]

I expect if things ever get too bad with vMC, some smart guy'll come up with a way of stacking most of the non-functional vMC blocks into just a couple of block IDs, and it'll end up being a modding standard like modloader.

[finite8]

Well, in local memory, BlockID's are stored as an Integer. Java doesn't have unsigned integer so it would only use the upper bounds which is 2,147,483,647 (over 2 billion).

Now, not looking at the code or any other references, lets ASSUME it doesn't store the full 32bit integer in the NBT file and rather, just uses the integer to store the value:
If using 8 bits, then 128 IDs available
If using 9 bits, then 256 IDs available
If using 10 bits, then 512 IDs available
If using 11 bits, then 1024 IDs available

and so on.

The Java short type can hold 32,767 IDs. If that was the limit, i assume notch would have stored the ID's in this RATHER than use an int as that would essentially double the amount of System Memory being consumed by the game (as for every block, it would then store 32bits with 16bits per block being not being used by anything). Looking at this, it would appear that whatever the NBT stores is somewhere between the integers maximum bounds and the short.

If i am correct, there are plenty of ID's to go around, and even have some leftover to have a party, get wasted, have some children, get into a family dispute, suffer depression, get caught up in drugs, get put in jail for drug trafficking, and eventually write an autobiography.

Not sure on how Miencraft stores the ID's in the NBT file though.

[Gilberreke]

It stores as byte, 256 values.

[finite8]

It stores as byte, 256 values.

Unsigned or Signed?

If that is the case, then that is a bit of a short-sighted issue that Mojang are going to have to fix. They KNOW there is a big modding community out there and 256 ID's strangles that massively. It sounds like though that the NBT file structure is pretty flexible so an enhancement on top of that seems very possible. I mean, MapId's are stored using a 16bit index (unsigned) so it shouldn't be too hard although... it is stored as a separate file so that doesn't really mean too much as far as the main world data is concerned.

I have a gut feeling that they are going to enhance the BlockId's. 1.8 is going to open up more support for modding, so actually giving modders numerical space to add new items and blocks seems like a logical step.

Also... yikes! Storing a byte value in an int field? WTF is with that? Even they were thinking that at some point they wanted to enhance the id range, then changing from shorts to ints in-code really isn't that hard.

[Gilberreke]

Unsigned or Signed?

Unsigned.

If that is the case, then that is a bit of a short-sighted issue that Mojang are going to have to fix.

That's impossible, that'd almost double MC's RAM usage, which is probably not an option.

1.8 is going to open up more support for modding, so actually giving modders numerical space to add new items and blocks seems like a logical step.

Not true. There is no planned mod support. This is an urban myth. Notch detailed the mod support plan in detail and all it is, is making MC open-source for official modders. It makes MCP obsolete, but that's about it.

[finite8]

If that is the case, then that is a bit of a short-sighted issue that Mojang are going to have to fix.

That's impossible, that'd almost double MC's RAM usage, which is probably not an option.

Are you sure about this? From my first-look at the code, blockIds are stored as integers already which would imply that such information is already stored in memory as an int taking up the full 32bits memory. How they are stored in the NBT should be irellevant (unless the NBT is loaded into active memory and worked from there). I mean, BlockId's are identified using an integer so it would seem that some thought has been made on the potential BlockID range.

1.8 is going to open up more support for modding, so actually giving modders numerical space to add new items and blocks seems like a logical step.

Not true. There is no planned mod support. This is an urban myth. Notch detailed the mod support plan in detail and all it is, is making MC open-source for official modders. It makes MCP obsolete, but that's about it.

True, but there is also a lot happening in 1.8 he isn't letting anyone know about. Forcing modders to have to start screwing around with the NBT file and how it stores data so they can still do their mods would be very unhealthy for the modding ecosystem that has been established around Minecraft. Hopefully, Mojang realises this and takes it into account.

[Gilberreke]

Are you sure about this?

Hmm, you're right, they ARE stored as ints. I don't feel like looking where the bottle neck is, but I know 100% sure that the upper blockid limit is 255 and that it's near impossible to change this without serious performance repercussions. It has been looked into time and time again by lots of people.

[gftweek]

Notch confirmed that increasing the block ID's would double memory usage and severely impact multiplayer performance, so he doesn't consider it an option. This doesn't mean that it can't be modded in, but FC is against it as it would change the way save files work, and make the save file dependent on the mod (or require a repair tool to remove).

As for running out of block ids, it may just get to the point where modders replace existing blocks with their own when they can't add new ones, for example, sponge and spider webs are currently unused by vMC (although maybe not for long).

[Damion Rayne]

Are you sure about this?

Hmm, you're right, they ARE stored as ints. I don't feel like looking where the bottle neck is, but I know 100% sure that the upper blockid limit is 255 and that it's near impossible to change this without serious performance repercussions. It has been looked into time and time again by lots of people.

So this means that eventually vMC will take up all these ID's, modding will stop entirely and after the 255 limit is reached with vMC there is no further development? I mean wow, what a stupid game design decision...

[Gilberreke]

So this means that eventually vMC will take up all these ID's, modding will stop entirely and after the 255 limit is reached with vMC there is no further development? I mean wow, what a stupid game design decision...

I dare you to to write a procedural game the size of minecraft at all. Notch has done a pretty good job so far performance wise. I'm getting kind of sick of all the Notch hate.

And everyone, stop worrying, there'll be a solution, just be patient and stop speculating. I'm personally looking into writing an API on top of Forge that gives each mod its own 256 IDs that might fix the issue

[Damion Rayne]

So this means that eventually vMC will take up all these ID's, modding will stop entirely and after the 255 limit is reached with vMC there is no further development? I mean wow, what a stupid game design decision...

I dare you to to write a procedural game the size of minecraft at all. Notch has done a pretty good job so far performance wise. I'm getting kind of sick of all the Notch hate.

And everyone, stop worrying, there'll be a solution, just be patient and stop speculating. I'm personally looking into writing an API on top of Forge that gives each mod its own 256 IDs that might fix the issue

I don't hate Notch, do not put words in my mouth. It seems like a stupid game design decision because it means that there is an absolute end point, in a game that prides itself on being the ultimate sandbox.

[Gilberreke]

I don't hate Notch, do not put words in my mouth. It seems like a stupid game design decision because it means that there is an absolute end point, in a game that prides itself on being the ultimate sandbox.

A game that was never meant to be moddable. Give the guy a break. He couldn't have foreseen back when he wrote the first block ID code that this game was going to be so popular there was going to be a modding community.

[Damion Rayne]

I don't hate Notch, do not put words in my mouth. It seems like a stupid game design decision because it means that there is an absolute end point, in a game that prides itself on being the ultimate sandbox.

A game that was never meant to be moddable. Give the guy a break. He couldn't have foreseen back when he wrote the first block ID code that this game was going to be so popular there was going to be a modding community.

Suppose you're right on that, he never imagined that minecraft would make him a millionaire.

[FlowerChild]

Block IDs may be stored as ints in the code itself, but they are stored as 8 bit values in data (and are transmitted as such in the communication code). As such, there's a limit of 255 different block IDs available (0 is consumed by air).

This isn't a serious worry at present guys. I use 30 some odd block ids out of the 150 or so that are currently available, and if I ever do hit that, then I'll make the mod dependent on something like MCE that extends that limit to over 65K (at the expense of performance and fucking with people's save files).

However that is a LONG way off from where we are right now given I'm only using 1/5th of the available block IDs.

And that is all I will say on this conversation (I won't even return to this thread to read it again). I hate discussing technical details with the fan-base because it always gets ridiculously out of control.

Oh, and please change the thread title to not include my name, as per the forum rules. "Worried about Block IDs" would serve just as well and be more descriptive anyways.

[Damion Rayne]

Block IDs may be stored as ints in the code itself, but they are stored as 8 bit values in data (and are transmitted as such in the communication code). As such, there's a limit of 255 different block IDs available (0 is consumed by air).

This isn't a serious worry at present guys. I use 30 some odd block ids out of the 150 or so that are currently available, and if I ever do hit that, then I'll make the mod dependent on something like MCE that extends that limit to over 65K (at the expense of performance and fucking with people's save files).

However that is a LONG way off from where we are right now given I'm only using 1/5th of the available block IDs.

And that is all I will say on this conversation (I won't even return to this thread to read it again). I hate discussing technical details with the fan-base because it always gets ridiculously out of control.

Oh, and please change the thread title to not include my name, as per the forum rules. "Worried about Block IDs" would serve just as well and be more descriptive anyways.

Sorry, will change it.

[KriiEiter]

Just curious, but how exactly does block damage values work?

Would it be possible to just clump all blocks with similar break properties into one id with damage values?

I.E. All ores become one block with different damage values?

[Gilberreke]

Just curious, but how exactly does block damage values work?

Would it be possible to just clump all blocks with similar break properties into one id with damage values?

I.E. All ores become one block with different damage values?

You can't do it for vanilla blocks or you break compatibility with every save file and other mod out there. You can't clump most blocks together because of metadata.

[KriiEiter]

Just curious, but how exactly does block damage values work?

Would it be possible to just clump all blocks with similar break properties into one id with damage values?

I.E. All ores become one block with different damage values?

You can't do it for vanilla blocks or you break compatibility with every save file and other mod out there. You can't clump most blocks together because of metadata.

Actually I meant, why DOESN'T it work like that already, if it works?

[gftweek]

Probably could be for more vanilla blocks, but Notch or Jeb would have to implement this as it would change how save files worked as currently used blocks would no longer be used, and ones with damage values would not work with older saves (half of them would disappear and others would just become coal).

There are some reasons why this can't work though, for example for ores, lapis and redstone drop a random amount of resource items (not the ore), coal and diamond always drop one item, and the others all drop blocks, plus redstone glows when hit while the others do not, so they all function quite differently and would be difficult to combine into a single block.

[emmasteadman]

Notch has built in the ability to mod, but hasn't made it standard yet....given that, I can't imagine him using up so many blocks that it becomes unrealistic to mod; without Mojang themselves revamping the base code in some way to allow for more IDs or something. Modding is huge part of what sells Minecraft and will still do so when they release the final version. To ignore that would be shooting themselves in the foot so to speak.

[Gilberreke]

There are some reasons why this can't work though, for example for ores, lapis and redstone drop a random amount of resource items (not the ore), coal and diamond always drop one item, and the others all drop blocks, plus redstone glows when hit while the others do not, so they all function quite differently and would be difficult to combine into a single block.

Are you a programmer? Because every issue you suggest is actually a trivial one line change in the code. Those are not the problems...

[gftweek]

Notch has built in the ability to mod, but hasn't made it standard yet....given that, I can't imagine him using up so many blocks that it becomes unrealistic to mod; without Mojang themselves revamping the base code in some way to allow for more IDs or something. Modding is huge part of what sells Minecraft and will still do so when they release the final version. To ignore that would be shooting themselves in the foot so to speak.

Notch didn't build in the ability to mod, all mods are technically illegal decompilations of Mojangs code, Notch doesn't love that it happens, but he does love what people do with it, and recognised that people want it, but in no way does he have to support it.

There are some reasons why this can't work though, for example for ores, lapis and redstone drop a random amount of resource items (not the ore), coal and diamond always drop one item, and the others all drop blocks, plus redstone glows when hit while the others do not, so they all function quite differently and would be difficult to combine into a single block.

Are you a programmer? Because every issue you suggest is actually a trivial one line change in the code. Those are not the problems...

Heh, I am actually a programmer, but I've never looked at modding Minecraft so have no idea how the objects are structured, depends how the object structures are set up as to how easy this is to do. "Can't" was perhaps too strong a word therefore, although I would have thought the redstone glow at least was related to the damage value? I am primarily guessing though, it usually works for me.

I'd say the main reason Notch hasn't done this as it would require change save files (which he'd prefer not to do), and he currently has no reason to implement this as there are plenty of block ids available for vMC usage, he doesn't have to allow for mods, it is after all his code.

[KriiEiter]

I'd say the main reason Notch hasn't done this as it would require change save files (which he'd prefer not to do), and he currently has no reason to implement this as there are plenty of block ids available for vMC usage, he doesn't have to allow for mods, it is after all his code.

Well, he's already changed the saves once, and plans to do it again in 1.8, so why not give even himself more room for more blocks?

[gftweek]

I'm fairly sure 1.8 won't change the save file structure, just the world generation algorithms, you'll still be able to use old saves with it, they'll just have chunk errors in the boundaries of explored terrain where the 1.8 chunks start and the 1.7 chunks finish.