Harvest – A highly customisable farming script

Craggles

New member
Code:
har_current_activity => finish
apply_prerun_settings
CCS set to default
(but battle action is currently set to attack with weapon)
improve_spirits
finished_farming
true
overdrink
Overdrinking
head_full
num_at_songs
You have 3 AT songs active
max_at_songs
You can currently hold 3 AT songs in your head
equip_song_raisers
Maximizing...
168 combinations checked, best score 0.0 (FAIL)
Maximizing...
168 combinations checked, best score 0.0 (FAIL)
cheapest_at_buff
Division by zero (Harvest.ash, line 717)

Char 1

Code:
har_current_activity => finish
apply_prerun_settings
CCS set to default
(but battle action is currently set to attack with weapon)
improve_spirits
finished_farming
true
overdrink
Overdrinking
head_full
num_at_songs
You have 2 AT songs active
max_at_songs
You can currently hold 3 AT songs in your head
request_buff
Division by zero (Harvest.ash, line 780)

Char 2

The only difference is the second character has Carlweather's Cantata of Confrontation.
 

Theraze

Active member
Quick consumption suggestion. In the fortune cookie consumption section:
Code:
if (to_int(get_property("valueOfAdventure")) > mall_price($item[milk of magnesium])) use(1, $item[milk of magnesium]);
Or if you have profit saved somewhere easily usable, that works too. But yeah... if you're making over 800-1000 per adventure (which you should be even if you don't do anything more exciting than the giants) then that extra adventure from the fortune cookie is useful.

Edit: Here's the problem.
Code:
			int cost = num_turns/turns_per_cast(the_skill) * mp_cost(the_skill);
If you don't have ANY accordion, your turns per cast would be 0. And you can't divide num_turns by 0. Similar problem exists with any turtle tamer buffs if you don't have a turtle totem.

Easiest fix is to change this line:
Code:
		if(the_skill != $skill[none] && skill_num != 6025 && num_turns > 0)
to this:
Code:
		if(the_skill != $skill[none] && have_skill(the_skill) && skill_num != 6025 && num_turns > 0)
This makes it only auto-shrug AT songs that you can cast yourself. But the code already considers owned cost later. Alternative:
Code:
  while (item_amount($item[stolen accordion]) < 1 && get_meat(1) >= 50)
    use(1, $item[chewing gum on a string]);
Put that above the check, and it should get you an accordion if you have nothing. Alternative:
Code:
			int cost = num_turns/(turns_per_cast(the_skill) > 0 ? turns_per_cast(the_skill) : 1) * mp_cost(the_skill);
This one considers buff-only, uncastable effects to be highly valued, not reducing the count at all. If this works, it's probably the best of the 3 options.

Edit: Yep, third works and is the one I'd suggest.
> ash skill the_skill = $skill[none]; (10/turns_per_cast(the_skill) * mp_cost(the_skill));

Division by zero ()
Returned: void

> ash skill the_skill = $skill[none]; (10/(turns_per_cast(the_skill) > 0 ? turns_per_cast(the_skill) : 1) * mp_cost(the_skill));

Returned: 0

> ash skill the_skill = $skill[donho]; (10/(turns_per_cast(the_skill) > 0 ? turns_per_cast(the_skill) : 1) * mp_cost(the_skill));

Returned: 75
 
Last edited:

Winterbay

Active member
If you don't have ANY accordion, your turns per cast would be 0. And you can't divide num_turns by 0. Similar problem exists with any turtle tamer buffs if you don't have a turtle totem.

For what it's worth the same is also true for saucespheres if you have no saucepan.
 

Theraze

Active member
Ah, true. So yeah, that third fix should take care of sauce, turtle, and accordion buffs. :)

Edit: It also gets used twice, so here are both (replacement) lines.
In cheapest_at_buff
Code:
			int cost = num_turns/(turns_per_cast(the_skill) > 0 ? turns_per_cast(the_skill) : 1) * mp_cost(the_skill);
In request_buff
Code:
		int casts_needed = ceil(turns_needed / (turns_per_cast(the_skill) > 0 ? turns_per_cast(the_skill) : 1).to_float());
The second is more likely to have problems, since it could call any of those buff types.
 
Last edited:

heeheehee

