Parser is still an idiot

[air 0]

1. /me in nmdc-hubs is now treated raw info string or command of sorts. It appears to be bold green style, dubs itself to hub status string and even actually written to hub status log. Everything is okay with adc-hubs.

CDM:

Hub:    [Outgoing][-.-.-.-:411]         <AirstrikeD> /me ping|

Hub:    [Incoming][-.-.-.-:411]         * AirstrikeD ping

That is what it looks like: 2. Some built-in /commands that use /me to spam something in chat (e.g. /ratio) are broken in adc environment (again?). Haven't tested nmdc hubs though. CDM:

Hub:	[Outgoing][88.147.128.10:10000]	 	BMSG IJXP ping ME1

Hub:	[Incoming][88.147.128.10:10000]	 	BMSG IJXP ping ME1

Hub:	[Outgoing][88.147.128.10:10000]	 	BMSG IJXP /me\sratio:\s9,03\s(Uploaded:\s3,92\sTiB\s|\sDownloaded:\s444,51\sGiB)

Hub:	[Incoming][88.147.128.10:10000]	 	BMSG IJXP /me\sratio:\s9,03\s(Uploaded:\s3,92\sTiB\s|\sDownloaded:\s444,51\sGiB)

Hub:	[Outgoing][88.147.128.10:10000]	 	BMSG IJXP /me\suptime:\s17\shours\s24\smin\s22\ssec\s

Hub:	[Incoming][88.147.128.10:10000]	 	BMSG IJXP /me\suptime:\s17\shours\s24\smin\s22\ssec\s

What it looks like:

3. Despite this quite uncanny knack of forcing /commands to use adc-compatible /me instead of oldschool +me in this version, /w still uses +me by default.

4. Last but not least. Before the update i was having an entire drive for file exchange and storage purposes. So i had it share-enabled with some folders (e.g System Volume Information) disabled. Well, after upgrade i noticed the most of my share is gone and then i figured out that if i re-enable disabled folders or if i disable the drive and then enable only the folders supposed to be shared - my share becomes normal again. So i put my shared folders in another folder, unchecked the drive and then checked the new folder. I would like to know whether it is a bug or an undocumented restriction to share entire drives or anything else. I could even reproduce and printscreen it some other time if you'd need this.

[Crise 26]

1. /me in nmdc-hubs is now treated raw info string or command of sorts. It appears to be bold green style, dubs itself to hub status string and even actually written to hub status log. Everything is okay with adc-hubs.

CDM:

Hub:    [Outgoing][-.-.-.-:411]         <AirstrikeD> /me ping|

Hub:    [Incoming][-.-.-.-:411]         * AirstrikeD ping

That is what it looks like:

This first issue depends on the hub software actually... so it isn't possible for us to really fix it for everyone.

2. Some built-in /commands that use /me to spam something in chat (e.g. /ratio) are broken in adc environment (again?). Haven't tested nmdc hubs though. CDM:

Hub:	[Outgoing][88.147.128.10:10000]	 	BMSG IJXP ping ME1

Hub:	[Incoming][88.147.128.10:10000]	 	BMSG IJXP ping ME1

Hub:	[Outgoing][88.147.128.10:10000]	 	BMSG IJXP /me\sratio:\s9,03\s(Uploaded:\s3,92\sTiB\s|\sDownloaded:\s444,51\sGiB)

Hub:	[Incoming][88.147.128.10:10000]	 	BMSG IJXP /me\sratio:\s9,03\s(Uploaded:\s3,92\sTiB\s|\sDownloaded:\s444,51\sGiB)

Hub:	[Outgoing][88.147.128.10:10000]	 	BMSG IJXP /me\suptime:\s17\shours\s24\smin\s22\ssec\s

Hub:	[Incoming][88.147.128.10:10000]	 	BMSG IJXP /me\suptime:\s17\shours\s24\smin\s22\ssec\s

What it looks like:

3. Despite this quite uncanny knack of forcing /commands to use adc-compatible /me instead of oldschool +me in this version, /w still uses +me by default.

I'll look into these... although in this case the specific idiot in question would be me

4. Last but not least. Before the update i was having an entire drive for file exchange and storage purposes. So i had it share-enabled with some folders (e.g System Volume Information) disabled. Well, after upgrade i noticed the most of my share is gone and then i figured out that if i re-enable disabled folders or if i disable the drive and then enable only the folders supposed to be shared - my share becomes normal again. So i put my shared folders in another folder, unchecked the drive and then checked the new folder. I would like to know whether it is a bug or an undocumented restriction to share entire drives or anything else. I could even reproduce and printscreen it some other time if you'd need this.

