I'm totally doing this for Chapter 2 of "Paper Minecraft". However, for me "no mods" =/= vanilla, since the game is unrecordable (in fact, 1.8/1.9 is unplayable period on a laptop) without using OptiFine, and way too quiet without MAtmos. But other than those two mods, it'll be vanilla. Not even gonna install TooManyItems (even though it's necessary for the rest of the series for obvious reasons).
Three episodes and an intermission to go, then Challenge Accepted. (Also, a falling-damage mob trap is GENIUS. Solves both problems of normal traps (not working in daytime, and needing player interaction) at the same time.)
-
- WackoMcGoose
- Registered Member
-
Member for 13 years, 9 months, and 4 days
Last active Wed, Dec, 16 2020 20:07:05
- 0 Followers
- 635 Total Posts
- 89 Thanks
0
Planned, should be done soon along with the OptiFine patch. (I'm not sure what baseclass TMI uses, anyway... )
Options -> Evil Minecraft Options -> Fancy Blocks: OFF
This only affects the highpoly 3D break model; persistent blockbreaking is a permanent feature
I wouldn't really trust external installers. Direct manual installation into the .jar with WinRAR is the most reliable for me. Also, the mod does NOT work with existing saves, as Evil_Notch has mentioned several times. This is because of the major changes to the save format we made (blockbreak data array, full usability of the 4096 blockIDs that are only half-implemented in vanilla, and most save-breakingly, block metadata is now bytes instead of nibbles). A world converter is
plannedalready in progress according to the commit logs...Also, to everyone having major lag issues: the best advice I can give you is to try disabling Smooth Lighting. Besides the major increase in polycount that Fancy Blocks adds, everything else in the mod adds a lot of overhead that, combined with ambient occlusion, creates one Nether of a lagfest. (Heck, turning off Smooth Lighting in vanilla doubles my framerate, of course I'm on a really low-end laptop not meant for gaming but that's beside the point.)
0
Okay, that is a Blame Notch bug that's been around since late MCAlpha. Sometimes, blocks with unusual (read: anything other than a full 1m cube) render models will randomly decide not to render. It happened with fences a lot, until Notch apparently fixed it.
However, it seems to have come back to affect blockmodels in ModLoader. If a chunk-layer (a 16x16 area, one block thick) consists of nothing but air and ModLoader.RenderWorldBlock() models, with no normal blocks in the same chunk-layer and at or above the affected blocks, they just won't render. The reason it's happening with grass is, obviously, my fancygrass models. No one knows why it happens, and as you found out, the only solution is to put a block in the same chunk-layer that is a solid opaque cube (most normal blocks).
0
Whoops, sorry to confuse you. I am NOT stopping the mod altogether, I'm just not updating it until the next major Minecraft release. Too busy with EvilMinecraft right now, and I've got like twelve MCP instances on my desktop already (that's not an exaggeration, though only three of them are MCP6.1)...
0
Edit: Lol, inb4'd.
0
Can't wait for you to finish the official update including Multithreaded, since both Standard and Vanilla load chunks kinda slow...
0
1
If you want to keep using the mod (which seems to be breaking as it is), please stay on 1.2.3. The obfuscation DID change between versions (it usually doesn't for minor updates, but according to Searge it did), so the mod will not work in a 1.2.4 jar or with 1.2.4 ModLoader.
0
It's a ModLoader mod because of the custom renders and toggleability, but since it modifies base classes, and those baseclass changes have to be there immediately at runtime (the load order is MC baseclasses, then ModLoader itself, then mod_ files and non-baseclass mods installed in the .jar, and mods in .minecraft\mods last), I'm saying that it won't work if you just put it in \mods because the changed base classes won't have been loaded at the right time.
0
0
It generates when you first run the mod. That's how ModLoader's property-file system works.
0
Oddly enough, no results found from either Notepad++ find-in-files (string literal search) or Eclipse (field search). I made sure it wasn't case-sensitive or anything, and it found literally nothing. Not a single instance of the world anywhere in Client/src/net/minecraft/src/.*sigh* Oh Minecraft, why must you be so difficult... WorldType -> WorldProvider -> ChunkProviderGenerate (normal world with biomes) and ChunkProviderFlat (superflat world with no biomes). Still don't know how to actually implement a new world type (and I'm still busy with EvilMinecraft...), and I still don't know why Notepad++'s string-literal search didn't find "superflat", even though it has to be in there somewhere because how could the word be on the world-type button otherwise?
0
That does work, however it causes TMI to derp. Specifically, it hardlocks Minecraft into Survival mode. There's no way to play in Creative, not by changing gamemode in TMI, not even by the worldsave being set to Creative.
0
gx.class is BlockSnow (which I modded the heck out of), and (if I'm reading the error right), it's referring to method gx.a, BlockSnow.setBlockBoundsBasedOnState(), which I removed because it was interfering with the snow render changes I made.
Point is, I think the Magic Launcher may be having issues where a mod removes a method from a class, even if it should be able to use the superclass version (this method is an override of a Block method, which is empty, but can still be called implicitly as the "missing" method). The launcher is expecting there to be a class-specific version, even though Java itself knows the superclass' version is just as valid.
0
0
No clue. gx.class is BlockSnow, so... oh wait, think I get it. It might be refering to a method BlockSnow uses (that is an override of a Block method), that I commented out to make my changes work. Only possibility I can think of... uh, it might be setBlockBoundsBasedOnState(), so whatever Magic Launcher does is expecting a BlockSnow-specific version, and it is given the generic empty Block version instead.
I think I already mentioned that direct installation into minecraft.jar is the only officially-approved method. Mod auto-installers might possibly work, but they're not recommended (as you already noticed), and since the mod pokes several vital-at-runtime classes (particularly BiomeGenBase), having ModLoader load it from a zip in .minecraft\mods\ does NOT work.