Архитектура павн от зигги, вопрос

[StevenH]

Прочитал следующую тему про архитекуру в павн от зигги https://ziggi.org/arhitektura-pawn-proekta-dlya-sa-mp/, довольно интересный подход, но у меня возник вопрос. Во допустим делаю работу таксиста, и допустим мне надо задействовать стандартный паблик OnPlayerConnect, как быть, если он допустим будет использоваться и в другом pwn файле (например в работе механика)? Ведь в таком случае компилятор выдаст ошибку, что паблик уже используется

[Nexius_Tailer]

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

- - - Добавлено - - -

А, ну ещё y_hooks как альтернатива первому варианту

[SooBad]

А, ну ещё y_hooks как альтернатива первому варианту
В чём смысл подключать весь комплекс YSI, только ради одних хуков? (Ну, только если автор его не использует)
Следовательно, тогда и все остальные перехваты придётся перестраивать.

[Nexius_Tailer]

В чём смысл подключать весь комплекс YSI, только ради одних хуков? (Ну, только если автор его не использует)
Следовательно, тогда и все остальные перехваты придётся перестраивать.
Кому-то может быть так удобнее, это ж один из вариантов

[StevenH]

Кому-то может быть так удобнее, это ж один из вариантов

Не хочется использовать библиотеку YSI, не знаю почему))

[DeimoS]

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

Вот лучший вариант.

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

Вот пример того, как я строю архитектуру проекта


.../gamemode/new.pwn
_
.../pawno/pawncc.exe
_
.../pawno/include/стандартные инклуды
_
.../pawno/source/lib/все сторонние инклуды (streamer и т.п.)
_
.../pawno/source/core/dialog_handler.inc
_
.../pawno/source/player/commands.inc
.../pawno/source/player/account/account_system.inc
.../pawno/source/player/account/ban_system.inc
.../pawno/source/player/message/chat_system.inc
_
.../pawno/source/admin/commands.inc
.../pawno/source/admin/admin_system.inc//Всё, что связано с авторизацией админов
.../pawno/source/admin/message/chat_system.inc

Подключение стандартных инклудов происходит обычным образом:

#include "a_samp.inc"
//или
#include <a_samp.inc>

А подключение всего остального уже идёт так:

#include "../source/account/account_system.inc"

Но это, кстати, не реальная структура, а лишь наброски того, как можно всё разделять, не ломая, при этом, стандартную структуру SA-MP

UPD: И да, эта архитектура основана на архитектуре Ziggi. Просто слегка переработана под собственные нужды

[StevenH]

Вот лучший вариант.

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

Вот пример того, как я строю архитектуру проекта


Но это, кстати, не реальная структура, а лишь наброски того, как можно всё разделять, не ломая, при этом, стандартную структуру SA-MP

UPD: И да, эта архитектура основана на архитектуре Ziggi. Просто слегка переработана под собственные нужды

Спасибо, ведь по сути, например при коннекте, каждый раз будешь вызываться этот самый сток из файла, не затратно ли это?

[SooBad]

Спасибо, ведь по сути, например при коннекте, каждый раз будешь вызываться этот самый сток из файла, не затратно ли это?

Это же инклюд... :rofl:
Не путай с вызовом коллбеков из фс.

[ziggi]

Спасибо, ведь по сути, например при коннекте, каждый раз будешь вызываться этот самый сток из файла, не затратно ли это?

Это на столько незначительная трата, что ей можно пренебречь. Думай об оптимизации алгоритмов, а не языковых конструкций.

[StevenH]

Это же инклюд... :rofl:
Не путай с вызовом коллбеков из фс.

Кто сказал что это все я буду делать в инклуде? Это будут pwn файлы, подключаемые из главного pwn файла.

- - - Добавлено - - -


Это на столько незначительная трата, что ей можно пренебречь. Думай об оптимизации алгоритмов, а не языковых конструкций.

Спасибо, буду пробовать такую конструкцию)

- - - Добавлено - - -


Это на столько незначительная трата, что ей можно пренебречь. Думай об оптимизации алгоритмов, а не языковых конструкций.

И еще один вопрос, например если краш детект покажет что где то происходит выход за пределы массива, каким образом он покажет строку ошибки (где происходит выход за пределы массива)?

[DeimoS]

Спасибо, ведь по сути, например при коннекте, каждый раз будешь вызываться этот самый сток из файла, не затратно ли это?

С такими вопросами легче вообще код не писать, дабы никаких затрат не было :)
У любых действий есть затраты. Но помимо затрат есть и польза. От неё и отталкивайся всегда: будь то программирование или что-либо ещё.



Кто сказал что это все я буду делать в инклуде? Это будут pwn файлы, подключаемые из главного pwn файла.


Да хоть ".exe" подключай - без разницы. Директива include вставит содержимое файла с любым расширением. Просто если это не ".pwn", ".p" или ".inc", то расширение нужно указать вручную (не получится просто написать "#include <name>")



И еще один вопрос, например если краш детект покажет что где то происходит выход за пределы массива, каким образом он покажет строку ошибки (где происходит выход за пределы массива)?

Таким же, как и обычно. С параметром "-d3" в ".amx" файл попадает достаточно информации о том, что за файл и какая строка.