Repeating is the way of the net...Largo said:
I dont want all codes gone. If our shavenheaded leader, and the rest of the Beer Owners, has some useful codes in his matchbinds, then i want to keep those.
Example would be some key words/variables should be highlighted with a common color in matches. Like putting colortag around objective, playername, locations.
E.g. Teamsay Launch successful, :&life: %health% :&msg: / :&arm: %armour% :&msg: near :&obj: %objective% :&msg: / :&loc: %location%
With :&life: etc. being newly defined entries in anemote.ini. The main problem here is that i cant get automatic message color to fit say and teamsay (usually 2 different colors). So either i have to define :&msg: for Say and :&tmsg: for Teamsay or have same color for both say and teamsay (which is a bad thing imo).
However, that would allow enemies to send messages with :&tmsg: as long as leagueas doent allow me to prevent non-teammmembers from using it OR giving me a :&msg: that is resolved to whatver i have set saycolor and teamsay color to, depending on context.
Ideally i want the last solution, with the addition of tying :&life: :&arm: :&weap: :&loc: :&obj: :&msg: :&nam: to menu counterparts (become standard codes) instead of being independent userdefined anemote entries, i.e. having entries for picking the colors for %weapon% %health% %armour% %location% %objective% and %ammo%, and letting the colordefinitions reside in anemote.
Of those, :&nam: (playername) and :&msg: (message stdcolor) would have to be resolved depending on teammate/enemy and say/teamsay, respectively.
Right now it can almost be done with anemote if the receipients have the same entries (with their own colors ofcourse) else they just get a unrecognized anemote code. Contextual resolving and blocking will have to be added to make it work properly.