Предложения для развития

Список пока не реализованных идей и запросов ( todo / future request / change request / improvement ).

ToDo:

• Сделать возможность запрета перенаправления по возвращаемому значению из функции OnOpForceMove
• Сделать возможность смены директорий на лету (сейчас могут быть с этим проблемы).
• Реализовать хранение информации в бд. По умолчанию в SQLite3 с возможностью подключения драйверов других баз данных (в частности, в первую очередь MySQL).
• Встроенный бан менеджер с перегружаемыми из lua событиями.
• Сделать параметр настроек "ограничение количества поисковых запросов".
• Функция статистики и информации о сервере.
• Реализовать функцию получения пользователей по профилю/профилям.
• Добавить возможность в функции Core.SendToIP отсылать данные таблице ip адресов, а не только одному ip.
• Сделать возможность смены настройки sAddresses на лету.
• Сделать поддержку характеристики QuickList.
  
  
  Оптимизация:
• Кеширование поисковых запросов и отвечающих им результатов поиска
• Умный кэш (кэш для рассылки всем, кроме...).
• Сделать хвостовой кэш для массовой рассылки: рассылка по окончанию шага цикла (кэш по умолчанию для массовой рассылки).
• Сделать отложенный выход для того чтобы не совершать бесполезные массовые рассылки.
• Сделать событие OnReEnter при условии реализации отложенного выхода.
  
  
  На потом:
• Оптимальная линковка хабов (встроенный в хаб функционал линковки).
• Авторегистрация хаба в хаблистах (процесс регистрации в отдельном потоке).
• Доработать анти-спам.
• Сделать потоки в Lua.

Какие предложения по поводу параметров событий OnScriptStart, OnScriptStop и OnScriptRestart ?

Хорошо бы к этому всему добавить OnScriptError

Уже давно есть.

Setuper - вот интересная статья про соединение 2х пассивных пользователей. Будет такое на RusHub-e? В адц протоколе такое возможно при использовании стронга.

Технология понятна, однако для такого фокуса нужно чтобы пассивный клиент отсылал команду на соединение с пассивом, но NMDC клиент устроен так, что при соединении с пассивным он не будет ничего отсылать на хаб.

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

А это ещё зачем? Разве не достаточно OnScriptStart и OnScriptStop?

Не могу себе представить поведение функции , когда при рестарте в скрипте обнаружилась ошибка. Вызывать OnScriptStop? Или отправлять false в качестве аргумента, и вызывать OnScriptError?

ИМХО эта функция добавит мазохизма к и без того хитрозакрученному скриптовому API.

Согласен. Событие OnScriptRestart не нужно.
Однако вопрос остаётся открытым. Какие параметры нужны в событиях OnScriptStart и OnScriptStop? Обойтись только именем скрипта?



Не совсем понял. При рестарте в скрипте происходит ошибка, тут же начинает выполняться событие OnError этого скрипта (если оно в нём есть). Если в этом событии ошибка, то скрипт останавливается, в противном случае скрипт останавливается или нет в зависимости от того что возвращает это событие. После этого уже вызываются события OnScriptError во всех остальных скриптах.

А зачем там что-либо кроме имени? Для ошибок есть OnScriptError.

Тут важно другое - чтобы функции вызывались так же, как и OnScriptError - без таймера.

У меня очередной feature-request:
Функция, возвращающая список настроек. Я думаю, это несложно реализовать.

Назрел вопрос об улучшении в следующей версии. Вопрос такой: может ввести дополнительно умные параметры дабы избежать проверок, которые нужно обязательно делать?
Речь тут идёт о параметрах пользователя. Хочу сделать вот что: UID.iSlots = nil, а UID._iSlots = 0. Если не хочется проверять параметр на nil значение, используем безопасный параметр (с подчеркиванием спереди) с чётко определённым значением по умолчанию.
Стоит ли это сделать или это бредовая идея??

Стоит, ведь часто какой-нибудь параметр проверяется на nil, и ему присваивается дефолтное значение

Возможно даже стоит сделать функцию, которой можно будет устанавливать значения по умолчанию для параметров. Например, установит значение по умолчанию для отсутствующего тэга как "n/a" или как "отсутствует", для того чтобы без проблем можно было писать те же самые приветствия с перечислением параметров пользователя.

