ASH changes in 7.9

Veracity

Developer
Staff member
New control flow constructs:

Code:
foreach <key> in <aggregate>
    <block or statement>

Code:
for <var> from <int expression> upto  <int expression> [ by <int expression> ]
    <block or statement>

for <var> from <int expression> downto  <int expression> [ by <int expression> ]
    <block or statement>

The "by x" clause is optional and defaults to "by 1".

Code:
repeat
    <block or statement>
until ( <boolean expression> );

All loops (while, foreach, for, repeat) allow "break" and "continue" within the loop body.

Functions can now recursively call themselves.

You can now declare a "forward reference" for a function, which allows mutual recursion. Like this:

int my_function( int parm1, boolean parm2);

and then later, you declare the actual function with the same return type and parameters and an actual function body.

New functions:

boolean string_to_boolean( string );
int string_to_int( string );
float string_to_float( string );
item string_to_item( string );
zodiac string_to_zodiac( string );
location string_to_location( string );
class string_to_class( string );
stat string_to_stat( string );
skill string_to_skill( string );
effect string_to_effect( string );
familiar string_to_familiar( string );
slot string_to_slot( string );
monster string_to_monster( string );

The above are the inverse of the previously existing xxx_to_string functions. You can now, therefore, use any simple data type you wish with get_property/set_property

int count( <aggregate> thing );

Returns the number of elements in the specified map or slice.

location my_location();
boolean take_stash( int count, item thing );
 

Tirian

Member
My thought (when I requested it) was that one would place it in a between-battle script to let you know where you were just about to adventure so that you could do some last-second tweaking of buffs or MCD levels or what have you.

I have to confess that Holatuwol added this really quickly after I requested it and I still haven't gotten around to writing the map that would associate safe adventuring threshholds for each location so that I can actually use it effectively, but it should be very handy once that happens.
 

Nightmist

Member
[quote author=Tirian link=topic=205.msg1135#msg1135 date=1150622651]
My thought (when I requested it) was that one would place it in a between-battle script to let you know where you were just about to adventure so that you could do some last-second tweaking of buffs or MCD levels or what have you.[/quote]

Oh... I currently use a function that sets up all of that (Well only MCD if you have access to that, when I start factoring in equipment I need to also take into account of the loss of moxie ++ the equipment might of given me and so it was slightly harder then I had expected, I should have mine completed by the end of the next weekend (I do all//most of my script work in the weekends)) and then adventures for 1 turn. (This functon is called by my main adventuring script which is using a while loop so its pretty much a second inbetween-adving script >>)
 

Tirian

Member
Yes, I've been working on the same thing. Maybe the admins should create a private forum for "powerusers and their scripts that they wouldn't want to fall into the wrong hands" so we can share our work. :D

I found a few issues with moving toward adventuring for 1 turn at a time instead of my_adventures(). First is that you have to give up condition checking which is a good way to handle things much of the time. Also, there are places like the Icy Peak where it does some condition checking to make sure that you have unlocked the Trapzor's quest and it would break my heart if that was an extra call to the server for every adventure. More importantly, there are times like the Typical Tavern quest and the Cyrpt where you have to give up control for many rounds at a time. (Although I think KoLmafia has changed its handling in the past two or three days to the point that I can now script the cyrpt the way I want to -- joy!)

So my suggestion was that all of these things could be alleviated if the between-battle script could be broken up into a just-before and just-after scripts and the former would have access to knowledge about where it was that you were about to go. I don't think the splitting up happened (although I'm having trouble with getting any between-battle scripts to run so I can't be certain), but that's when my_location() was added.
 
Top