Posts by BrickedKeyboard

    99percent : a fork of the bukkit version that I use on my server has another solution to this. Items falling on the field cost it energy. It's possible to make a "railgun" where you use railcraft launcher rails to send chest carts filled with items (the more items, the better) at the shield. Eventually you can overwhelm almost any power source.


    There's also a lot of ways to make user errors with a force field and have it go down. Honestly I don't think that "balance" is even an issue : why should someone be able to go anywhere and grief anyone at any time? Without incredible defense, on a PvP server with no rules at all there's absolutely nothing you can do if someone attacks your base when you are offline. Also, minecraft handles latency extremely poorly with no client side prediction or any other the other things that would be needed to actually have decent PvP battles.


    And there are several glitches that allow easy bypass of a shield. Have you tried glitching through the floor? It is extremely easy to do and is the method I use when I am playing as Op and need to get inside someone's shield.


    (on the bukkit port, there is a counter to this, a quick feature that I wrote)

    Bug Found : the petrochemical generator will not consume a fuel bucket unless it is removed by the player, using the GUI. It does not scan it's own inventory for full fuel buckets and remove them automatically. This prevents you from using redstone power to refuel a generator using pneumatic tubes, which would be a convenient feature to have.


    FIXED : All you need to do is add to your OnTick() class for the TileEntityPetrochemicalGenerator.java file is your function "update();" to the top. That will cause it to check if it has buckets in inventory every tick.

    java.lang.ArrayIndexOutOfBoundsException: 1
    at mffs.TileEntity_Area_Projektor.onNetworkAPI(TileEntity_Area_Projektor.java:87)
    at mffs.NetworkAPI_Client.HandlePacket(NetworkAPI_Client.java:57)
    at mod_ModularForceFieldSystem.HandlePacket(mod_ModularForceFieldSystem.java:189)
    at ModLoaderMp.HandleAllPackets(ModLoaderMp.java:83)
    at Packet230ModLoader.a(Packet230ModLoader.java:157)
    at hc.b(SourceFile:272)
    at abp.b(NetClientHandler.java:81)
    at ma.c(SourceFile:56)
    at net.minecraft.client.Minecraft.k(SourceFile:1593)
    at net.minecraft.client.Minecraft.x(SourceFile:705)
    at net.minecraft.client.Minecraft.run(SourceFile:658)
    at java.lang.Thread.run(Unknown Source)


    Not certain what it takes to cause this, but it is possible to place an area projector and somehow this happens. This is with my bukkit port : it's quite possible that something in bukkit is the root cause.


    However, regardless, your client should not allow an out of bounds index to be processed (it should ignore the projector instead of causing the client to crash).

    The recipe for the petrochemical generator is pretty silly, and unbalanced for it's output. If you run a buildcraft combustion engine on fuel and a power converter from the other mod, you get the same total energy, but at a much slower rate per tick and at a higher cost. I've done quite a bit of math on the other generators in Industrialcraft, and I can say with certainty that this one isn't balanced. Also, you get 600,000 energy from 1 bucket of fuel and you do not need much energy to convert oil to fuel. Thus, the oil materializer that makes 1 uu matter into 20 oil is not balanced, either.


    In any case, here's the recipe for the petrochem generator on my server. I feel this is very close to being balanced when you account for how good this generator is. Here's the line of code that defines it :



    Bugs Found :


    In the Bukkit port, if a chunk isn't loaded (so the type id would probably be null) the shield will still try to replace the block there. It does not bother to check if there is a block there that can't be replaced, so it replaces it with shield even if there is something that is not supposed to be broken there. (such as a personal safe, or bedrock, etc)


    I found this line :
    if(!forcefieldworldmap1.ffworld_getfirstfreespace() && !world.getMaterial(forcefieldworldmap1.getX(), forcefieldworldmap1.getY(), forcefieldworldmap1.getZ()).isBuildable() )


    and attempted to fix by changing it to


    if(!forcefieldworldmap1.ffworld_getfirstfreespace() && !world.getMaterial(forcefieldworldmap1.getX(), forcefieldworldmap1.getY(), forcefieldworldmap1.getZ()).isBuildable() && !(world.getMaterial(forcefieldworldmap1.getX(), forcefieldworldmap1.getY(), forcefieldworldmap1.getZ())== null) )


    I'm not sure if this fixed it, because I don't understand how a lot of your code really works.


    I also found another bug : the EU injector can sometimes stop working. I added a couple more checks to it that hopefully fixed this bug, but since I was unable to reproduce this problem I wasn't able to fix it.

    Bugs :
    1. The suit will regenerate it's own health if it takes a large amount of damage in one hit. This is because the code does not check to see if the damage taken will put the suit over the threshold for damage (1001). I fixed this for my own copy, and it works.
    2. The suit will still absorb some damage even if the power level is depleted. (more than it would if it were armor)
    3. If you die while taking a big hit, the suit parts will be destroyed. Again, this is because the code is not threshold checking.


    4. NO Energy is used in SMP to increase the player's jump or speed. This is because the client never tells the server when speed running/jumping is on. (this might be bukkit only)
    5. The client code obscures the true food level of the player. It should not affect food if platform is not simulating.
    6. The client code applies the same speed boost while inside the nether, not factoring in that coordinates need to be divided by 8.



    All these bugs are fixable, I have fixed most of them in my copy. For number 4, since I don't fully understand the client-server communications, I just made it so the client doesn't subtract energy to run/jump and it doesn't feed on the client if it is on server.


    And of course the suit is ridiculously OP, but everyone knew that.


    Also, the nano suit has the same "big hit" bugs as quantum. It can regenerate, and it can be destroyed on death.

    Thunderdark : I found a bug that I think is client side. If you equip an MF device in a multiplayer server, where there are other players who are NOT right next to you (that is, they are outside the chunk loading range), and then right click the MF device to switch modes, it crashes all other clients on the server.


    That is, you don't crash, and the players that are next to you don't crash. Only far away players crash. The server does not crash.


    The error message states that an invalid packet was sent and references this mod. I suspect you need some sanity checks in the client for processing packets with MF device changes in them, and the bug won't happen.

    Right so the new bukkit thingie is running smoothly on my forge/redpower/buildcraft/IC2/bukkit server (I had to change some annoying block ID's but everything seems fine)


    The client is another matter: It crashes horribly.
    Now I changed the block ID's in the client as well and considering that the server is running that should not be a problem.
    And it isn't because I 'asked' modloader to only load IC2 and the modular forcefield mod and it still crashes horribly.


    This is the report modloader gives me (the report from minecraft itself flashes by to fast to read)


    I am not certain of the cause of this error, however, you can download the client I use at brickedtechnology.blogspot.com and use it. You'd have to adjust IDs and so forth, and remove the mods that I have, but it would work.

    JustVisiting : those "embodied energy" studies have a major flaw. In the scenarios where it is physically possible to get those panels onto your roof at a lower cost than the power company charges per watt delivered (it is quite possible to do that today. Go to sunelec.com and just look, there's hundreds of kits that would have a payoff within a decade at normal power prices in a state like Texas), how is the manufacturer of the panels able to provide energy at that low a price. If a solar panel manufacturer could create energy to produce a panel at such a low cost as to break even at the prices they are selling them, they could make more money by selling energy on the open market.


    It also doesn't pass another test. Modern solar panels have a higher efficiency rating and a higher lifetime than any photosynthetic organism. (I don't think individual cells in any form of tree last for 20 years). Yet, obviously, the energy provided by photosynthesis at the low efficiency ratings nature is capable of (just a few percent) is enough energy to allow the plant to self replicate and generate an energy surplus.


    Please link one of these studies. It needs to have a publication date within the last 5 years to have any realistic validity. I earnestly think that the solution to the world's energy problems is to


    1. Develop a solar cell design that requires the least amount of rare earths and other expensive materials while providing good efficiency. There's hundreds of university labs that have published varying designs, it is quite likely that such a design has already be developed.


    2. Develop an automated manufacturing process for this cell that can produce it in enormous quantities, with the least human labor inputs possible. Build some of these factories.


    3. Begin covering the world's unpopulated deserts with these panels, selling the electricity produced and also using it to run the factory and pay for additional factories.


    4. Keep going until we've covered enough desert to run the world off of solar. It's possible to store the energy for the night in many ways, from some types of batteries to electrolyzing water to hydrogen (possibly reforming to methane after that) and then reversing the process. There is enough desert, easily. (the U.S. could run off of 100x100 square of arizona, leaving most of the state empty)


    The advantages of doing this are myriad, and I think that ultimately the economics will push power production to this. Solar plants won't require a lot of maintainence, or purchasing of fuel, or many environmental impact mitigation actions (since all you have are static panels on the ground somewhere). One has to optimize and automate the manufacturing of a single solar cell type to an extreme degree, and all panels produced world wide will become cheaper. (versus if you tried to say, make nuclear power plant parts cheap to manufacture...there are thousands of unique parts inside a nuclear plant and each one of them would require a separate effort to optimize, while solar panels are all the same)