Feature - Implemented wand-zap item in daily deeds

When you use a PYEC, _zapCount should be set to 0 because the wand gets cooled off, like what was mentioned earlier in the thread.
 
lostcalpolydude said:
In UseItemRequest I see
Code: 
		case ItemPool.EXPRESS_CARD:
			Preferences.setBoolean( "expressCardUsed", true );
			break;
That looks like the right place to add resetting of _zapCount.
Click to expand...

That's in registerRequest; it's better to parse the response and reset _zapCount if sucessful.

r9670, extremely untested.
 
Setting expressCardUsed needs to be moved too, right? Or maybe not, since it should be set even if the first PYEC use was outside of mafia, but having those in different places still seems weird.
 
Since we want expressCardUsed=true when we use it regardless of success, I don't see a functional problem with having it there. Style-wise, I dunno. There's plenty of items that exist both in registerRequest and parseConsumption, but that doesn't make it The Right Way To Do It.
 
Even if brief network issues prevent the request from getting to the server? registerRequest is probably always wrong for maintaining an accurate state under all conditions, but it's good enough 99.9% of the time.
 
Don't get me wrong, I agree with you. As much stuff as possible should go into parseConsumption, especially where synching character states is concerned. I'm not sure why I'm being obstinate on the matter.
 
lostcalpolydude said:
Even if brief network issues prevent the request from getting to the server? registerRequest is probably always wrong for maintaining an accurate state under all conditions, but it's good enough 99.9% of the time.
Click to expand...
Well... it's tough. I intend to, eventually, submit a developer doc on "how to handle a request".

In the perfect world with no network errors, registerRequest logs what you are attempting in the session log, and parseResponse looks at the result, decides what really happened, and updates KoLmafia's internal state - inventory, settings, local variables, whatever - to reflect that. That is especially important if the request can fail because of something you did outside of KoLmafia; if you assumed success in registerRequest, parseResponse has to detect the failure and (perhaps partially) roll back what registerRequest did. I think it's cleaner to simply modify the state after you know exactly what happened.

If you have used the express card outside of KoLmafia, using it again will fail, and you will not reset your wand - and you can detect that in parseResponse and not reset the property.

Now, laggy networks complicate things. I always run with connection timeouts (from the Login Frame's Connection tab) turned OFF. HTTP runs over TCP, which is a reliable data transport protocol and which will retransmit and acknowledge. When the system says that we have successfully transmitted a request, that means that KoL has actually received it. With timeouts turned off, only a drastic failure will cause the request to fail - and if that happens, all bets are off; KoL could have received - and acted on - the request, or it could have never received it. That's why we log "Time out during data post (url). This could be bad..." - only in the debug log, unfortunately.

We can also timeout while waiting for the response. If that happens, we don't know if it's safe to try again for things like "use" or "adventure" requests, although things like looking at inventory are safe to retry.

Now, if you turn on the LoginFrame connection option which is enticingly described as "Improve handling of semi-random lag spikes", KoLmafia will use socket timeouts to abort laggy requests sooner, rather than waiting for TCP to detect the catastrophic failure. This might make KoLmafia get a timeout after seconds, rather than minutes - but if the network is just Real Slow, the request could very well have gone through and we'll be in the "This might be bad" situation of not knowing what state KoL itself is really in. I'm not sure if that Connection option is a Feature or a Bug; I refuse to use it.

If you have socketTimeouts turned off, doing all the work in parseResponse is clearly correct, since KoLmafia will always wait until it gets the response and it will update state to agree with what KoL itself says happened.
If you have socketTimeouts turned on, neither doing the work in registerRequest nor deferring it to parseResponse is guaranteed to leave your state correct if a timeout happens, but if we did everything in registerRequest, even timeouts during the request would not be catastrophic; you wouldn't be tempted to retry things that would be dangerous to repeat - using items, say - since the item would (seemingly) be gone from your inventory.
 
You must log in or register to reply here.
Back
Top