Why Update to 1.7

  • The FTB Forum is now read-only, and is here as an archive. To participate in our community discussions, please join our Discord! https://ftb.team/discord

Frontrider

New Member
Jul 29, 2019
319
0
0
So save files are now well over ten times bigger than they used to be? Instead of four pieces of stone being stored as 1,1,1,1 it is now Minecraft.Stone,Minecraft.Stone,Minecraft.Stone,Minecraft.Stone? I smell nonsense.

Its stored as 1,1,1,1, but there is now a mapping table that says 1 = Minecraft.Stone.

Bukkit still uses item ids instead of the names.And thats fairly annoying.
 

Frontrider

New Member
Jul 29, 2019
319
0
0
Very few use bukkit outside of vanilla without MCPC+ Cauldron, so the devs don't really have a reason to.

I prefer writing names instead of numbers. Mutch easier to do. I was really surprised when i realised that they removed this feature.
 

portablejim

New Member
Jul 29, 2019
267
0
1
I am fairly sure that in vanilla the values are hard-coded (because the ids are constant). Forge (well FML) adds a name=>Block/Item mapping which is populated when mods register blocks/items and initialized with the vanilla blocks/items. On map creation it runs through the map assigning ids to each entry in the map, which then is used for the world and saved with it. On joining the server the map is sent to the client.

Bukkit specifically doesn't add blocks or items (to be completely compatible with vanilla clients) and so there is no reason to make a manager to manage the same IDs as vanilla.
 

immibis

New Member
Jul 29, 2019
884
0
0
Bukkit still uses item ids instead of the names.And thats fairly annoying.
Why wouldn't they? It's not like vanilla IDs can change.

The name-to-ID mapping is actually a Forge thing. Vanilla just has plain IDs (like before) and names as well.
 
  • Like
Reactions: Padfoote

Frontrider

New Member
Jul 29, 2019
319
0
0
Why wouldn't they? It's not like vanilla IDs can change.

The name-to-ID mapping is actually a Forge thing. Vanilla just has plain IDs (like before) and names as well.

I know that they have no reason. But i don't think that they have any reason not to make it easier. I did not started to remember the id of everything for the reason i don't need to.


Eh, misspelling things can be too easy. Each to his own I guess.

probably.
 
Last edited:

Hambeau

Over-Achiever
Jul 24, 2013
2,598
1,531
213
I am fairly sure that in vanilla the values are hard-coded (because the ids are constant). Forge (well FML) adds a name=>Block/Item mapping which is populated when mods register blocks/items and initialized with the vanilla blocks/items. On map creation it runs through the map assigning ids to each entry in the map, which then is used for the world and saved with it. On joining the server the map is sent to the client.

Bukkit specifically doesn't add blocks or items (to be completely compatible with vanilla clients) and so there is no reason to make a manager to manage the same IDs as vanilla.

No, Vanilla is not hard coded, it just has the advantage of being loaded and registered before any other mod. One of the benefits of having been written by Mojang, y'know. In fact, they've mentioned in several interviews that "Vanilla" blocks are eventually intended to be completely replaceable.[DOUBLEPOST=1402343508][/DOUBLEPOST]
Why wouldn't they? It's not like vanilla IDs can change.

The name-to-ID mapping is actually a Forge thing. Vanilla just has plain IDs (like before) and names as well.

The plan is to remove numeric blocks completely in 1.8.
 

Frontrider

New Member
Jul 29, 2019
319
0
0
No, Vanilla is not hard coded, it just has the advantage of being loaded and registered before any other mod. One of the benefits of having been written by Mojang, y'know. In fact, they've mentioned in several interviews that "Vanilla" blocks are eventually intended to be completely replaceable.[DOUBLEPOST=1402343508][/DOUBLEPOST]

The plan is to remove numeric blocks completely in 1.8.

Mojang's set up will be better. I think its like something what forge does now, with no id mismatches.

Not just numeric ids, but also the data values.No need for modders to take a few ids and than put several blocks there. No id loss on things like bedrock.
 

GreenZombie

New Member
Jul 29, 2019
2,402
-1
0
Why wouldn't they? It's not like vanilla IDs can change.

The name-to-ID mapping is actually a Forge thing. Vanilla just has plain IDs (like before) and names as well.

Really? There were numerous suggestions to the forge team that they should do some kind of abstract registration API so mods could stop stomping on each others toes, and response was that Forge were waiting on a MC 1.7 feature that would make id's moot.
 

immibis

New Member
Jul 29, 2019
884
0
0
Really? There were numerous suggestions to the forge team that they should do some kind of abstract registration API so mods could stop stomping on each others toes, and response was that Forge were waiting on a MC 1.7 feature that would make id's moot.
Yes, really.

There are IDs. The IDs are just managed by Forge, in a way that affects mods slightly less than it would have if they'd implemented it in 1.6.

1.8 won't change it either. The ID management code will just move to vanilla.
 

GreenZombie

New Member
Jul 29, 2019
2,402
-1
0
Yes, really.

There are IDs. The IDs are just managed by Forge, in a way that affects mods slightly less than it would have if they'd implemented it in 1.6.

1.8 won't change it either. The ID management code will just move to vanilla.

It was always a given that ids were not going away. Storing map data using ids is much much more efficient. What needed to change, what apparently did change, was that mods now have to ask for an id, rather than specifying an id. A change Forge could have implemented much earlier than 1.7

If this wasn't a base feature, why the @#$( did Forge wait so long?
 

Frontrider

New Member
Jul 29, 2019
319
0
0
It was always a given that ids were not going away. Storing map data using ids is much much more efficient. What needed to change, what apparently did change, was that mods now have to ask for an id, rather than specifying an id. A change Forge could have implemented much earlier than 1.7

If this wasn't a base feature, why the @#$( did Forge wait so long?

Because using static config files is easier to implement, and has the same results.
 

immibis

New Member
Jul 29, 2019
884
0
0
It was always a given that ids were not going away. Storing map data using ids is much much more efficient. What needed to change, what apparently did change, was that mods now have to ask for an id, rather than specifying an id. A change Forge could have implemented much earlier than 1.7

If this wasn't a base feature, why the @#$( did Forge wait so long?
Instead of handling IDs in 1.7, mods and vanilla handle actual blocks and items. The IDs can change with less risk of things breaking.
I don't think there was much risk of things breaking before, considering IDs would only change before you load a world or connect to a server.
I should bring this link up every time someone mentions ID problems