Курилка программистов

[xStream 86]

Скорость? С нетпакетами? Вы серьезно? О_о

Библиотека нетпакетов создавалась для использования on demand, а не в polling режиме. 

[xStream 86]

Напомню, что такое изначально нетпакеты - это интерфейс для взаимодействия клиента с сервером. Игра-то клиент-серверная.

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

Изменено 24 Января 2015 пользователем xStream

[xStream 86]

Ну простите Когда все это писалось, только учились, поэтому там такой шлак, я согласна. Вначале вроде неплохо было, потом обрастало функционалом.

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

ЗЫ Кстати, отвечу на вопрос, почему все использование вешалось на on_item_drop: не знаю :-) Спальник повесили именно потому, что хотели именно такое поведение - взяли и типа разложили. Хотя... это так давно было, что я уже и не помню всех подробностей.

[xStream 86]

Я конечно жутко извиняюсь, но вот уж никак не могу согласиться, что использование кода Артоса - хорошая идея. У него есть детская болезнь - универсализм. Это очень плохо, как показывает моя многолетняя практика. Лучше сделать несколько вариантов, но под определенные задачи (это я про его стремление писать универсальный код под все версии игры, к примеру). Еще одна болезнь - у человека нет понятия о таких вещах, как инкапсуляция, изоляция и прочее. Процедурный стиль и венгерку я не обсуждаю - это личные предпочтения, хотя первое приводит к плохой масштабируемости. (жирным выделила то, что считаю противоположными в контексте программирования вещами)

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

Это сейчас, пользуясь огромным количеством наработок предшественников, легко так говорить про бревна. Не надо так 

 

"легко так говорить про бревна" - немножко не по адресу. dc

Изменено 26 Января 2015 пользователем Dennis_Chikin

[xStream 86]

@Карлан, использование идей? :-) А у него свои когда-то были? Он аггрегатор идей - да, генератор - нет. Но и на том спасибо.

 

Деунивесализировать? :-) Еле произнесла. А зачем, если он в свою очередь брал чье-то? Его так называемые модули монструозны и кросс-зависимы. Именно поэтому писал маландринус свою систему сигналов, писала я свою систему ивентов - компактность и независимость. И вообще, гибкость нужна и миниатюрность, я считаю. Меня бы это не трогало, если бы мое не перетряхивалось, выворачивалось и пихалось в этих монстров. Ну почему нельзя отдельные вещи использовать as is? У меня на работе вообще правило в разработке - никогда не трогать сторонние библиотеки, ибо если выйдет какое-то обновление, то хана будет; да и вообще - лучше автора нюансов никто не знает - работаем только с предоставляемыми интерфейсами.

 

ЗЫ Прям до белого каления доводит слово "коды" :-) Программный код всегда в единственном числе. Но это так, граммар-наци негодует.

 

------------

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

[xStream 86]

@Dennis_Chikin, я уже писала, но напишу еще раз: очень легко рассуждать о том, нафига такие простыни, если есть колбеки и вообще почему сделано так, а не иначе: сделано так, потому что учились, изучали, было куча решений в лоб. Все. Больше ничего. Нашлось решение, оно работало, потом было переработано (моя песочница, сигналы Сашины) именно потому, что стало ясно, что работать тяжело с такими вещами.

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

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

Это все безусловно очень удобно.

[xStream 86]

@Dennis_Chikin, я точно такого не говорила :-) И уж как автор ТЕХ самый таймеров и нелюбимых тобою on_drop, точно могу сказать, как оно было. Например, в первых патчах игры не было колбека on_use, точнее он не срабатывал. А on_drop работал. И такого много было.

[xStream 86]

 

 

Я так понимаю, Вы программист или связанны с этим? Поинтересуюсь, на каком языке пишите, если не используете 3rdparty?

Да, я программист.

Я этого не говорила. Я просто сказала, что мы не трогаем внутренности библиотек.

 

 

Коды Рида-Соломона

Это к программному коду имеет весьма отдаленное отношение. Ваш КО

 

 

простые функции для работы с нет-пакетами "по требованию".

Что значит по требованию? Да и зачем?

 

 

чем пакеты лучше системы слотов-сигналов/событий

Ничем. Это разные вещи Одно представляет из себя интерфейс для общения клиент-сервер, а второе - масштабируемую систему, для написания слабосвязных модулей.

 

 

но учитывая что это все надо еще из огсе выдирать то ну его нафиг

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

[xStream 86]

Слава Маландринусу - есть в куда.

*Обиженно надула губы.* Эта идея давнишняя, между прочим, и реализовывалась изначально на фиктивных невидимых объектах, которые могут быть любыми, не обязательно теми, что Саша придумал.

 

Вот на этом ветку и закончим. Там дальше много лишнего было сказано. dc

Изменено 30 Января 2015 пользователем Dennis_Chikin

[xStream 86]

@Zander_driver, неверный подход. Именно в дискуссиях, как сказал кто-то из философов, рождается истина. Я настаиваю - рефакторить надо действительно сложные и тяжелые места, где какие-то хвосты, лишние данные, сложная структура и обвязка. А сон, таймеры и подобное - использовать то, что поновее и поактуальнее. Ну не дебилы же пишут такие системы, в конце концов! Посудите сами - эволюция реализаций этих фич шла довольно долго и имеем вещи, которые учитывают ошибки прошлого и работают эффективно. Нет, придем и перепишем: каждый программист должен написать свой велосипед? Это известная истина. Я не против, но хаять категорично то, что было сделано другими зачастую под определенные нужды, с учетом каких то нюансов, и не разобравшись, что почем (а об этом явно свидетельствуют некоторые посты) - не айс. Не надо так.

