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

[Dennis_Chikin 3 658]

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

 

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

 

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

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

[Zander_driver 10 334]

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

И кстати да,

Делалось для максимальной скорости.

 

Неплохо бы провести сравнительные тесты с модулями Артоса. Преимущество существенное?

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

[Dennis_Chikin 3 658]

Опять за рыбу деньги...

 

Есть полтора десятка разных поделий, с которыми имеем эффект хромоты.

Меняем вызовы тупо поиск/замена - эффект пропадает. Дальше уже можно спокойно разбираться по отдельности с каждым поделием.

 

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

[Zander_driver 10 334]

Повесил на апдейт получение полного нетпакета ствола в руках. Модулем артоса, разумеется. время замерялось при помощи profile_timer, суммировалось в переменной s_read_artos_time, а в переменной s_read_artos_count считалось количество апдейтов.

На другом апдейте, работающем раз в 5 секунд, такой код

    log(string.format("Artos_NetPacket_TEST: Прочитан %i раз, суммарное время чтения %G микросекунд.", s_read_artos_count, s_read_artos_time))
    s_read_artos_time = 0
    s_read_artos_count = 0

Ну и собственно результаты теста, взятые из лога:

* DBG: events:Artos_NetPacket_TEST: Прочитан 157 раз, суммарное время чтения 14801.4 микросекунд.
* DBG: events:Artos_NetPacket_TEST: Прочитан 207 раз, суммарное время чтения 22187.6 микросекунд.
* DBG: events:Artos_NetPacket_TEST: Прочитан 297 раз, суммарное время чтения 30413.6 микросекунд.
* DBG: events:Artos_NetPacket_TEST: Прочитан 325 раз, суммарное время чтения 31858.9 микросекунд.
* DBG: events:Artos_NetPacket_TEST: Прочитан 326 раз, суммарное время чтения 32043.8 микросекунд.
* DBG: events:Artos_NetPacket_TEST: Прочитан 323 раз, суммарное время чтения 31671.8 микросекунд.
* DBG: events:Artos_NetPacket_TEST: Прочитан 325 раз, суммарное время чтения 32811.8 микросекунд.

Поделить мы думаю сами можем. В итоге получается что-то около 100 микросекунд на получение нетпакета.

0.1 миллисекунды, или одна десятитысячная секунды.

 

 

 

 

 

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

Учитывая что нетпакет он и в африке нетпакет, и смысл хранящихся там данных - остается неизменным, утверждение о сложности замены мне тяжело понять. Видимо я чего-то не знаю.
Разница на порядки - в какую сторону? Например читая нетпакет за 100 мкс, я не знаю чем осмысленным надо заниматься в игре с нетпакетами, чтобы этим вызывать упомянутую "хромоту"... можно конечно попробовать, на каждом апдейте актора перебирать 65535 серверных объектов, и у каждого который есть, читать нетпакет. тогда наверно мы получим тормоза но я же об осмысленности действий что-то сказал.

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

[RayTwitty 509]

Зачем нетпакет, если можно читать/писать значения прямо в память? 2015 год жи.

[Kondr48 314]

Shadows, а где про это почитать?) А то со всеми поделками 2014-2015 года иногда просто не успеваешь ознакомиться). Имеется ввиду 7 патч?

 

продолжение в "редактировании движка" dc

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

[Zander_driver 10 334]

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

[Dennis_Chikin 3 658]

"волоча за собой 13-гигабайтный прицеп глобального мода"

 

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

[Kondr48 314]

 

Dennis_Chikin, если кто соберется, окажу посильную помощь, в некоторых методах седьмого патча уже разобрался =)

 

[Карлан 1 049]

, ну например в логе свна. Там оно прям все подробнейшим образом расписано.

@Dennis_Chikin, лог свна + вики, не все, но подразумеваю неописанным никто и не пользуется, окромя авторов . 

 

upd:

, а че их там знать то? Что артефакт, что инвентори итем, что актор - одного поля ягоды, получаешь объект и меняешь свойства (что там тестировать - мне не ясно), у броников и артов иммунитеты идут через доп. таблицу, это же все интуитивно понятно на мой взгляд. Лучше основательно потести новое хранилище, а то все никак руки не доходят, и таки напиши чего-нибудь.

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

[RayTwitty 509]

сделать уже хорошее годное описание того, что мы имеем к 15-ому году в смысле движков.

http://www.amk-team.ru/forum/index.php?showtopic=10339&p=910319

Там как раз про это есть (Класс game_object->Хак для изменения значений в памяти объектов).

 

Имеется ввиду 7 патч?

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

[Kondr48 314]

 

