Page 2 of 2 FirstFirst 1 2
Results 11 to 19 of 19

Thread: More friendly warnings, this time for duplicate names

  1. #11
    Developer Veracity's Avatar
    Join Date
    Mar 2006
    Location
    The Unseelie Court
    Posts
    11,011

    Default

    Revision 17520 does the same for effects:

    Code:
    > test effectids Got Milk
    
    Got Milk has 1 effectid: 211
    
    > test effectids A Little Bit Evil
    
    A Little Bit Evil has 6 effectids: 597, 598, 599, 600, 601, 602
    We now have the infrastructure to do the kind of thing this Feature needs.
    Ph'nglui mglw'nafh Cthulhu
    R'lyeh wgah-nagl fhtagn.

  2. #12
    Developer Veracity's Avatar
    Join Date
    Mar 2006
    Location
    The Unseelie Court
    Posts
    11,011

    Default

    So, I have a little experimental change. I made the "name" of any item or effect that has an ambiguous name be the [XXX]NAME form, where XXX is the id. That means that such objects will print in that form. You can also use to_string() on that name and it will work.

    Code:
    > ash $items[ seal tooth, 2325, [7961\]Staff of Ed, ancient amulet ]
    
    Changing "ancient amulet" to "[7963]ancient amulet" would get rid of this message ()
    Returned: aggregate boolean [item]
    seal tooth => true
    [2325]Staff of Ed => true
    [7961]Staff of Ed => true
    [7963]ancient amulet => true
    
    > ash $item[ staff of ed ].to_string()
    
    Changing "staff of ed" to "[7961]Staff of Ed" would get rid of this message ()
    Returned: [7961]Staff of Ed
    
    > > ash $item[ [7961]staff of ed ].to_string()
    
    Bad item value: "[7961" ()
    Returned: void
    
    > ash to_item( "[7961]Staff of Ed" )
    
    Returned: [7961]Staff of Ed
    plural => Staff of Eds
    ...
    1) Since to_string() of such an object gives you the [XXX] form, and to_item() of a string with [XXX] gives you the correct object, this automatically does the right thing for map_to_file and file_to map. At least, new ones; an existing file with an ambiguous item or effect will still give the item or effect with highest item number.
    2) In $item[], if you want to use [XXX]NAME, the "]" closes the constant. You can escape it with a \, but that's sort of inconvenient. We should either say:

    "Use [XXX\]NAME to make this message go away", or fix $item[] parsing to allow the nested [XXX] without an escape. I think I like the latter, but have not implemented. Comments are welcome.

    3) It would obviously be easy to give an alternate message when you have multiple matching items or effects, as zarqon suggested.
    Ph'nglui mglw'nafh Cthulhu
    R'lyeh wgah-nagl fhtagn.

  3. #13
    Senior Member zarqon's Avatar
    Join Date
    Nov 2007
    Location
    Seoul, Korea
    Posts
    3,395

    Default

    Thanks to this change, I was made aware that there are two Spookyraven library keys.

    The current message could be slightly misleading if the cause is a use of $item[], since using $item[[id]name] fails with an error.
    Sig by JakAtk
    My scripts: One-Click Wossname | Om******t (??) | Psychose-a-Matic | RandBot
    Combat suite: Best Between Battle | Mer********d (?!) | SmartStasis | BatMan | BatMan RE
    For script authors: ASH Wiki | ZLib | BatBrain | CLI Links | CanAdv | Script Registry | Map Manager | About Bats
    If you appreciate my work, help me become BAT KING OF THE WORLD! Thanks to all donators!

  4. #14
    Developer Veracity's Avatar
    Join Date
    Mar 2006
    Location
    The Unseelie Court
    Posts
    11,011

    Default

    Revision 17526 should allow you to use [XXX]YYY in a $item[] or $items[] (or $effect, etc.) without error. Ergo, you don't need to use a "" to quote the "[".
    Ph'nglui mglw'nafh Cthulhu
    R'lyeh wgah-nagl fhtagn.

  5. #15
    Developer Veracity's Avatar
    Join Date
    Mar 2006
    Location
    The Unseelie Court
    Posts
    11,011

    Default

    Code:
    > ash $item[ ancient amulet ].to_string()
    
    Multiple matches for "ancient amulet"; using "[7963]ancient amulet". () Clarify by using one of:
    $item[[2180]ancient amulet]
    $item[[7963]ancient amulet]
    Returned: [7963]ancient amulet
    
    > ash to_item( "ancient amulet" ).to_string()
    
    Multiple matches for "ancient amulet"; using "[7963]ancient amulet". () Clarify by using one of:
    "[2180]ancient amulet"
    "[7963]ancient amulet"
    Returned: [7963]ancient amulet
    
    > ash $effect[ A Little Bit Evil ].to_string()
    
    Multiple matches for "A Little Bit Evil"; using "[602]A Little Bit Evil". () Clarify by using one of:
    $effect[[597]A Little Bit Evil]
    $effect[[598]A Little Bit Evil]
    $effect[[599]A Little Bit Evil]
    $effect[[600]A Little Bit Evil]
    $effect[[601]A Little Bit Evil]
    $effect[[602]A Little Bit Evil]
    Returned: [602]A Little Bit Evil
    
    > ash to_effect( "A Little Bit Evil" ).to_string()
    
    Multiple matches for "A Little Bit Evil"; using "[602]A Little Bit Evil". () Clarify by using one of:
    "[597]A Little Bit Evil"
    "[598]A Little Bit Evil"
    "[599]A Little Bit Evil"
    "[600]A Little Bit Evil"
    "[601]A Little Bit Evil"
    "[602]A Little Bit Evil"
    Returned: [602]A Little Bit Evil
    That's in revision 17531.

    The $item[] and $effect[] warnings are issued at script parsing time. the to_item() and to_effect() warnings are issued at script execution time.

    I did not validate item & effect values read from files since when we write those objects to a file using map_to_file(), we always include the id in square brackets first - just in case KoL later introduces a duplicate name.
    Ph'nglui mglw'nafh Cthulhu
    R'lyeh wgah-nagl fhtagn.

  6. #16
    Senior Member zarqon's Avatar
    Join Date
    Nov 2007
    Location
    Seoul, Korea
    Posts
    3,395

    Default

    Beautiful! Thank you.

    I did not validate item & effect values read from files since when we write those objects to a file using map_to_file(), we always include the id in square brackets first - just in case KoL later introduces a duplicate name.
    Originally Posted by Veracity View Post
    Most of the data files I use are made by hand as a way to supply data to the script, not written by mafia as script output. They do not have the brackets.

    I suppose I can fix that by loading and resaving all my maps.
    Sig by JakAtk
    My scripts: One-Click Wossname | Om******t (??) | Psychose-a-Matic | RandBot
    Combat suite: Best Between Battle | Mer********d (?!) | SmartStasis | BatMan | BatMan RE
    For script authors: ASH Wiki | ZLib | BatBrain | CLI Links | CanAdv | Script Registry | Map Manager | About Bats
    If you appreciate my work, help me become BAT KING OF THE WORLD! Thanks to all donators!

  7. #17
    Developer Veracity's Avatar
    Join Date
    Mar 2006
    Location
    The Unseelie Court
    Posts
    11,011

    Default

    I suppose I could validate the data when loading. I did have an implementation of that, but when I looked at the generated data file, I saw that every item or effect had brackets, and decided, "why bother?" But, yes, I can see why a hand-generated data file would not have that.

    Let me consider that again.
    Ph'nglui mglw'nafh Cthulhu
    R'lyeh wgah-nagl fhtagn.

  8. #18
    Developer Veracity's Avatar
    Join Date
    Mar 2006
    Location
    The Unseelie Court
    Posts
    11,011

    Default

    OK. Given this test script:

    Code:
    boolean[item] imap2;
    
    file_to_map( "imap2.txt", imap2 );
    
    print( "" );
    print( "read item map" );
    foreach it in imap2 {
        print (it );
    }
    and this imap2.txt

    Code:
    seal tooth	true
    Staff of Ed	true
    2325	true
    I now get:

    Code:
    > test-constants3.ash
    
    Multiple matches for Staff of Ed; using [7961]Staff of Ed in (imap2.txt, line 2). Clarify by using one of:
    [2325]Staff of Ed
    [7961]Staff of Ed
    
    read item map
    seal tooth
    [2325]Staff of Ed
    [7961]Staff of Ed
    Note that the map is sorted by the "key" - the item, which is to say, by itemId - rather than being in the order of lines in the file.
    Note also that the file & line number in the warning are for the data file, not the script.

    Revision 17543
    Ph'nglui mglw'nafh Cthulhu
    R'lyeh wgah-nagl fhtagn.

  9. #19
    Senior Member Crowther's Avatar
    Join Date
    Nov 2006
    Posts
    1,344

    Default

    I really like this. I think it explains a problem I had with BBB in the library.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •