Вопросы по RusHub, Технические вопросы

летает успехов в разработке! уверен проект будет успешным!

А почему нет ни слова про отличительные особенности? Перспективы? Преимущества?
На чём движок,кстати?

Пока что почти полностью реализовал протокол. В перспективе подключить мускул, сделать веб-морду и удалённое управление.
Преимущество - достаточно высокая оптимизация.
Написано на vs 2008 или vs 2005 без разницы

Работает отлично! Про функционал конечно "Москва не сразу строилась" будем ждать новых версий.
Setuper респект!

А при чём тут qt, если гуй не нужен?

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

Илюх, не сочти за наглость, но может все надпись сделаешь на русском? Раз это русский хаб то пусть всё будет по нашему! Думаю стоит продвигать наш язык))))

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

Вопрос зачем иметь две функции при входе юзера(в момент захода и при окончательном заходе) что это даёт?

Функция OnUserEnter - это аналог функции птохи UserConnected.
Функция OnUserConnected - это функция, которая выполняется самой первой при входе. Выполняется после отправки клиенту команды $Lock и до любых других действий. В птохе некий аналог этой функции SupportsArrival. Однако, функция SupportsArrival не будет выполняться, если клиент не поддерживает характеристики и дополнения. Так как это первоначальный этап входа, то на данном этапе определён только ip адрес.

Собственно техпорсы предлагаю пенренести сюда, оставив в теме RusHUB только багрепорты и новости в новых версиях.

Можно разъяснений по поводу работы функции
а именно вот этих 2 показателей:
что вообще есть пользовательские данные и должен ли юзер при смене данных о нахождении в оплисте туда попадать или исчезать оттуда, по моим маленьким тестам если выставить bInOpList в true при том что юзер онлайн, юзер не попадает в оплист, и при изменении bInOpList с true на false тоже никаких действий нет, юзер так и остается в оплисте. Так и должно быть? По-моему будет удобно если хаб будет сам выполнять данные операции по вводу и выводу из оплиста юзера.

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

Core.SetUser(UID, 4, true) до входа (после получения пароля) вносит пользователя в лист операторов (устанавливает ключик).


Пример из скрипта регистрации:
Хотя действительно нужно сделать эту возможность не только при входе (не только до добавления пользователя в списки). В следующем релизе сделаю.

Можно ли добавить функцию, или реализовать скриптом аналог этого из птоки.
Возможно с этим введение, решилась бы проблема со входом на хаб пользователей с никами ботов.

Можно.
Записал себе в TODO

Хочу узнать, а зачем делать функции которые возвращают всегда статичные данные пока хаб работает? Я про фукнции может лучше определить некоторые переменные в таблице Core типа чтобы не делать лишних вызовов функций? По-моему так удобнее, логичнее и разумнее.

Да, действительно. В следующей версии плагина сделаю.

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

я думаю это не страшно)))

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

Еще один вопрос: в своем хабе PPK сделал разделение таблиц в которых хранятся функции апи, к примеру Core, SetMan, BanMan etc... Будет ли оптимальней сделать так или же не критично что все функции хранятся в одной таблице?

Разные таблицы он сделал только для логического разделения. Вообще без разницы в нескольких таблицах хранить или в одной. Единственное, разница есть в оптимизации таблиц: легче написать для одной таблицы local Core = Core, чем перебирать все таблицы. Да и запомнить легче одну таблицы, а не вспоминать какой таблице принадлежит та функция, которую мы хотим использовать. Кроме этого, за хабом мы закрепляем одну таблицу, а остальные таблицы мы закрепляем за различными модулями, - вот вам и логическое разделение. Core - функции хаба, Ban - функции модуля бана и тд.