Monster Encounter Tests

holatuwol

holatuwol

Developer
Okay, since I'm here anyway ... please choose between one of the following two features.  #1, the ability to add a monster name to the list of conditions.  #2, the ability to ask whether or not a given monster is in the "queue".  You can't have both, because that's too much work given this time of year (I'm only going to bother with one or the other).
 
Re: Illarion's NeoStasis script v1.4

Even though I don't have a use with this script, but in general, I would like to vote for add monster encounter.

EDIT: For explanation. When I'm being lazy and not playing turns by hand, I gCLI everything. Doing this would allow me to play the queue to some extent while not watching every turn.
Code: 
conditions add monster blooper
-or-
conditions add monster w imp
etc...replace with dairy goat, various valley monsters if needed, more etc...

Whereas, knowledge of the current queue, I could see use in..making scripted decisions, or I suppose, if you run a swath of adventures, then want to see what the last 5 encounters were...but I don't see as much use as adding a monster as a condition.
 
Splitting from initial post.

Also, when providing your answer, please give a brief explanation as to why you chose one over the other. Thanks!
 
I vote for adding monster name to the list of conditions. The reasons that macman's given pretty much echo my opinions. In fact, I was wishing that I could "conditions add monster blooper" just the other day :)

As far as insight into the monster queue, I think what I'd really prefer to see (and this would be down the road, certainly less important than monster-name-as-condition) would be a mapped list of the five monsters in the queue, rather than info on whether a single monster is in it. Example: when I do the Goatlet, my rules of thumb are basically:

(1) If the dairy goat is in the queue once, and 0-1 of the other two goats are also in the queue, I want to clear the queue.
(2) If the dairy goat is in the queue twice, I want to clear the queue.

So basically, I don't want to clear the queue if it looks like: drunk goat, saber goat, drunk goat, saber goat, dairy goat. Make sense?
 
I'd personally like to see at least 1 function dealing with the queue, for example inqueue($monster[Procrasination Giant]), maybe returns an int value for the number of times the Procrastination Giant is in the queue. Since with this info and the wiki, you could probably find probabilities for specific encounters, allowing micromanagement of your turns. Also, I don't use stopping conditions very much (and anyways, I think item conditionals remove the need for monster conditionals, at least for now) - assuming this is the use of conditionals you mean. But that's just my 2 cents on the matter.
 
If you don't know what "the queue" is, the feature probably doesn't concern you. :)  Also, in case this changes any one's minds, here's how either would be implemented.

For monster encounter conditions, if you set it and you hit the monster, KoLmafia clears all pending conditions and stops.  On the other hand, if you manage to fulfill your conditions, KoLmafia clears your pending monster condition and says, "You didn't really need to do this anyway."  The idea is there for CLI-focused players.

You can already write ASH scripts to create a virtual queue.  The idea is simply to make it built-in, so that KoLmafia creates its own built-in settings-driven queue.  You can access what's in each slot directly by looking up the associated property, but in_queue (or maybe queue_position) are the only built-ins that will be added.  This idea is there for ASH-focused players.

To be honest, I'm biased toward monster encounter conditions since I've never felt the need to ASH script anything except as a challenge or for the now-dormant 'make holatuwol write a script' thread, but I figured I'd ask the community regarding which one would be more interesting.
 
[quote author=holatuwol link=topic=885.msg4352#msg4352 date=1177627369]For monster encounter conditions, if you set it and you hit the monster, KoLmafia clears all pending conditions and stops.  On the other hand, if you manage to fulfill your conditions, KoLmafia clears your pending monster condition and says, "You didn't really need to do this anyway."  The idea is there for CLI-focused players.[/quote]*Sneaks on to the computer at the orgo lab he works at* On immeditate response, I wasn't a fan of the implementation. However, now I'm trying to think of a example, where either of those implementation methods would prove troublesome, and well...I can't. So, thinking over the methods again, I think they both make sense.
 
I'm voting for the monster name - and I can't think of any situation where my other conditions would be cleared and I would still want to find that monster (generally I would use this for gCLI adventuring, so I can change to another area when I get a monster that *doesn't* drop the item I'm looking for).
 
The monster conditions thing wound up being more complicated than I thought, so I had to rearrange the fight code to get it to work.  In effect, adding the combat queue was really easy.  So in the end, you got both. :)

boolean combat_queue_contains( monster m ): Added

The player properties associated with the queue are "monsterQueue1", "monsterQueue2", "monsterQueue3", "monsterQueue4" and "monsterQueue5". Hopefully that's not too confusing for anyone. ;)
 
What is the syntax for the monster adding, is it "conditions add 1 monster <monster name>"? Also, will this perform fuzzy matching, and be able to function with the "?" operator?
 
No numbers, only one monster at a time to avoid confusion.

conditions set monster name

It doesn't function with ? right now (I think), and it performs substring matching, not fuzzy matching.
 
Hola, how hard would it be to add a cli command called "queue" or something, that simply printed the five monsters that were currently in the settings of mafia for "monsterQueue1", "monsterQueue2", etc? I can make a function in my namespaces script, to suffice until you have time, but seeing as the properties are there and everything, I wasn't sure how difficult it would be to implement the command.

EDIT: I've added the queue command to my namespaces script, so no hurry on adding it yourself.
 
[quote author=holatuwol link=topic=885.msg4502#msg4502 date=1178775242]
Hm. Would it be more useful than a Greasemonkey script which shows you the queue in your browser?[/quote]Well....the only thing with that is...I frequently, instead of manually adventuring might issue the command to mafia "adventure 3 goatlet" or something. I frequently use even single adventure commands (adventure 1) to let mafia conduct the battles for me (instead of loading the fight page and hitting "use custom combat", so, the greasemonkey script misses out on all of these. It's kinda moot since I've added a equally effective command to my namespaces script (which turned out easier than I had thought). But before I had written the function for my script, it was something I thought about. Quick question (which I could test, but figure I'll ask), is monsterQueue1 the monster that will come off of the queue next, or the most recent monster to enter the queue?

EDIT: It just seems based on the ease with which I implemented it into my script, it seems to be a relatively simple function to add, but I could be wrong...
 
Edit: Well, it's not difficult, but I don't like adding things to the CLI that don't have a GUI equivalent when the feature sounds like it'd be useful in the GUI as well. But I see your point about the relay browser.
On second thought, it doesn't seem useful in the GUI at all, for the way casual players play. I'm thinking of integrating it into the location details frame in some way, but it might just wind up cluttering that interface. I'll think this over, but for now, I've added the "queue" command to the CLI.
 
[quote author=holatuwol link=topic=885.msg4511#msg4511 date=1178843084]
On second thought, it doesn't seem useful in the GUI at all, for the way casual players play. I'm thinking of integrating it into the location details frame in some way, but it might just wind up cluttering that interface. I'll think this over, but for now, I've added the "queue" command to the CLI.[/quote]Awesome, thank you!
 
[quote author=Alexander Daychilde link=topic=885.msg5059#msg5059 date=1183347979]
I vote for adding a monster to the conditions. My reasoning? The queue is gone. ;-)[/quote]Already there
Code: 
conditions add <monster name>
 
You must log in or register to reply here.
Back
Top