Feature - Rejected current_pvp_stances().count() == 0
- Thread starter 3_D
- Start date
I just tested this. I have no interest in participating in PvP this season, but I figured I could break my hippy stone, try this out, and then ascend.
I caught it all in a DEBUG log:
Before breaking my hippy stone:
I broke my hippy stone <- You don't get to see stances if you haven't done this.
I pledged to a clan <- You don't get to see stances until you do this.
I see no bug.
Perhaps PeeVeePee request could give an informative message if:
- You haven't broken your stone
- You haven't pledged to a clan.
but nothing has changed in KoLmafia's ability to parse pvp stances.
I caught it all in a DEBUG log:
Before breaking my hippy stone:
Code:
> ash current_pvp_stances()
(Requesting: peevpee.php?place=fight)
(Response says I need to break my hippy stone)
Returned: aggregate int [string]I broke my hippy stone <- You don't get to see stances if you haven't done this.
I pledged to a clan <- You don't get to see stances until you do this.
Code:
> ash current_pvp_stances()
Returned: aggregate int [string]
Bilge Hunter => 1
Death to Ninja! => 4
Dressed in Rrrags => 11
Karmic Battle => 6
Letter of the Moment => 2
Liver of the Damned => 5
Most Murderous => 8
Pirate Wars! => 3
Purrrity => 7
Scurvy Challenge => 0
Smellin' Like a Stinkin' Rose => 10
Thirrrsty forrr Booze => 9I see no bug.
Perhaps PeeVeePee request could give an informative message if:
- You haven't broken your stone
- You haven't pledged to a clan.
but nothing has changed in KoLmafia's ability to parse pvp stances.
Why do you think that?
current_pvp_stances() tells you what it learned by visiting the “start a fight” page in Huggler.
We now know there are 3 ways that KoL will refuse to tell us the stances.
Currently, we shrug and give you an empty array.
Which serms reasonable, since you are completely unable to start a fight in any of those 3 situations.
What do you want? An error message telling you WHY you can’t start fight - and an empty array of stances, just as now?
Or do you want KoLmafia to give you an array of stances - which you cannot actually use to start a fight - even though KoL refuses to tell us what they are?
You decided to change this to Bug: Confirmed.
What is the bug? What are you expecting?
3_D
New member
Well yes. I might conceivably want to know the names of the stances, even after I have no fites left for the day. That's how this started.
You could mark it Will Not Fix, I'll never be able to gainsay you. Or it could be documented somewhere that this is intended behavior.
Last edited:
basic lihc
Member
you may always want to make decisions based on stances, like to increase scores or to decide to break the hippy stone,
since KoL shows no stances from the fight page in some cases I would expect the stances to be instead gathered from Information Booth
"peevpee.php?place=rules"
they might be spelled differently. I think in previous season one page had "Pirate Warrrs!" and current_pvp_stances( ) had "Pirate Wars!"
since KoL shows no stances from the fight page in some cases I would expect the stances to be instead gathered from Information Booth
"peevpee.php?place=rules"
they might be spelled differently. I think in previous season one page had "Pirate Warrrs!" and current_pvp_stances( ) had "Pirate Wars!"
Uh huh. And that has exactly what to do with scripts? A script is going to decide to do those things based on the (changing every season) names of stances?
current_pvp_stances() returns a map from string -> integer
The string is the name of the stance on the dropdown on the fight page.
The int is the option number that you need to use in the URL to submit a request to fight with that stance.
The names from the info booth do not always agree with the names on the dropdown.
I also think I recall that the order of stances does not always match, either.
Considering that we cannot guarantee the same result by going to the info page rather than the fight page. you need to modify your expectation.
basic lihc
Member
Yes. as an example, if your script is making a choice to use or save a daily effect like "friars", you may have it make a different decision if it finds one of the known recurring names for stances based on "food drop", "familiar experience", or "booze drop", because friars give an effect for each
perhaps users should take current_pvp_stances() to mean usable pvp stances and visit the info page themselves if they want current pvp stances. int [string] format does not necessarily impose this because unlike stance names which may always be of interest, the correct order/stance numbers only matter when fight requests can be made. but the non matching names would be more bothersome
Are these real scripts or theoretic scripts?
If they're theoretic scripts, they can check the info page themselves using visit_url(). This will in fact be slightly more useful, because it'll give the descriptions too.
If they're theoretic scripts, they can check the info page themselves using visit_url(). This will in fact be slightly more useful, because it'll give the descriptions too.
Also, the stance names from the fight page are exactly what you need to use for the “pvp” command - and everywhere else in KoLMafia that cares about stance names.
Our (my) view is that the “info” page is for human eyes to look at - not something that concerns KoLMafia itself.
If your script wants to process data from the “info” page, go right ahead! It’s not a restricted URL.
But I think it is unlikely that KoLMafia will provide an interface to the “info” page. That is easily done in a script.
And, meta-comment: users can write a Bug or a Feature Request, but it is solely the responsibility (and privilege) of the Devs to classify it further: Confirmed, Not a Bug, Won’t Fix, Fixed, Implemented, Rejected. I tend to mark Bugs as Fixed and Features as Implemented, but others wait for the OP to confirm it is fixed.
Which is to say, it is not your call to declare a bug as “Confirmed”. In fact, this “Bug” is not “Confirmed”. I think it is “Not a Bug”, since the ASH function specifically requires looking at the Fight page in order to return what it is contracted to return.
Our (my) view is that the “info” page is for human eyes to look at - not something that concerns KoLMafia itself.
If your script wants to process data from the “info” page, go right ahead! It’s not a restricted URL.
But I think it is unlikely that KoLMafia will provide an interface to the “info” page. That is easily done in a script.
And, meta-comment: users can write a Bug or a Feature Request, but it is solely the responsibility (and privilege) of the Devs to classify it further: Confirmed, Not a Bug, Won’t Fix, Fixed, Implemented, Rejected. I tend to mark Bugs as Fixed and Features as Implemented, but others wait for the OP to confirm it is fixed.
Which is to say, it is not your call to declare a bug as “Confirmed”. In fact, this “Bug” is not “Confirmed”. I think it is “Not a Bug”, since the ASH function specifically requires looking at the Fight page in order to return what it is contracted to return.
Unless the Bug is that KoLmafia doesn’t throw you into an error state with an appropriate error message about why it cannot retrieve stances based on the three possible failure reasons.
I might agree with that, but I’m not sure it’s worth my time to code that up - especially absent DEBUG logging showing all the error cases, which would let me write tests.
I might agree with that, but I’m not sure it’s worth my time to code that up - especially absent DEBUG logging showing all the error cases, which would let me write tests.
3_D
New member
was how I worked around it, yes. (also, what is the difference between a real and a theoretic script?)
agree.
Elaborate?
Sorry, I didn't mean to step on your shoes there by relabeling, didn't know it was reserved power.
seemed genuine at the time, sounded like you were acknowledging me.
Last edited:
A real script is a script you've actually written, and are experiencing problems with. A theoretic script is a script you haven't written, but think that somebody might theoretically write in the future, so you're spitballing potential solutions to a problem you don't actually have.
I prefer to fix problems in real scripts, because as part of writing a real script you've considered other solutions (which you don't have to for a theoretical script, because it doesn't exist), and you know whether your ideas are viable or not (because you have to try them).
I prefer to fix problems in real scripts, because as part of writing a real script you've considered other solutions (which you don't have to for a theoretical script, because it doesn't exist), and you know whether your ideas are viable or not (because you have to try them).
And at least one of the devs is willing to spend a lot of time discussing and/or defending against theoretical situations, to the detriment of the community and sometimes codebase
Going to mark as Won't Fix - please feel free to parse the info page in your script.
It might be possible to do what you're suggesting in a way that works for the codebase, but it might be better to discuss that in the comments of the PR you make rather than here for now.
It might be possible to do what you're suggesting in a way that works for the codebase, but it might be better to discuss that in the comments of the PR you make rather than here for now.