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

Thread: Veracity's Property Management Library - vprops.ash

  1. #11
    Minion Bale's Avatar
    Join Date
    Jun 2008
    Posts
    13,287

    Default

    I really love this, but I want to make a request of all scripters who use this library to store their preferences in mafia's pref files.

    Always make sure that the properties you create BEGIN with information to identify the script which created them. This will help a lot once a lot of script have made use use of Veracity's new concept in script configuration. I know I will be using it.

  2. #12

    Default

    One of the things zlib includes that I find immensely useful, and is a big reason why I use its vars, is the WOSSMAN relay script for easy management. I've mangled Zarqon's script to make a version that manages preferences instead. To do this I had to also make a library script (I called it "vprops2") that keeps track of property types and stores them in a data file, "PropertyTypes.txt". The first time it's run it gets a list of all properties and attempts to guess their types, but they can be changed as needed in the relay script.

    I put vprops2 up here, and the prefs relay is here. Again, that relay is clearly just a mod of WOSSMAN, so all credit to Zarqon. If you find vprops2 usefull feel free to incorporate however much of it you want into vprops or whatever else you want.

    At the top of the PREFS relay is the option "PREFS_showbuiltin". If you turn this on and then refresh, the relay will no longer display custom props, but will show all builtin ones instead.

    One thing I've realized is that the builtin properties kind of come in two varieties with no obvious way to differentiate - they're either managed & updated by Mafia (things like quest status values, numbers of times various things have been used/dropped, etc), or they can be preferences the user might want to change, like the various scripts you might have assigned or other preferences.

    I wanted to first make sure there isn't a way to tell them apart already, and if there isn't, what you think the best way might be? I don't think there's any getting around the fact that it'd require going through all the builtin properties and labeling them as one or the other. I could conceivably just curate all the readonly properties and dump the set to another data file, or add a property in PropertyTypes... hmm.

    edit: Derp, there's of course also the fact that any non-builtin properties that aren't changed from default couldn't be found this way. There'd have to be a separate list of those somewhere.
    Last edited by Smelltastic; 03-21-2017 at 01:38 AM.

  3. #13

    Default

    Okay, here's what I've done:

    vprops2 imports vprops, but doesn't automatically load the types map. It includes define_property2, which first takes the scriptname as the first argument, then the rest of the values same as define_property. If you use define_property2 to define your property, it stores the type data in PropertyTypes.txt and remembers that property name in another property named PREFS_known_<scriptname>. It only bothers to load the types map in the future if it doesn't see the property in that list. This, I think, preserves the intent of vprops while also allowing a settings script to see what settings are available and what their types should be. One additional benefit of this is a normalize_property function that doesn't require the type, since the map already has it.

    The first time vprops2 is run, it runs through the user properties list and attempts to guess at both their datatypes and 'readonly' status based on the data and property name. These can then be changed individually in the PREFS interface.

    I think I've gone about as far as I can go with it, I hope other people find it as necessary as I do.

    vprops2: https://sourceforge.net/p/kolm-prefs...ts/vprops2.ash
    relay_PREFS: https://sourceforge.net/p/kolm-prefs...elay_PREFS.ash
    Last edited by Smelltastic; 03-21-2017 at 04:34 AM.

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

    Default

    OK, I need to look closely at what you've done here. When I saw your post, I was on my way out the door, so I deferred comment until later - and it dropped off my "new posts". You've done a lot of work and deserve a response. Which I will give you. Soonish.

    I came to report that I submitted a bug fix. Turns out that using split_string() to separate a property into elements for a set or a list has a flaw: that function ALWAYS gives at least one string: if there is no delimiter, you get back the original string. Which is fine - except when the original string is "", where this library wants/expects/needs to end up with an empty set or list.

    Revision 29 makes that so: to_list_of_xxx( "" ) will now give you a list with 0 elements in it. Ditto for sets.

    (And it is revision 29 not because I have been busy as a bee changing this library. All three of my scripts on sourceforge are in subdirectories of the same repository, so a change to any will bump the latest version for all. I've been busy as a bee with my other scripts.)
    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,417

    Default

    (Still need to comment on vprops2, etc. I will say that when I was first thinking about this, I was expecting that define_property() woud store info in a local database - sort of like what vlib does - but only the meta-information about the property; you'd still edit the property via "set" in the gCLI. I decided that was unnecessary for what _I_ needed, so I didn't go there. For, you, however, it is "essential", so you went there. Pondering.)

    I have a standard header that I include in my (four, currently) scripts that use this to try and make it clear what the script user can do: edit the file, or, (preferred), simply "set" the properties. It's become clear that my "simple and obvious" instructions are neither. Here is what I say. Suggestions for improved script boilerplate is welcome.

    Code:
    //-------------------------------------------------------------------------
    // All of the configuration variables have default values, which apply
    // to any character who does not override the variable using the
    // appropriate property.
    //
    // You can edit the default here in the script and it will apply to all
    // characters which do not override it.
    //
    // define_property( PROPERTY, TYPE, DEFAULT )
    // define_property( PROPERTY, TYPE, DEFAULT, COLLECTION )
    // define_property( PROPERTY, TYPE, DEFAULT, COLLECTION, DELIMITER )
    //
    // Otherwise, you can change the value for specific characters in the gCLI:
    //
    //     set PROPERTY=VALUE
    //
    // Both DEFAULT and a property VALUE will be normalized
    //
    // All properties used directly by this script start with "VGC."
    //-------------------------------------------------------------------------
    Obviously, that last line is not "boilerplate", but is specific to the particular script that includes the rest of the comment.
    Ph'nglui mglw'nafh Cthulhu
    R'lyeh wgah-nagl fhtagn.

  6. #16
    Developer fronobulax's Avatar
    Join Date
    Feb 2009
    Location
    Central Virginia, USA
    Posts
    4,150

    Default

    For some reason it seems counter-intuitive to me to open up a script in a text viewer/editor to view the properties that are available to me and then go somewhere else (command line, property setting script) to choose/specify my changes/preferences for that property. There is no reason for that other than personal preference, but the relay script to view and set the parameters for bccascend remains my preferred way to view and set those parameters. Similarly there is a very old script that displays zlib parameters and allows them to be edited. That provides no documentation but it does allow the values to be set.

    So as a user I'd love a relay script because then I can see what all the properties are, (potentially) set them to valid values without worrying about typos or exact spelling and have some kind of documentation. I can even imagine a script with a validate button on it so I could validate input/changes when I was in a place that supported fixing errors. A Restore defaults button would also be useful.

    As someone who sees everything as a potential problem to be fixed and tends to seize the first solution, I can imagine code that reads a file and dynamically builds such a relay script. The data file can be a dependency for scripts that use SVN. I'd consider making the relay builder a Kolmafia function and figure out a means whereby the user could trigger a build/rebuild.

    Reworking my scripts to use the new property scheme is on my TODO list and if by converting, I get a relay script setter for free I am even more inspired to convert. That said, my KoLmafia TODO list never seems to get the attention it deserves. I want to blame my position as the volunteer IT department for a small non-profit that was compromised and needs computers cleaned up and secured but I am sure Fallout 4 gets some of the blame ;-)
    You just vehemently agreed with me
    Originally Posted by Veracity View Post
    I agree with frono.
    Originally Posted by Veracity View Post

Posting Permissions

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