БИБЛИОТЕКА NurRage

[Slava1]

Ребят, всем привет.
Хотели поделиться библиотекой NurRage — может, кому-то поможет в разработке.
Делали её, чтобы немного упростить код и работу с сервером.

Будем дальше улучшать и добавлять новые возможности.
Спасибо всем, кто посмотрит

https://nurrage-lib.gitbook.io/nurrage-lib-docs

https://nurrage-lib.gitbook.io/nurrage-lib-docs

 

[XDeveluxe]

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

 

[Slava1]

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

Спасибо большое!
Да, изначально библиотека задумывалась так, чтобы упростить разработку и сократить рутину особенно полезно новичкам, но мы стараемся сделать её удобной и для опытных разработчиков.
В будущем добавим больше гибкости и инструментов под разные уровни.

 

[UchihaMadara]

Прикольно. Только наверно не хватает UI конструктора, на котором можно было собирать быстренький прототип.
Ну и такое решение, где одна менюшка = один Browser, лично мне кажется неоптимизированным.

 

[akudinov28]

Ни в коем случае не хочу сказать, что штука бесполезная. Под капот не смотрел, но в теории может как минимум помочь новичкам, которые реально хотят разобраться, понять как писать код на рейдже. Другое дело, что логика реализации в некоторых моментах вызывает вопросы. Например команды. Как будто весь смысл в унификации и стандартизации, чтобы в итоге в любой ситуации работать с одним объектом. Однако, как мы все понимаем, будет слишком много разных проверок и сценариев использования для разных случаев. В одном случае нужно создать блип, только если его еще нет, в другом случае нужен каждый раз новый блип. При создании машины может в одном случае потребоваться запуск таймера на ее удаление через время, в другом случае нужно посадить в нее инициатора команды, в третьем нужно вообще посадить в нее npc и пустить машину по маршруту. В итоге всё равно все сведется к использованию коллбэка action, а значит к отсутствию необходимости в использовании всех этих createVehicle, createObject и т.д., так как расширение списка checker приведет рано или поздно к разрастанию его до монструозного размера. Что до проверок, то как по мне, тут где-то было гораздо более элегантное решение middleware’s на базе декораторов. И это подводит меня еще к одной мысли: если уж стандартизировать код и облегчать его чтение и переиспользование, то начать стоит с перехода на typescript.

 

[akudinov28]

Прикольно. Только наверно не хватает UI конструктора, на котором можно было собирать быстренький прототип.
Ну и такое решение, где одна менюшка = один Browser, лично мне кажется неоптимизированным.
Посмотреть вложение 22454

В принципе, это легко переписывается на любую библиотеку с роутером. Вместо создания нового браузера редирект на нужную страницу, проигрывание звуков и прочие плюшки - через вызов нужной функции в браузере с передачей имени нужного звука, ну и так далее.

 

[Slava1]

Прикольно. Только наверно не хватает UI конструктора, на котором можно было собирать быстренький прототип.
Ну и такое решение, где одна менюшка = один Browser, лично мне кажется неоптимизированным.
Посмотреть вложение 22454

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

 

[Slava1]

Ни в коем случае не хочу сказать, что штука бесполезная. Под капот не смотрел, но в теории может как минимум помочь новичкам, которые реально хотят разобраться, понять как писать код на рейдже. Другое дело, что логика реализации в некоторых моментах вызывает вопросы. Например команды. Как будто весь смысл в унификации и стандартизации, чтобы в итоге в любой ситуации работать с одним объектом. Однако, как мы все понимаем, будет слишком много разных проверок и сценариев использования для разных случаев. В одном случае нужно создать блип, только если его еще нет, в другом случае нужен каждый раз новый блип. При создании машины может в одном случае потребоваться запуск таймера на ее удаление через время, в другом случае нужно посадить в нее инициатора команды, в третьем нужно вообще посадить в нее npc и пустить машину по маршруту. В итоге всё равно все сведется к использованию коллбэка action, а значит к отсутствию необходимости в использовании всех этих createVehicle, createObject и т.д., так как расширение списка checker приведет рано или поздно к разрастанию его до монструозного размера. Что до проверок, то как по мне, тут где-то было гораздо более элегантное решение middleware’s на базе декораторов. И это подводит меня еще к одной мысли: если уж стандартизировать код и облегчать его чтение и переиспользование, то начать стоит с перехода на typescript.

