Sergeo7

You haven't understood my point of view at all. (Don't even try to, actually.) But I agree, this goes too far.. so EOT too.

А нет возможности, что это происходит из-за сбоев, вызванных, скажем, разгоном, перегревом или другим багом от железа?

Please, don't take it personally, but I know at least one side client developer that shared modified source with others just to comply with GNU/GPL ideology in the eyes of the public. And yes, community relies on information, not on some "funny" remarks. Did you provide any useful information? Or did you just pushed side developers to think about how can they use cheats? Those who really wanted to find out about cheat clients are already aware of it, you know. PS: It's certainly goes almost offtop, sorry. :(

You certainly have knew, it's just I don't appreciate your sarcasm about modifications. Cheating clients are already exist, so what? Maybe you writing specifications or developing some reliable code to prevent it? Or don't you like the whole idea of open source? Or why do you bring this up at all?

adrian_007: It's all in human nature - where exist possibility to do a good deed, arm in arm goes possibility to do a bad one. It's not that all side developers aim to create cheat-mods though.

You can apply some modifications and see how it works or can try to fix bugs to help developers. The main idea is not just to compile ApexDC, but to examine the source-code, modify it for your own preferences and maybe even learn from it.

And it will be good if alternate BG color can be specified. With some color schemes default color looks very bad.

А файл ApexDC.pdb в каталоге программы присутствует? Если да, то странно, что он пуст.

По идее апекс создаёт файл с информацией о вылете exceptioninfo.txt, выкладывайте их содержимое сюда. Может разрабы обратят внимание. На счёт стронга, его код копируется в апекс практически без изменений, в апексе только свои фичи добавляют. Так что если вылетает апекс, вероятнее всего, соответствующий билд стронга тоже будет вылетать. Хотя обновления стронга становятся доступны раньше. %)

I don't mean that. Maybe my english is so bad. :thumbsup: I had talked about legitimate capturing of text messages by plugin and via plugin API and redirecting them to external server for further displaying in AJAX or flash chat and vice versa.

