and the problem with that is? i wish to gain more knowledge about the topic why cant i?
Why Update to 1.7
- Thread starter 1SDAN
- Start date
-
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
and the problem with that is? i wish to gain more knowledge about the topic why cant i?
Because there is none. I can't think of a way to make it more detailed than it is now.
The thing is, it's seriously that simple, and everyone has explained it to you many times.
There is no official post, or anything, its just a simple "id's are gone".
there are several reasons that have been mentioned already with the bigest one being no ID conflicts ever again.
For me one additional reason and bigges for me is that stagnation kills if we don't update we will get less new players interested in modded minecraft. If you just started playing with Minecraft you are at 1.7.x so you don't really want to go backwards so less chances that you will look at old minecraftversions and its mods. The same goes for people that played Vanilla and want to switch to mods they already updated to 1.7.x months ago why on earth would they want to go back?
Similar thing for new modders they are more likely to make mods for curent version of MC so we will have some cool mods in 1.6 and some fun mods in 1.7 but they won't work togather. It is much better if everyone updates to curent version and we have all mods compatible and can make great modpacks etc.
For me one additional reason and bigges for me is that stagnation kills if we don't update we will get less new players interested in modded minecraft. If you just started playing with Minecraft you are at 1.7.x so you don't really want to go backwards so less chances that you will look at old minecraftversions and its mods. The same goes for people that played Vanilla and want to switch to mods they already updated to 1.7.x months ago why on earth would they want to go back?
Similar thing for new modders they are more likely to make mods for curent version of MC so we will have some cool mods in 1.6 and some fun mods in 1.7 but they won't work togather. It is much better if everyone updates to curent version and we have all mods compatible and can make great modpacks etc.
Ok then, Im only answering this, because I always ask for the long answers too
Basicallu, prior to 1.7, blocks and items were recognised by the game by a numeric value. Eg. Stone would be ID 1. So if I go and dig up some stone (with a silk touch pickaxe, so I recieve stone) thr game would recognise that I have just destroyed an ID 1, and now have an ID 1 in my inventory. Unfortuanantlu, this was rather messy, and caused problems when 2 blocks/items had the same ID. In the 1.7 update, the format was changed, so now items/blocks are stored like this: modname:block/itemname. This basically makes it nigh impossible for the game to have 2 things having the same ID. The mod author would have to name their mod the exact same thing, as well as their block/otem. Even then, the oredictionary from forge should kick in, making them essentialy the same item. This is a huge deal for mod developors, pack creators, and users. From the developors point of view, they dont have to worry about conflicts with any other mods, along with some other things I am too tired to think of. From the pack creators point of view, they can just drag and drop mods together, and they *should* work. From the users point of view, they can easily add any mods, without the concern of id conflicts, as well as being able to download and use maps, which may not.be from the same modpack. Eg. I want to download a resonant rise world, and play it on my TPPi pack. Prior to 1.7, I would have to make aure all the IDs align perfectly, or the world is pretty much fusged up. Post 1.7, provised i have thw mods that are used in the world, it should work just fine. Even if I dont, the things from the mods I dont have will just dissapear (which also happened in pre 1.7). Hope this helps. (Pleawe excuse my spelling, I havnt slept for a long time, and Im typing on my phone)In 1.6 and below, a mod registers a keybind for a specific key (and the key it is set to is set in Options=>Controls). When the keybind is pressed (or released) the mod gets the corresponding methods called. In case of a conflict, only the first mod in a effectively random list gets the call. As such you get cases such as mods fighting to bind 'M' (e.g. minimap mod, IC2), with only 1 succeeding, or loosing the ability to sneak if you bind a mod to the same key as sneak.
In 1.7, every time a key is pressed an event is sent to all interested mods. The mods act depending on which keybind is/isn't pressed. If 2 mods bind to the same key, both will get the messages about the key.
EDIT: I was actually wrong. It has been redone, but it doesn't provide the benefits I claimed it did. I actually did not look at the code close enough and the testing I thought I did must have been incorrect.
Last edited:
I always chuckle when something so simple to explain and understand seems to be not so. Programming isn't some magic voodoo. Block IDs going bye bye, is as simply put instead of giving a block a name AND assigning it an ID, you just name it, the core code handler takes care of the rest. It offloads a ton of work for modpack guys because block ID conflicts are gone. Also I agree with the above keybind handler being equally important.
Think of it this way...
Named IDs work like DNS does in the Internet... You just have to know the name of the item to use it, instead of keeping a table of all the assigned numeric IDs used by every mod loaded by the modpack you use.
The new name format works a bit like DHCP in your router... It allows for name "duplication", if the modder needs to have a different block behavior. The format is [Mod]:[Block/{option}]... Where vanilla has "Minecraft:Stone" (why not "MC"?) another mod might have "ModX:Stone" and both would be assigned different internal numbers automatically when loaded.
In 1.6 and older, Numeric IDs have to be pre-assigned and very carefully checked for duplication. There's no way to make sure your mod isn't using the same ID as someone else's mod unless you are in contact with that person, and even then there are probably many others using that ID. If you want to swap a set of mods for another, this can be a hairy problem, and makes extra work for pack creators like FtB, who want to create an error free experience.
There are a limited number of blocks available at any given time in Minecraft, although I understand that limit was raised in 1.7. At some point it's conceivable to use all the IDs if you load enough mods. With the new system you can remove mods you don't use, making IDs they would have used available for other mods.
1.7 adds the Named ID system while retaining the older Number ID system so that modders can concentrate on 1.7 functionality first, but they will apparently have to work on converting to the Named ID system at some point as the old system will be removed, possibly as soon as 1.8.
Last edited:
Now THERE'S some great info! Yes, I mean, no ids is a great step forward, but SERIOUSLY, what took them so long to do this?!
Because as stated...
You want to know what the coders know? They said the same thing as me. IDs are gone, and that's about it. One doesn't define them as Ids and names, just names now. If you only defined them as a ID, #Get_Rekt_Scrub as you have a LOT more work cut out for you then those who did, as you have to add names where as other just have to remove IDs. That's about it.
It's not any more complicated then this. I mean, seriously. Nothing in life is simple, except for everything. A truth people have trouble grasping way too often.
The main consensus is that 1.7 has a lot of back end stuff that modders have been slavering for since the inception of the MC modding community back in beta days.
No doubt it's in preparation for the official modding API that has also been taking a long time (which might not be used, as Forge is already a modding API in popular use, it's just not "official").
Also there are benefits to these changes for the player too, the change to the ID system means one less headache when assembling your own pack, ID conflicts will somewhat be a thing of the past. You still might get the odd mod conflict if say two mods need to change the same vanilla class either crashing totally or having one mod override the other breaking some functions. But that will rarely happen with forge mods.
I do wonder how the game will resolve name conflicts, what happens if say 2 mods have copper ore? how does the game handle that and does the ore dictionary still function? does it still need to function? Will mods work with another mod's copper so long as the name's 100% the same?
No doubt it's in preparation for the official modding API that has also been taking a long time (which might not be used, as Forge is already a modding API in popular use, it's just not "official").
Also there are benefits to these changes for the player too, the change to the ID system means one less headache when assembling your own pack, ID conflicts will somewhat be a thing of the past. You still might get the odd mod conflict if say two mods need to change the same vanilla class either crashing totally or having one mod override the other breaking some functions. But that will rarely happen with forge mods.
I do wonder how the game will resolve name conflicts, what happens if say 2 mods have copper ore? how does the game handle that and does the ore dictionary still function? does it still need to function? Will mods work with another mod's copper so long as the name's 100% the same?
Name conflicts aren't gonna be a thing, unless the mod itself doesn't have an internal name. The name system, as I saw it, was "Modname.itemname", and that made perfect sense to me.
OK so it factors in the mod name so you'd only get problems if the mod name and items where exactly the same which is a contingency that is very unlikely to happen outside of amateur modding. That being said is a modder able to allow the use of similar resources like the ore dictionary does? Will ThemalExpansion.OreCopper be useable in say a macerator? I would guess the modder would just have to make it so their code only checks the latter half of the name, right?
The ore dictionary existed before 1.7 and in 1.7 it could even be done without people having to register items in it, as the system in 1.7 forces you to name items. The ore dictionary didn't work quite so easily, mind you. You registered something in it, and made your item ore dictionary compatible with said item in the ore dictionary, basically. Now one could add a streamlined process that can do it automatically, and it'd work as well as it would in 1.6.4 but it'd be easier to do in 1.7 as items now NEED a internal name.
that is handled by the oredictonary. oredict names are a different thing that the block name
EDIT=Ninjas!
Hard thing, because the mods what i want to use are on 1.6. But, lets see what we have on 1.7 by now.
Ore dict is really usefull, will survive even if ( We will see, make no comment on this, mojang really pushes it on the vanilla api right now) forge becomes obsolate.
Ore dict is really usefull, will survive even if ( We will see, make no comment on this, mojang really pushes it on the vanilla api right now) forge becomes obsolate.
Another change in 1.7: Config GUIs. If utilised, you could change config files in-game.