Bukkit CoreProtect 2.17.4

Fast, efficient block logging, rollbacks, and restores

  1. Hello thanks for your fast reply , we have
    http://puu.sh/jseND/fe46fffbb6.png
    DB content for this event :

    select * from co_block order by time desc;

    returns

    http://forum.rlmines.fr/misc/exportco.html

    Please note that the log of the creeper explosion (created on purpose) and rollback happened within the same minute. (same version of coreprotect) and of course instead of the enchant tables we had some grass
     
    #41 fastlockel, Aug 7, 2015
    Last edited: Aug 7, 2015
  2. Intelli

    Supporter

    There's no data regarding a block being placed?

    Were you using CoreProtect prior to the v2.11.0 update?
     
  3. Cldfire

    Cldfire Retired Moderator
    Retired

    Ah yes, coreprotect. Sir, it's good to see you and your excellent plugin here! :)
     
  4. DB log is above and YES I use coreprotect for several years, updated recentrly to July 2nd version

    NO block was placed we spawned the creeper on purpose 30 seconds before rollback, you could even try it if you want since the server is public
     
  5. Intelli

    Supporter

    Can you provide a screenshot of the "/co version" command, as well as the contents of the "co_material_map" database table?

    I'm guessing your database somehow became corrupted during the upgrade from v2.10 to 2.11.
     
  6. Intelli

    Supporter

    Hmm, it's odd, as I see a mixture of dirt/grass/enchantment tables being logged.

    You could try switching to a new DB and see if that resolves the issue.
     
  7. Ok I'll try this and tell you. Thanks for your (very re-)active support and can not count how many times your plugin saved people
    after a grief or massive destruction.
    Tell you tomorrow if it's fine (I have to go)
    Thanks
    Nicolas
     
  8. Ok finally : after
    - drop tables
    - restart server
    The bug of the enchant tables has disappeared

    It seems that the issue was due to the table of materials wich was not correctly set. Perhaps I switched from 2.10 to 2.12 skipping 2.11 or whatever.

    Dropping tables and regenerate seems to fix it.
    Thanks !
    Nicolas
     
  9. Intelli

    Supporter

    Glad to hear you got it fixed! Odd issue though. Skipping versions shouldn't matter, as it has a built in patcher which will patch for any missed versions.

    Did you at any point downgrade versions? For example, 2.10 -> 2.12 -> 2.10 -> 2.12.
     
  10. Nope, the only other possibility I see is that I am Using Bungeecord. Perhaps for a short while while updating my bungeecord servers one was not using the same version as others (I usually test the update on one server instance then if ok, update all others.
     
  11. if its possible can you do it if a player was in the area or mob and which kinda mob/player or if a block were in a regioned area
     
  12. Coreprotect 3 hype!!!
     
  13. Hello one of myadmins returns again a confusion in rollback I check the co_material_map and I have multiple entries with the same id column where rowid is fine (thi is the primary key):
    select * from co_material_map WHERE id = 6
    returns
    rowid id material
    6 6 minecraft:fire
    125 6 minecraft:bedrock
    245 6 minecraft:air

    I have a bungeecord server but it should not add several materials with the same id
    Until rowid <= 123 I have rowId = id
    rowid id material
    1 1 minecraft:long_grass
    2 2 minecraft:grass
    3 3 minecraft:dirt
    4 4 minecraft:red_rose
    5 5 minecraft:air
    6 6 minecraft:fire
    7 7 minecraft:trapped_chest
    8 8 minecraft:fence_gate
    9 9 minecraft:chest
    10 10 minecraft:sapling
    11 11 minecraft:lapis_block

    then it changes

    rowid id material
    123 123 minecraft:gold_boots
    124 5 minecraft:air
    125 6 minecraft:bedrock
    126 7 minecraft:stone
    127 8 minecraft:coal_ore
    128 9 minecraft:iron_ore
    129 10 minecraft:log

    ****
    Maybe therer is a cache and several bungee servers add their own 'id' for materials , because of cache the use a new id , but the id is already used by another bungee server ?

    Why not using the rowid which is an autoincrement, and is sure to be unique ? Using the PK (autoincrement) in the co_block reference to material would be safe, and more efficient (pk is faster for join) but if you generate and 'id' in the plugin itself you are not sure to be unique when the cache is not synch. rowid is save sice db generated and pk (can not have duplicates whaterver happens)
     
    #54 fastlockel, Aug 18, 2015
    Last edited: Aug 18, 2015
  14. Intelli

    Supporter

    CoreProtect doesn't currently support sharing the same database between multiple servers. You should either be using a separate database, or a unique table prefix, for each server that you run CoreProtect on.

    I've gone ahead and created a ticket regarding this, so that support for shared MySQL databases should be added in a future release: http://dev.bukkit.org/bukkit-plugin...port-for-sharing-db-between-multiple-servers/

    That would require database queries in the main server thread, which is no-go for performance reasons. Internal IDs are currently dynamically managed in memory, for optimal performance.
     
  15. Ok Understand, however it was working fine until version 2.10 , perhaps some optimisation caused the isssue.
    I'll create one prefix per bungee server thought it was cconvenient to have it all in the same since I was using your
    tabmes to detect XRayers, I 'll haveto make a check for every prefix which is still ok of course
     
  16. Intelli

    Supporter

    Ah, yeah, it'd be the change from block IDs to block names that broke it then.
     
  17. Can chests with items destroyed by fire, tnt, and lava be rolledback and still have the items in them with this plugin? I'm using Prism right now but if a chest is destroyed with those three things and then rolledback all the items are still missing.
     
  18. Intelli

    Supporter

    If a chest is broken, it logs the items as being removed from the chest. So if you rolled back that chest, yes, the items would be brought back.
     
  19. Updated to 2.12 from 2.10 a short while back.

    I must say, the change of having to use b:<name> instead of b:<id> is very irritating, and inefficient.
    Often I don't know the exact name CoreProtect wants me to use for certain blocks, and with the requirement of using block names I often run out of room in the minecraft chat window to run my full command.

    Really considering downgrading back to 2.10 and staying there.
     

Share This Page