Гугл тоже придумали поисковик, но это не значит, что нельзя создавать альтернативы, как, например, Яндекс или Bing. Порой свои решения лучше подходят под конкретные задачи и позволяют оптимизировать процесс под нужды проекта. В конце концов, выбор между "создать с нуля" и "использовать готовое" всегда зависит от контекста и требований задачи. Поэтому мы и написали сообственный. Не засоряй мне тему своими неуместными сообщениями, хочешь конфликта - пиши в лс, там поговорим.
Если не секрет, то зачем апать мануал? Типо кого интересует разработка они сами зайдут и посмотрят этот раздел, а для "рядовых пользователей" это не поможет запустить сборку
Вот это странный момент. Middlwares, как я понимаю, это набор условий, при которых EventHandler должен сработать У вас же игровой процесс. Каждое событие должно быть обработано. Игрок зашёл в N зону - он должен увидеть Response для своих действий. Или там кнопку в UI нажал - ему прилетает Response - Успех/Ошибка.
Вот это тоже странный момент. Нарушается логика и ответственность. Сервер может напрямую взаимодействовать с CEF, а CEF напрямую вызывать сервер.
Думаю автор имеет ввиду, что используя его библиотеку будет удобнее просто написать одну строчку на вебе, что бы передать данные на сервер, в любом случае это все происходит через клиентскую часть, просто удобнее использовать например:
// CEF side
global.callServer('event.name', param);
// Автор скорее всего реализовал и преобразование в строку и может еще как-то обрабатывает param
// После чего в реализованной функции callServer вызывается ивент который находится на клиентской части, а этот ивент, в свою очередь,
// является просто "мостиком" для перекидывания данных между вебом и сервером// CLIENT side
// Предположительно ивент может выглядеть так
mp.events.add('client:browser.to.server', (name, ...args) => {
mp.events.callRemote('server:browser.to.server:events:call', name, args);
});
// Соответственно, все работает так же как и обычно, ничего нового тут нет, в любом случае даже на своем сервере
//ты обязан будешь реализовать что-то подобное, иначе у тебя
// будет целая "туча" подобных ивентов, которые по факту являются "водой" в твоем коде,
//и легче будет организовать все через один ивент - и код чище, и тебе комфортнее работать,
// плюс можно отслеживать через сервер все ивенты// SERVER side
custom.events.add('server:browser.events:name', (player, ...args) => {
// todo event
});
// Так же стоит уточнить, что скорее всего автор создал какой-то свой EventHandler,
// который и загружает, при запуске сервера, в себя ивенты, самый просто можно реализовать
// через массив, просто сохраняя туда все ивенты, а потом по имени находить ивент и передавать в него аргументыО чем я и говорю. Нарушается ответственность. Каждый начинает выполнять то, что ему не положено выполнять. UI не должен взаимодействовать с сервером и управляться сервером.
Ну так, по факту, оно и выполняет свою ответственность, просто для удобства, что б не прописывать постоянно на клиенте новые ивенты через которые нужно перекинуть данные их просто прокидывают через один ивент, так намного читабельнее код становится, все что здесь меняется это подход к написанию кода и не более, все в мультиплеере работает одинаково, ты не сможешь изменить работу клиента, сервера или веб части
От использования этого ресурса ничего не меняется в работе мультиплеера, но становиться читабельнее и комфортнее писать код в моменте разработки, если говорить "по факту", то этот ресурс просто вкусовщина, ты либо флудишь в своем коде целой кучей ивентов, либо используешь какие-либо либы/пишешь сам либы, которые помогают тебе комфортнее и чище писать код, что в будущем, на огромном проекте, даст преимущество в скорости фикса багов например, я уж не говорю про упрощенную совместную разработку с кем-либо
// SERVER side
mp.events.add('playerJoin', (player) => {
eventHandler.callBrowser(player, 'browser:openHUD', player.id);
});// WEB side
eventHandler.add('browser:openHUD', (_playerID) => {
hudState = true;
playerID = _playerID;
// todo
});Я хз зачем ты мне объясняешь как устроен mp.
Оно не выполняет свою ответственность. Проложи точно такой же мост, только до БД. А че, удобно же, можно не писать лишние ивенты на клиент-сайд и сервер-сайд. Кнопку нажал = INSERT INTO accounts....
Видишь код обработчик нажатия кнопки, сразу понимаешь, что там заносятся данные в таблицу БД
Зачем на сервере регестрировать евент который может быть вызван напрямую с браузера и затрагивает БД, или разрешает ее модифицировать? Ответ: Я тоже не знаю.
Так будет тоже самое, если без использования rpc.
мне кажется что опасность не в библиотеке, в том числе архитектурная, а в руках разработчика
На самом деле нет
Ну хорошо, давай на примере наглядном что ли разберем. У тебя задача при нажатии кнопки, пусть к примеру это будет кнопка подтверждения продажи машины, выдать игроку N-ую сумму денег и записать это в базу данных. Как ты это сделаешь, если по вашим словам мухи отдельно, котлеты отдельно.мне кажется что опасность не в библиотеке, в том числе архитектурная, а в руках разработчика
кто-то построит структурный проект с мидлварями а кто-то монструозный говнокод с вызовами в скуль по кнопке из юи
можно же встроить правильно нечто подобное, чтобы он не размывал ответственность, через какие нибудь образные свои ServerAPI, ClientAPI, UIBridge
и использовать просто как часть инфраструктуры
а тем кому надо они охуенно справятся и так
я неделю назад смотрел код, где у чела каждый клик по кнопке в юайке вызывает серверный евент который делает инсерт
охуенно
На самом деле нет
Вы чуть-чуть на разных языках говорите. Ты - как разработчик, а Учиха как проектировщик скорее.
И без орм будет то же самое что с ним - че то там пушится и записывается в бд прямым селектом, правильно
Так и зачем тогда ебаться
Да, формально маршрут тот же, но у тебя меняется семантика связей
Это ломает архитектуру и восприятие, с точки зрения дизайна кода - да, это конечно как минимум стирает границы понимания зон ответственности, и это плохо.
Универсальный мост ломает или ну как минимум меняет доступность действий, вызывая соблазн кнопка-сервер-инсерт как ну минимум на уровне восприятия
И это
именно так и есть
Если ты ограничиваешь его, делаешь транспортный слой как вот какой то UIBridge, цеф никогда не видит серверные прямые энтрипойнты, принимает команды-аргументы с валидацией и правами, пушит состояние в слой а не команды "покажи модалку", ещё с какими нибудь вайтлистом и типизированными дто - тогда окей, он останется инструментом.
И писать такие штуки как ограниченный транспортный слой - нормально.
Но "удобная прослойка" чтобы туда-сюда пушить евенты - да понятно, удобно, прикольно да и ничего такого, просто враппер
Но на самом деле архитектурно - полная хуйня, конечно.
С другой стороны ну на рагемп про щас бы про клир код и архитектуру говорить, лмао
Работает и похуй, ещё и удобно, ёбнешься
Грю, тут люди "сборку с нуля чтобы не ставить ебучую баганую редагу" на прямом скуле пишут
А вы развели
Для почти любого рядового разработчика здесь это будет скорее полезно чем нет почти в любом случае
А до разделений зон ответственности, слоёв и дизайна кода он сам когда-нибудь дойдёт
Или нет
На клиенте ты регистрируешь Событие "sell.vehicle", которое ожидает, что игрок Согласился/Отказался от сделки. Это событие можно вызвать разными путями.
Это все понятно, но я имел немного не это. Я про сам путь ивента от веба на сервер. Он у нас идет CEF-client-server, верно? Так rpc делает то же самое, но в обертке. Как ни крути, все проходит через клиент, что бы сервер понимал кто его триггерит
Да
у тебя на клиенте валидации, которые прогоняются через клиент а на сервере - валидации которые прогоняются через сервер, естественно
