Posts by MJEvans

  • [bug][1.63 pre-from-irc] bad interaction with switches and RP2 red-wire on machines/reactor chambers?

    Unsure. The behavior I observed with both the RP2 redstone wire on machines+CF blocks (but NOT on vanilla blocks or RP2 blocks) was that I could not place a switch (vanilla) or the wire against any of the IC2 blocks I tested (CF foam wall side, and machine side); at least the later of which worked in the last stable version. (In fact I noted /that/ by seeing the wire that had popped off my massfab when the wire pulsed and the blocks updated)


    The reactor issue also allowed a 'shutdown' (forced off by redstone signal) reactor to blow up (I reloaded from the backup), and my failsafe vanilla switch on the side also failed to function (it popped off on block update, would not go back on even with shift click).



    In all cases, failed items 'fell off' or the placement was rejected outright and returned to inventory. It briefly placed client-side. This is -likely- an issue with installing the dependencies -over- Forge; but the vanilla switch makes me not sure; hence the inclusion of the checksums for my files (md5) as well as the script I used to prepare the test jars.

  • [bug][1.63 pre-from-irc] bad interaction with switches and RP2 red-wire on machines/reactor chambers?

    If he needs more reference link to this thread, though I can't really see anything super-interesting from my end. He -may- also have a newer version of MCForge than I had access to. I had to alter my installer script to get it to work with 1.3.1 (installing ModLoaderMP over it on the server instead of the other way around).


  • [bug][1.63 pre-from-irc] bad interaction with switches and RP2 red-wire on machines/reactor chambers?

    Quote from MJEvans

    I just tried that 1.63 'release' with ModLoaderMP v2.1 installed in to the server.jar -after- Forge.


    The behavior of IC2 blocks and RP2 blocks is now -way- off. I am unable to place redstone wire (RP2) against IC2 blocks. I am -also- unable to shift+click to place a switch on to a reactor chamber. --Further-- Injection of redstone signal in to reactor chamber by an RP2 not-gate (I think we used a NOR gate for that, which one isn't important) to shut it off -also- does not work.


    I don't believe the issues of #2 are caused by RP2 since the normal switch no longer places either. Is this just a pre-release bug?


    An additional thought to occur to me since my initial reply in the other thread where this was off-topic: is this potentially fixed by the rail-placement fix added to Forge or does it need a similar adjustment in IC2 code?

  • [Question] What does i make wrong with version 1.62 of industrial craft?

    Ok, I just tried that 1.63 'release' with ModLoaderMP v2.1 installed in to the server.jar -after- Forge.


    #1) It seems the ID converter script ran well, I won't have to worry about that.


    #2) The behavior of IC2 blocks and RP2 blocks is now -way- off. I am unable to place redstone wire (RP2) against IC2 blocks. I am -also- unable to shift+click to place a switch on to a reactor chamber. --Further-- Injection of redstone signal in to reactor chamber by an RP2 not-gate (I think we used a NOR gate for that, which one isn't important) to shut it off -also- does not work.


    I don't believe the issues of #2 are caused by RP2 since the normal switch no longer places either. Is this just a pre-release bug?

  • Bug: [Redstone on IC2 blocks]

    It's crash, and there are several known minor bugs that just require the right individuals to again have a little bit of spare time from their busy RL lives to provide your fix. Be glad you're this close and hit your F5 key waiting for a new Minecraft Forge release and new IC2 release to fix your woes. Just go to bed, or go to work, and check again when that's done.

  • [Support][ModloaderMP] [Dependency Of][IC2 1.62] java.lang.NoSuchMethodException: ft.getNextWidowId()


    Compare your block and item IDs from server to client; there's probably a mismatch.

  • [Support][ModloaderMP] [Dependency Of][IC2 1.62] java.lang.NoSuchMethodException: ft.getNextWidowId()

    Quote from Bluehorazon

    It's something with forge. They compiled it using the first ModloaderMP-Version. Just install as normal and copy the modloader.class from ModloaderMP over the Forge-file. More Information is in the forge-thread in the MCF. There is also a fix for an issue with breaking blocks.


    Doh; looks like I just need to wait for Forge 1.3.2 then... hope it's out soon. (asking my prospective end users to do this would be too much; they've never done any kind of modding before.)

  • [Support][ModloaderMP] [Dependency Of][IC2 1.62] java.lang.NoSuchMethodException: ft.getNextWidowId()

    I'm trying to setup IC2 1.62, however my current test seem to indicate a problem with ModLoaderMP. I was wondering


    1) If anyone else was having this
    2) If there's a known solution
    3) If there's someplace -besides- the minecraftforums (since the lack of threading there more or less ruins any good chance at proper bug reporting/reply)
    4) Possibly a someone here has an alternate route to forward the nice threaded version of the problem to the author.


    java version "1.7.0_147-icedtea"
    OpenJDK Runtime Environment (IcedTea7 2.0) (ArchLinux build 7.b147_2.0-5-x86_64)
    OpenJDK 64-Bit Server VM (build 21.0-b17, mixed mode)


    crash


    versions (in install order):


    Edit: PS, I misread this as 'GetNextWindowId; while there is no such thing as get next widow id, google does know of a get next window id

  • [Question] Disabling Certain Ore Generation

    Humm... this is the latest version. If the strings will work they aren't part of the default config file.


  • [Question] Ore BlockIDs / Macerator-Function

    Really, forge should already be bashing addon ores/ingots/ingot blocks/saplings/similar plants in to single IDs for each type of thing. Mods should support that now, and make it a default later (allowing port now while less painful, or start clean with no pain later).


    Turning on 'compact vanilla IDs' should be a further option for those with -many- mods; and the forge IDs should be packed in with them. It would also make sense to reserve the larger/more common forge member damage values as default IDs to be recycled only as a last resort (that way you could drop in say buildcraft or rp2 at a later date).

  • Suggestion: [Toolbox]

    I'd like to suggest some additions for this:


    1) a 'machine' that allows you to place the pack in to one slot and use a chest like view of it's contents in other slots (along with current inventory)


    2) The 'next non-empty row' would be extracted, allowing for multiple layers of items


    3) A way to dump the contents in to a reactor (I reload my reactors redstone-powered so I don't care about order, but dumping row after row of stuff in and then sorting the few things that miss the empty slots I wanted would be /ideal/)

  • SUGGESTION: Better Sell-o-mats

    Having not had power for ~30 hours I've been unable to check (and am at work right now on break so still can't check); is the toString of the item stack (and it's count) displayed in the owner view so we can have an idea what the customer will see?

  • [Question] Ore BlockIDs / Macerator-Function

    The machines are already almost all compressed; there are >16 machines, but only 2 block IDs for them. If you look at my spoiler I marked with ? and * the blocks that MIGHT be free-able given constraints. Anything else would require disabling parts of IC2.