Minecraft 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

Harvest88

New Member
Jul 29, 2019
1,365
-1
0
At this point any mod API they release is a downgrade to Forge and therefore basically worthless.

In addition, that ID removal change is pretty much going to go and break every mod ever. I'd say that's about one step forward and twenty back.


Yea but hey no more ID fixing cause of this if they actually do it like this
One of them is ModA:IamDumb and the other ModB:IamDumb
Like the user said the only conflict will be if both mods are the same. (which you can get problems with the modmaker that you stole their name from anyway) So if this actually get placed in then yea I think it'll be better in the long run.
 
  • Like
Reactions: The Mobius Archives

Democretes

New Member
Jul 29, 2019
1,134
0
1
A modding API. Yeah that's gonna take a while. The rewrote 70,000 lines of code to fix blocks/items being hardcoded. We're a little far off. When it does finally come out, I think it'll be more problematic at first than helpful since every mod will have to rewrite something or another just to make blocks and items simply be registered.
 

netchip

New Member
Jul 29, 2019
85
0
0
Forge will just adapt this. Mod authors will need to change a few methods and everything is fine ;) Probably, I can't look into the future of course.
 

ShneekeyTheLost

Too Much Free Time
Dec 8, 2012
3,728
3,004
333
Lost as always
Forge will just adapt this. Mod authors will need to change a few methods and everything is fine ;) Probably, I can't look into the future of course.
Unfortunately, it's a good deal more than 'a few methods'. Every bit of code that calls objects is going to have to be re-written. Hell, the variables themselves will have to change from an Int to a String variable. Any time an Item or Block is referenced, it will need to be changed. That's... a fairly straightforward process, yes, but it is a LOT of changes that will have to be enacted. It will take time to do, just to bang out that many characters in data entry.
 

netchip

New Member
Jul 29, 2019
85
0
0
Unfortunately, it's a good deal more than 'a few methods'. Every bit of code that calls objects is going to have to be re-written. Hell, the variables themselves will have to change from an Int to a String variable. Any time an Item or Block is referenced, it will need to be changed. That's... a fairly straightforward process, yes, but it is a LOT of changes that will have to be enacted. It will take time to do, just to bang out that many characters in data entry.
" Every bit of code that calls objects is going to have to be re-written."

False. Every reference to a block id has to be rewritten. But nobody references a blockid directly, most use some kind of Forge api or reflection to access the block id of another mod.

Also, in the initialising method, where you initialise your blocks, you adapt the called functions to the new forge ones.
 

Siro

New Member
Jul 29, 2019
638
0
0
" Every bit of code that calls objects is going to have to be re-written."

False. Every reference to a block id has to be rewritten. But nobody references a blockid directly, most use some kind of Forge api or reflection to access the block id of another mod.

Also, in the initialising method, where you initialise your blocks, you adapt the called functions to the new forge ones.

To expand on this: Forge itself could wrapper the block IDs of mods its loading. Anything that registers in a dictionary could be cast as ThatModName:ThatDictionary name. Anything that isn't registered that way could just be referred to as either ThatModName:Generic1 or Forge:LoadedMod1-block1, etc. As long as something is being written to load into forge properly, it would be a relatively simple solution prior to mod authors using the new references.
 
  • Like
Reactions: netchip

Zealstarwind

New Member
Jul 29, 2019
278
0
0
I VERY MUCH doubt that we will get a modding api in 1.7.
Heck i doubt that we will ever get it, mojang needs to clean up their code alot.


They need to use something better then Java, the worlds shiznittiest coding language.... yet one of the most widely used... It's one of the reasons I'm a bit excited but skeptical on minecraft for the playstation (3/4/vita) because it does away with the crummy coding of java and uses the Playstation infrastructure which has a focus on processing which is kinda what Mojang really needs for Minecraft but java is just terribly coded.
 

BanzaiBlitz

New Member
Jul 29, 2019
429
0
0
It might be they fully intend to keep iterating until they're ready for MC 2.0 as the Mod API reveal. Considering they're in regular contact with the Forge devs (to my knowledge), along with a lot of other MC modders, it isn't being given some vague patch-plop like less friendly companies do, like EA. It helps to keep an open mind that Mojang is full of crazy people that love their work and take pride in this massive ecosystem of players that has grown long past Notch handing off the reins.

Personally, I'd like to see a publicly stated freeze of updates beyond snapshots for a few months so modders have a breathing period after 1.7 to lock things down like it was in 1.2.5, for those that remember (feels so long ago! :eek:). Snapshots keep popping so people can root out bugs and see new features, but modders have a stable timeline for one release to catch up! :p
 

Hydra

New Member
Jul 29, 2019
1,869
0
0
Anyone who has seen snapshot 12w37a will know that all technical blocks have been removed, and that you can now reference blocks in commands with their names (e.g. minecraft:stone), instead of using IDs. This is a major step towards towards the Mod API as it means that there will be no more id conflicts (!!!), and that just in general they are working on it. So, do you think that we will get the API in 1.7? My guess is that we will, with 1.7 coming out at Minecon.

There isn't "a modding api", there's just a road towards a more moddable minecraft. A road Mojang is already on.[DOUBLEPOST=1379451914][/DOUBLEPOST]
They need to use something better then Java, the worlds shiznittiest coding language....

As a Java dev: you don't know what you're talking about, sorry.
 
  • Like
Reactions: Pokefenn

Ember Quill

Well-Known Member
Nov 2, 2012
350
119
68
As a Java dev: you don't know what you're talking about, sorry.
As a fellow Java dev: while Java certainly does have some advantages (namely, that it's inherently cross-platform and "just works" as long as the user has a JRE installed), it's still pretty terrible when it comes to performance and memory usage. It's possible to mitigate these downsides by optimizing your code, but Mojang hasn't really done much of that with Minecraft. And then there's Forge and the various mods that rely on it, which all contribute their own performance issues even despite their own optimizations.
 

Hydra

New Member
Jul 29, 2019
1,869
0
0
As a fellow Java dev: while Java certainly does have some advantages (namely, that it's inherently cross-platform and "just works" as long as the user has a JRE installed), it's still pretty terrible when it comes to performance and memory usage. It's possible to mitigate these downsides by optimizing your code, but Mojang hasn't really done much of that with Minecraft. And then there's Forge and the various mods that rely on it, which all contribute their own performance issues even despite their own optimizations.

The bottleneck in Minecraft isn't Java. Besides, with modern JIT compilers the difference between native and bytecode-compiled-to-native is hardly noticable. Any language has it's pro's and con's but saying that it's the "shiznittiest coding language" is just complete bollocks. And no, Java isn't terrible at all performance wise. You should know that.