Один большой файл или отдельные плагины?

[gnull]

Какой подход выбрать? Плюсы и минусы?
1. Разбить код (модули, системы) на инклюды и подключить в один главный файл для управления всем
2. Каждую систему/модуль писать как отдельный плагин и взаимодействовать через api

p.s. модулей или систем может быть множества...

 

[7RG]

1) Один главный плагин + #include модулей​

Плюсы

• Просто стартовать и дебажить в начале.
• Прямой доступ к общим данным без API-слоя.
• Меньше накладных расходов на коммуникацию между плагинами.

Минусы

• Со временем превращается в монолит: сложно поддерживать.
• Любая ошибка/краш бьет по всему сразу.
• Релоад/обновление только целиком.
• Тяжелее параллельно работать нескольким людям.

2) Каждый модуль отдельным плагином + взаимодействие через API (natives/forwards)​

Плюсы

• Изоляция: упал модуль — остальное живет.
• Можно релоадить и обновлять частями.
• Масштабируется лучше при большом количестве систем.
• Четкие границы ответственности.

Минусы

• Нужно проектировать API и версии.
• Больше инфраструктуры (проверки зависимостей, fallback-логика).
• Сложнее первый запуск.

 

[ZooM4322]

1) Один главный плагин + #include модулей​

Плюсы

• Просто стартовать и дебажить в начале.
• Прямой доступ к общим данным без API-слоя.
• Меньше накладных расходов на коммуникацию между плагинами.

Минусы

• Со временем превращается в монолит: сложно поддерживать.
• Любая ошибка/краш бьет по всему сразу.
• Релоад/обновление только целиком.
• Тяжелее параллельно работать нескольким людям.

2) Каждый модуль отдельным плагином + взаимодействие через API (natives/forwards)​

Плюсы

• Изоляция: упал модуль — остальное живет.
• Можно релоадить и обновлять частями.
• Масштабируется лучше при большом количестве систем.
• Четкие границы ответственности.

Минусы

• Нужно проектировать API и версии.
• Больше инфраструктуры (проверки зависимостей, fallback-логика).
• Сложнее первый запуск.

Чаво?

 

[7RG]

Чаво?

монолит против модульности
Чаво = архитектура :)
Монолит удобен на старте, модульность удобна на дистанции.
Когда систем много, API-подход обычно выигрывает по поддержке.

 

[sauntside]

@7RG, чатгпт умеете, могете

 

[7RG]

@7RG, чатгпт умеете, могете

Мимо.

 

[DarkerZ]

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

 

[ZooM4322]

1) Один главный плагин + #include модулей​

Плюсы

• Просто стартовать и дебажить в начале.
• Прямой доступ к общим данным без API-слоя.
• Меньше накладных расходов на коммуникацию между плагинами.

Минусы

• Со временем превращается в монолит: сложно поддерживать.
• Любая ошибка/краш бьет по всему сразу.
• Релоад/обновление только целиком.
• Тяжелее параллельно работать нескольким людям.

2) Каждый модуль отдельным плагином + взаимодействие через API (natives/forwards)​

Плюсы

• Изоляция: упал модуль — остальное живет.
• Можно релоадить и обновлять частями.
• Масштабируется лучше при большом количестве систем.
• Четкие границы ответственности.

Минусы

• Нужно проектировать API и версии.
• Больше инфраструктуры (проверки зависимостей, fallback-логика).
• Сложнее первый запуск.

Хоть иногда перечитывали что вы копируете с чатгпт! Смысл вроде более менее понятен, что вы скопировали от туда, но подача публике, реакция "Чаво? "

 

[Nekro]

Какой подход выбрать?

модулей или систем может быть множества...

Зависит от задачи и требований, соответственно выбираются и подходы

 

[7RG]

Хоть иногда перечитывали что вы копируете с чатгпт! Смысл вроде более менее понятен, что вы скопировали от туда, но подача публике, реакция "Чаво? "

Если что-то не так, поправь по сути: где именно ошибка в тезисах?

 

[ZooM4322]

Если что-то не так, поправь по сути: где именно ошибка в тезисах?

Уже ничего, прости если что-то не так сказал, плохо увидел, проснулся просто недавно! Все гуд, придирок нет

 

[gnull]

