Daily Deeds support

if i am creating a multipref with a 10 turn counter, not having it increment is pointless. unless the expectation is that multipref will always call an ash script or something, in which case it renders people who aren't developers without that option, really. to be honest, what i would REALLY like to see happen with a custom deed like that is be able to make it hidden if prerequisites aren't met (ie: if i'm not a sauceror or the nemesis quest isnt completed yet) but i'm guessing that's a LOT more work. In the meantime it would be nice if user created preferences would reset daily somehow, or at the least increment when the button is clicked (and the button would grey out when the max turns were reached).

just my .02 and if it's not doable I am sure to find other uses for custom deeds, so please don't take it as criticism.
 
maximillian the red said:
if i am creating a multipref with a 10 turn counter, not having it increment is pointless. unless the expectation is that multipref will always call an ash script or something, in which case it renders people who aren't developers without that option, really.
Click to expand...

You don't need to be a developer to use aliases and ASH. For the less technically-minded, this thread exists.

It is not "pointless," you are just not using it correctly. First, define an alias:
Code: 
alias inc => ashq string d=$string[%%];int oldVal=get_property(d).to_int();if(d != "" && get_property(d) != "")set_property(d,oldVal+1);

then just add ";inc <whatever preference you want>" to the end of the command portion of your deed.

to be honest, what i would REALLY like to see happen with a custom deed like that is be able to make it hidden if prerequisites aren't met (ie: if i'm not a sauceror or the nemesis quest isnt completed yet) but i'm guessing that's a LOT more work.
Click to expand...