Но тут опять же есть вопрос: можно же сделать глобальные значения по умолчанию для всех скриптов, а можно сделать значения по умолчанию для каждого скрипта в отдельности. Во втором случае, если сделать функцию установки значения по умолчанию, то при старте скрипта можно будет установить нужные значения по умолчанию для текущего скрипта, при этом в других скриптах ничего не сломается.

Может это всё очень надуманно и не стоит этого делать? Или же сделать? И какой из двух вариантов лучше сделать? (склоняюсь ко второму).

По-моему новых параметров плодить не надо, это уже не красиво получается. А с установкой по умолчанию идея хорошая, но нужно это делать для каждого скрипта индивидуально, что мне кажется заморочкой со стороны программы. Я бы сделал вот так:



Таким образом мы всегда имеем значение в поле. В строковых параметрах понятно, если нет значения - то пустая строка, при конкатенациях не надо будет делать проверки на существование строки, а если, допустим, тег равен "", то понятно что он отсутствует. С булевыми переменными тоже лучше обходиться так же, если нет значения - то false, проверки все равно идут без сравнения (if tUser.bConnected ...). Что касается числовых значений, то лучше их перегонять в 0 при отсутствии, т.к. какая разница, ограничение в 0 или оно равно nil, с остальными параметрами аналогично. Я конечно напишу скрипт под каким угодно апи, но так я считаю будет проще всего.

тут есть нюанс. 0 - это означает скорость 0 kb/s, то есть у клиента тотальное ограничение скорости установлено. Это значение не может быть значением по умолчанию!


По поводу удаления всех nil значений для параметров, думаю что это не правильно. Тут в логике будет ошибка. Если пользователь клиента указал значение по умолчанию, а в скрипте для значения по умолчанию мы полагаем отсутствие параметра, то логика нарушается.
В частности nil значения нужны будут для принудительной установки параметров тэга.

Именно поэтому и были предложены тэги с подчёркиванием спереди, так тэги с параметрами по умолчанию.

Реквестую аналог параметра птоки

Тогда уж и пусть запоминает и выдаёт даты максимальной шары (вместе с самой шарой) и максимального количества юзеров (вместе с самим количеством) за всё время работы РусХаба с первого включения и всё то же самое - за текущую сессию.
Этого так сильно не хватало в Птоке.

Сделаю.

Это планируется реализовать в пункте "Функция статистики и информации о сервере" TODO







Есть предложение добавить новую функцию типа Core.AddCmd(sCmd, sFunc)
Эта функция будет оптимизировать обработку команд, так как зачастую почти в каждом скрипте мы парсим команды в событии OnChat. При помощи этой функции можно будет добавлять команду и функцию, которая будет выполняться, если поступила данная команда. Наверное нужно сделать для каждого скрипта свой внутренний список, в который будут добавляться команды, и таким образом, команды с одинаковыми именами смогут существовать в различных скриптах и выполнять различные функции (при поступлении команды).

Введя такую функцию предполагается снять нагрузку на обработку события OnChat.

Пример:


В данном примере в функцию Regme автоматически подставятся аргументы: UID пользователя и tParams - параметры команды
По умолчанию я думаю зашить префиксы команд + и !, и возможно следует сделать функцию, которая будет менять или добавлять префиксы (я пока что ещё с этой идеей не переспал).

Стоит ли это делать я на данный момент не знаю.

я щитаю, что стоит.

Ага, будет очень удобно

Есть подобная фишка в хексхабе, в верли тоже на команду отдельное событие. Я считаю что стоит сделать как с таймерами, т.е. функция типа
Core.AddTrigger("somecmd") будет возвращать айди события, а по событию будет вызываться функция OnTrigger(iId), при указании функции в Core.AddTrigger("somecmd", "SomeCmdFunction"), будет вызываьться функция, переданная вторым параметром. А вот передачу параметров в таблице tParams не считаю удобным т.к. они используются всегда по-разному (порой нужно взять параметры через пробел, порой нужна вся строка), поэтому можно просто передавать строку, идущую за командой.