hearmeneigh / fchat-rising

A heavily modded F-Chat 3.0 client for F-List
https://hearmeneigh.github.io/fchat-rising/
MIT License
40 stars 18 forks source link

Age matching rework #70

Open BakaVermeil opened 2 years ago

BakaVermeil commented 2 years ago

This is a proposal/discussion for the changes on my branch https://github.com/BakaVermeil/fchat-rising/tree/agematching.

I've noticed in personal experience that age matching results in an erroneous NO result more often than not. Especially in cases where one party has a missing or invalid age set.

This changes several things in concept regarding matcher.ts: (Note that I have absolutely no type script familiarity. I live in C++/C#/Python.)

It adds an age_max property to CharacterAnalysis. And correctly parses cases in which someone has set a single number, or a - separated age range, (20 and 20-40 are now both acknowledged.) The old Age property now serves as the minimum age value.

It completely redoes resolveAgeScore() with a more, personally, correct age matching that should result in less failures. Previously someone who lacked any of the four age kinks usually ended up with a result of NO, instead of no comparison. Unless the comparators profile had no age entry.

The main thing is hopefully more robust failure catching, resulting in a Neutral result rather than a No result. The second is a complete redo of how the UA and Ageplay kinks are handled.

If a character is UA, that is the only thing the comparison cares about. First checking for the other persons UA kink, then if that can not be found for their Ageplay kink at a reduced level. The threshold for UA is now <18. (As I've had several encounters muuuuch more concerned with the legal requisites in the US and UK especially, than the moral range.) Also Ageplay traditionally refers to the Roleplay in BDSM. (But many people do not use it this way, hence the reduced weighting but still using it.)

Overall I'm looking for feedback/discussion and erm, I'm pretty sure the code won't run as is. I don't have a dev environment set up to test with. And have had massive issues getting one working under windows.

BakaVermeil commented 2 years ago

Just to note, I am not exactly sure if my solution here solves a second way of getting wrong matches. image This is with my profile having an X to Y set, where the X is recognized (using the current release version of fchat) while the other person has No UA, Ageplay, Older or Younger character kinks set at all. Blank for our purposes. Yet it matches as NO.

DemonPriestessSahala commented 2 years ago

First checking for the other persons UA kink, then if that can not be found for their Ageplay kink at a reduced level. The threshold for UA is now <18. (As I've had several encounters muuuuch more concerned with the legal requisites in the US and UK especially, than the moral range.) Also Ageplay traditionally refers to the Roleplay in BDSM. (But many people do not use it this way, hence the reduced weighting but still using it.)

My main concern is that a significant percentage of F-List does not use the kinks this way. I've only ever encountered one person who used Ageplay in the BDSM sense of an adult roleplaying a child, rather than as a euphemism for That Which Shall Not Be Named. In my general experience (which includes watching ads in major public channels), the latter is a far, far, far more common use of the kink. I don't think it deserves reduced weighting.

Also in my general experience, it's much more common for the UA kink to be omitted entirely and for Ageplay to be set (or for profiles to mention using the Ageplay kink as a litmus test) than vice-versa. This doesn't invalidate your experience by any means - it's entirely possible that we frequent different corners of the site. But it points to the fact that usage is far from uniform or well-defined. It may or may not be possible to code around that, and the idea of applying relative weights for these without user input is concerning.

The threshold for UA is now <18

I can see your point here. Rather than hard-coding any value at all, it seems better to present an input to the user asking for a value. "What's UA for you?"

I think you should start smaller than a complete rewrite. Fix or suggest one thing at a time and see how it does. Obvious errors first and separate out the preference issues for individual discussion, That way, your non-contentious items aren't held up by discussions of others.

Thank you~

BakaVermeil commented 2 years ago

My main concern...

Fair shout, and a "What's UA for you?" setting would indeed be the perfect solution! (Out of the scope of what I can achieve with the code however unless I get a working environment going.)

I think you should start smaller than a complete rewrite

Also fair, though I personally think this attempt is a fairly straightforward case. One of the dozens of IFs isn't working as expected, so I redid them.

If I scratch the weighting difference between UA and Ageplay could you do a review for logic errors if the rest is in line with the project goals?

DemonPriestessSahala commented 2 years ago

There are definitely some parts of your proposal that sound noncontroversial and should sail through, assuming that they can be technically implemented. I think that's what you're referring to in your second para (the fixed IF, the straightforward case). It was really the part about getting into what criteria constitute a match that I thought might hold things up.

It adds an age_max property to CharacterAnalysis. And correctly parses cases in which someone has set a single number, or a - separated age range, (20 and 20-40 are now both acknowledged.) The old Age property now serves as the minimum age value.

The issue with age ranges absolutely sounds like it needs to be fixed. Special characters and unusual user intents in fields like that are usually where the interesting edge cases pop up.

Previously someone who lacked any of the four age kinks usually ended up with a result of NO, instead of no comparison. Unless the comparators profile had no age entry. The main thing is hopefully more robust failure catching, resulting in a Neutral result rather than a No result.

That also sounds like a bug to me. Making the result no-comparison sounds like a good way of handling this.


I had a second on a break to think more about the questions raised in the original issue and the request in your last comment. May I please request some clarification first?

Let's define some shorthand to make this conversation easier (regardless of how people are actually using or interpreting the corresponding kinks):

With that out of the way, we're back into propositional calculus. If I understand you correctly, these would be the use cases (and please correct me if I'm wrong):

Each of these is going to be represented by some combination of kinks. But, in theory, this can be reduced to two checkboxes and a box to fill in your threshold value, which isn't a lot of UI clutter. That way, you could turn on the combination that matters in your world and turn off what doesn't matter, and then set your own threshold for morals, comfort, and legality.

If these checkbox names match up to the kink names (or close enough), then it's clear to people exactly what kinks they're filtering on, however they might be using that information.

With that clarity, the person writing the code wouldn't have to divine and interpret a user's intent or how that might set multiple underlying criteria. That seems like it would get rid of the relative weighting problem entirely, along with some of the logic questions.

How does that sound as a concept? Am I on-target with your use cases?

ETA; Going back to look at the exact text associated with each kink, it appears we're only talking about two specific kinks - please correct me if I'm wrong and you think the other three in that section are also important. I say two because they are the ones that mention or involve sexuality or thresholds.

Forgive the crudeness of the mockup. I haven't finalized my recommendation on the wording. image

I made the threshold value box separate from the age boxes above because those define who you want (or are willing to play with). This one defines who you don't want (or even potentially want to see).

Thus, it stands that we might apply a different weight to characters matching under this number (which you probably want red if you have this box checked) than we might for the one above (which might be simply yellow for less desirable). Correct me if you think there are circumstances where we could use the lower limit box above instead.

BakaVermeil commented 2 years ago

The issue with age ranges

Yeah, the Age Range thing is a trick I see often enough to find worthy of support. It does require users to copy and paste the - into the field on the site. But ultimately, works.

That also sounds like a bug to me.

Hopefully to be resolved now. :D

Let's define some shorthand

Agreed with the definitions. Two observation from personal experience:

Users who have UA set to a level are clear on what that means.

Users who have AP set to a level might mean UA, or AP. But there is no way to tell the intent. My personal experience leans towards them being more open to UA in general.

With that clarity, the person writing the code wouldn't have to divine and interpret a user's intent

I am hesitant to rely on client specific features. After all there is no guarantee that the person you are comparing your own profile with is aware of it. Sane defaults need to be assumed here.

My personal idea for that, which is in the PR was to do the following: If UA is present, that takes precedence. If it is not, but their profile is UA, then we use Ageplay at a reduced level to allow some flexible matching with people that fall under my second observation.

It is in my opinion better to match generously, than to return a miss match. "You like AP, so maybe you don't hate UA, so we will show the profile with a 'hesitant about'".

I made the threshold value Instead of the check boxes, perhaps a description of how matching works could work as well? "Ages below this number will be considered UA. Your UA Kink determines how these profiles are matched. Or if missing, your AP kink will be used."

The reasoning behind my hesitance is just that, lets be honest, most people don't check settings menus.

Overall though I think we're pretty much agreeing on the direction to take!

BakaVermeil commented 2 years ago

ETA; Going back to look at the exact text associated with each kink, it appears we're only talking about two specific kinks

Yes, only AP and UA are relevant here I think. Older/Younger seems silly within the context of UA as well. (UA maybe, but Younger in Favorites should really not impact the consideration.)

I have been thinking about making Older/Younger a flexible range based on your own profiles age. With the range growing as your character becomes older. But the default 8 years is close enough to be functional for the people that have non-UA profiles.

DemonPriestessSahala commented 2 years ago

I agree that we're probably more agreed than not, and certainly more than before.

Sane defaults need to be assumed here.

Sanity? On F-List? :D I think the sane default is to make no assumptions at all - not to care what the intent was (either for the profile reader or the profile writer). It's impossible to know why or what it means to any one person. What we do know is that they made the filter list because they're controversial, so we shouldn't read in any deeper meaning. Let's do what we're told by the user, kink by kink in this case, and don't filter otherwise.

Or if missing, your AP kink will be used.

The other reason I listed the four cases was to understand what situations we have to treat differently regardless of how we got there. For example, to handle case 1 (AP but not UA) or case 2 (UA but not AP), you can't really fall back from one kink to the other because these are the people who see some meaningful difference between them. Falling back only works for the people who treat them together: cases 3 and 4 (neither and both).

It is in my opinion better to match generously, than to return a miss match. "You like AP, so maybe you don't hate UA, so we will show the profile with a 'hesitant about'". perhaps a description of how matching works could work as well

I think this might be where the confusion is creeping in. There's matching in the sense of match score for the purposes of kink comparison (where a match means turning things shades of green, yellow, and red, and thus promoting something as compatible). And then there's matching in the sense of smart filters (where a match means to hide or adjust the match score for something you have said is incompatible).

Since English is not my first language, that was one of the more confusing aspects when I started to use Rising, and I still catch myself tripping up here from time to time. For the sake of clarity, to which of those two senses are you referring?

I am hesitant to rely on client specific features. most people don't check settings menus.

If this were on the stock client, I would absolutely agree with you 100%. But I think most/all of the people who use Rising made the change because they want what's in those settings menus. Otherwise, they would have stuck with the stock clients.

BakaVermeil commented 2 years ago

Sanity? On F-List? :D

I know I know! :D But I do think more people use AP to mean UG than not, so that's probably fine? More importantly since those too lazy to bother setting kinks, probably don't check app options either. But fair shout.

I think this might

(where a match means turning things shades of green, yellow, and red, and thus promoting something as compatible)

This is the feature I use on a daily basis. Primarily when someone messages me, to check compatibility at a glance. And when browsing the LFRP channels, to primarily read ads marked green. However because of mismatch (read: incompatible comparison) many ads are shown in Red, purely because of age.

I do not use the toggle that hides incompatible ads, or messages from incompatible users.

If this were on the stock client, I would absolutely agree with you 100%

^.^ We could, print the changelog to the console the first time a new version is opened and tell users about the new feature? And then "sane defaults" are... UA starts at below 18?

Glendening commented 2 years ago

If I may put in my two cents related to this and the general of false positives. You might have already said this so at worst i'm reinforcing it. From my personal user experience.

-Triggering a no when an entry is missing leads to many false negatives. -Lack of entries in the list (fave/yes/maybe/no) should trigger a maybe instead of a no. That should go the same for details like age, species, and others. If the entry is completely missing it shouldn't default to no and thus if ad filtering is turned on, filter out their ad. -I personally would rather have extra maybes rather than lots of extra false yes/nos.