Posts by Two

    1: Inventory size is a game design question about how mobile the author wants you to be, and with most things being stationary, you obviously shouldn't be too mobile. Whether or not the player likes that is a different question. For everything else there is a teleporter and the ender chest, although those are not helping on a nomad play-style.


    2: Again, game design problem: The Quantum Suit makes you mostly invincible, the only drawback is that your electric items can no longer be recharged by your pack. If that pack would be integrated into the quantum suit, you would be invincible and have no drawbacks at all. Imo the whole quantum suit concept is too op to be reasonable even though you need massive amounts of EU to produce it. Once you have it, you basically won the game.


    3: There are already some compatibility parts in IC² to work with RP, BC and other mods, but the more you add the more complex the whole thing becomes. It is already a nightmare to keep up with Forge/Minecraft development as you basically need to rewrite half of the code every 3 month. Add a few other mods, and you can hire a complete team just to keep the addon compatible. And not every other mod author is that cooperative, when I remember the result from the talk to Eloraam. So for a single hobby author leaving the task to make mods compatible to other people is a reasonable thing to do.


    4: I would love to see some use for those dead parts instead of just removing them. Some things can easily be turned into viable options easily, e.g. I wrote a quick 3-line addon to change the recipe for dynamite and voilà they are a reasonable early-game alternative to mining. Similar things could be done to bio-fuel, for example making it a non-metallic Tier-0 set (compost reactor ;)), or giving it extra abilities that makes them an option compared to the usual way. This however requires time and thinking, and from my perspective it looks like the IC-team does not spend the major part of their day on advancing the mod.


    5: Absolutely agree. You can't just build a nuclear reactor on a public server as griefers just need to flip out some components and boom there go your days of working. But just adding a pass-code to the reactor would cause people to just wrench it instead. There should be a way to secure reinforced doors, so they only open given a certain pass-code, then you can spend the resources and build a secure room for your reactor. This still would not stop all griefers, but building a laser before you can break in somewhere takes at least enough time to stop most server hoppers from griefing you.
    The nuclear bomb can be deactivated via config, and I strongly suggest to do that as a server admin. I would even go that far and deactivate it by default, as the bomb actually servers no other purpose than to create a huge explosion.

    Hi,


    I am currently trying to get a bit into the IC² API however I can't even seem to get Forge to load IC² from Eclipse.


    Steps I've done so far:
    1. Clean MCP install (7.2)
    2. Clean Forge src 4.1.1.251 install
    3. Copied clean Jars/libs
    4. Run Forge install.cmd
    5. Started Eclipse, launched the game, everything works fine
    6. Copied industrialcraft-2_1.106.jar to jars/mods
    7. Launched the game again (from Eclipse), crash:


    Any idea what I am doing wrong?

    While I agree the reactor time is rather unrealistic, there are several game-design factors that make it a better choice to have them refilled frequently. For once to craft your version of Uranium a player would have to gather up to 80 Uranium ore before a currently entry-level reactor could be crafted, which means you probably already have a wind farm generating way more power anyways, and on the other hand having a permanent, almost infinite power source is kind of imbalancing if the player has it too early in the game.


    As a compromise I think an additional version of Uranium fuel for when you have too much Uranium anyways might be a better idea. Basically a condensed Uranium cell that is made out of 20 Uranium ingots and while giving the same amount of EU it just lasts 20 times as long as a standard Uranium cell and can be used wherever a standard Uranium cell could be used as well.

    The big question is whether or not this design if more efficient than if you would have spent all those resources on just a few stable reactors. Beside the resources required for the reactor itself, you need additional filters and pipes as well as several spare-coolant cells.

    The current dynamite recipe requires to build 3 standard TNTs first, and therefore requires a total of 15 gunpowder before you can craft dynamite. Unless you farm Creepers a lot, you usually have superior tools available before you have gathered 15 gunpowder. I therefore suggest to change the recipe to require 1 gunpowder, 1 sand and 1 string for 2 dynamite (15 gunpowder = 3 TNT = 4 industrial TNT = 32 dynamite, so 1 gunpowder ~= 2 dynamite).


    This would allow players to use dynamite much earlier in the game, as you just need sand and wool (frequently available) and 1 gunpowder to craft TNT. This would be a more appropriate form of mining instead of using stone pickaxes.

    This is a pretty good example of why test-driven development, or even just unit testing, is a fucking amazing thing.
    Write a test to exercise the code handling something, if it breaks in the future, the tests will reflect it.


    I am not sure if you know the vanilla Minecraft code, but it is on average a big pile of mess with some not-so-bad parts every now and then. Doing TDD is close to impossible on top of that mess and unit testing on experimental code (aka game development) is imo slowing down things more than it helps. There are other methods like Module Driven Development, which are much more helpful on frequently changing code while reducing the amount of bugs drastically as well.


    Anyhow, beside discussing religious believes ;), some form of development process other than hacking it together & release might be helpful to reduce the bugs on IC as well.

    Two things from my side on this:
    1. BUG: Heat spreader inside a reactor often do not properly cool down all heat even if the reactor is shut down. This causes these items to be left with a fraction of heat and therefore with a fraction of damage, making them unusable in recipes. Only certain components actually manage to cool them down properly (like the component cooler).


    2. General: To my understanding this version had an increased version of testers, yet it feels like the buggiest version released ever. I think there should be the question around: why? Not to blame and to call names, just for one reason: to figure out what could be done better next time.
    While I absolutely agree that releasing a version without any bugs is probably for a hobby project unrealistic, some things shouldn't even happen in such a project. If bugs are so plain obvious (like the jetpack not working, CF-Pack charge, or the Quantum helmet crash (just to name a few), it becomes equally plain obvious that testing was not done at all on these items, as otherwise these bugs would have been immediately noticed. In my opinion such versions of IC² should either be released clearly marked as in-dev versions, so everyone knows they might encounter lots of bugs, or the concept of testing should be on the table to discuss in general.

    I just had the most annoying version of that bug when I accidentally connected the output of my MFSU to my machine set (Macerator, Furnace, the usual stuff). Lucky me realized in time that I did it as no machine so far drew power, so none exploded, so I quickly cut the line apart.


    But from that point on every time I tried to use a machine it exploded. After the second explosion, I decided to dismantle the machine and used my wrench: the machine exploded. So I decided to dismantle the MSFU first, then the next machine, and it exploded. With the MFSU in my pocket. Once all machines had exploded I realized that even the Batbox was still transmitting all its power to the MFSU in my pocket! And if tried to place any new machine anywhere on the no longer existing line it instantly exploded as well.


    Had to restart the server to get rid of that. -.-

    It kinda does. It implies that it requires IC2 to function, and modifies/extends a functionality of IC2.


    So according to your words it is an IC² mod then, because it changes functionality of IC². The crafting change applies to IC² tools as well, so you cannot craft diamond drills i.E. unless you have upgraded your crafting table first.


    Quote

    not sure if thats relavent for your mod, but it really helped me


    Thanks for the idea, but with the recent update there is virtually no lag even with that rather long pathing of mobs. I even consider to make the pathing a standalone mod, because it just eliminates almost all lag out of Minecraft servers that you previously had like with mob-towers. ;)

    You feel that Minecraft is too easy? You punch Creepers into other mobs, dodge arrows with your eyes closed and have started naming those zombies chasing you? Then this is the right thing for you.


    Find all details in the Minecraft Forum here


    Tested and currently running with IC² 1.106. =)

    Another thing that is not necessarily wrong but probably could be improved are the cooling cells. Now they are kind of a heat-buffer for reactors - which is ok - but you can either use them all the time or not use them at all.


    Example: I place a coolant cell next to a heat distributor to check whether or not that component will overheat, but it doesn't work because the coolant cell always gets its part of the heat (the heat distributor is not smart in this case). So I place it next to a reactor distributor (that saps heat from the reactor only), but here is the problem: this only works as intended if these components are placed down, right otherwise it gets the heat first and then the heat vents start their working.


    It might be more intuitive if the reactor tick instead works by priority as in:
    1. Uranium cells emit heat
    2. Heat vents try to sap heat from everywhere and use adjacent cooling as much as possible to remove the heat completely.
    3. Remaining heat is distributed evenly to surrounding components.


    This would eliminate the top-down rule and allow coolant cells to act as security buffer in experimental but supposed-to-be-stable setups.

    Hi, some bugs I encountered yesterday while playing 1.106 with a friend (finally!! :) ). Please note that I didn't research these bugs, so I can't tell you whether they were just random or happen all the time.


    - MFE does not output a redstone signal reliably. The (vanilla) redstone wire was attached to the back side of the MFE, the MFE was set to "emit if partially filled". Initially the redstone signal activated, the immediately went off again. From that point on no matter what I set the MFE to, no redstone was emitted.
    - Swords do deactivate but the animation does not. This was fixed with 1.103 but not it's back. Dropping and recollecting the sword fixes that temporarily.
    - Constant explosion bug (already mentioned in other threads).
    - Leaves of rubber trees cannot be transformed into plant balls (other leaves work fine).
    - Machine/item sounds most of the time do not work.


    Not bugs but feature issues:
    - The iron furnace does not accept lava buckets, the stone one does. That makes the "upgrade" a lot worse than the initial version if you have access to lava (which you usually have).
    - A set of carbon armor without the chest piece is not enough to survive a full creeper attack (or at least almost kills you, not enough test samples ;)). If you don't happen to run into mobs all the time (so the recharge feature does not overweight) it is easier and cheaper to just build iron armor.



    Btw: if you are still looking for good coders, I'd love to help. Beside the good coding I happen to be excellent at bug fixing. ;)