Github Bot
Poster of Commits
What's Changed
- BasicScope obsolete comments by @fredg1 in #499
- Add Preference to Suppress the Dialog for items with malignant status effects by @BadHorseMonkey in #501
Full Changelog: r26151...r26152
View on Github
r26152 - BasicScope obsolete comments by @fredg1 in
- Thread starter Github Bot
- Start date
Full Changelog: r26151...r26152
View on Github
I just noticed this in the source.
1) What was the motivation for it? Can you point me to a Bug Report or something?
2) It is extremely badly named, since it suppresses all "message display" things - the large bulk of which have nothing whatsoever to do with "malignant status effects".
3) The property is not in defaults.txt.
github.com
1) What was the motivation for it? Can you point me to a Bug Report or something?
2) It is extremely badly named, since it suppresses all "message display" things - the large bulk of which have nothing whatsoever to do with "malignant status effects".
3) The property is not in defaults.txt.
Add Preference to Suppress the Dialog for items with malignant status effects by BadHorseMonkey · Pull Request #501 · kolmafia/kolmafia
Creates a new boolean preference "suppressNegativeStatusPopup". If true, the Description frame that shows the status results in the SwingX GUI is not displayed. If not present or false,...
github.com
the motivation was the swing GUI popup on using a Seal Tooth, which had been reported a few times. The example below is just one such.
If we want to revisit it (or if you want me to revisit it), Im happy to do so. Are there changes you'd like to it?
I could make it more tailored, I could rename the pref, I could add it to defaults as empty/false, I could do other things...
Bug - Not A Bug - gCLI command "use seal tooth" always opens a documentation window (unexpectedly)
via user burrows, but I'm seeing the same thing. > use seal tooth Using 1 seal tooth... You acquire an effect: Bloody Hand (3) Finished using 1 seal tooth. As far as I can tell, use type in items.txt is message/combat reusable, which is a combination unique to the seal tooth (item #2). It...
kolmafia.us
If we want to revisit it (or if you want me to revisit it), Im happy to do so. Are there changes you'd like to it?
I could make it more tailored, I could rename the pref, I could add it to defaults as empty/false, I could do other things...
I hope you don't think that showing me a bug report in which I, personally, explained why I had implemented the "message" use-type and why I, personally, had put it on seal tooth - and which I, personally closed as "Not a Bug" - will be a particularly compelling justification of why you did exactly what I told you I did not want to be done. *side-eye*
1) I have no idea who "burrows" is. Apparently, they couldn't be bothered to write their own bug report and explain what, exactly, the issue is. There does appear to be a user with that name here, who joined more than two years after you wrote that bug report.
2) Perhaps they jumped to the conclusion that they got a popup because it gave a bad status effect? Even though none of the scores of other items that give a bad status effect pop up a message? Even though literally none of the other items with a "message" type give a bad status effect?
3) So the property name "suppressNegativeStatusPopup" is talking about something which doesn't actually exist. It is a bug.
4) So the description in Preferences - "Suppress popup dialog for items which cause harmful effects" - is talking about something which doesn't actually exist. It is a bug.
5) A seal tooth is a combat item. It works fine in combat and does not print a message. You can also "use" it and gain a status effect with which you can make a familiar larva. I can't imagine why somebody would do that more than once. I can't imagine why somebody would care that we show them the use message, the one time they use it.
6) The popup message is not a dialog. It does not require you to acknowledge or dismiss it. It has an OS-specific close button.
I'd like this to go away. No property. Nothing in Preferences. Nothing in UseItemRequest. It is already not in defaults.
If it REALLY causes inconvenience to people (pro tip: it does not.), we can talk about changing "message" to "usable" for that item.
But, man - I explained why I implemented "message" and said that I was happy with it the way it is, and two years later, you override me.
1) I have no idea who "burrows" is. Apparently, they couldn't be bothered to write their own bug report and explain what, exactly, the issue is. There does appear to be a user with that name here, who joined more than two years after you wrote that bug report.
2) Perhaps they jumped to the conclusion that they got a popup because it gave a bad status effect? Even though none of the scores of other items that give a bad status effect pop up a message? Even though literally none of the other items with a "message" type give a bad status effect?
3) So the property name "suppressNegativeStatusPopup" is talking about something which doesn't actually exist. It is a bug.
4) So the description in Preferences - "Suppress popup dialog for items which cause harmful effects" - is talking about something which doesn't actually exist. It is a bug.
5) A seal tooth is a combat item. It works fine in combat and does not print a message. You can also "use" it and gain a status effect with which you can make a familiar larva. I can't imagine why somebody would do that more than once. I can't imagine why somebody would care that we show them the use message, the one time they use it.
6) The popup message is not a dialog. It does not require you to acknowledge or dismiss it. It has an OS-specific close button.
I'd like this to go away. No property. Nothing in Preferences. Nothing in UseItemRequest. It is already not in defaults.
If it REALLY causes inconvenience to people (pro tip: it does not.), we can talk about changing "message" to "usable" for that item.
But, man - I explained why I implemented "message" and said that I was happy with it the way it is, and two years later, you override me.
Making blood-faced volleyballs was pretty common while the diabolic pizza cube was in Standard -- if you made a pizza with a familiar, you got familiar equipment for your current familiar. This was a good way to get the Pocket Professor equipment for +2 lectures.
Also blood-faced volleyball is an easily accessible long named item which means that the pizzas gave more adventures.
@Veracity I added a preference and didn't make it a default so that it didn't impact anyone who did want the behavior you wanted. You asked if there was a bug report. That was one. This is another: https://kolmafia.us/threads/use-seal-tooth-opens-window.25830/#post-161201
I didn't understand that as "don't change it", but rather "don't call it a bug, it's working as intended."
At the time you said "That is such old content, it's probably pointless to display the HTML any more. But it certainly is not a "Bug" that it displays it; it is working as intended."
Let's roll it back.
I didn't understand that as "don't change it", but rather "don't call it a bug, it's working as intended."
At the time you said "That is such old content, it's probably pointless to display the HTML any more. But it certainly is not a "Bug" that it displays it; it is working as intended."
Let's roll it back.
PR for rollback. I asked you to review.
github.com
Rollback of pref for suppressing messages by BadHorseMonkey · Pull Request #1855 · kolmafia/kolmafia
see: https://kolmafia.us/threads/r26152-basicscope-obsolete-comments-by-fredg1-in.27175/
github.com
FWIW, I made the other report. And it was because I was making blood-faced volleyballs every run (maybe every day?) during the Pizza Oven Times. And while it was workable, it sure was inconvenient to have windows pop up during my automated runs.
Maybe this should have been discussed in 2009, when I implemented the "message" type for items.
KoL has a bunch of things which give you a cute "message" when you use them but otherwise have no particular effect. wind chimes, for example. I figured if you troubled to use them, you'd want to see the message.
For that matter, I also set up to show you the message when you grow a familiar, since that is also cute - and it is literally something you get to see exactly once per familiar. Somebody decided that was "annoying", so that was commented out. That means that every time I use a new familiar, these days, I go to the Relay Browser and do it manually, so I can see the "once ever per familiar" message.
This is a "fun" feature, not a "serious" feature.
Apparently, KoLmafia is only for "serious" things, these days.
This PR caught my eye, because there is an open PR which, among much bigger things, marks all the "mixed drink with a fly in it" items as "message". If you try to drink one, KoL fails and tells you that you change your mind. I.e., it gives you a cute message.
We don't actually support that, yet. I'm thinking we should, but now I see that if we do, we're probably just setting ourselves up for bug reports from the humorless. Which is strange, since "humor" is SUPPOSED to be one of the things that people like about KoL.
KoL has a bunch of things which give you a cute "message" when you use them but otherwise have no particular effect. wind chimes, for example. I figured if you troubled to use them, you'd want to see the message.
For that matter, I also set up to show you the message when you grow a familiar, since that is also cute - and it is literally something you get to see exactly once per familiar. Somebody decided that was "annoying", so that was commented out. That means that every time I use a new familiar, these days, I go to the Relay Browser and do it manually, so I can see the "once ever per familiar" message.
This is a "fun" feature, not a "serious" feature.
Apparently, KoLmafia is only for "serious" things, these days.
This PR caught my eye, because there is an open PR which, among much bigger things, marks all the "mixed drink with a fly in it" items as "message". If you try to drink one, KoL fails and tells you that you change your mind. I.e., it gives you a cute message.
We don't actually support that, yet. I'm thinking we should, but now I see that if we do, we're probably just setting ourselves up for bug reports from the humorless. Which is strange, since "humor" is SUPPOSED to be one of the things that people like about KoL.
Nor anybody’s, these day.
Why is that relevant?
Is it because that is a frame which can be used to show Kol’s response to a submitted request? Sort of like a ShowDescriptionFrame, but referring to it as a “mini-browser” rather than as a “ShowRequestFrame” has extra baggage, or something?
Why is that relevant?
Is it because that is a frame which can be used to show Kol’s response to a submitted request? Sort of like a ShowDescriptionFrame, but referring to it as a “mini-browser” rather than as a “ShowRequestFrame” has extra baggage, or something?
Maybe it's not, or not for this discussion. I was trying to suggest that my way of playing wasn't the only way of playing and people who do use the mini-browser might not be as surprised by the method of displaying the message.
I also always want the funny/cute messages. For me, the gCLI would be a better location.
TBH, if we moved it, we'd probably find people who thought it was too much there.
I also always want the funny/cute messages. For me, the gCLI would be a better location.
TBH, if we moved it, we'd probably find people who thought it was too much there.
Here is what right-clicking on windchimes in InventoryManager and asking for KoL description gives you.
Here is what "using" windchimes in InventoryManager gives you.
They are both in a "mini browser" in that it has a URL - which you can edit - and it shows the HTML response to that request in a window which can display HTML.
If you "never use a mini browser", then that means you "never ask KoLmafia to show you KoL's description of an item (effect, familiar, ...)"
Do you ever receive gift packages? Those also are like "message" items, insofar as when you "use" them, it pops up a Documentation window, just like the others, showing you who sent it, what it contained, and what the inside message is.
You never do any of those things? OK. Suit yourself - but I bet you are a rare bird, in that respect.
Here is what "using" windchimes in InventoryManager gives you.
They are both in a "mini browser" in that it has a URL - which you can edit - and it shows the HTML response to that request in a window which can display HTML.
If you "never use a mini browser", then that means you "never ask KoLmafia to show you KoL's description of an item (effect, familiar, ...)"
Do you ever receive gift packages? Those also are like "message" items, insofar as when you "use" them, it pops up a Documentation window, just like the others, showing you who sent it, what it contained, and what the inside message is.
You never do any of those things? OK. Suit yourself - but I bet you are a rare bird, in that respect.
I have no problem with reverting this.
There are users who prize unattended automation above all and thus prefer to opt in to anything that stops automation. Until the similarities with asking for the KoL description were made clear to me I had a vague question as to whether this feature was misunderstood as having implications for automation.
I have, upon occasion, shut down KolMafia and the relay browser and found windows still open, almost always containing a KoL description of an item that I had asked for. If the window were there and I had not asked for it there might be a case for not displaying it and thus not making me close it afterwards. But that could also be handled by making sure all windows were closed when the relay browser was closed and/or KoLmafia was shut down. When phrased like that it sounds like a lot of work for very little gain.
There are users who prize unattended automation above all and thus prefer to opt in to anything that stops automation. Until the similarities with asking for the KoL description were made clear to me I had a vague question as to whether this feature was misunderstood as having implications for automation.
I have, upon occasion, shut down KolMafia and the relay browser and found windows still open, almost always containing a KoL description of an item that I had asked for. If the window were there and I had not asked for it there might be a case for not displaying it and thus not making me close it afterwards. But that could also be handled by making sure all windows were closed when the relay browser was closed and/or KoLmafia was shut down. When phrased like that it sounds like a lot of work for very little gain.
The issue is, if an item is usable, we show it on the Item Manager, and you can “use” it from there. If its only effect is a funny message, we either show it, or the user says “I clicked and nothing happened. Wha?”
One could argue that since a seal tooth gives you the Bloody Hand effect, THAT item has sufficient feedback, and we could mark it usable, rather than message.
It would have been nice if any of the people who were “annoyed” with seeing the message had troubled to post why they were intentionally getting Bloody Hand repeatedly.
(Were I to re-enable showing the funny messages when you put a familiar in your terrarium, I guarantee Legacy of Loathing players would point out that you can now grow the same familiar once per ascension, rather than once ever, and it is “annoying” to have to see it more than once.)
One could argue that since a seal tooth gives you the Bloody Hand effect, THAT item has sufficient feedback, and we could mark it usable, rather than message.
It would have been nice if any of the people who were “annoyed” with seeing the message had troubled to post why they were intentionally getting Bloody Hand repeatedly.
(Were I to re-enable showing the funny messages when you put a familiar in your terrarium, I guarantee Legacy of Loathing players would point out that you can now grow the same familiar once per ascension, rather than once ever, and it is “annoying” to have to see it more than once.)
Well, I have no friends who are still playing, so I don't get gifts. I am probably rare in that respect. Most people give up before I do.
I typically view the descriptions in the relay browser by clicking on the icon and viewing the documentation in the browser window it opens. I think that @fronobulax is also using it the same way.
But yeah, I absolutely have chosen Game description from the InventoryManager frame in a Documentation Frame.
So, I'll amend my statement to say "I don't use the general menu Mini-Browser frame for adventuring tasks. And when I am using the a documentation frame to read a description, it's an immediate response to something I've done in the GUI." So maybe that's the difference. I don't feel like it's unexpected if it's an immediate response to something I clicked.
Which, if I am using a seal tooth from the swing UI, then I'm in the gui and I can see and close the dialog after reading the cute message. If it's in a script, I don't think I want a popup in the swing UI when I come back at the end of the script. I don't know if that's a usable difference in behavior to act on.
I typically view the descriptions in the relay browser by clicking on the icon and viewing the documentation in the browser window it opens. I think that @fronobulax is also using it the same way.
But yeah, I absolutely have chosen Game description from the InventoryManager frame in a Documentation Frame.
So, I'll amend my statement to say "I don't use the general menu Mini-Browser frame for adventuring tasks. And when I am using the a documentation frame to read a description, it's an immediate response to something I've done in the GUI." So maybe that's the difference. I don't feel like it's unexpected if it's an immediate response to something I clicked.
Which, if I am using a seal tooth from the swing UI, then I'm in the gui and I can see and close the dialog after reading the cute message. If it's in a script, I don't think I want a popup in the swing UI when I come back at the end of the script. I don't know if that's a usable difference in behavior to act on.
UseItemRequest.parseConsumption(String responseText, boolean showHTML)
That second argument determines whether "message" things will pop up a window for you.
As coded, UseItemRequest.processResults - which is called only if it's actually a UseItemRequest, as opposed to a GenericRequest or a RelayRequest, say - calls that with "true". Since InventoryManager calls a request of that type, you get the popup window. A "use" command - called by scripts - also uses such a request.
I can see why a script doesn't need a popup window.
Let's see:
- DrinkItemRequest, EatItemRequest, and SpleenItemRequest - called by UseItemRequest - do not get the showHTML argument.
If we implement "message" for those - like the cocktails with a fly - they should get that argument.
- gift packages ignore showHTML and always assume true. Considering we log the sender - which we SHOULD do before parsing the results, since it would be nicer to log the sender before the gift - it is not clear that showHTML should be non-optional.
We could jigger things so that showHTML defaults to false, but can be overridden by UseItemRequests from the ItemManager, but not from scripts.
See, this is what we should have discussed in 2009 (or earlier) when this functionality was first implemented.
That second argument determines whether "message" things will pop up a window for you.
As coded, UseItemRequest.processResults - which is called only if it's actually a UseItemRequest, as opposed to a GenericRequest or a RelayRequest, say - calls that with "true". Since InventoryManager calls a request of that type, you get the popup window. A "use" command - called by scripts - also uses such a request.
I can see why a script doesn't need a popup window.
Let's see:
- DrinkItemRequest, EatItemRequest, and SpleenItemRequest - called by UseItemRequest - do not get the showHTML argument.
If we implement "message" for those - like the cocktails with a fly - they should get that argument.
- gift packages ignore showHTML and always assume true. Considering we log the sender - which we SHOULD do before parsing the results, since it would be nicer to log the sender before the gift - it is not clear that showHTML should be non-optional.
We could jigger things so that showHTML defaults to false, but can be overridden by UseItemRequests from the ItemManager, but not from scripts.
See, this is what we should have discussed in 2009 (or earlier) when this functionality was first implemented.
The other pop-up window you wind up seeing a lot is Degrassi Knoll shopping list: if you have philter set up to deal with items, then each ascension the first run will throw away the shopping list, and you'll get another window.
Personally, I don't care for the window popping up (both because it's a flash and because it's an extra thing to close when I close Mafia), but would be happy with the text appearing in the CLI (and logs).
I think it would be nice to have the familiar-terrarium text appear in the CLI log as well.
Personally, I don't care for the window popping up (both because it's a flash and because it's an extra thing to close when I close Mafia), but would be happy with the text appearing in the CLI (and logs).
I think it would be nice to have the familiar-terrarium text appear in the CLI log as well.
Here's an experimental PR that doesn't show the messages if you "use" (eat, drink, ...) an item from a script, but continues to pop up the Documentation window if you do it through the GUI.
I suppose that showItemUsage could be augmented to extract the text and write it to the gCLI and/or logs, if showHTML is false.
I also would like the grow-my-familiar text to always go to those places.
Those things could be follow-ups, if we want them.
github.com
Items with the "message" type display an amusing message when used and are not consumed.
I suppose that showItemUsage could be augmented to extract the text and write it to the gCLI and/or logs, if showHTML is false.
I also would like the grow-my-familiar text to always go to those places.
Those things could be follow-ups, if we want them.
items display message only if used from GUI by Veracity0 · Pull Request #1859 · kolmafia/kolmafia
Items with the "message" type display an amusing message when used and are not consumed. Allow "message" as a secondary attribute. A "drink with a fly in it", N. O. B...
github.com
Items with the "message" type display an amusing message when used and are not consumed.
- Allow "message" as a secondary attribute.
- A "drink with a fly in it", N. O. Beer, Otarian Battle Scar are all drinks that are undrinkable. Make them drink, message
- gloomy black mushroom and oily golden mushroom are foods that are inedible. Make them food, message
- Add showHTML field of a UseItemRequest to control whether we'll pop up a documentation frame to display KoL's funny message. This defaults to true.
- The "use" command (and its synonyms: eat, drink, chew) - as well as functions in the RuntimeLibrary which are implemented using the CLI command - get a UseItemRequest (or subclasses) and specify that showHTML is false.