Developer
Staff member
Quick consumption suggestion. In the fortune cookie consumption section:
Code:
if (to_int(get_property("valueOfAdventure")) > mall_price($item[milk of magnesium])) use(1, $item[milk of magnesium]);
Or if you have profit saved somewhere easily usable, that works too. But yeah... if you're making over 800-1000 per adventure (which you should be even if you don't do anything more exciting than the giants) then that extra adventure from the fortune cookie is useful.

Another suggestion is to do the same with munchies pills -- if you're making 1300 MPA or more (which is slightly more involvement than mere castle farming), then this becomes optimal, as well.
 

coderanger

Member
I asked about this a while ago, finally wrote the patch and been using it for a few weeks now. https://gist.github.com/4012381aa0b3c6b28e42 that adds the idea of a familiar_script for each mode, which if set overrides the normal familiar/familiar equipment logic. I can share my test script which cycles through item-producing familiars if people are interested, but it is far from polished.
 

Banana Lord

Member
Well, Banana Lord's suggestion was actually relevant, because mafia had an updated daily build with the change to can_equip 10 hours before your post saying you were going to closet the shirt waiting for mafia to update... :)
Yay for unintentionally intentional relevance, obfuscational sentences, and creative spelling!

EDIT: My dictionary informs me that the correct term is "obfuscatory". As a grammar nazi I apologize for this transgression :p

Banana Feature Request
There has to be a way to turn that into a thing. Let's coin that phrase right now.

Option to use Modifier maximizer
The maximizer is already used in the rollover section, and Harvest will save the most optimal outfit for you (using the name you specified for your rollover outfit in the relay script). As for the farming section, the best way to farm is not always to maximise +meat or +items, sometimes combat modifiers are optimal, and sometimes we need special items equipped to farm at all (i.e.: The Sea). In most situations like this Harvest leaves it up to the user to decide on the most optimal course of action. My goal with Harvest was to make it easy for the user to implement a particular farming strategy, not to design one for them. Just out of interest, has anyone tried dj_d's MakeMeatFast.ash? Does it/did it work well?

[Divison by zero problems]
Do you have a blank line at the bottom of the script file? turns_per_cast($skill[none]) -> 0 is the only situation I can think of that would give that error. If it was a spelling mistake Mafia would throw a "bad skill value" error.


Quick consumption suggestion. In the fortune cookie consumption section:...
Yep, good idea. I wasn't originally going to be fussed about minor optimizations like that, but hey, who am I to deny an inch where I've already given a mile? :p

If you don't have ANY accordion, your turns per cast would be 0. And you can't divide num_turns by 0. Similar problem exists with any turtle tamer buffs if you don't have a turtle totem.
There's a function to make sure the player has a mace of the tortoise and a rock and roll legend (or better). The theory was that that would never be a problem, but in the current version of the script they're called in the wrong order. Wouldn't a simpler fix be to make sure that get_buffing_aids() gets called before request_buff(...) and cheapest_at_buff()?

Would you mind giving me a quick tutorial on the "?" and the ":" characters? I've never used those before :).

For what it's worth the same is also true for saucespheres if you have no saucepan.
Hmm. My rationale for always getting the accordion and turtle casting items was that it would almost always be necessary for a character, and where it wasn't it would either become so as the character's farming ability was improved, or be beneficial for other reasons. That doesn't apply to the saucepan. Are saucespheres ever optimal/useful? I didn't write Harvest with characters below level 13 in mind, or those with combat difficulties. It might be worth revising that opinion though.

Another suggestion is to do the same with munchies pills -- if you're making 1300 MPA or more (which is slightly more involvement than mere castle farming), then this becomes optimal, as well.
See what I meant about that inch mile thing? Let that optimal crowd have their way once, just once, and you'll never get a moment's piece :D. Added to to-do list.

