Предложения для развития |
Здравствуйте, гость ( Вход | Регистрация )
Предложения для развития |
18.1.2010, 19:20
Сообщение
#181
|
|
RusHub team lead Группа: Модераторы Сообщений: 4 030 Регистрация: 20.6.2008 Из: г. Королёв (Моск. обл.) Пользователь №: 46 Спасибо сказали: 1708 раз |
Список пока не реализованных идей и запросов ( todo / future request / change request / improvement ).
ToDo:
|
|
|
1.3.2010, 23:31
Сообщение
#182
|
|
RusHub team lead Группа: Модераторы Сообщений: 4 030 Регистрация: 20.6.2008 Из: г. Королёв (Моск. обл.) Пользователь №: 46 Спасибо сказали: 1708 раз |
Какие предложения по поводу параметров событий OnScriptStart, OnScriptStop и OnScriptRestart ?
|
|
|
1.3.2010, 23:36
Сообщение
#183
|
|
Освоившийся участник Группа: Администраторы Сообщений: 344 Регистрация: 2.6.2008 Из: RB,Ufa Пользователь №: 8 Спасибо сказали: 106 раз |
Хорошо бы к этому всему добавить OnScriptError
|
|
|
1.3.2010, 23:55
Сообщение
#184
|
|
RusHub team lead Группа: Модераторы Сообщений: 4 030 Регистрация: 20.6.2008 Из: г. Королёв (Моск. обл.) Пользователь №: 46 Спасибо сказали: 1708 раз |
Уже давно есть.
|
|
|
2.3.2010, 20:07
Сообщение
#185
|
|
Я коварный Санта Клаус Группа: Пользователи Сообщений: 523 Регистрация: 4.11.2008 Из: Саратов Пользователь №: 985 Спасибо сказали: 54 раза |
Setuper - вот интересная
|
|
|
2.3.2010, 20:37
Сообщение
#186
|
|
RusHub team lead Группа: Модераторы Сообщений: 4 030 Регистрация: 20.6.2008 Из: г. Королёв (Моск. обл.) Пользователь №: 46 Спасибо сказали: 1708 раз |
Технология понятна, однако для такого фокуса нужно чтобы пассивный клиент отсылал команду на соединение с пассивом, но NMDC клиент устроен так, что при соединении с пассивным он не будет ничего отсылать на хаб.
Хотя это можно обойти, предварительно запомнив режим клиента, отсылать всем пользователям хаба не пассивный режим, а активный. А при соединении пользователей сравнивать запомненные режимы. Эта идея летает уже достаточно давно. По всей видимости реализовать можно. |
|
|
3.3.2010, 18:09
Сообщение
#187
|
|
Местный Группа: Неактивированные Сообщений: 908 Регистрация: 26.12.2008 Пользователь №: 1 574 Спасибо сказали: 1406 раз |
Цитата OnScriptRestart А это ещё зачем? Разве не достаточно OnScriptStart и OnScriptStop? Не могу себе представить поведение функции , когда при рестарте в скрипте обнаружилась ошибка. Вызывать OnScriptStop? Или отправлять false в качестве аргумента, и вызывать OnScriptError? ИМХО эта функция добавит мазохизма к и без того хитрозакрученному скриптовому API. |
|
|
3.3.2010, 19:33
Сообщение
#188
|
|
RusHub team lead Группа: Модераторы Сообщений: 4 030 Регистрация: 20.6.2008 Из: г. Королёв (Моск. обл.) Пользователь №: 46 Спасибо сказали: 1708 раз |
Согласен. Событие OnScriptRestart не нужно.
Однако вопрос остаётся открытым. Какие параметры нужны в событиях OnScriptStart и OnScriptStop? Обойтись только именем скрипта? Цитата Не могу себе представить поведение функции , когда при рестарте в скрипте обнаружилась ошибка. Вызывать OnScriptStop? Или отправлять false в качестве аргумента, и вызывать OnScriptError? Не совсем понял. При рестарте в скрипте происходит ошибка, тут же начинает выполняться событие OnError этого скрипта (если оно в нём есть). Если в этом событии ошибка, то скрипт останавливается, в противном случае скрипт останавливается или нет в зависимости от того что возвращает это событие. После этого уже вызываются события OnScriptError во всех остальных скриптах. |
|
|
4.3.2010, 13:10
Сообщение
#189
|
|
Местный Группа: Неактивированные Сообщений: 908 Регистрация: 26.12.2008 Пользователь №: 1 574 Спасибо сказали: 1406 раз |
А зачем там что-либо кроме имени? Для ошибок есть OnScriptError.
Тут важно другое - чтобы функции вызывались так же, как и OnScriptError - без таймера. |
|
|
14.3.2010, 3:18
Сообщение
#190
|
|
Местный Группа: Неактивированные Сообщений: 908 Регистрация: 26.12.2008 Пользователь №: 1 574 Спасибо сказали: 1406 раз |
У меня очередной feature-request:
Функция, возвращающая список настроек. Я думаю, это несложно реализовать. |
|
|
26.7.2010, 10:22
Сообщение
#191
|
|
RusHub team lead Группа: Модераторы Сообщений: 4 030 Регистрация: 20.6.2008 Из: г. Королёв (Моск. обл.) Пользователь №: 46 Спасибо сказали: 1708 раз |
Назрел вопрос об улучшении в следующей версии. Вопрос такой: может ввести дополнительно умные параметры дабы избежать проверок, которые нужно обязательно делать?
Речь тут идёт о параметрах пользователя. Хочу сделать вот что: UID.iSlots = nil, а UID._iSlots = 0. Если не хочется проверять параметр на nil значение, используем безопасный параметр (с подчеркиванием спереди) с чётко определённым значением по умолчанию. Стоит ли это сделать или это бредовая идея?? |
|
|
26.7.2010, 10:56
Сообщение
#192
|
|
AmxModx Scripter Группа: Пользователи Сообщений: 302 Регистрация: 2.12.2008 Из: Королев Пользователь №: 1 283 Спасибо сказали: 127 раз |
Стоит, ведь часто какой-нибудь параметр проверяется на nil, и ему присваивается дефолтное значение
|
|
|
26.7.2010, 11:31
Сообщение
#193
|
|
RusHub team lead Группа: Модераторы Сообщений: 4 030 Регистрация: 20.6.2008 Из: г. Королёв (Моск. обл.) Пользователь №: 46 Спасибо сказали: 1708 раз |
Возможно даже стоит сделать функцию, которой можно будет устанавливать значения по умолчанию для параметров. Например, установит значение по умолчанию для отсутствующего тэга как "n/a" или как "отсутствует", для того чтобы без проблем можно было писать те же самые приветствия с перечислением параметров пользователя.
Но тут опять же есть вопрос: можно же сделать глобальные значения по умолчанию для всех скриптов, а можно сделать значения по умолчанию для каждого скрипта в отдельности. Во втором случае, если сделать функцию установки значения по умолчанию, то при старте скрипта можно будет установить нужные значения по умолчанию для текущего скрипта, при этом в других скриптах ничего не сломается. Может это всё очень надуманно и не стоит этого делать? Или же сделать? И какой из двух вариантов лучше сделать? (склоняюсь ко второму). |
|
|
26.7.2010, 12:22
Сообщение
#194
|
|
Главный ра******й тут... Группа: Главные администраторы Сообщений: 1 727 Регистрация: 18.5.2008 Из: RF, 2la Пользователь №: 1 Спасибо сказали: 776 раз |
По-моему новых параметров плодить не надо, это уже не красиво получается. А с установкой по умолчанию идея хорошая, но нужно это делать для каждого скрипта индивидуально, что мне кажется заморочкой со стороны программы. Я бы сделал вот так:
Цитата sMyINFO = $MyINFO $ALL Nick $ $$$$ iShare = 0 -- от 0 и более, без вариантов sMode = "" -- обычно всегда указывается клиентом, но если нет, значит пустая строка sDesc = "" -- всегда строка, если описания нет, то она пустая sEmail = "" -- аналогично описанию sTag = "" -- аналогично описанию sConn = "" -- аналогично описанию iByte = 0 -- тут если нет я так понимаю автоматом 0, пусть так и будет sClientName = "" -- аналогично описанию sClientVersion = "" -- аналогично описанию iSlots = 0 -- если нету, лучше 0, лишних проверок меньше, да и ошибок будет меньше iUsHubs = 0 -- аналогично слотам iRegHubs = 0 -- аналогично слотам iOpHubs = 0 -- аналогично слотам iLimit = 0 -- аналогично слотам iOpen = 0 -- аналогично слотам iBandwidth = 0 -- аналогично слотам iDownload = 0 -- аналогично слотам sFraction = "" -- аналогично описанию Таким образом мы всегда имеем значение в поле. В строковых параметрах понятно, если нет значения - то пустая строка, при конкатенациях не надо будет делать проверки на существование строки, а если, допустим, тег равен "", то понятно что он отсутствует. С булевыми переменными тоже лучше обходиться так же, если нет значения - то false, проверки все равно идут без сравнения (if tUser.bConnected ...). Что касается числовых значений, то лучше их перегонять в 0 при отсутствии, т.к. какая разница, ограничение в 0 или оно равно nil, с остальными параметрами аналогично. Я конечно напишу скрипт под каким угодно апи, но так я считаю будет проще всего. |
|
|
26.7.2010, 13:27
Сообщение
#195
|
|
RusHub team lead Группа: Модераторы Сообщений: 4 030 Регистрация: 20.6.2008 Из: г. Королёв (Моск. обл.) Пользователь №: 46 Спасибо сказали: 1708 раз |
Цитата iLimit = 0 -- аналогично слотам тут есть нюанс. 0 - это означает скорость 0 kb/s, то есть у клиента тотальное ограничение скорости установлено. Это значение не может быть значением по умолчанию!По поводу удаления всех nil значений для параметров, думаю что это не правильно. Тут в логике будет ошибка. Если пользователь клиента указал значение по умолчанию, а в скрипте для значения по умолчанию мы полагаем отсутствие параметра, то логика нарушается. В частности nil значения нужны будут для принудительной установки параметров тэга. Именно поэтому и были предложены тэги с подчёркиванием спереди, так тэги с параметрами по умолчанию. |
|
|
31.8.2010, 3:25
Сообщение
#196
|
|
Главный ра******й тут... Группа: Главные администраторы Сообщений: 1 727 Регистрация: 18.5.2008 Из: RF, 2la Пользователь №: 1 Спасибо сказали: 776 раз |
Реквестую аналог параметра птоки
Код iLoginTime - User login time in seconds from 1.1.1970
|
|
|
31.8.2010, 4:38
Сообщение
#197
|
|
Белый Волк Группа: Пользователи Сообщений: 1 723 Регистрация: 11.9.2008 Из: г.Томск Пользователь №: 516 Спасибо сказали: 657 раз |
Тогда уж и пусть запоминает и выдаёт даты максимальной шары (вместе с самой шарой) и максимального количества юзеров (вместе с самим количеством) за всё время работы РусХаба с первого включения и всё то же самое - за текущую сессию.
Этого так сильно не хватало в Птоке. |
|
|
31.8.2010, 12:15
Сообщение
#198
|
|
RusHub team lead Группа: Модераторы Сообщений: 4 030 Регистрация: 20.6.2008 Из: г. Королёв (Моск. обл.) Пользователь №: 46 Спасибо сказали: 1708 раз |
Реквестую аналог параметра птоки Сделаю.Код iLoginTime - User login time in seconds from 1.1.1970 Тогда уж и пусть запоминает и выдаёт даты максимальной шары (вместе с самой шарой) и максимального количества юзеров (вместе с самим количеством) за всё время работы РусХаба с первого включения и всё то же самое - за текущую сессию. Это планируется реализовать в пункте "Функция статистики и информации о сервере" TODOЭтого так сильно не хватало в Птоке. Есть предложение добавить новую функцию типа Core.AddCmd(sCmd, sFunc) Эта функция будет оптимизировать обработку команд, так как зачастую почти в каждом скрипте мы парсим команды в событии OnChat. При помощи этой функции можно будет добавлять команду и функцию, которая будет выполняться, если поступила данная команда. Наверное нужно сделать для каждого скрипта свой внутренний список, в который будут добавляться команды, и таким образом, команды с одинаковыми именами смогут существовать в различных скриптах и выполнять различные функции (при поступлении команды). Введя такую функцию предполагается снять нагрузку на обработку события OnChat. Пример: Код function OnStartup() Core.AddCmd("regme", "Regme") end function Regme(UID, tParams) local sPass = tParams[1] if sPass then AddReg(UID.sNick, sPass) end end function AddReg(sNick, sPass) ... end В данном примере в функцию Regme автоматически подставятся аргументы: UID пользователя и tParams - параметры команды По умолчанию я думаю зашить префиксы команд + и !, и возможно следует сделать функцию, которая будет менять или добавлять префиксы (я пока что ещё с этой идеей не переспал). Стоит ли это делать я на данный момент не знаю. |
|
|
31.8.2010, 13:29
Сообщение
#199
|
|
Местная ТехПоддержка Группа: Администраторы Сообщений: 1 875 Регистрация: 18.7.2008 Из: Моск. Обл, г. королев, район Болшево Пользователь №: 221 Спасибо сказали: 220 раз |
я щитаю, что стоит.
|
|
|
31.8.2010, 13:57
Сообщение
#200
|
|
AmxModx Scripter Группа: Пользователи Сообщений: 302 Регистрация: 2.12.2008 Из: Королев Пользователь №: 1 283 Спасибо сказали: 127 раз |
Ага, будет очень удобно
|
|
|
31.8.2010, 20:08
Сообщение
#201
|
|
Главный ра******й тут... Группа: Главные администраторы Сообщений: 1 727 Регистрация: 18.5.2008 Из: RF, 2la Пользователь №: 1 Спасибо сказали: 776 раз |
Есть подобная фишка в хексхабе, в верли тоже на команду отдельное событие. Я считаю что стоит сделать как с таймерами, т.е. функция типа
Core.AddTrigger("somecmd") будет возвращать айди события, а по событию будет вызываться функция OnTrigger(iId), при указании функции в Core.AddTrigger("somecmd", "SomeCmdFunction"), будет вызываьться функция, переданная вторым параметром. А вот передачу параметров в таблице tParams не считаю удобным т.к. они используются всегда по-разному (порой нужно взять параметры через пробел, порой нужна вся строка), поэтому можно просто передавать строку, идущую за командой. |
|
|
Похожие темы
Тема | Ответов | Автор | Просмотров | Последнее сообщение | |
---|---|---|---|---|---|
ВАЖНО: Ваши Вопросы И Предложения По Поводу Форума | 447 | Svyat | 324 797 | 20.10.2015, 19:39 Посл. сообщение: Ksan | |
От: Ваши Вопросы И Предложения По Поводу Форума От темы с ID: 753 |
3 | anila | 9 189 | 28.3.2013, 16:02 Посл. сообщение: настя | |
От: Ваши Вопросы И Предложения По Поводу Форума От темы с ID: 753 |
0 | AntonRibin868 | 5 829 | 13.4.2011, 4:46 Посл. сообщение: AntonRibin868 | |
От: Ваши Вопросы И Предложения По Поводу Форума От темы с ID: 753 |
0 | Ksan | 5 588 | 26.12.2010, 17:39 Посл. сообщение: Ksan | |
От: Ваши Вопросы И Предложения По Поводу Форума От темы с ID: 753 |
1 | Accelerator | 4 842 | 16.1.2010, 15:27 Посл. сообщение: Wariner |
|
Сейчас: 23.12.2024, 17:32 |