AML v.4.X Series

Well once again i open the floor for developers to post thoughts on how they want this serie of AML so i don’t get bothered with this later on what should be included into the detection and what should be dismissed

in my opinion:

  1. remove that damn team flooders etc, for banning there is hubsoft
  2. some more friendly restrictions for op/non-op clients… this is stupid, when user is banned because he’s using a ‘‘op client’’ and he can’t use any features dedicated for ops (discussed many times)… more restricted clients should be w/o adc 1.0 support…

and btw, don’t use param names like Identity fields, it make just a mess, use normal ones, or at least %[paramUS] or sth

Cool anything else? i had this discussion before version 3.x and that time called for more stricter tagging at that time and im not a fan of changing course when ive started working on lists

and Adrian Reply here aswell cant start working until you do

and what i have to answer to?
TA wil give you formatted tag, ST will give you status, CO will give you formatted connection etc. simple…

SL <-- whats that
Lock ?

am i supposed to guess my way thru the whole thing ?

Thank you

Test Profile for DC++

<?xml version="1.0" encoding="utf-8" standalone="yes"?>
			<DetectionEntry ProfileID="1">
					<InfField Field="CO" Pattern="^(0\.(005|0[125]|[125])|[125]|[125]0|100(0)?)$" Protocol="both"/>
					<InfField Field="VE" Pattern="^(\+\+ )?0\.(((40([0-3]|3[2-4])|6(6[6-8]|7[0-4]))|6(8(1{0,2}|[5-9])|9([1-8]|9(5)?)?)$)|70[0-7])$" Protocol="both"/>
					<InfField Field="TA" Pattern="^<\+\+ V:%[VE],%[CSM],%[CSH],%[CSS]>" Protocol="nmdc"/>
					<InfField Field="SU" Pattern="^MiniSlots XmlBZList ADCGet TTHL TTHF (GetZBlock ZLIG )?$" Protocol="nmdc"/>
					<InfField Field="LO" Pattern="^EXTENDEDPROTOCOLABCABCABCABCABCABC$" Protocol="nmdc"/>
					<InfField Field="PK" Pattern="^DCPLUSPLUS%[PKVE]ABCABC$" Protocol="nmdc"/>
					<InfField Field="TS" Pattern="^File Not Available$" Protocol="nmdc"/>
					<InfField Field="ST" Pattern="^[12]$" Protocol="nmdc"/>
					<InfField Field="TA" Pattern="^<%[VE],%[CSM],%[CSH],%[CSS]>" Protocol="adc"/>
					<InfField Field="SU" Pattern="^((ADC0|(TCP|UDP)4){1}(,)?){1,3}$" Protocol="adc"/>
		<Param Name="DVE" Pattern="[\w\d \.]{2,10}"/>
		<Param Name="CSS" Pattern="(S:\d{1,10}(,O:\d{1,10})?)"/>
		<Param Name="CSL" Pattern="([BLURD]{1}:\d{1,10}([\.,](\d{1,10}))?)(,([BLURD]{1}:\d{1,10}(\.(\d{1,10}))?))?"/>
		<Param Name="CSM" Pattern="(M:[AP5]{1})"/>
		<Param Name="CSH" Pattern="(H:(\d{1,3}/){2}\d{1,3})"/>

in tag you can use params like H:%[HN]/%[HR]/%[HO] for hub counts

for additional fields, look at 2 src files - User.h and User.cpp


hmm and i think it’d be a good idea to add one extra field - client name (for nmdc only, this part between ‘<’ and ’ V:’) because as i see it might be a nice optimization trick (no need to match all tag at all, some mismatch can be checked in separated profile)

Well crise and me had a discussion over msn that 2 letter symbols had a change to be overwritten in the future thats why i choose 3 letters

overwritten but where? only those you’ve created or in user class at all?

const tstring hn = Text::toT(identity.get("HN"));
const tstring hr = Text::toT(identity.get("HR"));
const tstring ho = Text::toT(identity.get("HO"));
const tstring cn = Util::toStringW(Util::toInt(identity.get("HN")) + Util::toInt(identity.get("HR")) + Util::toInt(identity.get("HO")));
const_cast<Identity&>(identity).set("AH", Text::fromT(cn));
return (hn.empty() || hr.empty() || ho.empty()) ? Util::emptyStringT : (cn + _T("(") + hn + _T("/") + hr + _T("/") + ho + _T(")"));}

Does this part even exist in other client or is it RSX++ only ?

in this part only AH iss mine (AllHubs)

Okey then ill use those instead since im not that familar with the new CDM im kinda guessing but with proper documentation and help its much easier