Jump to content

Recommended Posts

Posted

http://www.minecraftforge.net/forum/topic/66762-about-reccommended-build-candidacy/

 

So, I posted this the other day. A suggestion regarding how Forge does its releases to help modders, I won't go into the details here.

LexManos himself replied, and was frankly rather condescending in his response.

I posted again, trying to explain better why I thought it would help in a reasonable manner, even though I was upset at how I was responded to. I also voiced that I was displeased with how I was responded to, and with the implications of some things said, but tried to remain as civil as possible about it.

 

Upon coming back to the forums today, I found, instead of a response to my response, perhaps with the thread being closed after a difinitive "no" or something, that my thread had been outright deleted with no explanation. I'll be blunt here: This is not good forum management. If my behaviour was in some way unnacceptable (and I would say honestly it was at worst equally unnacceptable to how I was responded to) then I should have just gotten warning points and the thread closed. Instead I find it's just gone without explanation, without getting to see if anyone responded, or anything.

 

I don't understand why my thread, where I was trying to post a civil, well-intentioned suggestion, was deleted, when threads and posts that are obvious flaming jerks are left untouched.

Like these for example:
http://www.minecraftforge.net/forum/topic/65936-forge-server-error/
http://www.minecraftforge.net/forum/topic/66418-to-lenmanos-your-wrong-idc/

 

All I want is an explanation, because honestly, I'm hurt at how this was handled.

Posted (edited)

The whole thread was pretty unproductive & boiled down to "Why didn't you modders enough time to update" -> "We did".

Core mods aren't supported AND you can specify in 1 line of code what versions you mod does & does not run on. heres how:

https://mcforge.readthedocs.io/en/latest/gettingstarted/structuring/#what-is-mod

Quote

A dependency string can start with the following four prefixes: "before", "after", "required-before", "required-after"; then ":" and the modid.

Optionally, a version range can be specified for the mod by adding "@" and then the version range.*

EDIT: I just found out that apparently core-mods can't do this? they can only use the @MCVersion annotation

Edited by Cadiboo

About Me

Spoiler

My Discord - Cadiboo#8887

My WebsiteCadiboo.github.io

My ModsCadiboo.github.io/projects

My TutorialsCadiboo.github.io/tutorials

Versions below 1.14.4 are no longer supported on this forum. Use the latest version to receive support.

When asking support remember to include all relevant log files (logs are found in .minecraft/logs/), code if applicable and screenshots if possible.

Only download mods from trusted sites like CurseForge (minecraft.curseforge.com). A list of bad sites can be found here, with more information available at stopmodreposts.org

Edit your own signature at www.minecraftforge.net/forum/settings/signature/ (Make sure to check its compatibility with the Dark Theme)

Posted

I'm not sure what's unproductive about suggestions. The base of the suggestion had nothing to do with coremods. The point I was making is that mod authors (any mod authors, not just coremod authors) aren't given any warning before a new reccommended build comes out, and as such, have no time to make sure their mod works correctly on that version before it becomes the defacto "standard" of the modding community for that version.
 

It doesn't help to specify what versions you can and cannot run it on if you don't have enough time to react to even update that single line, and if you have absolutely no way of knowing what builds it will work with until the build is already out. The moment a reccommended build gets released, it's entirely possible that a user will download that, since it's the reccommended and it's above the lowest build needed listed on the mod page, and then find out the mods don't work, and complain to the mod authors.

 

Giving even a brief period where the build is out in the open but not the RB yet would allow mod authors to prepare. If they can't make it work with that version, it would at the very least give them time to update that line, or mention in their mod page description that it doesn't work with versions above [version].

 

I don't know how making a build with changes the Reccommended Build literally the same day those changes are implemented amounts to giving modders enough time to update. Unless they're super fast and not at all busy with other things, and are very actively watching the Forge builds, even 24 hours wouldn't be enough time to react if there was any heads-up.

 

