Oh, very nice, I was trying to figure out how my make a text deed display the value of _gapBuffs instead of simply the text _gapBuffs. So .. silly time on the forums not matching my time, your above post happening a few minutes ago? so this r9659 should be on the daily builds page in about 30 minutes?
Daily Deeds support
- Thread starter roippi
- Start date
roippi
Developer
If you're hand-coding it, you just enclose the preference in pipes. If you're using the builder, you add the text you want to display before, then just the preference (no spaces), then any text afterwards.
It takes a while for changes on sourceforge to matriculate down to builds.kolmafia.us. If you were building from source, you could have it already
roippi
Developer
I'm going to have some free time this weekend so I'm thinking of doing some work on daily deeds. This post mostly to organize my projects:
-Hatter built-in deed, dynamically populated with available hatter buffs
-See if I can improve drag-and-drop scrolling
-Minor typo fixes
-Fix preview of preferences text deeds when users manually pass pipe characters
-Document everything, update wiki
Anyone have any bugs/requests/critiques while I'm at it? Are custom deeds usable? How are people using them? What do you wish you could do that you can't?
-Hatter built-in deed, dynamically populated with available hatter buffs
-See if I can improve drag-and-drop scrolling
-Minor typo fixes
-Fix preview of preferences text deeds when users manually pass pipe characters
-Document everything, update wiki
Anyone have any bugs/requests/critiques while I'm at it? Are custom deeds usable? How are people using them? What do you wish you could do that you can't?
I sleep better at night knowing you have done this. Thank you.
Many of my daily activities involve pulling an item from my DC and using it. This dates back to a time when just pulling the item would not trigger a refresh of the DD panel. If I knew what conditions triggered a refresh/rebuild of the panel then I would certainly drop or modify my existing procedures and use yours.
Items I am using include:
ball-in-a-cup
cheap toaster
Chester's bag of candy
Clan V.I.P. lounge key
handmade hobby horse
jingle bell
Oscus's neverending soda
set of jacks
The Legendary Beat
Many of my daily activities involve pulling an item from my DC and using it. This dates back to a time when just pulling the item would not trigger a refresh of the DD panel. If I knew what conditions triggered a refresh/rebuild of the panel then I would certainly drop or modify my existing procedures and use yours.
Items I am using include:
ball-in-a-cup
cheap toaster
Chester's bag of candy
Clan V.I.P. lounge key
handmade hobby horse
jingle bell
Oscus's neverending soda
set of jacks
The Legendary Beat
roippi
Developer
I'll try to answer real quick before I lose phone access for the next few days ( camping). The deeds panel itself is only rebuilt when the dailyDeedsOptions pref changes. Individual items are updated when the pref, item, and/ or skill that they are attached to changes.
For most of those it looks like an item deed will work for you.( as long as you "use" it) Dummy preferences, aliases, and some other kludges can be used to fine- tune behavior. Unfortunately out of time now but if you can provide one specific exams you're trying to implement we'll work on that.
For most of those it looks like an item deed will work for you.( as long as you "use" it) Dummy preferences, aliases, and some other kludges can be used to fine- tune behavior. Unfortunately out of time now but if you can provide one specific exams you're trying to implement we'll work on that.
roippi
Developer
No worries, I don't think you're alone in having that problem. I'll tell you how I do it (there are multiple ways, really), but first a little info so you understand what's going on. That way you (and anyone else with this problem) can apply the knowledge to other kinds of deeds.
Each deed is attached to a preference. This is the thing it checks to see if it should be enabled/disabled. In the case of built-in stuff that mafia tracks, these preferences already exist and properly increment when you do the appropriate action. However, for stuff that mafia doesn't track, you need to do this yourself. The easiest way I've found is just to have a little utility ash script:
called inc.ash in your /scripts folder. Now you can easily increment preferences by putting "; inc <whatever preference>" in the command section of your deed. But I'm getting ahead of myself. There are essentially 2 ways to implement your deed, and I'll go through both (using stabonic scroll as an example). I'll assume you're using the custom deed builder too. You can just hand-edit the dailyDeedsOptions preference, but that's a bit more advanced. I'll talk about that at the end.
Command deed:
The most basic deed. The button will always be shown, regardless of whether you have the item you're using.
displayText: stabonic scroll
preference: _stabby
command: use stabonic scroll; inc _stabby
That's it. Notice that the inc.ash script increments your _stabby preference in order to disable the button.
Combo deed:
This is the advanced one. There is no GUI for building this, but you can collapse all of the use-this-item-once-a-day buttons into one combobox. I've talked about the syntax for this on previous pages, but this is essentially how it would look for you:
$CUSTOM|Combo|Daily Items|false|$ITEM|stabonic scroll|_stabby|use stabonic scroll; inc _stabby|$ITEM|Hobby Horse|...
If you have a lot of daily items, this is a superior method than cluttering up the interface with buttons. You'll have to hand-edit the above into your dailyDeedsOptions preference once it's constructed.
Each deed is attached to a preference. This is the thing it checks to see if it should be enabled/disabled. In the case of built-in stuff that mafia tracks, these preferences already exist and properly increment when you do the appropriate action. However, for stuff that mafia doesn't track, you need to do this yourself. The easiest way I've found is just to have a little utility ash script:
Code:
/*
Increments a preference.
*/
script "inc.ash";
void main( string pref )
{
string value = get_property( pref );
int intValue = to_int( value );
set_property( pref, intValue + 1 );
}called inc.ash in your /scripts folder. Now you can easily increment preferences by putting "; inc <whatever preference>" in the command section of your deed. But I'm getting ahead of myself. There are essentially 2 ways to implement your deed, and I'll go through both (using stabonic scroll as an example). I'll assume you're using the custom deed builder too. You can just hand-edit the dailyDeedsOptions preference, but that's a bit more advanced. I'll talk about that at the end.
Command deed:
The most basic deed. The button will always be shown, regardless of whether you have the item you're using.
displayText: stabonic scroll
preference: _stabby
command: use stabonic scroll; inc _stabby
That's it. Notice that the inc.ash script increments your _stabby preference in order to disable the button.
Combo deed:
This is the advanced one. There is no GUI for building this, but you can collapse all of the use-this-item-once-a-day buttons into one combobox. I've talked about the syntax for this on previous pages, but this is essentially how it would look for you:
$CUSTOM|Combo|Daily Items|false|$ITEM|stabonic scroll|_stabby|use stabonic scroll; inc _stabby|$ITEM|Hobby Horse|...
If you have a lot of daily items, this is a superior method than cluttering up the interface with buttons. You'll have to hand-edit the above into your dailyDeedsOptions preference once it's constructed.
roippi
Developer
No problem. One thing I didn't really mention: feel free to change around the names of things; if you don't want to call the preference _stabby, call it whatever you'd like. However, make sure to start it with an underscore - preferences that start with an underscore are automatically reset by mafia on rollover. If you leave off that underscore, the button will remained grayed out forever!
roippi
Developer
I've gone over the wiki documentation and updated that significantly, so people should check that out if they're having issues/struggling to figure out what these "custom deed" thingies are.
-------------
Frono, I just went back and read your question now that I'm not reading it on a 2" display. Reading comprehension is working a bit better now. So basically you are pulling stuff from your DC, using it, and then putting it back. Hm. Well, there's a couple ways of doing it.
Item deeds cannot be used to pull things for you, nor for storing things. They won't even be displayed if you don't have the item in your inventory (they'll appear once you pull the item). So one clunky implementation might be to have a "pull all" command button, Item deeds for all the individual items, and then "DC all" button to put them away. Clunky, but only two buttons showing when you don't have things pulled.
A fancier implementation might be to make one combo deed. The combobox would always be enabled, and you would disable the individual elements as you used them. Each element would pull the item, use it, put it away, and finally increment a preference to disable that element. Something like:
$CUSTOM|Combo|Daily Items|false|$ITEM|stabonic scroll|_ballInACupDaily|display take ball-in-a-cup; use ball-in-a-cup; display put ball-in-a-cup; inc _ballInACupDaily|$ITEM|Cheap Toaster|...
(uses inc.ash that I just posted above)
I don't know exactly how you want it to behave; there's a couple of other methods that are somewhere in between these two.
-------------
Frono, I just went back and read your question now that I'm not reading it on a 2" display. Reading comprehension is working a bit better now. So basically you are pulling stuff from your DC, using it, and then putting it back. Hm. Well, there's a couple ways of doing it.
Item deeds cannot be used to pull things for you, nor for storing things. They won't even be displayed if you don't have the item in your inventory (they'll appear once you pull the item). So one clunky implementation might be to have a "pull all" command button, Item deeds for all the individual items, and then "DC all" button to put them away. Clunky, but only two buttons showing when you don't have things pulled.
A fancier implementation might be to make one combo deed. The combobox would always be enabled, and you would disable the individual elements as you used them. Each element would pull the item, use it, put it away, and finally increment a preference to disable that element. Something like:
$CUSTOM|Combo|Daily Items|false|$ITEM|stabonic scroll|_ballInACupDaily|display take ball-in-a-cup; use ball-in-a-cup; display put ball-in-a-cup; inc _ballInACupDaily|$ITEM|Cheap Toaster|...
(uses inc.ash that I just posted above)
I don't know exactly how you want it to behave; there's a couple of other methods that are somewhere in between these two.
Actually it seems my concern is addressed. If the VIP key is pulled as part of a login script, will the Daily Deeds and Breakfast options recognize that and update accordingly? You seem to be saying Yes above in which case I can move my functionality from a script to a Deed.
(What my script does is pull an item and then immediately use it. What I'd like and think I can get is to have the script pull an item and then have DD update to offer the option to use it, or have it reset the breakfast flag and be used there. The latter only applies to things like the toaster that are automagically done on on breakfast).
(What my script does is pull an item and then immediately use it. What I'd like and think I can get is to have the script pull an item and then have DD update to offer the option to use it, or have it reset the breakfast flag and be used there. The latter only applies to things like the toaster that are automagically done on on breakfast).
roippi
Developer
Ah. Yes, it should recognize that you get the VIP key; any built-in deed that looks for the VIP key calls PreferenceListenerRegistry.registerListener to make sure the deed's update() is called if the number of keys changes. If it doesn't update for whatever reason, that's a bug and should be addressed.
Now, the Breakfast button won't un-grey or anything just because you pulled the key. That button just checks if breakfastCompleted = true, which is set after running breakfast. Your script that pulls it could set that particular preference to false if you like. I think you understood this, just pointing it out for completeness' sake.
Beyond that, in general it seems you have two ways of making DD 'update.' One is by affecting the preference that a given deed is attached to. The other is by changing the quantity of an Item deed (noting that if you have zero of the item, the button will disappear).
Now, the Breakfast button won't un-grey or anything just because you pulled the key. That button just checks if breakfastCompleted = true, which is set after running breakfast. Your script that pulls it could set that particular preference to false if you like. I think you understood this, just pointing it out for completeness' sake.
Beyond that, in general it seems you have two ways of making DD 'update.' One is by affecting the preference that a given deed is attached to. The other is by changing the quantity of an Item deed (noting that if you have zero of the item, the button will disappear).
OK. I will check this out in a bit. I only run one character at a time and with SmartStasis and the Island War I'm going on two wall clock hours to burn 200 turns...
I was hoping that "something" would recompute breakfastCompleted but setting it to false and forcing a recompute is an acceptable solution.
Thanks.
I was hoping that "something" would recompute breakfastCompleted but setting it to false and forcing a recompute is an acceptable solution.
Thanks.
Breakfast runs before my Login script. The script moves things from my DC so that they can be used, for example the cheap toaster. (The idea here is to have the maximum number of unique items in my DC when Jicken Wings updates their DC stats. So, unless I have more than one, I want things in my DC whenever they are not being used which pretty much means whenever the character is not logged in). So by resetting the Breakfast flag the toaster will get used whenever Breakfast is re-invoked. Re-running the command after the inventory has changed will not, as far as I know, use the newly added items, because it thinks it is done whereas resetting the preference will force their use the next time Breakfast is called.
Regardless of whether there is an alternative, resetting the pref at the end of the login script made DD do exactly what I wanted so I am happy.
What constitutes a "full execution of breakfast" varies as items get added to the inventory. The gCLI command Breakfast might possibly check what the current definition is and ignore the preference but since I would much rather have the button than have to switch to the gCLI and remember what to type ;-) resetting the preference is actually a better solution for me.
Got it. I understand your suggestion now. Instead of setting the preference in the script so I can manually press the DD button you are suggesting that I just use the cli command breakfast which bypasses the preference and saves me a button push.
I am chagrined to say that unchecking the Breakfast option on login eliminated my problems as well since I could just trigger Breakfast once after things had been moved from the DC. I will note that calling breakfast twice resulted in one worthless item in inventory. As near as I could figure the code in HermitRequest does not distinguish between "character has visited hermit and retrieved all available clovers" and "we need to visit hermit because we don't know how many clovers are available".