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

[Zander_driver 10 321]

Читаю потихоньку ваши труды. Ну вот правда, где РЕАЛЬНО вы видели циклическое размусоливание system_ini() или math.random по 10000 раз за апдейт? Для неких практических нужд. А если видели, ну, вызовите доктора тому кто такое написал. Страдает же человек.

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

Гораздо полезнее было бы наверно, прочесать коды и выкинуть циклы оттуда где они не требуются, вычистить простыни из 100500 if .. then странного содержания, и превратить их в нечто более благородное и лаконичное. Пользы будет в разы больше. Не говоря уж о том что на ясном, лаконичном и кратком коде, проще создавать что-то новое. Удобнее, знаете ли.

[Zander_driver 10 321]

 

 

А вообще таймеры не нужны.

Нет Просто мало кто умеет их готовить. Полезным (и незаменимым!) может быть что угодно.

[Zander_driver 10 321]

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

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

 

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

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

[Zander_driver 10 321]

 

 

Если глянуть по ссылке, про "историю пессимизации" - там вообще-то 10-15 секунд загрузки на вычищенных конфигах, и аж минуты на невычищенных. Плюс "хромота" непосредственно в игре. Плюс 10 секунд (до 2-х минут на ОПКМ) той же загрузки на "торговле", + 4 на тайниках, + 4 на ящиках, плюс 10-30 загрузки и лаги непосредственно в игре по 2 сек на звуках. Ага, вот это у нас называется нынче "гоняться за наносекундами", и "делать ничего не надо". Запуск игры по 4 минуты и перезагрузка по полторы-две после каждой смерти... На не самом древнем железе. Ну нифига ж себе - "неважно"... Не говоря о десятках и сотнях мегабайт памяти при разборах этих конфигов. Да, я понимаю, можно сказать и про "сначала конфиги зачисти". Ага, во всех солянках, всех дмх, всех опах и что там еще наплодили, я вот должен бегать и конфиги чистить. Офигеть...

Ну я не говорю вообще-то что в таком тяжелом случае за сокращением времени гоняться не надо. но вы согласитесь, это же случай в самом деле ужас какой тяжелый. Вы этого лагодинозавра любите и хотите его лечить - дело ваше. Я бы наверно не стал. и если б мне предложили разобрать и привести в благообразный вид 800кб чужого кода из мерзких if-then портянок, ну, я бы задал вопрос "А что оно вообще делает?" и написал бы свое для этих целей, с нуля. А разжиревшего динозавра - просто в корзину.

 

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

 

 

 

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

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

[Zander_driver 10 321]

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

 

Кстати, приведу одну цитату, ко всем "не надо ничего !"

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

Этим и занимаюсь - делаю простые как бревно, вещи, которых никто почему-то не сделал. Очевидно потому что считали - не нужно, и так хорошо. А я считаю что - нужно. То что было в АМК 1.4.1 лично меня не устраивает."

 

dc

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

[Zander_driver 10 321]

@Serge!, lua_help.script вообще движком не читается. это файл-справочник, который когда-то был нужен разработчикам.

 

 

почему никто не правил function isWeapon(object)? из _g.script?

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

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

[Zander_driver 10 321]

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

И кстати да,

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

 

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

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

[Zander_driver 10 321]

Повесил на апдейт получение полного нетпакета ствола в руках. Модулем артоса, разумеется. время замерялось при помощи 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

[Zander_driver 10 321]

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

[Zander_driver 10 321]

 

 

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

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

 

 

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

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

[Zander_driver 10 321]

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

 

 

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

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

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

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

 

 

 

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

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

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

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

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

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

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

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

[Zander_driver 10 321]

 

 

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

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

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

[Zander_driver 10 321]

 

 

Потом как всегда выяснится что из всех полученных знаний на практике нужно собственно нифига из полученного

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

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

[Zander_driver 10 321]

А давайте все стороны перестанут искать чем друг друга поддеть