если на старте выбрать главный плагин + #include модулей, в будущем болезненно будет переписывать большие модули на отдельные плагины?
я просто не понимаю, зачем писать отдельные плагины под свой "мод с нуля", если данные будут общими и каждый отдельный модуль будет заточен под систему, которая есть. Другое дело написать плагин и выкинуть в сеть для других.

 

[goldfish]

не слушай никого, качни сразу любые плагины на любом синтаксисе и любой версии с AM, скопипасть в один файл, сохрани и компиль
профит 200%

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

 

[Nebraska]

Какой подход выбрать? Плюсы и минусы?
1. Разбить код (модули, системы) на инклюды и подключить в один главный файл для управления всем
2. Каждую систему/модуль писать как отдельный плагин и взаимодействовать через api

p.s. модулей или систем может быть множества...

Микросервисный подход уместен, если речь идет про enterprise - проекты, где каждый микросервис существует независимо от других и в этом действительно есть необходимость (масштабируемость, отказоустойчивость)

В данном случае, уместнее будет придерживаться первого пункта (глупо заморачиваться, учитывая предметную область)

 

[goldfish]

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

 

[Synd1qate]

Одним большим или модулями, представим, что у тебя проект(плагин) в 2к строк, как думаешь, что лучше? Конечно модульность, намного проще редактировать какую то нужную часть, нежели править напрямую в коде где много строк. И так по сути в любой системе.
А так лучше взаимодействовать через api

 

[Grey83]

скопипасть в один файл, сохрани и компиль
профит 200%

не скомпилится
как минимум из-за дублирования OnPluginStart()

Сообщения автоматически склеены: 11 Мар 2026

@Synd1qate, без IDE многофайловые исходники ковырять очень неудобно.

Мой Revival в последних версиях имеет чуть больше 2000 строк, кстати.

Сообщения автоматически склеены: 11 Мар 2026

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

В результате компиляции это один файл или несколько?

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

Сообщения автоматически склеены: 11 Мар 2026

Какой подход выбрать?

а какой автомобиль лучше: болид формулы 1 или карьерный самосвал БелАЗ?

Подход определяется по тому, что должно быть в результате.

 

[gnull]

я имею ввиду условно

/scripting/main.sp будет содержать OnPluginStart, OnClientAuthorized, OnMapStart, OnClientPutInServer и т.д. и т.п.
+ будет подключать другие sp-файлы, например,

/scripting/mymode/dataplayer/data_main.sp - основные данные игрока (steamid, donate, vip, adminLevel итд)
/scripting/mymode/dataplayer/data_stat.sp - статистика игрока
/scripting/mymode/events/player_death.sp - тут уже логика различная, например увеличить кол-во убийств у переменной в data_stat.sp
/scripting/mymode/events/player_spawn.sp - аналогично различная логика
/scripting/mymode/events/weapon_fire.sp - аналогично различная логика
/scripting/mymode/system/database.sp - разные функции по работе с бд

все это будет подключаться в main.sp (точка входа), понятное дело, вы пишите, что код разрастется, то все разбито на части, и легко найти что за что отвечает.

@Grey83, @Synd1qate, @Nebraska, @7RG,

 

[goldfish]

Если один, то это монолит, а если несколько - то должно быть ядро с модулями (иначе это просто куча независимых плагинов)

насчет ядра и модулей, как это выглядит? просто отдельный плагин с нативами?

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

Но в любой момент можно ограничить функционал общей группы плагинов удалением одного из его "модуля"

правда и звучит както по нубски, не бейте сильно)

 

[ZooM4322]

я имею ввиду условно

/scripting/main.sp будет содержать OnPluginStart, OnClientAuthorized, OnMapStart, OnClientPutInServer и т.д. и т.п.
+ будет подключать другие sp-файлы, например,

/scripting/mymode/dataplayer/data_main.sp - основные данные игрока (steamid, donate, vip, adminLevel итд)
/scripting/mymode/dataplayer/data_stat.sp - статистика игрока
/scripting/mymode/events/player_death.sp - тут уже логика различная, например увеличить кол-во убийств у переменной в data_stat.sp
/scripting/mymode/events/player_spawn.sp - аналогично различная логика
/scripting/mymode/events/weapon_fire.sp - аналогично различная логика
/scripting/mymode/system/database.sp - разные функции по работе с бд

все это будет подключаться в main.sp (точка входа), понятное дело, вы пишите, что код разрастется, то все разбито на части, и легко найти что за что отвечает.

@Grey83, @Synd1qate, @Nebraska, @7RG,

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