I think the API subsystem must be updated further to implement this idea by supporting such things as custom(i.e. plugin provided) command line options or some interface to existing, item custom menus/custom toolbar buttons, custom webserver pages, possibility to add/remove downloads via API (it's possibly unsafe idea, but still) etc. For example there will be the following way: User select newly added directories in share manager and call custom menu item "Add to feed", which calls dialog for the feed element description; Plugin parse marked directories, generate short download links and put them on it's web server page/RSS output (there may be even some external php or other RSS/news aggregator to put together releases from different clients); Those links can look like this: adc://just.hub.addr/UserName?dl={ReleaseShortLink}. Maybe there is a way to use existing magnets system for this, directory magnet links for example. User open ApdexDC webserver page and click on those short links or use some external aggregating resource; The client (it will connect to hub if needed) recognize this link and put associated directory to the download queue. For now there are no possible solutions for this within apexdc plugins idea. And for finding newest files automatically client certainly must support source file creation timestamps in a file list. But this idea somehow unpleasant to the developers of apexdc/strongdc.

If you thought about using internal server, then current API implementation won't support such a thing. Otherwise one can easily capture incoming and generate outgoing chats in a plugin and exchange them with any external webserver you want.

В Advanced-Security поснимать все галки. Ещё можно попробовать не использовать настройки предыдущего клиента, а запустить апекс "с нуля", т.е. в каталоге без подпапки Settings.

Всё в настройках, не ленитесь смотреть.. для самого высокого приоритета по дефолту идут такие установки - *.sfv;*.nfo;*sample*;*cover*;*.pls;*.m3u (см. исходный код апекса), ни о каких *.wv там и речи не шло.

Они там вроде ничего такого серьёзного в сетевом коде не поправили, разве что активнее юзают неблокирующие запросы и обработчики чуток переработали. Попробуйте отключать шифрование и всё, что с ним связано и посмотрите как там с эмуляцией DC.

I think so too. That mess with the different encodings in some places is really troublesome. When will you release this patch to a public? BTW can I ask if the next idea will ever work with this? Somehow data (3-byte kanji characters) were transmitted and utf-8 encoding were restored in spite of NMDC-hub, but the only place, where they displayed correctly, was status-bar. --// skipping superfluous code.. dcpp:setListener( "ownChatOut", "encodeUTF8", function( hub, text ) DC():PrintDebug( " ** Sent: "..text) if string.find( text, "[^%z\1-\127\194-\244][^\128-\191]*") then DC():SendHubMessage( hub:getId(), "<"..hub:getOwnNick().."> "..DC():FromUtf8(utf8_url_encode(text)).."|" ) DC():PrintDebug( " ** Encoded: "..text) return 1 end end ) dcpp:setListener( "chat", "decodeUTF8", function( hub, user, text ) DC():PrintDebug( " ** Received: "..text) if string.find( text, "%%([a-fA-F0-9]+)%+") then text = url_utf8_decode(text) --Displays 3-byte chars incorrectly in the main chat, (2-bytes still ok). DC():InjectHubMessage( hub:getId(), "<"..user._nick.."> "..text ) --Displays correctly. DC():PrintDebug( " ** Decoded: "..text) return 1 end end )

This is my "most needed feature" for the time being. It'll be very useful to have possibility of sorting files/dirs in filelists by date and time of creation and will help to create autonomous bot of new releases. PS: Since all filelists are in XML, I don't think that it'll affect clients compatibility.

У афтаров апекса своя политика по этому вопросу, если не устраивают такие пределы изменения настроек, юзайте альтернативные клиенты или каким-либо образом сделайте свою сборку, такие вещи даже непрофессиональным программером меняются в 2-3 клика мышью.

Резервная копия папки Settings решает.

Improved: Further improvements to the plugin system What specifically has been changed in the plugin system?

1) Reading file dates is much much faster process than hashing so, if you move files, updating this property won't take a long time. 2) We have discussed possibility to disble feature for those who don't need it up to now (maybe even disable by default). 3) It's NOT time when you shared the file but the time when it was created on HDD these are a way too different things. 4) Some file managers allow preservation of creation date upon moving. Plus moving some persistent files over a HDDs isn't frequent event.

It's just a matter of agreement how programs should treat a file attributes. But in fact you miss the point. I had been talking about getting this data from uploader's side, so downloader can sort file-list by date or use some kind of date/time analysis, e.g. for downloading newest files in share. For example someone have a folder with 1000 files you like, from which you downloaded all. Next time you go to the same folder and see 1200 files. Assuming that previous files you had deleted or they are not in your share now, how can you know which files you need? If there is a date of creation you can just sort by it and see if there are files created approximately after last visit and download them. At present for such task you need to keep/memorize previous files - which is really inconvenient. Or simply add an additional protocol command, that'll provide file-lists list ^__^ To go even further client can have support for several metadata sending commands for date/time, file comments, ratings, MP3-tags, attributes or whatever. ^____^'

Fight the power. Join the ADC! :thumbsup:

Sorry, maybe I was not clear enough when explained what I was thinking about. If rearrange forums again and do it like this: Main -> Support -> Subforums: Guides, English, Bulgarian / Български, Croatian / Hrvatski, Finnish / Suomi, French / Francais, German / Deutsch, Hungarian/ Magyar, Icelandic / íslenska, Italian / Italiano, Polish / Polski, Russian / Русский, Serbian / Srpski / Српски, Slovak / Slovensky, Swedish / Svenska English subforum'll be still one click away from the main page (hmm.. yes, link will be smaller in size. ^^") but other languages'll be too. No one gets hurt and all will be happy. ))

We do know what downloader set in "Line speed" and it's on his conscience if it's true or just random. And is it truly impossible to detect if client can send filelist with dates? How about adding feature to Supports/SUP list to make it visible for downloader?