Спасибо большое за развёрнутый фидбек
Полностью согласен сейчас рассчитан больше на упрощение и ускорение базовой разработки, чтобы сократить время на рутину.
Идея с middleware и декораторами действительно интересная, возможно, в будущих версиях реализуем через TypeScript слой или модульную систему действий.
Мы продолжаем улучшать библиотеку и пробуем разные подходы, чтобы сделать её более гибкой и масштабируемой))

 

[akudinov28]

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

Могу дать один совет. Был один фреймворк еще на альтв, назывался Athena. Писал его один из бывших разработчиков, собственно, самого альтв. Изначально фреймворк задумывался как фреймворк, то есть библиотека, помогающая стандартизировать, унифицировать и упростить написание кода. Вот только все пошло не по плану. Были энергия, время и желание фреймворк расширять, было очень много запросов от коммьюнити, и все пошло как снежный ком. Хотели упростить работу с БД - пришлось интегрировать заранее предопределенную СУБД (монго). Хотели упростить и унифицировать работу с интерфейсами - пришлось интегрировать заранее предопределенную библиотеку (vuejs). И так далее. Думаю, посыл ясен. В итоге вместо фреймворка, упрощающего написание кода и поощряющего уклон в творчество и полет мысли, получился фактически готовый игровой мод, ограничивающий во многом кастомизацию из-за своего строгого апи. Причем проблема вышла настолько серьезной, что разработчику было проще забросить Athena и писать с нуля новый фреймворк rebar, о чем он сам объявил, и уже даже выпустил его в свет. Учитывайте чужие ошибки)))

 

[Slava1]

Могу дать один совет. Был один фреймворк еще на альтв, назывался Athena. Писал его один из бывших разработчиков, собственно, самого альтв. Изначально фреймворк задумывался как фреймворк, то есть библиотека, помогающая стандартизировать, унифицировать и упростить написание кода. Вот только все пошло не по плану. Были энергия, время и желание фреймворк расширять, было очень много запросов от коммьюнити, и все пошло как снежный ком. Хотели упростить работу с БД - пришлось интегрировать заранее предопределенную СУБД (монго). Хотели упростить и унифицировать работу с интерфейсами - пришлось интегрировать заранее предопределенную библиотеку (vuejs). И так далее. Думаю, посыл ясен. В итоге вместо фреймворка, упрощающего написание кода и поощряющего уклон в творчество и полет мысли, получился фактически готовый игровой мод, ограничивающий во многом кастомизацию из-за своего строгого апи. Причем проблема вышла настолько серьезной, что разработчику было проще забросить Athena и писать с нуля новый фреймворк rebar, о чем он сам объявил, и уже даже выпустил его в свет. Учитывайте чужие ошибки)))

Спасибо огромное
Очень ценю, что поделились этим опытом как раз стараюсь не сделать из NurRage монстра, который всё ограничивает.
Основная идея чтобы библиотека оставалась лёгкой и гибкой, а разработчик сам решал, какие части подключать.
Такие советы очень помогают, спасибо большое за внимание и за пример с Athena)))

 

[ash]

Могу дать один совет. Был один фреймворк еще на альтв, назывался Athena. Писал его один из бывших разработчиков, собственно, самого альтв. Изначально фреймворк задумывался как фреймворк, то есть библиотека, помогающая стандартизировать, унифицировать и упростить написание кода. Вот только все пошло не по плану. Были энергия, время и желание фреймворк расширять, было очень много запросов от коммьюнити, и все пошло как снежный ком. Хотели упростить работу с БД - пришлось интегрировать заранее предопределенную СУБД (монго). Хотели упростить и унифицировать работу с интерфейсами - пришлось интегрировать заранее предопределенную библиотеку (vuejs). И так далее. Думаю, посыл ясен. В итоге вместо фреймворка, упрощающего написание кода и поощряющего уклон в творчество и полет мысли, получился фактически готовый игровой мод, ограничивающий во многом кастомизацию из-за своего строгого апи. Причем проблема вышла настолько серьезной, что разработчику было проще забросить Athena и писать с нуля новый фреймворк rebar, о чем он сам объявил, и уже даже выпустил его в свет. Учитывайте чужие ошибки)))

Лол, rebar такой же кусок кала как и была athena что v4 что v5, всю ее переписал несколько раз с нуля, и v3 и v4 и v5 под себя потому что просто не возможно было использовать фреймворк, каждый раз переделывали все апи раз в год, нахуя? стало лучше? нихуя! Плагины которые были на v4 по моему все на v5 уже не работали без адаптации. В итоге на столько говно сделали несколько раз, что автор решил что нужно сделать еще одно новое говно rebarV с модным апи такое же но только меньше только самое важно, если вы смотрели сорсы а я смотрел уж поверьте вы поймете что там тупо было с атены скопировано почти 1в1 очень много и только то как вы имеете к этому доступ изменилось потому ну там есть свои заебы с модулями и импортами в js но что бы 3 раза сделать реврайт фремворка из за этого не понимания... В итоге это все равно кусок *** причем ну если подумать, атену ты убил этим зачем? ну сделай тогда v6 или v10 новую major версию в чем проблема? Нет надо убить потому что его заебало уже отвечать на вопросы по своему гавнокоду))) В общем автор тот еще дубина... На столько хуйню написал что даже переписывать ее не захотел и начал новую хуйню делать, и сообщество совсем не причем это не из за их запросов к этому пришло, там все можно было через плагины добавить и фреймворк сначала хотел быть универсальным и иметь больше функций фулл из коробки а потом когда js сказал привет подумали чет много жса надо меньше давайте выпиливать, потом решили чет нахуй давайте еще раз хуего на жсе напишем rebar и убьем атену что бы люди еще раз поверили в нашу хуйню которую мы то же убьем))) Да конечно новичкам норм не спорю но рил... Ну пофиг что там задержка 300мс если что была на открытие cef потому что webview.open() был обернут в async, лол один if исправил это на 1мс. Говоришь монгу вставили туда? Да автор просто не хотел заебываться ставить там реляционную базу делать схему миграции бла бла бла, просто вставил монгу чтоб хуярить говнокод на своем враппере быстрее!!! Да там была простая работа с базой раз и вставил в базу, но это добавляет именно вам ответственности что бы все было правильно, это было быстро и удобно но полный кал с токчи зрения архитектуры. В общем за 3 года там тысячу раз сломали сигнатуры и 0 раз реально сделали хоть какой то импрувмент он был по моему на v4 последний дальше гг))) Сколько там было багов всяких и тд я молчу потому что я каждую систему переписывал))) Я знаю о чем говорю потому что я следил за этим фреймворком очень долго но в итоге я просто понял если ты реально хочешь сделать свой сервер а не просто учишься, нельзя полагаться на подобные фреймворки которые живут своей жизнью и делают что хотят, в один день ты либо останешься без сапорта на старой версии и тогда все равно все делать самому или прими как данность то что все на тебя похую. По этому забил на атену вообще про rebar я просто молчу я сразу знал это лишь вопрос времени его смерть, даже до того как альт умер автор уже забил на него. Я сейчас забил на js вообще, учите детки шарп будете богаты. Так что если возьмут вашу маленькую библиотеку и сделают там тысячу строк говнокода ваш tiny framework не решит эту проблему, делайте грамотную продуманную архитектуру что бы люди не думали как сделать плохо, а знали как надо делать хорошо! Тогда размер не будет иметь значения. А автор молодец библиотека норм keep continue только я может чет не понял а где ссылка на сорсы или сорсов тож не будет???)))

 

[akudinov28]

