Feature - Implemented wand-zap item in daily deeds

[Bale]

It would be nice. If you're going to do that though, there's still a tiny hurdle to adding a wand button to Daily Deeds. Mafia has no innate way to know the item number of your wand. I've been using this:

int whichwand = 0;
for i from 1268 to 1272
	if(item_amount(to_item(i)) > 0) whichwand = i;

However a wandType property containing the item number of the last seen wand would be nicer and match well with the _wandZaps preference.

wandType should be set to 0 on ascension or if the wand blows up.

 

[Veracity]

wand zap count is weird. There is no inherent limit on how many times you can zap. It gets more and more dangerous each time you zap in a day, but until you blow it up, there is no limit.

 

[slyz]

I don't think you need a property to store which wand you have, since it will be sitting right there in your inventory. There's even a findWand() function in KoLCharacter.java that does exactly what you posted

EDIT: there is no limit, but we know the first zap of the day is always safe. When the user creates his custom daily deed, he can decide if he wants to add a maxUse > 1 to his deed.

By the way, I think using a PYEC should reset _wandZaps to 0.

 

[Bale]

wand zap count is weird. There is no inherent limit on how many times you can zap. It gets more and more dangerous each time you zap in a day, but until you blow it up, there is no limit.

True, but that doesn't mean it is useless information. If someone is creating their own daily deed, then can decide how many zaps they are willing to risk each day. Most people will only zap if _wandZap is less than 1. Others would be willing to risk 2 zaps a day.

I don't think you need a property to store which wand you have, since it will be sitting right there in your inventory. There's even a findWand() function in KoLCharacter.java that does exactly what you posted

Oh. Then all that is needed is to make that function usable by a scripter so it can be used by daily deeds. Or perhaps a zap(item) function.

 

[slyz]

Since a _wandZaps preference would remove the need to check your current wand's description, I don't really see the use of an ash which_wand() function.

A boolean zap( item ) function could be nice, although the CLI command also gets the job done.

A zap daily deed could simply look like this:
$CUSTOM|Command|Zap|_wandZaps|zap <item>

EDIT: it works better with the preference

 

[roippi]

A zap daily deed could simply look like this:
$CUSTOM|Command|Zap|zap <item>

yup. although I think you meant _wandZaps for the preference.

Optionally if you don't want to hardcode it zapping a particular item, you could just have a reminder:

$CUSTOM|Text|Zaps today: |_wandZaps

 

[fronobulax]

Two old threads merged, and a bump.

How about a _wandZaps preference?

r9665

_zapCount seemed a better name to me so I used it. Code increments it by one when a wand is used and clears it when the wand blows up. Obviously invalid if zaps are done outside of mafia. PYEC use does not affect it - couldn't find an obvious place to detect PYEC usage and don't have one myself - and standard mafia processing for underscored preferences applies for rollovers and Ascension. Tested by zapping unzappables and eventually blowing up one wand.

 

[xKiv]

The zapping page also tells you how warm the wand is, that might be useful to parse (and increment _zapCount by more than 1 where appropriate).
Also, if wiki is to be believed at all on the matter, the absolute usage limit is 5 (and it guarantees explosion).

 

[fronobulax]

The zapping page also tells you how warm the wand is, that might be useful to parse (and increment _zapCount by more than 1 where appropriate).
Also, if wiki is to be believed at all on the matter, the absolute usage limit is 5 (and it guarantees explosion).

I believe the 5 limit. I was going for simple and easy so incrementing the count by one was all I tried to do. Parsing to get the wand status seems to be useful only in the case where someone has zapped outside of mafia and while that would be a nice thing to check, I'm not interested in doing it immediately.

 

[roippi]

r9665

Cool. Marking this implemented.

 

[Alhifar]

You can go up by more than one per zap, for what it's worth.

 

[Bale]

You can go up by more than one per zap, for what it's worth.

That's one reason that I once heard Veracity give for why she didn't want to use a mere incremental implementation. A proper implementation will actually parse the page text after a zap to determine how many points to increment the counter so that the use can make a properly informed decision.

