1.7 brings almost no features to Minecraft and will probably be skipped by mod devs, that's my point of view.
1.7 packs?
- Thread starter PhilHibbs
- 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
It's an odd-number release. That means big internal changes, and not many actual new user-end features. The next even-number release, 1.8, will finesse the changes made internally in 1.7 and add some new features, and will be the next stable platform for mods. So, like 1.2.x, 1.4.x, and 1.6.x.
Indeed, MC 1.6.4 is *very* stable. It's been the most stable MC release so far, IMHO. Also, Forge for MC 1.6.4 seems pretty good. No problems there. Memory leaks are way, way down vs. 1.5.2 .
There only server crash I've had in 1.6.4 in 3 weeks thus far has been a noSuchMethod crash caused a mod trying to call a deprecated method from another mod . I disabled the broken item(s) and that fixed the issue.
By the end of this year, we should have 1.6.4 mod packs that are as stable (if not moreso) than their 1.5.2 equivalents and 1.7 will still be way out on the horizon.
There only server crash I've had in 1.6.4 in 3 weeks thus far has been a noSuchMethod crash caused a mod trying to call a deprecated method from another mod . I disabled the broken item(s) and that fixed the issue.
By the end of this year, we should have 1.6.4 mod packs that are as stable (if not moreso) than their 1.5.2 equivalents and 1.7 will still be way out on the horizon.
No features, unless you include the inception of replacing BlockIDs with NameIDs ("Minecraft:Stone" instead of "1"). Eventually, probably in 1.8, the old static numeric IDs will be removed and replaced with dynamic numeric IDs internally assigned as blocks are registered when the mod is loaded. BTW, for this purpose MC Vanilla will be considered a mod, even though it gets loaded first. You can't count on the old static IDs then because they probably will fail as the new names will most likely load alphabetically. This means "Stone" may end up as block "123" instead of "1" like it has been.
Any new mod work for 1.7 and up will need to keep this in mind, because although 1.7 allows use of the old numeric IDs AND the new nameIDs 1.8 almost certainly will not, and adopting the new naming convention now means one less thing to fix when the old IDs are removed.
Also, there were changes to the network interface as well as over 200.000 lines of code not related to terrain generations.
I guess you're right... almost no new features in 1.7.
That would be a bad idea. If you delete or add a mod, or change the load order, half of the item IDs in the game would change. Worlds would not be compatible from one copy of Ultimate to another, if some optional mods had been enabled on one of them. I can't see an easy solution to the block ID problem.
There'd be something to fix that for the modding API, or before that forge could figure it out.
1.7 sucks arse all it has is big flowers and some shitty mountains to stop easy traverse by horseback making the horse update shit.
Seriously all mods should be perched to release on 1.6 and stay that way at least till 1.8 because for the FTB community 1.7 is horseshit (you saw what i did there).
That's kind of funny.
I threw together a small 1.6.4 modded MC that contains BoP.
I have exactly the same issue.
I can't travel but 100-200 blocks before I come to terrain that I can't take the horse over.
I seriously regret putting in BoP now and wish I had stayed with vanilla generation. I certainly won't ever use BoP again.
BoP is ok if you remove about 25 percent of the biomes. I get sick of too much snow and too many biomes that are impossible to build in and look ugly. I find you can make it a good experience you just have to fine tune it.
This system cannot work that way. As stated on the last Minecon the want you to be able to remove and add mods as you like. So it is more likely that the game would know, last time ID=125 was Stone. So unpractically it would update every id in the game to the new stone id. Or more likely keep stone on the id 125 because stone is known already known.The only problem from this could be if you add so much mods that you run out of ids (like it is already today). For Server play the server only needs to send the Name->ID list.
But no more manual assigning of IDs, that would be great.
On the other side i would like a version like 1.2.5 where all mods come together...maybe 1.6 is this version.
You wrongly understand name/ids way work. At _first_ mod load it get free ids for mod blocks/items and name/id mapping stored into world data and at next loads fixed ids used for mod block/items. It's just meaning that for 2 worlds and same mod will be used possible differents ids dependent from order adding mods to world.
I don't think I do. I'm a data migration programmer. Whilst I don't know all the specifics about Minecrafdt, I understand the principles of IDs, surrogate keys, metadata, relationships, cardinality, and persistence. I have a good instinct for when something is difficult. Of course there is always the possibilty that I am wrong, and that there is some trick that I have not spotted.
So if I enable one optional mod in a pack, and you enable a different optional mod, and then we each enable the other, our worlds will not be compatible? This is what I mean by "a bad idea".
On the other hand, as long as it is an optional system, and basically a better kind of "auto assign", and as long as the existing manual ID assignment is still poissible, I don't have a problem with it. At present, compatible packs are possible. With fully automatic block IDs, they are not possible, and I would not like to see such a retrograde step. Better that something be difficult than it be impossible.
Why it is bad idea?? Ids will be insternal data for world. Any mods configs will be must only block names use for any purposes. So from mods/user side will be totally not important what id assigned for block in specific world. Config still be compatible for worlds with same mods list independent from order mods adding to world in each world. This will resolve main problem with mod configuration and configs share: ids conflicts.
I have a strong feeling 1.6.4 will be the golden age for mods for the very long future, possibly until the official API is released. 1.7 had dramatic changes to the coding, and to my understanding, it will takes MONTHS for forge to get even a semi-stable release out. Then you will have to wait months for all the other mods to update. Then, modpacks need to be made and thoroughly tested before being released. During that time, 1.8 will probably be released, and slow everyone down again. That patch will also likely have huge changes in the code as they work towards an official API. My guess is 1.9 will be out shortly after that, with again, huge changes to the code. Finally, I believe 2.0 is where we will get the official API, rendering forge no longer needed and making modding so much easier. However, even then, it will take months for mods to update for the official API.
I plan on starting new with Direwolf20 1.6.4 or FTB Unleashed 1.6.4 modpack. If you play the waiting game, you will NEVER stop. I would wager 1.6.4 is the version you'll want to stick with for the next year or so. I really don't see stable modpacks releasing for newer versions until the official API comes. Someone correct me if i'm wrong here, there's just too many code changes for them to keep up with and minecraft is going to be patching far faster than modders can keep up with the new improved/larger team.
I made a stock 1.7 world, and I have to say the world gen is about a thousand times better. However, it's not worth waiting a year for.
By the way.. for people who have been at this longer than myself. Is it worth waiting until 1.0.1 or 1.0.2 of the 1.6.4 modpacks before creating a new world? I assume most major bugs are worked out during the beta stages, but has there ever been a case where people have jumped on a new FTB modpack, only to find their world is buggy/missing features that cannot be fixed?
I plan on starting new with Direwolf20 1.6.4 or FTB Unleashed 1.6.4 modpack. If you play the waiting game, you will NEVER stop. I would wager 1.6.4 is the version you'll want to stick with for the next year or so. I really don't see stable modpacks releasing for newer versions until the official API comes. Someone correct me if i'm wrong here, there's just too many code changes for them to keep up with and minecraft is going to be patching far faster than modders can keep up with the new improved/larger team.
I made a stock 1.7 world, and I have to say the world gen is about a thousand times better. However, it's not worth waiting a year for.
By the way.. for people who have been at this longer than myself. Is it worth waiting until 1.0.1 or 1.0.2 of the 1.6.4 modpacks before creating a new world? I assume most major bugs are worked out during the beta stages, but has there ever been a case where people have jumped on a new FTB modpack, only to find their world is buggy/missing features that cannot be fixed?
I don't want the IDs to be consistent just within a world. I want them to be consistent within a modpack, so that worlds created with a modpack will be compatible with other copies of the same modpack.
If a server enables three optional mods, this suggeston of automatic ID assignment would mean that every user would have to enable the same threee mods in the same order. If you accidentally enable one of them first in the wrong order and load the game, then the wrong IDs will be assigned and you will have to re-install the modpack and start again and enable the right mods in the right order.[DOUBLEPOST=1383044304][/DOUBLEPOST]
The only time I can think of that happening was with the 1.5.x Direwolf20 pack where a mistake was made in the block IDs.
He means essentially putting a boot sector of the ID assignments in the save file once generated, giving servers or save files shared from another user the power to override any ID assignment your personal copy of minecraft might have already loaded. Then the auto-assign becomes just a handy way of avoiding conflicts, rather than a compatibility-destroying ball and chain.
Like someone wrote 1.7 add stuff that Biomes O Plenty adds - MESA biome full of colored clay - badlands has it with normal clay also. 2 new trees - forestry adds couple trees, extra trees adds about 70 new trees, natura has own trees. New biomes are in Biomes O Plenty and Extra Biomes. So no new exciting stuff which haven't been in mods. 1.6 added clay blocks, zombie hordes - which are the best thing in 1.6 update, also horses for fast travel - like we haven't had MPS, Gravi suite, advanced nano chest )
But the thing which is really great in 1.7 update is totally new graphics & audio adjusts - chunk rendering, every sound separate (enviroment, mobs, etc).
Why are you worying about 1.7 packs when 1.6.4 aren't right now - you can make your own and it's stable but almost everyone is lazy and wait for someone do the work I will stay in 1.6 pack due to old laptop with 2 G of ram and on-board graphics.
)But the thing which is really great in 1.7 update is totally new graphics & audio adjusts - chunk rendering, every sound separate (enviroment, mobs, etc).
Why are you worying about 1.7 packs when 1.6.4 aren't right now - you can make your own and it's stable but almost everyone is lazy and wait for someone do the work
I will stay in 1.6 pack due to old laptop with 2 G of ram and on-board graphics.If server will send list assiged ids to block names before mods loading then local mods will get at loading and id requests exactly same ids as used at server side. Not important in like case order of load/enable mods at client side.
It's will be compatible. If ids mapping to blocks names wil be part of world then at mods loading it will be used from world assigned list. Modspack configs will not have any ids in to text. So will be not important what ids used in specific world.
That's quite a big change. At present, block IDs must all be known when the game loads. This would require block IDs to only be definitively set when a world is loaded, and all that information has to be sent from the server every time a client logs in. I think it's a very silly suggestion.
I'm not really worried about 1.7 packs any more. I accept that it won't be for quite a while. I'm just trying to work out what all this speculation about automatic block IDs is, as there is no basis for it whatsoever in what Mojang have said or done, CMIIW.Why are you worying about 1.7 packs when 1.6.4 aren't right now - you can make your own and it's stable but almost everyone is lazy and wait for someone do the work
Let me clue you in... If every block from every mod had to be registered using the old system there would be no more new mods, ever. There are no more available blocks to cover all the mods.
Of course, nobody would ever load every available mod, but the fact that every Mod creator has to pick a range of IDs to use leads to the problem that was just remedied between unleashed and Direwolf's pack here on FtB... Duplicate ID use.
Let me give you a real life parallel. When the IP address system, now called IPv4, was created, it was determined that 32 bits would give all the addresses anyone would ever need. 32 bits = 4,294,967,296, minus a few for sub-netting overhead.
At the time. there were no personal computers. Address subnets were assigned to maybe a dozen University mainframe computers and an unknown number of military mainframes., but nowhere near 4 billon.
The last available address using this scheme was assigned in the late 90's, if I recall correctly, during the web boom. There was already an effort in place to create a bigger address range which was actually rolled out a year ago to replace IPv4... IPv6. This has a 128 bit range and a better management infrastructure to streamline various services unavailable when IPv4 was designed, such as Streaming Video/Audio, VoIP and e-mail. I cannot give an exact number right now because it overflows my calculator, but I've seen claims that it amounts to 16 addresses for every square centimeter of dry land on earth.
What did we do in the meantime? There are certainly more than 4 billion computers and other devices connected to the web...
We use local "public" networks, behind personal routers, that are reserved for personal use and not allowed outside the personal router. The router translates these to valid "private" addresses for use on the "internet". These routers are usually set up to assign IP addresses to new computers, because that's easier for John Q. Public. These private networks, and IPv4 in general, are slowly being phased out, allowing people and organizations to upgrade their infrastructure, much like Mojang is allowing Mod developers to do here. The new system will assign BlockIDs the way personal routers assign IP addresses.
As I understand it, Each client will maintain it's own internal Block ID registry, based on the order the blocks are loaded when the game starts up. Think of how DHCP and DNS work to make it easier for you to access the web. Think of each block as needing an address, like your computer needs an IP address.
When the game loads, it builds a database file, probably stored with the Saved World information. The records, if I were to build such a system, would include the Mod name and version number, followed by the Block name, then the first available numeric ID. This would allow the loader to check if that mod version had been loaded before. If so, it skips registration. If not it registers the new mod. Assigning the first available Block number works like DHCP automatically assigning the next available IP address to a new computer on the network.
In practice, this would emulate the process used in every computer, called DNS, or Domain Name System. In the computer, it allows you to access a website just by knowing it's name and not have to memorize it's IP address. Here it sees "minecraft:stone" and returns the numeric block ID to the renderer.
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?
Tl;dr:
The new system should free up what seems to be one of the major incompatibilities between Mods.[DOUBLEPOST=1383057235][/DOUBLEPOST]
As stated in my above post, take a look at the TCP/IP protocols that have worked for over 40 years. It really isn't rocket science.
I have personally built mod packs for 1.4.7 and 1.5.2 and 1.6.x and I can say ID conflicts are common and suck. Can be a real head ache. ESPECIALLY if you are deal with world gen IDs. Like Biome IDs. Trying to merge BoP and Extra biomes XL is HARD. This could really make life easier for people to make creative interesting unique mod packs that many people would enjoy. I am really excited for these changes it just going to be a long time before we see them. And guess what.. Thats good news! Now we can have 1.6 become a super solid stable well fleshed our modded minecraft. Just like 1.2.5. Its ok if things take a while updates have been to quick anyways. Anyways just my two cents.