Как сделать контекстное меню для команды?

Допустим, у вас есть команда !rules, по которой показываются правила хаба, команда !hubs, по которой показываются хабы сети и команда !radio, по которой показываются транслируемые через сеть радиостанции. Вы хотите, чтобы эти команды можно было вызывать из контекстного меню хаба.

API 2:


API 1:

Как по команде сделать показ сообщения (например правил хаба)?

1. Открываем папку, где располагается файл PtokaX.exe, и заходим в папку texts.
2. Создаём в этой папке текстовый файл.
3. Переименовываем этот файл (например в имя rules.txt)
4. Открываем его, и пишем сообщение (например правила хаба)
5. Ищем в настройках хаба настройку: "Включить текстовые файлы" (В старых версиях настройка находится во вкладке "Настройки" справа. В новых версиях в "основных настройках" - "Больше настроек"). Там же можно (если необходимо) установить отправку этого сообщения в приват.
6. Для старых версий там же в настройках нужно перезагрузить текстовые файлы (или просто воспользоваться командой в чат !reloadtxt).

Всё готово и по команде !rules можно будет увидеть правила хаба.

Таким образом можно создать любые текстовые сообщения по команде. Например, можно сделать правила, сайты, хабы сети, информацию для операторов и тд. и тп.

Что такое MOTD или как установить сообщение при входе?

MOTD - это сокращение от Message Of The Day. Переводится как "Сообщение дня". Показывается при входе на хаб. Для старых версий PtokaX устанавливается на первой вкладке. Для новых версий устанавливается в настройках. Для отсылки данного сообщения в приват нужно установить галочку: "Отправлять сообщение дня в приват".

Как сделать отсылку сообщения пользователю при входе на хаб?

Простейший код реализации отсылки сообщения в чат пользователю при входе:

API 2:

API 1:


Простейший код реализации отсылки сообщения в приват пользователю при входе:

API 2:

API 1:

Где скачать хаб PtokaX?

Читаем внимательно тут: http://mydc.ru/topic19.html

В данной теме будут описываться часто задаваемые вопросы. Прежде чем писать очередной пост, посмотрите нету ли решения вашей проблему в этой теме!!!

Итак, поехали...

Где скачать хаб PtokaX?
Как сделать отсылку сообщения пользователю при входе на хаб?
Как прописать абсолютные пути?
Что такое MOTD или как установить сообщение при входе?
Как по команде сделать показ сообщения (например правил хаба)?
Как сделать контекстное меню для команды?
Как запретить скачивать и искать на хабе незарегистрированным?
Как запретить пользоваться чатом и личкой на хабе незарегистрированным?
Как написать функцию оповещения об ошибках скрипта?
Как запретить символы в нике для определённых профилей?
Как изменить выводимые в чат ники пользователей?
Как сделать действие по команде?
Как сделать приветствие с указанием времени суток?
Есть ли скрипт статистики скачивания на хабе?
Как сделать оповещение в ОпЧат о слишком большой шаре пользователя?
Как сделать ограничения действий или добавить исключения по профилям?
Как сделать ограничения действий или добавить исключения по никам пользователей?
Как установить/удалить/запустить PtokaX как службу?
Как сделать сообщение, которое будет выдаваться при входе на хаб(Перед надписями "Этот хаб работает ...")?

Самый оптимальный:


Однако чаще всего используется не одна команда, поэтому так:

Название: addkey
Версия API: API1
Версия скрипта: 1.4.7
Автор: Sephiroth_Lukaw
Описание: Скрипт раздаёт ключики без прав.
Перенесено из раздела "Запросы скриптов".

[attachment=1448:addkey_v.1.4.7.lua]

Название: Registration
Версия API: API2
Версия скрипта: 2.0
Автор: DestroyNet
Описание: Скрипт регистрации с подтверждением.
Перенесено из раздела "Запросы скриптов".

[attachment=1446:Registration.v2.0.lua]

Название: Janus_HS_light
Версия API: API2
Версия скрипта: 1.01
Автор: Berkut
Описание: Скрипт содержит антирекламу и антимат (реализовано путём замены фраз).
Перенесено из раздела "Запросы скриптов"

[attachment=1496:Janus_HS...ght_API2.lua]

Название: TestScript
Версия скрипта: 1.0
Версия API: API1
Автор: GhosTjokeR
Описание: Скрипт для прохождения тестов.
Перенесён из раздела "Запросы скриптов"

[attachment=1444:TestScript.zip]

Название: OneSend
Версия: 1.0
Версия API: API1, API2 (универсальный)
Автор: Setuper
Описание: Отсылает PM сообщение 1 раз при входе пользователя. При последующих входах сообщение отсылаться не будет.
Скрипт перенесён из раздела "Запросы скриптов".

[attachment=2353:OneSend.lua]

Название: PxSettings
Версия скрипта: 1.0d
Версия API: API2
Автор: Mutor
Язык: англ.
Описание: Зарубежный скрипт управления настройками хаба.
Скрипт перенесён из раздела "Запросы скриптов".

[attachment=1442:PxSettings1.0_API2.lua]

Название: HelloUser
Версия API: API2
Автор: ?
Предоставил: brigadir
Описание: Скрипт выводит информационное сообщение при входе (сообщение с различными параметрами: Время Хаб онлайн, Общая шара хаба, Количество посетителей, Ник, ip, шара, вклад шары, профиль, тэг, описание, email, тип соединения).
Скрипт перенесен из раздела "Запросы скриптов"

[attachment=1441:HelloUser.lua]

Название: Chat-cleaner
Автор: Svyat
Подправления: Nickolya
Сделано: 16.06.08
Версия: RC2
Лог версий:
- 16.06.08 - Дата релиза RC1
- 17.06.09 - Добавлено меню
Описание: Скрипт Очистки главного чата. Очищает главный чат хаба, посылая сообщение с большим количеством знаков переноса (\n)
Перенесено из раздела запросы скриптов.

[attachment=1439:chat_cle..._API_1__.lua][attachment=1440:chat_cle..._API_2__.lua]

Название: Kicker
Автор: Setuper
Версия API: API1, API2 (универсальный)
Версия: 1.1
Описание: Скрипт ограничения одновременных киков. Скрипт, который запрещает выделять всех юзеров и кикать. Вместо этого кикается тот, кто пытался всех кикнуть.
Скрипт перенесён из запросов скриптов и старая тема удалена.

[attachment=1438:Kicker.lua]

Вместо кода:можно писать код:
Оптимизация состоит в использовании метода вместо функции, ну и конечно же меньше символов писать (в свою очередь интерпретатор загружает данный код чуть-чуть быстрее).

И ещё обратите внимание на отсутствие внешних скобок Можно было написать так:однако, в данном случае внешние скобки можно опустить)))

Скобки у аргумента функции (или метода) можно опускать только в том случае, когда аргумент один и этот аргумент представляет из себя постоянную строку без конкатенаций.

$Sending

Синтаксис:



Если запрошенные байты равны -1, то:



Направление команды:

Клиент ---> Клиент

Описание:

Данная команда является расширением протокола. Отсылается в ответ на команду $GetZBlock, $UGetBlock, или $UGetZBlock.
Оба параметра [Начальный_байт] и [Конечный_байт] имеют номера, начиная с 0; первый принятый байт будет байт с номером 0.
Сначала, во время тестирования этой команды (GetTestZBlock), не было никаких параметров.

$GetZBlock

Синтаксис:



Направление команды:

Клиент ---> Клиент

Описание:

Данная команда является дополнением к протоколу. На поддержку данной команды указывает характеристика GetZBlock в команде $Supports.

Вместо команд $Get и $Send используется вышеприведенная команда.
Параметр [Число] начинается с 0 (именно с 0, в отличии от команды $Get, в которой данный параметр начинается с 1) и обозначает начальную точку загрузки файла.
[Число_байт] - это число отправляемых байт (или -1 для неизвестного или целого файла).
[Имя_файла] - очевидно, что это имя файла.

После этого второй клиент отвечает командой "$Sending [Байты]|[Сжатие]", если отправка прошла успешно или командой "$Failed [Описание_ошибки]|" в противном случае.

Если всё в порядке, то данные будут отправляться до тех пор пока не отошлёться вся не сжатая длина файла.
[Байты] - указывает сколько будет извлечено отосланных байт без сжатия, потому как отсылающий клиент не знает на сколько хорошо был сжат файл. Одна отсылка туда и обратно оптимизирует механизм передачи файла.

Сжатие: Для сжатия используется библиотека ZLib (v 1.1.4 в DC++ начиная с версии 0.21), использующая динамическое сжатие. Уровень сжатия может изменяться для того чтобы снизить нагрузку на процессор или в случае если файл не сжимается. Уровень сжатия регулируется с помощью хеш-функции adler32.

Команда $GetZBlock устарела, но согласно DC++ 0.696 её поддержка ещё существует. Новая реализация этой команды используется в команде $ADCGET с параметром ZL1.

лучше над этим не заморачиваться, так как для этого надо будет много написать кода))))

Вместо ip чтобы шара была делается так:




Читаем файл scripting-interface.txt, и меньше вопросов будет

В функции GetUserAllData должен быть только 1 аргумент. Удали второй.

Довольно давно на форуме летали мысли по созданию подобной темы. В данной теме предполагается раскрывать как общие методы оптимизации, которые применяются ко всем lua скриптам, так и методы оптимизации конкретных кусков кода.

Итак, немного слов о том как работает lua.
LUA - это скриптовый язык программирования, то есть для работы ему не обязательна предварительная компиляция. "Загрузка" lua кода осуществляется интерпретатором. Существуют и скомпилированные lua коды. Компиляция осуществляется с помощью инструмента luac.

Преимущества скомпилированного кода:

• Компилятор Lua способен выполнять элементарную оптимизацию. Например, он оптимизирует простые выражения с участием переменных и констант. Не обязательно заменять, скажем, выражение
  Код
  a = 2 * 34567 + b
  на
  Код
  a = 69134 + b
  Однако в открытом lua коде эту оптимизацию всё же следует производить.
• Скомпилированный код загружается интерпретатором в разы быстрее из-за того, что интерпретатору не надо тратить время на перевод скрипта в байт-код.

Основные методы оптимизации.

При разработке программ на Lua нужно иметь в виду, что компилятор этого языка не обладает широкими способностями по оптимизации. С другой стороны, интерпретатор Lua реализован очень эффективно и чаще всего обеспечивает весьма приличную скорость работы. Если же нужна сверхвысокая производительность, то мы должны сами следить за тем, чтобы в коде не было множества лишних конструкций. Добиться этого будет легче, если мы будем придерживаться нескольких простых правил при написании кода на Lua.

1. Доступ к локальным переменным в Lua несколько быстрее, чем к глобальным. Если требуется интенсивный доступ к глобальной таблице или функции, лучше завести локальную, присвоить ей значение глобальной и только потом начинать использовать. Эта техника не несет накладных расходов на копирование, так как в Lua данные таких типов копируются как ссылки, а не как значения.
   Код
   t = {"1", "2", "3", "4", "5"}
   function test()
     local temp, i = t, 0
     while i < 6 do
       Core.SendToAll(temp[i])
       i = i + 1
     end
   end
   
   
   
2. По возможности в коде, критичном по производительности, не создавай множество объектов Lua, управляемых сборщиком мусора. Такие объекты создаются при склеивании строк, вызове конструкторов таблиц (например при вызовах функций с переменным числом аргументов), при объявлении любых функций, при выполнении команд dofile/dostring. Не следует дробить строки и лишний раз использовать конкатенацию, то есть вместо кода
   Код
   "test1".."\r\n".."test2"
   следует использовать код
   Код
   "test1\r\ntest2"
   В первом случае в lua стеке до следующей уборки мусора останутся строки: "test2", "\r\n" и "test1\r\ntest2", во втором же случае в стеке останется всего лишь строка "test1\r\ntest2". Подумайте над этим! Это не пустые слова. Каждый может проверить данное утверждение, используя lua debagger.
   
   
3. Вместо многочисленных конкатенаций можно использовать метод format. Использование метода не будет оставлять много мусора. Например, вместо того, чтобы писать
   Код
   local str = "String: "..sParam1..", "..sParam2..", "..sParam3..", "..sParam4
   можем написать
   Код
   local str = ("String: %s, %s, %s, %s"):format(sParam1, sParam2, sParam3, sParam4)
   Для незначительных конкатенаций (менее 4 строк ("String: ", ", ", ", ", ", ") ) выигрыша нет, но для множества конкатенаций данный метод сэкономит память. Рекомендуется для конкатенации менее 4 временных строк использовать оператор конкатенации (..), а для множественной конкатенации использовать метод (format).
   Давайте разберём, что в данных 2 случаях записывается в мусор:
   1)
   Код
   local str = "String: "..sParam1..", "..sParam2..", "..sParam3..", "..sParam4
   В мусоре будет следующее:
   Код
   tostring(sParam4)
   ", "
   tostring(sParam3)
   ", "
   tostring(sParam2)
   ", "
   tostring(sParam1)
   "String: sParam1, sParam2, sParam3, sParam4"
   
   2)
   Код
   local str = ("String: %s, %s, %s, %s"):format(sParam1, sParam2, sParam3, sParam4)
   В мусоре будет следующее:
   Код
   "String: sParam1, sParam2, sParam3, sParam4"
   tostring(sParam4)
   tostring(sParam3)
   tostring(sParam2)
   tostring(sParam1)
   "String: %s, %s, %s, %s"
   "String: sParam1, sParam2, sParam3, sParam4"
   
   
   
4. Одним из способов оптимизации является вариант использования для строк локальных методов, вместо глобальных функций. Например, использовать метод:
   Код
   sData:find(sStr)
   вместо функции глобальной таблицы
   Код
   string.find(sData, sStr)
   
   
   
5. Перевод скриптового кода в код на C/C++ - один из действенных методов оптимизации. Если вдруг показалось, что какой-то участок кода на Lua нужно подвергнуть интенсивной оптимизации, обнаружен первый сигнал к тому, что этот кусок кода нужно переписать на C++.
   
   
6. Большинство команд протокола NMDC оканчивается на символ "|", который служит для разделения команд, когда они находятся в одном потоке или в одной строке. Поэтому эффективнее отсылать 1 раз единую строку с командами, нежели отсылать несколько раз отдельные команды.
   Код
   local t = {
     "$MyINFO $ALL nick1 $ $ $ $0$",
     "$MyINFO $ALL nick2 $ $ $ $0$",
     "$MyINFO $ALL nick3 $ $ $ $0$"
   }
   local sStr = ""
   for i, v in ipairs(t) do
     sStr = (sStr == "" and "" or sStr.."|")..v
   end
   Core.SendToAll(sStr)
   тоже самое касается и сообщений (если вместо команд отправляются сообщения).
   
   
7. Если в таблице используются только целочисленные индексы, то в цикле следует использовать функцию ipairs, в противном случае использовать функцию pairs
   Код
   local t1 = {
     "1",
     "2",
     "3"
   }
   for i, v in ipairs(t1) do
     ...
   end
   local t2 = {
     a = "1",
     b = "2",
     c = "3"
   }
   for i, v in pairs(t2) do
     ...
   end
   
   
8. По возможности используйте метод match для строк вместо метода find. В условиях (логических выражениях) используйте метод find, во всех других случаях используйте метод match.
   
   
9. По возможности подключайте файлы с помощью функции require, а не с помощью функции dofile.
   Функция require выполняет файл однажды и передаёт загруженные параметры по ссылке.
   Функция dofile выполняет файл каждый раз и передаёт загруженные параметры по значению.
   При этом стоит учитывать, что функция require ищет загружаемые lua модули по путям, которые хранятся в переменной package.path (для загрузки dll библиотек package.cpath), а функция dofile загружает файлы по полному пути, который вы указываете перед названием файла.

Управление памятью

Язык Lua автоматически управляет памятью при помощи сборщика мусора (garbage collector): интерпретатор периодически вызывает сборщик мусора, удаляющий объекты, для которых была выделена память (таблицы, userdata, функции, потоки и строки) и которые стали недоступными из Lua («мертвые» объекты).

