Content/Cross-Mod Compatibility in Forge/A Forge Sister-Mod?

  • Please make sure you are posting in the correct place. Server ads go here and modpack bugs go here
  • 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

What Sort of Content should Forge Have?

  • Nothing. Forge is fine as an API.

    Votes: 24 70.6%
  • Forge should implement ore generation - I'm sick of having 8 types of copper.

    Votes: 4 11.8%
  • Forge should implement Tinker's Construct - style tool creation. It should be in Vanilla, too!

    Votes: 0 0.0%
  • Forge should implement optimizations from mods like Fastcraft.

    Votes: 10 29.4%
  • Forge should implement Dual-Wield - everyone wants it, but only Forge can make every mod support it.

    Votes: 0 0.0%
  • All of the Above! (except 'Nothing,' of course)

    Votes: 1 2.9%
  • Forge should implement client mods like NEI or InvTweaks - most people download them anyway.

    Votes: 0 0.0%

  • Total voters
    34

Type1Ninja

New Member
Jul 29, 2019
1,393
-7
0
EDIT: Clearly, everyone disagrees with me. I suppose my idea is too communist to work (as in, it's literally communist in the way it works :p).

DOUBLEEDIT: A lot of this is deprecated, see that last few pages of discussion for updates on the idea in general


Background: I make a modpack. Only recently have mods begun to have true compatibility with each other, with - on the tech side - more or less everything running off of RF (magic hasn't really caught up yet, though I'll have to look into Botania). However, my desire for compatibility, sparked in the dark ages of nothing-works-with-anything-else, is still present and growing. Here's what I (personally) would like to see, and I would like to know if other people agree with me.

I would like to see Forge begin implementing more content-oriented updates, in order to (rather rudely) push modders into coding compatibility into their mods. For example, Forge could take over ore generation entirely - guaruntee having only one type of copper, as config files can only do so much. Or, they could eat Tinker's Construct, making it so that every mod now adds it's tools not as items but as a set of stats/modifiers for a new tool material (Fluxed Electrum Tinker's tools, here I come!). Another thing - perhaps the biggest - that I would like to see is the RF API being implemented into forge. UNIVERSAL POWER! PLEASE! *sobs*
(To be fair, RF is doing a good job - there's just a few outlier mods that refuse to join the glob *cough* ICBM *cough*)

Something I would like to see is the official implementation of a Dual-Wield system. We all want it, but the only mods that add it don't have a very good compatibility record. Only Forge really has an impact universal enough to make every mod compatible with a Dual-Wield system.
The integration of every optimization mod ever would be nice. No more "This pack contains fastcraft" - that would become a given, and everyone's computers would run better for it.

I'm out of ideas as to which mods or types of mods should be assimilated - anybody else have any?

As to whether copyright would be respected throughout all of this, I don't know. Lots of modders are nice enough to at least semi-cooperate, and some of them probably wouldn't mind simply joining Forge in an official capacity to continue developing their mod.

And, when they've finally done all that, Mojang/Microsoft proceeds to eat Forge and the food-chain of coding is finally complete. The Forge people are hired into Mojang - finally, a modding API developed for modders, by modders.
... The worst part of that is that it could be taken seriously.
 
Last edited:

Padfoote

Brick Thrower
Forum Moderator
Dec 11, 2013
5,140
5,898
563
Ore generation built into Forge has been debated to death on these forums before. I would link examples, but posting links on my phone is a pain. In short, it will never happen.

A single universal power system has also been debated to death. There are mods that should not be on a universal power for their own balance or other reasons, such as RotaryCraft and IC2.

Dual wielding is a buggy system when implemented in MC. I'd rather not see it baked into Forge. Personally, I'd rather never have it in a pack I use.
 

pizzawolf14

New Member
Jul 29, 2019
566
0
0
I don't mean to offend, but, in my opinion, it'll be a dark day when forge incorporates content into it. There's a ton of reasons, but I'll give you the first two that pop into my mind.

1) It will likely mean the end of new ideas in mods. With the api that is the base of every mod worth playing turned into a restrictive specific universal currency system, modders would probably find it a lot harder to make their own, creative, new power systems. Also, the ones that are persistent enough to do so will get more heat than your brand new smeltery.

2) It will likely mean the end of player creativity. If everything uses the same power, same tool system, same ore gen, and the same balance to account for the double damage available from dual welding, players will find themselves constantly going down the same path. The game would lose a ton of what makes Minecraft a game I can come back to no matter what the circumstances are: replayability.
 

Type1Ninja

New Member
Jul 29, 2019
1,393
-7
0
I don't mean to offend, but, in my opinion, it'll be a dark day when forge incorporates content into it. There's a ton of reasons, but I'll give you the first two that pop into my mind.

1) It will likely mean the end of new ideas in mods. With the api that is the base of every mod worth playing turned into a restrictive specific universal currency system, modders would probably find it a lot harder to make their own, creative, new power systems. Also, the ones that are persistent enough to do so will get more heat than your brand new smeltery.

