1.7 packs?

[MigukNamja]

Agreed. I have faith that Mojang will use block and item names as indices in saved worlds rather than bare IDs. In other words, after this change, the only block and item conflicts should be over names. So, your 1.7 saved world with mod package X will be transportable to another 1.7 and beyond world with mod package X + Y.

Note that the actual saved world contents may use IDs for each block and item to simply compress the data save and use an index table of name-to-ID and ID-to-name mappings. So, yes, technically speaking, the saved world files may use block IDs, but that doesn't mean the saved files are assuming those are unique or even portable.

Hambeau's analogy with DNS FQDN names and IPs is apt. feed-the-beast.com is uniquely feed-the-beast.com . The actual IP address is subject to change at any time and indeed, there may be multiple IPs (via DNS SRV) associated with feed-the-beast.com .

tl;dr - Don't worry about numbers in 1.7 . Modders should *only* be concerned that names are unique, and they should be unique if the MOD ID (name) is unique.

 

[PhilHibbs]

Let me clue you in...

Please, don't assume I'm ignorant and then post nonsense.

Each PC could have completely different ID registries, since they are completely client based.
Also, this system would allow Mojang to increase the total blockID count at any time, if needed, because the names would remain the same and who cares about what numeric ID "stone" has anyway?

OK, so my machine thinks that Mod:Railcraft:AbyssalStone is 12345, but the server thinks it is 23456. So when the server sends me the data for a chunk, and lets say there are 10 pieces of Abyssal Stone in a row, it can't just say "23456,23456,23456,23456,23456,23456,23456,23456,23456,23456", because my machine doesn't know what that is. It has to say "Mod:Railcraft:AbyssalStone,Mod:Railcraft:AbyssalStone,Mod:Railcraft:AbyssalStone,Mod:Railcraft:AbyssalStone,Mod:Railcraft:AbyssalStone,Mod:Railcraft:AbyssalStone,Mod:Railcraft:AbyssalStone,Mod:Railcraft:AbyssalStone,Mod:Railcraft:AbyssalStone,Mod:Railcraft:AbyssalStone". That's a lot of bandwidth. It would me much better just to expand IDs to 32 bits. Sure it could do some simple compression like run length or LZ, but it's still a big overhead, for example when a chest breaks and a hundred mod items spill out as entities and it has to send the names instead of just the IDs.

The new system should free up what seems to be one of the major incompatibilities between Mods.

So what is the new system, rather than this wild speculation? Got any links?

Agreed. I have faith that Mojang will use block and item names as indices in saved worlds rather than bare IDs.

That's a ridiculous idea, see example above.

 

[MigukNamja]

Phil,

Client-server in 1.7 would have to use names and not IDs, at least for the login phase where the client is getting oriented with the world. So, two(2) possible ways:

1. Name-to-ID mapping is given to the client when the client logs in
2. IDs are never used and only names are used

The former is more efficient post-login since IDs are shorter (fewer bytes) than ASCII names. The latter is simpler.

And, dude, you need to chill. It seems you do not understand the difference between proving a negative and proving a positive. You are attempting to prove that names in 1.7 simply cannot be made to work. That is nearly an impossible proof because you have to cover the entire space of possibilties and prove each one is unworkable. Good luck !

However, to prove that it's merely *possible* for names to work in 1.7, me and others just have to show 1 possible way. We have shown that.

You also seem ignorant of client/server architecture and network communication in general. A 1-time exchange of names and IDs is trivial. A few hundred kilobytes at most. In 2013, that's not even a drop in the bucket.

 

[PhilHibbs]

I can see that all user interaction will be done with names. That's clear from the examples of Command Blocks that I've seen. I assume that this will extend to config files as well, when any mod needs to refer to another mod's items it will do it with the name ID string.

And please, don't call me ignorant. Feel free to accuse me of exaggeration though, I'm guilty of that. But I have developed communications protocols from the ground up through handshaking, the "who lets go" problem, and up to the file transfer layer. Sure, it could use a layer of indirection. As the saying goes, "There are no problems in computer science that cannot be solved by adding a layer of indirection... except for the problem of too many layers of indirection".

 

[PhilHibbs]

And, dude, you need to chill. It seems you do not understand the difference between proving a negative and proving a positive. You are attempting to prove that names in 1.7 simply cannot be made to work. That is nearly an impossible proof because you have to cover the entire space of possibilties and prove each one is unworkable. Good luck !

What I usually do in my work is to point out the flaws in the design, and eventually once those flaws have been worked around, we have a working system. But I always start out from the point of view of "it won't work", because that way, it eventually does work because I was skeptical about it. I apologise if my fervour for finding problems with solutions sometimes appears to be simple negativity. I have what might be called... "a robust approach". Oh, and sometimes, the flaws are so deep and difficult that the whole thing has to be thrown away and taken back to the drawing board. So I'm always considering that possibility. Some problems are hard, and not always obviously so.

