Minecraft 1.7 pre release - Will be waiting a long time for mods

[DREVL]

Lets go back.... back.... back even further in time to when API was promised by LOLtch... maybe back to Dec 2010.
http://www.moddb.com/games/minecraft/news/minecraft-plan-for-mods-and-api[DOUBLEPOST=1382477321][/DOUBLEPOST]

Yeah- that where the 2 1/2 years came from, not from when DB was hired.

oh... lol my bad...

 

[Ripley]

http://minecraft.gamepedia.com/Plugin_API
It has been planned since 2010, we're nearly there I'm sure .

And that mojang article is funny, isn't forge the predominant api for modders now?

 

[Harvest88]

So what's exactly is going to halts mods up to a whole 365+ days for the shift over to 1.7? All I know is a whole new Biome generator or something.,

 

[WayofTime]

So what's exactly is going to halts mods up to a whole 365+ days for the shift over to 1.7? All I know is a whole new Biome generator or something.,

Redesigned sound system, redesigned block/item ID mapping, redesigned packet handling. Honestly, it'd be quicker to tell you what didn't change...

 

[Harvest88]

ahh wow, hopefully it'll be better in the end.

 

[Ashzification]

So what's exactly is going to halts mods up to a whole 365+ days for the shift over to 1.7? All I know is a whole new Biome generator or something.,

Pretty sure they said "until the new year." not for another year

 

[Ripley]

Redesigned sound system sounds really good, minecraft messes up so bad when many sounds are playing.

 

[Iskandar]

Well- Heres my two cents

Given its been almost 2 years since Dinnerbone was hired to build the API- so far there's ... nothing.

Ok ok, 1.3 merged SSP and SMP- yet client and server side mods needed, and server lag+bugs brought into SSP. Promise of API not delivered. Very difficult update for modders.​

1.4- Promise of API- nothing API related actually added or mentioned​

1.5 New launcher- mod installation gets a lot harder. Everyone must jump through a lot of unnecessary complexity or use a 3rd party programme.​

1.6 Not much in the way of API progress here. Have to re-authenticate your account if you play via old launcher or 3rd party launcher (like FTB)​

1.7 Not even a HINT of an API in the changelog. Almost every mod seems broken by this update.​

​

So there's nothing usable. No early alpha versions. No Real progress- just seems like a never ending cycle of hassle, false hope and rebuilding mods while everyone waits for the next version.

Which then begs the question- why update?

Why not wait however many versions until when/IF we ever get said API?

If we stick on 1.5 or 1.6

• More mod dev time dedicated to building mod content
• Stable/Unchanging code base- making more complex/in depth mods significantly more viable.
  • By extension I'd guess happier mod devs- I don't know anyone who enjoys porting forward.
• No more waiting for version updates- just new content when it comes
  • By extension no more losing worlds/progress
• You'll be able to play 'abandoned'/non-updating mods (Redpower, apparentlyThermal Expansion) with 'new' content.
  • Most likely more cross-compatibility- 'a' version of Xmod with 'b' version of Ymod (Eg you don't like GregTech's plates but love Thaumcraft 4.) {ok- hypothetical example but you get the idea.}

​

​

So I hear you ask - 'What about the new vanilla content/fixes?'

Why not pull that back onto 1.6?​

It sounds a lot easier than pushing everything forward onto 1.7.​

​

Also if the largest MC modded community collectively decides to stick with a version- it'll certainly make a point.​

You never know- DB might hear us and actually implement said API.​

Edit- so it seems we're looking at a total of more than 3 years of API conception and development. (5th July 2010), yet nothing solid. Thanks guys.

Eh, 1.7 is a very, very necessary update. A lot, and I mean a lot, of outstanding issues and kludges have been resolved with this update, Minecraft will be a lot cleaner and streamlined, which will make modding easier from this point forward. And block IDs are now GONE, which has been the biggest headache in Minecraft modding since pretty much day one. Mod conflicts will be, pretty much, a thing of the past.

The only negative thing you can say about this update is that they really should have broken it down into two or three mini updates instead of changing EVERYTHING at once, it would have made things less painful. But in the end, modding in a post 1.7 world will be much, much easier and less of a headache to set up for the user, than we have seen before.

It will take a bit of time, but this is a very, very positive change.

 

[Ashzification]

Mod conflicts will be, pretty much, a thing of the past.

What happens when 2 mods have the same block name?
It's still going to happen, it didn't go away just because the numbers are gone.

 

[Iskandar]

What happens when 2 mods have the same block name?
It's still going to happen, it didn't go away just because the numbers are gone.

No, it won't. See, a block is not just identified by its name but its mod, too. So, for example, Forestry:copper will not conflict with IC2:copper. The only way you can have a conflict is if you have 2 mods with the same name that use the same blocks, which should be fairly damn unlikely.

 

[Ashzification]

No, it won't. See, a block is not just identified by its name but its mod, too. So, for example, Forestry:copper will not conflict with IC2:copper. The only way you can have a conflict is if you have 2 mods with the same name that use the same blocks, which should be fairly damn unlikely.

Hm. Fair point. Argument redacted.

 

[Eyamaz]

Minecraft still has numbered IDs. UUIDs have a range up to (IIRC) 127999. Mod authors will no longer be setting the ID of items/blocks themselves but sending a mod:block or mod:item to minecraft which will then load it into an ID itself (from my understanding.)

now here is my issue with this.