2) It will likely mean the end of player creativity. If everything uses the same power, same tool system, same ore gen, and the same balance to account for the double damage available from dual welding, players will find themselves constantly going down the same path. The game would lose a ton of what makes Minecraft a game I can come back to no matter what the circumstances are: replayability.
Ore generation built into Forge has been debated to death on these forums before. I would link examples, but posting links on my phone is a pain. In short, it will never happen.

A single universal power system has also been debated to death. There are mods that should not be on a universal power for their own balance or other reasons, such as RotaryCraft and IC2.

Dual wielding is a buggy system when implemented in MC. I'd rather not see it baked into Forge. Personally, I'd rather never have it in a pack I use.
True. Well... I guess I can dream, right? :p

(As for dual wielding, would it be cool if it weren't buggy? The reason it's such a pain to use is that it isn't developed with other mods in mind.)
 

Padfoote

Brick Thrower
Forum Moderator
Dec 11, 2013
5,140
5,898
563
(As for dual wielding, would it be cool if it weren't buggy? The reason it's such a pain to use is that it isn't developed with other mods in mind.)

Not really, no. I've used it in plenty of other games where it was fully fleshed out and it still wasn't that cool.
 

Kotaro

New Member
Jul 29, 2019
66
0
0
Forge should be nothing more than an API. Baking gameplay changing elements in this could force everyone down a certain path.

For an example, while RF is very useful as a uniform power system, it shouldn't be forced upon everything. That would limit creativity in power systems. Sure, you could still make one, but it would always be "I have this neat power system. Oh yeah, RF comes with it too.."
 

pizzawolf14

New Member
Jul 29, 2019
566
0
0
Going to expand on what I said earlier. I think that, by all means, there should be compatibility between mods, but only where it fits, and only if it is implemented as seamlessly as can be. In my opinion, the answer doesn't lay with forge. I think that it is up to the modders to decide to make thermal expansion metallic tool parts, and that the author should choose if he wants to use the rf power system or not.
 

KhrFreak

New Member
Jul 29, 2019
689
1
0
the only thing i could ever see being added to forge like this is Forge Multipart and that's only if it gets a rewrite into java instead of scala (and hopefully becomes less buggy.) other that that i would be really disappointed in the forge team if they started to add content like that into Forge
 
  • Like
Reactions: Padfoote

malicious_bloke

Over-Achiever
Jul 28, 2013
2,961
2,705
298
Content, no.

Crossmod compatibility, already handled by other mods to some extent.

AOBD works for most things, CofH core can handle worldgen for pretty much anything in existence and universal cables exist.

No need for forge to enforce something like this.
 

Bibble

New Member
Jul 29, 2019
1,089
0
0
Ok, I think I'd agree with most on here, that content is a no-no. There should be nothing in Forge that the user can see (otherwise you risk one set of people not liking it and avoiding forge, causing divisions).

Now, as far as cross-mod support goes, it's an interesting one. On the one hand, I like the idea of a "universal backpane" for these things. Something to act as a common backing, no matter whether it's the thing that their mods themselves use, or interface with (as with the interface to EU and MJ). The problem here arises with standards and naming. You can't have an energy api without also dictating the naming and transmission types (see the differences between old MJ, RF and EU for how different they can be). This is worse with magic mods, as mana, aura and magic are used in many different ways, by many different mods, all intrinsic to the very nature of the mod.

Possibly a better idea would be a separate project (Anvil, maybe), with some standardised systems (isCrushable, recipe dictionaries, power, components, etc.). Not something that anyone is forced to use, but something that might save some effort recoding the same material time and again.
 
  • Like
Reactions: Type1Ninja

Type1Ninja

New Member
Jul 29, 2019
1,393
-7
0
This is worse with magic mods, as mana, aura and magic are used in many different ways, by many different mods, all intrinsic to the very nature of the mod.

Possibly a better idea would be a separate project (Anvil, maybe), with some standardised systems (isCrushable, recipe dictionaries, power, components, etc.). Not something that anyone is forced to use, but something that might save some effort recoding the same material time and again.
I agree that Magick-y mods wouldn't really benefit from this: most of them are already really different.
A separate project is probably the best way to do this, but it would need to be really well advertised to catch the attention of enough modders to become truly universal.
Otherwise, this will happen: https://xkcd.com/927/
And that, really, is the only reason why forge would ever add anything in the first place. They're the only group guaranteed a large enough reach to make sure that we don't just gain standards continuously (which technology did for a while, as you pointed out - MJ, RF, EU,UE... ).

Other than that (not to quoted person), YES, I get that NO CONTENT should be added to forge. STOP SAYING THAT! I guess I get the idea. :(
 

Bibble

New Member
Jul 29, 2019
1,089
0
0
I agree that Magick-y mods wouldn't really benefit from this: most of them are already really different.
A separate project is probably the best way to do this, but it would need to be really well advertised to catch the attention of enough modders to become truly universal.
Otherwise, this will happen: https://xkcd.com/927/
And that, really, is the only reason why forge would ever add anything in the first place. They're the only group guaranteed a large enough reach to make sure that we don't just gain standards continuously (which technology did for a while, as you pointed out - MJ, RF, EU,UE... ).

Other than that (not to quoted person), YES, I get that NO CONTENT should be added to forge. STOP SAYING THAT! I guess I get the idea. :(
The problem is that that isn't how things work in modded minecraft. Something has to be popular before being standardised. That's why RF is the current power standard, Thermal expansion was standard in most packs back when it was using MJ, then they realigned the theories behind MJ back to it's original intention, so they made RF, which was basically MJ, but using the storage-capable philosophy that TE used before. This was well coded, and with decent APIs, so mods began supporting it to the point where it became easier to just tap into RF, rather than build your own power system.

There had been attempts before to unify power systems (as I recall, Universal Electricity had that as it's main intention), but there was no reason to actually install it, it added nothing other than complication.

Baubles are another good example. Thaumcraft was widely used, and Azanor simply added baubles as a standalone API that anyone could tap into, and they did, because it was going to be in any pack that the mod was in anyway.

If, for instance, Forge added a few methods here and there (isGrinable, etc.), and, once people were using them, budded it off into it's own project, that would be the only way I really see anything like this working.

But that's me, with barely any time to play the game, let alone get into the coding and politics of modding, so what do I know? I'm not going to sign people up for work they don't want or need.

EDIT: And, "Content in Forge" is in the title, that is the original topic, so people are going to feel like they probably at lest kinda need to weigh in on that part.
 

ScottulusMaximus

New Member
Jul 29, 2019
1,533
-1
1
Thermal expansion was standard in most packs back when it was using MJ, then they realigned the theories behind MJ back to it's original intention, so they made RF, which was basically MJ, but using the storage-capable philosophy that TE used before.

Err no... The ENTIRE point of MJ was that it couldn't be stored. As soon as TE added a way to store it the MJ API became irrelevant and an annoyance to users because it's entire premise was on demand production.
 
  • Like
Reactions: pizzawolf14

Bibble

New Member
Jul 29, 2019
1,089
0
0
Err no... The ENTIRE point of MJ was that it couldn't be stored. As soon as TE added a way to store it the MJ API became irrelevant and an annoyance to users because it's entire premise was on demand production.
Two things. Firstly, the first part of what you said was my point. TE was using MJ, when it was just an energy source to use (and the choices were either EU, MJ or Blutricity), but was not using it in the way that it was intended. The MJ system was realigned and enforced back to it's originally intended function, at which point TE began with RF. RF worked functionally the same as they'd been using MJ, which was not how MJ was intended to be used.

I'd argue that the philosophies of MJ are still applicable, but the scale is wrong. By the time that most players build systems that follow MJ principles, you're talking about steam (constant production at the top end of what's needed), whether through boiler or reactor. MJ works well for buildcraft machines (filler, quarry, mining well, etc.), but when you try adding in the power creep of cross-mod compatibility, it falls over due to the now small scale of it. By the time players use generation-focussed power systems, they're already intrinsically tied to RF.

I like MJ, and I like the theory behind it, but other mods just kind of outgrew it. It's not really an annoyance, it's just different.
 
  • Like
Reactions: pizzawolf14

ScottulusMaximus

New Member
Jul 29, 2019
1,533
-1
1
Two things. Firstly, the first part of what you said was my point. TE was using MJ, when it was just an energy source to use (and the choices were either EU, MJ or Blutricity), but was not using it in the way that it was intended. The MJ system was realigned and enforced back to it's originally intended function, at which point TE began with RF. RF worked functionally the same as they'd been using MJ, which was not how MJ was intended to be used.

I'd argue that the philosophies of MJ are still applicable, but the scale is wrong. By the time that most players build systems that follow MJ principles, you're talking about steam (constant production at the top end of what's needed), whether through boiler or reactor. MJ works well for buildcraft machines (filler, quarry, mining well, etc.), but when you try adding in the power creep of cross-mod compatibility, it falls over due to the now small scale of it. By the time players use generation-focussed power systems, they're already intrinsically tied to RF.

I like MJ, and I like the theory behind it, but other mods just kind of outgrew it. It's not really an annoyance, it's just different.

Aaaah, I misunderstood your post then...
 

WTFFFS

New Member
Jul 29, 2019
768
0
0
Forge handling Ores would be good, mod x calls for copper\tin\silver, Forge generates them, mod y and g also use them already done mod c has a specialised ore only it uses mod c has to handle it's own gen pretty much what CoFH does now but enforces only one type without me having to go into the configs and disable 4 different types of bloody copper. (and then forgetting one type and having to restart the world OR run everything through a unifier of some sort)
 

Bibble

New Member
Jul 29, 2019
1,089
0
0
Forge handling Ores would be good, mod x calls for copper\tin\silver, Forge generates them, mod y and g also use them already done mod c has a specialised ore only it uses mod c has to handle it's own gen pretty much what CoFH does now but enforces only one type without me having to go into the configs and disable 4 different types of bloody copper. (and then forgetting one type and having to restart the world OR run everything through a unifier of some sort)
There are two sides to this, though. Obviously the ore dictionary is already a big part of Forge, but there's also the issue that having Forge simply take over the oregen as standard becomes tricky, different mods need different amounts of things. Imagine making an old Factorization solar mirror array with typical silver ore gen, or coping with IC2's iron-heavy requirements without bumping the generation for it at all.

Forge shouldn't simply enforce it's own view of oregen on things without giving the mods some way of influencing it.
 
  • Like
Reactions: pizzawolf14

WTFFFS

New Member
Jul 29, 2019
768
0
0
There are two sides to this, though. Obviously the ore dictionary is already a big part of Forge, but there's also the issue that having Forge simply take over the oregen as standard becomes tricky, different mods need different amounts of things. Imagine making an old Factorization solar mirror array with typical silver ore gen, or coping with IC2's iron-heavy requirements without bumping the generation for it at all.

Forge shouldn't simply enforce it's own view of oregen on things without giving the mods some way of influencing it.
Valid point hadn't thought about that part of it so yeah bad idea that way maybe let the mod gen then forge converts that would take care of it so a post-gen ore dictionarying but pre-load .... hmm yeah nah overly complex solution to a minor problem lol