Sergeo7

Member
 View profile  See their activity

  • Content count

    64

  • Joined

  • Last visited

Posts posted by Sergeo7

  3. Posted

    yes i don't like opne source... i don't like it so much that i've released rsx++.

    and about the cheat clients - is it bad that user know about them? so maybe ppl shouldn't know about weapon, it's also a bad thing? kinda sux because all open comminity rely on information

    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. :(

  4. Posted

    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?

  5. Posted

    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.

  6. Posted

    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.

  9. Posted

    По идее апекс создаёт файл с информацией о вылете exceptioninfo.txt, выкладывайте их содержимое сюда. Может разрабы обратят внимание.

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

  10. Posted

    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.

  11. Posted

    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:

    1. User select newly added directories in share manager and call custom menu item "Add to feed", which calls dialog for the feed element description;
    2. 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.
    3. User open ApdexDC webserver page and click on those short links or use some external aggregating resource;
    4. 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.

  12. Posted

    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.

  15. Posted

    Они там вроде ничего такого серьёзного в сетевом коде не поправили, разве что активнее юзают неблокирующие запросы и обработчики чуток переработали.

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

  16. Posted

    every string that goes outide the core is in utf8 - no matter if this comes from adc or nmdc :) and when sending, nmdc decode it (adc leave it as is). imo best solution :)

    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																			

)

  17. Posted

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

  20. Posted

    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.

  21. Posted

    i.e. If I download a file from anothjer user I'm not guaranteed to show the same date of creation as part of the files meta data (look yourselves at the properties of files you have downloaded).

    Therefore, a bot would not be able to read an original creation date.

    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.

    I just thought of small http server in Apex, just for filelist download, I could use HFS f. ex right away. In this way slower users could select among not only two, but many filelists to download.

    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. ^____^'

  23. Posted

    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. ))

  25. Posted

    Don't understand why downloader need to select it? As I think, we had been talking about selecting proper filelist on uploader's side, depending on downloader's speed.

    If the feature is disabled then all of the functionality ignored, if enabled - we must globally disable DC-emulation and create second filelist with dates. This filelist we will upload only to users who has, for example, >5 in connection field.