It's interesting that when I search for paladin, I get the anti-paladin help file.

Maybe my server needs an exorcism?

Any suggestions on how to deal with that?

I also noticed that there wasn't an entry for monks. At least I don't see one and it falls back to using 'monk damage'. Anyone ever write up a good one?

thanks

I realize that this is several months after the fact and that I've been posting a lot in a relatively short amount of time, but I also ran across some help difficulties and I figured I'd record the problem I found and the fix I did.

At the heart of the help approximation is the string::find function that looks for your argument inside the keyword of each help file until it finds one that contains your argument. For drmike here, he was searching for "paladin", but alphabetically the first entry that contains that argument is "anti-paladin". The fact that there is a help file with the keyword of exactly "paladin" never comes up.
For me, I was looking for a refresher on the intricacies of "redit" but was only given "credit".

Right off the bat, there's a large efficiency hit that's going to happen because the search is performed on a List of help_data structs, so the only way to be sure that there is no entry that does not precisely match the argument is to search every single one every time, because what if zzz is a helpfile?

So at line 221 of help.cpp I now have:

help_data* bHelp=NULL;
int lev, diff, bDiff=10;

So now diff will track how close each string::find is, bDiff will be the best difference so far, and bHelp will be what help file that best difference was.
My compiler didn't like it when I tried to "help_data* pHelp, bHelp = NULL;" so that is why bHelp gets its own line.

Then in the main loop, at line 258 in help.cpp I made the bulk of the changes:

  if( !(argall.compare(pHelp->keyword) ) ) // bingo
	return pHelp;

  if( ( diff = (pHelp->keyword).find( argall ) ) != string::npos ) 
  { // then the argument is somewhere in the keyword
	if(!diff) //As close to the front as possible: 0
		return pHelp;
		
	if ( diff < bDiff )
	{ // then the match is closer to the front of the word than our best case
		bDiff = diff;
		bHelp = pHelp;
	}
  }
}
return bHelp; 

Now "help redit" returns redit and "help dventure" returns adventure. If nothing is ever found by string::find, bHelp is never changed from NULL and so the usual behavior continues from there.

Sorry for being long-winded, but I wanted to properly convey the problem because I feel my solution is non-ideal. With a List, I don't see any other method that doesn't include non-ideal accuracy or N iterations being common. I could see replacing it with a Map with keywords for keys so any exact match circumvents a loop, but I'm not crazy enough to make that big of a change. Today.

Hope this helps anybody who comes across it.

I guess there's an edit timer on this forum or I would have just edit my fix.

I wasn't aware "keyword" can be a list of many keywords, and so can be much longer than 10 characters long. This makes my solution even more inefficient as, for example, "help start" will never have a diff less than ~15 or so, so it will never match exactly to break the loop, nor will it reach diff=0 to break the loop.

Anyway, for now making bDiff unreasonably big like 99 makes it so you can access help files with long keywords.