Jump to content

Forge Source 9.10.0.789 installer problem


avi12

Recommended Posts

Hello.

I ran the installer, then the installer got stucked at "jinput-2.0.5-sources.jar Done".

tMDStWy.png

 

And BTW, I tried to cancel the installer, delete the folder, extract the folder and run the installer again, and it still got stuck.

What should I do?

Link to comment
Share on other sites

How long did you take to wait for the installer to finish? Jinput-2.0.5-sources.jar took a long tie to download by me, maybe thats the same case as you?

Don't PM me with questions. They will be ignored! Make a thread on the appropriate board for support.

 

1.12 -> 1.13 primer by williewillus.

 

1.7.10 and older versions of Minecraft are no longer supported due to it's age! Update to the latest version for support.

 

http://www.howoldisminecraft1710.today/

Link to comment
Share on other sites

I haven't tried to download manually this file, and a bit after I posted the post I ran again the installer, and got stuck in the same file, again.

Where can I download the file from, and where do I put the file?

EDIT:

Just checked and I have the file... So what should I do?

EDIT 2:

I manually downloaded the file, then replaced it with the file that the installer downloaded, that didn't change the installer (still stuck).

Link to comment
Share on other sites

Sadly the download system we use in python doesn't seemt o have any form of progress bar or anything and some files are quite large. But you should be able to download things just fine.

 

Either way could you get me a md5 sub of your libraries folder

http://sourceforge.net/projects/md5deep/?source=dlp

That is a good program to use, and then just run md5deep -r -z .

From inside your libraries folder, it should result in something like this:

Z:\MCP-1.6-Forge\mcp\jars\libraries>md5deep -r -z .
     74953  e9960995974979445b03bc644b9e9853  argo\argo\2.25_fixed\argo-2.25_fixed.jar
    126470  f0d5afe00d01aaae90e24b0745da1a3a  com\google\code\gson\gson\2.2.2\gson-2.2.2-sources.jar
    189285  08cce0687047cc068b6f1bdd45b14cf4  com\google\code\gson\gson\2.2.2\gson-2.2.2.jar
    103871  0d622e2ac4368b5a33d540a9e4819e0c  com\paulscode\codecjorbis\20101023\codecjorbis-20101023.jar
      5618  f6a93b7eb8083e4ced92e7e253657057  com\paulscode\codecwav\20101023\codecwav-20101023.jar
     21679  247b45f9d2f0071ad543c14d0ff31d5c  com\paulscode\libraryjavasound\20101123\libraryjavasound-20101123.jar
     18981  93730cef2e75762c5a1431c6d7a0c78e  com\paulscode\librarylwjglopenal\20100824\librarylwjglopenal-20100824.jar
     65020  6d9d7d6c163caf74984465694d3566e7  com\paulscode\soundsystem\20120107\soundsystem-20120107.jar
   1170055  e0888a4515f9c05afa36fcb8fdfb51a9  com\google\guava\guava\14.0\guava-14.0-sources.jar
   2189111  5f4a710056b492b9cbdff5d3897b402a  com\google\guava\guava\14.0\guava-14.0.jar
    246635  b5bc8f1993486e46544daab5042d2142  commons-io\commons-io\2.4\commons-io-2.4-sources.jar
    185140  7f97854dc04c119d461fed14f5d8bb96  commons-io\commons-io\2.4\commons-io-2.4.jar
      5762  a3e3c3186e41c4a1a3027ba2bb23cdc6  lzma\lzma\0.0.1\lzma-0.0.1.jar
    282276  dbd3709364779ac65079bd669fee962f  net\java\jinput\jinput\2.0.5\jinput-2.0.5-sources.jar
    208338  cc07d371f79dc4ed2239e1101ae06313  net\java\jinput\jinput\2.0.5\jinput-2.0.5.jar
     10362  12f3021e9cab2beece3c191138955a56  net\java\jinput\jinput-platform\2.0.5\jinput-platform-2.0.5-natives-linux.jar
     12186  32fea5fd88f91b9dd335839aca06f3d1  net\java\jinput\jinput-platform\2.0.5\jinput-platform-2.0.5-natives-osx.jar
    155179  b168b014be0186d9e95bf3d263e3a129  net\java\jinput\jinput-platform\2.0.5\jinput-platform-2.0.5-natives-windows.jar
     10247  2a1f2968a3b58534b2d5dea69abdb854  net\java\jutils\jutils\1.0.0\jutils-1.0.0-sources.jar
      7508  f60976b19661c849c5c87433045a9885  net\java\jutils\jutils\1.0.0\jutils-1.0.0.jar
     17357  829effa9f93d5ece21e64baf78e9d4cb  net\minecraft\launchwrapper\1.3\launchwrapper-1.3.jar
     73276  24adb285f7df2f52dc9d1ea6e426065f  net\sf\jopt-simple\jopt-simple\4.5\jopt-simple-4.5-sources.jar
     61311  1372bd4823bb1ef61e7db6724f601150  net\sf\jopt-simple\jopt-simple\4.5\jopt-simple-4.5.jar
     49495  a355b838f756130ea0b150bffdb2c9a0  net\sourceforge\argo\argo\2.25\argo-2.25-sources.jar
    123642  5ff00179da80a95958e75ff4570491e4  net\sourceforge\argo\argo\2.25\argo-2.25.jar
    393048  c18d8bac3f0c5961c6c5fbad3fbb02f5  org\apache\commons\commons-lang3\3.1\commons-lang3-3.1-sources.jar
    518924  722da64d6286a030e5e60d7678c27edc  org\lwjgl\lwjgl\lwjgl-platform\2.9.0\lwjgl-platform-2.9.0-natives-osx.jar
   1575895  724591fbb5f5198e1fd518c3003c273d  org\bouncycastle\bcprov-jdk15on\1.47\bcprov-jdk15on-1.47-sources.jar
   1997327  7749dd7eca4403fb968ddc484263736a  org\bouncycastle\bcprov-jdk15on\1.47\bcprov-jdk15on-1.47.jar
    848683  96926ba2f53d45e5f98f440378dfebc6  org\lwjgl\lwjgl\lwjgl\2.9.0\lwjgl-2.9.0-sources.jar
    994633  ce74486a7687ad7ea91dcc1fcd6977b8  org\lwjgl\lwjgl\lwjgl\2.9.0\lwjgl-2.9.0.jar
    569061  8bf181ad1340d45e3505f267a5d33cc7  org\lwjgl\lwjgl\lwjgl-platform\2.9.0\lwjgl-platform-2.9.0-natives-linux.jar
    315805  71b48e6b3e1b1dc73fe705604b9c7584  org\apache\commons\commons-lang3\3.1\commons-lang3-3.1.jar
    609967  30e99b9386040f387fd94c26c1ac64d3  org\lwjgl\lwjgl\lwjgl-platform\2.9.0\lwjgl-platform-2.9.0-natives-windows.jar
    230979  b4ee4382dc948585555d0c67a0d76e2f  org\lwjgl\lwjgl\lwjgl_util\2.9.0\lwjgl_util-2.9.0-sources.jar
    173360  6a0eeaf3451ed9646b7d61a9dd8b86cc  org\lwjgl\lwjgl\lwjgl_util\2.9.0\lwjgl_util-2.9.0.jar
    214592  d21c2a06a4e6b175aa01e328f38a1182  org\ow2\asm\asm-all\4.1\asm-all-4.1.jar
    983980  df4c3fd90219f2fe6751615d9684101e  org\ow2\asm\asm-all\4.1\asm-all-4.1-sources.jar
   2051509  2962a80a78d13bc04ff325c1ae278d46  org\scala-lang\scala-compiler\2.10.2\scala-compiler-2.10.2-sources.jar
   1058962  4fc5640a9e08915551c553da67aa5de7  org\scala-lang\scala-library\2.10.2\scala-library-2.10.2-sources.jar
   7121818  8800aafcc03e346dbbde171bef0b2bfe  org\scala-lang\scala-library\2.10.2\scala-library-2.10.2.jar
  14411577  44f4d11085423ebffbfb177c1fe4cc69  org\scala-lang\scala-compiler\2.10.2\scala-compiler-2.10.2.jar

 

