[1.95b] Frames Bug Thread

1st Official Post

    Here are the bugs that I have found :


    1. The entire energy net quits when a frame moves. This means that all machine and all wire must be removed and replaced, or the game must be restarted. This is impossible to do automatically because a wrench will not work inside a deployer.


    2. Nuclear Reactors Cause a crash when moved.


    Not a bug : Teleporters continue to work, however, the teleporter aboard the frame can only teleport TO the fixed teleporter elsewhere. You cannot teleport from the fixed teleporter back to the mobile one. The secret to making it work is to carry a frequency linker. When you're aboard the frames vehicle, use it on the teleporter after moving the vehicle, but before you teleport back to base. Beam back to base. Once you want to return to the vehicle, use the frequency linker on the teleporter at base and it'll know the new coordinates of the mobile teleporter. Piece of cake.


    The first 2 bugs I am sure the IC2 team knows about : what other bugs are there?

    Quote from Player

    Frames are just a dirty hack which violates the normal behavior of tile entites. There's nothing we can do about it without TE relocation support from Minecraft.


    Or from Forge?

    Disappointed with the bugs and nerfedness of AtomicStryker Corp's Advanced Machines, and the unupdatedness of Snyke's Enterprises?
    Need low-lag renewable power?
    Come to ImmTech Intragalactical this thread for free UUM!
    Note: UUM may stand for Unnerfed Unbuggy Updated Machines and may not be actual UUM. The extra U was lost due to a bit error.
    Battery snot included.

    Quote from Player

    yes, possible also rp2 specific API similar to what BuildCraft did for the blueprints.

    I thought it was impossible to get an API for rp2 because Eloraam is not going to release it until she has finished rp2.

    Yeah, that's bull, RP2 is pretty much complete and almost bugfree to warrant a full release, but I guess she wants to at least finish Control, because she stated the Control in pr5 is just a preview and most recipes are temporary due to the lack of intermediary components.

    • Official Post
    Quote from RichardG

    Yeah, that's bull, RP2 is pretty much complete and almost bugfree to warrant a full release, but I guess she wants to at least finish Control, because she stated the Control in pr5 is just a preview and most recipes are temporary due to the lack of intermediary components.

    Dont forget the Worldgenerationbugs (cutten Volcanoes and Rubbertrees), uses for Tungsten and i guess with the full Release we will get a blutric Macerator, a blutric Extractor and a blutric Nuclearreactor.


    I'm still waiting for a Wafer, where you can insert Logic-Components in a 5x5-Grid with 4 In/Outputs, but with the Computer and the upcoming communitymade Scriptlanguages is that a bit useless.

    Quote from Player

    Frames are just a dirty hack which violates the normal behavior of tile entites. There's nothing we can do about it without TE relocation support from Minecraft.


    Well, oddly enough, all of your tile entities continue to function once the frame moves them. All your machines, generators, etc. The energy nets apparently depend on the location of the cable segments or something, and the code is not refreshing the network correctly once moved by a frame. Presumably, if your e-net code occasionally checked the position of some of the pieces of wire in a particular net for a movement, it could trigger a refresh and it would all work fine.


    Same with the reactor : before the code that causes the crash, stick in a location integrity check and update the pointer instead of getting those NPEs.


    This doesn't seem really all that difficult to fix. The trouble is that e-net is nasty, dense code that doesn't decompile very well, or I'd take a crack at it myself.

    Quote from BrickedKeyboard

    Well, oddly enough, all of your tile entities continue to function once the frame moves them. All your machines, generators, etc. The energy nets apparently depend on the location of the cable segments or something, and the code is not refreshing the network correctly once moved by a frame. Presumably, if your e-net code occasionally checked the position of some of the pieces of wire in a particular net for a movement, it could trigger a refresh and it would all work fine.


    Same with the reactor : before the code that causes the crash, stick in a location integrity check and update the pointer instead of getting those NPEs.


    This doesn't seem really all that difficult to fix. The trouble is that e-net is nasty, dense code that doesn't decompile very well, or I'd take a crack at it myself.


    Yes, but all of that increases the CPU load, perhaps by a great deal.