I asked about this a while ago, finally wrote the patch and been using it for a few weeks now. https://gist.github.com/4012381aa0b3c6b28e42 that adds the idea of a familiar_script for each mode, which if set overrides the normal familiar/familiar equipment logic. I can share my test script which cycles through item-producing familiars if people are interested, but it is far from polished.
I'm still hesitant to add this. In general I believe that "more settings = bad". The only advantage of adding a new setting for each section (bountyhunting, farming, etc.), each of which specifies a separate script, is so that you can cycle through item-producing familiars. Now that might be a worthwhile feature, but in order for it to be worth adding I need to be convinced that the irritation of additional complexity is outweighed by the benefits to most users. So, convince me :). If I do add it, I don't think I'll do it like you have. I'd make it as invisible as possible by providing a checkbox to toggle automatic familiar switching on or off. Now comes the fun part of design, options and problem solving.

  • Harvest could automatically look for item-producing familiars, or the user could specify them in a data file.
  • Harvest could decide which familiars were optimal, or simply use all of the familiars from a predefined list that were available to the character.
  • The script could decide the optimal number of items to collect from each familiar before switching to another based on the character's most recent MPA stats, or it could let the user specify this number in the afore-posited datafile.
  • The script could work out which familiars to use in certain sections (modes), or let the user specify that somehow.

As you can see the main decision to make is to automate or not to automate, and taken together automating all of that would not be trivial. So perhaps I could automate some things and leave others up to the user, but again, this forces the user to work out what's optimal and what isn't, and strange though it sounds, I wonder if most people wouldn't be happier not making this decision at all. The argument that adding a new feature is at worst harmless because users who find it difficult to use can simply ignore it is demonstrably false (look at open source software). I'm interested to know what you all think.
 
Last edited:

Theraze

Active member
Basically, the ? : thing means that if the check on the left of ? is true, do what's on the left of the : and if it's false, do what's on the right side. These two would basically be equivalent... ish.
Code:
if (this) do something;
else do something else;
is similar to
Code:
(this ? do something : do something else);
When ternary operators get really awesome is in the middle of another calculation, since it means you don't need to rewrite your whole thing repeatedly. Anyways, if you want to read more about it, Wikipedia has an article here:
http://en.wikipedia.org/wiki/Ternary_operation

Basically, we're most like the C and Java implementation. Here's their example on that...
if (a > b) {
result = x;
}
else {
result = y;
}
This can be rewritten as the following ternary statement:
result = a > b ? x : y;

So, if we weren't using ternary operators, our best way to do this would be as an additional two lines...
Code:
			int turnspercast = turns_per_cast(the_skill);
			if (turnspercast < 1) turnspercast = 1;
			int cost = num_turns/turnspercast * mp_cost(the_skill);
instead of just using them to do this:
Code:
			int cost = num_turns/(turns_per_cast(the_skill) > 0 ? turns_per_cast(the_skill) : 1) * mp_cost(the_skill);
 

Banana Lord

Member
Ah OK, thanks. I was going to be learning C this summer (southern hemisphere), but I ended up doing maths instead, which has been great up until now because, while it may be useful, does anyone actually ENJOY studying probability? Currently my only formal education in computer science has been conducted in Python.
 

Winterbay

Active member
Probabilities are fun! I mostly use my knowledge to laugh at journalists that make hideous assumptions in newspapers based on sub-par research since my work isn't that maths intensive atm.
 

Banana Lord

Member
Euch. Are not. In my experience probability's either too easy to be interesting, or tedious and difficult (although I have no problem with the latter, in normal circumstances). I did hear a good suggestion today though, we could calculate the probability of a student determining the Talyor polynomial of order 23 about x=671 of some semi-randomly chosen function and plot their stress level against time as a series of vectors in 3-space. That way we could tick off half of the course in a single exam question! Free banana points for whoever posts a Wolfram Alpha link to that first. You can spend them on BFRs! (Banana Feature Requests, not brominated flame retardants).

Ended up looking at BFRs (brominated flame retardants, not Banana Feature Requests) on Wikipedia, I *love* their blackout page. Very nicely done. I was expecting something more.... Well, more wikipedia-ish.
 
Last edited:

Winterbay

Active member
You can spend them on BFRs! (Banana Feature Requests, not brominated flame retardants).

Ended up looking at BFRs (brominated flame retardants, not Banana Feature Requests) on Wikipedia, I *love* their blackout page. Very nicely done. I was expecting something more.... Well, more wikipedia-ish.

Does my profession show through if I say that I started thinking about the flame retardants directly at that TLA? :)
 

Banana Lord

Member
Haha, well, the thought only occurred to me as I typed the acronym for "Banana Feature Requests" so it had the same effect on both of us. Now, your profession... *Shakes magic 8-ball* You are a firefighter! No? An environmental activist working in a professional capacity! Still nothing? OK, then you must be an investor with big interests in the bromine industry! Third time lucky eh?
 