Правда, лучше жить дружно. И в хорошем настроении, код быстрее пишется, с меньшим числом опечаток.

[Zander_driver 10 321]

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

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

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

[Zander_driver 10 321]

Можешь сделать через {восточные ворота} и сказать себе "круто получилось",

Ну вот на самом деле тут соглашусь, ты прав. И таки именно потому соглашаюсь, что прошел по тому пути, по которому прошел. Да сделал то что хотел, скриптовым костылем через {восточные ворота} как ты выражаешься Но во первых таки сделал, получил определенный результат. Во вторых, получил знания о том как оно должно быть. В третьих, уяснил, увидел, понял, где и что сделал неправильно, где именно и почему мои действия именуются словами "через {восточные ворота}". Поэтому в четвертых, говорить "Круто получилось" я не буду. Просто - получилось. Кое-как, но все же. хоть и не круто, а это результат.

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

Не думаю, что есть какой-либо резон спорить, чей подход лучше. Просто разные, и все.

Изменено 30 Января 2015 пользователем Dennis_Chikin
Предмет - есть, а слова - нет ! ;)

[Zander_driver 10 321]

 

 

Нужно четко понимать всю систему на которой ты работаешь

На момент, когда я добавлял себе в мод модуль нетпакетов Артоса, и se_stor его же авторства, я совершенно не понимал как оно работает. Действовал по принципу дикаря, которому дали пулемет, сказали "нажми вот тут, и будет круто", и я пошел охотиться на мамонтов, нажимая где показали. было круто

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

[Zander_driver 10 321]

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

 

 

кто тут за монструозность говорит

Ты же знаешь меня монструозность не пугает нисколько

 

 

И, да, ответа на вопрос ... я так и не получил

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

 

 

Desertir, базар фильтруй . Химический состав и структуру тебе не выявить?

Вот например вопрос. Откуда берется такая беспричинная агрессия к окружающим тебя людям? не первый и не десятый уж раз это вижу. Изменено 30 Января 2015 пользователем Zander_driver

[Zander_driver 10 321]

 

 

С какой стати? Если предмет удалён, то потерян смысл доставлять сообщение дальше. Ещё раз хочу подчеркнуть. Огрызок объекта в виде его онлайновой части - это не повод думать, что объект ещё существует. Его уже нет, а значит нечего дальше передавать. Рассмотри это с такой точки зрения. Событие с объектом - это нечто вроде доставки почты. Мы идём по комнатам и спрашиваем "это для тебя?" Как нашли адресата, то отдали ему предмет. На этом всё, дальше доставлять нечего и некому.

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

 

 

Хорошо, вот вам еще решение в лоб: создавать два сообщения on_item_drop_safe и on_item_drop. safe кидается перед обычным. Подписчики на safe гарантируют сохранность "объекта доставки". Это своеобразный аналог const функций в том же C++, например. Просто в ЛУА такого нет.

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

[Zander_driver 10 321]

Дочитал блин. malandrinus, как мне кажется, все время имеет в виду нечто чуть другое нежели остальные.

1.Мысль, как уже говорил но повторюсь. Если кто-то сотворил безобразие с объектом, то вот ни в коем разе это не значит что остальным надо рубить вызовы. Почем вам знать, что эти остальные хотели делать. у вас рассуждения будто они все поголовно искали повода объект удалить, аки волки какие.

2. Порочная практика, рассадники феерических багов... ну для начала рассадник феерических багов это хранение "откуда-то" "как-то" полученной юзердаты клиентского объекта, и последующие попытки над ней что-то сделать. Вот это и искоренять лютым образом.
3. Как уже озвучено xStream, немножко дожую. Как у себя реализовал в _кое-чем_ : есть разделение на действие информационное, и действие - действенное. т.е.

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

Какая разница? Предмета уже нет. Если у тебя появился такой случай, значит криво поставлены приоритеты, надо сделать нормально. Логично удалять предмет уже после завершения всех действий с ним.

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

Предмета нет - это не повод прекращать информационные действия связанные с ним.