Conversion of pre-ZDB CommandSigns db file #69


  • New
Open
Assigned to _ForgeUser9042228
  • _ForgeUser254132 created this issue Oct 10, 2012

    Prior to zonedabone picking up CommandSigns, the plugin was not multi-world aware, and so when you created a sign it merely stored the sign's coordinates in the signs.dat file, such that if you had two signs at the same coordinates they would end up conflicting with one another.

    Well, I have an old multiworld server map with a lot of old commandsigns spread across its three seperate maps, but I find that when the ZDB versions of the plugin try to convert these signs and organize them by world, a large number wind up getting deleted.  My question then is:  How is old signs.dat conversion being handled, and is there a better way to implement it?

    What I envision is two possibilities:  If it is possible at runtime, when the plugin identifies an out-of-date signs.dat or a signs.dat which has worldless signs in it, it locate the coordinates given for that sign in all loaded worlds and compares what exists at those coordinates in each world to determine which one is most likely to be the sign; for instance, a sign at that coordinate in one world might be a dead giveaway, whereas air, or a block surrounded completely by other blocks (inaccessible) would not be candidates for where that sign is supposed to be.  Where the process can not determine which world to assign the sign to (multiple good matches or no good match), it could assign it to a bogus world indicating its unknown or conflicting status, which a server admin can then manually modify (it would be nice if the plugin would also report on startup that these unknown signs exist in its db to let admins know there's a problem).

    If that's not possible, there's another possibility, but it depends on how the plugin gets its information that a CS has been activated.  If the plugin is checking a coordinate every time a block is right-clicked or every time a sign is redstone powered, then what CS could do when it encounters an old signs.dat or finds signs in its current database that have no world affiliation is to assign them to a dummy world and check them whenever the listener reports that a coordinate has been right-clicked or redstone activated, and if it finds a sign at that location, to reassign the sign to its correct world.

    Just some suggestions, you may have a better idea.  Of course, there's always the manual solution where I pop open NP++ and begin a lot of Find/Replace actions. xD

  • _ForgeUser254132 added the tags New Enhancment Oct 10, 2012
  • _ForgeUser9042228 posted a comment Oct 11, 2012

    Try using a CommandSigns version pre 1.7.9 for conversion.

    In 1.7.9, there was a fix made to input/output to prevent reading issues due to signs that no longer exist. If a sign is not given a world now, it will declare it as invalid and ignore the sign. In previous versions of CommandSigns, this may still work.

    As of 1.8.0, we've now moved on to a new format to clean up the code. Adding functionality to read pre ZDB files will only clutter it up once again.

    See how it goes with 1.7.3. Otherwise, send me your files and I'll convert them with RegEx.

  • _ForgeUser9042228 unassigned issue from _ForgeUser7307234 Oct 11, 2012
  • _ForgeUser9042228 self-assigned this issue Oct 11, 2012
  • _ForgeUser254132 posted a comment Oct 11, 2012

    Okay, I will try out your suggestions and get back with you. I probably won't get a chance to try them out 'til after this weekend, but I'll follow up with you when I do. Thanks!


To post a comment, please login or register a new account.