Нужен ваш взгляд изнутри или "С чего начать и как продолжить?"
#1

Доброй ночи вызвавшимся помочь да и тем кто просто читает топик...

Понимаю что вопрос заезженный до изнеможения, но все же, отложите в сторону кирпичи и тухлые яйца..
В общем, за неделю проведенную за книгой от Cloud`а и в компиляторе, кое в чем разобрался но все же есть пара глобальных вопросов которые считаю нужным затронуть сейчас а не изучать язык по урокам(по большей части сомнительным урокам)
Итак..
1. В чем разница между GM и FS(Что стоит реализовывать на FS а что внутри GM(Если конечно такой вопрос можно поставить))
2. Чем является оптимизация кода?(Увы не могу понять как отличается ГМ скажем на 500кб от 450кб с абсолютно одинаковым функционалом)
3. Использование mysql_tquery или orm сценариев?(Т.к речь зашла об orm - как прикручивать к сценарию защиту от инъекций mysql_escape_string, и вообще необходима ли она в сценарии?)
4. Командный процессор: ZCMD, DC_CMD, или же вообще обойтись без него?
5. Какие плагины стоит взять на изучение и вооружение?
6. PVar или строка в Enum массиве для хранения bool`ов типа "IsLogged", "IsLoggedAsAdmin"?

Благодарю всех кто прочел и/или дал хоть какой то ответ
Reply
#2

