Jump to content

LexManos

Forge Code God
  • Posts

    9270
  • Joined

  • Last visited

  • Days Won

    68

Posts posted by LexManos

  1. Forge doesn't have any management over what mods you run.

    If you want to hire someone to write a mod for you, that's between you and them.

    We don't care, nore do we want to be involved in that situation at all.

    But as a warning, the community in general doesn't take kindly to any form of DRM, so don't do it.

  2. Update Regarding LTS System:  Please read

     

    The Big Forge Update


    Earlier this year, 1.13 was announced and the snapshots started coming out, the update was relatively small, but enough to be a hurdle for mod developers. This combined with 1.12 stabilizing, and a few fundamental Java changes that broke modding in general, made the Forge team decide to use this opportunity and work on cleaning the years of technical debt that Forge had accrued.


    During this time, it was discovered that a lot of things needed updating. In fact, well, everything did. And so, it was done, a full rewrite of practically everything Forge related. This took a long time, longer than originally anticipated. But what’s the outcome of this you might ask? A lot.


    cpw’s mod launching system (ModLauncher) allows for parallel mod loading and support for more modern Java versions. (Considering the original was written to target Java 6). The Forge installer now runs tasks at install time once, rather than doing it every time you run the game. These alone provide dramatic reduction in launch times. ForgeGradle, the “devkit” for creating mods, has been rewritten and is faster at, well, everything. It also integrates much better with IDEs. What does that mean, you ask? Simple. Mods are nicer to make. (Also 100% less setupDecompWorkspace.) MCPConfig allows for much easier MCP updates, and is public source too, so people can see exactly what's going on between updates.

     

    In short: There was a lot of work to do. And now that it's done, future updates will be much, much smoother.

     

    1.14 and 1.15


    The 1.14 release came around, just in time for the rewrite to be finished, so it was time to get the ball rolling again. The bulk of the restructure work was done through 1.13's life, so all that remained was actually seeing how it was to update all of it, and it went pretty well. A lot of improved systems exist now that make developing for these modern versions far easier and just better in general.


    The 1.15 release was relatively simple, even if Mojang decided to restructure everything and make changes to how the rendering works. (Taking some of our systems in the process, don't worry, this is a good thing.) 1.15's rendering changes were mostly a refactor, and we expect 1.16 to be a large update to rendering. This plus 1.14 seeing growth is why we chose 1.14 to be a candidate for LTS. (More on that further down.)


    Hopefully this kind of restructure from them is a rare thing in the future, but we welcome the change, since it often brings improvement. Although the rendering changes may pose a tough hurdle for some, the update for most should be relatively straight-forward.

     

    Forge support and LTS


    Forge's support for Minecraft versions will try to follow a predictable cycle, assuming Mojang also follows a predictable cycle. We will always actively target the latest Minecraft version, as ever. We will now also deem a previous major Minecraft version as "LTS" (Long Term Support). The LTS version will receive support for modders and players alike, however all new features must target the latest version first, and then may be backported.


    An LTS version differs slightly from the latest version, in that any new features you may want to add to it, must target the latest version, only once it has been merged in, can it be backported. (The exception to this is if the feature is non-applicable to the latest version.) The Forge Team will also mostly be focusing on the latest.


    This is so the community has time to stabilize a bit and gives modpack developers some time to create something special. But still have Forge running full steam ahead.
    Late last year (Happy 2020!) a vote was held privately with many developers of various Minecraft projects to determine which version will be LTS: Should 1.12 remain LTS or should 1.14? A vast majority chose 1.14, and so, from now on we are dropping 1.12 from support, and 1.14 is now LTS.

    What does this mean?


    1.15 is latest. It will get full support.
    1.14 is LTS. It will also get support, and new features, but new features must be made for 1.15 first.

    1.12 is no longer supported on this forum, no new features, and no more bugfixes.


    All other versions are not supported. This means if you come to us for help with those, we will ask you to update. This includes crashes/bugs.


    To keep with Mojang's history of releases, we expect 1.14 to stay LTS for 12-18 months, giving plenty of time for modders and pack developers alike. However, this may change depending on what surprises Mojang has in store for us.

     

    Finally…


    Thank you. Thank you to all the modders/developers, all the players, and especially to all the contributors. The Minecraft modding community would not be what it is without you. You are responsible for the striving ecosystem we have today.
    We hope this new year brings you all you desire, and we look forward to seeing what you create.

     

    And now time for some shameless plugging, if you like Forge, please consider supporting us. http://www.patreon.com/lexmanos


        - The Forge Team.
     

    • Like 19
    • Thanks 8
    • Haha 1
    • Confused 1
    • Sad 6
  3. It is explicitly against Mojang's instructions to sell capes.

    Plus, it's the ONE thing they have, let them have it.

    As for Notch having a Optifine cape, that means nothing. They can add anyone to their list. Doesn't mean the person supports them. Also Notch has nothing to do with Minecraft anymore.

     

    Also, this is a English forum, speak english, this goes for diesieben's quotes as well.

  4. 1.15 has been more challenging then previously expected. Instead of just being adding bees, and fixing bugs as reported by Mojang. They decided to take this release to re-write most of the rendering engine. Unfortunately, they also took the rendering guy from the Forge team. And my weakest point has always been, you guessed it, rendering. So it's being quite difficult to sort through all the changes, and update our massive changes to reflect the new stuff. gigaherz, tterrag, and unneon are trying to get up to speed and sort through all the rendering changes. So far, we've processed 512 out of the 520 patch files Forge does. As well as brought the compile errors down from >1400, to 161. So, progress is being made. Unfortunately, not publicly as before we get it compiling the repo we're working in contains the full MC decompiled codebase. And we do not have legal authority to redistribute that, so we're working on it privately. 

     

    Hopefully, we'll have a build working and published here shortly, we're hoping that it won't be as broken as it could be. We'll keep you informed when there is something to inform.

     

    As for the mapping data, we've already answered this, Mojang's release under the license you quoted does NOTHING to help us and only helps those who do not respect their license {Hacks/pirate clients/malware}. We are STILL holding out hope that Mojang's lawyers will come back with a new license that actually allows us to use this data.

    • Like 1
    • Thanks 2
  5. 28 minutes ago, JetCobblestone said:

    Ok so first question, itemList.hair fibre it registering the new item, but is also telling it to look in the file itemList to look for what the item is.

    No.. No it's not.. it's attempting to assign a variable. It's nothing to do with looking into a file or anything. Please look into the basics of variables, fields, and what assignments are.

    28 minutes ago, JetCobblestone said:

    And so what you're saying, the @ symbol is telling forge to read this file? Thanks for the tips

    No... @ is just how annotations work. Go look into what annotations are.

  6. 10 minutes ago, JetCobblestone said:

    I also import the item list I have, so it knows the data for the items which I'm trying to load.

    `itemList` -> First, you should never name a class using lowercase as the start. You should read this: https://www.geeksforgeeks.org/java-naming-conventions/

     

    10 minutes ago, JetCobblestone said:

    I then start the actual code by opening a public class, so that it can be accessed by the main.

    If you're in the same package, it doesn't need to be public, but public is good for other reasons.

     

    10 minutes ago, JetCobblestone said:

    I then set the variable modid, so that I can easily change the name of my mod if needed. I did this in the main, but I couldn't seem to access it from there in this class, despite it being public.

    Then you didn't actually reference the field, you need to understand the basics of referencing fields from other classes.

     

    10 minutes ago, JetCobblestone said:

    I then open a public static void method so I can call upon the code in my main programme. I set it as static, as nothing in it changes, and as a void as it returns nothing, just registers the items.

    is is class... oh wait no,  you're talking about your original code. You can't have a class inside a method. Also, 'static' has nothing to do with 'nothing in it changes', it is a access modifier, it means that you don't need to have a instance of the containing class to refernece the method/field. You can call it directly.

     

    10 minutes ago, JetCobblestone said:

    Next we are telling forge that this is a registration event, so it knows I'm trying to register items.

    Yup, this will automatically scan the annotated class and register everything to the event bus. Making every annotated event function inside be called for the proper event.

    10 minutes ago, JetCobblestone said:

    The next class is where I get lost. Tbh I don't know why it's there but that's what tutorials told me to do, they didn't explain it ?  I think the name is important?

    THIS IS A PROBLEM! Stop copy/pasting code from 'tutorials' if the 'tutorial' doesn't teach you WHY the code exists then it's a horrible tutorial and you should not use it.

    The @EventBusSubscriber annotation goes on classes, it then scans the entire class for any static method that has the SubscribeEvent annotation and automatically adds them to the eventbus specified in the EventBusSubscriber annotation. That annotation can go on ANY class, it doesn't need to be a class inside a class. So you could simplify your code a lot.

    10 minutes ago, JetCobblestone said:

    We're then telling forge, ok this is the part we're registering.

    Good, that's what SubscribeEvent does yes.

     

    10 minutes ago, JetCobblestone said:

    We then open a method to contain all the items being registered.

    Then we say: register all of these

    Then we say what we want to register and where extra information on these items can be found.

    Why do you have 'itemList.hair_fibre =' ? What does that do? Why are you doing it?

     

    10 minutes ago, JetCobblestone said:

    Then we are creating another method which returns a section of code which would be the same for each item, meaning I don't have to add that on each time so it saves space.

    This one is a little weird, you're making a helper method, that is being used in a inner class, in the parent class... Why are there so many damn classes in this file!

     

    Overall, I think you should look into learning some of the basic standards and practices of java coding. Namely access levels, how to reference things from other classes, what a nested class is. As well as the standard naming scemes, as if you ever post code for others to read, following these naming formats allows the reader to understand your code structure from any line.

     

    You also have not shown me anything the explains why you are trying to call anything from your 'main' code. Everything is done for you. Thats the POINT of the @EventBusSubscriber and @SubscribeEvent 

  7. Generate your JSON at/before build time Don't care how you do it.

    At runtime, the data should be static. This allows for better control, caching, management, and a ton of other things. 

     

    Also, stop using upper case in your resource names. There is a reason MC explodes if you try to create a ResourceLocation for it.

     

    Edit: Oh god actually looked at your code, you're doing every thing wrong...

  8. Apologies to those who have attempted to register and verify their email address in the last week.

    Something changed with out email settings, and well, we couldn't send the email to notify me that things broke.

    We have switch to a new SMTP service and things should be resolved.

    New accounts should get the verification emails now.

    Anyone with a pending account should be able to request a resend of their validation email {I couldn't find anything that let me do that in bulk}.

     

    Again, sorry for the issue.

  9. Look in the logs folder, and give us the log files.

    This isn't a issue in Forge, something in your texture pack in providing a invalid texture, and thus getting the default missing texture, which is a purple and black checkerboard.

    We can't tell you what, as that would be in your logs.

    But remove your texture pack and you will be fine.

  10. The data shown in the debug screen is the data that the client knows about.

    And the only data that the client knows about is the data sent over the network

    And the only data sent over the network is the data that can be serialized

    And the only data that can be serialized is the data with corresponding metadata values.

    So yes, The client only knows about what you tell it via the metadata.

    • Like 1
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.