say i have a pre-initialized world playing, oh idk, Railcraft, Forestry, and Buildcraft. Then i decide to add Applied Energistics in. The way I understand it working is that AE will have its IDs added to the UUID list first, thereby changing the UUIDs of all three other mods, effectively breaking the world since the UUIDs of the world and the new UUIDs are not the same.

or maybe Lex and CPW have already thought about this (or maybe even mojang,) and i'm worrying about something trivial again. who knows.

 

[portablejim]

For those complaining about the plugin/modding API...

Mojang have been moving to create a plugin API for minecraft, just in small steps. Here are some questions mojang may have asked, and answers to them.

• What if people just want to change a sound or texture, or set custom text. Should they have to code an entire plugin just to replace a sound? These files are replaced as a whole. So why not make it easy to replace these "resource" files in minecraft?
  Answer: The minecraft textures have been split up into individual files, allowing somebody to easily replace just one section and another person to replace another section.
  Answer: The idea behind texture packs has been expanded to include things like sounds and strings. However people have shown that they want more than one of these installed, so allow layering of resource packs (so you have a list of resource packs, like you have a list of mods)
• But what if the modifications that people want to do are fairly large. They want to load different classes and they want to insert function calls into the code. They also might want to have their own custom libraries... heck, we want to be able to use some different libraries
  Answer: New launcher that uses the "fancy class loading" (called ASM) that forge uses to load itself (and powers coremods, allowing several modifications to the same function of the same class to not interfere with each other). It allows custom libraries to be specified and even allows the launcher to launch a custom class first, before it launches minecraft.
• Modifications still have to register blocks and items. How do we make it easy for plugins (when we actually specify what a plugin looks like) to not step on each other's toes.
  Answer: Hide the block id at a lower level, so plugins don't need to see it. It will only be seen when dealing with world saves, where it would be wasteful to store it as a string on the disk.
• The code is still ugly though. I can't make an API on top of this!
  Answer: Rewrite the code to make it easier for an API to be introduced.

 

[Omicron]

Well- Heres my two cents

*snip*

Spoken like someone who has no idea how programming is done or what 1.7 actually includes beyond new biomes.

 

[quantumllama]

It's always entertaining to read people who don't know how programming works complain about these things. It's the same everywhere be it MMOs, patches or pretty much anything else

As portablejim explained; they seem to be moving in a right direction that will hopefully make it easier for both modders and the people who want to play with mods while improving the performance. It usually does mean sweeping changes to how stuff works / is done but in the end these steps are probably necessary for what they have in mind for the end result.

I would have done all of these changes in one fell swoop even if it takes a year to finish it all and call it 2.0, but I don't have the pressure of millions of players asking me for updates every day. They've been trying to balance the cosmetic updates with the code stuff to keep everyone happy, which is a perspective many people on both sides of modded minecraft usually lack.

 

[dtech100]

Why are you worring about mods for 1.7 when for 1.6.x not all mods are released and some are changing all the time (f.e. IC2) ?
But some mods won't be on 1.6.x and other didn't add anything new - only port. Also 200k lines of new code will be a pain in the a.. for modders.
Another problem is that FTB didn't release 1.6.x pack. So mods for 1.7 will be in good shape in january 2014 and some solid pack will be at next year.
Some people still play on 1.4.7 packs and don't worry about new stuff
Modded Minecraft players will stick to 1.6.4 - everyone is waiting for Thermal Expansion, also FTB new launcher and 1.6.4 packs.

 

[Hambeau]

Block IDs are still available as numbers in 1.7 from what I've been reading, but won't be for long.

The smart modder will make the conversion to text identifiers as soon as possible (1.7) to avoid being forced to in 1.8 or whenever numeric IDs are actually phased out.

 

[SatanicSanta]

What's the problem with this? Everyone is so worried about updates; if everything is constantly updating, and you are with it, when do you have time to play the game?

 

[Hambeau]

No, it won't. See, a block is not just identified by its name but its mod, too. So, for example, Forestry:copper will not conflict with IC2:copper. The only way you can have a conflict is if you have 2 mods with the same name that use the same blocks, which should be fairly damn unlikely.

There is still a possibility for block errors, depending on the ego of the modder.

It's been reported that although the full name is, for example, "Minecraft:Stone", the block can be accessed as simply "Stone", omitting the mod portion entirely.

If this carries through to any block name, a lazy or egocentric modder could omit their mod name as well.

 

[MigukNamja]

say i have a pre-initialized world playing, oh idk, Railcraft, Forestry, and Buildcraft. Then i decide to add Applied Energistics in. The way I understand it working is that AE will have its IDs added to the UUID list first, thereby changing the UUIDs of all three other mods, effectively breaking the world since the UUIDs of the world and the new UUIDs are not the same.

or maybe Lex and CPW have already thought about this (or maybe even mojang,) and i'm worrying about something trivial again. who knows.

Will definitely be a problem if the world is saved using only numerical IDs and the last allocated UUID is not stored.. However, I'm pretty sure Mojang is smart enough to avoid this mistake and will include at least a name-to-ID/ID-to-name table and store the last UUID used so world save files are portable and unnused UUIDs can be allocated to new mods.

I am probably speaking for more than me when I say that shifting the burden of unique IDs to the game registry, i.e. MC core code, and away from the mod devs and ultimately the user or mod pack creator is a loooooooong overdue and welcome upgrade. Cognitive dissonance struck the first time I was writing a mod and could register an item by name and a texture by name (great !), but had to pick unique block and item IDs, even with the config file providing what little assistance it could.