Spigot NoClocks 1.21

Drag-n-drop solution to CPU-hungry redstone mechanisms.

  1. Htgan submitted a new resource:

    NoClocks - Kills Resource Hungry Redstoning

    Read more about this resource...
     
  2. Could there be a permission to use the clay bypass? (Or permission to bypass it regardless of what block is underneath the redstone)

    As I wouldn't mind so much if the player is active, it would be nice to grant players with X amount of days played on the server permission to use redstone clocks
     
  3. I will try and come up with an efficient way to make it permission based.
     
    • Like Like x 1
  4. Will this break TNT Cannons?
     
  5. This will break TNT cannons if the cannons have rapid fire or fast pulsating redstone in it.
    I have added option to turn down the frequency threshold to accommodate slightly faster redstone mechanisms but it will reduce the overall effectiveness of the plugin.
     
  6. Htgan updated NoClocks with a new update entry:

    Added Permissions Support and More.

    Read the rest of this update entry...
     
    • Like Like x 1
  7. Nice plugin, I liked the end of your video #RANDOM :p
     
    • Like Like x 1
  8. Doesn't seem to work well with the clocks that use comparators.
    I'm also getting spammed with "Not using perms." in the chat every time I place redstone.
    This setup doesn't work even with the threshold lowered to 250 and all the repeaters on 4 ticks:
    [​IMG]
     
  9. Apologies, the "not using perms" was a debug message that I've overlooked.
    Threshold set to 250, which is the least strict, will be almost equal to not even having the plugin there at all.
    The lower the number, the least strict, the more the server will allow faster redstone.
    What you want is to go somewhere around 2000, which is pretty tough on fast clocks. I wouldn't go anything higher than 3000, or anything lower than 1000, to be honest.
    I will immediately push an update that removes the debug message.

    If by any chance I've misunderstood you and that you want to actually not have the plugin block the clock you are showing me in the picture, then there is completely no reason for you to use this plugin. If you want to allow clock speeds as fast as only having 2 diodes, then you are basically allowing anyone to make any fast clock at any speed they want.

    Edit:
    I just realized that maybe you did not watch the video on the plugin.
    This plugin is intended to STOP what you're showing in the picture. So if your current issue is that the redstone clock you've shown in the picture is failing to work, then the purpose of this plugin has been fullfilled.
    There is a bypass that will ALLOW something as fast as shown in the picture. Using a block of red-stained clay under any redstone wire/diode will enable the clock speed bypass.

    Apologies, I am just a bit confused after you said "doesn't work", I'm not sure if you're referring to the clock in the picture or my plugin. If your clock works, then my plugin doesn't work, if your clock doesn't work, then my plugin works, you know what I'm trying to say?
     
    #9 Htgan, May 5, 2015
    Last edited: May 5, 2015
  10. Htgan updated NoClocks with a new update entry:

    Removed debug messaging.

    Read the rest of this update entry...
     
  11. Sorry for the confusion. I meant that clock was being blocked by the plugin, but was running at 4 ticks per repeater. I'm mostly just concerned with stopping 1-3 tick and burnout clocks but would like to allow 4+ tick clocks to function.

    The plugin also didn't block the 1-tick comparator clocks.
     
  12. I understand what you're saying now, you want to be able to distinguish between a comparator clock that has a 1 tick speed and a repeater clock with 8 ticks.
    Testing on my local server, a threshold of 300 does not stop an 8-tick clock, but the accuracy of the plugin depends greatly on the TPS health of your server. In an ideal 20TPS environment, a threshold of 300 is enough to stop comparator clocks but still let live an 8-tick clock. This is because the plugin tracks time in real time, meaning it uses the millisecond time on the machine to determine how much time has passed. However, the spigot server itself does not track time in real time, it is based on the TPS, if the TPS drops, server time will run slower than what is expected by the plugin, creating a margin for error in the calculation of how fast the redstone clocks are really going. It'll make the plugin think that the clocks are going faster than they really are.

    What I will do is:
    1. Implement a way to keep comparators in line. (This involves tricky methods because currently bukkit does not trigger an event when comparators are powered by redstone signals, which it should do)
    2. Loosen the hard restriction set inside the plugin to allow threshold of under 250, all the way down to 50. (I still don't recommend going anywhere below 200)
    3. Throw in a bit more features

    You can also private message me about your server's performance, and I can help you improve it a bit, and it will improve the accuracy of NoClocks.
     
  13. Thanks for the info; I figured it was something like that.
    For a while I've been using a plugin that detects redstone clocks over a specified amount of time. It's source may be useful in this case:
    https://github.com/hwei/RedstoneClockDetector

    My server's pretty stable around 19.8+ TPS but dealing with fast clocks manually using the above plugin to find them can be a bit of a pain, hence my search for a plugin that can handle it automatically. =)
     
  14. Htgan updated NoClocks with a new update entry:

    Discipline Comparators, Added Sound/Effects.

    Read the rest of this update entry...
     
  15. I have tried that plugin, before I decided to code my own. The plugin was well coded, but it over complicates the entire process, and involves many unnecessary features. I needed something that was straight to the point treating the issue from the very first step.
    In the latest update I've pushed out a minute ago, I've added a kind of hacky method to deal with the comparators, it often makes them appear facing the other way when server kills the signals, but they are in fact facing exactly the same way as before, a simple right click on the comparator or toggling the redstone signal source can remedy this. They have no side effects if ignored.

    Hopefully this update makes the plugin more suited to your needs! :D
     
  16. I was able to tune it perfectly =)
    I came across one bug, though. If you create a redstone "grid" in front of a comparator clock, the plugin fails to prevent it. I have the sound effects enabled and the plugin tries to disable the clock, but spams the particles and sound effects instead. Here's a pic:
    [​IMG]
     
  17. Yea I'm getting that too, it's a huge headache. The thing is that they still haven't added support for comparators in the redstone event listener, even though this block's been around for years. I haven't been coding for long, so I'm not skilled enough with plugins to find a way to detect when a comparator is powered by a redstone signal.
    I will seek help from other developers and hopefully have this issue resolved quickly.
     
  18. Could try a BlockPhysicsEvent:

    Code (Text):
        public void onComparatorChange(BlockPhysicsEvent event){
            if (event.isCancelled()) return;
            if (event.getBlock().getType() == Material.REDSTONE_COMPARATOR_OFF || event.getBlock().getType() == Material.REDSTONE_COMPARATOR_ON || event.getBlock().getType() == Material.REDSTONE_COMPARATOR){
                if (event.getChangedType() == Material.REDSTONE_WIRE){
                    if (event.getBlock().isBlockPowered()) System.out.print("Comparator is on");
                    else System.out.print("Comparator is off");
                }
            }
        }
     
  19. Htgan updated NoClocks with a new update entry:

    Should completely fix issue with Comparators!

    Read the rest of this update entry...
     
    • Like Like x 1