Обсуждение кода
- Автор темы Xelson
- Дата начала
- Сообщения
- 212
- Реакции
- 334
- Помог
- 3 раз(а)
Shel, не устраивает тем что неудобно :) Контролировать множество модулей сложнее, чем один. Представь, что ты запил 20 классных фич и для каждой фичи отдельный модуль. Лично мне было бы не очень комфортно: когда в списке модулей их 20 разных штук, то очень легко запутаться и слишком много информации надо контролировать, она избыточна. Так что, по-моему, не очень уместно разделять все таким образом, это как делать граб из 8 модулей или ещё что-то :)
Сейчас это два модуля. Не двадцать. Это не много. Как писалось выше, вряд-ли что-то еще выйдет на публику. Остально пишется, но для себя и знакомых.
Плагины которые можно разделять, разделяем же? Почему бы модули, функционал которых не схож не разделить?
Мне лично нужен ButtonsManager, а r1nk0 и то и то, зачем мне их объединять?
Надеюсь никто кроме dog:r1nk0 не додумался прописать модуль в modules.ini?
Не делайте так.
Плагины которые можно разделять, разделяем же? Почему бы модули, функционал которых не схож не разделить?
Мне лично нужен ButtonsManager, а r1nk0 и то и то, зачем мне их объединять?
Надеюсь никто кроме dog:r1nk0 не додумался прописать модуль в modules.ini?
Не делайте так.
Последнее редактирование:
- Сообщения
- 212
- Реакции
- 334
- Помог
- 3 раз(а)
Shel, понятно что не двадцать, я об будущей перспективе на расширение модуля. Кто знает, может быть я хочу пулл реквест добавить на полезную фичу, или fl0wer хочет таким образом поделиться со своим производительным интерфейсом к фуллпаку, или ещё кто-то. А вместо этого придется базу собирать и писать все с нуля, когда можно сделать единую базу для полезных фич и просто писать новый код, а не repeat yourself каждый раз, когда тебе надо, по логике, просто расширить библиотеку. Получилось так, что модулей всегда было по пальцам пересчитать, так один модуль предоставлял множество нативов. И вроде бы ничего, что их теперь в amxx modules теперь 20 (например), но мне такое ощущать некомфортно, потому что так сложилось давно. Повторюсь: такой подход создает много избыточной информации, которую мне не обязательно знать, очередной раз проверяя список загруженных модулей.
А вот плагинов всегда было много и к этому все привыкли
Однако иногда этим очень злоупотребляют и получается так, о чем я уже выше говорил про граб. Излишняя модульность нарушает свой же принцип.
Здесь не очень корректна аналогия с плагинами. Твои модули приносят новый API функционал, который использовать могут совершенно по-разному и в разных целях, и это концепция библиотеки, вот прямо как boost в c++. А плагины — это чаще всего концепция расширения геймплея, поэтому их вполне логично отделять друг от друга. Вот и я предлагаю на каждую концепцию выделять модуль, а не дробить концепцию на излишние части, чтобы потом раздавать им знакомым. Это может стать очень полезным и востребованным для других скриптеров пока это что-то целостное, а не раздробленное. Если уж дело пошло на паблик релиз.
В общем отвечу в посл. раз. В конкретно данных случаях ты не сможешь ничего добавить, так как нечего. Я исхожу из готовности продукта когда пишу сообщения. Ты же видимо хочешь абстрактно обсудить. Ну тебе не удобно, мне не мешает, паре человек тоже удобно когда они могут загрузить лишь то что нужно. Твой образ мышления ясен, он на прямую связан с модовыми серверами, где это требуется, я бы тоже сделал 1 модуль вместо 10, да.
Нет, пример приведенный не производительный.
DRY конкретно здесь ни к месту, выше так же описано почему, компилятор и линкер умные. Метамод как раз и был придуман чтобы распараллелить работу и не писать всё в одном.
Конкретно TeamChanged не паблик релиз, нет, это лишь для тех кто понимает сложность, скорее для тех кто пишет плагины по просьбам. На серверах под собственным контролем таких проблем нет.
P.s если на то уж пошло то у n21 конкретно, всегда был и есть доступ к моим наработкам, всё благодаря Игорю.
Нет, пример приведенный не производительный.
DRY конкретно здесь ни к месту, выше так же описано почему, компилятор и линкер умные. Метамод как раз и был придуман чтобы распараллелить работу и не писать всё в одном.
Конкретно TeamChanged не паблик релиз, нет, это лишь для тех кто понимает сложность, скорее для тех кто пишет плагины по просьбам. На серверах под собственным контролем таких проблем нет.
P.s если на то уж пошло то у n21 конкретно, всегда был и есть доступ к моим наработкам, всё благодаря Игорю.
- Сообщения
- 212
- Реакции
- 334
- Помог
- 3 раз(а)
Shel,
В данном контексте я имел ввиду что придется постоянно тратить время на подготовку базы, что непрактично. Вообще больших проблем с этим нет, но опять же, возвращаемся к удобству.
Ладно, если больше фич не планируется для паблик релиза, то и компоновать пока что нечего. Разговор об такой идеи поднимался и этого уже достаточно сейчас. Спасибо.
Ну почему, я ведь пример привел что может быть добавлено. Да и это вопрос времени, может быть что-нибудь вспомним что хотелось бы упростить и забустить в производительности. Если речь конкретно про меня — я, например, был бы не против добавить утилиту для аттача спрайтов к энтити/игрокам с возможностью их отображения через стену, что очень тяжело для amxx плагина.
DRY относится к принципам программирования и архитектуре, а не к финальной компановке и компиляции. Без разницы что там скомпилировалось, когда архитектура исходного кода на столько плоха, что расширять проект просто невыносимо.
В данном контексте я имел ввиду что придется постоянно тратить время на подготовку базы, что непрактично. Вообще больших проблем с этим нет, но опять же, возвращаемся к удобству.
Так я ведь ничего не выпрашиваю, ты что. Все что нужно у нас уже есть. Сейчас наоборот речь идёт об сурсах которые ты опубликовал и об будущих перспективах, хоть и маломальских.
Ладно, если больше фич не планируется для паблик релиза, то и компоновать пока что нечего. Разговор об такой идеи поднимался и этого уже достаточно сейчас. Спасибо.
Последнее редактирование:
Ты слишком помешан на вебе, в контексте данных задач это не имеет места быть. Ты исходники открывал хоть раз? Что там особенного то?
Не нужно так. ^^^^^^^^^^
Нет общего между модулями ничего.
База - hlsdk, metamodsdk, + 3-4 файла. Не понимаю о чем ты пишешь, они в любом модуле присутствуют, а расширения которые ты пишешь - можешь глобально у себя в системе в VC_{SDK_VERSION}_PATH добавить и пускай тянутся откуда-угодно, в репозитории укажи зависимость, как это было реализовано в amxmodx'е. Единственное что пока что мы выяснили - ты хочешь общий модуль, чтобы тебе было удобно смотреть 1 строчку вместо 5.
Если нужны исходники (чтобы собрать 1 общий модуль для себя) - у вас конкретно есть возможность их получать, причем давно, через полара либо через 8дп (хотя ему за все время было предоставлено меньше чем Игорю) и имелось ввиду конкретно это.
Выше уже написал, приведенный пример не имеет места быть, вы пока этого не осознаете считая это хорошим решением. Это не так.
Модуль - 16 строк.
Но калькуляция подойдет тебе лишь, а мне вот нужно будет другой алгоритм, что делать будем? Фуллпак нужно каждому отдельно реализовывать, здесь нет общих способов. Под furien/public/zombiemod реализовывал, все работает, аптаймы по 1-2k. часов уже. Нагрузки минимальные, действительно, но, трассировка которую ты будешь выполнять в фуллпаке привнесет свой вклад.
P.s прекрасно знаю и успешно пользуюсь DRY.
Не нужно так. ^^^^^^^^^^
Нет общего между модулями ничего.
База? Ну иди скажи тогда Arkshine чтобы он все модули в один собрал. Удобно же. Меньше возни.
База - hlsdk, metamodsdk, + 3-4 файла. Не понимаю о чем ты пишешь, они в любом модуле присутствуют, а расширения которые ты пишешь - можешь глобально у себя в системе в VC_{SDK_VERSION}_PATH добавить и пускай тянутся откуда-угодно, в репозитории укажи зависимость, как это было реализовано в amxmodx'е. Единственное что пока что мы выяснили - ты хочешь общий модуль, чтобы тебе было удобно смотреть 1 строчку вместо 5.
Ты видимо не верно интерпретируешь, либо не в курсе.
Если нужны исходники (чтобы собрать 1 общий модуль для себя) - у вас конкретно есть возможность их получать, причем давно, через полара либо через 8дп (хотя ему за все время было предоставлено меньше чем Игорю) и имелось ввиду конкретно это.
Как это связано с тематикой ButtonsManager'а/TeamChanged'а? Наверное удобно в голове держать какие функции в fakemeta/engine/cstrike реализованы? 100 нативов или названия модулей? Выбираю второе.
Выше уже написал, приведенный пример не имеет места быть, вы пока этого не осознаете считая это хорошим решением. Это не так.
Речь об этом?
Модуль - 16 строк.
Но калькуляция подойдет тебе лишь, а мне вот нужно будет другой алгоритм, что делать будем? Фуллпак нужно каждому отдельно реализовывать, здесь нет общих способов. Под furien/public/zombiemod реализовывал, все работает, аптаймы по 1-2k. часов уже. Нагрузки минимальные, действительно, но, трассировка которую ты будешь выполнять в фуллпаке привнесет свой вклад.
P.s прекрасно знаю и успешно пользуюсь DRY.
Последнее редактирование:
- Сообщения
- 212
- Реакции
- 334
- Помог
- 3 раз(а)
Ни разу про веб не упомянул, и, по-моему, помешан на нем кое-кто другой) Повторюсь, что это принцип разработки и совершенно не важно в какой сфере программирования. А как контекст линковки и компиляции относится к DRY мне до сих пор непонятно.
Так я же объяснял свою позицию:
Все стандартные amxx модули вполне логично концептуально разделены, практических никаких противоречий себе я не наблюдаю. Не люблю, когда мои сообщения читают между строк :/
Кроме тебя есть полно людей, которые делали опенсурс модули. В конце концов, есть весь github, и в том числе твои же репозитории.
Полезные фичи, которые делают некоторые комплексные и ресурсозатратные операции удобнее и производительнее.
Так, а процесс создания спрайтового объекта куда ты дел? А менеджмент управления форвардами, чтобы отключать или включать когда это нужно, ты не делал? А где форс checkvisibility? Не замечаю выборку игроков, которым надо отображать спрайт.
И самое главное, что это такая общая задача, результаты которой понадобятся много где, но в итоге ты напишешь тонну кода для этого в каждом из плагинов, где потребуется простейшее отображение спрайтов через стенку, что по логике делать должен клиент. Чем не причина для упрощения и реализации в виде модуля для оптимизации? Чем не member of features module?
Ну не знаю не знаю, лично я копипасчу код уже второй раз и всё что меняется — условия отображения для игроков и сам спрайт. Ну и еще иногда анимация.
- Сообщения
- 3,585
- Реакции
- 1,573
- Помог
- 138 раз(а)
так дестроить не надо?
Начнем с того всё опять же в абстракцию.
Не упомянул, но прослеживается мышление обычного парня занимающегося frontend'ом на начальных (5-6 лет) стадиях.
Ну и что будешь делать модулем? Вдруг пользователю нужно будет чтобы отобразилось у игроков с g_iActive[33], g_iActiv1e[33], g_2iActive[33], g_iActi3ve[33], g_iAct4ive[33], g_iAct5ive[33], g_iA6ctive[33], g_iA7ctive[33], g_8iActive[33], g9_iActive[33], g_i10Active[33], g_iAct11ive[33], g_iA12ctive[33], g_13iActive[33], g_iActi14ve[33], g_i15Active[33], g_16iActive[33], g_17iActive[33], g_iAc18tive[33], g_19iActive[33], g_iAc20tive[33], g_iA21ctive[33], g_iA22ctive[33], g_iA23ctive[33], g_iAct24ive[33], g_iActi25ve[33], g_iA26ctive[33], g_i27Active[33], g_28iActive[33], g_29iActive[33], g_iAct30ive[33], g_31iActive[33], g_iActiv32e[33], g_33iActive[33], g_iActiv34e[33], g_i35Active[33], g_iActive36[33], g_iA37ctive[33], g_i38Active[33], g_iAct39ive[33], g_iAc40tive[33], g_iActiv41e[33], g_iA42ctive[33], g_iActiv43e[33], g_iActiv44e[33], g_45iActive[33], g_46iActive[33], g_iActive47[33], g_iActive48[33], g_iActive49[33], g_iActive50[33], g_iActive51[33], g_iActive52[33], g_iActi53ve[33], g_iAc54tive[33], g_55iActive[33], g_i56Active[33], g_iActive57[33], g_iA58ctive[33], g_iA59ctive[33], g_iAc60tive[33], g_iAc61tive[33], g_iAc62tive[33], g_iAct63ive[33], g_iA64ctive[33], g_iA65ctive[33], g_iAct66ive[33], g_iAc67tive[33], g_iA68ctive[33], g_iA69ctive[33], g_iA70ctive[33], g_i71Active[33].
Добавишь миллион полей? Нет. Вернемся к обратным вызовам.
У вас с wopox1337 видимо синхронизация, пока не понимаете проблематики реализации API, подходящего всем.
Начинай делать модуль, а мы посмотрим как уместишь всё в одном и том же месте без той же тонны кода.
Либо не начинай - это и будет единственным верным решением. Напиши для себя то, что нужно тебе, ни больше ни меньше.
На данный момент ты мыслишь как потребитель, а не разработчик подобного ПО. Попробуй еще и как разработчик и потребитель одновременно помыслить.
Модуль решит лишь твою задачу, но не пользователя.
Видимо твои задачи заканичваются на создании и отображении спрайтов.
В общем смотри исходники amxmodx'а. Считай это позицией. Возможно наконец поймешь проблемы модификации ядра.
Не упомянул, но прослеживается мышление обычного парня занимающегося frontend'ом на начальных (5-6 лет) стадиях.
Это плохо.
До первого пользователя которому не подойдет.
Ну и что будешь делать модулем? Вдруг пользователю нужно будет чтобы отобразилось у игроков с g_iActive[33], g_iActiv1e[33], g_2iActive[33], g_iActi3ve[33], g_iAct4ive[33], g_iAct5ive[33], g_iA6ctive[33], g_iA7ctive[33], g_8iActive[33], g9_iActive[33], g_i10Active[33], g_iAct11ive[33], g_iA12ctive[33], g_13iActive[33], g_iActi14ve[33], g_i15Active[33], g_16iActive[33], g_17iActive[33], g_iAc18tive[33], g_19iActive[33], g_iAc20tive[33], g_iA21ctive[33], g_iA22ctive[33], g_iA23ctive[33], g_iAct24ive[33], g_iActi25ve[33], g_iA26ctive[33], g_i27Active[33], g_28iActive[33], g_29iActive[33], g_iAct30ive[33], g_31iActive[33], g_iActiv32e[33], g_33iActive[33], g_iActiv34e[33], g_i35Active[33], g_iActive36[33], g_iA37ctive[33], g_i38Active[33], g_iAct39ive[33], g_iAc40tive[33], g_iActiv41e[33], g_iA42ctive[33], g_iActiv43e[33], g_iActiv44e[33], g_45iActive[33], g_46iActive[33], g_iActive47[33], g_iActive48[33], g_iActive49[33], g_iActive50[33], g_iActive51[33], g_iActive52[33], g_iActi53ve[33], g_iAc54tive[33], g_55iActive[33], g_i56Active[33], g_iActive57[33], g_iA58ctive[33], g_iA59ctive[33], g_iAc60tive[33], g_iAc61tive[33], g_iAc62tive[33], g_iAct63ive[33], g_iA64ctive[33], g_iA65ctive[33], g_iAct66ive[33], g_iAc67tive[33], g_iA68ctive[33], g_iA69ctive[33], g_iA70ctive[33], g_i71Active[33].
Добавишь миллион полей? Нет. Вернемся к обратным вызовам.
У вас с wopox1337 видимо синхронизация, пока не понимаете проблематики реализации API, подходящего всем.
Ну это ты не наблюдаешь, мы замечаем.
Ты написал лишь об отображении. Остальное в 16 строк поместится.
Всё это я тоже указал.
Начинай делать модуль, а мы посмотрим как уместишь всё в одном и том же месте без той же тонны кода.
Либо не начинай - это и будет единственным верным решением. Напиши для себя то, что нужно тебе, ни больше ни меньше.
Опять потерял контекст (teamchanged). Там есть исходники подобных модулей? Думаю нет.
...
На данный момент ты мыслишь как потребитель, а не разработчик подобного ПО. Попробуй еще и как разработчик и потребитель одновременно помыслить.
Модуль решит лишь твою задачу, но не пользователя.
Видимо твои задачи заканичваются на создании и отображении спрайтов.
В общем смотри исходники amxmodx'а. Считай это позицией. Возможно наконец поймешь проблемы модификации ядра.
- Сообщения
- 59
- Реакции
- 28
- Помог
- 1 раз(а)
- Сообщения
- 212
- Реакции
- 334
- Помог
- 3 раз(а)
Люди столько не живут. Особенно я.
Подожди. Мы еще выяснили, что так будет удобнее рассматривать пулл реквесты других разработчиков, которые пожелали сделать свой вклад. Кстати, вроде бы как не я один хочу, судя по поддержке пользователей форума.
Так, ну ты объясни то обычному парню занимающемуся frontend'om на начальных (5-6 лет) стадиях, а то не вкуривает парень принципы разработки ПО.
Здесь уже модуль не поможет, это клинический случай. Пускай это будет исключением.
Прости, я не заметил в коде. Ой, опять не заметил. Где это там? Менеджемент форвардов опустим.
Нет, я не потерял контекст об базе модуля, коим teamchanged модуль в чистом виде не является. Это база модуля поверх которого идет код. Ты же сам про hlsdk, meta api говорил, ну и еще amxmodx api можно добавить. Что помешало правильно понять контекст? ...Абстракции?
Вроде бы потребителем модуля фич и является сам разработчик. Для более широких задач, который поставил сам себе разработчик, он может воспользоваться накопленными знаниями ну и своим временем. Сэкономить время остальных, кому надо условно пометить объект через стену или прикрепить метку на -=абстрактную=- жертву, модуль поможет, я думаю. Впрочем, это всего лишь идея и мы всего лишь обсуждаем её, не стоит так агрессивно относится к ней. Не все кейсы покрывает, я согласен.
Ну все, теперь у меня очень напряженные отношения с шелом, и теперь я отвергаю идею features модуля и концепцию упрощенного управления вх спрайтами.
Куда они внесут свои пожелания? В ядро? ?
Чьей? Покажи, а потом почитай их сообщения и подумай, что схожего между вами в данном контексте (помимо того что вы хотите это).
Сталкивались сто раз с таким, опять же, открой претензии на гитхабе в репозитории amxmodx'а, поищи изначально плохо сформулированные концепции которые никто не исправит, так как сломается обратная совместимость, а новые не добавят, так как не хотят дублировать. Те же таски.
Ну да, трейса же там не видно. Этот чеквизибилити и будет у каждых разный. (хоть flFraction == -1, 1 строка)
Опять вернемся к мультиусловиям которые описаны выше.
Мы уже пытались понять что ты имеешь ввиду под базой, базовый набор либо же свои наработки которые добавляются к базовому набору, которые дальше упрощают работу. В итоге ни то ни то. Сейчас выясняется что первое. Тогда не ясно опять какие сложности доставляет собрать базовый набор себе и использовать дальше? Второй случай описан в предыдущем сообщении.
Например: https://github.com/afwn90cj93201nixr2e1re/amxmodxMetamodSDK https://github.com/afwn90cj93201nixr2e1re/amxmodxHLSDK
Он покрывает только 1 кейс, конкретно твой. Нет никакой динамичности в этом фуллпаке. @demnix'у нужна была статичность #1, тебе нужна #2, пойдешь реализовывать и то и то в ядре? ?
Выше же написано, сделай динамичное условие отображения, чтобы когда например игрок в воде был ему другим цветом показывало, сделаешь? Сделаешь. Поймаешь пресинк и проверишь в воде ли игрок, сделаешь таск и проверишь в воде ли игрок, серверфрейм и т.д. Затем через натив выставишь.
Все равно вернемся к тому же с чего начали, к нагрузке.
Это должны быть модули, не модуль.
- Сообщения
- 225
- Реакции
- 90
- Помог
- 1 раз(а)
Сделать отдельные модули и внести их в общий модуль
- Сообщения
- 3,585
- Реакции
- 1,573
- Помог
- 138 раз(а)