Dennis_Chikin

А вот не вариант. Ну, то есть, в этом конкретном случае, с инвентарем актора, еще туда-сюда... И то не факт. Вообще же, время, проходящее между разными событиями - оно не гарантировано. Так что очень даже может выйти неожиданность. Не, удалили - значит, удалили. Не важно, как именно мы гарантируем, что ни кто не попытается что-то делать после, но такая гарантия нужна. Опять же, выбрасыванием вносится путаница - кто выбросил, зачем выбросил ? А надо сносить, да. Вот только где бы волшебную палочку найти, с функцией "снести мгновенно все спагетти, и заменить на не-спагетти, и чтоб сразу работало" ? Опять же, я для себя решил, что у меня ни кто сам ничего не ведет и не меняет. Есть разделение на "информативную часть" - выбросили предмет с какой-то секцией - все заинтересованные модули, которые на это подписывались, оповещены. Но именно о событии. Кому нужны собственно предметы инвентаря, или желает, чтобы с ними что-то произошло - ходит как раз вот в эту самую систему учета. Ну, здесь принцип отличается от вышеописанных суперсистем тем, что вместо технических средств используется набор правил, добровольно соблюдаемых. (Черт, вот так отложишь в долгий ящик то, что надо было 5 лет назад написать буквами в файл, потом начинаешь объяснять по кускам, получается нифига непонятно. Лень - смертный грех.) В общем, "должен остаться только один" - в смысле, нечто, что отлавливает и сортирует движковые события (нажали кнопку "выбросить", нажали кнопку "переложить", продали, нечто в аномалию попало). Этот кто-то один и все критичные манипуляции осуществляет. С учетом ранее отловленного движкового. Мда, опять же та же "песочница" получается (или "ивинты" и т.д.) - только названия разные, и разная степень применения технических средств принуждения. Вкус фломастеров...

"лечить надо болезнь, а не симптомы." - На самом деле не надо доказывать. Самоочевидно. Просто, есть разные лекарства, ну или даже разные названия для одного и того же лекарства. И, в общем-то, само лечение сводится к соблюдению определенной дисциплины. Которую можно поддерживать добровольно, либо быть вынужденным/заставлять поддерживать техническими средствами. Ну я вот пошел к тому, что удаление может быть только в одном единственном месте. После которого уже ничего ни откуда не вызывается, и ни куда не передается. Ага, и в биндер руками тоже ни кто не лазит. Что и как выбрать - вот это интересный вопрос. Подозреваю, что в итоге все равно все будет определяться личными вкусами. Кому-то не лень 100500 оберток написать, и еще охранника с дубиной приставить. Кто-то решил, что будет следовать правилам, которые для себя же однажды и установил. Кто-то выберет нечто среднее. Однако, имея дело с неким супермегамодом, слепленным неизвестно кем и неизвестно из чего, иногда приходится и затычками пользоваться. По тому как невозможно сделать ВСЕ СРАЗУ. И вот здесь надо знать, что игровой объект без серверного случиться таки может. В общем-то, вообще все, что угодно случиться может. Пока не доказано обратное. Возможно тот динамит каким-нибудь babah.scriptом взрывается. Или в аномалию выкидывается, которая его тут же и удаляет. Подумавши: наверное, это еще и к вопросу о комментировании. И документировании. "supermod9001.on_item_drop(obj) -- здесь взяли и удалили предмет ... supermod100500.on_drop(obj)" собственно, вот здесь кому-то может быть и неожиданной сама идея, что могут ведь, действительно, и удалить. Опять же "От этого момента вызовы оставшихся в очереди колбэков не имеют смысла, поэтому тот колбэк, что удаляет предмет, должен просигналить, что он является последним в цепочке вызовов." - аналогично, неочевидно, почему именно. Если комментарии это не разъясняют. Либо отдельное описание. P.S. Кстати, а почему не имеют ? Серверного объекта нет, а вызовы вполне могут и иметь. 2 xStream: Алилуйя ! А то все анекдот про "гуталина нет" вспоминался.

Да, и где-то уже про это писал: сразу снести строчки for o in npc:memory_sound_objects() do check_item(o) end Ибо пользы от них нет, а тормоза - есть.

