Jump to content

cpw

Members
  • Posts

    195
  • Joined

  • Last visited

  • Days Won

    2

Posts posted by cpw

  1. They are working for me with FML build 356. With regard to forge, they may not be compatible with the additional base edits forge makes, though I don't see why that would be the case. I tested all CJB mods except xray and the PlayerAPI dependent mod.

    Note: you need to force CJB_MAIN to load first: add a 0 (zero) in front of it, and it'll work.

  2. I'm sorry, the mods are identified on the client, right? They work on the client, right? How do you know they're not working on the server? Just because they're not identified as present on the server?

     

    The list of mods "joined" on the server is the accepted subset intersection of server and client mods. That is how FML is designed to work. The whole list is sent for possible server side rejection but is not identified as being the "joined" list because it is discarded. The only mods "reported" as being joined, are those that FML believes are important, specifically, KNOWN mods present on both client and server - they are the only mods that can control acceptance or rejection of the connection, so they're the only ones that are relevant. The 1.2.5 argument is specious, because 1.2.5 handled mod handshaking differently (it was not handled by FML).

     

    Name one server side mod in your list that is actually an FML or proper server side modloader mod, please? Then I'll take this bug report seriously. At the moment your complaint seems to be that server side superior enchanting may or may not work. Which quite honestly I'm tempted to consider "not a bug" because of the way it has to load itself on the server, and the lack of proof that it actually ISN'T working. (Stack traces? errors? anything else?)

     

     

  3. None of those are FML mods. They will not be "negotiated" because there's nothing to negotiate. Superior enchanting works by replacing containerworkbench and containerenchant on the server side directly.

     

    It may or may not do it's own handshaking the first time one of those is accessed. I'm not sure what you're expecting to see here? None of these is a standard FML/ML server side mod. None of them will participate in that handshake because they can't. They may or may not actually work - I'm betting none of them is particularly compatible with anything we do in forge, but who knows. If they don't work, that's because they're not designed to live in a multi mod client and server environment. I can make efforts to provide ML compatibility, probably beyond the scope of ML compatibility somewhat. But I can't work miracles and make code that's not even designed for FML/ML/server side work there.

  4. The mods folder is easy: it's a defacto standard and has been for some time. I'm not going to change it. I may make it configurable. As for the rest of that? Holy wtf batman. That's like. Fine, if you really want to have 100 minecraft servers in overlapping folders, go ahead. The worlds will be incompatible with each other so your saves generally won't work from one minecraftserver jar to the next, but that's your choice I suppose.

     

    Your scheme really doesn't address the idea of trying to get very hands off from the jar at all does it? The idea is that at some point the *only* change that goes into the jar is an alternative main() implementation. It's still a way away but it'll happen. Or you'll be in modapi world where all bets are off again and this time you won't have a sympathetic (relatively) ear, you'll have wall of silence from mojang.

     

    The reason we try and keep out of the jar is simple: less change in the jar is better. We *can* do things like authenticating the jar. We have two kinds of mod types now: ones that are "normal" and ones that are "special" coremods- they get access to the ASM bytecode layer so they can make basecode changes without changing the basecode!

     

    They're handled by loading differently. And they're deliberately designed so i can drop a key in and force authentication of the things if the need arises.

     

    Your arguments are from an old school world that is sadly fading away. If you wish to, for now you can merge everything into your jar file. Don't expect that to keep working for long though. And coremods *have* to be separate, already. They are designed never to work from the jar.

     

    Finally, on those .class things- i'll have to add a special "mac is stupid and creates artifacts" filter. Thanks for bringing it to my attention.

  5. Hello

    Well, I cannot for the life of me make this problem occur on any linux install I own or create. I have no idea how you got java to run in such a barebones environment.

     

    I am attaching an experimental FML build to this post for you to merge into a minecraft_server.jar and report back success or failure. If this works, I'll push and merge it to generate a forge build. If not, I need to know how to build your environment...

     

    Note: just merge and start this up. Do not do anything else. it's not going to work with forge as it stands...

×
×
  • Create New...

Important Information

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