Why is 1.7 such a big change to modding?

TheBaconator

New Member
Jul 29, 2019
57
0
0
I see everywhere that "Oh this won't be able to update to 1.7" and "these two mods won't be compatible after 1.7" and I'm just wondering why things have changed. I know that MCP took a while to update but why did it?
 

Tristam Izumi

New Member
Jul 29, 2019
1,460
0
0
Mojang basically rewrote the backend of most of Minecraft. Things aren't handled in the same way, so may mods will need to rewrite how they interact with the Minecraft code from the ground up.

Then again, I've never heard either of the two phrases you've said anywhere, can you provide links? Perhaps you're misinterpreting something someone said in passing?
 

Pokefenn

New Member
Jul 29, 2019
976
0
0
Well, blockids no longer exist in a sense to users and mod devleopers.
What was previously a integer is now a string, so what would be a block/item id is now "modid:blockName" which you would reference instead of eg: "ModBlocks.testBlock.blockID".
This also means that you wont have to go through configs to fix ID conflicts.

Network code was rewritten, meaning that... most things dont work the same.
Also, biome stuff is REALLY different.
And also there was LOADS of other reafactors....
 

EnzymeA113

New Member
Jul 29, 2019
129
0
0
Also, Forge has changed to the Gradle build system, which has created some subtle but significant changes in the way that you make your mod.
 

RavynousHunter

New Member
Jul 29, 2019
2,784
-3
1
There's also the fact that there's no version of MCP, that I know of, for vanilla 1.7. If I remember correctly, that's basically how Forge and mods exist, and without it, nothing can move forward.
 

immibis

New Member
Jul 29, 2019
884
0
0
Vanilla Minecraft in 1.7 does not change block IDs in any user-visible way, except in /give. This means blocks still have fixed IDs. Worlds still store fixed IDs. World files do not store block names like minecraft:stone, they only store numbers like 1. Changing IDs still breaks your world.

Any changes in IDs are strictly because of Forge, and could be done in earlier Minecraft versions as well (so you should complain that they took so long). I don't know what exactly Forge plans to do, or what they already have done.

There are some changes to how blocks and items work internally, to move towards a world without IDs. Most uses of IDs have been replaced with Block/Item references. The way blocks and items are registered has changed - Block and Item objects are no longer automatically registered when they are created.

Networking is rewritten, but FML, if updated sanely, will hide this from mods - because the main way that mods sent data over the network is still there.
 
  • Like
Reactions: Pokefenn

Derpysauce

Well-Known Member
Aug 29, 2013
882
259
79
Ben shapiro
Not that much of a challenge to mod developers well kinda but odd number updates are more unstable (1.7.4) more lag more crashes more bugs so it's kind unsaid but most mod developers say no way to this probably going to wait until 1.8 it's been said that 1.6 was the most stable build of minecraft so far
 

NJM1564

New Member
Jul 29, 2019
2,348
-1
0
Vanilla Minecraft in 1.7 does not change block IDs in any user-visible way, except in /give. This means blocks still have fixed IDs. Worlds still store fixed IDs. World files do not store block names like minecraft:stone, they only store numbers like 1.

I believe that's a legacy system that will be phased out.
 

RavynousHunter

New Member
Jul 29, 2019
2,784
-3
1
Aye, I was referring to a stable version. I know I wouldn't work without a version of MCP that's at least mostly stable.

Also, why's it strings? With the work a string table would require, you could probably just use a dictionary or hashtable, one each for both blocks and items, with a regular int as a key. Or, hell, if you want as many IDs as possible, just use a long. Unless there's some implementation details I'm missing here...
 

Hambeau

Over-Achiever
Jul 24, 2013
2,598
1,531
213
Aye, I was referring to a stable version. I know I wouldn't work without a version of MCP that's at least mostly stable.

Also, why's it strings? With the work a string table would require, you could probably just use a dictionary or hashtable, one each for both blocks and items, with a regular int as a key. Or, hell, if you want as many IDs as possible, just use a long. Unless there's some implementation details I'm missing here...

Do you memorize the IP address of every website you visit? Do you even know the IP address of the mailservers that your friends use?

I heavily doubt it... Like the rest of today's user community you probably rely on DHCP to get your IP address, probably without even knowing what it is, and use DNS so you can direct your browser to http://forum.feed-the-beast.com instead of having to type in the IP address every time.

Using numeric IDs is prehistoric in comparison to the new system, much like the way we had to manually edit our systems' "hosts" file to include sites we wanted to visit without having to remember the IP address before DNS was invented, or remember the address of every site we wanted to visit before that.

Before DHCP came along you had to pay a pretty hefty monthly charge just to get an IP address assigned to you, or to get access to a system with a pool of loanable addresses, since the people/companies that owned the subnets had to pay for them as well.

The point is that doing things the way you suggest adds more background processing the larger the number is, slowing down the game, does nothing to solve blockID conflicts and would have to be increased again in the future as newer mods are written and their IDs have to be tacked on to the end of the existing list.

This way, every client has it's own table of available IDs that is loaded with nameIDs in the order they are registered, kind of like a DNS routing table, so you don't have to have a static ID table with every ID used by every mod in existence on every copy of the game for things to work right. If a mod is not used it's nameIDs aren't even loaded, which leaves more IDs for the mods that are loaded to use.

I read, probably on the Curse Minecraft forums, that the maximum number of IDs has been increased as part of the new system as well.
 

Ashzification

New Member
Jul 29, 2019
7,425
1
0
I see everywhere that "Oh this won't be able to update to 1.7" and "these two mods won't be compatible after 1.7" and I'm just wondering why things have changed. I know that MCP took a while to update but why did it?
All of the above was the long of it.
The short of it:
Minecraft changed a lot of stuff.
Stuff Mod Devs depend highly on.
That stuff made MCP more difficult to update.
Forge 'found' a new system they want to use, for probably very good reasons.
Because of all of that Mod Devs have a mountain to climb, before they can even begin to get end-user-ready mods.

What's that mean for mod packs?
Don't hold your breath.
 

SatanicSanta

New Member
Jul 29, 2019
4,849
-3
0
Unfortunately a lot of mod devs are saying "screw 1.7" and not updating past 1.6.4 unless 1.8 is better somehow :/
 

Derpysauce

Well-Known Member
Aug 29, 2013
882
259
79
Ben shapiro
Source(s)? I haven't gotten that impression at all.
I have the impression that mod devs won't work on 1.7 at all because like I keep saying 1.8 will have a more stable build possibly different coding most likely actually do to the massive changes 1.8 or 9 will pretty it up many 1.8 will make it easier to mod who knows the point is 1.7 it's the bomb no one's wants to be there everyone waiting until mojang cleans up the wreckage