Jump to content
Search In
  • More options...
Find results that contain...
Find results in...

shinji

Members
  • Content Count

    15
  • Joined

  • Last visited

Community Reputation

1 Neutral

About shinji

  • Rank
    Tree Puncher

Converted

  • Gender
    Undisclosed
  • Personal Text
    I am new!
  1. Well that would explain why it failed on 1.6.2 version as well (in the same way) although I didn't expect that version to load fully I was hoping to just get a bunch of other errors in that test. This is what I get starting #886. Launching game Looking for old natives to clean up... Unpacking natives to C:\Users\Robert\AppData\Roaming\.minecraft\versions\1.6.4-Forge9.11.0.891\1.6.4-Forge9.11.0.891-natives-460208861642497 Launching in C:\Users\Robert\AppData\Roaming\.minecraft Running C:\Program Files\Java\jre7\bin\javaw.exe -XX:HeapDumpPath=MojangTricksIntelDriversForPerformance_javaw
  2. That I can understand. I'm posting in regards to a potential breakage on the Forge side since 1.6.2 although I'm not sure where. There have been changes made to Forge in the past to allow Optifine to be Forge loadable.
  3. This works fine with 1.6.2 builds of Forge. When I updated to Forge #883 (the current recommended) and loaded the preview release of Optifine I get a ClassNotFoundException for optifine.OptiFineForgeTweaker. The interesting part is that the class exists in the Optifine jar when I checked. For the sake of experimentation I also tried to run using the 1.6.2 version of Optifine resulting in the same error. The 1.6.2 version of Optifine loads fine with Forge #859. The same error persists across all 1.6.4 builds starting with #879 (which was the first listed for download). I've attached m
  4. Optifine should be fine. Make sure you are using the 1.5.1 builds. AFAIK single player commands isn't updated yet to 1.5.1.
  5. Confirmed this bug cleared on build #608 as noted in changelog. Verified in game too... Going to go ahead and close thread now. Thanks for the quick fix.
  6. I took a look and verified what both Matt_Bradock and rick1051414 have mentioned. 3d items are rendering on the wrong side (or at least some of them are) Screenshot below with only Forge active. Default texture pack. Glass replaced my Obsidian wall to show why we were not seeing them. You can see it is 1 thick and we are looking through it from the side/back.
  7. Thanks for the tip. I just verified that switching to Fast does indeed workaround the issue although I would hope it could be fixed for Fancy too. For those using Optifine switching dropped items to Fast will also work for now. Using Fast will force dropped items to render as 2D and I guess the items in the frames counts too.
  8. I'll go back and reverify but I'm pretty sure that it was with reproducible with just forge. EDIT: I went back and verified. Check with build #604. Default texture pack. Debug screen up so you can see Optifine is NOT active. With Forge Enabled Without Forge Enabled P.S. - Also checked with #605 while I was writing this. Be aware that this only affects 1.5.1. It does not affect any 1.5 Forge builds. Bug even affects the 1.5.1 #597 oddly enough where the 1.5 #598 is ok. Log again... seems earlier I included a log that mentioned Optifine in error.
  9. Forge loads fine with Magic Launcher. Checked and verified although it isn't without its bugs too.
  10. For some reason installing Forge #600 on 1.5.1 is causing some items (e.g. Weapons and any kind of bucket) to not show up in frames. The items are seemingly random but they are always the same items when it does happen. I verified that Forge was at fault by only removing forge and seeing that the issue clears. Can you look into why this happens? FYI - As you will see below the UI is disabled on the first image. I did that in error and don't feel like retaking the screenshot. The mods shown on the second image are indeed enabled when I did the first screenshot. Without Forge
  11. Thanks for that tip. I did some hunting on that and found a bug report post related to FML that suggested a function call that FML uses to prioritize mods. I'll suggest it to the mod author in their thread. https://github.com/cpw/FML/issues/48
  12. The problem existed on the most recent recommended so unless the patch was applied after that point... EDIT: Checked on build 260 and load order is still alphabetical and still breaks CJB due to this without a package rename.
  13. This is an older post but we figured it out. It is a combination of how FML is setup to load the external mods and how the author of CJB packaged it. It is throwing the error because it is loading the CJB_CHEATS package before CJB_MAIN and since CJB_PlayerController isn't contained in CJB_CHEATS it throws the exception. It won't get that file until CJB_MAIN is loaded. FML appears to load things in alphabetical order. The workaround for now is to simply rename the CJB_MAIN file to something that makes it higher in the alphabetical order. I just stripped off the _MAIN part and that was eno
  14. It looks like at least CJB's Modpack on the Cheat and Quickcraft components throws errors when using ForgeModLoader. I did try updating PlayerAPI (which CJB is reliant on) and updating to the newest test build on CJB with no change. I've attached the ForgeModLoader-client-0.log file for you so you can look into it. ForgeModLoader-client-0.log
×
×
  • Create New...

Important Information

By using this site, you agree to our Privacy Policy.