Literally all my suggestion boiled down to:
What: Give mod authors a heads-up when a new reccommended build is coming, stating exactly what changes it contains since the last reccommended build.

How: Add some note or something on downloads page, make a tweet, whatever, that says "Build [whatever] will become the reccommended 1 week after release" or something.
Why: So mod authors have a week to make sure their mods work with the reccommended build before it becomes the reccommended build (and therefore the build most users expect any mods to work on), to avoid day-1 reccommended build downloaders flooding complaints that the mod doesn't work on the reccommended expected build.

 

And instead they focused on me using the recent coremod reccommended build fiasco as an example, complaining about coremods and how absolutely terrible they are and that no mod author should ever use them etc. etc. and shrugged off the suggestion because "it's coremods!" and replied in a tone that was somewhere between putting-down and outright condescending.

When really, this would help any mod author who might have their mod affected by builds in-between the old and new reccommended builds. Instead of needing to either wait for a reccommended then hurry to fix it, or continually make sure it works on every single latest build leading up to the reccommended, they could then see "oh that is going to be the reccommended in a week i'll make sure it works with that build since that's the build most users will probably be using in a week or so".

 

Besides. Being unproductive isn't a good reason to outright delete the thread, wiping any memory of it from existence.

Look at those examples I posted at the bottom. Those are the definition of unproductive, terrible forum behaviour, yet they weren't deleted, even after quite a while, so why was I singled out so promptly for the purge?

Posted
2 minutes ago, IdrisQe said:

Giving even a brief period where the build is out in the open but not the RB yet would allow mod authors to prepare

Correct me if I'm wrong but aren't the "latest" versions exactly this?

2 minutes ago, IdrisQe said:

What: Give mod authors a heads-up when a new reccommended build is coming, stating exactly what changes it contains since the last reccommended build.

How: Add some note or something on downloads page, make a tweet, whatever, that says "Build [whatever] will become the reccommended 1 week after release" or something.
Why: So mod authors have a week to make sure their mods work with the reccommended build before it becomes the reccommended build (and therefore the build most users expect any mods to work on), to avoid day-1 reccommended build downloaders flooding complaints that the mod doesn't work on the reccommended expected build.

https://github.com/MinecraftForge/MinecraftForge/commits/1.12.x

https://github.com/MinecraftForge/MinecraftForge/commit/76c138c40043431a6cdecf674570d757d89b26c7

 

4 minutes ago, IdrisQe said:

Besides. Being unproductive isn't a good reason to outright delete the thread, wiping any memory of it from existence.

Agreed

About Me

Spoiler

My Discord - Cadiboo#8887

My WebsiteCadiboo.github.io

My ModsCadiboo.github.io/projects

My TutorialsCadiboo.github.io/tutorials

Versions below 1.14.4 are no longer supported on this forum. Use the latest version to receive support.

When asking support remember to include all relevant log files (logs are found in .minecraft/logs/), code if applicable and screenshots if possible.

Only download mods from trusted sites like CurseForge (minecraft.curseforge.com). A list of bad sites can be found here, with more information available at stopmodreposts.org

Edit your own signature at www.minecraftforge.net/forum/settings/signature/ (Make sure to check its compatibility with the Dark Theme)

Posted

