keybounce

Forge compatibility issue. Forge is now failing to work with MumbleLink. Regression: Worked perfectly in 145 with 443. I cannot get it to work in 147 with either 499 (stable/optifine) or 524 (latest) Logs: 1. MultiMC, 147, 524, in jar. No other mods. Identifies a basemod mod_MumbleLink, in minecraft.jar, but then fail to find the class at construction time. http://pastebin.com/fSHxVN1D 2. MultiMC, 147, 524, in mods folder. Same setup. Same issue. http://pastebin.com/PrtfECGA 3. Magic Launcher, 145, 443, in internal mods. Works. Note that even though it is "internal", it still gets identified by the mod filename and not just "minecraft.jar" http://pastebin.com/ncsDwpjr Note also that this has about 20 mods. 4. Magic Launcher, 147/524, internal mods. Fails. http://pastebin.com/18ScdzS2 Notes: Folder "MumbleLink" in the mods folder contains the native libraries that mumble link uses.

Thank you. Next question: How do I determine which changes are in which forge release? Granted, it's not an issue right now -- 445 is two days old, and nothing newer is in the commit history -- but in general, how do you tell which sets of commits are in which forge release without the per-version changefile log?

Done, thank you. Next question: The most recent builds don't even have a changelog :-). Que' pasa?

The changelogs at http://files.minecraftforge.net/ seem to be one revision out of step at each line. Additionally, some changelogs, like http://files.minecraftforge.net/minecraftforge/minecraftforge-changelog-1.4.5-6.4.1.416.txt are clipped.

(I am surprised that this wasn't in "Excessively asked questions") Optifine releases usually indicate a specific version of forge; it's rarely the official release version. Right now, release/recommended is 372; optifine 144 D2 calls for 374. What issues are known in 374 that were not present in 372 (i.e, what bugs since release are now known and fixed later)? Is Optifine asking for anything 374 or later, or is it only 374, exactly? (Mystcraft was in that situation for a while, for example)

> 2012-11-07 19:00:27 [sEVERE] [ForgeModLoader] There was a problem reading the entry __MACOSX/._mod_MumbleLink.class in the jar /Users/michael/Documents/Games/Minecraft/Playing/Mods/142/MumbleLink-142.zip - probably a corrupt zip This was with forge 349, on a zip file that had to be repackaged. Repackaged with Mac finder -- which stores extended attributes in the zip file. The work-around: Repackage with command-line zip command. Easy enough for me, less so for other users. It's not a class file, despite the name. FML should ignore it, rather than giving up on the entire zip. > 2012-11-07 19:00:27 [WARNING] [ForgeModLoader] Zip file MumbleLink-142.zip failed to read properly, it will be ignored

Timber (RML mod) fails to work. Log attached. Timber: http://www.minecraftforum.net/topic/119361-132-tehkrushs-mods-timber-updated/ EDIT: Never mind, apparently (OvermindDL) says it is a client-only mod. Was not aware that still existed for things without a GUI.

Last I checked, 251 was still the recommended release, and Mystcraft has too many issues with anything newer. I do not accept that it is just a side effect of Apple Java. Many other java programs can run without bringing up a new icon. I did mention it before; Lex posted his opinion and then locked the thread so I could not respond. A bug is a bug. It's one thing to say "Too minor to fix". I can respond with why I think it's not minor, and why it causes me problems (makes the dock wider, blocks the otherwise visible space on the bottom where I have windows position to provide me with status information, etc). But to say "No, it's not a bug, our code is just perfect"?

I do not get dock icons with vanilla 1.3.2 servers. I did not get dock icons with 1.2.5 servers with forge. I am only getting dock icons now, with 1.3.2 and forge. Based on that, I'm concluding that forge is doing something now, that is causing dock icons to show up for applications that have no gui and no need for a dock icon. I do want dock icons to appear for java apps that need them. The idea of "Disable them system wide to get rid of them in this one program" is a bad one. And, for what it's worth, I could not find any setting in the java preferences to disable icon creation.

The specific icon is the generic cup of coffee icon, same as running the minecraft.jar (client) from a shell script instead of from the Mojang launcher.

I do not get a GUI. What do you mean, side effect of JVM? I don't get an icon for vanilla servers, and didn't for forge 125. Or craft-bukkit 125.

On Mac OS 10.7.4, Forge 4.1.1.251, when run as a server with the "nogui" option, will still generate a dock icon/show up in the application list.

Note: I am not a modder. I am a user. I am trying to understand the how/why of multiple world generation mods working together. So I've been playing around with a bunch of mods. Things like NetherOres, Twilight Forest, and Mystcraft. I've been hearing about things such as RedPower (marble!), Simple Ores, and other such things. And ... well, there's something called "Dense Ores" in mystcraft. Simply put, it tries to generate all known ores (everything registered with forge) in higher quantities, at higher than normal Y's. And there's things like better ore distribution/custom ore distribution, both of which want to change how ores are laid out, to give more meaningful clusters instead of completely random vanilla layouts. Not to mention lots of mods that add custom critters for specific dimensions. So what's the issue that I see? Both SimpleOres and NetherOres add ores that normally only generate in the nether. But as far as I can tell, there's no hook in forge to say "This is a nether ore", or "This is a normal/overworld ore", or "This is a custom new-dimension material, only generate in my custom dimensions". There are no hooks to permit altering how they are generated -- Better Ore Generation basically has a config file where you spell it out in detail. Which works well enough. But then there's no way for a Dense Ore age in Mystcraft to ramp the generation up higher than normal without having to take over the generation completely, ruining the motherlode/vein style distribution. === What do I see as potential resolutions? Again, I am a user that wants to work with mods that alter world/dimension generation. 1. Indicate if a given world piece -- animal, mineral, plants, biome, etc -- is nether only, hell only (note that those are not the same since Mystcraft lets you have a hell biome in a non-nether age), or correspondingly end/sky only, or "Normal dimensions/overworld compatible", or "custom dimensions only". 2. A way to run ore generations, with the output being a list of locations where the ores should go, rather than being actually modified in the ground; this would permit mods to alter the generation results of other mods. 2b -- ideally a way to specify a seed other than the normal world seed, for secondary/multiple generations. 3. Equally, now that I think about it, that same sort of behavior -- the output of the generation is a list of locations and changes, rather than changing the blocks in the ground -- for surface decorations, or entities spawned at chunk generation. Note that case #2 -- ore generations being a list rather than ground modifications -- would permit mods such as Mystcraft, which generates very large amounts of stone exposed to air in the dark (floating sky islands) to work well with mods such as Redpower -- which assumes that stone exposed to air in the dark must be a cave and not in very large amounts

Tee hee. Because I want my overworld to function in vanilla. Anything goes in the ages, but the overworld has to function if loaded in vanilla. And, you're not the first person to recommend Redpower. I had issues with it and 125 when playing on someone else's server, and there's the whole issue of marble generation in Mystcraft.

... And I finally managed to make it happen in vanilla 1.3.2, so it is not forge at all. Reporting at the MC site. (What happens? Well, the button is supposed to put 9 ticks of "on" state into the loop, and it is supposed to take 14 ticks to go around the loop. Instead, that 9 ticks of "on" extends to all 14 ticks of the loop, and the side with the doorbell button is always on, like if you pressed the button twice.) As for lag/chunk issues: This time the testing was with only one person on the server, standing still, right in front of it. Technically it's an adjacent chunk, but no chunks were being loaded/unloaded. === Lex, do you (or anyone) have ideas on how to make things like this work properly? Any way to design around MC's "quirks"? I want to play with long distance instant wire, but the "best"/cheapest way I've seen for that involves pulse transmitters, and a decoder/counter at the far end. If this is messing up, I can only imagine how that will mess up ... (The pulse transmitters I'm not that worried about; BUDs making a piston retract is pretty stable. The question of distance, unloaded chunk signal propagation, and then just the tracking at the other end ...)

