Вопросы Разработчикам Скриптов, вопросы по скриптам (мелкие вопросы)

Да.. "как-то так". Но ведь не будешь на все возможные сочетания символов свои захваты городить? Поэтому в примере и используются (%S) - работает, ты ж сам видел. Но вот с окончанием захвата (а может, и с началом?) - проблема.

хм... странно... а тэги этих самых юзеров можешь написать сюда? Надо разобраться из-за чего не происходит захвата.

по поводу повторений в нике думаю, что можно сделать так:

Sephiroth_Lukaw
Ну не знаю, что имел в виду уважаемый докладчик.. Или у меня лыжи совсем уже не едут..))
Запустил в таком виде:

Ну код мне и выдал каждый ник каждого юзера, при каждом входящем майинфо. В чем тут прикол? Что-то не догоняю :(

ну, по идее, регулярки вроде бы всегда медленнее...
P.S.
local _,_,Test=string.find(user.sName, "(.)%1%1%1")
P.P.S.
И вправду, ты всегда, зачем то лишние "" вставляешь
""..user.sName.."" -> user.sName

Действительно, наверное всё же оптимальнее использовать регулярное выражение:

Setuper
Думаешь, дело может быть в тэге?
Мы ж не весь майинфо стринг исследуем, а конкретный юзерский объект...

-есть захват


нет захвата
Кстати, этот захват я попробовал и в ValidateNickArrival, и в NewUserConnected, на всякий случай. Результат тот же.

==============================================================
Ай ребята, ну где ж вы раньше были с таким элегантным и эффективным регулярным выражением ))) Целый день убил, пытаясь захват сделать.

Работает! Может, еще какие-нибудь хитрые выражения есть? (Хабик небольшой, народу немного, нагрузка на ресурсы не бешеная)

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

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


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

А как захватить несколько сообщений юзера? Т.е. если он пишет

его кикало. В моём представлении это можно сделать только конкатацией. Есть ещё какие то варианты и как будет реагировать если между сообщениями этого юзера вклинится сообщения ещё кого то?

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

Wariner, я вот что посоветую... Ковыряй настройки хаба =) Там есть антифлуд. настрой его как надо и все.

Ну хватит говорить лишь бы о чем-то! Речь идет о сообщениях не повторяющихся, но в сумме дающих адрес.
Идеальной антирекламы сделать не получится, т.к. не будет конца извращениям, генерируемым мозгом человека...
В птоке АНТИФЛУД, а это отностится к антирекламе, которую туда еще не влепили.
P.S. удалите сами весь этот "базар"

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

Пока что, в тестовом варианте, проверка юзера идет на трех этапах:
ValidateNickArrival
MyInfoArrival
NewUserConnected
(Насколько я понял, именно в такой последовательности нужно делать, на каждом этапе используя информацию, доступную именно на этом этапе)
Вот есть условие:

которое используется как отменяющее проверку (приписано в начале каждой из трех функций)
Хотелось бы сделать применение условий более гибким, т е создать локальные группы,
а условие, отменяющее проверку и отсылающее к сопоставлению с "членством" в локальной группе, перенести в начало каждой из кучи прикладных функций: NoProxy, OneIP4OneClient, CheckNick, CheckDesc, CheckEmail, и т д, которые, как я где-то писал об этой идее, подключаются по мере необходимости простым раскомментированием имени функции.
например как-то так
локальная группа А = принадлежность к таблицам х, у и/или профилю такому-то...
Что-то мудревато пока получается, в голове не складывается. Может, есть наработки, чтобы не изобретать велосипед?

Setuper
Почему ж все-таки захваты не работают? Я посмотрел крайний захват МайИнфо, который ты привел. В сравнении с моим первый "блином комом", там нет лишнего %S+ , которое я по ошибке поставил между перечислением хабов и слотами. Но все равно работает от раза к разу, то все выдает, то все по нулям. С чем тут еще может быть связано? Речь-то пока ни о каких не левых юзерах, теги всех присутствующих учтены в ClientTags, хотя, стоит крыжик "Принимать тэг от неизвестного клиента за действительный". Может, это баг Птоки такой, забыть и не мучиться? Птока - 0360 LUA 5.1.2

Ты идёшь по моим стопам. Именно такую фишку я реализовал в моём боте, но немного более сложную чем ты предполагаешь сделать, а именно, в базе данных существует таблица с действиями. Таблица состоит из следующих столбцов (строк может быть любое количество): он_офф, Тип_действия, действие, номер_профиля_s, номер_профиля_e, номер_текущего_профиля_s, номер_текущего_профиля_e, ip_s, ip_e, ник.
В таблице указаны действия и их применимость или не применимость к определённой группе. Например, тип_действия=оповещение, действие=вход_с_запрещённых_ip, номер_профиля_s=5, номер_профиля_e=12, номер_текущего_профиля_s=1, номер_текущего_профиля_e=nil, ip_s=nil, ip_e=nil, ник=nil. Таким образом, оповещение о входе пользователя с запрещённым ip поступит профилям, начиная с номера 5, до номера 12, если текущий профиль меньше пятого, однако, если текущий профиль пользователя больше, либо равен пятому, то параметр номер_текущего_профиля_s говорить сколько надо прибавить к текущему профилю, чтобы отсылать оповещений. В данном случае надо прибавить 1, а так как номер_текущего_профиля_e=nil, то последний профиль не изменяется, таким образом, если текущий профиль меньше пятого, то оповещение отправится всем профилям от 5 до 12, иначе оповещение отправится профилям от (текущий_профиль + 1) до 12. Кроме этого, если параметры ip_s, ip_e и ник не указаны, то оповещение отправляется только профилям, если же, например, ip_s=0, ip_e=167772160, то оповещение прийдёт только тем профилям, которым разрешено плюс ip этих пользователей должны будут лежать в диапазоне 0.0.0.0 (=0) - 10.0.0.0 (=167772160), а если ещё указывается и ник, то оповещение отправляется указанному нику, но при условии, что профилю с этим ником разрешена отсылка, и ip адрес этого ника лежит в разрешённом диапазоне.

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

Что касается захватов, то последняя моя функция коррекции должна работать всегда. Как её использовать я тоже прописал.

Setuper
Ясно.. что ничего не ясно
Ну да ладно. Вот есть небольшой вопрос: как организовать разделители в менюшках, если в коде использованы вот такие конструкции?

Сверху этого пункта в меню получается еще три, хотелось бы их отделить, по типу
$UserCommand 0 3

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

Просто пиши уже готовые коды без разделений

Я вот что имел в виду (на картинке)
Тут приведен пример правда из обычного оформления юзерской команды, через сенд дата.
Сверху и снизу меню скрипта погоды обставлено "разделителями" - снизу есть, сверху не получается. (красная линия)
Даже в обычном варианте трудности.
Как тут быть? И тем более, как быть в первом вопросе?

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

Например в твоём случае:
есть менюшка: Объявления, Релизы, Запросы\\Подменю
Если после этой менюшки ставить разделитель, то он появится после "Подменю" а не после "Объявления, Релизы, Запросы", потому что разделитель нельзя вставить между ними, так как они отправляются как единое целое.

Надеюсь ясно изложил?

Setuper

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

2Setuper: если не сложно можешь сказать несколько слов о метатаблицах. Я как всегда несколько не понял описания на http://lua.ru