There is no restrictions about sharing whole drives as far as I know but there is some restrictions about sharing windows directories... but if that restriction applies you should get a message in your status bar about it.

[air 0]

1. Before 1.3.0 the result of '/me ping' has been looking like it still does in adchpp or in uhub. The adc variant of /me is on the second screenshot. And i'd like to add that current nmdc-style /me is looking this bold and green like a system message in every nmdc hub i've laid my fingers on, be it different versions of ptokax, or be it dbhub, or even be it verli.

2. Anyways i suppose that blaming the parser is better than blaming oneself. It keeps his self-esteem at a decent level and this way preserves his sanity and mood in a good shape. =)

4. No messages. After pressing okay to close the prefs I just notice the filelist update gets started, then gets finished and then i see 120+ gb instead of 760+ and have a filelist without the folders that make up the missing 640. Then i create a new folder, physically move the share there, uncheck the drive and check the folder with my share in it - no indexing occurs, i press okay again and see my 760+ gb back online.

[air 0]

5. Literally nothing happens when 'close connection' of transfers' rightclick menu option is chosen on incoming filelist transfers (green colored ones) while the client states to be 'connecting...'.

[Crise 26]

5. Literally nothing happens when 'close connection' of transfers' rightclick menu option is chosen on incoming filelist transfers (green colored ones) while the client states to be 'connecting...'.

I don't think that is a bug, because no connection has been made at that point so there is nothing to close... well the menuitem itself could be grayed though.

[air 0]

5. Well... From 1.2.2 (or maybe i turned on something wrong in settings) while using the automatic alternative search technique apex not only tries to perform a successful TTH search but also tries to download some filelist chunks from clients that provided responds to that search to browse these filelists in background in order to match queue. And due to various reasons (e.g. having an awfully set up apex speedmod legacy client with some cheats enabled) some guys can't upload their filelist to me. So then the transfers tab becomes filled up with some dozens of Connecting...â

[Crise 26]

So that is what i wanted to ask:

5.1. How can this urge of filelist download can be enabled or disabled in settings?

5.2. Is it really necessary to still try to download such filelists when the matters of autosearches (especially ones that launched the download of these filelists) are already downloaded and eventually if the main download queue is empty?

5.3. How can i disable future file transfers with those failing-to-give-me-filelist guys?

5.1: There is an option in queue settings, "Automatically match queue for search hits" turn that off to disabled the stream of filelist requests on searches.

5.2: It is true that option could certainly use some improvement but it's an option that can also be found in other clients so that's why it's there to begin with (and yes at one time it was enabled by default, however, that is not the case anymore but of course that will not change the setting with existing installations).

5.3: Right now there is no way to do this in the client itself... perhaps with lua scripts.

[air 0]

Muchas gracias on that.

[air 0]

Moved to windows 6.1.7600 x64 two days ago and then today updated to 1.3.1 x64. So...

1. Me still gets correct oldschool parsing of /me posts in ADC hubs and incorrect system-message-like parsing of /me in NMDC-hubs. Hubsoft only changes the number of *** before the message. Could anyone please at least make /me look similar ways in ADC and NMDC?

Addendum: this also happens with /me-using /commands like /r

6. Found in 1.3.0 x64 that SID/CID conflict messages (like "xxx (sid1)has same CID (cid) as yyy (sid2), ignoring") are not only posted in status field but also rendered in chat like the system message from the above, which is not supposed to be happening because apparently this "ignoring" flood was fixed in 1.3.0 x86. This bug is still actual for 1.3.1 x64.

Screenshots will be added some time after, if needed.

[Crise 26]

Moved to windows 6.1.7600 x64 two days ago and then today updated to 1.3.1 x64. So...

1. Me still gets correct oldschool parsing of /me posts in ADC hubs and incorrect system-message-like parsing of /me in NMDC-hubs. Hubsoft only changes the number of *** before the message. Could anyone please at least make /me look similar ways in ADC and NMDC?

6. Found in 1.3.0 x64 that SID/CID conflict messages (like "xxx (sid1)has same CID (cid) as yyy (sid2), ignoring") are not only posted in status field but also rendered in chat like the system message from the above, which is not supposed to be happening because apparently this "ignoring" flood was fixed in 1.3.0 x86. This bug is still actual for 1.3.1 x64.

