Jump to content

keybounce

Members
  • Posts

    92
  • Joined

  • Last visited

Everything posted by keybounce

  1. I want advice on managing two different servers with two different config files. I have a 1.2.5 server, and a 1.3.2 server. Both have Twilight Forest. But they need different config files, different block ID's, etc. It's easy enough (relatively ...) to enable/disable the different versions for different configs. I can use the 1.2.5 version when talking to one server, and the 1.3.2 version when talking to the other. But I have no idea how to manage the different config files that the different servers need. Suggestions? Ideas?
  2. Investigating the problematic files show that they are the extended attributes of the .class files -- specifically, quarantine markers to indicate a browser-downloaded file.
  3. The forge API is very useful, for mods that want to use the Forge API. The forge API results in many changes to many base classes, so you have issues with mods that don't use forge. There is no layering, no parts, no separation, so you can't just use the subset of forge that you want/need. This means that many mods cannot work with other mods. Whether or not Lex is "a prick" does not affect a modder's desire to use Forge. It does the job of making complicated mods simpler. Whether or not Lex is "a prick" does affect the ability of users to use a mod. I do believe that Lex feels that the failure of users to learn is the fault of the users, and not the fault of the software makers/providers. I feel that that's the wrong view. I do agree that there is no actual support team for Forge. I think that if you had people who signed up for support, and had to deal with users, they would quickly realize that design decisions made by Lex and Cpw are bad decisions that cause problems for the users, and they would try to get those decisions changed. But that's the point: Since neither Lex nor Cpw truly provide support, and insist on changing how things are done (FML now deliberately breaks RML compatibility on mod loading), and no one else provides support, no one sees how bad the user experience is. And as long as the view is "Works for me", nothing gets better. Until the view is "Works for others", we have more of the same.
  4. I want to suggest that the current behavior of the mods folder is a disaster and needs to be re-examined. In the past, whether you stuffed stuff into a jar file, or used magic launcher, the basic rule of operation was the same: Stuff was only used in a given configuration of the game if you said "Use this in this configuration". Adding a mod file to a directory containing your mods did not force it to be used all the time. You had to use a launcher to enable it, or a jar file patcher, etc. Now, this wasn't the best or easiest way for users. Not everyone made their mods compatible with Magic Launcher. Some mods needed more stuff stuck into a config file or directory and expected users to unpack and much around. There was no real standard for how all this was set up. With Forge 4, universal, I had to start using the Mods directory. Naturally, this meant that when I had trouble with Forge 4, and went back to 125, I had problems there. So a quick round of Magic Launcher, disabling mods, test, and "ps ax | grep java" gave me the answer: -inactiveExtMods=Superior_Enchanting-132.zip;twilightforest-1.11.3.zip That's a bad answer. And in seeing this, I realized why it's a bad answer. You're not saying "I want to use this mod in this configuration". You're saying "I want to use everything BUT this mod". What this means is, if I have three or four configurations, then to add a mod to one, I have to go to every other one and disable it. If I replace a mod, I have to do an update dance. If I'm using different servers with different configs, I have an ongoing maintenance nightmare. Heck, just using different single player worlds with different configs becomes a nightmare. Previously, in the thread where this whole issue bit me trying to get forge to work with repackaged mods, I had mentioned using a version specific mod directory. I still think that's a good idea -- so one directory for mods in this configuration, one directory for mods in that configuration, etc., instead of one directory for all mods in all configurations. I still like that idea. I think it's easy enough to explain to users. Instead of multiple configurations for Magic Launcher, and having to deal with maintaining multiple lists, you have multiple directories, and it's either in or not in a directory. At startup, you just select which one you want to work with. Now, that might be enough for mods where order either doesn't matter, or is specified by the mod. It's not good enough in general. What I think would be better: I don't think the whole "order of install" will go away before the mod API is more developed. The whole "Use Magic Launcher" fails on servers -- ML cannot work with server jars. People do change the server and mod configs on their servers, people do connect to different servers, the whole 1.3 "easily share your world with a friend" system, etc. First: Some sort of concept of "One directory for each config". For both server and client configs. Second: Some sort of "Select these mods from a list", _standard_, for FML, where you can use order. And order is easy enough to explain to users: Number them. I've seen people try to use Magic Launcher from the assumption that the order they click on them is the order they will load (it's not). Magic Launcher doesn't show numbers in front of them, and from what I've seen, the presence of numbers is enough to express "order" for most people. People are going to try to use mods that want to be in the jar, that don't bother with the forge API, at the same time as using forge API mods. Saying "FML won't work with those" is arrogant. Saying "FML has to read your zip files, even if the class files are loaded" is a disaster. Lex, I believe you've said that users are ignorant and cannot be educated. I disagree, and I feel that as producers of products for people to use, the computer industry as a whole has been a disaster. People will use their operating system to repack files. Telling them "Compress the class files, and stick that zip in your mods folder" is one thing; telling them "Oh, but if you use Apples, you're hopeless and we won't even attempt to work with you" -- and you wonder why users have trouble? Up to 3.3.8, FML could read class files loaded via Magic Launcher, or in a server jar, just fine, even if those classes had been repacked with Apple's flat-fork leftover crud. 4.0 broke that. 4.0, to my surprise, wants to read the zip files even when used as a client from Magic Launcher, with Magic Launcher doing a merge. And while the view of "The Mods folder is there for a reason, use it" is good; the view of "You shall not modify my jar file" is good; that does not mean that all mods can be done that way. === I'm assuming that at this point, there is something either currently in FML, or going in soon, that permits mods to be distributed as a zip containing supplemental files. Take "Ruins" as an example -- it has inside it a resources directory, that is supposed to go into the mods folder, containing samples/templates of buildings to be made in the world. Or look at "Mumble Link" -- it has compiled binaries that are supposed to go inside the bin folder. What these have in common: Right now, they have to be opened up and repackaged. Both have to be opened up, the subfolders and inner zip files moved here, or there; in the case of Mumble Link (written for RML, not FML) the insides contain a single mod_xxx.class file, a second .class file, and a directory of class files; along with a directory of natives. The instructions say "Add this to your jar file". The instructions for Magic Launcher say "Repackage all such problematic mods as a new zip file, and give that to me". All of this works just fine with RML. And if the goal of FML is 100% compatibility with RML -- which you state on every page of this forum -- then you cannot just say "Your mac is useless", or "You're an ignorant user", or "You have to use the mod folder". RML does not require that. I do not have the ability to use RML for some mods, and FML for other mods -- the instant I need a forge mod I have to use FML for everything, even those mods that don't use forge. And things that work with RML now break. And the "single directory for all mods" fails to work with multiple configs. And the whole "Use magic launcher" scales nicely for interior mods, but not for exterior mods. And even that fails completely for servers.
  5. That makes sense. That assumption -- that you'll always be online -- is not a good one. I don't mind the files being needed for download. But how about a warning? A notice? Some indication that "If you have never used the new forge, and are going to play offline, you'll also need these files". I have a laptop, and I don't always have a network connection when I play. Fair enough. But here's the thing: This has worked just fine in 1.2.5 / 3.3.8 forge/fml. It broke now. And, for what it's worth, it only broke on the things that I had to repack in finder. Things that get unpacked/repacked by command-line zip behave just fine (see that create_server script file) Ok, then tell me where I use that for _SERVERS_? I have not found any sort of manager for servers. Fundamentally, a server world is a database of blocks and code that accesses it. I can, and will, change that access code. I have switched between vanilla, CB, forge mods; I have altered the list of mods on/off each time; I have changed versions of the minecraft server. Having everything in the jar file -- which has worked just fine up to 125 -- means that if I am running a given jar file, then I know exactly what configuration of mods and server I'm using, without having to worry about "what got left over in the mod folder". CPW, I'm going to give you a quick lesson on software longevity: Fixed path assumptions are bad. I'm going to go with the assumption that there's something changed in forge 4 that breaks this past behavior. I'm going to go with the assumption that you know of failure cases that I don't, things where this really will cause problems that I haven't seen. I'm going to go with the assumption that there really is a good reason for having mod packages in their own little place, not part of the distributed code package. Heck, I'm going to go with the assumption that your goal is to have the completely unaltered vanilla server jar, a loader program that you use to load fml, forge, and vanilla, such that you never have to alter any of the disk files, and then every file is kept intact and unchanged so that they can be signed, sealed, delivered with a guarantee of no viruses or bad things. All that is good. Heck, it's not any different than using Magic Launcher to use an unmodified minecraft.jar, a bunch of mod zips, and a loader that does an "on the fly merge". It's no different than my attempt (failed, sadly) to set up Os X so that all of Apple's stuff on the root partition was separate from all of my stuff on a UserData partition, same sort of setup I've used in almost every unix install I've ever had at home. (LaunchD in 10.7 is stupid. It won't attempt to mount local fixed partitions before it checks for the validity of several important paths, and won't even start the system in single user mode if those paths fail -- so attempting to have /tmp, or /var/vm/ (swapfiles and hibernate file) on the second partition results in having to use the emergency recovery disk, and that's when I found out that 10.7 puts a recovery partition, not at the end of the drive, but right after the root partition -- so I can't make the root large enough, and I'm stuck. And I can't go back to 10.6 because it can't install with that recovery partition. Gaarrgggh.) But a fixed name folder, "mods", that has one name, potentially used by many different things? C:\Program Files was a bad name, especially when C:\Windows, C:\Winnt, and C:\Win95 all might have wanted to have different things in the same place. Having one fixed folder, "Mods", that cannot be changed or reconfigured as a command line argument is a recipe for disaster. Please, give us the option to specify a mod folder on the command line. That way, I might have a different folder, and different server.jars, for running on 1.2.5, or on 1.3.2, or on 1.4.1, or on 12w35b, or on CB1.3.1, or on CB1.3.2, etc. That way, I can turn various mods on or off by just using a folder that has or does not have that mod's zip. This way, the startup might look something like java -Xms30m -Xmx700m -jar new_server.jar nogui --mods Mods132-test3 I'll remind you: The single biggest problem that shows up over and over in Risugami's thread or in Magic Launcher's thread seems to be the whole "stuff was left over in the Mods folder from a prior version/installation" issue. (with duplicate -- in both Mods and the jar/magic launcher -- being number two). I don't think you really understand what you're saying here. Here's how I run 125: Or, here's how I run 125 when I'm talking to a mystcraft server Or, I've got other variants of both of those -- some servers use different mods, there's an annoying issue where the default Id's used by mystcraft changed between 086 and 092 so if I'm talking to an older 086 server I have to alter the config file, I'll use nether ores in one test world, but not in another, etc. So ... just stuff it into a single static folder that can't differentiate based on which server I'm planning on playing with? Use a gui overhead to launch a program, rather than a terminal window where I can hit "ctrl-Z" when I need to pause the game because the fan is running too loud / CPU cores are getting too hot? (They hit 99 degrees C, and the emergency shutoff triggers if they go over 100 -- or so I'm told, I haven't actually tested that). And as for "Use Magic Launcher", well, I tried that for 132. Again, this is my first attempt with 132, and the new forge universal. This is through the GUI, so I can determine what order things need to be in to update my scripts. And, since I saw the whole issue with the server, and the mcmod.info overwrites, I actually tried to use the external mod folder this time. Now, never mind the duplicate block ID in there. If you recognize it, please tell me; otherwise, I'll hunt down why Twilight Forest is conflicting with agt (which isn't replaced by anything that got placed into the jar, so it's a vanilla 132 block ... probably a 125 config of twilight forest leftover that fails in 132, I'll figure it out.) Again, the unexpected download of additional stuff without warning. These are complete surprises to me. The specified mod folder has the following: keybouncembp:13Main80 michael$ ls '/Volumes/UserData/Users/michael/Library/Application Support/minecraft/ mods' total 2584 0 MumbleLink/ 0 sppcommands/ 96 Superior_Enchanting-132.zip* 2488 twilightforest-1.11.3.zip 0 resources/ keybouncembp:13Main80 michael$ So somehow, it has detected the actual zip files passed to magic launcher I never pointed FML at that directory. There are mods in that directory *that I do not want to use for this*. There are mods in there that are conflicting, or not being used, etc. That is the full storage of all 132 mods. My 125 folder has something like 7 or 8 different versions of optifine that I accumulated as it kept patching. It won't surprise me if something similar happens now. I don't see any sign of ruins, or water propagation fix, being loaded, so it looks like it's only looking at the mods actually being used by Magic Launcher, rather than everything in the directory -- good. But again, these are mods that are jar mods, not mod-directory mods, that have to be in the jar file, that have worked with this repackaging in 125/338, that (as far as I can tell from working with 125) work just fine when accessed by Java's reflection API to find the mod classes, but give an error when trying to read the zip file. Incidentally: As I said, when I run the server, I specify "nogui". Yet I still got the dock icon for the server. Does not happen with 1.3 vanilla, or 1.3.1 craftbukkit.
  6. I just attempted to run forge universal, minecraft 132, and some mods, all together. Up until now, I've been on 125. Starting up minecraft gives this output: The first surprise was that FML is not completely installed, but wants to download some additional stuff on first run. Had this been an attempt to play offline, this would have been an unexpected disaster. The second surprise: This style of operation worked just fine in 125 forge/fml, but it is now dying on the mods that I had to repackage and what I'm assuming are the leftover shadows of empty resource forks. The third surprise: Complaints about the mcmod.info file. In 125, I kept everything in the server jar file, nothing in the mod folder -- something I picked up from dealing with several different client configurations, connecting to different server versions, so anything being in the mod folder was asking for conflicts and problems. In assembling the 132 jar file that way, I found that (apparently) FML wants a mcmod.info file at the same filename for each mod -- so FML mods that are put together in the server.jar cannot help but overwrite each other. This time I put the server's mods into the mod folder, and got a complaint about the server.jar file itself. Attached files: 1. Script used to generate the server jar file 2. Script used to start the server jar (NB: Although I specify nogui, I still get a dock icon for the server) 3. FML-server-0.log
  7. ... and it's Lights Out. Grumble grumble phantom skylight grumble grumble cave worlds in mystcraft grumble grumble Vechs ...
  8. I am getting a strange error in 1.2.5. I don't know who/which mod is responsible, but I'm using yours. The error first occurred the last time I played, trying to go into the nether. It now happens at startup. The server was created by the following: Can you help me locate this error?
  9. The good news: It seems to be working? The bad news: Server says I need to get 5 redpower mods, and 2 computer craft mods.
  10. No. I see errors and missing class members, so I figure that's serious enough to cause a problem at run-time.
  11. I'm having trouble with a "simple" forge install. Using Magic Launcher to "patch" jars, installing just modloader and forge, I get this: Modloader-125.zip ok minecraft-forge-client-3.1.3.105.zip 2 errors Log: Missing class member: public (Lxd;IIIIFI)V a, class: jx, mod: minecraftforge-client-3.1.3.105.zip Missing class member: public (Lxd;IIIIFI)V a, class: rr, mod: minecraftforge-client-3.1.3.105.zip This is before adding any actual mods to use forge; my goal is Mystcraft, mystcraft forge patches, and optifine. So as someone that has failed the first step: What am I doing wrong?
  12. OK. You do realize that it had 0% chance of working on PPC until the very recent discovery that Apple had a pre-release J6? I'm actually surprised the download is that high if it just plain wouldn't work at all.
  13. Apple dropped it primarily because they could not get it in sufficient quantities (first), and the larger optimization support for X86 (second) (at least, that's the official world). Major game companies stopped supporting PPC macs because Apple stopped making them. Minecraft still supports it (two lighting bugs; one caused by byteswap that makes torches produce skylight, and the open sky produce torchlight; the second (unknown cause) causes skylight to leak though edges if the surface dirt/grass is only one layer thick). Lighting bug aside, it's fully playable, and even usable with Optifine (At least, 1.2.5, singleplayer -- multiplayer is a pain, and 1.3 remains to be seen). ... I'm trying to make sense of this. Separating out forge's modloader functionality from it's "hook into the game functions" functionality ... well, I can certainly see that for many people, they will both be used together, because many mods will use the hook-into-game-functions. But by that logic, everything to support all existing mods should be tacked onto Modloader. And that doesn't happen, right? A fundamental rule of computer science, over the last three-four decades: Break things into parts, and keep the parts separate. Given that Modloader has shown that modloader functionality is not the same as hook/modify functionality, and given that FML already exists as a separate system, it really seems to me, to make sense, to say that the existing "Forge" system is too big, and needs to be broken into two parts -- one is the modloader, and the other is the hooks, and while everyone will be using the loader, not everyone will be using the hooks. Am I misunderstanding something basic here?
  14. So reviewing this, I realized it may seem unclear. As of 1.2.5: Modloader (Risumgami's) is the current best way to add things to minecraft. It only has to add stuff to the single player version; it has no client/server timing issues to worry about. As of 1.2.5: Modloader_MP is dead. As of 1.2.5: FML is the best way to get Modloader functionality into multiplayer. Moving forward: 1.3, maybe, or 1.4, definitely, will have single player games running as a client/server. That means adding mods into minecraft will require FML (as a multiplayer mod loader), and Risugami's will be dead. That means: Moving forward, Java 5 PPC macs will either have FML or will be F'd, my life. That, in turn, means: Since Forge's system of hooks and callbacks cannot be made to work with J5, then those parts of it which can -- and permit simple adds-ins to work -- needs to be separated out, so that there is a clear "Simple forge-compatible, single player server-compatible, mod loader replacement for J5 and J6 systems" ("FML"), and "Complex, J6 only system of hooks and callbacks" (ForgeHooks, or whatever). Yes, J5 macs are kinda old. But a 1.42 GHz PPC is more than twice the power of the minimum system requirements, and almost as good as the recommended system requirements. And there are 1.6+ G4s, as well as G5's and dual-G5's out there. EDIT: Just got ninja'd -- let me see what was added
  15. Power PC macs do not have access to Java 6. Well, that's not completely true. There is no official port. There is an unofficial port of J6, but it is based on version 3 of J6 which apparently has lots of bugs, and the port is not really finished -- it "sort of" almost works. === Risugami's Modloader supports J5, as do lots of mods that I want to use. But going to multiplayer requires FML, and FML, as part of forge, requires J6 because forge requires J6. And the goal is to run in craftbukkit; MCPC distributes a craftbukkit + forge combo that is J6 required. Given that apparently a large amount of forge needs J6 features, but simple modloader type functionality does not, I'm assuming that FML itself can be compiled with J5 only, even if the rest of the forge hooks require J6. So, let me restate my goal/request here: 1. Those parts of forge that do not use J6 language features are J5 compiled/compatible, and 2. Distribution clearly has two parts, so forge addins (or multiplayer FML mods) can be identified as J5 ok or J6 required. Is this in the range of possible? Is this even reasonable? It seems to me it is -- you have modloader functionality, and hook access functionality, and it seems "obvious" that instead of the old rule "Modloader, Modloader_MP, Forge, Optifine, in that order" it should now be "Modloader, FML, ForgeHooks, Optifine, in that order" -- or is that an impossible refactoring/decomposition?
  16. So forge currently says something like keybounceMBP:minecraftforge-client-3.1.3.107 michael$ file m* minecraftforge_credits.txt: ASCII English text, with very long lines mm.class: compiled Java class data, version 50.0 (Java 1.6) mn.class: compiled Java class data, version 50.0 (Java 1.6) mod_MinecraftForge.class: compiled Java class data, version 50.0 (Java 1.6) ms.class: compiled Java class data, version 50.0 (Java 1.6) my.class: compiled Java class data, version 50.0 (Java 1.6) Any chance of getting this compiled with the version 49/Java 1.5 flag?
×
×
  • Create New...

Important Information

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