New Content - Implemented Guzzlr tablet - May Item of the month

Rather than total deliveries, maybe just _guzzlrBronzeDeliveries. That should be complete, since daily Gold and Platinum counters already exist.

guzzlrProgress could indeed be useful, but I would expect it to stay over rollover, since you can keep a quest over rollover too.
 
Last edited:

taltamir

Member
The following traits need to be reset to defaults on ascension:
Code:
guzzlrQuestBooze
guzzlrQuestLocation
guzzlrQuestTier
questGuzzlr
first 3 should be changed to blank
the last one should be "unstarted"

=====

Abandoning a delivery correctly resets these:
Code:
guzzlrQuestLocation
guzzlrQuestBooze


But does not reset these:
Code:
questGuzzlr
guzzlrQuestTier
 
Last edited:

fredg1

Member
Rather than total deliveries, maybe just _guzzlrBronzeDeliveries. That should be complete, since daily Gold and Platinum counters already exist.

You're adding a property anyway, so it'd be better to get one that's actually directly usable, than one whose literally only purpose is to go in:
Code:
int totalDeliveries = get_property("_guzzlrPlatinumDeliveries").to_int() + get_property("_guzzlrGoldDeliveries").to_int() + get_property("_guzzlrBronzeDeliveries").to_int();

guzzlrProgress could indeed be useful, but I would expect it to stay over rollover, since you can keep a quest over rollover too.
IIRC, I remember someone saying that even though a quest carries through RO, the progress made doesn't.
 

fredg1

Member
citation: Ossein#8315 in the ASS discord, in #iotm-discussion:
Jonathan Lock / #1937905 05/24/2020
it's also worth mentioning that fights needed resets daily, even if your quest was accepted the previous day
and also previous day's fights don't seem to count towards the new lowered requirement
 
Last edited:

gausie

D̰͕̝͚̤̥̙̐̇̑͗̒e͍͔͎͈͔ͥ̉̔̅́̈l̠̪̜͓̲ͧ̍̈́͛v̻̾ͤe͗̃ͥ̐̊ͬp̔͒ͪ
Staff member
I will look into the bugs on ascension and quest abandonment.

It seems like if we're going to track bronze deliveries completed in a day (useless directly) it might just make more sense to track all deliveries in a day (somewhat compound but at least directly useful)
 

taltamir

Member
Instead of arguing about which of the two values is better, why not just have both? even if they could be calculated from each other... that just makes it easier for mafia to give them both

citation: Ossein#8315 in the ASS discord, in #iotm-discussion:
Jonathan Lock / #1937905 05/24/2020
it's also worth mentioning that fights needed resets daily, even if your quest was accepted the previous day
and also previous day's fights don't seem to count towards the new lowered requirement
alright. So it is still trackable though, just needs to be
_guzzlrDeliveryProgress
 
Last edited:

fredg1

Member
alright. So it is still trackable though, just needs to be
_guzzlrDeliveryProgress

It's, in retrospects (and after a "nudge" in the right direction by The Dictator), not actually a good idea, since you'd need to know if the shoes were used or not; simply counting the "raw" amount of fights won since you accepted the delivery doesn't really... give anything.
 

taltamir

Member
It's, in retrospects (and after a "nudge" in the right direction by The Dictator), not actually a good idea, since you'd need to know if the shoes were used or not; simply counting the "raw" amount of fights won since you accepted the delivery doesn't really... give anything.
Any script that deals with it is likely going to take the approach of:
1. if we own shoes then force wear them.
2. if we own shoes assume they were used
You're adding a property anyway, so it'd be better to get one that's actually directly usable, than one whose literally only purpose is to go in:
Code:
int totalDeliveries = get_property("_guzzlrPlatinumDeliveries").to_int() + get_property("_guzzlrGoldDeliveries").to_int() + get_property("_guzzlrBronzeDeliveries").to_int();
I thought of a use for it. instead of targeting number of adventures, target number of deliveries. an option to, say, "do 3 bronze deliveries a day then stop"
 

fredg1

Member
Any script that deals with it is likely going to take the approach of:
1. if we own shoes then force wear them.
2. if we own shoes assume they were used

You may not want to always use shoes, though. If you are pointed to, let's say, Barf Mountain, a zone in which you definitely want to adventure in anyway, no reason to go for the "quick" route, in detriment of +meat equipment. And informational scripts like Guide shouldn't "assume" what you did.

I thought of a use for it. instead of targeting number of adventures, target number of deliveries. an option to, say, "do 3 bronze deliveries a day then stop"

Fair enough.
 

taltamir

Member
You may not want to always use shoes, though. If you are pointed to, let's say, Barf Mountain, a zone in which you definitely want to adventure in anyway, no reason to go for the "quick" route, in detriment of +meat equipment. And informational scripts like Guide shouldn't "assume" what you did.
If you code not using the shoes in barf mountain you can also at the same time add a line to exclude it from the assumption of wearing the shoes.
Thus you could determine if the shoes were worn or not based on the target zone.

Also it occured to me that the thing it would be useful for the hat. only wear it when you are about to finish the delivery instead of every adventure.
... eh, nevermind. probably not worth it to wear the hat even for just 1 adventure
 

fredg1

Member
Also it occured to me that the thing it would be useful for the hat. only wear it when you are about to finish the delivery instead of every adventure.
... eh, nevermind. probably not worth it to wear the hat even for just 1 adventure

...you mean the pants?
 

taltamir

