Jump to content
  • Home
  • Files
  • Docs
All Content
  • All Content

  • This Topic
  • This Forum

  • Advanced Search
  • Existing user? Sign In  

    Sign In



    • Not recommended on shared computers


    • Forgot your password?

  • Sign Up
  • All Activity
  • Home
  • Non-Forge
  • Site News (non-forge)
  • Regarding Minecraft 1.12, And policy changes.
  • Announcements

    • LexManos

      Forge 1.12 and Announcement   06/17/17

      Please read this: http://www.minecraftforge.net/forum/topic/58706-regarding-minecraft-112-and-policy-changes/  
Sign in to follow this  
Followers 18
LexManos

Regarding Minecraft 1.12, And policy changes.

Started by LexManos, June 17, 2017

23 posts in this topic

LexManos    1381

LexManos

LexManos    1381

  • Reality Controller
  • LexManos
  • Forge Code God
  • 1381
  • 8159 posts
  • Report post
Posted June 17, 2017

 

Minecraft 1.12:

The newest version of Minecraft has been released. Forge has been updated to support this new version. However due to the way Mojang implemented the Recipe changes there are a lot of under the hood changes that we need to do. Most notably re-writing on of the largest/most intricate systems of Forge, The Registry system. This will take some time, so do not expect a recommended release quickly. However if you are a modder you can start using the current versions to build against. Some API's may change in the early days of Forge so be sure to be ready for that. I'm sorry, I usually try my best to maintain binary compatibility, but it's just what will need to happen. For users, you can use the current builds. But just be warned that things are actively being developed and we ask to please responsibly report issues on the forum.


Once I finish the rewrite and get a stable recommended build of Forge out I will make a more detailed post listing all the major changes like I always do.

 

New Policy on Coremods:

Sadly core modding is still a thing. As always we request that you guys attempt to work with us to get changes into Forge instead of core modding it yourself. However, if you MUST we have decided to put forth to the community a few 'Best Practices' for core modding. The intention is that large communities such as FTB, Technic, and Curse work with us to promote these best practices.

 

1) Coremod must be the coremod only, and no extra library/features/apis/etc.
There are far too many coremods in the community that package tons of classes that have nothing to do with the modifications they make to the game together so that people will be forced to use their coremod just because they want a utility. This is bad. So Coremods themselves should be limited to JUST the IFMLLoadingPlugin, and IClassTransformers, and as few utility methods needed to make those hooks run.

 

2) Coremod binaries must be signed.

This is a very basic thing that just verifies the person/organization we think made the coremods actually did. It also verifies that the file that was downloaded has not been modified in any way. As it sits there will NOT be any central authority on the keys used to sign things. So Self-signing will be allowed as long as you provide the community your signature. Starting in 1.13, with the loading system rewrite, users will be prompted to accept signatures of coremods. It is our intention to work with people like FTB, Curse, and others to make these signatures easy to use and manage.

 

For example a user would say they trust FTB, and wouldn't be prompted for every coremod that exists in a FTB modpack.

 

For the technical side you can read more about Jar Signing here: https://docs.oracle.com/javase/tutorial/deployment/jar/signindex.html

 

3) Coremods should be visible source.

This will be a controversial standard, but my thoughts on it is that if you're screwing with someone else's code (which is the only reason to ever write a coremod), then you should be willing to show what you are doing. It is stressed that this is VISIBLE SOURCE only. It is not a requirement that you allow others to use your code, or modify and distribute it. It's simply that we can see it.

 

The signatures and visible source are NOT designed to be security measures. As there is nothing preventing malicious code from being signed and a user accepting it. This is just the risk you run with Minecraft modding as you're running compiled code from random people on the internet. This is however designed to make the community more open and try and stem the number of coremods out there that have no reason to be coremods.

 

Major Policy change:

 I am happy to officially announce a new member of the Forge team. Everyone welcome Mezz. His official responsibilities are to be the Pull Request, and Issues manager. Basically, he's the guy you yell at if your PR/Issue is rotting on github. He's the guy who is tasked with reminding me that they exists. He will be the one responsible for filtering all the PRs/Issues before they get to me. So I don't have to deal with telling you guys to follow the standards like making a test mod, posting logs, etc..

 

 In addition, he is also the one who decides if old versions will have PRs accepted. Yes this means there will be a limited development system for older versions. How far back that means is ENTIRELY up to Mezz. However the rules are that ANY pr adding features for a old version MUST be applied and accepted for the current version FIRST. Save for features that would have no place in the new version. Example being adding a new achievements hook when the new version removed achievements.

 

 It will still be our official stance on this forum to only provide support for the Current version, and the previous version. However, if the community wishes to have a few dedicated people step forward and become our Legacy support team them I am willing to work with them and see what we can set up. The main reason we do not provide support for old versions is simply we do not have the manpower. So start helping out!

 