В онлайне ? В оригинале не обыскивают вообще. В солянке - wather_act.script. Проблема решена давно, но... В общем, одной строчкой не обойтись. А чтоб еще единая "для большинства" - тем более. Проще закрасить, и переписать заново. Что и сделано, но для одного конкретного. Ну, можешь поискать что-нибудь типа max_dist=5+math_sqrt(value), и как-нибудь покрутить. Типа там max_dist=5+math_sqrt(value)/10

Утка - в зайце, заяц - в шоке ! Но жарят таки в тесте.

Господи, зверство какое ! Утка делается В ТЕСТЕ.

Кирза ! С детства дико любил пшеничную кашу. И совершенно искренне не понимал, за что все ненавидят эту самую "кирзу". Пару месяцев сподобился - купил очередную "кашу пшеничную". Осознал. P.S. Кстати, 2 года назад был немало удивлен, обнаружив, что в нашей местечковой кишечной( sic! ) хирургии перловка считается "стол 0". Вот прямо вот так, с чешуей. =8-O Почетное второе место после капусты для больных с кишечными анастомозами в онко. А может даже и первое. Вот именно. На костер !

Есть. Во-первых, болт, серверного объекта просто не имеющий. Во-вторых, неоднократно встречался с ситуацией, когда подряд отрабатывают два скприпта, удаляющих один и тот же объект, и вот здесь любые манипуляции кроме получения id от игрового дают набор самых забавных эффектов. А, да, в выкладывавшемся мной недавно, как тут изящно изволил выразиться один из пользователей, "дерьмокоде" имеет место быть иллюстрация с игровым объектом, полученным через drop-коллбэк. local obj = alife():object( id ) if obj then if obj.parent_id ~= 65535 then -- переложили в тайник/отдали else -- выбросили end else -- удален end Ну, правда, случай несколько иной, но настораживающий. Допускаю, что через actor:object() в определенных ситуациях получить тоже вполне можно. Наконец, странные манипуляции с патронами при смерти непися, попытка удалить которые из death_manager тоже в общем-то заканчивается непредсказуемо.

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

2 Shadows: это я тут флужу потихоньку , поскольку имею в виду как раз сборку из исходников. То есть, что имею в виду: Опции, которые задаются при запуске движка. И, по сути, да, которыми выбирается нужный бранч (но внутри одного exe). Ну, да, инвентарь ЗП/билд, грубо говоря. Хотя не уверен, что вот этот конкретный случай - именно через опции. Скорее, именно инвентарная dll. Прятать оружие - это типичная опция. Или конфиг. Вот кстати да, конфиги тоже ни кто не отменял, и поведение движка ими задавать - почему бы нет. Опять же из LUA в оригинале можно же дергать бинарный кусок. А уж какой именно, и что там в нем будет - вопрос более другой. P.S. Да, понимаю, что работа сильно на любителя и не на один день. "Это как" - это вот так же, как делался софт единым исполняемым файлом для разных процессоров. Где запускалось для минимального случая в семействе (80286, скажем), проверялось, а потом использовались куски с разными наборами команд и разным функционалом. Могу согласиться, что это - извращение, но не то, что "не может быть, по тому что в гугле написано". Впрочем, да, согласен, перебор в том смысле, что вряд-ли кто озадачится ТАКИМ. P.P.S. И, да, наверное, действительно разумнее подумать о вынесении всякого разного в скрипты.

Э-эээ, ну вообще-то опции не помогут, нет ? А вообще я чем дальше, тем больше хочу success storyes тех, кто уже собирал. Как долго, какие проблемы, можно ли вынести "вариабельные" куски вот в те же dll ?