The other reason she didn't implement this is because if the wand is used outside of mafia then there would need to be another page load at logon to determine if it is warm. She felt that people would rely on mafia's belief that they haven't used the wand. She's probably right about that.

I believe that discussion was on our old bug tracker. RIP.

Despite those reasons not to implement this, the new daily deeds expansion to cover absolutely everything with limited uses/day kinda required that this be implemented in some form since now people will believe they should be able to make a wand button and find it weak sauce to be told that they cannot. It would have gotten annoying to hear the uncomprehending complaint again and again.

 

[fronobulax]

I wasn't around for the previous discussion. I will confess to a certain literalism except, perhaps, in theological matters so I will note that the preference implemented counts how many times the wand was used. The number of uses does increment by a constant one. What I had missed, however, is that the probability that the next zap would explode the wand is a function of the wand's heat, not number of uses, and one use can change the heat by "more than one". So the usage count is useful for folks who want to know whether it has been used on a day, or not, but it is potentially misleading for folks who want to calculate the risk that the next use will explode the wand. As also noted, any tracking mafia does can become potentially misleading if the wand is used outside of mafia.

So do we leave things as is because "good enough is the enemy of perfect" or do we make a FR to track wand heat and eventually deprecate _zapCount? Under the circumstances do we accept the extra and usually unnecessary server hit to check wand status on login so that wand heat changes outside of mafia are detected?

 

[slyz]

I don't think the server hit at start-up is strictly necessary. Maybe we could just update _zapCount when the user visits a wand's description page, or after a zap.

 

[roippi]

The status quo of _zapCount fits 100% of my needs, as I can't ever imagine a scenario where I would make a different choice depending on if my wand had a 25% chance or a 50% chance to blow up. *shrug*

 

[fronobulax]

I don't think the server hit at start-up is strictly necessary. Maybe we could just update _zapCount when the user visits a wand's description page, or after a zap.

I was alluding to Bale quoting veracity about the server hit. That said, what the hit gives us is the ability to have _wandHeat (or whatever it gets called if and when) be set properly on login, just in case the user did use a wand outside of mafia. Detecting the heat after a mafia controlled use should not be an issue or a extra server hit.

Now that I understand the difference between wand usages and wand heat, is the difference important enough to FR?

 

[Terion]

That said, what the hit gives us is the ability to have _wandHeat (or whatever it gets called if and when) be set properly on login, just in case the user did use a wand outside of mafia.

Looking at a wand (going to the zap menu) will simply say the wand is warm if it has been used once or more that day; it won't actually tell you anything about how hot it's gotten. Unlike the screen when you zap something, and you find out how searing hot the wand has become after that use.

So you can look at the zap page at login to see if you've used your safe-zap for the day, but you can't make any guess as to the chance of failure if it says the wand is warm (beyond knowing that the chance is non-zero.)

 

[Veracity]

That said, what the hit gives us is the ability to have _wandHeat (or whatever it gets called if and when) be set properly on login, just in case the user did use a wand outside of mafia.

Looking at your wand at login to see if you zapped it outside of KoLmafia seems like a complete waste of a server hit, approximately 100% of the time. You want to parse the heat when you zap it and save it in an "_" preference? Why not - although a simple "zapped once today" vs. "not zapped today" boolean is all that any normal player will need. I can imagine a player using a wand a second time on the last day of an ascension to get the last Legend key, say, knowing that they will never NEED the wand again this run, but other than that, I think any rational player agrees with roippi: a 25% vs. a 50% chance of blowing up the wand is not going to ever affect their decision to use it.

Not that everybody is rational, but we don't need to cater to irrational gameplay...

 

[lostcalpolydude]

In UseItemRequest I see

		case ItemPool.EXPRESS_CARD:
			Preferences.setBoolean( "expressCardUsed", true );
			break;

That looks like the right place to add resetting of _zapCount.

 

[Theraze]

To add resetting? It's a daily value because it has _ in it... when else are you resetting it? When it explodes and you can't get another for 3 days, so the _ would have reset it anyways? I'm so confused...