Page 1 of 1
Spawn.CleanName - not clean enough
Posted: Fri Sep 24, 2004 7:00 pm
by morevit
One of the first macros I made when I started using MQ2 was an assist macro. I was using it in an LDoN and it worked fine until we came upon a named. My macro (using the target's CleanName) output something like "Assisting OurTank with #Whirling Pain in the Ass". I'm still trying to figure out what the "#" indicates. At first I thought it indicated the mob had something in its hand (and that may still be true) but I've had mobs with the indicator drop nothing. Anyway, this isn't something you want to be displaying to the general public. I quickly rewrote the macro to work around the problem but still...
Posted: Fri Sep 24, 2004 9:50 pm
by oneoneone
The # is something you'll find around "Named" mobs in some zones. Not all zones/named use the #, but some do, including LDoN's. Its something Sony labels the mobs as, not something MacroQuest does.
Posted: Fri Sep 24, 2004 10:38 pm
by Amadeus
I have this fixed ...will put it in for the next zip.
Posted: Fri Sep 24, 2004 10:44 pm
by Shwei
Bah, and I spent a whole 5 minutes on
Code: Select all
/docommand ${If[${Target.CleanName.Left[1].Equal[#]},/say ${Target.CleanName.Right[${Math.Calc[${Target.CleanName.Length}-1]}]},/say ${Target.CleanName}]}
Posted: Fri Sep 24, 2004 11:33 pm
by Rusty~
i've just been using ${Target.DisplayName} over ${Target.CleanName}
Posted: Sat Sep 25, 2004 12:51 am
by morevit
Amadeus wrote:I have this fixed ...will put it in for the next zip.
Thanks

Posted: Sat Sep 25, 2004 12:53 am
by morevit
Rusty~ wrote:i've just been using ${Target.DisplayName} over ${Target.CleanName}
Bah. I'll look at this, but "DisplayName" is not in the docs and may well go away. (I have verified that it exists and that you aren't insane, but my statement stands).
Posted: Sat Sep 25, 2004 5:15 am
by Rusty~
i saw it used in MacroQuest.ini for custom spawn labels.. it's basically just the name that shows about the spawn's head

Posted: Sat Sep 25, 2004 6:27 am
by Cr4zyb4rd
After poking around at the code a bit, DisplayedName comes straight from the spawn's struct. It's the string pointed to in memory whenever the client itself displays the name of a mob (as the name might suggest). This is probably what you most often want to use in your macro output as its what other people in the game are going to see.
CleanName is just the mob's "real" name (also a member of the spawn's struct) ran through the MQ function CleanupName(), which simply removes any numbers, changes _ into a space, and (most important) moves any articles (the, a, an) to the end of the string. This last bit is what allows you to do searches for "orc battlemaster" and get a match even though the mob is technically named "the orc battlemaster". It's mostly for MQ's internal use (as in the output of /npc) or when you want to make the display look pretty on your end.
I don't think any change to the source is needed (I'd hate to see the # stop showing up on /npc lists) but I do believe a change to the documentation is in order. I'll PM wassup and bring this thread to his attention.
Posted: Sat Sep 25, 2004 7:35 am
by morevit
Fair enough. If DisplayName is what I'm looking for and it gets documented that should solve the problem.
I think you may have been looking at the wrong code though. CleanName does _not_ move the article though there may be an internal routine with the same name that does or perhaps there's a flag. I'm afraid I haven't had as much time as I'd like to pour over the MQ2 code yet.
Posted: Sat Sep 25, 2004 1:15 pm
by Amadeus
I am making a modification to CleanupName() that allows it to take 3 arguments for times when we want to strip the '#'.
It doesn't break anything else in the code and fixes the CleanName datatype.
Posted: Sat Sep 25, 2004 7:37 pm
by Cr4zyb4rd
I think you may have been looking at the wrong code though.
I quite wasn't.
CleanName does _not_ move the article though there may be an internal routine with the same name that does or perhaps there's a flag
Yes, CleanupName takes a flag to remove the article. Much as I described in my post...