[Suggestion] Tick rate scaling options

  • 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.

  • 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.

  • Intressting i suggested something similar (but not the same) to reduce Lag from ULV-Generators just the the Solarpanel/Watermill/Windmill is waiting until 5EU are stored and outputs that in one 5EU-package (holdable by Tincables). 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).


    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
    2. Adding Code for the EU/tick change you suggested TO EVERY SINGLE ENERGYEMMITING BLOCK.
    3. Adding Code for Cables that they can hold the configurated EU-Packets


    My Idea for that was a bit less effective but costs only TWO LINES OF CODE (i would've written a Oneliner) added into the three ULV-Generators


    I think thats all. Finally a +1 for your Idea.

    I don't say, your "insert whatever" is bad. I'm only showing ways for making it better.
    GregTech Website
    Patreon really helps me out. If you consider funding the development of GT, so I might be able to do it fulltime, why not?
    GregTech 6, the Main Thread, Bug Reports go here too.
    I'm also on #gt-dev on irc.esper.net, if you don't want to make a Forum account just to contact me.
    (I'm there almost every day, when I'm at my own computer. Yes you can drop bugs and suggestions there too)

  • 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