Feature - Implemented Adventure Queue Support

roippi

roippi

Developer
r12070 more-or-less finalizes this, I think, at least in terms of being able to close this feature request. Location Details should dynamically update with adventure-queue-correct encounter rates. appearance_rates() has an overloaded form to get the queue-corrected rates as well. Report any bugs you see in either.

Adding olfaction/banishing/whatever support is possible now though not exactly straightforward. I'll get around to it eventually.
 
lostcalpolydude

lostcalpolydude

Developer
Staff member
The location field should probably be combat_queue or something, in preparation for an eventual noncombat_queue. I think the noncombat queue will ultimately be more complicated since superlikelies need to not be included.
 
roippi

roippi

Developer
The usefulness of having access to the noncombat queue seems much more marginal than access to the (already marginal) combat queue. Plus it's more complex, as you say, and mafia's knowledge of noncombat adventures is.. quite limited right now.

I'm not opposed to it being implemented, if only for completeness' sake. Don't think I'll be doing it though.

I'll change .queue to .combat_queue just so it's not an issue if someone implements the noncom queue.
 
zarqon

zarqon

Well-known member
Roippi, this is fantastic! It's very exciting to see the possibility of more accurate predictions for adventuring scripts.

I'm already using this in my local BatMan RE to display the queue in the Adventure Again box, and will be integrating it into ZLib's has_goal() predictions, especially once it accounts for banished monsters and Olfaction/Creamstaff.

I know mafia tracks monsters banished by both Boris and Jarlsberg's special abilities, as well as the Nanorhino. It doesn't appear to track any of the others, such as Howl of the Alpha or combat items. Temporary banishments like Creepy Grin, Stinkeye, or the cocktail napkin could add counters which include the monster name, but tracking in a preference would probably be better.

Rather than add individual preferences for every single thing that banishes a monster, perhaps a single preference containing all banished monsters and duration of banishment would be more future-proof? I imagine it would also make it far easier to collate all the banished monsters in order to adjust their appearance rate.

Looking ahead, once banished monsters are accounted for, the function could also add tumbleweed to zones where all monsters have been banished.

One issue to report: Cyrpt mini-bosses are being treated as regular monsters. They should probably have their appearance rate changed to 0 for both versions of the function. If you wanted to be fancy, the queue-savvy version could show it as the only monster in the location if 0 < zone evilness <= 25.
 
Winterbay

Winterbay

Active member
zarqon said:
Looking ahead, once banished monsters are accounted for, the function could also add tumbleweed to zones where all monsters have been banished.
Click to expand...

I don't know if this is normal behaviour or just Jarslberg wonkiness but when banishing all monsters in a zone (with the banish staff) they all got back (I was trying to only have noncombats left, and I'm not surprised it didn't work, but still) so I'm not sure if it is possible to banish all monsters in a zone any longer.
 
zarqon

zarqon

Well-known member
Ah. Well, one step at a time I suppose. I'm getting excited about this and getting ahead of mys... er, getting ahead of them...selves.

ETA: Wiki entry for tumbleweed mentions that it
Will only occur if you are adventuring in a zone and:
  • the zone has monsters which appear conditionally,
  • that condition is not met,
  • and all other monsters have been banished.
Click to expand...
So it seems a bit more complicated. For zones without conditional monsters, evidently banishing all monsters causes them all to un-banish? For zones with conditional monsters, banishing all the other monsters can lead to tumbleweed.
 
Last edited:
zarqon

zarqon

Well-known member
Came across another issue with this. If this should be a new bug report, let me know or if you're a minion feel free to move it.

> ash appearance_rates($location[haunted bathroom], true)

Returned: aggregate float [monster]
Claw-foot Bathtub => ∞
Guy Made of Bees => �
Malevolent Hair Clog => ∞
none => 30.0
Toilet Papergeist => ∞
Click to expand...

All the regular monsters have an appearance rate of infinity, and the GMoB has a square (non-displayable character of some sort). I checked the queue tracking and saw this:

> ash my_location()

Returned: Haunted Bathroom
nocombats => false
zone => Manor2
parent => Manor2
parentdesc => Spookyraven (Second Floor)
bounty => none
combat_queue => Lord Spookyraven; Toilet Papergeist; Claw-foot Bathtub; Malevolent Hair Clog; Claw-foot Bathtub
noncombat_queue => Don't Hold a Grudge; Having a Medicine Ball; Don't Hold a Grudge; Having a Medicine Ball; Having a Medicine Ball
Click to expand...

My guess is that it's the Lord Spookyraven being there that's somehow screwing things up. Should we be filtering monsters by location? i.e. not registering monsters which are not known to be native to our current location?

Either way, something should probably be done to avoid ∞'s and �'s in the event of bad data.

ETA: It happened again when my queue contained this:

combat_queue => Claw-foot Bathtub; Toilet Papergeist; Malevolent Hair Clog; Malevolent Hair Clog; Guy Made of Bees
 
Last edited:
roippi

roippi

Developer
This is probably a divide-by-zero issue, since we internally represent special monsters' encounter rates as zero. I forget the formula I used to calculate queue-modified encounter rates, but I'm sure it's to blame.
 
H

heeheehee

Developer
Staff member
That would make sense, since I vaguely recall said symbol cropping up some time back as the manifestation of NaN (which you'd get from 0./0.).
 
roippi

roippi

Developer
Here's the method, if anyone wants to fix it.

Code: 
	public static double applyQueueEffects( double numerator, int denominator, MonsterData monster, String zone )
	{
		RollingLinkedList zoneQueue = COMBAT_QUEUE.get( zone );

		// without queue effects the result is just numerator/denominator.
		if ( zoneQueue == null )
		{
			return numerator / denominator;
		}

		// rate for monster IN the queue is 1 / (4a - 3b) and rate for monster NOT IN the queue is 4 / (4a - 3b) where
		// a = number of monsters in zone (aka the old denominator)
		// b = number of unique monsters in the adventure queue

		HashSet<Object> zoneSet = new HashSet<Object>( zoneQueue ); // just care about unique elements

		double newNumerator = numerator * ( zoneQueue.contains( monster.getName() ) ? 1 : 4 );
		double newDenominator = ( 4 * denominator - 3 * zoneSet.size() );

		return newNumerator / newDenominator;
	}
 
You must log in or register to reply here.
Top