And, I didn't think we were actually talking about 1.7 any more, I assumed that this was speculation about 1.8+. Sure, 1.7 has names as an alternative to IDs in Command Blocks, but I don't think it's actually changed the data value mechanism or the Anvil file format at all, has it?

 

[MigukNamja]

Phil,

Ditto here. I have built multi-threaded client/server architectures from the ground-up in C, C++, Java, and Perl. I'm fairly familiar with data synchronization issues and am aware of the basic techniques to avoid separate name spaces while maintaining network, CPU, and memory efficiency as well as a decent API.

The thing is, I'm not the sharpest tool in the coder shed and I've seen the Mojang code and it's - for the most part - better than anything I ever wrote. And, if I can come up with an ID-independent world and client/server architecture, I'm sure Mojang can, too. Hence, I am confident that they will accomplish their goals without noticably impacting performance or world file save size.

tl;dr - Don't worry, be happy. 1.7 will resolve the item/block ID issue that's plagued modded MC since day 1.

 

[Hambeau]

Go read the discussions on the Mojang forum that I read. My work here is done.

 

[PhilHibbs]

Mojang have a forum?

 

[Hambeau]

http://www.minecraftforum.net/index.php

These are hosted on Curse and you will need a Curse account to post.


I get there using a link from Mojang's page

https://minecraft.net/

So I can check the top bugs reported and the progress on fixing them.

 

[Jess887cp]

I'm throwing in my two cents by saying that I always make serious worlds on beta packs, and "what's already out." But I'm also really excited for 1.7 because I can finally build a dye factory that isn't utter shite.

 

[PhilHibbs]

Oh, I know about the Curse forum. Do you have anything more specific than "the discussions ... that I read"?

 

[immibis]

PSA:
1.7 still uses block IDs.
They still work the same way as before.

 

[ShneekeyTheLost]

PSA:
1.7 still uses block IDs.
They still work the same way as before.

Let's see... where was that facepalm.jpg at again?

Ugghh, seriously... that was like THE feature touted for this update I actually cared about, simply because it would completely obviate ID conflicts. Motivation to update: 0.001%

 

[PhilHibbs]

Ugghh, seriously... that was like THE feature touted for this update I actually cared about, simply because it would completely obviate ID conflicts. Motivation to update: 0.001%

I don't thnk that anyone has actually said that 1.7 would completely remove the ID conflict problem. No-one who knew anything about what they were talking about anyway. They have introduced one place where ID strings can be used instead of numbers. Command Block strings. That's it. I really am baffled where all this bizarre speculation about "the end of numeric IDs" has come from. Sure, maybe at some point in future there will be some magic that solves the ID conflict problem, and this is the first baby step in that direction. And it may be as simple as each instance getting a copy of the ID table from the server when it connects, and doing an on-the-fly re-map of server IDs to local IDs. But I don't think that Mojang have said anything of the like, CMIIW.

 

[Grydian2]

According to the change log of 1.7

Using IDs will soon be impossible

Its happening in stages. There will be legacy support for block IDs but its being phased out.

 

[PhilHibbs]

According to the change log of 1.7
Using IDs will soon be impossible

I'm pretty sure that that only refers to console commands and command block strings.

 

[Grydian2]

For 1.7 but that doesnt mean its not the first step in moving away from block IDs. Which mojang has said they want to do. You cant reinvent the entire game in one update dude.

 

[Hambeau]

Right now you can use both Block IDs and NameIDs, much like in the Network world where with an interim protocol stack you can use both IPv4 and IPv6... This gives both ISPs and consumers a timeframe to upgrade their equipment. Sorry for all the network references but we draw our comparisons from what we are familiar with

Right now Mods can still use their Block IDs and have to keep fighting conflicts every update, or start using NameIDs and avoid them.

Eventually, BlockIDs WILL be removed. Nobody outside of Mojang has a timeframe on that just yet.

 

[immibis]

Right now Mods can still use their Block IDs and have to keep fighting conflicts every update, or start using NameIDs and avoid them.

Nope, you have to use both.

Edit: And the IDs aren't just used for save compatibility, either.
They're actually used for saving the world, same as before.

One thing they did do is to pass around Block objects (for non-modders: pointers to the chunk of memory that stores information about a block type) in a lot of places, where previously they would pass around the block ID and then look it up in Block.blocksList (the master table which maps block IDs to Block objects).

 

[arthahar]

They're actually used for saving the world, same as before.

I think noneone in thread say another. Discussion only about time of block id allocation/registration and persistent in different world saves, and accesability blocks ids in mod configs.