Posts by Krid

    I haven't seen an answer for this, but why is the Advanced Pump so incredibly slow? I have one here that's full of energy (With an energy orb upgrade, no less!), and a liquid valve panel connecting right to a quantum tank, and it's only working at about a block per second.


    The documentation is nonexistent, so I can't tell if this was an intended nerf that makes the advanced pump pointless, a bug, or intentional self-sabotage when Buildcraft is detected in response to the addition of oil fields.

    it always annoyed me that i can't go mining with bodyarmor. a way to combine armor with lap, bat, cf, jet packs :Quantum-Bodyarmor: / :Composite Armor: / :Bronze Chestplate: / :Nano-Bodyarmor: + :Batpack: / :Electric Jetpack: would be great! or at least quantum armor that works as power supply for your tools (just like the lappack)

    I do like the idea of using the Quantum Chestplate like a lappack. I can survive building a house out of nukes and detonating it; I think using it to power tools would hardly be crippling.
    Also, it would bring it in line with the other Quantum items, as it's the only one without a special function that drains power:
    Helmet trades power to get rid of eating, breathing, and poison.
    Chest plate has no special function.
    Leggings trade power for very fast movement.
    Boots trade power for massive jump height.

    That's a bit more advanced than I was thinking.
    I was thinking that the scaling ratio should be set in the config files and only able to change via reboot.


    Machines need to either be running on every MC tick or capable of processing multiple items per tick.
    EU can update once or twice a second with a negligible impact on player experience, but as things work now a stack of 64 items can be processed in as little as 3.2 seconds. If machines ran at a lower tick rate without being able to process multiple items per tick then that same stack would take 32 or 64 seconds to process.


    Personally? I favor the multiple items per tick solution, as that both removes the cap on overclocker returns and further reduces overhead.

    He wants an admin device that provides unlimited power to machines as fast as they can possibly use it so admins can have demo machines in spawn to show off the mod's features and how things work.

    Your Idea has a small problem: The Machines can only store a limited amount of EU, if you come with a 320EU-Package (every ten ticks) then it will not enter the machine and flows farther => Machine more Energystorage => Machine runs longer if full charged => inbalancement between Server and Client if the configs are not identical (but that can be fixed easyly).


    In the grand scheme of things, increasing machine buffer sizes is a very minor change that won't make much of a difference. In practice a system would need to have highly variable production which exceeds its storage capacity in order for a small buffer increase to have an impact. A system with a power deficit would see no change, nor would a system with a power surplus.


    Your Codeidea is good but it has a few MINOR problems, which makes it more complex than you think.


    1. Adding Code for enabling EU-Packets to Split (into the normal Values), that they can get into Machines


    You don't split the packets, you just have the machines accept the larger ones.


    2. Adding Code for the EU/tick change you suggested TO EVERY SINGLE ENERGYEMMITING BLOCK.


    ...which would be less than one line of change.
    Also, wasn't there already a power scaling factor coded in so admins could adjust power production rates?


    3. Adding Code for Cables that they can hold the configurated EU-Packets


    OR just multiply the the cable's packet size limit by the scaling factor.


    None of this needs to be visible to the player since it's all back-end changes anyway. Copper cable would still be labeled as 32EU/T since it would still be 32EU per minecraft tick; the player doesn't need to know if that's 32EU twenty times per second or 640EU once a second. :D

    It's actually really easy to do. You just have IC2 only process the network if the current MC tick is divisible by the scaling factor.
    Bam, instant tick rate


    In pseudocode:
    if(!(curTick%energyNetScaling))
    {
    energyNetUpdate();
    }


    More advanced code would have it update different networks on different MC ticks to smooth usage out, but this is just a quick and dirty example.

    I would like for EU transportation to have a configurable tick rate, such that it can be set to only update every N minecraft ticks. For example, a scaling factor of 10 would result in 1 EU tick every 10 minecraft ticks.
    To maintain similar machine utility, other factors would have to be scaled as well. An MFSU, for example, would output 5120EU packets every IC2 tick with a scaling factor of 10. Glass fiber cable would likewise have a capacity of 5120UT per IC2 tick.


    Machines would continue to work at normal speeds, although their internal buffers may have to be changed to match.

    Doing calculations for a lot of packets is very demanding on a server, and can one to its knees with ease.
    Until we get a more efficient EU system, I propose the introduction of a Network Segmenter.


    Here's how it would work:
    The segmenter only allows EU to pass in one direction.
    When placed on a wire, the segmenter determines which side is the "source" and which is the "sink" by looking for machines that take EU. The "source" side is whichever one has zero machines that consume EU.
    Once the "source" side has been determined, the Segmenter finds the shortest route to every machine on the "source" side and determines the per-packet loss for each. It then stores a list of all the machines and the loss from each.
    From then on the segmenter retrieves the power generated by each machine directly, deducts wire losses, and outputs the power it onto the "sink" network segment directly using the largest packet size the "sink" segment can tolerate. This skips all further network calculations for the "source" segment and minimizes the number of packets.
    If the "sink" segment is a directly connected device then the power is added directly without the use of packets.


    Such a machine would allow, for example, a field of 512 solar panels connected to an MFSU to involve zero packets, and thus a negligible server load.


    A hypothetical "version two" would involve the segmenter mimicking the power production aspect of all "source" machines and simply deactivating the originals.


    The segmenter would not function without a source network, nor would it function with a source network containing a nuclear reactor. In both cases it would block the transfer of EU between segments.