I do Forge for free, however the servers to run it arn't free, so anything is appreciated.
Consider supporting the team on Patreon

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.


  • Recently Browsing

    • No registered users viewing this page.
  • Posts

    • I'm developing a dimension, but it's kinda resource intensive so some times during player teleporting it lags behind making the player phase down into the void, so im trying to implement some kind of pregeneration to force the game loading a small set of chunks in the are the player will teleport to. Some of the things i've tried like using ServerLevel and ServerChunkCache methods like getChunk() dont actually trigger chunk generation if the chunk isn't already on persistent storage (already generated) or placing tickets, but that doesn't work either. Ideally i should be able to check when the task has ended too. I've peeked around some pregen engines, but they're too complex for my current understanding of the system of which I have just a basic understanding (how ServerLevel ,ServerChunkCache  and ChunkMap work) of. Any tips or other classes I should be looking into to understand how to do this correctly?
    • https://mclo.gs/4UC49Ao
    • Way back in the Forge 1.17 days, work started for adding JPMS (Java Platform Module Support) to ModLauncher and ForgeModLoader. This has been used internally by Forge and some libraries for a while now, but mods (those with mods.toml specifically) have not been able to take advantage of it. As of Forge 1.21.1 and 1.21.3, this is now possible!   What is JPMS and what does it mean for modders? JPMS is the Java Platform Module System, introduced in Java 9. It allows you to define modules, which are collections of packages and resources that can be exported or hidden from other modules. This allows for much more fine-tuned control over visibility, cleaner syntax for service declarations and support for sealed types across packages. For example, you might have a mod with a module called `com.example.mod` that exports `com.example.mod.api` and `com.example.mod.impl` to other mods, but hides `com.example.mod.internal` from them. This would allow you to have a clean API for other mods to use, while keeping your internal implementation details hidden from IDE hints, helping prevent accidental usage of internals that might break without prior notice. This is particularly useful if you'd like to use public records with module-private constructors or partially module-private record components, as you can create a sealed interface that only your record implements, having the interface be exported and the record hidden. It's also nice for declaring and using services, as you'll get compile-time errors from the Java compiler for typos and the like, rather than deferring to runtime errors. In more advanced cases, you can also have public methods that are only accessible to specific other modules -- handy if you want internal interactions between multiple of your own mods.   How do I bypass it? We understand there may be drama in implementing a system that prevents mods from accessing each other's internals when necessary (like when a mod is abandoned or you need to fix a compat issue) -- after all, we are already modding a game that doesn't have explicit support for Java mods yet. We have already thought of this and are offering APIs from day one to selectively bypass module restrictions. Let me be clear: Forge mods are not required to use JPMS. If you don't want to use it, you don't have to. The default behaviour is to have fully open, fully exported automatic modules. In Java, you can use the `Add-Opens` and `Add-Exports` manifest attributes to selectively bypass module restrictions of other mods at launch time, and we've added explicit support for these when loading your Forge mods. At compile-time, you can use existing solutions such as the extra-java-module-info Gradle plugin to deal with non-modular dependencies and add extra opens and exports to other modules. Here's an example on how to make the internal package `com.example.examplemod.internal` open to your mod in your build.gradle: tasks.named('jar', Jar) { manifest { attributes([ 'Add-Opens' : 'com.example.examplemod/com.example.examplemod.internal' 'Specification-Title' : mod_id, 'Specification-Vendor' : mod_authors // (...) ]) } } With the above in your mod's jar manifest, you can now reflectively access the classes inside that internal package. Multiple entries are separated with a space, as per Java's official spec. You can also use Add-Exports to directly call without reflection, however you'd need to use the Gradle plugin mentioned earlier to be able to compile. The syntax for Add-Exports is the same as Add-Opens, and instructions for the compile-time step with the Gradle plugin are detailed later in this post. Remember to prefer the opens and exports keywords inside module-info.java for sources you control. The Add-Opens/Add-Exports attributes are only intended for forcing open other mods.   What else is new with module support? Previously, the runtime module name was always forced to the first mod ID in your `mods.toml` file and all packages were forced fully open and exported. Module names are now distinguished from mod IDs, meaning the module name in your module-info.java can be different from the mod ID in your `mods.toml`. This allows you to have a more descriptive module name that doesn't have to be the same as your mod ID, however we strongly recommend including your mod ID as part of your module name to aid troubleshooting. The `Automatic-Module-Name` manifest attribute is now also honoured, allowing you to specify a module name for your mod without needing to create a `module-info.java` file. This is particularly useful for mods that don't care about JPMS features but want to have a more descriptive module name and easier integration with other mods that do use JPMS.   How do I use it? The first step is to create a `module-info.java` file in your mod's source directory. This file should be in the same package as your main mod class, and should look something like this: open module com.example.examplemod { requires net.minecraftforge.eventbus; requires net.minecraftforge.fmlcore; requires net.minecraftforge.forge; requires net.minecraftforge.javafmlmod; requires net.minecraftforge.mergetool.api; requires org.slf4j; requires logging; } For now, we're leaving the whole module open to reflection, which is a good starting point. When we know we want to close something off, we can remove the open modifier from the module and open or export individual packages instead. Remember that you need to be open to Forge (module name net.minecraftforge.forge), otherwise it can't call your mod's constructor. Next is fixing modules in Gradle. While Forge and Java support modules properly, Gradle does not put automatic modules on the module path by default, meaning that the logging module (from com.mojang:logging) is not found. To fix this, add the Gradle plugin and add a compile-time module definition for that Mojang library: plugins { // (...) id 'org.gradlex.extra-java-module-info' version "1.9" } // (...) extraJavaModuleInfo { failOnMissingModuleInfo = false automaticModule("com.mojang:logging", "logging") } The automatic module override specified in your build.gradle should match the runtime one to avoid errors. You can do the same for any library or mod dependency that is missing either a module-info or explicit Automatic-Module-Name, however be aware that you may need to update your mod once said library adds one. That's all you need to get started with module support in your mods. You can learn more about modules and how to use them at dev.java.
    • Faire la mise à jour grâce à ce lien m'a aider personnellement, merci à @Paint_Ninja. https://www.amd.com/en/support 
  • Topics

×
×
  • Create New...

Important Information

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