Доброй ночи.
Попробую ответить:
Код:
1. GM - игровой мод, в то время как FS - дополнительные скрипты.
    С точки зрения работы, отличия между ними:
    -  При инициализации и выгрузке используются разные Callback'и 
       (OnFilterScriptInit -> OnGameModeInit, OnGameModeExitOnFilterScriptExit
    - SA-MP позволяет поочередно и по кругу запускать до 16 GM
    - FS может быть запущено несколько, одновременно, в то время как GM может быть запущен 
      только один
    - Некоторые нюансы, связанные с OnRcon... в GM

    По сути, все, что необходимо знать - FS может использоваться вместе с любыми GM, в то время 
    как GM - сам по себе. 
    GM отвечает за основное назначение сервера, в то время как FS - за какие-то доп. возможности. 
    Было задумано так, чтобы администратор мог подключить / отключить FS в любой момент, во 
    время выполнения GM.

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

3. На счет orm - тут только мое мнение.
    Я не использовал никакие сценарии, потому как PAWN совсем к этому не располагает. Подробнее, 
   может, кто-то другой расскажет.

4. Командный процессор обычно нужен для бОльшей чистоты кода, нежели для оптимизации программы.
    Лично я использовал ZCMP и SSCANF2 - удобно, и никак не связывает руки.
    Пользователь не так часто вводит команды, чтобы серьезно задумываться микро-оптимизацией 
    их обработки. Мой совет - выберите то, что вам удобнее.

5. Имхо:
    - Стример, как неотъемлемая часть серьезного мода (у меня стоит плагин от Incognito)
    - Тот же SSCANF (я использовал его при обработке команд, отличный парсер)
    - Для отладки я просто скачал и подключил два плагина - nativechecker и crashdetect - полезны 
    в том случае, когда возникают какие-то ошибки, или когда сервер по непонятным причинам падает.
    
6. Так как в PAWN нет ничего, кроме CELL, даже используя самую маленькую переменную под bool, 
    вы займете 4 байта памяти. 
    Я перенес такие boolean-значения в массив игроков, воспользовавшись конструкцией enum. 
    Не могу сказать точно, что быстрее и лучше - здесь уж каждый при своем мнении, но я не 
    рискнул использовать PVar, потому как подозреваю, что при каждом обращении к переменной 
    через такие функции, идет поиск по массиву текстовых значений - названий переменных (другое 
    дело фиксированный массив, где просто рассчитывается смещение и считывается число, без 
    каких-либо строк).
Хорошие вопросы, кстати.
Не сочтите меня человеком знающим, а то люди посмотрят на мое количество сообщений и опять начнут негодовать.
Reply
#3

therainycat, большое спасибо за развернутый ответ.
По 1-му вопросу: суть я понимаю, но я не могу понять, зачем мне много ФС , если весь код неплохо может ужиться в 1-ом ГМ? И если я правильно все понял то такое распределение: Подключение к БД в каркасе(ГМ) а сам код, каким бы он не был, скажем, система авторизации регистрации в FS; не сказывается отрицательно на работе режима в целом?

По 2-му: Не могли бы вы предоставить ссылки на какую то литературу или топики по этому поводу?

Жду еще ответов
Reply
#4

fr1run, Ну если очень просто говорить, то в GM размещаете всё игровое, в том числе систему аккаунтов, домов, машин, миссии, всю логику работы сервера...
В FS размещаете разные дополнения, которые не связанны с GM, например web-карта, какие-нибудь утилиты для скриптинга, например TextDrawEditor. У меня в FS работают боты, связь с сайтов, бан по IP. так-же я отлаживаю новый код в FS на боевом сервере, т.к. есть возможность загрузить\выгрузить скрипт без перезапуска сервера.

Так-же нужно понимать механизм работы GM и FS. Все они работают на разных потоках, если я ничего не путаю.
... Всё таки путаю. Всё работает на одном потоке, и если, например в FS будет бесконечная рекурсия, то повиснет всё....
Reply
#5

1. Дополняю: необязательно подключать ФС, код из них можно разобрать и воткнуть в ГМ.
2. Оптимизация обычно заключается на уход от кастомных функций, работающих через костыли (PlayerToPoint -> IsPlayerInRangeOfPoint, напрмер), от логических ошибок, переполнений динамической памяти, просадки ФПС даже.
4. Надо смотреть независимые стресс-тесты. Сейчас самый быстрый dc_cmd. Я вообще КП не пользуюсь, но zcmd УЖЕ не рекомендую.
5. Я стараюсь скриптить без плагинов, но в результате реализации некоторых идей возникают конкретные потребности: при превышении лимита объектов юзаю стример от Incognito, при работе с MySQL - соответствующий плагин (рекомендую тот, который ещё поддерживается). Всякие крашдетекты не использую, т.к. все коды пишу сам, а следовательно момент "не понятно от чего упал" отсутствует в принципе.
6. Данные, которые необходимо очищать при выходе игрока, да и вообще любые НЕтекстовые удобнее хранить в PVar'ах. Да, они немного медленнее, но на работе мода не скажется. Я делал очень быстрые таймеры с просчётом на PVar - отлично работало. Текст удобнее в массивах хранить и использовать, но разница тут только в кол-ве строк инициализации (pvar - 3, массив - 1).
Reply
#6

Quote:

но zcmd УЖЕ не рекомендую

чем он плох стал?
Quote:

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

оттого, что код написан своими руками - не значит, что в нём нет никаких ошибок. Вот происходит где-то деление на 0, выход за границы массива, обращение к отрицательному индексу и т.д - как их распознать-то? По неведомым лохнесским багам? Ведь крашдетект создан не только для определения причины падения сервера, но и также определение ошибок во время выполнения кода. Про возможные уязвимости в коде (а также уязвимости самого сервера), которые могут привести к крашу сервера - тоже очень будет полезен данный плагин. Насчёт стримера - без него вообще никуда, особенно, если сервак с онлайном. Оптимизация для игроков будет "во", потому что самп - любительский мод, в некотором плане нестабилен, и регулярно что-то где-то крашится по неведомым причинам. Как показывает практика, динамически подгружающиеся пикапы, объекты, 3D тексты будут куда лучше, чем они будут все разом при входе загружаться.
Reply
#7

К вопросу PVar или переменные:
PVar'ы, конечно, удобные, но я бы не рекомендовал их использовать. Ибо при правильном написании кода смысла в их использовании нет.

Не трудно догадаться, что выглядит более изящно:
pawn Код:
if (IsPlayerLogged(playerid)) {
}
или
pawn Код:
if (IsLogged[playerid]) {
}
pawn Код:
if (GetPlayerAge(playerid) < 18) {
}
или
pawn Код:
if (PlayerInfo[playerid][Age] < 18) {
}
Я к тому, что лучше всего делать функциональную обёртку для нужных переменных. Это красиво, это удобно и в будущем, если будет желание перейти на PVar или переменные - это будет просто сделать.
Reply
#8

Quote:
Originally Posted by DartfoL
Посмотреть сообщение
чем он плох стал?
Скоростью?


Quote:
Originally Posted by DartfoL
Посмотреть сообщение
оттого, что код написан своими руками - не значит, что в нём нет никаких ошибок.
Если моими - то значит. Где есть деление на 0 или выход за пределы массива можно найти без проблем.
Reply
#9

По тестам OKStyle выполнение одной команды без командных процессоров будет 0,007 мс. Да, определённо нужна оптимизация! Все эти ваши командные процессоры - полный бред и нужны разве что настоящим извращенцам с миллионами команд в моде.
Reply
#10

Quote:
Originally Posted by XemyL
Посмотреть сообщение
По тестам OKStyle выполнение одной команды без командных процессоров будет 0,007 мс. Да, определённо нужна оптимизация! Все эти ваши командные процессоры - полный бред и нужны разве что настоящим извращенцам с миллионами команд в моде.
Да даже если у тебя миллион команд в моде, 500 человек не будут их вызывать так, как вызывает цикл. И нагрузки от них будет гораздо меньше, чем об этом кричат. Но нет, есть же тесты! И всем плевать, что в тесте цикл вызывает команду по 10000 раз за несколько миллисекунд. Прямо жизненный тест.
И конечно же, если команды написаны криво, командный процессор поможет!
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)