Лол, rebar такой же кусок кала как и была athena что v4 что v5, всю ее переписал несколько раз с нуля, и v3 и v4 и v5 под себя потому что просто не возможно было использовать фреймворк, каждый раз переделывали все апи раз в год, нахуя? стало лучше? нихуя! Плагины которые были на v4 по моему все на v5 уже не работали без адаптации. В итоге на столько говно сделали несколько раз, что автор решил что нужно сделать еще одно новое говно rebarV с модным апи такое же но только меньше только самое важно, если вы смотрели сорсы а я смотрел уж поверьте вы поймете что там тупо было с атены скопировано почти 1в1 очень много и только то как вы имеете к этому доступ изменилось потому ну там есть свои заебы с модулями и импортами в js но что бы 3 раза сделать реврайт фремворка из за этого не понимания... В итоге это все равно кусок *** причем ну если подумать, атену ты убил этим зачем? ну сделай тогда v6 или v10 новую major версию в чем проблема? Нет надо убить потому что его заебало уже отвечать на вопросы по своему гавнокоду))) В общем автор тот еще дубина... На столько хуйню написал что даже переписывать ее не захотел и начал новую хуйню делать, и сообщество совсем не причем это не из за их запросов к этому пришло, там все можно было через плагины добавить и фреймворк сначала хотел быть универсальным и иметь больше функций фулл из коробки а потом когда js сказал привет подумали чет много жса надо меньше давайте выпиливать, потом решили чет нахуй давайте еще раз хуего на жсе напишем rebar и убьем атену что бы люди еще раз поверили в нашу хуйню которую мы то же убьем))) Да конечно новичкам норм не спорю но рил... Ну пофиг что там задержка 300мс если что была на открытие cef потому что webview.open() был обернут в async, лол один if исправил это на 1мс. Говоришь монгу вставили туда? Да автор просто не хотел заебываться ставить там реляционную базу делать схему миграции бла бла бла, просто вставил монгу чтоб хуярить говнокод на своем враппере быстрее!!! Да там была простая работа с базой раз и вставил в базу, но это добавляет именно вам ответственности что бы все было правильно, это было быстро и удобно но полный кал с токчи зрения архитектуры. В общем за 3 года там тысячу раз сломали сигнатуры и 0 раз реально сделали хоть какой то импрувмент он был по моему на v4 последний дальше гг))) Сколько там было багов всяких и тд я молчу потому что я каждую систему переписывал))) Я знаю о чем говорю потому что я следил за этим фреймворком очень долго но в итоге я просто понял если ты реально хочешь сделать свой сервер а не просто учишься, нельзя полагаться на подобные фреймворки которые живут своей жизнью и делают что хотят, в один день ты либо останешься без сапорта на старой версии и тогда все равно все делать самому или прими как данность то что все на тебя похую. По этому забил на атену вообще про rebar я просто молчу я сразу знал это лишь вопрос времени его смерть, даже до того как альт умер автор уже забил на него. Я сейчас забил на js вообще, учите детки шарп будете богаты. Так что если возьмут вашу маленькую библиотеку и сделают там тысячу строк говнокода ваш tiny framework не решит эту проблему, делайте грамотную продуманную архитектуру что бы люди не думали как сделать плохо, а знали как надо делать хорошо! Тогда размер не будет иметь значения. А автор молодец библиотека норм keep continue только я может чет не понял а где ссылка на сорсы или сорсов тож не будет???)))

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

Я не про размер говорил, а про ту самую грань, где заканчивается фреймворк и начинается уже кастомный игровой мод, заточенный под конкретные запросы и нужды. Условно: написать некий boilerplate, внедрив кастомный загрузчик систем, какие-то расширяемые хелпер классы, стандартизировав структуру модулей, работу с базой для популярных СУБД, внедрив какие-нибудь централизованные проверки на основе декораторов - это круто. Развивать его дальше, запихнув туда строго предопределенный react, например, захерачив туда готовый инвентарь, или писать полную систему управления доступом, завязав на нее весь фреймворк, тем самым ограничивая легкую кастомизацию этой системы - такая себе идея. Как говорится - лучшее враг хорошего.

P.S. Всё вышесказанное это мое личное мнение, я могу быть не прав. Я не разработчик особо, да и свой мод я уже забросил, ибо одному это дело везти невозможно, о чем я знал на старте, но свои набитые шишки доходчивее доносят информацию для мозга))) так что я тут больше по инерции))

 

[Vermilion]

Прикольно. Только наверно не хватает UI конструктора, на котором можно было собирать быстренький прототип.
Ну и такое решение, где одна менюшка = один Browser, лично мне кажется неоптимизированным.
Посмотреть вложение 22454

Нужно вьебать туда блупринт

 

[ash]

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

Я не про размер говорил, а про ту самую грань, где заканчивается фреймворк и начинается уже кастомный игровой мод, заточенный под конкретные запросы и нужды. Условно: написать некий boilerplate, внедрив кастомный загрузчик систем, какие-то расширяемые хелпер классы, стандартизировав структуру модулей, работу с базой для популярных СУБД, внедрив какие-нибудь централизованные проверки на основе декораторов - это круто. Развивать его дальше, запихнув туда строго предопределенный react, например, захерачив туда готовый инвентарь, или писать полную систему управления доступом, завязав на нее весь фреймворк, тем самым ограничивая легкую кастомизацию этой системы - такая себе идея. Как говорится - лучшее враг хорошего.

P.S. Всё вышесказанное это мое личное мнение, я могу быть не прав. Я не разработчик особо, да и свой мод я уже забросил, ибо одному это дело везти невозможно, о чем я знал на старте, но свои набитые шишки доходчивее доносят информацию для мозга))) так что я тут больше по инерции))

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

 

[UchihaMadara]

Нужно вьебать туда блупринт

У меня года 4 назад была идея форкнуть какой-нибудь FlowJS.