Интерпретатор Lua задает предел объема памяти (threshold), занимаемого данными. Как только занятый объем достигнет этого предела, запускается алгоритм, освобождающий память, занятую накопившимися «мертвыми» объектами. Затем устанавливается новый предел, равный двукратному объему памяти, занимаемой после очистки.

Чтобы запустить сборку мусора немедленно, нужно программно установить предел занимаемой памяти в 0 (вызвав lua_setgcthreshold() из C или collectgarbage() из Lua). Чтобы остановить сборку мусора, устанавливаем этот предел в достаточно большое значение.

Замечено, что в некоторых случаях память, занимаемая данными Lua, проявляет тенденцию к разрастанию, что может негативно сказаться на производительности программы. Чтобы избежать этого, лучше периодически вызывать сборку мусора принудительно.

При написании программ на Lua обязательно учитывай то, каким образом интерпретатор Lua управляет распределением памяти. Сборка мусора в версии 5 — относительно затратная по производительности операция (используется алгоритм non-incremental mark and sweep). Она инициируется автоматически, когда объем выделенной памяти превышает двукратный объем памяти, оставшейся выделенной после предыдущей сборки мусора (объем выделенной памяти, при превышении которого произойдет следующая сборка мусора, также можно задавать программно). Значит, фактически, в достаточно большой динамической системе сборка мусора может быть запущена в произвольный момент времени, вызвав просадку по производительности. Чем больше памяти выделено под объекты Lua, тем дольше происходит сбор мусора.

Итак, если мы, например, читаем в Lua данные из файла построчно и склеиваешь их в одну строку линейно, скорее всего, процесс будет продвигаться страшно медленно: после каждой следующей операции склейки объем занятой памяти, как минимум, удваивается и, соответственно, запускается процесс сборки мусора.

Код создает новую строку (и присваивает ее переменной some_string), а строка, хранившаяся в some_string до склейки, остается в памяти до следующей сборки мусора:

$GetINFO

Синтаксис:



Направление команды:

Клиент ---> Хаб

Описание:

Запрос команды $MyINFO с хаба.

[Ник] - ник отправителя.
[Ник_жертвы] - ник пользователя, о котором нужно узнать информацию. Сервер должен отправить строку MyINFO указанного клиента.

$Capabilities

Синтаксис:



Характеристики:

Поддерживается: Valknut (Hub to Client)

Направление команды:

Клиент ---> Хаб
Хаб ---> Клиент

Описание:

Команда $Capabilities является расширением протокола (используется в клиенте DCGUI). Цель данной команды такая же как и у более популярной команды $Supports.

Известные Характеристики:

UniSearch
XSearch
MD4x

$ADCGET / $ADCSND

Направление команды:

Клиент ---> Клиент

Описание:

Данная команда является дополнительной клиент-клиент командой протокола NMDC, указываемая по средствам характеристики ADCGet в команде $Supports. Эта характеристика указывает на поддержку команды GET нового протокола ADC, и используется для скачивания файлов между клиентами. Команды должны выполняться после того как клиенты уже связались друг с другом и готовы получать или отдавать файлы.

ZLIG, TTHL, и TTHF - это все доступные дополнения команды $ADCGET

запрос:



ответ:



Файл-лист: запрос



ответ:



а также запрос по контрольной сумме TTH:



ответ:

$Ping

НЕ ПОДДЕРЖИВЕТСЯ КЛИЕНТОМ DC++

Синтаксис:



Направление команды:

Клиент ---> Клиент

Описание:

[IP]:[Порт] - это IP и UDP порт, который отправитель пытается прослушать.
Пинг измеряет время ожидания сигнала.
Если вы своим клиентом пытаетесь пинговать, то вы должны быть уверены в том, что данная команда соответствует протоколу NMDC v1.0 beta 9 и поддерживается другим клиентом.

$BotINFO / $HubINFO

Синтаксис:

Запрос клиента на пинг:



Ответ сервера



Направление команд:

Клиент ---> Хаб ($BotINFO)
Хаб ---> Клиент ($HubINFO)

Описание:

Данная команда нужна для получения более полной информации о хабе.

[Описание_бота] - может быть любой строкой, обычно это информация об адресе или хаб-листе.
[Имя_хаба], [Адрес_хаба] и [Описание_хаба] - это пункты, которые будут показаны в хаб-листе (некоторые хабы имеют несколько адресов это помогает определит главный адрес). Описание хабов меняется часто, поэтому требует частого обновления.
[Макс_юзеров], [Мин_шара], [Мин_слотов], [Макс_хабов] - соответственно максимально допустимое число пользователей, минимально допустимая шара на хабе, минимальное число слотов, максимальное число подключенных хабов.
[Тип] - этот параметр даёт информацию о программе, под управлением которой работает хаб.
[Владелец] - владелец хаба или email адрес владельца хаба

Если адрес хаба 127.0.0.1, то Hublist.org удалит информацию об этом хабе из своей базы данных.

Поддержка:

Данные команды поддерживаются следующими программами:

• PtokaX
• Verlihub
• Yhub
• SDCH
• PHPDC-Hub
• DB Hub >= 0.314
• GeneralBot >= 0.24 (NMDCH Script)
• HubRules >= 1.11 (DCH++ Plugin)
• HubList >= 0.1.0 (ODC(#)H Plugin)

На поддержку данных команд указывают характеристики BotInfo/HubInfo в команде $Supports
Различные хабы по разному обрабатывают данные команды, - некоторые отключают пингера после отсылки ему команды, а некоторые продолжают держать пингера на хабе, предполагая, что пингер сам разорвёт соединение с хабом.

$MultiSearch

ЧАСТИЧНО ПОДДЕРЖИВАЕТСЯ КЛИЕНТОМ DC++

Синтаксис:

Активный пользователь:



Направление команды:

Клиент ---> Хаб

Описание:

Данная команда является командой со стороны клиента для того чтобы иметь преимущество перед линкованым NMDC хабом. Клиент отсылает команду $MultiSearch на хаб, хаб, в свою очередь, пересылает команду $Search по UDP на все связанные с ним хабы, на подобие того, как команда $Search отсылается хабом всем пользователям хаба.

Данная команда используется совместно с командой $MultiConnectToMe. Поддержка этой команды была ограничена в версиях oDC. Её поддержка вызвана некоторыми проблемами. Для детального разбора проблем смотрите описание команды $MultiConnectToMe.

Описание синтаксиса параметров смотрите в команде $Search.

$MultiConnectToMe

ЧАСТИЧНО ПОДДЕРЖИВАЕТСЯ КЛИЕНТОМ DC++

Синтаксис:



Направление команды:

Клиент ---> Хаб

Описание:

Эта команда была придумана как команда со стороны клиента, для того чтобы иметь преимущество перед слинкованным хабом. Клиент отсылает команду $MultiConnectToMe на хаб, хаб, в свою очередь, пересылает команду $ConnectToMe по UDP на все связанные с ним хабы, на подобие того, как команда $Search отсылается хабом всем пользователям хаба.

Данная команда используется совместно с командой $MultiSearch. Поддержка этой команды была ограничена в версиях oDC. Было проблематично поддерживать эту команду, потому как NMDC хаб не мог контролировать все свои линкованые части и не мог транслировать соединение с удалёнными пользователями. Таким образом, oDC клиент должен был отсылать команду $MultiConnectToMe даже тогда, когда пользователь находился в оффлайне.

Пример:

$FeaturedNetworks

Синтаксис:

APN мульти-хаб-чат сообщение обычно выглядит следующим образом:



Где YYY - это префикс, XXX - это ник пользователя и MMM - это сообщение.



YYY - идентификатор хаба в сети. На настоящее время APN MultiHubChat система может иметь до 5 таких идентификаторов, а в некоторых случаях и больше.

Направление команды:

Хаб ---> Хаб

Описание:

Команда $FeaturedNetworks - это команда дополнения к протоколу Access Point Name (APN) MultiHubChatsystem, для того, чтобы определить другие хабы и другие точки входа (IRC, Telnet) и тд. Первоначально команда была создана для того чтобы помочь разработчикам APN и для того чтобы добиться лучшей интеграции между мульти-хабами.

На мульти-хабах сообщения в чат поступают с уникальными префиксами (идентификаторами), обычно длинной в 3 символа (в нике). Хаб, который получает сообщение от какого-то "своего" пользователя должен разослать его по всем остальным хабам.


Реализация:

Если хаб отсылает данную команду, то на хабе должен быть определён какой-то префикс, который будет применяться к пользователям хаба.

Префикс хаба определяет админ хаба. Однако существуют следующие префиксы:

APx - Хаб x (DC, где x - это ¹, ² или ³).
APt - Telnet доступ (Telnet Чат Плагин)
IRC - IRC доступ (IRC Плагин)
APs - Shoutcast (Shoutcast Announcer Плагин)

Команда $FeaturedNetworks может использоваться практически любым хабом или MHC ботом.

Продолжаю знакомство с ООП в LUA.

Реализация класса в lua.

• Конструкторы
• Открытые переменные и функции (public)
• Закрытые переменные и функции (private)

Использование класса cMyClass

хехе. Давайте я вам расскажу самый продвинутый способ борьбы против рекламы.

Смысл вот в чём: если хорошенько подумать, то можно понять, что избавиться от рекламы не так уж и просто, потому что если запрещаешь что-то, то юзер находит обходные пути. Тогда назревает вопрос: как сделать так, чтобы юзер не мог найти обходные пути. Ответ на этот вопрос прост: надо чтобы юзер не находил обходные пути, то есть использовал старые пути, которые уже известны. Этого можно добиться только в том случае, если у юзера не возникает потребности изобретать что-то новое.

Из всего сказанного следует простой метод борьбы с рекламой: надо уверить рекламщика в том, что его реклама успешно прошла.


Пример:

Рекламщик пытается рекламировать свой хаб: dchub://10.10.10.10

Антиреклама действует следующим образом: она рекламщику отсылает его же рекламу: dchub://10.10.10.10
А всем остальным пользователям отсылается модифицированное сообщение. Допустим установлен генератор случайных чисел и всем пользователям (кроме рекламщика) придёт сообщение: dchub://245.85.94.77

То есть мы уверили рекламщика в том, что его реклама прошла в чат, и он, успокоившись, уже не станет изобретать какие-то другие методы рекламы.

Метод реализован в проекте мульти-бота SBot.

За два с половиной года существования на моём хабе такого метода антирекламы никто не смог прорекламировать свои хабы.

$To

Синтаксис:



Направление команды:

Клиент ---> Хаб
Хаб ---> Клиент

Описание:

Эта команда используется для отправки личного сообщения.

[Ник] - этот параметр не обязан совпадать с ником отправителя (это может быть, например, бот), НО он не обязан совпадать только в случае поступления этой команды от хаба клиенту, а не от клиента хабу! При поступлении команды от клиента хабу, последний может (обязан) проверять совпадение ника с ником отправителя.
[Ник_получателя] - ник получателя приватного сообщения.

При поступлении данной команды от клиента, хаб просто транслирует эту команду в соответствующее соединение.

$Send

Синтаксис:



Направление команды:

Клиент ---> Клиент

Описание:

Данная команда посылается скачивающим клиентом в ответ на команду $FileLength отдающего клиента.
Команда просит отдающего клиента начать отдачу файла.

$MyNick

Синтаксис:



Направление команды:

Клиент ---> Клиент

Описание:

Первая команда, которую нужно послать клиенту при соединении с другим клиентом.
Команда $Lock должна быть послана вслед за данной командой.

Специфичность:

DC++ проверяет, чтобы указанный в этой команде ник был найден хотя бы на одном из хабов, в противном случае соединение закрывается немедленно.

$MCTo

Синтаксис:



Направление команды:

Клиент ---> Хаб

Описание:

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

$MaxedOut

Синтаксис:



Направление команды:

Клиент ---> Клиент

Описание:

Данная команда отсылается клиентом, когда у него нету свободных слотов.

$GetListLen

Синтаксис:



Направление команды:

Клиент ---> Клиент

Описание:

Старая команда.

Данная команда используется для того, чтобы получит размер файл-листа стиля DcLst удалённого пользователя. Удалённый пользователь в ответ отправит команду $ListLen.

Однако эта команда давно исключена из протокола. Начиная с версии 0.69, DC++ больше не генерирует списки стиля DcLst.

$Get

Синтаксис:



Направление команды:

Клиент ---> Клиент

Описание:

Данная команда используется для инициализации загрузки нужного файла. Клиент как бы просит у другого клиента файл.

[Файл] - это полное имя файла и путь к нему в соответствие с указанным в команде $SR или в файл-листе.
[Число] - начальная точка загрузки (начинается с 1, а не с 0)

Команда $Error с параметром "File Not Found" посылается когда файл не доступен. NMDC разъединяет пользователя если в запросе не указана директория. (то есть клиент отсылает команду $Error в ответ на команду "$Get не_существующая_директория\не_существующий_файл$1|" и разъединяет в ответ на команду "$Get не_существующий_файл$1|")

Когда файл доступен, источник файла отсылает команду $FileLength.

Для извлечения файл-листа служит команда:

$FileLength

Синтаксис:



Направление команды:

Клиент ---> Клиент

Описание:

Данная команда отсылается отдающим клиентом скачивающему клиенту в ответ на команду $Get. Единственным параметром является размер скачиваемого файла в байтах.

$Failed

Синтаксис:



Направление команды:

Клиент ---> Клиент

Описание:

Эта команда является командой DC++ дополнительных характеристик. Отсылается в ответ на команду $GetZBlock, $UGetBlock, или $UGetZBlock. Одним из значений параметра [Сообщение] может быть значение "File Not Available" (Файл не найден).

$Error

Синтаксис:



Направление команды:

Клиент ---> Клиент

Описание:

Эта команда отсылается когда возникает ошибка.

[Сообщение] - это строка, описывающая ошибку. Наиболее распространённая ошибка "File Not Available" (Файл не доступен), возвращается когда у запрошенного клиента не оказалось нужного файла (хотя он раньше у него был). Если вы пишете своего клиента, то учтите, что реализация этой строки может привести к несовместимости.

$Direction

Синтаксис:



Направление команды:

Клиент ---> Клиент

Описание:

Эта команда отсылается в ответ на команду $Key. Команда решает какая сторона будет скачивать.

[Направление] - данный параметр может принимать значения "Upload" или "Download". Параметр принимает значение "Upload" только в случае если ваш клиент ничего не хочет скачать с соединяемого пользователя.
[Номер] - это случайное число. Когда оба клиента хотят скачивать друг у друга, первым начинает скачивать тот, у кого это число выше. Если эти числа равны, то соединение закрывается.

Специфичность:

Максимальное значение параметра [Номер] - 0x7FFF. NMDC должен разорвать соединение, если отсылаемое число вдруг оказалось больше максимального.

DC++ может не посылать эту команду после команды $Lock, если в команде $Lock встретилось значение EXTENDED. Смотрите описание команды $Supports.

У DC++ клиентов есть следующий баг:
У клиента A ноль свободных слотов, у клиента B есть свободные слоты. Клиент B хочет скачать у A файлы, клиент A также хочет скачать у B некоторые файлы.
Если клиент A хочет получить что-то от клиента B и он посылает случайное число, клиент B не может получить слот, потому что их нет у клиента A и тогда в статусной строке появляется надпись "Соединение...". Решение этой проблемы предложено на страницах обсуждения клиента. Выход из этой ситуации осуществляется отправкой всё большего и большего случайного числа, пока не освободится свободный слот и не установится соединение.

$Canceled

Синтаксис:



Направление команды:

Клиент ---> Клиент

Описание:

Данная команда отсылается клиентом в ответ на команду $Cancel другого клиента. Смотрите описание команды $Cancel для более детального вникания. Следует отметить орфографию написания команды $Canceled, в отличии от хорошо известного слова "Cancelled."

$Cancel

Синтаксис:



Направление команды:

Клиент ---> Клиент

Описание:

Скачивающий клиент может отменить скачку с некоторых клиентов (версии NMDC Windows по крайней мере). Это делается с помощью отсылки команды $Cancel (без символа | на конце!).

В свою очередь отдающий клиент при получении этой команды должен закрыть поток и отослать в ответ команду $Canceled (также без символа | на конце). Следующий пример показывает как это работает. D - скачивающий клиент, U - отдающий клиент.



Данная команда поддерживается только в версиях NMDC 1.x. Mac и Windows NMDC 2.x версии не могут отменить передачу как это делает NMDC 1.x. DC++ никогда не поддерживал команду $Cancel или $Canceled.

Смотрите также описание команды $Canceled

исправил

$ValidateDenide

Синтаксис:



Направление команды:

Хаб ---> Клиент

Описание:

Эта команда является частью рукопожатия между клиентом и хабом. Хаб отправит эту команду клиенту в ответ на команду $ValidateNick, если такой ник уже используется на хабе, или ник совпадает с зарезервированным ником (таким как "Hub-Security").

[Ник] - это отвергнутый ник.
После того как эта команда придёт к клиенту клиент сгенерирует сообщение "Your nick was already taken (Ваш ник уже используется)" (содержание этого сообщения, вообще говоря, настраивается в клиенте).

Замечание:
Обратите внимание на название команды: $ValidateDenide, а не $ValidateDenied, как казалось бы должно быть!

$ValidateNick

Синтаксис:



Направление команды:

Клиент ---> Хаб

Описание:

Эта команда является частью рукопожатия между клиентом и хабом. Она посылается клиентом на хаб после команды $Key. Она определяет ник [Ник], который вы хотите использовать на хабе.

Внимание!
По протоколу ник не должен содержать символы: $ | и пробел.
Клиент, до входа на хаб, может преобразовывать все пробелы на нижние подчёркивания, и, таким образом, продолжать использование данного модифицированного ника.

Смотрите также:

$HubIsFull, когда хаб полон
$ValidateDenide, когда ник уже используется
$GetPass, когда для ника запрашивается пароль
$Hello, когда ник принят

$Version

Направление команды:

Клиент ---> Хаб

Синтаксис:



Описание:

Команда, содержащая версию NMDC протокола клиента.
Эта команда должна быть послана клиентом на хаб после того, как хаб пошлёт клиенту команду $Hello.

Последняя 1.x версия NMDC была 1.0091. Используется альтернативный десятичный разделитель (,). Поэтому, DC++ использует номер версии в качестве числа 1,0091 не зависимый от местоположения компьютера.

$UserIP

Направление команды:

Хаб ---> Клиент
Клиент ---> Хаб

Синтаксис:

Запрос со стороны клиента:



Ответ со стороны сервера:



Описание:

Эта команда посылается клиентом на хаб, для того, чтобы получить ip адрес одного или более пользователей. Все пользователи разделены в команде знаками $$ (также как и в командах $NickList и $OpList). IP адрес, посылаемый хабом, должен быть реальным для хаба удалённым IP адресом, и этот IP адрес может отличаться от IP адреса, посылаемого в команде $ConnectToMe (потому что клиент может быть подключен к хабу напрямую, а между вторым клиентом и данным клиентом может находится маршрутизатор, который и сменит ip адрес в случае использования команды $ConnectToMe). DC++ не просит свой собственный IP адрес. Хабы, поддерживающие расширение протокола UserIP2 (UserIP v2), должны автоматически отсылать собственный IP клиента при входе на хаб.

$UserCommand

Направление команды:

Хаб ---> Клиент

Синтаксис:





[Тип] - положительное, целое число, описывающее тип команды:
0 - разделитель
1 - raw команда
2 - raw команда с ограничением на единственный ник %[nick]
255 - очистка команд
[Контекст] - целое число, регулирующее где показывать контекстные менюшки:
[1] - Контекстное меню хаба (доступно по клику на вкладке хаба). Примеры: просмотр правил, смена пароля. Эта команда может содержать параметр %[nick]. Вместо этого следует использовать переменную %[mynick] или %[line:blah].
[2] - Контекстное меню юзера (доступно по клику на любого юзера). Примеры: показ статистики юзера, проверка бана юзера. Эта команда может содержать переменные: %[nick], %[mynick] и %[line:blah].
[4] - Контекстное меню поиска. Пример: сообщить о битом файле. Эта команда может содержать специфические аргументы ника и файла.
[8] - Конкестное меню файл-листа. Пример: сообщение о найденном итом файле у юзера в списке файлов. Эта команда может содержать специфические аргументы ника и файла.
Замечание: этот контекст является новым в DC++ 0.669

[Детали] - этот параметр зависит от параметра [Тип]
[Тип] = 0 (разделитель) и [Тип] = 255 (очистка) не должны содержать параметра [Детали]
[Тип] = 1 (raw) использует в качестве деталей [Заголовок]$[Команда]
[Заголовок] - это название менюшки. Менюшка может быть составной, то есть содержать подменюшки. Для построения подменюшки используется обратный слеш (\). Например, [Подменю]\[Заголовок]. Степень вложенности подменюшек может быть любой.

Более высокие числа зарезервированы для дальнейшего использования.


Эскейп последовательности:
Если в меню используются знаки $, | и &, то их необходимо заменить на кодовые аналоги (аналоги html). Соответственно $ | и &

Как и все команды NMDC, данная команда разделяется от других знаком |.


Контекст:

Контекстное число - это бинарный флаг, который может быть составлен из других чисел, например, меню юзера и меню поиска вместе дадут (2 | 4 = 6). То есть для того, чтобы менюшка появилась в меню юзера и в меню поиска следует указывать контекст равный шести.


Детали:

Разделитель (вертикальная черта):



После [Контекста] и перед символом | может находиться некий текст, который в любом случае будет игнорироваться

Raw команды:



Команда добавляет raw пункт меню с заголовком [Заголовок] и raw командой [raw]. Эта команда должна оканчиваться на |, и если этого символа нет, то она отвергается.

Raw команда с ограничением на единственный ник:



Тоже самое, что и в предыдущем случае, но эта команда работает одна на один ник. Это должно помешать использованию массовой рассылки.

Очистка меню:



Команда стирает все менюшки из указанного контекста и ниже. То есть, например, 7 - сотрёт все менюшки с контекстами 1,2 и 4.

Примеры:



Эта команда отсылает в приват сообщение "You are being kicked====" для ника, и отправляет команду $Kick. Менюшки будут в поиске и меню юзера. Raw команда с ограничением на единственный ник не позволит сделать множественный кик.



Команда удалить все менюшки из контекстного меню хаба (вкладка хаба).

На поддержку данной команды может указывать наличие характеристики UserCommand в команде $Supports. Однако, из-за большой распространённости данной команды наличие этой характеристики в команде $Supports не обязательно.

$Supports

Синтаксис:



Характеристики поддерживаются: DC++ 0.17+ (Клиент - Клиент), DC++ 0.300 (Хаб - Клиент)

Направление команды:

Хаб ---> Клиент
Клиент ---> Хаб
Клиент ---> Клиент
Хаблист ---> Хаб
Хаб ---> Хаблист
Пингер ---> Хаб
Хаб ---> Пингер

Описание:

Данная команда используется для определения характеристик. Чтобы указать на то, что сервер имеет хотя бы одну характеристику, он должен отослать в начале команды $Lock следующую фразу EXTENDEDPROTOCOL. Если вторая сторона также поддерживает некоторые характеристики, то она также отсылает $Supports. Эта команда обязательно предшествует команде $Key.

Замечания:

• EXTENDEDPROTOCOL не должна отсылаться, если сервер не поддерживает никакие характеристики
• Пустая команда $Supports не допустима
• Пробелы в именах характеристик также не допустимы
• Для характеристик клиента, имя дополнения должно быть таким же как и имя команды этого дополнения.
• Хабы обычно хотят получить команду $Supports до команд $Key и $ValidateNick. Итак, последовательность должна быть такова:

Характеристики для связи Клиент - Хаб:

BotList
ClientID
Feed
HubTopic
IN
MCTo
NoGetINFO
NoHello
OpPlus
QuickList
TTHSearch
UserCommand
UserIP2
ZLine
ZPipe0


Характеристики для связи Клиент - Клиент:

ADCGet
BZList
CHUNK
ClientID
GetCID
GetTestZBlock
GetZBlock
MiniSlots
TTHL
TTHF
XmlBZList
ZLIG

$SR

Синтаксис:



Направление команды:

Клиент ---> Хаб
Хаб ---> Клиент
Клиент ---> Клиент
Хаб ---> Хаб

Описание:

Данная команда используется для возврата файла или директории, которая соответствует запросу в команде $Search. Все условия, которые находятся в оригинальном запросе, должны находиться в [Результат], и все типы и ограничения, используемые в команде $Search, должны быть выполнены.

[Результат] представляет из себя либо [Имя_файла][0x05][Размер_файла] для поиска по файлам, либо [Директория] для поиска по директориям
[0x05] - это 5-ый ASCII символ (используется в качестве разделителя).

Данная команда посылается клиентом, если у данного клиента нашлось что-то из запроса команды $Search от другого клиента.
Если команда $Search была послана от пассивного пользователя, то команда $SR должна быть возвращена хабу (через TCP). В этом случае, в конец данной команды должно быть дописано [0x05][Целевой_ник]. Перед пересылкой этой команды пользователю, который инициализировал поиск, хаб удаляет данную приписку с разделителем и целевым ником. Если команда $Search была послана от активного пользователя, то команда $SR возвращается на указанный в команде $Search IP адрес и UDP порт.
Параметр [IP_хаба:Порт] нужен только в том случае, если порт хаба не является портом по умолчанию (411).
В UNIX системах в путях к файлу должен встречаться только прямой слеш (/).
DC++ клиент будет отсылать максимум 5 результатов поиска для пассивных пользователей и 10 для активных. Кроме этого, для того, чтобы снизить нагрузку, хаб может сократить количество возвращаемых поисковых запросов.
Для файлов, содержащих TTH, параметр [Имя_хаба] заменяется на TTH:[base32_encoded_tth_hash] (см. TTH)

Примеры:

Ответ на пассивный поиск:



Ответ на активный поиск:

v 1.4.0.0 (файл перезалит в первой теме)

Fixed:

* Исправлена ошибка функции Core.GetUser (Огромное спасибо prapor-у за указание на найденную ошибку.)

Added:

* Добавлена реализация функции Core.GetUserValue

$Search

Синтаксис:

Пользователь в активе:



Пользователь в пассиве:



Направление команды:

Клиент ---> Хаб
Хаб ---> Клиент
Хаб ---> Хаб

Описание:

Данная команда используется для начала поиска файлов на хабе. Формат [Строки_поиска] не зависит от режима подключения клиента (актив, писсив).


[IP] - IP адрес активного пользователя.
[Порт] - UDP порт, который клиент слушает для приёма ответов на запрос от других клиентов.
[Ник] - ник пассивного пользователя.
[Строка_поиска] - строка поиска, которая описывает файл, который ищет клиент. Части этой строки разделяются знаками вопроса ('?'):

[Размер_ограничения]?[Максимальный_размер]?[Размер]?[Тип_данных]?[Поисковый_параметр]

[Размер_ограничения] - принимает значение 'T', если поиск должен быть ограничен максимальным или минимальным размером, иначе 'F'.
[Максимальный_размер] - принимает значение 'F', если [Размер_ограничения] равен 'F' или если размер ограничения устанавливает более низкий предел размера файла, инача 'T'.
[Размер] - минимальный или максимальный размер файла в байтах (в случае если указан [Максимальный_размер]) и если [Размер_ограничения] принимает значение 'T', иначе 0.
[Тип_данных] - ограничение поиска по типу файлов. Данное ограничение принимает одно из следующих целых чисел:

• 1 для любого типа файлов;
• 2 для аудио файлов ("mp3", "mp2", "wav", "au", "rm", "mid", "sm");
• 3 для архивов и сжатых файлов ("zip", "arj", "rar", "lzh", "gz", "z", "arc", "pak");
• 4 для документов и текстовых файлов ("doc", "txt", "wri", "pdf", "ps", "tex");
• 5 для выполняемых файлов ("pm", "exe", "bat", "com");
• 6 для картинок ("gif", "jpg", "jpeg", "bmp", "pcx", "png", "wmf", "psd");
• 7 для видео ("mpg", "mpeg", "avi", "asf", "mov");
• 8 для папок;
• 9 для TTH поиска;
• 10 для CD/DVD образов.

[Поисковый_параметр] - поисковый параметр определяет совпадения в имени файлов
Если тип поиска установлен в 9, то поисковый параметр должен представлять из себя TTH искомого файла.

Как и во всех сообщениях NMDC, в поисковом параметре следует избегать употребления следующих символов: "$", "|" и "&".
Все пробелы в поисковом параметре заменяются на знак '$'.

После отправки на хаб этого сообщения, хаб должен без изменений переслать это сообщение всем пользователям хаба. Каждый пользователь с одним или более совпадениями должен послать UDP пакет на [IP]:[Порт] в случае активного запроса или на хаб в случае пассивного запроса.

Смотрите описание команды $SR для детального разбора.

Примеры:

$RevConnectToMe

Синтаксис:



Направление команды:

Клиент ---> Хаб
Хаб ---> Клиент

Описание:

Клиент посылает данную команду на хаб для того, чтобы попросить пользователя [Ник2] инициализировать соединение с помощью команды $ConnectToMe. Команда $RevConnectToMe отсылается когда клиент не может сам соединиться (находится в пассивном режиме соединения с хабом).

[Ник1] - ник клиента, который просить соединиться с ним (пассивный).
[Ник2] - ник клиента, с которым нужно соединиться (активный).

Примечание:

Данная команда не применима к пассивному пользователю (к клиенту в пассивном режиме). Соединение пассив-пассив невозможно!

$Quit

Синтаксис:



Направление команды:

Хаб ---> Клиент
возможен случай: Клиент ---> Хаб

Описание:

Данная команда может отсылаться только хабом для того, чтобы клиент удалил разъединившегося пользователя из своего списка пользователей. Если вы решили написать свой клиент, не посылайте на хаб команду $Quit.
Данная команда показывает, что [Ник] отключился от хаба.

Пример:



Известны случаи, когда данная команда использовалась на хабе. Данная команда отсылалась клиентом на хаб и ник являлся ником клиента - хаб закрывал соединение с клиентом. Реализован этот принцип в Verli хабе.

$OpList

Синтаксис:



Направление команды:

Хаб ---> Клиент

Описание:

Данная команда используется хабом для отсылки клиентам списка ОПераторов (ники с ключиками). Этот список ограничен и разделён символами "$$".

В старых версиях протокола NMDC команда $OpList является подмножеством команды $NickList.

По протоколу NMDC v1 хаб также включает в команду $OpList всех зарегистрированных на хабе ботов. Современные хабы должны быть наделены способностью как показывать ботов среди ОПераторов, так и не показывать.

Если клиент найдёт в параметрах данной команды свой ник, то он должен включить у себя функции перенаправления и кика пользователей (добавить соответствующие контекстные менюшки).

$OpForceMove

Синтаксис:



Направление команды:

Клиент ---> Хаб

Описание:

ОПератор может отослать команду $OpForceMove для того, чтобы предложить клиенту переместиться на другой хаб.

[Ник_жертвы] - ник, которому предлагается перенаправиться.
[Новый_адрес] - это IP адрес или хост-имя (и опционально через двоеточие порт) другого хаба, на который происходит перенаправление.
[Причина] - причина перенаправления.

После получения этой команды хаб должен отослать жертве команду $ForceMove.
Сервер разъединяет клиента, однако клиент и сам закрывает соединение с хабом.

Комментарии:

После отправки ОПератором на хаб команды $OpForceMove, хаб отсылает жертве команды и прекращает отсылать клиенту-жертве какие-либо команды.
Если команда $OpForceMove послана на хаб пользователем, не являющемся ОПератором, хаб должен разъединить такого пользователя.

$NickList

Синтаксис:



Направление команды:

Хаб ---> Клиент

Описание:

Данная команда используется хабом для того, чтобы отправить ники пользователей, которые находятся на хабе в данный момент. Этот список ников оканчивается и разделён символами "$$". Команда используется в старых версиях протокола NMDC.

Смотрите также $OpList, $GetNickList

$MyPass

Синтаксис:



Направление команды:

Клиент ---> Хаб

Описание:

Данная команда посылается клиентом на хаб в ответ на команду $GetPass.
[Пароль] - это обычно не шифрованный текст пароля клиента.
Символ | недопустим в пароле.

Также см. команду $GetPass

$MyINFO

Синтаксис:



Направление команды:

Клиент ---> Хаб
Хаб ---> Клиент

Описание:
Данная команда отправляется клиентом на хаб, и хабом всем клиентам и, содержит всю основную информацию о клиенте.

Описание параметров команды:

[Ник] - ник пользователя (без пробелов).

[Описание] - описание пользователя. Поле определяемое самим пользователем. Клиенты автоматически к описанию добавляют в конце тэг. Вообще говоря тэг является не обязательным элементом, однако тэг содержит важные параметры, которые помогают хабу общаться с клиентом. Одним из важнейших параметров является режим. При помощи режима хаб определяет как клиент будет взаимодействовать с ним и с другими клиентами.

[Тэг] - автоматически добавляемый клиентом тэг. Общий вид любого тэга: <[Имя_клиента] V:[Версия_клиента],M:[Режим],H:[Хабы],S:[Слоты],[Ограничители]>
Вообще говоря параметры не обязательно должны быть в тэге именно в такой последовательности. Такая последовательность просто является общепринятой, и некоторые клиенты любую другую последовательность параметров могут воспринимать не правильно.

Несколько примеров различных видов тэгов:

DC++:
<++ V:x,M:x,H:x/y/z,S:x,O:x>

BCDC++:
<++ V:x,M:x,H:x/y/z,S:x,O:x,B:x>

CZDC++:
<++ V:x,M:x,H:x/y/z,S:x,O:x,L:x>

DC:Pro:
<DC:PRO V:x,M:x,H:x/y/z,S:x,O:x,F:x/y>

DC++k CDM:
<++ V:x,M:x,H:x/y/z,S:x,O:x>

DCDM++:
<++ V:x,M:x,H:x/y/z,S:x,O:x,B:x>

DCGUI:
<DCGUI V:x,M:x,H:x,S:x,L:x>

iDC++:
<++ V:x,M:x,H:x/y/z,S:x,O:x>

MS++V:
<++ V:x,M:x,H:x/y/z,S:x,O:x,B:x>

NMDC v2:
<DC V:x,M:x,H:x/y/z,S:x,O:x>

oDC:
<oDC V:x,M:x,H:x/y/z,S:x,O:x>

PhantomDC:
<++ V:x,M:x,H:x/y/z,S:x,O:x,B:x>

PeerWebDC++:
<PWDC++ V:x,M:x,H:x/y/z,S:x>

PeerWebDC++:
<PWSDC++ V:x,M:x,H:x/y/z,S:x>

rmDC++:
<RMDC++ V:y,M:x,H:x/y/z,S:x,O:x,B:x,D:x>

StrongDC++:
<StrgDC++ V:y,M:x,H:x/y/z,S:x,O:x,L:x>

zDC++
<++ V:x,M:x,H:x/y/z,S:x,O:x>

Z++
<Z++ V:x,M:x,H:x/y/z,S:x,L:x>

LDC++
<LDC++ V:x,M:x,H:x/y/z,S:x,L:x>

ApexDC++
<ApexDC++ V:x,M:x,H:x/y/z,S:x,L:x>

AvaDC++
<AvaDC V:x,M:x,H:x/y/z,S:x,L:x>

FlylinkDC++
<FlylinkDC++ V:x,M:x,H:x/y/z,S:x,L:x>

Greylink++
<gl++ V:x,M:x,H:x/y/z,S:x,L:x>

Pelink++
<pl++ V:x,M:x,H:x/y/z,S:x,L:x>

RSX++
<RSX++ V:x,M:x,H:x/y/z,S:x,L:x>

zK++
<zK++ V:x,M:x,H:x/y/z,S:x,L:x>

UKCable++
<UKC++ V:x,M:x,H:x/y/z,S:x,L:x>





[Имя_клиента] - имя, которое определяет тот или иной клиент.

[Версия_клиента] - версия, под которой выпущен клиент.

[Режим] - режим клиента. Может принимать значения: A, P или иное (5). A - активное соединение с хабом, P - пассивное соединение с хабом, 5 - соединение через прокси-сервер SOCKS5.

[Хабы] - хабы на которых находится клиент. Параметр может иметь следующий формат: U/R/O, где U - число хабов, на которых данный пользователь является незарегистрированным, R - число хабов, на которых данный пользователь является зарегистрированным, O - число хабов, на которых пользователь яляется ОПератором.

[Слоты] - число свободных или полное число слотов в клиенте.

[Ограничители] - данный параметр является не обязательным. Он может содержать в себе несколько параметров. Всё зависит от того или иного клиента. Обычно данный параметр показывает ограничение скорости. Конкретные значения данного параметра не привожу, для тех, кто хочет узнать его значения, я привёл примеры тэгов различных клиентов (см. чуть выше).

[Соединение] - тип соединения с хабом (указывается либо тип соединения, либо скорость соединения). Устанавливается непосредственно пользователем клиента.
Типы соединений в клиенте NMDC1: 28.8Kbps, 33.6Kbps, 56Kbps, Satellite, ISDN, DSL, Cable, LAN(T1), LAN(T3).
Типы соединений в клиенте NMDC2: Modem, ISDN, Wireless, DSL, Cable, Satellite, LAN(T1), LAN(T3).
Новые типы (Мбит/c): 0.005, 0.01, 0.02, 0.05, 0.1, 0.2, 0.5, 1, 2, 5, 10, 20, 50, 100, 1000

[Флаг] - статус пользоателя (ascii символ). Этот символ ещё называют магическим байтом. При отсутствии принимает значение кода 0.
Типы статусов (коды ascii символов для данного статуса):

• normal (1, 16, 17, 32);
• normal away (2, 3, 18, 19);
• server (4, 5, 12, 13, 20, 21, 28, 29);
• server away (6, 7, 14, 15, 22, 23, 30, 31);
• fireball (8, 9, 24, 25);
• fireball away (10, 11, 26, 27).

Статус server используется, когда клиент пробыл на хабе больше 2 часов, расшарил больше 2 ГБ и имеет отдачу свыше 200 МБ.
Статус fireball используется, когда с клиента скачивают со скоростью, превышающей 100 КБ/с.

[E-Mail] - email адрес пользователя. Может отсутствовать (пустая строка).

[Шара] - количество байт, которые расшарил пользователь. Этот параметр в любом случае должен приводится к числу.



Расшифровка буквенных обозначений тэга (на английском):
V: Client Version.
M: Mode.
H: The number of Hubs the client is connected to.
S: Number of Slots open.
O: Open an extra slot if speed is below.
B: Upload Bandwidth limit in kb/s.
L: Upload bandwidth Limit.
D: Download bandwidth limit in kb/s.
F: Fraction download / upload.



Возможные комбинации ограничителей:

• L:x
• O:x
• O:x,B:x
• O:x,B:x,D:x
• O:x,L:x
• O:x,F:x/y

Ограничители, ограничивающие скорость скачки:

• L:x
• B:x
• F:x/y

В параметрах данной команды символы $ и | не допустимы!

Эта команда является частью рукопожатия между клиентом и хабом. Посылается клиентом на хаб после получения команды $Hello. Клиент также отсылает эту команду время от времени, а также когда какой-либо из параметров этой команды изменится. Любая, как правило изменённая, отсылка этой команды транслируется хабом всем клиентам с характеристикой NoHello.

$LogedIn

Синтаксис:



Направление команды:

Хаб ---> Клиент

Описание:

Данная команда отсылается хабом клиенту в ответ на успешную последовательность пройденных команд $GetPass / $MyPass. Эта команда отправляется исключительно ОПераторам. Команда как бы контролирует вход операторов.

Замечание:
Обратите внимание на название команды: $LogedIn, а не $LoggedIn, как казалось бы должно быть.

$Lock

Синтаксис:



Направление команды:

Хаб ---> Клиент
Клиент ---> Клиент
Хаблист ---> Хаб
Хаб ---> Пингер

Описание:

Данная команда используется для того, чтобы убедиться в том, что с сервером соединяется оригинальный клиент DC (NMDC). Сервер (хаб, клиент, хаблист) может и не проверять отправленный клиентом (клиент, хаб, пингер) ключ, однако ключ должен посылаться клиентом в любом случае.

[Код] - это какая-либо последовательность символов (может даже случайная), исключая пробел, $ и |, максимальная и минимальная длина которой неизвестна.
[ПК] - это идентификатор устройства.

Эта команда является частью рукопожатия между клиентом и хабом, между клиентом и клиентом и в регистрации хаб-листа. Из-за того, что используемый алгоритм легко декодируется (см. Lock2Key), практически каждый может создать свой клиент.

Клиент никогда не должен посылать команду $Lock на хаб. Клиенты должны отсылать команду $Lock, когда два клиента соединяются друг с другом.

Пример для DC++:



Секции "ABCABC" являются наполнителями.

Ключевое слово EXTENDEDPROTOCOL в коде команды даёт право клиенту, кроме прочих команд рукопожатия отправить команду $Supports. Те есть это слово говорит о том, что хаб (клиент) поддерживает систему дополнительных расширений или характеристик.
Хаб(клиент) в ответ на команду $Supports также отправляет эту команду другой стороне уже со своим списком поддерживаемых расширений. Если какой-либо из участников не поддерживает дополнительные расширения, отправки команды $Supports не происходит.

Характеристики команды $Lock в протоколе NMDC:

• длина кода от 46 до 115 символов;
• длина Pk до 16 символов;
• символы команды $Lock: случайные, с кодами от 37 до 122.
• символы команд $Lock и $Key с кодами 0, 5, 36, 96, 124 и 126 должны быть заменены, соответственно, на /%DCN000%/, /%DCN005%/, /%DCN036%/, /%DCN096%/, /%DCN124%/ и /%DCN126%/

Экранируемые коды(символы):
0 (\0), 5(\5), 36($), 96(`), 124(|), 126(~)

$Kick

Синтаксис:



Направление команды:

Клиент ---> Хаб

Описание:

Данная команда отсылается на хаб клиентом и заставляет хаб закрыть соединение с жертвой. Жертве отсылается оповещение, в отличии от команды $Close. Только ОПераторы могут отсылать команду $Kick. В простонароде данную команду называют КИК.

Замечание:
На самом дела на хаб клиентом отправляется строка, состоящая из 3 команд:

Однако, первые 2 команды, которые представляют из себя, соответственно, сообщение в личку жертве, и сообщение всем в чат, автоматически приписывает клиентом. А непосредственно за кик отвечает только последняя команда: $Kick [Ник_жертвы]|

$Key

Синтаксис:



Направление команды:

Клиент ---> Хаб
Хаб ---> Хаблист
Клиент ---> Клиент
Пингер ---> Хаб

Описание:

Команда $Key отсылается на хаб в ответ на команду $Lock, которая отсылается хабом перед входом на хаб. Когда соединяются клиент с клиентом, или хаб с клиентом, ключ рассчитывается по определённому алгоритму, исходные коды которого доступны и свободно распространяются на разных языках программирования (см. Lock2Key). Команда $Key также используется, когда хаб регистрируется в хаб-листе, однако, в этом случае ключ вычисляется по иному. Такой обмен ключами является своего рода гарантом того, что соединяемые устройства работают на одном протоколе.

Сторона, которой отсылается ключ, может и не проверять правильность этого ключа, однако, отсылающая сторона всегда обязана отсылать рассчитанный ключ.

$HubTopic

Синтаксис:



Направление команды:

Хаб ---> Клиент

Описание:

Команда $HubTopic отсылает клиенту топик хаба, на подобии IRC.

[Топик] - это строка, содержащая топик.

Доступность команды в клиентах:

Данная команда поддерживается почти всеми современными клиентами.

Данная команда поддерживается следующими хабами: Verlihub, RusHub. Хаб PtokaX не поддерживает данную команду, однако команда может отправляться скриптом. На поддержку данной команды может указывать наличие дополнения HubTopic в команде $Supports, однако, это наличие не обязательно.

$HubName

Синтаксис:



Направление команды:

Хаб ---> Клиент

Описание:

Данная команда является частью рукопожатия между клиентом и хабом. Команда отправляет клиенту имя хаба.

[Имя_хаба] - это имя, которое использует данный хаб. Имя хаба обычно состоит из самого имени и из топика.

Дополнения:
Эта команда может быть отправлена в любое время, например, когда хаб изменил имя. Данная команда используется только для описания хаба.

Клиент1 и Клиент2 на одном и том же хабе этой командой могут получить разные имена, это может получится только на NMDC хабах, поэтому это имя не может быть использовано для однозначного определения хаба.

В Имени хаба в DC++ вместо символов (&, |, $) ожидаются их HTML эквиваленты.

$HubIsFull

Синтаксис:



Направление команды:

Хаб ---> Клиент

Описание:
Команда, посылаемая клиенту хабом для того, чтобы сообщить, что хаб полный, то есть на хабе достигнут предел пользователей.

Связанная с данной команда: $ValidateNick

$Hello

Синтаксис:



Направление команды:

Хаб ---> Клиент

Описание:

Данная команда является частью рукопожатия между клиентом и хабом. Посылается клиенту для того, чтобы указать ему ник, с которым хаб сопоставляет данный клиент. Хаб как бы даёт согласие на вход пользователя под данным ником. В ответ на эту команду, входящий на хаб клиент, должен отослать команду $Version

Данная команда является командой приветствия пользователя и отправляется хабом не только вошедшему на хаб клиенту, но и всем клиентам, находящимся в данный момент на хабе. Однако, если клиент при входе на хаб в команде $Supports указал характеристику NoHello, то такому клиенту, при входе какого-либо пользователя, хаб не будет отправлять команду $Hello.

$GetPass

Синтаксис:



Направление команды:

Хаб ---> Клиент

Описание:

Хаб посылает данную команду клиенту для запроса пароля зарегистрированного пользователя.
Команда посылается соединяющемуся с хабом пользователю только если его ник находится в регистрационном листе хаба (ник зарегистрирован на хабе).

Также см. команду $MyPass

$GetNickList

Синтаксис:



Направление команды:

Клиент ---> Хаб

Описание:

Эта команда заставляет хаб послать клиенту 2 списка зарегистрированных(вошедших) ников.



Тут надо отметить, что список $OpList является подмножеством списка $NickList. Если на хабе нет операторов и ботов, то хаб должен послать просто "$OpList $$|".

Однако, только старые версии протокола отправляют данные команды. Новые же версии несколько упрощены и отправляют только команду $OpList, а вместо команды $NickList используется команда $MyINFO.

Замечание:
Клиент не обязан запрашивать у хаба список пользователей, поэтому данная команда по своей сути не является обязательной.

$ForceMove

Синтаксис:



Команда сопровождается отсылкой в личку оповещения о перенаправлении:



Команда сопровождается отсылкой в чат оповещения о перенаправлении:



Направление команды:

Хаб ---> Клиент

Описание:

Хаб отсылает команду $ForceMove клиенту, чтобы предложить ему переместиться на другой хаб (предлагает клиенту перенаправиться).

[Ник_отправителя] - ник, который отправляет команду $OpForceMove.
[Ник_бота] - ник основного бота на хабе.
[Ник_жертвы] - ник, который должен быть перенаправлен на новый адрес.
[Новый_адрес] - это IP адрес или хост-имя (и опционально, через двоеточие, порт) другого хаба, на который происходит перенаправление.
[Причина] - причина перенаправления.

Комментарии:

Жертва может следовать перенаправлению или не следовать ему, это зависит от настроек клиента. По этой причине разъединение после отсылки клиенту этой команды - это общее, но не обязательное требование для хаба.

Примечание:

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

$ConnectToMe

Синтаксис:

Для клиентов DC++ и NMDC.



Пример:



Для клиентов NMDC v2.205 и DC:PRO v0.2.3.97A:



Пример:



Направление команды:

Клиент ---> Хаб
Хаб ---> Клиент
Хаб ---> Хаб

Описание:

Эта команда начинает процесс соединения между клиентами. Команда отправляется на хаб клиентом, находящимся в активном режиме соединения с хабом. Хаб пересылает эту команду целевому клиенту без изменения. Получив эту команду, целевой клиент отвечает, соединяясь напрямую с указанным IP через указанный порт.

[Ник_отправителя] - ник клиента в активном режиме, который хочет соединиться с целевым клиентом [Ник_получателя]. Клиент отправителя, после отправки на хаб запроса на соединение, начинает слушать указанный в запросе TCP порт.

Замечание:

Обратите внимание, что в скриптовую функцию старой версии PtokaX данная команда передаётся без символа вертикальной черты '|' на конце.

$Close

Синтаксис:



Направление команды:

Клиент ---> Хаб

Описание:

Эта команда заставляет хаб закрыть соединение с клиентом, чей ник написан в аргументе этой команды. Только операторы могут (имеют право) отправлять эту команду хабу. Эта команда в простонародье называется ДРОП.

[Ник] - ник пользователя, который подлежит разъединению с хабом.

В отличии от команды $Kick, команда $Close разъединяет пользователя без уведомления о разъединении. (По крайней мере на хабах NMDC первой версии эта команда работает именно так).

$BotList

Синтаксис:



Направление команды:

Хаб ---> Клиент

Описание:

Данная команда используется хабом для передачи клиенту списка ботов. Этот список ограничен и разделён символами "$$". Клиенты BDCH, BlackDC и ZionPlusPlus поддерживают эту команду для того чтобы различать операторов и ботов. Однако данная команда не является распространённой и не поддерживается большинством хабов.

На поддержку данной команды указывает наличие характеристики BotList в команде $Supports.

$BadPass

Синтаксис:



Направление команды:

Хаб ---> Клиент

Описание:

Эту команду отсылает хаб клиенту, который коннектится. Команда посылается, если клиент отослал хабу неправильный(некорректный) пароль в ответ на посланную хабом команду $GetPass. После отсылки этой команды хаб закрывает соединение с этим клиентом, или даже банит его.

Структурированное описание протокола NeoModus Direct Connect (NMDC), под управлением которого на сегодняшний день работает подавляющее большинство хабов. Хотя уже внедряется новый протокол ADC, однако, как говориться, всему своё время.

По мере написания, на каждую команду будет появляться ссылка на пост, описывающий эту команду.
Делаю тему закрытой, дабы структурировано описать команды.


О структуре команд

Все команды протокола начинаются с символа $. Исключение составляет команда сообщения чата, которая должна иметь следующую структуру: При этом, данный синтаксис команды чата обязателен в направлении клиент -> хаб, в то время, как хаб может отсылать клиенту любые сообщения, не начинающиеся с символа $, и клиент должен принимать такие сообщения, однако обработка таких сообщение не регламентирована протоколом (клиент может отображать такие сообщения как в чате, так и в статусной строке, или же вовсе игнорировать такие сообщения).

Символы-разделители протокола: $, | и пробел. Протокол не имеет экранирующих символов, поэтому для отсылки символов $ и | в параметрах команд нужно использовать их коды: &#36; и &#124;
Строка сообщения разделяется на команды по средствам символа |. Пример трёх команд, отосланных одной строкой:


Взаимодействие хаб-клиент


$BadPass
$Close
$ConnectToMe
$ForceMove
$GetINFO
$GetNickList
$GetPass
$Hello
$HubIsFull
$HubName
$HubTopic
$Key
$Kick
$Lock
$LogedIn
$MyINFO
$MyPass
$MultiConnectToMe
$MultiSearch
$NickList
$OpForceMove
$OpList
$Quit
$RevConnectToMe
$Search
$SR
$Supports
$UserCommand
$UserIP
$Version
$ValidateNick
$ValidateDenide


Взаимодействие клиент-клиент

$Cancel
$Canceled
$Direction
$Error
$Failed
$FileLength
$Get
$GetListLen
$Key
$Lock
$MaxedOut
$MyNick
$Ping
$Send
$To


Взаимодействие хаб-хаб

$FeaturedNetworks
$ConnectToMe
$Search
$SR
$Up
$UpToo




Взаимодействие хаб-хаблист

$Key
$Lock
$Supports


Взаимодействие пингер-хаб

$BotINFO
$HubINFO
$Key
$Lock
$Supports


Команды характеристик

$ADCGET / $ADCSND
$BotList
$Capabilities
$FeaturedNetworks
$GetZBlock
$MCTo
$Sending
$UGetBlock
$UGetZBlock
$Z
$ZOn


Разное

TTH
Lock2Key


Известные характеристики

Хаб-Клиент:
BotList
ClientID
Feed
HubTopic
IN
MCTo
NoGetINFO
NoHello
OpPlus
QuickList
TTHSearch
UserCommand
UserIP2
ZLine
ZPipe0

Клиент-Клиент:
ADCGet
BZList
CHUNK
ClientID
GetCID
GetTestZBlock
GetZBlock
MiniSlots
TTHL
TTHF
XmlBZList
ZLIG



Общая (обязательная) последовательность входа на хаб.
"Рукопожатие" между клиентом и хабом.



Последовательность входа на хаб, который поддерживает характеристику QuickList.



Последовательность действий хаба при регистрации в хаб-листе



Последовательность входа на хаб PtokaX
(последовательные команды могут отсылаться одной строкой, разделённой символом | )



Последовательность команд при получении списка пользователей (GetNickList) на хабе PtokaX



Последовательность входа на хаб HeX
(последовательные команды могут отсылаться одной строкой, разделённой символом | )


Материал из этой темы перенесён в вики: http://wiki.mydc.ru/Описание_протокола_NMDC

Объектно-Ориентированное Программирование (ООП) в LUA

В данной теме обсуждаются мощнейшие методы ООП


Итак, потихоньку буду писать основные понятия.

Объект и класс

Прежде всего следует понять что такое объект, и что такое класс

Согласно языку С++, класс - это определяемый пользователем тип, а объект - это экземпляр класса.
Попробуем в lua определить понятие класса.

Каждому классу могут соответствовать несколько объектов. Каждый объект занимает своё место в памяти и манипулирует со своими переменными и функциями. Приведу пример класса и объектов:
Возьмём класс - автомобиль. У этого класса есть некие свои "переменные" и "функции", такие как цвет (функция определения цвета), тип (хэтчбек, универсал, седан) и тд.
Объектом данного класса, например, будет красный седан
Другим объектом будет синий универсал
Третьим объектом будет также синий универсал

Второй и третий объекты не отличаются ничем, однако, они разные объекты, физически разные машины, хоть и выглядят одинаково (они занимают разные адреса в памяти).

Итак, класс - это некая общность объектов.


Конструктор

Функция, которая предназначается для инициализации (создания) объектов называется конструктором. Ввиду того, что такая функция создаёт (конструирует) объект. В С++ имя конструктора совпадает с именем класса, и вызывается при выделении памяти под объект.
В lua бы будем использовать для конструктора имя: __init, а вызываться конструктор будет при создании объекта.

Пример:



То есть при создании объекта обязательно сначала вызывается конструктор. В приведённом примере при создании объекта по средствам конструктора в объект передаются некоторые значения: 1, 2, 3. Если конструктор не содержит передаваемых параметров, то такой конструктор называется конструктором по умолчанию.


Деструктор

Деструктор вызывается каждый раз при уничтожении объекта. Это полная противоположность конструктору.


Закрытые переменные (private переменные)

Закрытые переменные - это переменные, которые могут использоваться только членами-классами.
В lua закрытые переменные у нас будут содержать 2 подчёркивания спереди.


Защищённые переменные (protected переменные)

Защищённые переменные - это переменные, которые могут наследоваться
В lua защищённые переменные у нас будут содержать 1 подчёркивание спереди.



продолжение следует...

вообще говоря вот код из исходников:
Отсюда можно видеть, что библиотеки можно класть в папку с PtokaX, либо в libs, либо в scripts/libs

[attachment=1106:Report.lua]

исправил и перезалил))

скрипт был написан под апи1 !!!

Под апи2 прикрепляю: [attachment=1107:Report.lua]

v 1.3.0.0 (файл перезалит в первой теме)

Fixed:

* ScriptMan.Restart()
* Core.Restart()
* TmrMan.AddTimer(nTimerInterval, sFunctionName)

Пофиксил функции рестартов (были перепутаны местами в старой версии)
В функции AddTimer параметр nTimerInterval задаём как обычно в милисекундах, однако, в целях оптимизации округление идет в меньшую сторону секунд, поэтому следует брать значения кратные секундам, иначе они в любом случае будут округляться до них.

Пример использования AddTimer:

Давно уже все просят сделать "спасибы". И флуда меньше будет, а то очень часто наблюдаю посты со словами спасибо.

самая важная фраза: пользователи всех производных программ получат вышеперечисленные права

Если имя клиента является неизвестным, то тег клиента приклеивается к описанию!!!

Функция коррекции данных пользователя:


Использование коррекции:

Компиляция Клиентов Dc++
Думаю, что многие видели различные версии клиентов DC++.
Однако, все эти клиенты возникли от одного праотца DC++.

Для компиляции своего клиента необходимо следующее:
1). Среда разработки Microsoft Visual Studio 2008.
2). Библиотека WTL [attachment=927:WTL80_sf.7z]3). Исходники клиента DC++ [attachment=926:DCPlusPl..._src_vs9.7z]

1). Microsoft Visual Studio 2008 качаем откуда-нибудь или покупаем
2). Библиотеку WTL (Windows Template Library) распаковываем в любую папку, и после этого из этой папки копируем содержимое папки include в папку Microsoft Visual Studio/VC/include.
3). В исходниках уже создан проект, поэтому просто открываем файл DCPlusPlus.sln. После открытия компилируем проект, построенный проект после компиляции появится в папке app.

Вот и всё! Строим проект, модифицируем файлы и создаём свои моды клиента

Название скрипта: OneNick-OneIP
Версия API: API1, API2 (универсальный)
Версия скрипта: 1.1
Автор: Setuper
Описание: Скрипт, запрещающий заходить с одного IP под несколькими никами.

А конвертер юзать не пробовали? Я думаю, что нормально должно сконвертироваться.

Проблема совместимости некоторых скриптов заключается в путях к файлам и директориям.

Windows вообще говоря использует в путях как прямые (/), так и обратные слеши (\).
Unix'ы в путях используют только прямые слеши (/).

Отсюда возникает проблема совместимости скриптов на Windows и Unix системах.


Предлагаю эту проблему совместимости решать следующим образом:

В путях писать только прямые слеши:
Например, для API 2:Для API 1:
(функции Core.GetPtokaXPath() и frmHub:GetPtokaXLocation() возвращают пути с прямыми слешами)

При использовании той, или иной консольной команды (mkdir, rmdir и тд.) путь в параметре этой команды нужно заключать в двойные кавычки, тогда путь может содержать только прямые слешы, что как раз будет соответствовать предложенному принципу совместимости.

Предлагаю разработчикам учесть этот факт и писать универсальные скрипты, совместимые с обеими системами windows и unix!!!


Самый универсальный, кроссплатформенный и кроссхабный метод определения абсолютных путей:

Не понимаю, что не понятного? Всё очень подробно разобрано. Объясняю всё конкретно для этого скрипта:

1). Копируем в папку scripts файл old_api.lu

2). Открываем скрипт chatrooms.lua и в самом начале скрипта (можно перед комментарием, можно после) дописываем строчку:
3). Вместо OnStartup() пишем Core.OnStartup()
Вместо UserConnected(tUser) пишем Core.UserConnected(tUser)
Вместо RegConnected=UserConnected пишем Core.RegConnected=Core.UserConnected
Вместо OpConnected=UserConnected пишем Core.OpConnected=Core.UserConnected
Вместо ChatArrival(tUser,sData) пишем Core.ChatArrival(tUser,sData)
Вместо ToArrival(tUser,sData) пишем Core.ToArrival(tUser,sData)

Всё! Скрипт переведён! Не понимаю чего тут трудного?
Всё по инструкции

я бы немного упростил и оптимизировал)))


или ещё более оптимизированный вариант (используя стандартные средства lua):

API1 http://mydc.ru/topic605.html

Переименовал тему в Вопросы разработчикам скриптов. Так название лучше отражает суть темы

Перезалил файл old_api.rar

Исправлена невозможность использовать функцию Core.GetPtokaXPath() при инициализации скрипта.

Лучше бы сделал командой. Например, пользователь отправил в чат какую то фразу не в той раскладке, скрипт её сохранил и пользователю достаточно отправить какую-нибудь команду, например для крактоски, !r и скрипт отправит это сообщение повторно, но уже транслированное в нормальную раскладку.

Проект закрыт, а программа то существует. Может кого заинтересует, разные люди бывают))))

Название: Чат комнаты
Версия: 1.0
Версия API: 2
Код: открытый
Автор: Setuper
Описание: возможно создать несколько чат комнат. Чат комнаты могут быть "закрытыми", то есть для получения сообщений нужно войти, а могут быть открытыми, то есть сообщения отсылаются всем доступным профилям (как в ОпЧате, вы не входите постоянно в ОпЧат, если вы Оператор, то он вам доступен). При запуске скрипта создаётся файл ChatRoom.dbs, в котором по умолчанию создаются 3 комнаты: комната для операторов, комната для випов и общая закрытая комната. В файле ChatRoom.dbs множество настроек. Опишу их на общей комнате:
добавлю, что если скрипт чат комнаты в списке скриптов стоит до скрипта антирекламы и параметр bReturn=true, то сообщения чат комнаты не будут отслеживаться антирекламой, в противном случае будут.
После первого запуска скрипта в файле настроек по умолчанию создаётся 3 комнаты. Вы можете менять количество комнат по смоему усмотрению.

Конечно возможности программирования на lua не ограничены. Данный код я вырвал из SBot'a и немного преобразовал, но большая часть возможностей чат комнат осталась в SBot'е (чат комната непосредственно в чате, а не в личке, чёрные и белые списки для любого пользователя, установка паролей на чат комнаты, антифлуд, антимат, антикапс, антиреклама в чат комнатах и тд. и тп.). Нету времени.

Для самостоятельного перевода скрипта под версию API 1 следует воспользоваться инструкцией: ИНСТРУКЦИЯ

Юзаем!

Метод быстрого перевода скриптов под API_1 (PtokaX 0.3.6.0 и ниже).

Ограничения на язык: Lua 5.1



Скрипт, подключая который на API_1, будут работать скрипты, написанные под API_2 !!!

Для этого следует всего-то проделать следующие 3 шага:

1). Помещаем в папку scripts файл из архива: [attachment=3987:old_api.rar]

2). Открываем скрипт, написанный под API_2, и дописываем в начало скрипта код:(код изменён для использования под обе версии API)

3). В именах основных функций PtokaX (OnStartup, OnExit, UserConnected, RegConnected, OpConnected и тд.) дописываем Core. спереди.

Примеры реализации пункта 3:

Было:дописав Core., получается:


Или так: было:дописав Core., получается:


Или даже так: было:дописав Core., получается:


Или даже так: было:дописав Core., получается:



Полный список всех функций в алфавитном порядке, впереди которых надо дописывать Core. :

• BotINFOArrival
• ChatArrival
• CloseArrival
• ConnectToMeArrival
• GetINFOArrival
• GetNickListArrival
• KeyArrival
• KickArrival
• MultiConnectToMeArrival
• MultiSearchArrival
• MyINFOArrival
• OnExit
• OnError
• OnStartup
• OnTimer
• OpConnected
• OpDisconnected
• OpForceMoveArrival
• PasswordArrival
• RegConnected
• RegDisconnected
• RevConnectToMeArrival
• SearchArrival
• SRArrival
• SupportsArrival
• ToArrival
• UDPSRArrival
• UnknownArrival
• UserConnected
• UserDisconnected
• ValidateNickArrival
• VersionArrival

В общем, находим в скрипте все вышеприведённые слова (если они есть в скрипте) и перед всеми найденными словами дописываем Core.


Всё! Почти любой скрипт, написанный под API_2 будет у вас работать на API_1 (исключения составляют вещи, которые есть только в API_2 - после перевода по данной методике эти вещи будут просто игнорироваться скриптом (или возвращать nil) - это связанно с расширенной функциональностью API_2, по сравнению с API_1)!!!

Обращаю внимание, что переведя по данной методике, скрипт будет работать вне зависимости от версии API, ОДНАКО таким макаром можно переводить только скрипты, написанные под API2 !!!

Таким образом можно за пару минут самому перевести скрипт на API_1, даже больших размеров (что в некоторых случаях заняло бы для перевода несколько дней). А когда вы всё же будете готовы перейти на новые версии PtokaX, обратные изменения также не займут много времени!

Называется венгерская нотация)))))


В lua можно использовать следующие:


(iShareSize, bConnected, hFile, tTable, mtTable)

http://mydc.ru/ipb.html?s=&showtopic=3...post&p=2068

Продолжение разбора интерфейса PtokaX.

Функции API 2 и их аналоги в API 1:

Core.Version - Получить версию PtokaX.
Аналог API 1: второе значение функции getHubVresion()

Core.Restart() - Перезапустить хаб.
Аналог API 1: frmHub:Restart()

Core.Shutdown() - Отключить хаб.
Аналог API 1: нету

Core.ResumeAccepts() - Продолжать прослушивать сокет(ы), если их прослушивание не было приостановлено.
Аналог API 1: нету

Core.SuspendAccepts() - Приостановить прослушивание сокета(ов). Хаб выглядит так, как будто не работает.
Аналог API 1: SuspendAccepts(0)

Core.SuspendAccepts(nTime) - Приостановить прослушивание сокета(ов) на указанное время в секундах. Хаб выглядит так, как будто не работает.
Аналог API 1: SuspendAccepts(nTime)

Core.RegBot(sBotName, sDescription, sEmail, bHaveKey) - Регистрирует бота на хабе. Максимальная длина строковых параметров - 64 символа !!! В нике недопустимы символы: $|<>:?*"/\ и пробел. В параметрах Description и Email недопустимы символы $ и |. Функция возвращает nil в случае невозможности зарегистрировать бота, в случае удачной регистрации возвращает true.
Аналог API 1: frmHub:RegBot(sBotName, bHaveKey, sDescription, sEmail)

Core.UnregBot(sBotName) - Удаление бота. Функция возвращает nil в случае невозможности разрегистрировать бота, в случае удачной разрегистрации возвращает true.
Аналог API 1: frmHub:UnregBot(sBotName)

Core.GetBots() - Возвращает таблицу со всеми ботами, зарегистрированными скриптами, как таблицу с полями sNick, sMyINFO, bIsOP and sScriptName.
Аналог API 1: нету

Core.GetActualUsersPeak() - Возвращает фактический пик пользователей.
Аналог API 1: frmHub:GetActualUsersPeak()

Core.GetMaxUsersPeak() - Возвращает максимальный пик пользователей.
Аналог API 1: frmHub:GetMaxUsersPeak()

Core.GetCurrentSharedSize() - Возвращает суммарную шару хаба в байтах.
Аналог API 1: frmHub:GetCurrentShareAmount()

Core.GetHubIP() - Возвращает IP хаба, если он доступен, иначе возвращает nil.
Аналог API 1: frmHub:GetHubIp()

Core.GetHubSecAlias() - Возвращает фактический псевдоним Hub-Security бота.
Аналог API 1: frmHub:GetHubSecAliasName()

Core.GetPtokaXPath() - Возвращает путь до файла PtokaX.exe.
Аналог API 1: frmHub:GetPtokaXLocation()

Core.GetUsersCount() - Возвращает число пользователей на хабе.
Аналог API 1: frmHub:GetUsersCount()

Core.GetUpTime() - Возвращает время работы хаба в секундах.
Аналог API 1: frmHub:GetUpTime()

Core.GetOnlineNonOps() - Возвращает таблицу со всеми таблицами онлайн пользователей без статуса оператора.
Аналог API 1: frmHub:GetOnlineNonOperators()

Core.GetOnlineNonOps(bAllData) - Возвращает таблицу со всеми таблицами онлайн пользователей без статуса оператора. Используйте true для параметра bAllData, если вы хотите, чтобы таблицы содержали все данные.
Аналог API 1: frmHub:GetOnlineNonOperators()

Core.GetOnlineOps() - Возвращает таблицу со всеми таблицами онлайн пользователей со статусом оператора.
Аналог API 1: frmHub:GetOnlineOperators()

Core.GetOnlineOps(bAllData) - Возвращает таблицу со всеми таблицами онлайн пользователей со статусом оператора. Используйте true для параметра bAllData, если вы хотите, чтобы таблицы содержали все данные.
Аналог API 1: frmHub:GetOnlineOperators()

Core.GetOnlineRegs() - Возвращает таблицу со всеми таблицами зарегистрированных (profile > -1) онлайн пользователей.
Аналог API 1: frmHub:GetOnlineRegUsers()

Core.GetOnlineRegs(bAllData) - Возвращает таблицу со всеми таблицами зарегистрированных (profile > -1) онлайн пользователей. Используйте true для параметра bAllData, если вы хотите, чтобы таблицы содержали все данные.
Аналог API 1: frmHub:GetOnlineRegUsers()

Core.GetOnlineUsers() - Возвращает таблицу со всеми таблицами онлайн пользователей.
Аналог API 1: frmHub:GetOnlineUsers()

Core.GetOnlineUsers(bAllData) - Возвращает таблицу со всеми таблицами онлайн пользователей. Используйте true для параметра bAllData, если вы хотите, чтобы таблицы содержали все данные.
Аналог API 1: frmHub:GetOnlineUsers()

Core.GetOnlineUsers(nProfileNumber) - Возвращает таблицу пользователей с указанным профилем.
Аналог API 1: frmHub:GetOnlineUsers(nProfileNumber)

Core.GetOnlineUsers(nProfileNumber, bAllData) - Возвращает таблицу пользователей с указанным профилем. Используйте true для параметра bAllData, если вы хотите, чтобы таблицы содержали все данные.
Аналог API 1: frmHub:GetOnlineUsers(nProfileNumber)

Core.GetUser(sNick) - Возвращает таблицу онлайн пользователя по нику.
Аналог API 1: GetItemByName(sNick)

Core.GetUser(sNick, bAllData) - Возвращает таблицу онлайн пользователя по нику. Используйте true для параметра bAllData, если вы хотите, чтобы таблицы содержали все данные.
Аналог API 1: GetItemByName(sNick)

Core.GetUserAllData(tUser) - Добавляет или обновляет все данные в таблице пользователя. Возвращает nil в случае неудачи (пользователь оффлайн) или true в случае успеха.
Аналог API 1: нету

Core.GetUserData(tUser, nValueId) - Добавляет или обновляет данные с указанным идентификатором в таблице пользователя. Возвращает nil в случае неудачи (пользователь оффлайн) или true в случае успеха.
Аналог API 1: нету

Core.GetUserValue(tUser, nValueId) - Возвращает данные с указанным идентификатором или nil в случае неудачи (пользователь оффлайн).
Аналог API 1: нету

Core.GetUsers(sIP) - Возвращает онлайн пользователей с указанным ip как таблицу с таблицами пользователей или nil в случае, если пользователь с указанным ip не найден или ip введен неверно.
Аналог API 1: нету

Core.GetUsers(sIP, bAllData) - Возвращает онлайн пользователей с указанным ip как таблицу с таблицами пользователей или nil в случае, если пользователь с указанным ip не найден или ip введен неверно. Используйте true для параметра bAllData, если вы хотите, чтобы таблицы содержали все данные.
Аналог API 1: нету

Core.Disconnect(sNick) - Разъединяет пользователя с указанным ником. Возвращает nil в случае неудачи, true - в случае успеха.
Аналог API 1: DisconnectByName(sNick)

Core.Disconnect(tUser) - Разъединяет указанного пользователя. Возвращает nil в случае неудачи, true - в случае успеха.
Аналог API 1: tUser:Disconnect()

Core.Kick(tUser, sKickerNick, sReason) - Кикает пользователя. Максимальная длина параметра KickerNick - 64 символа, максимальная длина парамерта Reason - 128000 символов. Возвращает nil в случае неудачи, true - в случае успеха.
Аналог API 1: tUser:Kick(sKickerNick, sReason)

Core.Redirect(tUser, sAddress, sReason) - Перенаправляет пользователя на указанный адрес с указанной причиной. Максимальная длина параметра Address - 1024 символа. Максимальная длина параметра Reason - 128000 символов. Возвращает nil в случае неудачи, true - в случае успеха.
Аналог API 1: tUser:Redirect(sAddress, sReason)

Core.DefloodWarn(tUser) - Предупреждение пользователю по причини флуда. Возвращает nil в случае неудачи, true - в случае успеха.
Аналог API 1: нету

Core.SendToAll(sData) - Послать данные всем пользователям. Максимальная длина параметра sData - 128000 символов. Если данные не содержат в конце символа |, то он автоматически добавляется.
Аналог API 1: SendToAll(sData)

Core.SendToNick(sNick, sData) - Послать данные пользователю с указанным ником. Максимальная длина параметра sData - 128000 символов. Если данные не содержат в конце символа |, то он автоматически добавляется.
Аналог API 1: SendToNick(sNick, sData)

Core.SendToOpChat(sData) - Послать данные, как приват сообщение, в ОпЧат. Максимальная длина параметра sData - 128000 символов. Если ОпЧат не разрещен - не посылает ничего.
Аналог API 1: SendToOpChat(sData)

Core.SendToOps(sData) - Послать данные всем операторам. Максимальная длина параметра sData - 128000 символов. Если данные не содержат в конце символа |, то он автоматически добавляется.
Аналог API 1: SendToOps(sData)

Core.SendToProfile(nProfileNumber, sData) - Послать данные пользователям с указанным профилем. Максимальная длина параметра sData - 128000 символов. Если данные не содержат в конце символа |, то он автоматически добавляется.
Аналог API 1: нету

Core.SendToUser(tUser, sData) - Послать данные указанному пользователю. Максимальная длина параметра sData - 128000 символов. Если данные не содержат в конце символа |, то он автоматически добавляется.
Аналог API 1: tUser:SendData(sData)

Core.SendPmToAll(sFromNick, sData) - Послать данные как приват сообщение всем пользователям. Максимальная длина параметра FromNick - 64 символа, максимальная длина параметра Data - 128000 символов.
Аналог API 1: SendPmToAll(sFromNick, sData)

Core.SendPmToNick(sToNick, sFromNick, sData) - Послать данные как приват сообщение пользователю с указанным ником. Максимальная длина параметра FromNick - 64 символа, максимальная длина параметра Data - 128000 символов.
Аналог API 1: SendPmToNick(sToNick, sFromNick, sData)

Core.SendPmToOps(sFromNick, sData) - Послать данные как приват сообщение всем операторам. Максимальная длина параметра FromNick - 64 символа, максимальная длина параметра Data - 128000 символов.
Аналог API 1: SendPmToOps(sFromNick, sData)

Core.SendPmToProfile(nProfileNumber, sFromNick, sData) - Послать данные как приват сообщение пользователям с указанным профилем. Максимальная длина параметра FromNick - 64 символа, максимальная длина параметра Data - 128000 символов.
Аналог API 1: нету

Core.SendPmToUser(tUser, sFromNick, sData) - Послать приват сообщение указанному пользователю. Максимальная длина параметра FromNick - 64 символа, максимальная длина параметра Data - 128000 символов.
Аналог API 1: tUser:SendPM(sFromNick, sData)



-------------------
SetMan.Save() - Принудительно сохраняет настройки.
Аналог API 1: нету

SetMan.GetMOTD() - Возвращает сообщение дня MOTD.
Аналог API 1: frmHub:GetMOTD()

SetMan.SetMOTD(sString) - Устанавливает сообщение дня MOTD. Символ | не допустим в сообщении.
Аналог API 1: frmHub:SetMOTD()

SetMan.GetBool(nBoolId) - Возвращает Булево знаечение парамерта настроек true или nil с указанным идентификатором.
Аналог API 1: нету

SetMan.SetBool(nBoolId, bBoolean) - Устанавливает Булево значение параметру настроек с указанным идентификатором.
Аналог API 1: нету

SetMan.GetNumber(nNumberId) - Возвращает числовое значение параметра с указанным идентификатором.
Аналог API 1: нету

SetMan.SetNumber(nNumberId, nNumber) - Устанавливает числовое значение параметру с указанным идентификатором.
Аналог API 1: нету

SetMan.GetString(nStringId) - Возвращает строковое значение параметра с указанным идентификатором. Возвращает строку или nil.
Аналог API 1: нету

SetMan.SetString(nStringId, sString) - Устанавливает строковое значение параметру с указанным идентификатором.
Аналог API 1: нету

SetMan.GetMinShare() - Возвращает минимальную шару в байтах.
Аналог API 1: frmHub:GetMinShare()

SetMan.SetMinShare(nShareInBytes) - Устанавливает минимальную шару в байтах.
Аналог API 1: frmHub:SetMinShare(nShareInBytes)

SetMan.SetMinShare(nMinShare, nShareUnits) - Устанавливает минимальную шару. Максимальное значение параметра nMinShare - 9999. Параметр nShareUnits может принимать следующие значения: 0 = Б, 1 = КБ, 2 = МБ, 3 = ГБ, 4 = ТБ.
Аналог API 1: frmHub:SetMinShare(nShareInBytes, nShareUnits)

SetMan.GetMaxShare() - Возвращает максимальную шару в байтах.
Аналог API 1: frmHub:GetMaxShare()

SetMan.SetMaxShare(nShareInBytes) - Устанавливает максимальную шару в байтах.
Аналог API 1: frmHub:SetMaxShare(nShareInBytes)

SetMan.SetMaxShare(nMaxShare, nShareUnits) - Устанавливает максимальную шару. Максимальное значение параметра nMinShare - 9999. Параметр nShareUnits может принимать следующие значения: 0 = Б, 1 = КБ, 2 = МБ, 3 = ГБ, 4 = ТБ.
Аналог API 1: frmHub:SetMaxShare(nShareInBytes, nShareUnits)

SetMan.SetHubSlotRatio(nHubs, nSlots) - Устанавливает соотношение хабы/слоты.
Аналог API 1: frmHub:SetHubSlotRatio(nHubs, nSlots)

SetMan.GetOpChat() - Возвращает таблицу ОпЧата с полями: sNick, sDescription, sEmail, bEnabled.
Аналог API 1: нету

SetMan.SetOpChat(bEnabled, sNewOpChatName, sNewDescription, sNewEmail) - Устанавливает параметры ОпЧата. Максимальная длина строковых параметров - 64 символа !!! В нике недопустимы символы: $|<>:?*"/\ и пробел. В параметрах Description и Email недопустимы символы $ и |. Возвращает nil в случае неудачи, иначе возвращает true.
Аналог API 1: frmHub:SetOpChatData(sNewOpChatName, sNewDescription, sNewEmail)

SetMan.GetHubBot() - Возвращает таблицу параметров главного бота с полями: sNick, sDescription, sEmail, bEnabled, bUsedAsHubSecAlias.
Аналог API 1: нету

SetMan.SetHubBot(bEnabled, sNewHubBotName, sNewDescription, sNewEmail, bUseAsHubSecAlias) - Устанавливает параметры главного бота. Максимальная длина строковых параметров - 64 символа !!! В нике недопустимы символы: $|<>:?*"/\ и пробел. В параметрах Description и Email недопустимы символы $ и |. Возвращает nil в случае неудачи, иначе возвращает true.
Аналог API 1: frmHub:SetHubBotData(sNewHubBotName, sNewDescription, sNewEmail)


-------------------
RegMan.Save() - Принудительно сохраняет зарегистрированных пользователей.
Аналог API 1: нету

RegMan.GetRegsByProfile(nProfileNumber) - Возвращает таблицу со всеми зарегистрированными пользователями с указанным профилем как таблицы RegisteredUser.
Аналог API 1: нету

RegMan.GetNonOps() - Возвращает таблицу со всеми зарегистрированными пользователями, которые не имеют статуса оператора как таблицы RegisteredUser.
Аналог API 1: frmHub:GetNonOperators()

RegMan.GetOps() - Возвращает таблицу со всеми зарегистрированными пользователями, которые имеют статус оператора как таблицы RegisteredUser.
Аналог API 1: frmHub:GetOperators()

RegMan.GetReg(sNick) - Возвращает таблицу пользователя как таблицу RegisteredUser или nil, если пользователь с указанным ником не зарегистрирован.
Аналог API 1: нету

RegMan.GetRegs() - Возвращает таблицу со всеми зарегистрированными пользователями, как таблицы RegisteredUser.
Аналог API 1: frmHub:GetRegisteredUsers()

RegMan.AddReg(sNick, sPass, nProfileNumber) - Регистрирует пользователя с указанным ником, паролем и профилем. Символы $|<>:?*"/\ и пробел не допустимы в нике. Символ | не допустим в пароле. Миксимальная длина ника/пароля - 64 символа. Возвращает nil в случае неудачи, true в случае успеха.
Аналог API 1: frmHub:AddRegUser(sNick, sPass, nProfileNumber)

RegMan.DelReg(sNick) - Удаляет регистрацию указанного пользователя. Возвращает nil в случае неудачи, true в случае
успеха.
Аналог API 1: frmHub:DelRegUser(sNick)

RegMan.ChangeReg(sNick, sPass, nProfileNumber) - Изменяет регистрацию указанного пользователя. Возвращает nil в случае неудачи, true в случае успеха.
Аналог API 1: frmHub:ChangeRegUser(sNick, sPass, nProfileNumber)

RegMan.ClrRegBadPass(sNick) - Очищает количество неудачных вводов пароля для указанного ника. Возвращает nil в случае неудачи, true в случае успеха.
Аналог API 1: ClrRegBadPass(sNick)


-------------------
BanMan.Save() - Принудительно cохраняет баны.
Аналог API 1: нету

BanMan.GetBans() - Возвращает таблицу банов.
Аналог API 1: нету

BanMan.GetTempBans() - Возвращает таблицу временных банов.
Аналог API 1: frmHub:GetTempBanList()

BanMan.GetPermBans() - Возвращает таблицу постоянных банов.
Аналог API 1: frmHub:GetPermBanList()

BanMan.GetBan(sNick/sIP) - Возвращает таблицу бана для указанного ника/ip или nil если таковой таблицы нет.
Аналог API 1: нету

BanMan.GetPermBan(sNick/sIP) - Возвращает таблицу постоянного бана для указанного ника/ip или nil если таковой таблицы нет.
Аналог API 1: нету

BanMan.GetTempBan(sNick/sIP) - Возвращает таблицу временного бана для указанного ника/ip или nil если таковой таблицы нет.
Аналог API 1: нету

BanMan.GetRangeBans() - Возвращает таблицу забаненных рангов.
Аналог API 1: нету

BanMan.GetTempRangeBans() - Возвращает таблицу временно забаненных рангов.
Аналог API 1: frmHub:GetTempRangeBans()

BanMan.GetPermRangeBans() - Возвращает таблицу постоянно забаненных рангов.
Аналог API 1: frmHub:GetPermRangeBans()

BanMan.GetRangeBan(sIPFrom, sIPTo) - Возвращает таблицу забаненных рангов для данного ранга или nil в случае отсутствия таковой.
Аналог API 1: нету

BanMan.GetRangePermBan(sIPFrom, sIPTo) - Возвращает таблицу постоянно забаненных рангов для данного ранга или nil в случае отсутствия таковой.
Аналог API 1: нету

BanMan.GetRangeTempBan(sIPFrom, sIPTo) - Возвращает таблицу временно забаненных рангов для данного ранга или nil в случае отсутствия таковой.
Аналог API 1: нету

BanMan.Unban(sNick/sIP) - Снятие бана с указанного ника или ip. Возвращает nil в случае неудачи, true - в случае успеха.
Аналог API 1: нету

BanMan.UnbanPerm(sNick/sIP) - Снятие постоянного бана с указанного ника или ip. Возвращает nil в случае неудачи, true - в случае успеха.
Аналог API 1: UnBan(sNick/sIP)

BanMan.UnbanTemp(sNick/sIP) - Снятие временного бана с указанного ника или ip. Возвращает nil в случае неудачи, true - в случае успеха.
Аналог API 1: TempUnBan(sNick/sIP)

BanMan.UnbanAll(sIP) - Снятие всех банов с указанного ip.
Аналог API 1: нету

BanMan.UnbanPermAll(sIP) - Снятие всех поятоянных банов с указанного ip.
Аналог API 1: нету

BanMan.UnbanTempAll(sIP) - Снятие всех временных банов с указанного ip.
Аналог API 1: нету

BanMan.RangeUnban(sIPFrom, sIPTo) - Снятие бана с указанного ранга. Возвращает nil в случае неудачи, true - в случае успеха.
Аналог API 1: RangeUnban(sIPFrom, sIPTo)

BanMan.RangeUnbanPerm(sIPFrom, sIPTo) - Снятие постоянного бана с указанного ранга. Возвращает nil в случае неудачи, true - в случае успеха.
Аналог API 1: RangePermUnban(sIPFrom, sIPTo)

BanMan.RangeUnbanTemp(sIPFrom, sIPTo) - Снятие временного бана с указанного ранга. Возвращает nil в случае неудачи, true - в случае успеха.
Аналог API 1: RangeTempUnban(sIPFrom, sIPTo)

BanMan.ClearBans() - Очистка таблицы банов.
Аналог API 1: нету

BanMan.ClearPermBans() - Очистка таблицы постоянных банов.
Аналог API 1: ClearPermBans()

BanMan.ClearTempBans() - Очистка таблицы временных банов.
Аналог API 1: ClearTempBans()

BanMan.ClearRangeBans() - Очистка таблицы бан-рангов.
Аналог API 1: ClearRangeBans()

BanMan.ClearRangePermBans() - Очистка таблицы постоянных бан-рангов.
Аналог API 1: ClearRangePermBans()

BanMan.ClearRangeTempBans() - Очистка таблицы временных бан-рангов.
Аналог API 1: ClearRangeTempBans()

BanMan.Ban(tUser, sReason, sBy, bFull) - Дать постоянный бан пользователю. Возвращает nil в случае неудачи, true - в случае успеха.
Аналог API 1: tUser:Ban(sReason, sBy, bFull)

BanMan.BanIP(sIP, sReason, sBy, bFull) - Дать постоянный бан пользователям с указанным ip. Возвращает nil в случае неудачи, true - в случае успеха.
Аналог API 1: Ban(sIP, sReason, sBy, bFull)

BanMan.BanNick(sNick, sReason, sBy) - Дать постоянный бан пользователю с указанным ником. Возвращает nil в случае неудачи, true - в случае успеха.
Аналог API 1: NickBan(sNick, sReason, sBy)

BanMan.TempBan(tUser, nTime, sReason, sBy, bFull) - Дать временный бан пользователю. Параметр nTime - время в минутах (0 = время бана берётся из настроек). Возвращает nil в случае неудачи, true - в случае успеха.
Аналог API 1: tUser:TempBan(nTime, sReason, sBy, bFull)

BanMan.TempBanIP(sIP, nTime, sReason, sBy, bFull) - Дать временный бан пользователям с указанным ip. Параметр nTime - время в минутах (0 = время бана берётся из настроек). Возвращает nil в случае неудачи, true - в случае успеха.
Аналог API 1: TempBan(sIP, nTime, sReason, sBy, bFull)

BanMan.TempBanNick(sNick, nTime, sReason, sBy) - Дать временный бан пользователю с указанным ником. Параметр nTime - время в минутах (0 = время бана берётся из настроек). Возвращает nil в случае неудачи, true - в случае успеха.
Аналог API 1: NickTempBan(sNick, nTime, sReason, sBy)

BanMan.RangeBan(sIPFrom, sIPTo, sReason, sBy, bFull) - Постоянный бан для указанного ранга ip. Возвращает nil в случае неудачи, true - в случае успеха.
Аналог API 1: RangeBan(sIPFrom, sIPTo, sReason, sBy, bFull)

BanMan.RangeTempBan(sIPFrom, sIPTo, nTime, sReason, sBy, bFull) - Временный бан для указанного ранга ip. Параметр nTime - время в минутах (0 = время бана берётся из настроек). Возвращает nil в случае неудачи, true - в случае успеха.
Аналог API 1: RangeTempBan(sIPFrom, sIPTo, nTime, sReason, sBy, bFull)


-------------------
ProfMan.AddProfile(sProfileName) - Добавляет профиль в менеджер профилей, возвращает номер профиля в случае успеха или nil, если такой профиль уже есть.
Аналог API 1: AddProfile(sProfileName,0)

ProfMan.RemoveProfile(sProfileName) - Удаляет профиль их менеджера профилей, возвращает true в случае успеха или nil, если указанный профиль не существует или наоборот существует и используется.
Аналог API 1: RemoveProfile(sProfileName)

ProfMan.MoveDown(nProfileNumber) - Сдвиг профиля вниз. Возвращает nil в случае неудачи, true - в случае успеха.
Аналог API 1: нету

ProfMan.MoveUp(nProfileNumber) - Сдвиг профиля вверх. Возвращает nil в случае неудачи, true - в случае успеха.
Аналог API 1: нету

ProfMan.GetProfile(sProfileName/nProfileNumber) - Возвращает профиль как таблицу профиля или nil, если такого профиля нет.
Аналог API 1: нету

ProfMan.GetProfiles() - Возвращает таблицу с профилями как профильные таблицы.
Аналог API 1: GetProfiles()

ProfMan.GetProfilePermission(nProfileNumber, nPermissionId) - Возвращает true, если настройка разрешена, иначе возвращает nil.
Аналог API 1: нету

ProfMan.GetProfilePermissions(nProfileNumber) - Возвращает таблицу с настройками профиля.
Аналог API 1: GetProfilePermissions(nProfileNumber)

ProfMan.SetProfileName(nProfileNumber, sProfileName) - Изменяет имя профиля, возвращает true в случае удачи или nil, если указанного профиля не существует.
Аналог API 1: нету

ProfMan.SetProfilePermission(nProfileNumber, nPermissionId, bBoolean) - Изменяет настройку профиля с указанным идентификатором, возвращает true в случае удачи или nil, если указанного профиля не существует.
Аналог API 1: нету


-------------------
TmrMan.AddTimer(nTimerInterval) - Добавляет новый таймер для скрипта. Параметр nTimerInterval - время в милисекундах. Возвращает nil - в случае неудачи или nTimerId - в случае успеха.
Аналог API 1: SetTimer(nTimerInterval) StartTimer()

TmrMan.AddTimer(nTimerInterval, sFunctionName) - Добавляет новый таймер для скрипта. Параметр nTimerInterval - время в милисекундах. Параметр sFunctionName - это имя функции выполняемой таймером. Возвращает nil - в случае неудачи или nTimerId - в случае успеха.
Аналог API 1: нету

TmrMan.RemoveTimer(nTimerId) - Удаляет таймер с указанным идентификатором из скрипта.
Аналог API 1: StopTimer()


-------------------
UDPDbg.Reg(sIp, nPort, bAllData) - Регистрирует получателя данных от PtokaX через UDP, если параметр bAllData равен false, то получать данные только от этого скрипта. Возвращает nil в случае неудачи или true в случае успеха.
Аналог API 1: нету

UDPDbg.Unreg() - Удалить получателя данных.
Аналог API 1: нету

UDPDbg.Send(sData) - Отправить данные через UDP. Если скрипт зарегистрирован, то только от зарегистрированного скрипта, иначе от всех скриптов. Возвращает nil в случае неудачи или true в случае успеха.
Аналог API 1: нету


-------------------
ScriptMan.GetScript() - Возвращает таблицу этого скрипта с полями sName, bEnabled, iMemUsage.
Аналог API 1: нету

ScriptMan.GetScripts() - Возвращает таблицу всех скриптов с полями sName, bEnabled, iMemUsage.
Аналог API 1: нету

ScriptMan.MoveUp(sScriptName) - Сдвинуть указанный скрипт выше. Возвращает nil в случае неудачи или true в случае успеха.
Аналог API 1: нету

ScriptMan.MoveDown(sScriptName) - Сдвинуть указанный скрипт ниже. Возвращает nil в случае неудачи или true в случае успеха.
Аналог API 1: нету

ScriptMan.StartScript(sScriptName) - Запустить скрипт с указанным именем. Возвращает nil в случае неудачи или true в случае успеха.
Аналог API 1: нету

ScriptMan.RestartScript(sScriptName) - Перезапустить указанный скрипт. Возвращает nil в случае неудачи или true в случае успеха.
Аналог API 1: нету

ScriptMan.StopScript(sScriptName) - Остановить указанный скрипт. Возвращает nil в случае неудачи или true в случае успеха.
Аналог API 1: нету

ScriptMan.Restart() - Перезапустить все скрипты.
Аналог API 1: frmHub:RestartScripts()

ScriptMan.Refresh() - Обновить скрипт-лист.
Аналог API 1: нету


-------------------
IP2Country.GetCountryCode(sIP) - Возвращает код страны для указанного ip или nil, если ip не действителен.
Аналог API 1: нету

IP2Country.GetCountryName(sIP) - Возвращает имя страны для указанного ip или nil, если ip не действителен.
Аналог API 1: нету

IP2Country.GetCountryName(tUser) - Возвращает имя страны для указанного пользователя.
Аналог API 1: нету

Еще несколько интересных методов. Может кому понадобятся, может кого заинтересует (Я использую их в больших проектах. Они несколько сворачивают длинные выкладки).


P.S. Существуют различия между методами и функциями. tSys:GetN(t) - метод, tSys.GetN(t) - функция

Немного неверно ты думаешь. Команда "$UserCommand 255 3" не блокирует (и тем более не скрипты). Она просто стирает контекстные менюшки!

Причем существуют разновидности:
"$UserCommand 255 1", "$UserCommand 255 2", "$UserCommand 255 3", ... , "$UserCommand 255 15"
Для стирания различным менюшек.

В таблице CmdCfg установить параметр: ClearMenu = "no", вместо "yes" =)

Функции преобразования ip адреса в число и обратно:
Можно использовать для проверки рангов ip и для оптимального хранения ip адресов в бд.

Функции форматирования шары:

Функция приведения к нижнему регистру:

Функция приведения к верхнему регистру:



Более оптимальные по выполнению функции:

Коды городов для скрипта

Привожу полное преобразование на lua из кодировки cp1251 (Ansi) в utf-8 и обратно, с помощью функций AnsiToUtf8 и Utf8ToAnsi соответственно:

Название скрипта: Bomb
Версия скрипта: 1.5
Версия API: API1 и API2 (универсальный скрипт)
Автор: Setuper
Префиксы команд: +, !, /
Команды: +bomb - подложить бомбу, +helpbomb - помощь
Код: Бинарный и Открытый
Описание скрипта: Подкладываешь бомбу и через установленное время она взрывается (юзера выкидывает или кикает с хаба), если конечно он её не обозвредит.
Настройки скрипта: После первого запуска скрипта создаётся файл "SettingsBomb.dbs", который содержит все настройки скрипта. Итак,
sBot - имя бота. Если не задано или пустая строка, то берется основной бот, иначе регистрируется на хабе указанный;
iTime - время в секундах для разминирования;
iTimer - время, через которое у вас появляются таймеры для бомб (это минимальное время между двумя подкладываниями бомб);
iTimeArmour - задержка перед запросом на установку или снятие бронежилета;
iTop - число позиций в топе;
iTopAll - число позиций в общем топе;
tWire - таблица проводов бомбы (должно быть не меньше 2 проводов);
iAction - действие при взрыве. 1 - дроп, 2 - кик;
sMenuUser - контекстное меню пользователя;
sMenuHub - контекстное меню хаба;
sArmour - контекстное меню установки/снятия бронежилета;
sCheck - контекстное меню проверки состояния бронежилета;
sHelp - контекстное меню помощи;
sTopBombers - контекстное меню топа минёров;
sTopSappers - контекстное меню топа сапёров;
sTopLosers - контекстное меню топа неудачников;
sTopAll - контекстное меню общего топа;
tProfiles - таблица профилей, под которых не подкладываются бомбы.

При возникновении каких то трудностей или ошибок скрипта отписываем сюда, указав ошибку и действие, которое вызвало ошибку.

В скриптах с закрытым кодом есть возможность отсылать цвет провода как в чат, так и в личку боту!
В скриптах с открытым кодом есть возможность отсылать цвет провода только в чат!

Версии с идентификацией по ip:
[attachment=2170:Bomb_by_...er_v_1.5.lua][attachment=2171:Bomb_by_...1.5_open.lua]

Версии с идентификацией по нику:
[attachment=2172:Bomb_by_..._nick_id.lua][attachment=2173:Bomb_by_..._nick_id.lua]

ВНИМАНИЕ!!! Перед запуском очередной новой версии необходимо удалить старый файл настроек для того чтобы появился правильный новый файл настроек!!!

Удачной игры

Вот своял под апи2, но на работоспособность не проверял!

Сегодня я расскажу как на стороне клиента делать контекстные менюшки.

Открываем свой клиент и заходим: "Файл" - "Настройки" - "Команды-Юзера". Щелкаем добавить.

Видим типы команд:

Разделитель - горизонтальная черта между менюшками.
RAW - RAW команда
Чат - команда, отсылаемая в чат
PM - команда, отсылаемая в личку указанному юзеру

Далее контекст:

Меню хаба - означает, что команда будет доступна из контекстного меню хаба (правый щелчок по закладке хаба)
Меню юзера - означает, что команда будет доступна из контекстного меню юзера (правый щелчок по любому из юзеров)
Меню поиска - означает, что команда будет доступна из контекстного меню поиска (правый щелчок по файлу в результатах поиска)
Меню листа файлов - означает, что команда будет доступна из контекстного меню файл-листа (правый щелчок по файлу или папке после получения файл-листа юзера)

Далее рассмотрим параметры:

Название: в названии пишем имя контекстной менюшки. Если вы хотите создать подменю, то надо использовать обратные слеши ("\")
Команда: тут надо писать команду.
Хаб IP / DNS: тут надо писать IP или DNS имя хаба, на котором должна появиться и действовать данная команда. Если ничего не указывать, то команда появиться на всех хабах. Если указать "op", то команда появиться на всех хабах, на которых вы являетесь оператором (при условии, что рядом с вашим ником будет ключик, то есть если от хаба к клиенту прийдет команда получения статуса оператора).
К: тут обычно пишется ник получателя лички, если команда является командой типа PM.



Теперь рассмотрим простейший пример написания команд.

Устанавливаем тип команды: "чат"
Контекст: "Меню хаба" и "Меню юзера"
Название: "Меню клиента\Сказать привет"
Команда: "Всем привет"

после нажатия кнопки ОК, на всех ваших хабах появиться менюшка с названием: "Меню клиента", в которой будет менюшка: "Сказать привет". После нажатия на эту менюшку в чат того хаба, на котором была нажата менюшка, отправится фраза: "Всем привет".



Рассмотрим следующий пример:

Тип команды: "чат"
Контекст: "Меню хаба" и "Меню юзера"
Название: "Меню клиента\Послать дату и точное время в чат"
Команда: "Сегодня: %A - %d/%m/%Y. Точное время: %H:%M:%S"

Данная команда будет отсылать в чат ваше время на компьютере.



Следующий пример:

Тип команды: "чат"
Контекст: "Меню юзера"
Название: "Меню клиента\Сообщения\Сообщения в чат\Шара этого юзера"
Команда: "Шара пользователя %[userNI]: %[userSS] байт"

Список команд сохраняется в файле Favorites.xml в папке Settings вашего клиента.

Приложу мой список команд. Можете скопировать в свой файл Favorites.xml полностью тег <UserCommands> и у вас появятся менюшки на хабах.
Но перед копированием в этот файл сделайте резервную копию этого файла, если у вас ни получиться правильно скопировать, то вернёте свой старый файл. И еще! Перед записью в этот файл (Favorites.xml) нужно закрыть клиент (именно закрыть, а не свернуть!!!)

[attachment=434:Favorites.xml]

Итак, я думаю многие сталкивались в скриптах со всевозможными "захватами" и регулярными выражениями.
Почти в каждом скрипте они встречаются.

Сразу же начну с нескольких примеров:


Можете ли вы сказать, что тут выполняется??? Если не можете, то слушайте дальше...

Сначала расскажу, что такое захват, и что такое регулярное выражение.
Формально, захват - это нахождение определённый последовательности символов и помещение их в переменную.
Например, возьмём один из примеров, который я написал сверху:

этот пример - типичный пример захвата. Функция string.find "захватывает" из строки "11.12.13.14" определённую последовательность символов.
Выражение "^(%d+)%.(%d+)%.(%d+)%.(%d+)$", называется РЕГУЛЯРНЫМ ВЫРАЖЕНИЕМ.
в скобках указываются захваты, то есть тут 4 захвата. Из этой функции данные у нас заносятся в 6 локальных переменных, а именно s, e, a, b, c, d.
В переменную s (s от слова start) заносится начальная позиция захвата, равная 1. У нас строка "11.12.13.14" имеет 11 символов, следовательно 11 позиций. В переменную e (e от слова end) заносится конечная позиция захвата, равная 11. Обычно, в скриптах эти позиции не нужны, тогда, обычно, переменные обозначают одним именем (для сохранения памяти), обычно, обозначают как "_" (чтобы эта переменная была не столь заметна).
Далее в переменные a, b, c, d, соответственно, заносятся захваты (то, что захватывается скобками).
Разберём регулярное выражение: "^(%d+)%.(%d+)%.(%d+)%.(%d+)$".
Символ ^ означает, что следующее действие в регулярном выражении должно быть в начале строки. У нас следующее за символом ^ действие - это захват (%d+), следовательно, захват у нас должен выполняться обязательно с начала строки. Сейчас объясню более понятно на примерах.
Возьмём два регулярных выражения "^(%d+)" и "(%d+)".
Теперь с помощью действий:

в переменные a1 и a2 запишутся данные: a1="11" и a2="11".
Теперь изменим исходную строку (дописав вначале строки пробел):

смотрим, что в переменных: a1=nil и a2="11".
Теперь я думаю вам почти понятно в чем вся фишка, осталось только объяснить, что такое (%d+).
(%d+) - это захват числа. Во второй строке вначале стоял пробел, поэтому выражение ^(%d+) не могло захватить число вначале строки, поэтому и функция string.find вернула nil, и записала в переменные s=nil, e=nil, a1=nil, а функция string.find(" 11.12.13.14", "(%d+)") записала в переменные s=1, e=2, a2="11". Заметьте, что хоть мы и захватываем число, но тем не менее оно является строковым числом "11", а не просто 11 !!!!!!!!.
Аналогично дело обстоит с символом $, но только для конца строки.
Таким образом, мы рассмотрели 3 первых примера, которые я предложил вначале.
В первом примере: s=1, e=11, a="11", b="12", c="13", d="14" и захват происходит именно 4 чисел, разделённых точками, и никакой другой комбинации
Во втором: _=nil, a=nil, b=nil, c=nil, d=nil и захвата не произошло из-за пробела в конце.
В третьем: _=14, a="11", b="12", c="13", d="14" захват 4 чисел, разделённых точками, в любом месте (хоть вначале строки, хоть в середине, хоть в конце), и строка не обязана содержать только 4 числа, разделённых точками, в отличие от первых двух примеров.

Идём далее. Выпишу основные регулярные выражения:


вроде становится понятнее, не так ли?

Эквиваленты:
%d эквивалентно [0-9]
%D эквивалентно [^%d]
%w эквивалентно [A-Za-z0-9]
%W эквивалентно [^%w]

в 4 и 5 примерах встречается регулярное выражение %S. Находим в списке выше, и видим: %S - не символ пробела. То есть, это означает, что это не пробел, а следовательно это любой символ, кроме пробела.

Теперь рассмотрим всякие плюсики. Я буду рассматривать их совместно с регулярным выражением %s, то есть с символом пробела.



Теперь объясню разницу между * и -
Удобнее всего на следующем примере. Я уже рассказал, что означает точка (смотри выше в списке регулярных выражений: "." - любой символ).
Рассмотрим примеры следующих регулярных выражений:




Ну и последнее...

А если, допустим, я хочу захватить точку. Как быть?
Дело в том, что точка является так называемым магическим символом.
Магические символы: ( ) . % + - * ? [ ] ^ $
Перед всеми магическими символами нужно ставить %, то есть все магические символы надо экранировать.
Таким образом, чтобы захватить точку надо написать "(%.)"


На последок ещё несколько часто используемых регулярных выражений:



Теперь, я думаю, что вы и сами сможете написать, что же получается в примерах 4 и 5???

Название скрипта: RegMe
Версия скрипта: 1.5
Версия API: API1 и API2 (универсальный скрипт)
Автор: Setuper
Префиксы команд: +, !, /
Описание скрипта: Скрипт регистрации. Содержит в себе возможности регистрации и перерегистрации. Есть возможность перед регистрацией проходить тест по правилам хаба (не пройдя тест не регистрировать). Есть возможность в случае, если не указывается пароль, давать случайный пароль. За ненадобностью регистрации 1 ник на 1 ip - эту функцию скрипт не содержит (дабы не нагружать память базой пользователей). Скрипт может регистрировать бота (или же оставить главного бота) и устанавливать его параметры, а именно: статус away, описание, email, имя клиента, тэг, шару. Скрипт представляет собой бинарный файл, но все настройки скрипта вынесены в отдельный файл RegMe.dbs, который создаётся при первом запуске скрипта, и который можно открыть с помощью блокнота и править; этот файл содержит все сообщения скрипта и все менюшки, поэтому скрипт легко переводится на другие языки - достаточно только перевести то что написано в этом файле (но будьте осторожны - ошибки в этом файле могут привести не падению скрипта). Также существуют другие файлы, которые создаются после первого обращения к ним - это файл с просьбой зарегистрироваться (для не зарегистрированного), который показывается при входе на хаб (имя файла UnRegInfo.txt) и команды помощи (RegHelp.txt)

Некоторые настройки скрипта:
bShowInfo=1 - показывать дополнительную информацию о том, как можно избежать повторных вводов пароля при входе на хаб
bShowToAll=1 - показывать всем пользователям, что на хабе новый зарегистрированный участник
bQuestions=1 - задавать ли вопросы перед регистрацией
iQuestions=число - сколько правильных ответов нужно для регистрации
bRandomPass=1 - устанавливать случайный пароль в случае его отсутствия
bSendOpReport=1 - отсылать рапорт о регистрации ОПам
iRegProf=число - профиль регистрации (по умолчанию) - обычно 3
iBlocker=число - блокировщик для незарегистрированных:
1-чат
2-ПМ
3-скачку
4-поиск
5-чат и ПМ
6-чат и скачку
7-ПМ и скачку
8-чат и поиск
9-ПМ и поиск
10-скачка и поиск
11-чат, ПМ и скачку
12-чат, ПМ и поиск
13-чат, скачку и поиск
14-ПМ, скачку и поиск
15-чат, ПМ, скачку и поиск

[attachment=1607:RegMe_v1.5.lua]

SupportsArrival(tUser, sData)
Важная функция (с её помошью я смог устроить автоматическую регистрация по ip).
В данной функции происходить объявление основных полей таблицы пользователя, а также проверяется поддержка дополнений.
пример команды: "$Supports UserCommand NoGetINFO NoHello UserIP2 TTHSearch ZPipe0 |" - клиент говорит, что он поддерживает:

• UserCommand - контекстные команды менюшек,
• NoGetINFO - не нужна отсылка команды GetINFO для получения MyINFO,
• NoHello - не обязательна отсылка команд $Hello и $NickList,
• UserIP2 - поддержка технологии UserIP2,
• TTHSearch - поддержка поиска по TTH,
• ZPipe0 - поддержка команды $ZOn - команды сжатия данных (библиотека zlib)

Принципы построения, создания и использования Dynamic Link Library (DLL)

Среды разработки и языки: Borland С++ Builder 6, lua 5, PtokaX 3.6.*.*


Немного теории.

DLL - это один или несолько участков кода, хранимых в файле с расширением .dll. Код, содержащийся в dll, может быть вызван из испольняемой программы, но сама dll не является программой. DLL может содержать функции, классы и ресурсы. Прежде чем использовать dll, её нужно загрузить в память. Существуют два вида загрузки dll: статическая и динамическая. Статическая загрузка означает, что dll автоматически загружается при запуске приложения. DLL содержит экспортируемые функции, а описания этих функций находятся в библиотеке импорта (import library). Библиотеки импорта имеют имя, совпадающее с именем соответствующей dll, и расширение .lib. Для использования статической загрузки необходимо на этапе компоновки к проекту подключить lib-файл для dll. DLL загружается при загрузке приложения и можно вызывать экспортируемые функции так же, как и любые другие функции. Это самый лёгкий подход. Недостаток его в том, что при отсутствие необходимой dll программа не будет загружаться ваобще. Второй тип загрузки - Динамическая загрузка. Означает, что DLL загружается при необходимости и выгружается по окончанию использования. Достоинством является то, что dll находится в памяти до тех пор, пока она нужна, что приводит к более эффективному использованию памяти. В lua мы используем динамический вид загрузки.

Ещё немного о содержании dll библиотек.
Как же прсмотреть содержимо dll библиотеки? Ведь dll файл нельзя ничем открыть. Для просмотра содержимого dll существуют специальные утилиты. Я использую Борнандовскую утилиту tdump (находится в папке bin вместе с bcb.exe).

Далее писать теорию влом. Если что, то спрашивайте попробую объяснить)))

Приступим к написанию.

1. Открываем Builder C++ 6
2. Закрываем автоматически созданную форму (file -> close all)
3. Создаём новый проект (file -> new -> Other -> dll wizard) указываем тип "C" (в противном случае будут необходимы некоторые манипуляции с extern "C") я уще обычно ставлю галку vc++ style dll (но это не принципиально, просто будет различаться имя основной функции dll).
4. Далее в созданном проекте видим огромный коммент -> стираем его нах (в кратце он говорит о том что для того чтобы использовать библиотеку srting необходим дополнительный гемор).
5. функцию DllMain не трогаем, а пишем выше (или ниже) следующий код (данный код является самым простейшим):


6. сохраняем проект (file -> save project). вам будет сначало предложено сохранить юнит, а потом уже проект.
7. для компиляции нужны заголовочные файлы (из исходников),а именно файлы: "lua.h", "lualib.h", "lauxlib.h" и "luaconf.h".
8. все эти файлы можно найти скачав исходники lua.
9. эти файлы надо поместить в директорию проекта.
10. также нужна библиотека статической загрузки "PXLua.lib"
11. создаем dll (project -> build all)
12. копируем dll из папки проекта в папку с PtokaX (dll обычно имеет имя проекта. по умолчанию "project1.dll")
13. пишем скрипт

тут функция содержит впереди символ подчеркивания - это "украшения" компилятора))) (хотя существуют способы убрать этот символ, но я их тут рассматривать не буду). Просмотреть названия функций в библиотеке можно опять же воспользовавшись утилитой tdump.exe
14. заходим на хаб и перезагружаем скрипт. должно появиться "Hello World!".

p.s. для написания dll для PtokaX 0.4.*.* необходима библиотека статической загрузки "PXLua.lib" для данной версии и соответственно изменить SendToAll на Core.SendToAll

p.p.s. чуть позже выложу более сложные функции (ща влом писать)

"PXLua.lib" [для PtokaX 0.3.6.0] [attachment=256:PXLua.zip]
"Заголовочные файлы" [attachment=257:lua.zip]