1.8: what is holding you back?

[asiekierka]

the other annoying problem, when mods DO start using common "dynamic" libraries, is that Mod_A will be updated and depend on Mod_Library v1.2, but Mod_B's author will be doing exams or something, and require Mod_Library v1.1

I just downloaded a mod for my kid that required 3 other library mods. All code, all tiny, statically linking that content would make this download a lot more convenient now, and a lot less prone to versioning conflicts later.

Happens either way - remember when BuildCraft 6.1.5 was forced to break its API to restore an important feature and it broke Binnie's Mods for a few months, requiring me to create the world's hackiest workaround for FTB just so I didn't break Binnie's license?

Or when RF's API had a breaking change in 1.7.10, causing quite a few mods to act weird for a while.

 

[GreenZombie]

Happens either way - remember when BuildCraft 6.1.5 was forced to break its API to restore an important feature and it broke Binnie's Mods for a few months, requiring me to create the world's hackiest workaround for FTB just so I didn't break Binnie's license?

Or when RF's API had a breaking change in 1.7.10, causing quite a few mods to act weird for a while.

I think there is clearly a difference between a content mod changing its api to support its new features, and a library mod doing the same. It doesn't make any sense for two instances of buildcraft to live side by side, but a lot of core mods are not offering interoperation features. The animation API (afaik) simply allows a mod to animate its own models. There would be no problem if mods integrated static instances of libraries like that.

 

[lenscas]

I think there is clearly a difference between a content mod changing its api to support its new features, and a library mod doing the same. It doesn't make any sense for two instances of buildcraft to live side by side, but a lot of core mods are not offering interoperation features. The animation API (afaik) simply allows a mod to animate its own models. There would be no problem if mods integrated static instances of libraries like that.

Just to be clear, you would like that all api only mods get bundled by each mod that needs them?
This would mean that if you have 10 mods that need the rf api you have the api for rf 10 times installed. That seems inefficient and I wouldn't be surprised if it will give more errors/unexpected behavior in the long run then the way it is done now.

 

[GreenZombie]

Just to be clear, you would like that all api only mods get bundled by each mod that needs them?
This would mean that if you have 10 mods that need the rf api you have the api for rf 10 times installed. That seems inefficient and I wouldn't be surprised if it will give more errors/unexpected behavior in the long run then the way it is done now.

A mod that offers something like an RF api offers an API that allows mods to interoperate with each other. Libraries like this probably need to be shared. Although even here it would probably be better to have statically linked (potentially differing versions) of the rf api mod that inter operate using a strongly defined protocol over a message bus or something similar.

There is a class of api only mod - such as animation API (and presumably LLibrary) and others, where the features being provided are agnostic of how other mods are implementing similar features.

The point, previously made, is that code is actually cheap - the size cost of a mod is usually in the assets - especially as static linking typically allows the linking process to omit unused code.

 

[Chocohead]

remember when BuildCraft 6.1.5 was forced to break its API to restore an important feature and it broke Binnie's Mods for a few months, requiring me to create the world's hackiest workaround for FTB just so I didn't break Binnie's license?

*second hackiest. There are parts of Binnie Mods that mesh into Forestry 4 pretty ropey.

 

[KingTriaxx]

You mean the ones that require a third-party patch so the game doesn't self destruct?

 

[Chocohead]

You mean the ones that require a third-party patch so the game doesn't self destruct?

More than that, because there are methods that just have a parameter change type. And then there's the central multiblock class that has been nearly totally re-written to work with Forestry 4's new system but still work with the rest of Binnie's stuff. Or the dummy world that has to be used in order to work out the logs trees will grow with for the Arborist Database because the nice and simple getLogStacks method was removed. Bearing in mind all of this is in bytecode not Java itself. It was certainly fun doing it though.