Ага, когда имеем софт для управления рэйдом, или даже для банальной записи CD - иногда приходится задумываться о том, что может его в следующую major версию, или пусть пользователи себе все болванки позапорют, а кому повезет - просто перестанет оборудование работать после апдейта. Или пусть просто пока подождут обновляться/покупать железо новых моделей. Да, возвращаясь к ООП, тут наверное стоит скорее подумать о таком факторе, как стоимость управления разработкой. Ну, то есть, и во времени, и в деньгах, и в собственно людях. Сколько-то десятков лет жили без ООП, и даже без dll и ничего. И 640Kb - это было действительно очень много, по тому как работало и в 16-ти. Но, требовалась довольно таки серьезная дисциплина. Примерно оттуда - "один файл целиком на экране", системы наименований файлов, наименований функций, что куда должно передаваться и т.д. И вообще - один модуль, который на входе получает текст и на выходе выдает текст. Потом, да, еще придумали линкеры и возможность собирать .obj в .lib Да, с ООП ни о чем таком думать не надо - "не хочешь - заставим". Хотя в принципе, при соблюдении драконовской дисциплины скорость разработки не страдает ни разу. Скорее даже, наоборот, отсутствуют лишние телодвижения. 2 Viнt@rь: "драконовская" - это про меры по оформлению модулей и их взаимодействия. upd: ну, да, опять неправильное слово использовал. Скорее что "сопровождение" да. Драконовость в случае процедурщины - она подразумевает, что раз написанная функция всегда будет принимать те аргументы, которые принимала, именно в том виде, всегда возвращать результат тоже в заданном однажды виде, и лежать на своем месте. Сама написана так, что открыв файл - сразу понятно, что она делает. На глобальные переменные опять же пишутся спеки, и сам выбор имен заранее оговаривается. И т.д. В случае с ООП ко всему этому можно относиться гораздо проще.

