It looks like you're new here. If you want to get involved, click one of these buttons!
Hi...Could anyone help me about this? I have searched inc. in old forum but have not found or got any usefull similar post.
I have set ApexDC++ to check clients in my hubs (connection time outs, fake share, bad/illegal files in share, etc...) and corresponding raw commands to be sent as actions according to result of those checks, like warn, drop, kick, tempban, ban...
Problem is, in all of them, be it YnHub, Ptokax or Flexhub, at least within NMDC (and also NMDCS) protocol, the hub reacts as having received the raw command two times (showing in mainchat, also in opchat or feed, doubled reporting, first one showing the full raw, with action and reason for it, the second just the raw action without the reason...), this leading not only to at least doubled reports of that single raw but also causing hubsoft problems, as it reports error with "second" command ("...Command failed ... user already being disconnected", "user not found" or "...not in the userlist", etc...), even triggering error in hubbot script (Leviathan in Ptokax, for instance)...
By the way: before, i was still using RSX++ to take care of those OP tasks, without this problem, there was no double reporting, no such problem at all, only with Apexdc++ (as i intend to transition and delegate this work to a more updated, maintained/developped and, surely, consequentially, secure DC++ client/OP client as this one...) i am having this weird behaviour now...system is a windows 10 virtual machine in a Synology home NAS, running those hubsofts (Ptokax, YnHub, FlexHub) and dc++ clients (one to OP tasks on those hubs and another to plain normal dc++ client sharing and downloading on another hubs too...)
(In ADC protocol, i still don't know if that's happening or could happen, as i am still struggling to get raws set/translated to that protocol (new for me, as a newbie with flexhub or any other than nmdc protocol, windows hubsofts...), nevermind at least really working (lol)... but that will also be a matter for other post, probably...)
Any help, any idea?
Thanks in advance
Comments
Assuming you are speaking of ADL search here, I have looked at the code and ApexDC only sends one Raw command when ADLSearch hits are checked (the one with the highest set priority) during automatic checking.
Can you check the outgoing commands in CDM Debug window to actually verify that the exact same command is sent twice? If you use the same action for multiple sources (i.e. something outside of ADLSearch), I would recommend temporarily creating a copy that mentions the source (somewhere within the command itself, e.g. in the reason sent to user) so you can identify which source triggers the second command being sent.
Edit: for the record I have not looked at the "Operator tools" of ApexDC in literally years, because I presumed no-one was using them (they are ineffective imho, with the exception of ADLSearch specifically). Ostensibly though the way they work should be very similar to RSX, because both clients use effectively the same implementation.
Thanks for comment...
But, in fact, i was talking about raws sent when checking client, not yet ADLsearch...just connect time-outs, kick/tempban for fake share, that was what i saw, for now...didn't yet got to that point (adlsearch), just still on checking user on connecting to hub.
Hope it will do as you say, with adlsearch, but i suspect it will be the same thing, as it happens just by sending a raw command like the ones i said...
As about CDM debug window, thanks for remembering me of that, i will check it out, could be more a hubsoft side thing (although it's strange that happening with 3 different hubsofts and just with this client and not another one...)
Anyway, going to check and tell something if usefull...
Thanks
By the way...
Raw command used for connection time-out, as an example:
<%[myNI]> !drop %[userNI] %[userCS]|
(maybe i will have to change userCS to another more specific variable, i think i am going to write some more raws to be used for those various reasons (one for time-outs, another for fake share, and so on) according to the raw commands variables guide in the old forum...)
And, yep...it seems apex sends command twice, just as i said: first with reason, second just the command...
In this case, in YnHub as an example i caught (probably same in the other hubs), the CDM shows two lines:
...
(my nick) !drop (user nick) connection timeout ten times|
(my nick) !drop (user nick) |
...
And later two corresponding lines of reports of user being dropped...
Mainchat showed two lines reporting as previously posted, and feed reported idem as said before.
Funny thing, for the same reason, another client using connection time-out detection (in this case FlyLinkDC++), in same hub and with another user, did also disconnect user for that reason:
in Flylink mainchat and feed showed just one line reporting dropping user,
in Apex CDMdebug showed just one line telling user was disconnected by the (flylink nick),
but mainchat and feed (in Apex) also showed two lines reporting...
Note: for both and in both cases, mainchat shows first "connection timeout 10 times", then those lines i posted about.
Another difference (but that's possibly a thing to check with the way the raw command is set/written in flylink) is that:
while in Apex there is a first report with the reason for the raw and then just the command in the second line, as stated previously,
with flylink the report just shows that the user was dropped but with no reason showed in either main, feed (in either Apex or Flylink) or CDMdebug (in Apex)...
(probably just the raw not well written, a point about raws already discussed, too, in the forum, but i think probably not related with this issue here...)
Go figure, eh...?
Note that if you have multiple raw commands checked for 1 action in favorite hub properties, in that case all commands with a check mark will be sent. That is, however, the only instance in which the client will deliberately send multiple commands (because you are telling it to do so).
i have set just two commands (for now) to drop, choosen for each/according to type of hubsoft: one for client, another for adlsearch (i mean, one raw for dropping on connection time-out - client check, another for drop on defined to drop action in adlsearch, for example if finding a not allowed file, reason to drop but not enough to kick or (temp)ban...)
so, i think they are not conflicting (still, at least at this point in the checking process...)
or am i wrong in this and really, after all, the drop command triggers both of them (even if set for different checks...)?
If so, maybe then i will have to split into severall more commands (raws) with different and specific names...is it?
like one named timeout, another filedrop, etc...
Thanks for your help and the ideas you gave me, i am going to try that out (lot of work awaiting for me, lol...)
Thanks, really...
(although, by the way, flylink is set the same way with drop command "menu" with those 2 sub-items (Client and ADLsearch)...and did not show this behaviour, it seems...anyway, different clients, different implementations of settings, command behaviour, favourite hub settings and such, so that could be the reason for it...)
Thanks again for your efforts, i will try to work on it and post any usefull upcomings later, when possible (i.e. when i have the time to get this done and working to check it out...lol me too have a time consuming job, not much left to work/play with this "hobby"... )
Edit!...
sorry, checked and indeed i was wrong in part of my previous post:
In fact, in flylink raws are set in favorite hubs settings, there is only one raw there for each command (drop, kick, etc...) for each hub, so maybe that is it, the reason for all this mess...
I should have really said it in relation to RSX++, that one is wich indeed had those raw commands settings structure, drop command set with "sub-menu" of client and adlsearch raws...
Anyway...