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:
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:
the dictator said:
Rather than total deliveries, maybe just _guzzlrBronzeDeliveries. That should be complete, since daily Gold and Platinum counters already exist.
Click to expand...

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();

the dictator said:
guzzlrProgress could indeed be useful, but I would expect it to stay over rollover, since you can keep a quest over rollover too.
Click to expand...
IIRC, I remember someone saying that even though a quest carries through RO, the progress made doesn't.
 
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:
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)
 
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

fredg1 said:
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
Click to expand...
alright. So it is still trackable though, just needs to be
_guzzlrDeliveryProgress
 
Last edited:
taltamir said:
alright. So it is still trackable though, just needs to be
_guzzlrDeliveryProgress
Click to expand...

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.
 
fredg1 said:
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.
Click to expand...
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
fredg1 said:
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();
Click to expand...
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"
 
taltamir said:
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
Click to expand...

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.

taltamir said:
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"
Click to expand...

Fair enough.
 
fredg1 said:
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.
Click to expand...
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
 
taltamir said:
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
Click to expand...

...you mean the pants?
 
_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:
taltamir said:
_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.
Click to expand...

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.

taltamir said:
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.
Click to expand...

That's good to know.
 
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.
 
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
 
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):
fredg1 said:
[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]
Click to expand...

[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.
 
*copy-pastes the text inside the parenthesis*
"_guzzlrDeliveries"
*frowns*
Da heck is wrong with _s in this font? >:|
 
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.
 
You must log in or register to reply here.
Back
Top