ЗЫ Читаю и дежавю - я когда-то тоже такая резкая была, как удар серпом.

[xStream 86]

 

 

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

Самокритика? Вот те же on_drop - ну написали тебе, почему так было сделано, но никто не говорил, что надо это оставлять. А вы, сударь, такое ощущение, что не читаете - продолжаете возмущаться, как все сделано плохо.

Я вот одно могу сказать - посмотрела бы я на твои навыки этак лет 6-7 назад Это раз.

Два - по предложениям тоже пишем. Мол так и так, не очень полезно, а ты бурлишь. И еще других в побурливании уличаешь.

Как то так я вижу сложившуюся ситуацию.

 

 

"КТО РАЗРЕШИЛ ?" и "Почему строем не ходите?"

Эм, ты это о чем? О_о Сколько читала, не видела такого.

 

 

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

Я вас умоляю. То было вечность назад И молодым у нас дорога - вперед! 

[xStream 86]

По on_drop - да, полезный пост был. Но ведь и его проигнорировали - и это был не я. Не будем показывать пальцем, но опять же на этих 4-х страницах можно найти. А я уже просто так сказать, "по итогам" пост написал.

Блин... Я делала эти самые таймеры, я делала этот самый сон и я объяснила, почему они такие дерьмовые в АМК - мы тогда только учились и узнавали возможности системы. Неужели это не понятно? Мне неловко за такое творчество, и я объяснилась. Все, собственно.

Потом прибавила, что осознание дерьмовости пришло позже, и я писала что-то новое. Но так как к АМК я отношения уже не имела, то дерьмище осталось.

Что из этого непонятно? В чем срач то?

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

Собственно, все.

По сути, я даже не спорю - много кода в АМК д.е.р.ь.м.о. Но рабочее, поэтому не трогали, дабы не воняло. И что кто-то хочет исправить, молодец. Но хаять, как будто люди, которые делали то, дебилы - мне кажется не очень хорошей мыслью. Как минимум лично мне обидно И уж выставлять, что то, что ты сделал ("ты" - это не конкретно Dennis_Chikin, а абстракный моддер в вакууме), как некое ноу хау, когда другие, кто тоже шарит, говорят, что наверное не очень хорошая идея - ну наверное не стоит. 

Собственно только этот меня интересует.

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

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

Изменено 30 Января 2015 пользователем Murarius
Немного подправил... терминологию. ;)

[xStream 86]

@Dennis_Chikin, собственно один вопрос: при чем тут вообще таймеры? Что такое таймеры по-твоему?

[xStream 86]

@Dennis_Chikin, я спросила конкретно: что такое таймеры в твоем понимании? Мне банально любопытно, почему они не нужны в игре.

[xStream 86]

@Dennis_Chikin, ты издеваешься?  Я спросила почему ты считаешь, что таймеры в игре не нужны? Пофиг какие, неважно чьего производства. Ты написал, что не нужны, я и прошу пояснить, потому что мне интересно: может ты прав и я смогу в будущих проектах забыть, что это такое.

[xStream 86]

@Dennis_Chikin, вот теперь мне ясна позиция. Так же как и то, что у слова "таймер" в контексте обсуждения у тебя семантика этого слова отличается от общепринятого моего. Соответственно дискутировать банально нет и не было смысла.

Итог - не убедил, и таймеры (в традиционном понимании и назначении) нужны. Дякую.

 

ЗЫ. Пункты 2 и 3 у тебя противоречат друг другу, если что

[xStream 86]

@Desertir, я тоже не очень понимаю. 
------
Подводя итог: Dennis_Chikin возмущен реализацией. Вот и весь сказ.

По сути, реализация амк - это polling с перебором по условиям.

Сигнальная система - это события по сигналам (на самом деле где-то тоже идет polling, но централизованно и скрыто)

Можно реализацию polling'а разнести по объектам-"носителям" (а-ля, сталкер, аномалия и т.п.) - на их апдейты. Суть на самом деле не особо то и меняется (кроме только того, что актор всегда онлайн).

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

Приоритезирование задач может помочь, но сам принцип приоритетов не зависит от исполнения.

Самым удобным с моей точки зрения является event-driven модель - намного меньше макаронного кода, проще интерфейсы и более-менее инкапсуляция.

[xStream 86]

Мы уже выяснили, что есть сложности с формулировками

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

И тут самое интересное - как не извращайся, количество проверок на такие события не изменится. Другое дело интерфейс. Я за удобство, а быстрее работать заставить вряд ли выйдет. Точнее не так - ресурсов использовать меньше. Все ветвления и "медленные" обработчики делаются опять же разными способами, не меняя сути в принципе.

[xStream 86]

Ну, о терминологии: "таймер" и "очередь" - вообще-то взаимоисключающие понятия.

Нет, это просто разные понятия

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

... о! можно попросить словарик? Ну какая у тебя терминология. А то постоянно ты непонят остаешься.

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

Сие к таймерам ну никак не относится.

[xStream 86]

 

 

Посчитали нужным сделать - сделали. Посчитали нужным выложить - выложили. Посчитали нужным описать: что сделано, как работает, как используется - опять же, написали. Увидели, что нечто можно/нужно поправить - опять же, выложили свой вариант. Так же в принципе общеполезно может быть и "вот имеющийся вариант обладает такими вот особенностями, я их использую вот таким способом, а недостаток в моем случае ни как себя не проявляет/не мешает, поскольку вот в таких вот условиях он никогда не проявится".

То есть обсуждать и критиковать в принципе не разрешается?