Single out mod related code to child mods

[SvenKayser]

As discussed before: To make JMOD building easier, there is a request by nmarshall23 to single out mod related code to child mods.

[SvenKayser]

While I can definitely grasp the reasoning behind this, I'm not very fond of the idea, at least not at this point. Mainly because I'm not a big fan of mod clutter. Having several, possibly independently developed mod compatibility add-ons would certainly fill up the list of mods rather quickly.

Also considering that JMOD is nowhere near a stable API this would probably mean not only modpacks using old versions of JMOD to retain compatibility for their JMODs, but also, that those child mods would possibly arise in a multitude of versions for each version of JMOD - and worse comes to worst even in several versions to bind, for example, one for RoC 17a to JMOD 1.0.7, one for RoC 17a to JMOD 1.0.8, one for RoC 16d to JMOD 1.0.3 ... and so on. I guess you get where I am going with this. TL;DR: This is like inviting the clusterfuck to come and join the party, imo.

This also would require some sort of mechanism to "inject" those mods into JMODs scripting object. While that's all in all not super difficult to do, it would be something fairly low on my list of priorities. If you want to come up with a neat and simple solution, be my guest. But I want to reserve the right to decide if and when we are going there.

But, like always, I am open to good arguments, and I'm not resistant to being proven wrong.

[nmarshall23]

My contributions have been stymied by trying to figure how to build an Deobf version of Reika's DragonAPI, and Rotarycraft, etc.. I was using stub classes, but that isn't a great solution.

I tracked down it's dependences, but get visibly errors, Looks like Reika has ASM patches that need to be part of the minecraft source setup step.

Could you share how your dev environment is set up?

Back to this topic, I'm doubtful that JMOD will have versioning issues. If you look at Minetweaker, this was never a problem. There is ModTweaker which supports many of mods. Or you had very small addon mods that used a mod's api. I see far more mess having many mod api's intermingled with the core api.

I am looking to remove Minetweaker from my Modpack. At the moment Minetweaker, handles Railcraft, Immersive Engineering, Thaumcraft, and Apple, Milk & Tea2. Do you really want to have 4 more api's?

This also would require some sort of mechanism to "inject" those mods into JMODs scripting object.

I will take you up on this. At the moment, your branch of JMOD has bugfixes my ModPack needs.

Could you share how you are building with Reika's mods.

[nmarshall23]

I have found a way of setting up the required mods. Figures I would stumble on a solution soon as I asked for help.

I am currently porting features I had added while your were away, over to a clean repo. I will send you pull requests once I have tested them. Then I will get started on a prototype for this feature.

[nmarshall23]

I've been trying out the Nashorn Engine, and I have a few design questions.

Why import all of the actions into the script object? What if instead a JMOD Script had to import a package, For example:

var Rotarycraft = Packages.jmod.actions.Rotarycraft;
Rotarycraft.addBlastFurnaceRecipe("ingotBronze", 800, 10, 0, ["ingotTin", "ingotCopper", "ingotCopper", "ingotCopper"]);

I've tested this with a simple Java Object in an separate jar. The JMOD Script had no problem importing that Java Object.

My next step will be for the imported Object do a BasicAction.

[SvenKayser]

I've been considering this for a while and it has ups and downs.

Ups: Clearsly makes building this easier.

Downs: Shipping more files with the mods, making the actual js code more complex without any actual benefits for the user.

That minecraft even just blindly loads those jars is something I'm rather upset with (from a security perspective as a Java developer), but, on the other hand: I was planning to modularize parts of the mod anyways.

[SvenKayser]

Well, I've committed to this I guess. It's a bit more complex from a loading perspective, also would your approach effectively break "ownage" of certain script objects and therefore Actions and everything else that stems from that.

But I've used my AnnotationParser to identify so called ModBindings, which are basically normal mods bringing a few classes and their own scripting object.

It's a bit tricky, but it will work.

[SvenKayser]

Well, it will not since this would upset the loading process by an entire stage. So... well. I gotta figure a way to load those seperately.

[SvenKayser]

Since I wanted to finish plugin loading anyways.... Mod related code will now be sourced out into plugins. Plugins are compiled with the same tools a usual mod is, and they, logically, rely on JMOD (a jar is sufficient) to build, but other than that can be managed as a standalone project.

[SvenKayser]

A bit more info on why the complex plugin system in favor of simply just loading the Class as you proposed:

• I mentioned breaking ownership on objects. This is actually pretty important. Ownership determines which jmod an item or a block belongs to, and also reflects on the configuration of each jmod. While many arbitrary Actions will perform regardless of ownership, others won't.
• Having to put an extra line on top of each JMOD seems not very hard to do. But considering JMOD is set to be pretty damn fool-proof it makes things more complicated when it doesn't have to be.
• Mod related code actually appears at many more spots. Actions are the most prominent, but there is other mod related code (like the NEI integration) or even ASM Handlers (for Sync, for example).
• Either solution would have required the user to drop in an additional file, in your solution a .jar, in my solution a .jmodplugin. This gives better clarity what the user is dealing with (in my opinion), and also by actively controlling the loading process I am able to take control of it - which I use to pass on additional information shipped whit the plugin.

It's a boat load of complexity added, but it works actually pretty fine. The indev branch has working code for this already in it, even tho I am not finished singling out NEI and the ASM stuff - while I don't have a clear approach for the latter - yet.

[SvenKayser]

Driving this forward reveals why you approach really wouldn't have worked. There are so many deep links to mod related stuff in the code you still wouldn't have wed out that way.

Example: Calculating the correct item and the correct amount for the repair handler requires me to put in hooks in every plugin in case a plugin needs to alter that, in this case Chisel and EnderUtilities. Both introduce tools that require special handling.

It really is a lot of work doing that, and it's actually just shy of a rewrite.

[SvenKayser]

Closed (for the most part) as of https://github.com/SvenKayser/JMOD/commit/59d4cb91f6e030657d86c55d55e700fddfaf0b9d

[nmarshall23]

Thanks for looking into this. I agree this would require fundamental changes to how JMod works.

I also agree at this time, it's not worth the effort to make those changes.

[SvenKayser]

Actually it's already done. I'm at this moment working on merging your branch into jmod and single out your mod interfaces as plugins.