Screenshots will be added some time after, if needed.

6. depends on your configuration as well...

1. Well the thing is, in NMDC some hubsofts send the /me message back as * Nick message, but the client does not expect the hubsoft to do this because in NMDC chat messages are supposed to be like <Nick> message.

ie. normally a hubsoft in NMDC would be expected to return /me as <Nick> /me message... which is what the client expects, but some hubsofts try to be smart and do it differently and this makes the client behave differently.

[air 0]

1. Well the thing is, in NMDC some hubsofts send the /me message back as * Nick message, but the client does not expect the hubsoft to do this because in NMDC chat messages are supposed to be like <Nick> message.

ie. normally a hubsoft in NMDC would be expected to return /me as <Nick> /me message... which is what the client expects, but some hubsofts try to be smart and do it differently and this makes the client behave differently.

When I tested this with some decent effort in 1.3.0 this was happening in different versions of ptokax (0.4.1.0 and 0.3.5.2), in dbhub, and in verlihub. Both four hubs I've connected to seemed to give the client the string started with some stars, and then my nick. Stars quantity depends on hubsoft, in most cases there is one or two. Apex adds 3 additional stars and a space before the post and renders it bold green. And when I was using some 1.2.x apex on the same hubs (and I know at least dbhub and verli of the above hubs definitely have not been updated, vastly reconfigured or enhanced with some new hot ass plugins) - NMDC hubs' /me looked absolutely like it was in ADC and like it does look in ADC now. And it definitely has never been dubbed in status field/status log like it still does not in ADC.

I also tested oldstyle +me 5 minutes ago on that dbhub I am speaking of and my +me is bold, starry and green too. If it was +me->/me behaviour change to blame then I think +me would perform flawlessly. It ain't.

So I just have no other option but to think that something is wrong in apex. I still can get 1.2.0 and 1.2.1 and test it too if it is necessary.

[Crise 26]

Did you read this part at all, changed it a bit to emphasize the point :

ie. normally a hubsoft in NMDC would be expected to return /me as "<Nick> /me message|"... which is what the client expects, but some hubsofts try to be smart and do it differently and this makes the client behave differently.

In other words... the client regards any message without "<Nick> " at the begin as a message without a sender and hence treats it as a status message.

The reason why it may have coincidentally worked in an earlier version is because the bahaviour regarding status messages was changed.

The point, however, is that /me is not a standard part of NMDC, unlike it is in ADC... it was originally purely client side thing in NMDC. But then hubsofts started trying to be smart about it, unfortunately this was not unified smartness in that different hubsofts are "smart" in a different way (and some not at all, like ynhub f.ex. which still return the message as is, which is what the client expects). So it becomes difficult for the client to respond correctly on each different behaviour.

[air 0]

Okay. Now I got it. Excuse me my rudeness. So... How about to implement a workarond to stop hubs' being a smartass?

And regarding 6. Can you give me some extra clues?

[Crise 26]

Okay. Now I got it. Excuse me my rudeness. So... How about to implement a workarond to stop hubs' being a smartass?

And regarding 6. Can you give me some extra clues?

I can look into it, might be possible to work aeound it.

As forr 6. There is an option somewhere that affects it, don't remember exactly but it's probably the "Filter kick and NMDC debug messages" in Appearance,

[air 0]

I can look into it, might be possible to work aeound it.

As forr 6. There is an option somewhere that affects it, don't remember exactly but it's probably the "Filter kick and NMDC debug messages" in Appearance,

Turned it on. What kinds of messages does it filter exactly?

Side note: apexdc sure needs an offline guide with every option explained.

[Crise 26]

Turned it on. What kinds of messages does it filter exactly?

Side note: apexdc sure needs an offline guide with every option explained.

Basically messages that are not useful, like the one mentioned... and then some kick messages if you are an OP then you are likely to get them in OP chat as anyways, so it's not really a drawback to turn it on.

Regarding an offline guide, aside from the extremely outdated user guide in Guides section there aren't any at present... so wanna make one? :angry:

[air 0]

Never ever tried to compile a .chm, but well... I could look for it.

[Crise 26]

Never ever tried to compile a .chm, but well... I could look for it.

Doesn't necessarily have to be a chm... pdf f.ex. would work as well (although chm does have some nice search features and such)