Feature - Implemented Adding some overloads that will benefit users of the method chaining form

gausie

D̰͕̝͚̤̥̙̐̇̑͗̒e͍͔͎͈͔ͥ̉̔̅́̈l̠̪̜͓̲ͧ̍̈́͛v̻̾ͤe͗̃ͥ̐̊ͬp̔͒ͪ
Staff member
At the moment if you like to use the method chaining form:

Code:
variable.function();
//instead of
function(variable);

there are some methods that could use taking arguments in a different order. For example, it's silly to do

Code:
1.use($skill[The Ode to Booze])

compared to

Code:
$skill[The Ode to Booze].use(1)

or indeed

Code:
$skill[The Ode to Booze].use()

with 1 as the default value.

Can anyone think of any reasons I shouldn't add these overloads where possible? drink, eat, use (and even equip with slot and equipment) would all benefit.

As my first post since, I feel like I need to say: I'm still not decided on whether it's right to carry on working on kol-related tools given what has come to light.
 

Veracity

Developer
Staff member
Those all make sense and the functions should have been defined that way in the first place.
If "method chaining" had been part of ASH from the beginning, I am sure those methods would have been designed that way.
Given that it was added later, it was too late to replace the method declarations, but overloads are the way to go.
 

Veracity

Developer
Staff member
By the way, I am asking myself the same questions. Personally, KoL is tainted, to me now. There was a fair bit of content I did not enjoy much, but what seemed merely juvenile before is a lot more troublesome now. I'm still considering how I want to respond vis a vis KoL itself.

However, my "community" has not been KoL for many years. I don't do public chat or forums, and my clan is mostly inactive. I think there are 4 active members left. My community is right here. Members of this community will make their own decisions on how to proceed, but if they continue to play and script, go for it. My feelings about KoL - which for now extend to my withdrawing financial support - do not apply here, although the more I withdraw from the actual game, the less I will be inclined/able to support changes in the game in KoLmafia.

I'm finishing up a couple things in preparation for spinning up a final (?) point release. Finishing up KoE, support for choice adventures with extra arguments, and so on. Stuff that will leave KoLmafia in good shape for the current state of the game and in even better shape to automatically adapt to future developments. It's already quite good at that.

Your Feature would be a great thing to include, since future scripts by whomever would be cleaner.
 

Veracity

Developer
Staff member
I like what you did.

You made all of the following forms valid:

eat( int, item )
eat( item, int )
eat( item ) // count is 1

for: create, use, eat, eatsilent, drink, drinksilent, chew

I just used your technology for the following:

overdrink, retrieve_item, buy, buy_using_storage

as well as:

adventure( int, location )
adventure( location, int )

Revision 19548
 

Veracity

Developer
Staff member
Other possibilities which neither you nor I did (yet):

use_skill( count, skill ); //Current
use_skill( skill, count );
use_skill( skill ); // Currently exists, casts one time only

equip( item ); // Current
equip( slot, item ); // Current
equip( item, slot );

put_closet( int, item ); // Current
put_closet( item, int );
put_closet( item ); // default to 1 or to all? Latter obviates using item_amount()

take_closet( int, item ); // Current
take_closet( item, int );
take_closet( item ); // default to 1 or to all? Latter obviates using closet_amount()

// Similarly for stash and display and maybe shop. Perhaps.

I am tired. I want to spin a new release and stop. So this may or may not have further work done.
 

Veracity

Developer
Staff member
Bumping from Page 7.

You and I both added a bunch. Perhaps there are more that would be useful.
I (we) can look at them, by and by, and add anything appropriate.
And then mark this as Implemented.
 

Veracity

Developer
Staff member
Revision 20000 adds the following:

boolean adventure( location, int count, string filter )
void add_item_condition( item, int count )
void remove_item_condition( item, int count )
boolean buy( item, int count )
boolean buy( item, int count, int limit )
boolean buy_using_storage( item, int count )
boolean buy_using_storage( item, int count, int limit )
boolean put_closet( item )
boolean put_closet( item, int count )
boolean put_stash( item, int count )
boolean put_display( item, int count )
boolean take_closet( item, int count )
boolean take_storage( item, int count )
boolean take_display( item, int count )
boolean take_stash( item, int count )
boolean autosell( item, int count )
boolean hermit( item, int count )
boolean use_skill( skill, int count )
boolean use_skill( skill, int count, target )
boolean equip( item, slot )

All the versions where the count comes first still exist, of course.

I looked at every method in RuntimeLibrary and I think this is it.
 
Top