Winterbay

Active member
Toxicologist working with product safety in baby diapers and adult incontinence products :)
(you'ld be amazed at the amount of times we get questions as to wether we have flame retardants in our products or not)
 

Winterbay

Active member

Nope. Even if it weren't for the safety issues the amount you would have to add for it to actually have any effect on the flammability of a diaper is so high to be extremely cost prohibitive as well. There was actually I think 2 cases last year where old people who were smoking died as a result of dropping their cigarettes in their laps, forgetting about it, and the diaper catching fire, but it's hard to do anything about it (other than to stop people from smoking if they're suffering from dementia I guess).
 

coderanger

Member
I'm still hesitant to add this. In general I believe that "more settings = bad". The only advantage of adding a new setting for each section (bountyhunting, farming, etc.), each of which specifies a separate script, is so that you can cycle through item-producing familiars. Now that might be a worthwhile feature, but in order for it to be worth adding I need to be convinced that the irritation of additional complexity is outweighed by the benefits to most users. So, convince me :). If I do add it, I don't think I'll do it like you have. I'd make it as invisible as possible by providing a checkbox to toggle automatic familiar switching on or off. Now comes the fun part of design, options and problem solving.

  • Harvest could automatically look for item-producing familiars, or the user could specify them in a data file.
  • Harvest could decide which familiars were optimal, or simply use all of the familiars from a predefined list that were available to the character.
  • The script could decide the optimal number of items to collect from each familiar before switching to another based on the character's most recent MPA stats, or it could let the user specify this number in the afore-posited datafile.
  • The script could work out which familiars to use in certain sections (modes), or let the user specify that somehow.

As you can see the main decision to make is to automate or not to automate, and taken together automating all of that would not be trivial. So perhaps I could automate some things and leave others up to the user, but again, this forces the user to work out what's optimal and what isn't, and strange though it sounds, I wonder if most people wouldn't be happier not making this decision at all. The argument that adding a new feature is at worst harmless because users who find it difficult to use can simply ignore it is demonstrably false (look at open source software). I'm interested to know what you all think.

So another option I toyed with is having a single hook script that gets passed the stage name (and probably the familiar settings from Harvest) as arguments. That would reduce the impact of it from the UX side, and could be lumped in alongside the eatdrink script hook, etc. As for the idea that its single purpose, I would rebut that in two ways. One, it would also be helpful for things like the robot reindeer or hipster fights. Two, rotating item-producing familiars is a place I could see people having a lot of opinions on the best way to do it. For example, should you use the Zen Motorcycle and if so when? Allowing people to distribute and tweak those strategies externally keeps Harvest leaner and reduces the load on you (though I could imagine having a basic one in the same way you ship a middle-of-the-road combat script which works for the vast majority of people). Does that somewhat address your concerns?
 

Banana Lord

Member
@Winterbay: Wow, I wasn't sure if you were joking or not. Bet you didn't expect to end up with that job! :D

@Coderanger: Yeah, a single script was the only way I was considering implementing it. But at that point we're just looking at a script which is called immediately prior to combat, which is just a between battle script. So why bother having a hook for that at all? The only problem I foresee with a user wanting to write a custom BBS is working out whether Harvest is currently running or not (they might not want certain functions executed when they're not farming, or they might only want the BBS active when they're running Harvest). So I could either have a mafia property along the lines of _har_harvest_running or perhaps better yet simply provide a "Between battle script" option. Harvest would set the player's BBS to whatever was specified there (or do nothing if no script was specified) and then set their BBS back to whatever was set before Harvest ran (that's the behaviour for things like CCSs). That way if a user wanted a BBS to run all the time, no matter what they were doing, they could just set a BBS as normal and leave the Harvest setting blank, or if they only wanted to run a BBS while farming they could have no BBS set normally and Harvest would activate their specified script when it ran and deactivate it when it finished, and in the final case if the user wanted to run one BBS normally and a different one when they were farming they could similarly set a BBS as normal and specify another for Harvest to use which would be deactivated when Harvest finished.

Would that meet your needs? I started watching "just one more episode" of House last night (bad idea), so if any of that doesn't make sense please say so :).
 
Top