Zugg Software :: View topic - [2.06] Can't duplicate a setting within the same class

Wizard Joined: 14 Aug 2004 Posts: 1269

Maybe not a bug, but it would be nice to be able to duplicate settings within the same class. Obviously one would need to rename the duplicate before they get saved properly, since otherwise there would be a duplicate key violation in the database (which is why paste presumably doesn't work - it is trying to save the copy immediately). So maybe the duplicate key violation exception should be trapped and if it happens the setting is there but flagged as not saved (and therefore deleted if you click on another setting or press Cancel changes). One would need to rename it before saving the new setting.

Posted: Sun Oct 14, 2007 6:08 pm

Definitely a good idea. For now, you can copy the script and create a new setting, but it'd be nice to not have to worry about all the other options, especially for triggers and buttons, which can get pretty complex pretty quickly.

Posted: Sun Oct 14, 2007 6:50 pm

You can also already do this if you go to the XML tab and copy the XML text directly. Just change the ID field to be ID="-1" before you copy it, and then when you paste it will always create a new setting instead of overwriting the setting with the same name. Remember that Copy/Paste uses the XML code, and when pasting it looks for a setting with the same name to overwrite if it exists.

Hmm...although yes, there might be a problem with the key duplication. While the database itself is fine (the ID field is the key, not the name), the internal cache uses a hash table for looking up stuff and the hash is formed by the combination of the name and the class number. So having the same name in the same class might screw up the internal cache lookup.

Wizard Joined: 14 Aug 2004 Posts: 1269

I checked and at the moment if must actually be overwriting the setting when you paste into the class where the setting already is (as if you copy a setting, make some changes to the original and press paste, you lose the changes you made). My workaround up until now has been to copy the setting to another class, make my changes and move it back...

Posted: Mon Oct 15, 2007 11:04 pm

Yes, that is true. That's exactly what the copy/paste does. It looks for settings in the folder with the same name as what is being pasted and overwrites them. I know this is different than the normal copy/paste people are used to (where paste creates a new copy), but it's the same as the way it worked in zMUD, and it prevents duplicate settings with the same name from causing problems with the hash table cache that I was talking about.

What I'll probably do is add a separate command called something like "Paste Copy" that will create all new settings and will auto-rename them by appending an increasing number to the end of the name. That's about all I can do. I can't really prompt the user to rename it at the point in the background that this is being done...it would essentially cause multiple rename windows to appear if you pasted several settings (one for each setting) and they would be all on top of each other. There isn't any way to prompt and wait for the user input sequentially the way the Windows message stuff works with this.

Not sure when I'll do the autorename and paste-copy, but it's on the wish list.

Posted: Mon Oct 15, 2007 11:15 pm

I'd prefer an incrementing number to rename windows, but I also don't think having multiple rename windows open beneath one another is a bad thing.

Posted: Mon Oct 15, 2007 11:31 pm

Except when you remember the bugs in Windows regarding stay-on-top windows which means that if you accidentally clicked on the main settings window, then all of the "rename" windows might end up hidden behind. And I can just imagine all of the trouble and confusion that this could cause.

Wizard Joined: 14 Aug 2004 Posts: 1269

Er, in zMUD, it doesn't overwrite. It creates an identical copy with the same pattern or name. Not sure it works behind the scenes... I always just rename the new copy straight away.

Posted: Tue Oct 16, 2007 7:45 pm

Sorry, I was think about import rather than paste. Yeah, in CMUD it doesn't actually save it yet...when it tries to save it, then you get the prompt about renaming it or deleting it. And if somehow it saves two values with the same name, then you end up with one of the famous settings corruption problems in zMUD. zMUD uses the same name+class hash table internally as CMUD, but zMUD doesn't have the database to back it up. So once the hash table in zMUD gets messed up because of two settings with the same name/class, then this bad hash table gets saved to your *.MUD file and will continue to cause problems when loaded the next time.

Wizard Joined: 14 Aug 2004 Posts: 1269

Ooh, I didn't know I had been playing with fire all these years!