I have a redstone loop that behaves badly in Forge. You can see this loop setup, in 12w27a, here: Short summary: It is a 14 tick loop, 3x4 for repeaters, and 2 for torches. Ideal behavior is 9 ticks on, 5 ticks off (9 ticks on from a button). Since 12w30c (?), I have only seen it show either the 9/5 or the 8/6 state (in the video, when I'm mentioning that the timing of the notes is now different). I have never seen the lockup state in 1.3.2 vanilla. I just (two days ago) saw it lock up in 1.3.2 + forge. If it makes a difference, this is full multiplayer server. I will do more testing in 1.3.2 vanilla; as I said, I have not seen this happen there yet.

Because when I attempt to use an enchantment table to make use of Superior Enchanting, it tells me that there is no client side mod installed. Using RML, it works. Using Forge/FML, it fails. === Cpw, you have seemed so far to dislike my use of scripting to set up my environments. Consider that this gives you a 100% repeatable build for my issue. Consider that this gives you the perfect ability to test anything. I have identified something that works in RML, fails in FML. I have given you a reproduce-able build environment. None are FML mods. None of those mods even needs forge. I have other mods, not being used in that test, that are mod folder FML mods with mcmod.info files But this is a mod that works in RML that does not work in FML. And your website here says that you want to know about that class of mod. === What is really annoying? I have some server-side mods that I want to use that use forge but have no client-side component, do not do anything to alter the client-side. (Example: Ruins. Generates structures in the map on the server-side). I actually tested using RML on the client, and forge/FML on the server. Again, no FML/forge mod on the client at all, and none needed. The forge server refused to let the RML client connect. So, moving forward, forge is basically killing RML, and FML fails to accomplish what RML does.

What do I expect? On the client side, Superior Enchanting uses Modloader. The client and server side can see each other, talk to each other, and work happily together. In forge 3.3.8, FML identifies Superior Enchanting (and all of my client-side mods, actually), identifies the version information, forwards all the version information to the server, and the server reports every mod that I connect with. I've got a bunch of forge and modloader mods In forge 4, FML fails to identify and report any of the mods The point is, it works with Risugami's ModLoader, in multiplayer. Superior Enchantment, both the 1.2.5 and the 1.3.2 version, successfully talk between client and server with Risugami's Modloader, and fail with Forge Modloader. In Forge 3, the server is told about all of the mods FML found, and their versions, even the mods that are RML mods. In Forge 4, that all fails -- mods that are client-side only RML mods with no server-side component also fail to be reported.

Yes, there are server-side mods in that list. From the server creation script: unzip "$JarDir"/minecraft_server-132.jar ## unzip "$ModDir"/minecraftforge-universal-4.0.0.241.zip unzip "$ModDir"/FallFix_1_3_2.zip ## unzip "$ModDir"/ImprovedLogPlacing-132.zip unzip "$ModDir"/ImprovedLog-132-noforge.zip unzip "$ModDir"/MoreVillageBiomes-V2-132-smp.zip unzip "$ModDir"/SuperiorEnchantment-132smp.zip unzip "$ModDir"/WaterPropogationFix_132.zip Of those, SuperiorEnchantment is a modloader mod. On the server side, it just drops in. On the client side, it uses modloader. ImprovedLogPlacing also talks to the client, and it is not a modloader mod. Many of the mods are client-side modloader mods, and FML (forge 4) fails to retrieve the version information or pass it to the server -- the forge 4 server reports that the client connects with no mods, and SuperiorEnchantment fails to communicate between the server and client. (I did not test improve log placement). Superior Enchantment's thread: http://www.minecraftforum.net/topic/1054768-superior-enchantment-system-minecraft-132version-1133/

I am unable to get modloader mods to work in forge 241. Symptoms: 1. FML reports all mods as version 1.0 2. Server reports that I connect with no mods. 3. Log file shows no version information available. 4. Mods do work. However, mods that communicate with the server -- Superior Enchantment -- fail to be recognized on the server. Here is my client launch script: Note that I switched out forge for modloader; things worked with modloader. Here is the server-side creation/mod list: (Yes, I know that the two mod directory server mods are not being used. That's not the point). Client side logs: Modloader (mods work and talk to the server) (Minevideo IS the 1.3.2 version; the mod author did not update the text string.) Client side logs, forge modloader

Hmm ... that actually might be the best solution. I actually did try something similar to that back before it was officially supported by Magic Launcher, but the scripting needed to make it work became a bit of a maintenance headache. (Magic Launcher has supported this on windows for a long time, but only recently on macs)

Alright: 1. Problem: FML does not limit its search to files named "something.zip", "something.jar", or "something.class" when looking through the mods directory. Trying to rename a file's extension to disable it being loaded fails. 2. Usability: The idea of having a single directory storing everything leads to problems with selectively enabling/disabling mods; we need different directories (or something) for different configs.

Maybe I'm missing something, but wouldn't it make sense to have two separate server instances in their own directories? I do this with my client installation (also keeps me from accidentally corrupting worlds with wrong mods) and it works out great. You are missing something. The servers have different directories, completely separate. But the _CLIENT_ has a single directory, with a single config directory, with a single TwilightForest.cfg file. If I have the 1.3.2 config, the 1.2.5 client crashes when I try to activate the portal, and won't see an already active portal. If I have the 1.2.5 config, the 1.3.2 client crashes during initialization. Right now I have to manually swap the files each time I switch servers. I'm looking for something better. === Actually, this was for a slightly different issue. I tried using file renames to disable mods that I wasn't using that were in the mod folder, and it did not work. But this holds promise. I can't easily generate a semi-colon seperated list, but I can work with filenames in a text file. Just for exactness: Lets say I've got a file named "mods/ConfigA/Helpful Mod V4-132.zip". Exactly what do I need to write to the config/fmlStates.properties? (Yea, I hate spaces in filenames, but some people give them.)

@cpw: One of us is misunderstanding the other. I think the idea of "Stay out of the jars" is a good thing. I like the idea of a launcher that is given an unmodified jar, a list of mod zips, and makes it work. Magic Launcher does a really good job of that. But currently, sometimes those zips have to be repackaged. Sometimes there are files that go here, there, or elsewhere. That something has been a standard for some time does not make it a future standard. You should know that -- you've changed how RML mods load. A step towards the future? A step to breaking compatibility? 3.3.8 was able to load what I'm doing with no problem. For 4.0, I had to go back and redo -- with command line unzip, rm -rf, and command line zip -- all the problematic mod zips to make them work. But the mods folder? I cannot reliably disable mods from a simple shell script. I've tried renaming them (manually), but since neither .xzip nor .Zzip as extensions stopped FML, I'm looking at having to remove all / recopy selected every time I want to run minecraft. That's ... well, that's the only thing I've come up with so far. It's incompatible with Magic Launcher's system, and it's a pain, but I think it will work. Having a single mod folder that is always used no matter what has been stuffed in there? We have the concept of directory organization for a reason -- we don't just toss every file on the system into a single directory. We don't toss everything you do into "Documents". Ok, lets look at what I actually have to worry about. A 086 Mystcraft server with one set of ID mappings (config file) A 092 Mystcraft server with a different set of ID mappings. (Both of those are 125 system, but they want different versions of the mod. One is mine, one is a friend's.) A 125 Twilight forest world with one set of Block ID's. A 132 Twilight forest world, currently for testing, that has a different set of Block ID's. The 125's default causes crashes because Vanilla now uses some of those. A main world that is 125, on craftbukkit, with one set of plugins; a new version of that 125 world, on vanilla with one set of mods, and a testing world where we're trying to get a 132 set of those mods that works for myself and three other players. Oh, but three of them have not released yet (one's in closed beta; rest will be in beta by next weekend) That's multiplayer. Then, there's single player testing/creative worlds that use different mods -- they come and go on a regular basis. Heck, for a while I was running that 1.2.5 world in single player at times when I was the only person on it -- that actually stopped when I discovered just how buggy 1.2.5 multiplayer redstone was, and wanted to make stuff that worked in multiplayer. Eventually gave up. On the server side? Main world has run on 5 different versions of craft bukkit, with 3 or 4 different tree choppers, with plugins turned on or off based on what we're doing at the time. I've got a version of that world running in 1.2.5 vanilla for testing, that goes "live" as the main world as soon as I've gotten confirmation from the last two players that they have it working -- because we decided that we want Mystcraft and Extra Biomes/Bunyan in our main world, and those are only for 1.2.5 at the moment. Which means I'm constantly having to change the plugin list, or the mod list, altering this world one way, that world another. And for server worlds, there is one mod folder per world, one plugin directory per world -- I have been moving things in and out of those folders. I am a firm believer in scripting, in keyboarding. I don't like mousing. I like being able to run games from the command line, and examine the log files. I like easy access to log files. I can run different versions of minecraft client from different shell scripts, so I can run the version that corresponds to the world I want to play in -- and all of it using Magic Launcher for the client to avoid modifying jars. There is nothing like that for servers that I have seen -- so as soon as I'm talking about server mods, I have to modify the jar. Not that I want to -- that I have no other option. So I came up with a way to reliably patch/alter/create server jars without any problem -- now suddenly I can easily test different server-side mods. I can see how superior enchantment compares to other enchantment system mods. I can test different vanilla tree chop mods, just as easily as testing craftbukkit tree chop plugins. Is it fundamentally different than having a "virtual .jar" file that is never saved as a file, but exists as a class loader that looks stuff up in a list of zip files? No. The unmodified jar file is still there, and it is all patched into something that is run. So what happened with forge 4? FML wanted to be smarter. There were assumptions of "FML assumes you are doing A, B, and C.". Those assumptions were not documented, are different from the assumptions that were around in forge 3, and do not agree with the assumptions of Risugami's ML. Good. Nothing going in the jar is a good goal. You can't start by tossing out the current, though. Old school? The idea that you have two, maybe three different ways to do something -- one current, one or two old historicals that are maintained until everyone has migrated -- is old school? Or something else? This is where I conclude that one of us is misunderstanding the other. If the old rule was "Have a mod_foobar class that inherits from class X", then why switch the rule to "Have a file named anything.class, and we'll assume every such file is valid"? That's (one of) the key point(s) I'm trying to make here. You changed the assumptions and did not document it. You made a change that broke some things that worked just fine before -- with no warnings. And broke RML compatibility in the process. Does it give you new, better, different things? I'm betting it does. Do you have a fallback? Apparently not yet.

Alright, I tried renaming the files when I'm not using them. What happens? I've tried changing the extension to .Zzip, .xzip, etc. I know that Magic Launcher uses .zipX, but I don't want to use that -- that just means magic launcher will re-enable them fairly often. So, what's a way to leave a mod in place and disable it so that it won't be active? The whole "Everything is active unless you turn it off" is a pain, and I don't see a good working way to say "Only turn things on that you want for this config". (I thought I did, but it has failed me.) So yea, now I'm trying to figure out how to both enable/disable mods in the mods folder, AND adjust which config file is in use when a mod is active.