Ну вот я тоже примерно про это. Собственно, при отсутствии в сталкере скриптовой части, которую оказалось возможно изменять, не факт, что вообще моды на Сталкер были бы. Ну или максимум - маргинальные проекты, как те, в которых в 201* году маленькая группка любителей все еще перепиливает игрушки под дос первой половины 90-х... Кстати, здесь же мы подходим и к вопросу об ООП. Когда я писал про "не знаю, что это такое " - в общем, да, было некое утрирование. На самом деле есть места, где инкапсуляция (на самом деле изоляция) и наследование дают определенное удобство. Так же, как есть и некоторые проблемы. Вот недавно столкнулся с тем, что, действительно, game_object может существовать в нескольких экземплярах, и изменения родителю не передаются, хотя надо. Пришлось, хе-хе, через ненавистный многим pstor. И в общем-то дискутабельный вопрос о гомогенности кода: должно-ли все-все быть оформлено в едином стиле, даже если это неудобно (ну, то есть, включая printf( "Hello world" ), или в некоторых случаях процедурщина все же уместна. Вот пресловутый profile_timer() показывает, что в определенных случаях процедурщина смысл таки имеет (и ожидание 6-8 сек vs. 13 - это мелочь на фоне 5 минут, но когда те 5 сведены к 0.2 - то и 13 vs. 6 - тоже заметно). А коли так - может и hello world в обычную функцию развернуть не грех ? А продолжая рассуждения общетеоретические, то васик vs. ООП - оно, конечно, да. Но вот начав работать с C, причем сразу с ленточной/дисковой подсистемой, и имея набор хорошо организованных пресловутых .h (зато без линкера , что, собственно, и заставляло думать о содержании этих самых .h) - некоторые более поздние находки кажутся не таким уж и достижением Мировой Мысли, а Страустрап - скорее даже и вредным. 2 Desertir: "либо уже тормозит на столько, что код пишется со скоростью выполнения программы." - приложение запускается дольше, чем пишется код. И тогда уже вот честно становится лениво натравливать на каждый кусок profile_timer(), вместо того чтобы просто взять, и банально снести 20 вызовов функций из полусотни скриптов, результатом которых - получение одного битика.

xStream, а вот теперь я настоятельно прошу цитату "некоего персонажа". В которой будут упоминаемые слова. По тому как Вы действительно уж слишком упорно пытались перевести вопрос в плоскость административную, и Вам это удалось. То есть, жалоба принята к рассмотрению, и по итогам либо я иду в бан, либо - кто-то другой. Карлан, да если бы против... Ты же знаешь историю вопроса. И многие здесь знают. Просто упорно делают вид. Вообще, мучительно пытался вспомнить, где я это видел. Вспомнил. Сказка о том, как на день рождения некоей принцессы забыли пригласить одну из ее крестных. И даже не забыли, а письмо где-то потерялось. Но кого это волнует ? Мстя будет жестокой, неотвратимой, и всем, кто под руку попал. За ВСЕ. А также еще и за многое другое. Просто, был некий закрытый раздел, созданный этим летом, не будем показывать пальцем, кем созданный, в который пригласили всех, кто был на форуме в тот момент, и попросили расписать у кого чего есть под рукой. Ну а другие чтоб развили и дополнили. Чтоб потом скомпоновать, и уже в таком виде открыть. Поскольку с затеей ничего не вышло, то раздел расформировали, а часть тем перетащили в открытый доступ как было и как попало. Ну да кого это теперь волнует... Главное, повод есть, и ВСЕОБЩИЙ ВРАГ - тоже. И кстати, опять же вспомнился Владимир Вольфович. Когда обсуждалась некая гадость. Как сказал тогда упомянутый В.В. "Это - гадость ? Нет, вот СЕЙЧАС будет гадость." Так вот, извольте - гадость: все эти суперсовременные системы 12-го года - тоже старье. И тоже в музей. По тому что - борьба с ограничениями движка. Каковой нынче есть в исходниках. И еще неизвестно, когда у кого и дочего руки дойдут, и кто в итоге окажется в выигрыше: пользующщиеся музейными экспонатами 2008-го, 10-го, 12-го, или вовсе 15-го. Или какими-то промежуточными вариантами. Вот теперь можете писать жалобы. Администраторам, в конституционный суд, в Гаагу. Да, не забудьте только часовню 18-го века помянуть. Сколько здесь модераторов за историю форума сожрали ? Ну, одним больше-одним меньше - какая разница. Ну и цитатку жду.

Вот есть пост. В нем - ссылка + история вопроса. Что "ежели скрестить вот то и еще вон то - все плохо, а вот так - вроде и ничего. Что сделано - а просто выдернуто из ... и развернуто". Вот другой пост - ссылка, и вот к ней, к ЭТОЙ ссылке написано: "а вообще - не нужны". Вот третий - тоже, "просто убрано лишнее" (ну и там дальше поправили, что убрано не все лишнее). Ну какие еще надо поклоны исполнить, чтобы на лесоповал все же не ехать ? Или только написать завещание в пользу потерпевших, и, действительно, повеситься ? Меньшим не удовлетворитесь ?

Покаянцы. Реквизиты самого произведения не привожу, поскольку ценного там - только вот этот отрывок.

Гм, "чтобы ни куда не уходил" - это, наверное, все же не логика, а прежде всего custom_data с чем-то типа [smart_terrains] none = true Ну а дальше - уже действительно в логике все равно walker и путь, с одной точкой. Или camper. В общем, та самая схема, которая отвечает за нужные анимации и прочее поведение.

Спасибо, про profile_timer () я в курсе. Хотя, опять же, кому и пригодится. Впрочем, некоторые эффекты вполне можно оценить и визуально. Вот те самые, например, с трэйд-менеджером. А некоторые просто переписываются "по ходу дела". Если поменял 10 строк - то почему бы и не еще 5 соседних. P.S. А образец, кстати, как раз 2015го года, и если зайти в более соседний раздел, то можно увидеть, что вот на его основе продолжают "развивать". P.P.S. И, да есть еще такое слово как совместимость. Не та, которая с сэйвами, сделанными на ТЧ1.0, конечно, но та, которая step-by-step. В смысле, чтобы не переделать за раз все 13Гб мода, сразу как надо и без ошибок, а чтоб на промежуточных стадиях хотя бы запустить и посмотреть, что получается. (Бэг пардон за очередное неудачно употребленное слово).

Таки вопрос опять же: что делать с приведенным выше образцом ? Указанные проблемы/возможность проблем (про "перестаравшись" и про затраты времени) - да, согласен, есть. Да, несомненно, есть спортивный элемент, в какой-то степени. Или не спортивный, а разгребая вот то, что, опять же, в приведенном примере - заодно и переписал. И, отдельно, по поводу "все", "у всех" и "некрофилия" - несколько категорично. Не все и не у всех, во-первых, во-вторых - некоторым вещам тоже лет по пять-шесть. "- Кто не хочет делать так - отключить от интернетов и сослать на лесоповал ? - Естественно." О, вот мы и дошли до сути. Благодарю, вопросов больше нет.

Вот теперь уже я хочу пояснений. Означает ли все написанное, что в 2015-ом году все обязаны делать вот так: https://dl.dropboxusercontent.com/u/27871782/amk.script только прикрутить еще куда-то сбоку систему ивинтов и песочницу от одного конкретного автора (указать, какого именно) ? Кто не хочет делать так - отключить от интернетов и сослать на лесоповал ?

На взятие - почему нет ? (Единственно что, надо иметь в виду, что при загрузке взятие отрабатывается для ВСЕХ предметов, и если их много - тогда будет ой.) С брониками и стволами нет, но есть, например, телепорты. При создании: tt = get_anomaly_data( obj ) cd = parse_custom_data( tt.custom ) cd.cd = { ["id"] = v } tt.custom = gen_custom_data( cd ) set_anomaly_data( tt, obj ) При входе в онлайн: local ini = self.object:spawn_ini() local n = ( ini and ini:section_exist( "cd" ) and ini:r_string( "cd", "id" ) ) or abort( "(%s):reload, invalid section [cd]", self.object:name() ) local id = self.object:id() self.teleport = n -- идентификатор для чтения параметров t_ids[n], t_spawn[id] = id, n В принципе, можно проще. Здесь сразу предполагается странное, поэтому еще добавлено разбор кастомдаты и ее преобразование обратно в строку. Если не нужно - можно сразу строкой и записать. Функции брать традиционно из амк, (ну или альтернативные ).

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

По вопросу "исторического наследия" - так не то слово. Собственно, то что есть в амк-моде - в какой-то момент (и момент весьма затянулся) было практически единственным источником информации о "что вообще есть, и как это можно использовать". С работающими примерами. А вот вопрос о том, что из этого следует использовать в 2015 году, и в каком виде - вопрос уже другой. Как и вопрос о том, следовало ли вообще размножать то, что было в моде посредством простой копипасты, и скрещивая что попало с чем-нибудь еще. Причем вопрос уже не к авторам амк, естественно, а к тем, кто так делает. Впрочем, опять же совершенно верно, что идея заставить ходить всех строем - неполезна, и в общем-то нереализуема. Просто это работает в обе стороны. "Зачем сделали, зачем выложили, зачем написали ?" - здесь ответ простой, и не очень приятный для вопрошающего. В общем, даже странно, что именно об этом только здесь 5 страниц, не считая других тем, и не считая того, что отправилось в корзину ну вот хотя бы за пару последних месяцев. Остается только еще раз повторить: Посчитали нужным сделать - сделали. Посчитали нужным выложить - выложили. Посчитали нужным описать: что сделано, как работает, как используется - опять же, написали. Увидели, что нечто можно/нужно поправить - опять же, выложили свой вариант. Так же в принципе общеполезно может быть и "вот имеющийся вариант обладает такими вот особенностями, я их использую вот таким способом, а недостаток в моем случае ни как себя не проявляет/не мешает, поскольку вот в таких вот условиях он никогда не проявится". Ну и дальше уже дело хозяйское, кто что для себя выберет. P.S. А, да, остается только добавить, что "бывают и просто сны", и не всегда стоит искать какие-то намеки на неведомое в простых фразах, относящихся к самому предмету поста.

Можно и оттуда, и оттуда. Простейший вариант - под ноги актора: local obj = alife():create( "m_inventory_box", db.actor:position(), db.actor:level_vertex_id(), db.actor:game_vertex_id() ) if obj then local t = amk.get_invbox_data( obj ) t.custom = "[logic]\ncfg = scripts\\treasure_inventory_box.ltx" amk.set_invbox_data( t, obj ) end где m_inventory_box - секция тайника, прописанная в конфиге, amk.script - см. в соответствующем моде, логика: [logic] active = ph_idle@enable [ph_idle@enable] nonscript_usable = true tips = "какой-то текст"P.S. Да, еще бы, конечно, не помешала проверка на валидость этого самого db.actor:game_vertex_id()

fastcall не гарантирует одинаковые интервалы. Тоже меняются в зависимости от нагрузки, хотя и не так сильно. Хотя на мой взгляд - вполне, и даже избыточно. Просто надо помнить, что точно и через него ничего не отмерить. Где-то сам же malandrinus и описывал. game_time() - проблема с разрядностью. Да, так называемое "45-е мая". Ну, тут все по разному решают. Я вот, опять же, остановился на том, что 45 игровых дней на одной локации без единой перезагрузки сидеть вряд-ли кто будет. 2 xStream, к вопросу об определениях: "Таймер - нечто, позволяющее выполнить какое-либо действие через минимальное определенное время" - в принципе, годится. Хотя, вообще-то, "гарантированно выдерживаемый интервал времени".