Member
_guzzlrGoldDeliveries is incorrectly counting the number of gold deliveries finished today instead of the number of delivery quests started today.
finished gold deliveries today is not actually useful because I need to know how many deliveries I am able start. As you can only start 3 gold deliveries a day.

I had a gold delivery I started yesterday and did not finish. It then finished today on the first adventure in that zone. Which incidentally seems to disprove the claim that turns spent reset on dayroll.

Because of this after take 2 gold delveries today I ended up with _guzzlrGoldDeliveries
so it wouldn't auto take the 3rd gold delivery quest because of this misleading tracking.
Once I manually took my 3rd gold delivery for the day and completed it I got

Code:
Preference _guzzlrGoldDeliveries changed from 3 to 4

Also this was then resets to 3 next time I visited the tablet
Code:
Preference lastEncounter changed from Steampunk Giant to Guzzlr Client Selection
Encounter: Guzzlr Client Selection
Preference _guzzlrGoldDeliveries changed from 4 to 3
Submitting option 2 for choice 1412
Preference guzzlrQuestLocation changed from to Lair of the Ninja Snowmen
Preference guzzlrQuestTier changed from to bronze
Preference guzzlrQuestBooze changed from to bottle of vodka
Preference questGuzzlr changed from unstarted to step1

I am not sure but I am wondering, does abandoning a gold delivery counts towards that figure?
if not it can cause the reverse issue of trying to start your "3rd" gold delivery that day when it is actually the 4th because you abandoned one

=======

platinum deliveries btw counts deliveries started instead of deliveries finished
 
Last edited:

fredg1

Member
_guzzlrGoldDeliveries is incorrectly counting the number of gold deliveries finished today instead of the number of delivery quests started today.
finished gold deliveries today is not actually useful because I need to know how many deliveries I am able start. As you can only start 3 gold deliveries a day.

That's a good thing to remember! Because of this, what we were talking about previously about implementing "_guzzlrBronzeDeliveries" would NOT work; for consistency, it would count the amount of bronze quests STARTED. In the same way, even if it counted the amount of bronze deliveries finished,
Code:
 int totalDeliveries = get_property("_guzzlrPlatinumDeliveries").to_int() + get_property("_guzzlrGoldDeliveries").to_int() + get_property("_guzzlrBronzeDeliveries").to_int();
would NOT work, since, as we were just reminded, two of those properties count quests STARTED.
We really need a property which counts the amount of quests finished in a day, by itself.

I had a gold delivery I started yesterday and did not finish. It then finished today on the first adventure in that zone. Which incidentally seems to disprove the claim that turns spent reset on dayroll.

That's good to know.
 

taltamir

Member
As a workaround I am using my own custom stats.
instead of
Code:
_guzzlrPlatinumDeliveries
_guzzlrGoldDeliveries
I am using custom tracking of
Code:
_guzzlrPlatinumDeliveriesStarted
_guzzlrGoldDeliveriesStarted

Also worth noting that we do need to know deliveries completed total (not today though) since we need 5 bronze to unlock gold and 5 gold to unlock plat. And also for spading the tablet bonus compared to deliveries made total.
So only the daily tracking should track started rather than completed.
 

gausie

D̰͕̝͚̤̥̙̐̇̑͗̒e͍͔͎͈͔ͥ̉̔̅́̈l̠̪̜͓̲ͧ̍̈́͛v̻̾ͤe͗̃ͥ̐̊ͬp̔͒ͪ
Staff member
r20141 track started gold and platinum guzzlr quests on start (not completion), tracks total number of completed quests for the day (_guzzlrDeliveries) and fixes abandoning quests not resetting props
 

fredg1

Member
Thanks! I guess you meant _guzzlrDeliveries ?

Spading for the actual impact of using the shoes on progress is on it's way (so far, I seem to be the... only... contributor... ._.)
So far, it really shows that the shoes really just make you do 1.5 the progress you'd do without them, while also "correcting" some of the minimum fight requirements (assuming that no shoes = 1, and shoes = 1.5):
[Nth delivery of the day] = [longest it will take you to find the client, if you never search with the shoes] ; [shortest it will take you to find the client, if you always search with the shoes]
[1] = [10] ; [7]
[2] = [12] ; [8]
[3] = [13] ; [9]
[4] = [15] ; [10]
[5] = [17] ; [12]
[6] = [20] ; [15]
[7] = [25] ; [17]
[8+] = [34] ; [25]

[1] = 10 exact
[2] = 12 => 11.5
[3] = 13 => 12.5
[4] = 15 => 14.5
[5] = 17 (no data)
[6] = 20 (no data)
[7] = 25 (no data)
[8+] = 34 (no data)

Even though it looks promising so far, I'd really need people to help me get data for 6 and 8 before going forward, because of how much of a wrench they throw in the whole logic.
 

fredg1

Member
*copy-pastes the text inside the parenthesis*
"_guzzlrDeliveries"
*frowns*
Da heck is wrong with _s in this font? >:|
 

gausie

D̰͕̝͚̤̥̙̐̇̑͗̒e͍͔͎͈͔ͥ̉̔̅́̈l̠̪̜͓̲ͧ̍̈́͛v̻̾ͤe͗̃ͥ̐̊ͬp̔͒ͪ
Staff member
The only thing left before we can mark this as done is the enchantments on the tablet. I'm pretty confident that the booze drop = min(50, 1 + floor(bronze/4)), but the spading spreadsheet seems to suggest we don't have a clear grasp on the others. And certainly not their caps if they have them.
 
Top