Shadows, как раз по этим методам я с ним общался и немножко инфы имею) при возможности все потестю и выложу описание)

 

[abramcumner 1 159]

На исходниках такой хак сделать в принципе нельзя...

Этот хак:

если можно читать/писать значения прямо в память?

Делается ровно так же, как и на ассемблере. В чем проблема-то. Изменено 24 Января 2015 пользователем abramcumner

[xStream 86]

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

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

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

[xStream 86]

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

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

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

[xStream 86]

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

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

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

 

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

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

[Malandrinus 615]

Я бы сказал, что таймеры АМК, при всём к ним уважении, не подлежат никакому рефакторингу. Для своего времени это был прорыв, но сейчас это уже позавчерашний день. К использованию рекомендуются интегрированные системы компонентов, включающие систему хранения, событий и таймеры. Именно все три, поскольку они друг на друге строятся. Из готовых к применению я лично знаю набор от xStream и мой. Оба имеются в составе OGSE и существенной доработки не требуют. При желании можно перенести в любой мод. Собственно мои таймеры - даже не таймеры, а универсальные сохраняемые объекты с задаваемым условием времени жизни. Одно из условий - по времени, и тогда это таймер. А так можно задать любое условие и сделать объект, ждущий какого-то условия, чтобы совершить некое заданное действие. Используется это в массе разных компонент.

 

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

[Dennis_Chikin 3 658]

Ну, давайте поговорим о кулинарии.

 

Во-первых, кстати, да: я надеялся альтернативные варианты здесь тоже увидеть. С описаниями.

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

 

Как он сделано - создаются эти самые таймеры, перебираются с лютой, бешеной частотой, наконец срабатывают и удаляются. По срабатыванию проверяется количество этих самых срабатываний, как-то подобранных для прибитого гвоздями значения в alife.ltx, создается запускается новый таймер. Зачем ?

Если по факту раз n секунд надо лишь проверить, не наступило ли собственно время для события х. То есть, сравниваем нашу константу с game_time(). При чем здесь таймеры ?

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

 

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

 

То есть, где и для чего именно нужен именно таймер -  я так и не понял.

Может быть кто-нибудь разъяснит.

 

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

 

P.S. По сну - меня в принципе вполне устроило то, что выложено здесь. Секунды ловить - неинтересно. Да и в общем-то не планируется ни каких таких "длинных" апдейтов во время "промотки". Ну а в этой теме он лежит именно для иллюстрации, поскольку остался единственный таймер, понятия не имею для чего используемый и используемый ли вообще. Но остался.

 

P.P.S. Да, надеюсь, что руки дойдут до расписать смысл и устройство предлагаемого костыля, поскольку он тоже, в какой-то степени, "комплексный". Но опять же, рассчитан на то, что в него ДОПИСЫВАТЬ ничего не надо - полностью управляется "внешними" скриптами.

 

А вот избыток "интегрирования" - я считаю, что не есть хорошо. Но, возможно, кому-то удобнее "интегрированное".

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

[Zander_driver 10 334]

 

 

У него есть детская болезнь - универсализм.

Есть такая беда, идея писать один код на все версии игры мне самому никогда не нравилась.

 

 

но вот уж никак не могу согласиться, что использование кода Артоса - хорошая идея

Ну лично я его работами пользуюсь по принципу стиральной машинки - покуда и до тех пор, пока оно работает как мне надо, выдавая желаемый результат в приемлемом качестве и не требуя пристально копаться в себе - меня все устраивает. При этом временами оказывается что я использовал микроскоп в качестве отбойного молотка, но, оправдываясь тем что пока оно работает как мне надо. Стиральные машинки/микроскопы у Артоса получаются надежные.
Другое дело расковырять его код в целях переделать-пересобрать по своему - да боже упаси. Зачем? никогда подобным не занимался и вряд ли буду.

[Dennis_Chikin 3 658]

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

 

Возвращаясь к кулинарии:

1. создаем таймер.

2. перебираем таймеры. В цикле.

3. выполняем запуск по таймеру.

4. удаляем таймер.

5. пересоздаем таймер.

 

А еще - сохраняем и и загружаем таймеры + параметры.

 

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

 

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

[Desertir 202]

Ууу, для чего ООП? А может тогда сначала ответите, что такое ООП? А вы не ответите, потому что точного определения нет.

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

Но, по существу. Да, ООП это парадигма, которая настолько хороша (как с точки зрения программирования так и со стороны философии), что самые популярные языки программирования обязательно ее поддерживают. Об этом написано просто нереально много книг, и вот так "просто" ответить для чего она нужна, по моему, невозможно.

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