Response From Sponge: 

 

  • Like 20

Share this post


Link to post
Share on other sites

xalcon    2

xalcon

xalcon    2

  • Tree Puncher
  • xalcon
  • Members
  • 2
  • 8 posts
  • Report post
Posted June 17, 2017 (edited)

For future reference

Quote

[23:05:07] <@LexMobile> FML has mechanics for extracting jars from jars
[23:05:15] <@LexMobile> So packaging to the end user is still the same

If I understand this correctly, we would be allowed to put the coremod into its own jar and put that jar into the actual mod jar. While this might not be very useful for modders that use a coremod in multiple mods, it might be useful if its only a change for a single mod.

Question I have: could you point me and others to the jar extraction mechanic FML provides? I dont intend on using a coremod at all, but just in case.

Edited June 17, 2017 by xalcon
  • Like 2

Share this post


Link to post
Share on other sites

jamierocks    2

jamierocks

jamierocks    2

  • Tree Puncher
  • jamierocks
  • Forge Modder
  • 2
  • 4 posts
  • Report post
Posted June 17, 2017

You certainly have my support in regards to the changes regarding coremods. For too long have mod authors, written coremods that prevent Forge doing its thing: promoting mod compatibility. It's inevitable that this new policy won't eradicate coremods, but perhaps it will make their authors think more carefully about the repercussions of making changes.

 

And in closing, I would like to congratulate Lex on reaching 7777 posts :D

  • Like 2

Share this post


Link to post
Share on other sites

vpontin    1

vpontin

vpontin    1

  • Tree Puncher
  • vpontin
  • Members
  • 1
  • 35 posts
  • Report post
Posted June 17, 2017

I really like the changes, mainly the open-source coremod requeriment. This is good because it encourages the open-source development.

  • Like 1

Share this post


Link to post
Share on other sites

Barteks2x    1

Barteks2x

Barteks2x    1

  • Tree Puncher
  • Barteks2x
  • Members
  • 1
  • 5 posts
  • Report post
Posted June 17, 2017

While I do support changes regarding coremod as the idea (and completely agree with points 2 and 3 as-written), I'm a bit confused as to what the first part says about coremods that just can't have the mod and coremod part separated without the whole thing blowing up when any part is used without the other. While I know it's probably nto common, I want to know what the first policy says about my mod. With cubic chunks I can't for example have my any part of the mod working without coremod, and the coremod part can't work without other parts of the mod. Well, I actually use mixin which uses a tweaker, but this is outside of my control (and I could stop using mixin but it would be huge amount of work and has more potential for me breaking things).

 

While in principle I could make the "coremod" part work by itself, it's not going to be of any use. If this really still applies in my case, I really hope it never becomes anything close to a requirement.

  • Like 1

Share this post


Link to post
Share on other sites

LexManos    1381

LexManos

LexManos    1381

  • Reality Controller
  • LexManos
  • Forge Code God
  • 1381
  • 8159 posts
  • Report post
Posted June 17, 2017

Feel free to explode if a coremod is installed without its handler mod.

We already have a mechanic for depending on other mods, so you can do normal dependency resolution.

Tweakers are considered coremods for this policy, Its all the same thing. As for Mixins I've already spoken to Mumfey and he's on board with this. He just needs to sign the Mixin library and he'll be good. However, Mixins is a special case in regards to #1. Its entire point is to be a library for other coremods so there isn't anything to 'separate' out. The intention is to stop coremods being required by mods who dont NEED them because they use a central/popular library.

  • Like 1

Share this post


Link to post
Share on other sites

PaleoCrafter    0

PaleoCrafter

PaleoCrafter    0

  • Tree Puncher
  • PaleoCrafter
  • Design Guru
  • 0
  • 1 post
  • Report post
Posted June 17, 2017

@vpontin: Note that this isn't a requirement for open source coremods, they have to merely be visible source. Like Lex outlines in the post, this does not mean that the code is open to be edited by the community or that it would have to be licensed under an open source licence. The only requirement is that people can look at the code in order to reason about it and understand it more easily.

Share this post


Link to post
Share on other sites

Barteks2x    1

Barteks2x

Barteks2x    1

  • Tree Puncher
  • Barteks2x
  • Members
  • 1
  • 5 posts
  • Report post
Posted June 17, 2017 (edited)
7 minutes ago, LexManos said:

Feel free to explode if a coremod is installed without its handler mod.

We already have a mechanic for depending on other mods, so you can do normal dependency resolution.

Tweakers are considered coremods for this policy, Its all the same thing. As for Mixins I've already spoken to Mumfey and he's on board with this. He just needs to sign the Mixin library and he'll be good. However, Mixins is a special case in regards to #1. Its entire point is to be a library for other coremods so there isn't anything to 'separate' out. The intention is to stop coremods being required by mods who dont NEED them because they use a central/popular library.

While I completely understand the intention and I agree with it (cubic chunks itself is being a "victim" of depending on coremod while the coremod part isn't needed, specifcially I optionally depend on MalisisCore for GUI). What you say is still a bit confusing and seemingly self-contradictory to me, but I will wait and see. Spong uses mixin too, so I will definitely see what they do. I'm in very similar situation here.

Edited June 17, 2017 by Barteks2x

Share this post


Link to post
Share on other sites

LexManos    1381

LexManos

LexManos    1381

  • Reality Controller
  • LexManos
  • Forge Code God
  • 1381
  • 8159 posts
  • Report post
Posted June 17, 2017

If you USE mixins, things should be baked down into metadata that Mixins{Mumfrey's library} loads. That data {Usually the compiled classes and whatever other metadata Mixins create} should be separate from your mod and signed. And the source code that generates that data should be visible in some way.

 

If you require a coremod in your main mod, Just add 'required: mymod_coremod' to your @Mod.

If you require a mod from your coremod {such as the handlers for the mixins you do} then you can add the mod as a dependency to the coremod.

  • Like 1

Share this post


Link to post
Share on other sites

Barteks2x    1

Barteks2x

Barteks2x    1

  • Tree Puncher
  • Barteks2x
  • Members
  • 1
  • 5 posts
  • Report post
Posted June 17, 2017

So I should have the mixin classes (what you called metadata) separate from the other part. Does forge support circular dependencies (coremod depending on mod and mod depending on that coremod)? If it does, then I can do that but it seems needlessly artificial and unnecessary separation to me. And the main reason I asked the question in the first place.

 

My whole mod is completely open source so I'm absolutely fine with source visibility here. And I was interested in signing my jar anyway, now I just have a good reason to do it.

Share this post


Link to post
Share on other sites

LexManos    1381

LexManos

LexManos    1381

  • Reality Controller
  • LexManos
  • Forge Code God
  • 1381
  • 8159 posts
  • Report post
Posted June 17, 2017

Yes, Forge supports mutual dependencies. As long as you don't define both requiring to load AFTER each other. It should just detect that ModA wants ModB in the list, and ModB wants ModA in the list. The intention of #1 is to allow those who care about coremods to go in and figure out what is relevant to the coremod, the things that edit bytecode. It's to help prevent people from hiding things amongst 500 different classes that don't touch bytecode. On top of that it is also a technical thing. If the coremod code is separate from the mod code we can better manage the classpath and classloaders. We have had many issues over the years of people including APIs in coremod. Which screws over our ability to sort and verison APIs so that the one available is the one people want.

 

I kinda expect that once people see start using the Jar-in-Jar stuff, {which I admit needs fleshing out and documentation} that people will stop fat-jaring APIs but instead include them as a internal jar. And let Forge pull out the ones that best suit the environment based on what mods say they need.

  • Like 1

Share this post


Link to post
Share on other sites

Zidane    4

Zidane

Zidane    4

  • Tree Puncher
  • Zidane
  • Members
  • 4
  • 1 post
  • Report post
Posted June 17, 2017 (edited)

I don't speak for the whole community but since I am a leader of Sponge, I'll throw my 2 cents in by first saying that yes, SpongeForge will be adjusted to comply. We find these changes to be a good-faith effort to make some wholesome changes to the ecosystem as an attempt at dealing with the elephant in the room: coremods. SpongeForge falls under a coremod which will not function at all without its core changes but, as Lex has mentioned above, we can simply make the core portion not function at all should the whole thing not be here and throw up a descriptive error to say why. Expect to see some changes land in the next couple of days (when someone gets some time) on Sponge's end to make this change.

Edited June 17, 2017 by Zidane
  • Like 4

Share this post


Link to post
Share on other sites

gabizou    3

gabizou

gabizou    3

  • Tree Puncher
  • gabizou
  • Members
  • 3
  • 8 posts
  • Report post
Posted June 18, 2017

Chiming in as one of the other leaders of Sponge, I've always believed that making heavy modifications to the game (as coremods sometimes do) would benefit from being viewed source, since often times debugging odd interactions between SpongeForge (and SpongeCommon as the larger part) have been often times difficult to say the least to work out where the issue lies. That being said, I strongly support the idea around coremods being viewed source for the sake of inter-coremod compatibility overall, as the goal with SpongeForge has always been about remaining compatible with as many mods as possible out of the box (even if the technological attempts at maintaining that compatibility is not as evident or thought up very fast). As @Zidane has mentioned, SpongeForge will be making the necessary changes in the very near future to abide by these requirements. As per usual, my goal with inter-mod compatibility is always to provide as much descriptive console spam error logs to help Sponge and/or the mod itself get a better fix and make the users happier overall.

  • Like 3

Share this post


Link to post
Share on other sites

Alexiy    18

Alexiy

Alexiy    18

  • Creeper Killer
  • Alexiy
  • Forge Modder
  • 18
  • 180 posts
  • Report post
Posted June 21, 2017
On 6/17/2017 at 11:47 PM, LexManos said:

Coremods should be visible source.

Don't you think that this will also cause an increase of coremods, because more people will learn how to use ASM? 

I would add another recommendation for coremod makers - just provide configs for coremods with options to disable them or some of their features.

Share this post


Link to post
Share on other sites

LexManos    1381

LexManos

LexManos    1381

  • Reality Controller
  • LexManos
  • Forge Code God
  • 1381
  • 8159 posts
  • Report post
Posted June 21, 2017
2 hours ago, Alexiy said:

Don't you think that this will also cause an increase of coremods, because more people will learn how to use ASM? 

I would add another recommendation for coremod makers - just provide configs for coremods with options to disable them or some of their features.

That may be a concern, there will always be copy pasta. But Honestly that is easy enough to do these days and SUPER easy to do wrong. So I think itd probably just increase the quality of the copy pasta.

As for config stuff, that is to specific, we're not saying ANYTHING about functionality. Just guidelines on packaging.

Share this post


Link to post
Share on other sites

Draco18s    1777

Draco18s

Draco18s    1777

  • Reality Controller
  • Draco18s
  • Members
  • 1777
  • 11653 posts
  • Report post
Posted June 21, 2017
14 hours ago, Alexiy said:

Don't you think that this will also cause an increase of coremods, because more people will learn how to use ASM? 

I would add another recommendation for coremod makers - just provide configs for coremods with options to disable them or some of their features.

I don't think so. Modifying code via bytecode manipulation requires extensive knowledge of the JVM stack and instruction set. You can't really "copy-paste" an injection and expect it to work on a new class. It might work, it might not. 

 

To Lex:

I support these changes. I will continue to advocate that things should be done through forge and will likely not help people learn how to use ASM, at least not in a public setting, but I would instruct (to the best of my ability) how to coremod safely. I did a lot of it in 1.7.10 (and I'm not necessarily proud of it) and for the folks that merit knowing should be informed. Maintaining compatibility is important.

 

The one thing we will want is an easily accessible guide on signing jars and how to share the singing details correctly. It definitely isn't something i know how to do off the top of my head and I'm not confident that I'd be able to search out a solution either. (Can I search, sure, but I read between the lines that there might be a step that has to be done a certain way and don't know if I would be able to find details).

 

I'm also glad to see the appointment of someone to handle lingering PR requests and filtering, I know I had some that took a while to be approved. Even if in some cases it was my own fault for not following the guidelines, but again, best practices aren't something most people can pick up in an afternoon. Its easy to make mistakes (like knowing that X mistake was made in several places) and I know you don't have much time to impart that knowledge yourself. Don't hesitate to find a few helpers for Mezz, as well. Don't want to see him getting bogged down either. 

  • Like 1

Share this post


Link to post
Share on other sites

TheRPGAdventurer    1

TheRPGAdventurer

TheRPGAdventurer    1

  • Diamond Finder
  • TheRPGAdventurer
  • Members
  • 1
  • 425 posts
  • Report post
Posted July 23, 2017
On 6/18/2017 at 6:03 AM, vpontin said:

I really like the changes, mainly the open-source coremod requeriment. This is good because it encourages the open-source development.

yeah! no more of those kids with cool mods being greedy. There is no reason for my minecraft mods to be copyrighted.

  • Like 1

Share this post


Link to post
Share on other sites

diesieben07    5803

diesieben07

diesieben07    5803

  • Reality Controller
  • diesieben07
  • Forum Team
  • 5803
  • 37019 posts
  • Report post
Posted July 23, 2017
3 hours ago, TheRPGAdventurer said:

There is no reason for my minecraft mods to be copyrighted.

Open Source and Copyright are entirely different things and live independently.

Share this post


Link to post
Share on other sites

TheRPGAdventurer    1

TheRPGAdventurer

TheRPGAdventurer    1

  • Diamond Finder
  • TheRPGAdventurer
  • Members
  • 1
  • 425 posts
  • Report post
Posted July 23, 2017
Just now, diesieben07 said:

Open Source and Copyright are entirely different things and live independently.

oh ok!

Share this post


Link to post
Share on other sites

Mecha_Shadow    0

Mecha_Shadow

Mecha_Shadow    0

  • Tree Puncher
  • Mecha_Shadow
  • Members
  • 0
  • 4 posts
  • Report post
Posted July 26, 2017

I'm very new to all of this, but from what I understand, forge needs to be rewritten to support this new loading format that Minecraft is using, yes?

Share this post


Link to post
Share on other sites

18107    1

18107

18107    1

  • Tree Puncher
  • 18107
  • Members
  • 1
  • 10 posts
  • Report post
Posted August 1, 2017
On 18/06/2017 at 6:17 AM, LexManos said:

As always we request that you guys attempt to work with us to get changes into Forge instead of core modding it yourself.

How would I go about doing this?

 

I have been working on a coremod that causes the game to render the world 6 times per frame. Is this something that should have forge hooks for it, or is it better to use a coremod?

  • Like 1

Share this post


Link to post
Share on other sites

LexManos    1381

LexManos

LexManos    1381

  • Reality Controller
  • LexManos
  • Forge Code God
  • 1381
  • 8159 posts
  • Report post
Posted August 1, 2017
2 minutes ago, 18107 said:

How would I go about doing this?

https://github.com/MinecraftForge/MinecraftForge

  • Like 1

Share this post


Link to post
Share on other sites

avab    0

avab

avab    0

  • Tree Puncher
  • avab
  • Members
  • 0
  • 1 post
  • Report post
Posted Thursday at 09:23 PM

okay cool i agree

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  
Followers 18
Go To Topic Listing Site News (non-forge)

  • Recently Browsing

    No registered users viewing this page.

  • Posts

    • DaemonUmbra
      I download installer for 1.7.10 and it comes up with 1.12.2

      By DaemonUmbra · Posted 41 minutes ago

      I'd recommend you take a look at the StopModReposts project: http://stopmodreposts.org/
      Note: They already have this site blacklisted.   Disclaimer: This is my own personal recommendation and is not in any way a recommendation from Forge.
    • NickBurnett
      How can I spawn in entities with a 2D model like this mod?

      By NickBurnett · Posted 43 minutes ago

      @Draco18s   Well obviously, however I'm wondering if I could get a quick rundown example of how this would work. I'm not asking for anything too serious, just an idea of what my could should be similar to that way I have structure to go off of.
    • DaemonUmbra
      Install Forge - "libraries failed to download" Scala - Raspberry Pi Raspbian

      By DaemonUmbra · Posted 50 minutes ago

      I do not recommend downloading the libraries manually, try this solution instead:  
    • DaemonUmbra
      error mesage when installing forge 1.12.2 - 14.23.3.2670

      By DaemonUmbra · Posted 52 minutes ago

      Do not download libraries manually, try the solution suggested here:  
    • xTekBlue
      Recipe Help

      By xTekBlue · Posted 1 hour ago

      Okay, thanks. You two helped a lot. Mod is turning out great 
  • Topics

    • ItsObvious
      3
      I download installer for 1.7.10 and it comes up with 1.12.2

      By ItsObvious
      Started 9 hours ago

    • NickBurnett
      4
      How can I spawn in entities with a 2D model like this mod?

      By NickBurnett
      Started 10 hours ago

    • Raspomain
      3
      Install Forge - "libraries failed to download" Scala - Raspberry Pi Raspbian

      By Raspomain
      Started Saturday at 08:23 AM

    • Ajblanco
      6
      error mesage when installing forge 1.12.2 - 14.23.3.2670

      By Ajblanco
      Started 11 hours ago

    • xTekBlue
      20
      Recipe Help

      By xTekBlue
      Started Yesterday at 02:14 AM

  • Who's Online (See full list)

    • TreyRuffy
    • Choonster
    • DaemonUmbra
    • screamingwil
    • jhdoran
  • All Activity
  • Home
  • Non-Forge
  • Site News (non-forge)
  • Regarding Minecraft 1.12, And policy changes.
  • Theme
  • Contact Us

Copyright © 2017 ForgeDevelopment LLC Powered by Invision Community