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

[Dennis_Chikin 3 658]

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

 

А также про ООП, про как заниматься моддингом и его устарелости неустарелости,  кто как его себе представляет и т.д.  В общем, для много слов "обо всем". Что в более специализированные темы не лезет, но поговорить давно хотелось и хочется.

 

Но таки да, пп 2.0, 2.1 и даже 2.5 правил здесь вполне таки действуют.

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

[Nazgool 250]

 

 

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

Ответ :

 

 

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

Коды OGSE уже доступны. Посмотри как там всё устроено.

[Карлан 1 049]

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

[Desertir 202]

Здесь и видим в действии идею наследования и полиморфизма. Мы унаследовали новый таймер от старого, при этом весь его функционал перешёл в новый класс. А то, что надо - заменили на свои методы, т.е. переопределили иными словами. Полиморфизм же заключается в том, что имеющийся там код базового класса "не замечает", что функции condition и action - новые и вызывает их как свои.

Долго вчитывался в этот абзац. Предположим, что твои таймеры написаны на C++. Получается, что приведенные методы (ну кроме конструктора), должны быть виртуальными, мы же хотим вызвать метод потомка, имея объект приведенный к базовому типу (таймеры же гдето регистрируются и по ним идет итерация, там будет использоваться базовый класс). А как Луа "догоняет" это? Ну или ЛуаБинд, что мы вызываем метод наследника, что методы виртуальные.

[Zander_driver 10 334]

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

 

 

Система хранения уже зависит от событий, поскольку использует события для инициализации себя в нужные моменты

Вот здесь - почему собственно система хранения обязана быть зависимой? так ли много таких моментов, чтобы обязательно прибегать к событиям?

Кстати вдруг назрел вопрос, что собственно является хранилищем данных. Доработанный движок? или что-то другое.

Таймеры - тут да, зависимость ясна и очевидна, спорить не буду.

 

 

 

"Для чего нужно ООП?" - вот понятия не имею.

- Вот отсюда все проблемы и проистекают. Не знаем как пользоваться - не пользуемся - когда пользуются другие, видим в этом раздражающую ошибку. Да?

На самом деле даже понятно, почему такое отношение сложилось. В сталкермодинге местами бывает у многих совершенно неуместная тяга сделать на ООП что-нибудь "просто чтобы было". При том что

1) ООП сам по себе не отменяет такого фактора как кривонаписанные индусские коды, если автор склонен их писать

2) Применяют его там где ну вот не требуется он совершенно, совсем.

3) хаотический набор классов о трех методах и паре переменных, порой не несет в себе никакой логики.

Уверен, DC на просторах солянки видел много примеров, сочетающих в себе все три названных недостатка, вкупе с просто кривыми реализациями умудряющимися создавать проблемы на ровном месте. Это все печальный факт, что такое есть, но ООП то тут причем?
 

Что касается моего мнения. о том зачем и для чего ООП. Рассуждать на тему что это такое - уж не буду, пост маландринуса великолепен, сказать нечего. На тему зачем и для чего надо, а для чего не надо. имхо: если у нас некая сущность (объект) должна хоть в некоторых ситуациях проявлять какие то свои черты поведения (методы), и (пусть даже при относительной простоте действий объекта) таких объектов (возможно) может быть много - то использование ООП при разработке реализации такой сущности, принесет одни только плюсы.

[Malandrinus 615]

Позвольте и мне вставить словечко. Чем тратить время на нетпакеты, лучше бы собрались с силами и собрали бы движок со всеми известными модификациями и всем нужным штатно экспортированным в скрипты. Это исключило бы необходимость в нетпакетах в корне. Надо надеяться, такая работа уже ведётся. Вот это и будет 2015 год, а нетпакеты эти надо забыть, как страшный сон.

 

update:

Написал и после уже подумал, что даже и это не будет 2015 г., поскольку движок на данный момент мягко говоря подустарел, и реально шагом вперёд было бы активное обсуждение, чего там можно улучшить. Хотя это конечно совсем другая история.

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

[Dennis_Chikin 3 658]

Ну вот как бы +1, но это еще надо сделать. А пока годика 3 как есть вот такая штука, которую можно использовать, банально заменив в вызовах префикс с amk. на amk_netpk., или вообще банально копипастой нужного к себе (что с amk не получится).

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

