Feature - Rejected Fixing CCS monsters to match what the user sees vs. what mafia knows about

So during the El Dia de Los Muertos Borrachos!

I was seeing Encounters like this (example copy and paste from the Encounter listing):

<html>Combat: El Novio Cadáver (1)</html>

As a typical user, I would expect to be able to cut and paste this "El Novio Cadáver"
into the CCS to take special action against that monster type.

If I do this, the monster name in the CCS is changed to:

[ el novio cadáver ]

So ok, I see that the some transformations have happened to the name. I see that the special
character has been translated, and the el has been lowercased.

However, when posting a bug report to this list, I find out that "el"'s and "la"'s from the holiday
monsters have been removed.

So I would like to suggest that el's and la's be stripped from the name in the CCS so that a
typical user won't have to post bug reports to figure out what is wrong with the name.
 
Last edited:
The problem with stripping bits is that SOME monsters do actually have the articles as part of their names. TPTB love to keep things consistent.
 
Are you really sure though that "The Man" is never going to fuzzy match something else that uses "man" somewhere in its name and comes sooner/later in the alphabet?

If people want to fuzzy match, they have that option now. But if you set it in your CCS, it should do what you tell it to... further muddling of your settings seems bad.
 
The problem with stripping bits is that SOME monsters do actually have the articles as part of their names. TPTB love to keep things consistent.

I'm not suggesting to just generically strip it off every time.. I would expect that you would see if it's one of the monsters you are supposed to strip it off from...

I guess what I am suggesting is similar in a way to the way regex matching works for skills in the CCS.

For example, I can type "skill noodles" and CCS translates it to:
"skill entangling noodles".

So maybe you could do this for monster names too?
 
But you're asking for it in the other way. To make your example match the request, you're asking for using "skill el entangling noodles" and have it work. Which it doesn't.
 
But you're asking for it in the other way. To make your example match the request, you're asking for using "skill el entangling noodles" and have it work. Which it doesn't.

so if a complete "monster name" doesn't match, you could then parse each word in the name of the monster individually and try to attain a match, if you get a match, you could add another word and see if you
still get a match, so if I typed "a goth giant" you could try matching "a" which would fail, "goth" which would hit, and then "giant" which would hit many, and so then you combine the hits "goth giant" and see
if you get a match there. If I typed "the goth giant", "the" would match, as in "the man", "goth" would match, and "giant would match" but "the goth" would not match, and "goth giant" would still match.
 
Last edited:
You know this was pretty easy to fix without reworking the matches. I made this change, compiled and tested it.
Maybe someone can add this in and check it in for me.
In the file:

code/src/net/sourceforge/kolmafia/combat/CombatActionManager.java

In the function
<code>
public static final String encounterKey( String line, final boolean chan
geCase )
</code>

Add this to the end of all the other else if's

<code>
else if ( key.startsWith( "el ") )
{
key = key.substring( 3 );
line = line.substring( 3 );
}
else if ( key.startsWith ("la ") )
{
key = key.substring( 3 );
line = line.substring( 3 );
}
</code>
 
Last edited:
That fixes your specific problem with this specific monster, but does not address the general issue of leading articles at all. That just causes more confusion when behavior is forked oddly.
 
I guess you don't want El Diablo to be recognized?

<code>
else if ( key.startsWith( "el novio") || key.startsWith( "la novia") || key.startsWith ( "el padre") || key.startsWith ("la persona") )
{
key = key.substring( 3 );
line = line.substring( 3 );
}
</code>

That fixes your specific problem with this specific monster, but does not address the general issue of leading articles at all. That just causes more confusion when behavior is forked oddly.

But there are already cases for "a" and "an" in that code that do the exact same thing.
 
Last edited:
I sort of like having a single CCS section that looks like this:

Code:
[ cadáver ]
section holiday monster
...which has worked perfectly for me for years, including yesterday, for all of the holiday monsters.

Of course, you have to know that you can have a section match multiple monsters, rather than having to duplicate a section for each monster...
 
I sort of like having a single CCS section that looks like this:

Code:
[ cadáver ]
section holiday monster
...which has worked perfectly for me for years, including yesterday, for all of the holiday monsters.

Of course, you have to know that you can have a section match multiple monsters, rather than having to duplicate a section for each monster...

So I like this idea too, I'm just hoping that the typical user would think of it.
 
So can we mark this FReq rejected since users can just multi-match already?

It just seems like we're adding in additional layers of complexity which only helps if you want to treat specific holiday monsters differently than other monsters even though they have the same stats. The follow-up FReq would be for matching individual hobo names, since those also show something differently in the Encounter notification than the combat log and what CCSes need. :)
 
Back
Top