Thoughts on Mojang & Mods?

[ShneekeyTheLost]

Wow, it's wierd looking at this thread when one or more people on my ignore list are apparently doing things that GOT them on my ignore list. I see the reasoned responses, and that's about it. Makes me grateful that I have that option.

ANYWAYS, I think Mojang would have done much better to have brought the Forge crew in on the API project rather than the Bukkit crew, however there's not much point in changing it at this date. It won't kill Forge, it'll just mean less idjits whining about PEBKAC errors because they'll be using Plugins instead.

 

[immibis]

Supposedly, someone with commit access to Minecraft's code (i.e. someone who can change it) asked Lex what changes from Forge he thinks should be moved to vanilla... and Lex's response was "f**k off"
So I don't really see the first or third options happening.

 

[egor66]

A few days ago, I made this comments on an /r/feedthebeast post about the future of mods: http://www.reddit.com/r/feedthebeas...tftb_style_where_do_you_see_minecraft/c8vkjkg

It definitely seemed like a popular idea, but the thread didn't go much further. What do you guys think of the whole idea/ordeal?

No comment, really come one dude, really.

 

[Hydra]

why the heck would I want to leave my jar free of mods? is not like it costs money to get a new one or something.

The only reason to have to add stuff to the minecraft jar is when you need to modify base classes. And if two mods modify the same base class you get conflicts (in the sense that probably neither is going to work correctly). It's not how Java applications are supposed to work: you add on to an API, not overwrite existing stuff. The approach Forge takes is the correct one: open up the MC internals through a generic API so all you need to do is add your own stuff in a separate jar.

 

[Dravarden]

The only reason to have to add stuff to the minecraft jar is when you need to modify base classes. And if two mods modify the same base class you get conflicts (in the sense that probably neither is going to work correctly). It's not how Java applications are supposed to work: you add on to an API, not overwrite existing stuff. The approach Forge takes is the correct one: open up the MC internals through a generic API so all you need to do is add your own stuff in a separate jar.

EnchantView adds classes to the jar, and I can ensure you that there are no classes in the vanilla jar called "enchantView" and "theBombZenAPI"

 

[immibis]

EnchantView adds classes to the jar, and I can ensure you that there are no classes in the vanilla jar called "enchantView" and "theBombZenAPI"

Are those the only classes it has?

 

[Dravarden]

Are those the only classes it has?

thebombzen API (you need it for enchantView client) has:

Spoiler

mod_ThebombzenAPI
ThebombzenAPIBaseMod
ThebombzenAPIConfigGuiButton
ThebombzenAPIConfigOpenButton
ThebombzenAPIConfigOpenScreen
ThebombzenAPIConfigOption
ThebombzenAPIConfigScreen
ThebombzenAPIConfiguration

EnchantView client has:

Spoiler

EVCommandEnchantViewExists
EVConfigOption
EVConfigScreen
EVConfiguration
mod_EnchantViewClient
mod_EnchantViewServer
azd.class
cw.class

and EnchantView server has:

Spoiler

EVCommandEnchantViewExists
mod_EnchantViewServer

the API and client mod both go into the minecraft.jar and the server mod into the minecraft_server.jar, that is, if you have a server to host.

Something else that I noticed is that the mod turns itself off if you join a server that doesn't have it, and if the client that doesn't have it joins a server that has it, the client works 100% with vanilla enchanting.