As Lex had stated in the thread (I forget the exact words, this is my approximation), modders tend to not update their stuff until they are FORCED to(in this case, by users moving to the new recommended version, which their stuff doesn't work on).

 

The breaking change that was seen most was changes in the Coremod system, which already walks the thin line of being allowed but not supported and is some of the most change-sensitive stuff.

This change(build 2763, posted 09/27/18 09:37 PM) came about a week before the release build(build 2768, posted 10/04/18 07:48 AM) went up.

 

I'm going to lock this here because anything further will just be an argument of how things should be run.

This is my Forum Signature, I am currently attempting to transform it into a small guide for fixing easier issues using spoiler blocks to keep things tidy.

 

As the most common issue I feel I should put this outside the main bulk:

The only official source for Forge is https://files.minecraftforge.net, and the only site I trust for getting mods is CurseForge.

If you use any site other than these, please take a look at the StopModReposts project and install their browser extension, I would also advise running a virus scan.

 

For players asking for assistance with Forge please expand the spoiler below and read the appropriate section(s) in its/their entirety.

Spoiler

Logs (Most issues require logs to diagnose):

Spoiler

Please post logs using one of the following sites (Thank you Lumber Wizard for the list):

https://gist.github.com/100MB Requires member (Free)

https://pastebin.com/: 512KB as guest, 10MB as Pro ($$$)

https://hastebin.com/: 400KB

Do NOT use sites like Mediafire, Dropbox, OneDrive, Google Drive, or a site that has a countdown before offering downloads.

 

What to provide:

...for Crashes and Runtime issues:

Minecraft 1.14.4 and newer:

Post debug.log

Older versions:

Please update...

 

...for Installer Issues:

Post your installer log, found in the same place you ran the installer

This log will be called either installer.log or named the same as the installer but with .log on the end

Note for Windows users:

Windows hides file extensions by default so the installer may appear without the .jar extension then when the .log is added the log will appear with the .jar extension

 

Where to get it:

Mojang Launcher: When using the Mojang launcher debug.log is found in .minecraft\logs.

 

Curse/Overwolf: If you are using the Curse Launcher, their configurations break Forge's log settings, fortunately there is an easier workaround than I originally thought, this works even with Curse's installation of the Minecraft launcher as long as it is not launched THROUGH Twitch:

Spoiler
  1. Make sure you have the correct version of Forge installed (some packs are heavily dependent on one specific build of Forge)
  2. Make a launcher profile targeting this version of Forge.
  3. Set the launcher profile's GameDir property to the pack's instance folder (not the instances folder, the folder that has the pack's name on it).
  4. Now launch the pack through that profile and follow the "Mojang Launcher" instructions above.

Video:

Spoiler

 

 

 

or alternately, 

 

Fallback ("No logs are generated"):

If you don't see logs generated in the usual place, provide the launcher_log.txt from .minecraft

 

Server Not Starting:

Spoiler

If your server does not start or a command window appears and immediately goes away, run the jar manually and provide the output.

 

Reporting Illegal/Inappropriate Adfocus Ads:

Spoiler

Get a screenshot of the URL bar or copy/paste the whole URL into a thread on the General Discussion board with a description of the Ad.

Lex will need the Ad ID contained in that URL to report it to Adfocus' support team.

 

Posting your mod as a GitHub Repo:

Spoiler

When you have an issue with your mod the most helpful thing you can do when asking for help is to provide your code to those helping you. The most convenient way to do this is via GitHub or another source control hub.

When setting up a GitHub Repo it might seem easy to just upload everything, however this method has the potential for mistakes that could lead to trouble later on, it is recommended to use a Git client or to get comfortable with the Git command line. The following instructions will use the Git Command Line and as such they assume you already have it installed and that you have created a repository.

 

  1. Open a command prompt (CMD, Powershell, Terminal, etc).
  2. Navigate to the folder you extracted Forge’s MDK to (the one that had all the licenses in).
  3. Run the following commands:
    1. git init
    2. git remote add origin [Your Repository's URL]
      • In the case of GitHub it should look like: https://GitHub.com/[Your Username]/[Repo Name].git
    3. git fetch
    4. git checkout --track origin/master
    5. git stage *
    6. git commit -m "[Your commit message]"
    7. git push
  4. Navigate to GitHub and you should now see most of the files.
    • note that it is intentional that some are not synced with GitHub and this is done with the (hidden) .gitignore file that Forge’s MDK has provided (hence the strictness on which folder git init is run from)
  5. Now you can share your GitHub link with those who you are asking for help.

[Workaround line, please ignore]

 

Guest
This topic is now closed to further replies.

Announcements



×
×
  • Create New...

Important Information

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