This behavior exists in skill deeds and item deeds (not visible if you don't have the matching skill/item, respectively). It's just not feasible to do this for everything.

In the meantime it would be nice if user created preferences would reset daily somehow
Click to expand...

I'm looking for a good solution to this. Regular preferences don't reset, and preferences that start with an underscore reset to a blank string (breaking the custom deed entirely when you load it up on a new day). Neither is desirable behavior for our purposes here. Suggestions welcome. I handle resetting mine in a login script right now, but I'd prefer it if that were not the Official Solution.

just my .02 and if it's not doable I am sure to find other uses for custom deeds, so please don't take it as criticism.
Click to expand...

It's cool. Feedback is always welcome.
 
Unfortunately no, because "" is what get_property (and its internal equivalent) return for both preferences that aren't set (i.e. _aoisaowieuf), and preferences that are set but have no value (i.e. what _temp is reset to after rollover if I set it to 0 today). I'd have to remove all checking to make sure that you've input a valid preference.

Moreover, skill deeds are overloaded to do two different things when fed boolean and integer preferences, so we need to know which kind of preference it is when building it.
 
roippi said:
First, define an alias:
Code: 
alias inc => ashq string d=$string[%%];int oldVal=get_property(d).to_int();if(d != "" && get_property(d) != "")set_property(d,oldVal+1);

then just add ";inc <whatever preference you want>" to the end of the command portion of your deed.
Click to expand...

ok so i defined the alias, thanks for the code. as i understand the next part though i'm supposed to add it to the end of the command portion.
so my custom definition now looks like this:

$CUSTOM|MultiPref|Get Slime|_gotSlime|volcano slime;inc _gotSlime|10

however when i click the button it fails. below is the gCLI output.

gCLI said:
> volcano slime;inc _gotSlime

Unable to invoke inc

> alias inc

inc => ashq string d=$string[%%];int oldVal=get_property(d).to_int();if(d != "" && get_property(d) != "")set_property(d,oldVal+1);
Click to expand...

any advice on what i did wrong?
 
You can circumvent it by using CLI to execute an ASH function that executes a CLI command. Right.
Code: 
$CUSTOM|MultiPref|Get Slime|_gotSlime|volcano slime;ashq cli_execute("inc _gotSlime")|10
 
If you are going to invoke ASH, why not just use get_property() and set_property(). Forget aliases.
 
To remind you, those underscore preferences are going to reset to a blank string after rollover, breaking the custom deed.

On the upside, I just coded up the API for custom combo deeds. It was surprisingly painless. I'll commit it after a bit more testing. The GUI for it may take quite a while, though.
 
As a heads up, I will be making some significant changes to the custom deeds API sometime in the next couple of days. This will break the majority of current custom deeds, although fixing them will be rather trivial (just requiring a simple name change). Of note:

  • BooleanPref and MultiPref are gone, replaced with just "Command". The 2- and 3- argument versions behave like current BooleanPref deeds, and the 4-argument version behaves like MultiPref. Likewise, BooleanItem is just renamed to Item.
  • Internally, booleans are now coerced into integers. False is now equivalent to 0, and true to 1.
  • Preferences that are blank strings are now equivalent to 0 (which is equivalent to false, as above). This means that you can set _preferences and they will properly reset to 0 after rollover without you having to do anything.

I think that this should address a large usability problem that exists currently.
 
r9656 reworks custom deeds. Now there are "Command", "Item", and "Skill" types, with equivalent acceptable forms:

<type>|displayText|pref
<type>|displayText|pref|command
<type>|displayText|pref|command|maxUses

..where "command" is item or skill for those respective deed types.

Also, preferences now all coerce to integers. Practically, this means that when you define a _preference and it resets on rollover, the deed will work as intended with the preference resetting to 0. This should address a major usability problem, which is that preferences were difficult to reset upon rollover. Also, there is no need to keep track of "boolean" and "integer" type deeds: you can just think of all deeds as having a default maxUses of 1 unless you specify otherwise.

Also Also: added a somewhat experimental "Combo" deed. Try it out, it lets you make your own comboboxes, and disable individual elements (or the whole thing). Proper syntax is:

$CUSTOM|Combo|displayText|preference|$ITEM|displayText1|preference1|command1|$ITEM|displayText2|preference2|command2...

where the first displayText is the first display-only line in the combobox, and the first preference is the one that enables/disables the whole combobox.

Also Also Also: I updated the custom deeds builder GUI to handle the new behavior (no, not comboboxes). It should hopefully be bug-free, but let me know if otherwise.

Also^4: the "demo" posted in the OP will be broken until I update it. That will not happen tonight.
 
Code: 
dailyDeedsOptions=

[COLOR=#00ff00]$CUSTOM|Command|GAP free spells|_gapBuffs|equip greatampant; gap skill|5,
$CUSTOM|Command|GAP elem & tough|_gapBuffs|equip greatampant; gap structure|5,
$CUSTOM|Command|GAP +25%ItemD|_gapBuffs|equip greatampant; gap vision|5,
$CUSTOM|Command|GAP +100%Mox|_gapBuffs|equip greatampant; gap speed|5,
$CUSTOM|Command|GAP 5xCrit|_gapBuffs|equip greatampant; gap accuracy|5,[/COLOR]

[COLOR=#ff0000]$CUSTOM|Combo|GAPants|_gapBuffs
|$ITEM|free spells|_gapBuffs|equip greatampant; gap skill|5
|$ITEM|elem & tough|_gapBuffs|equip greatampant; gap structure|5
|$ITEM|+25%ItemD|_gapBuffs|equip greatampant; gap vision|5
|$ITEM|+100%Mox|_gapBuffs|equip greatampant; gap speed|5
|$ITEM|5xCrit|_gapBuffs|equip greatampant; gap accuracy|5[/COLOR]

[COLOR=#0000ff]$CUSTOM|Combo|GAPants|_gapBuffs
|$ITEM|free spells|_gapBuffs|equip greatampant; gap skill
|$ITEM|elem & tough|_gapBuffs|equip greatampant; gap structure
|$ITEM|+25%ItemD|_gapBuffs|equip greatampant; gap vision
|$ITEM|+100%Mox|_gapBuffs|equip greatampant; gap speed
|$ITEM|5xCrit|_gapBuffs|equip greatampant; gap accuracy[/COLOR]


I'm attempting to use a combo box. Obviously each "piece" here has been placed on a separate line for ease of reading on the forum, but in my prefs it's the one continuous string. The 5 Command buttons in the 1st set work fine, and all display in DD as a big long ugly row of buttons with the correct working counter at the end of each. Just as it should. The combo box as coded in the 2nd set above displays nothing. I assume I'm missing the correct syntax, but this is how I understand it. If I remove the maxuses from the end each $item like the 3rd set it displays the combo box and GO! button. Adding a single maxuses at the end of the whole string prevents the box from appearing also. Where should I add maxuses?'

I'm not sure how many of these types of situations there would be, but I know I'd like to do a combo box for the pool table also, so there's at least 2 off the top of my head that I use daily.
 
Last edited:
Well, you're close, but there's two problems. One is syntax, two is that you're trying to do something that I haven't implemented yet. Remember that this is somewhat "experimental."

Look again at the syntax I posted. There is no maxUses argument for the individual list items. Each individual list element is disabled once that element's preference reaches 1. You don't ever want to disable the individual elements with GAPants; you just want to disable the whole thing once _gapBuffs reaches 5. So, first thing to do is remove the |5 from each element, and change all of the element preferences to a dummy variable that will always be false - I use "false". It works.

So now that fixes the first problem, and your deed looks like

$CUSTOM|Combo|GAPants|_gapBuffs|$ITEM|free spells|false|equip greatampant; gap skill|$ITEM...

Cool. It works. Except that after you cast one buff, the whole combobox will be disabled. Wha? Well, this is the part that I haven't implemented yet. The whole combobox will be disabled one that first preference (_gapBuffs) hits 1. So, for now, you can't use _gapBuffs there.

For now, you could replace it with a dummy variable ("false") and add a text deed above the combobox to tell you what _gapBuffs is.
 
Last edited:
Not sure if this is easily doable, but in the Current Deeds section of the Daily Deeds preferences tab can "move up" and "move down" arrow be added to the multi-select box? I know we can drag and drop, but it doesn't scroll when I try which means I have to drag and drop a bunch of times to move something I add to the top. Or maybe a "send to top" button?

If this needs to be in feature request, i can move it.

edit:
Also, not sure if i misunderstood, but I defined a Command deed:
$CUSTOM|Command|Get Some Slime|_gotSlime|volcano slime|10,

When I click the button it passes and performs the "volcano slime" command and i get a vial - but it isn't incrementing the _gotSlime preference.
 
Last edited:
maximillian the red said:
Not sure if this is easily doable, but in the Current Deeds section of the Daily Deeds preferences tab can "move up" and "move down" arrow be added to the multi-select box? I know we can drag and drop, but it doesn't scroll when I try which means I have to drag and drop a bunch of times to move something I add to the top. Or maybe a "send to top" button?

If this needs to be in feature request, i can move it.
Click to expand...

Known issue, pretty much at the bottom of my priority queue. The proper fix is to make the JDnDPanel scroll when you're holding an item at the top or bottom of it, like all modern file handling systems do. (ie windows explorer)

edit:
Also, not sure if i misunderstood, but I defined a Command deed:
$CUSTOM|Command|Get Some Slime|_gotSlime|volcano slime|10,

When I click the button it passes and performs the "volcano slime" command and i get a vial - but it isn't incrementing the _gotSlime preference.
Click to expand...

_gotSlime is not a built-in mafia preference, so mafia will not increment it for you. You are responsible for making it do so. There are several ways of doing this; see the discussion a page or two ago.
 
roippi said:
_gotSlime is not a built-in mafia preference, so mafia will not increment it for you. You are responsible for making it do so. There are several ways of doing this; see the discussion a page or two ago.
Click to expand...

oh ok, yeah i had it doing that before. i thought the new deed type made it so i didnt have to. my bad.
 
And I got fidgety today because I left combodeeds half-implemented.

r9659 allows you to specify a maxUses argument to combo deeds in the form
Combo|displayText|preference|maxUses|<rest of deed>

so now this works for Greatest American Pants:
Code: 
$CUSTOM|Combo|GAPants|_gapBuffs|5|$ITEM|free spells|false|equip greatampant; gap skill|$ITEM|elem & tough|false|equip greatampant; gap structure|$ITEM|+25%ItemD|false|equip greatampant; gap vision|$ITEM|+100%Mox|false|equip greatampant; gap speed|$ITEM|5xCrit|false|equip greatampant; gap accuracy

As a reminder: maxUses is the threshold at which the ENTIRE combobox is disabled. You cannot specify thresholds for the individual list elements; they are disabled when their respective preferences >= 1.
 
You must log in or register to reply here.
Back
Top