[Zander_driver 10 334]

 

 

поскольку движок на данный момент мягко говоря подустарел, и реально шагом вперёд было бы активное обсуждение, чего там можно улучшить. Хотя это конечно совсем другая история.

Ну вот навскидку, еще по тем временам когда исходников движка не было - если назвать те несколько функций, которые НАДО сделать в движке в первую очередь чтобы с ним хотя бы можно было нормально работать, а не через нетпакеты и прочие скриптовые костыли - спрашивал вот Карлана, оказывается многое из очевидного как бревно, не сделано и поныне. Где то тут DC цитату про это кидал уже.

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

[xStream 86]

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

 

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

 

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

 

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

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

[xStream 86]

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

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

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

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

[АRХИТЕКТОР 37]

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

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

 

Вы правы, под каждую задачу есть своё решение. Но зачем изобретать велосипед? Хорошо, есть РАБОТАЮЩИЕ система ивентов, есть система слотов-сигналов, но зачем Вы призываете не использовать их, не понимаю.

 

p.s. for Grammar Nazi: "Коды Рида-Соломона"

Изменено 28 Января 2015 пользователем АRХИТЕКТОР

[Карлан 1 049]

@xStream, ну в данный момент существуют вполне нормальные методы получения чуть-ли не всего нормальными методами (я о 7 движке). И я, да, соглашусь что нет-пакеты Артоса в данный момент уже не так нужны, а точнее не нужны вовсе, сейчас уже наверное имеет смысл под свои нужды писать простые функции для работы с нет-пакетами "по требованию".

 

 

А зачем, если он в свою очередь брал чье-то?

Затем что сейчас дофига народу сидит на них, в том числе и я. Уже писал что однажды выбирал чьими работами пользоваться, Артоса или маландринуса, ну и вот как-то по принципу сороки, че блестит получше то и схватил . 

[Карлан 1 049]

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

 

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

[xStream 86]

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

[АRХИТЕКТОР 37]

Мне кажется, все темы, связанные с рефакторингом, или правильней оптимизацией (Ден, глянь сюда: http://RU.wikipedia.org/Рефакторинг), можно было бы объединить в одну (пока). Пока тут идёт теория, как дело дойдёт до практики, можно будет разбить.

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

 

<...>

Затем что сейчас дофига народу сидит на них, в том числе и я.

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

 

Пусть это будет хотя бы табличка с плюсами-минусами сущностей или типа того.

 

А то спорить то можно годами.

[xStream 86]

 

 

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

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

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

 

 

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

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

 

 

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

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

 

 

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

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

 

 

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

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

[Malandrinus 615]

 

 

легким движением руки максимальный объем расширяется до бесконечности

Каким образом?

[Malandrinus 615]

 

 

Так что "активное обсуждение" - простите, чепуха. Это будет куча маленьких группок каждая будет вещать со своей колокольни и не слушая других, делать то что ей самой надо.

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

Есть скриптовые наработки, которые можно оставить, хотя бы как отправной пункт. Но вещам типа нетпакетов или x-ray extensions место на свалке. Я просто не понимаю, как можно тратить на них время сейчас, когда есть такие возможности.

[Карлан 1 049]

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

 

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

[KD87 718]

хотя-бы какое-то минимальное описание синтаксиса который в движке используются

Этого тонны в интернете. Обычный c++ плюс минимально std - вектор и мап. Все, для большей части правок, которые жаждут ковырятели делать, больше ничего не надо. Какой смысл к этой тонне еще один плохой тутор писать? Изменено 29 Января 2015 пользователем Dennis_Chikin

[Dennis_Chikin 3 658]

Страшный и ужасный pstor - всего-лишь табличка. И при вызове сохранения сохраняется фактически руками.

Эрго, в 2015 году уже можно добавить в движок сохранение данных произвольного объема. Но поскольку всем лень, то если уж у кого-то каким-то загадочным образом образовался pstor жуткого размера - просто добавить проверку на размер пакета, и после 6, скажем, кило, сохранять в более другой. Слава Маландринусу - есть в куда.

 

А вот городить какой-то дополнительный апи с покером и гейшами^W^W^W объектами и какими-то ивинтами - смысла не вижу.