Malandrinus

Но всё равно не натуральные англоговорящие актёры. На приведённых роликах акцент не столь режет слух, как на ранних рекламных, но всё таки имеется. На натуральных актёров видимо денег не хватило. Это, я думаю, очень зря. Западники гораздо более привередливы к таким вещам. Если кто помнит ещё, на заре перестройки крутили рекламные ролики, и там зачастую говорили с диким акцентом. Как сейчас помню: "херши кьёла - вкюс побьеди" ("Херши-кола - вкус победы", если кто не понял =) Посмеяться можно, но уж точно не всерьёз воспринять. Это у нас, а у них с этим вообще труба. Избалованные...

Drunken Master, Я вполне согласен. Здесь имело бы смысл проводить параллели не со Сталкером, а с Фоллаутом. Вот только ведь нет ничего этого в игре. Оружие самодельное и всё. На мой взгляд сравнивать нечего, разве что технические параметры игры. Всё остальное - чистые спекуляции и фанатские заморочки. Если бы жанры совпадали, то можно было бы и сравнивать. Но этом сеттинге можно сделать и что-то в духе Сталкера и Фоллаута с открытием территорий, торговлей, продвинутым хомячеством и т.п. Но разработчики сделали коридорный шутер. Я думаю, что и верно поступили. Им нужно было дистанцироваться от Сталкера и заявить о себе, сделав игру в разумные сроки. Другое дело, что получилась, хоть и хорошая, но "просто игра". Ну и что? Надеюсь, игра окупилась и команда будет делать игры дальше. Лично мне игра понравилась. Только две вещи вызвали некое раздражение: "быстро нажимайте кнопку Е" и запредельная рельсовость. Я не против коридорных шутеров, я понимаю, что линейный сюжет имеет право на жизнь, но здесь дизайнеры кажется перешли все границы. Ну не нравится мне, когда меня гонят по сюжету штыком в спину.

Небольшое дополнение к ранее описанному здесь классу net_packet. Ранее я писал, что при создании нового объекта этого класса позиции чтения и записи установлены в 0. Оказалось, что в ЗП это не так, и позиция записи и чтения для свежесозданного пакета могут быть попросту случайными числами. При этом в большинстве случаев эти значения всё-таки равны нулю. Полагаю, что в этом и была причина проблем с созданием множества пакетов и вылетом при создании и использовании очередного. Также не подтверждается утверждение о том, что в ЗП нельзя создать много пакетов. Можно, я создал 50 тыс. в одном цикле, и проблем это не вызвало. Резюме: 1. в ЗП нужно перед использованием в обязательном порядке устанавливать как позицию записи, так и позицию чтения вновь созданного пакета. Для позиции чтения есть метод r_seek(<позиция>). Для записи метода нет, надо использовать w_begin(<значение>), который устанавливает позицию записи в ноль, записывает туда двухбайтовое <значение> и смещает позицию на два байта. 2. Исходя из сказанного вовсе нет необходимости создавать пакет заново. В ТЧ это имело смысл по причине простоты (пакет был нормально инициализирован). В ЗП имеет смысл создать один глобальный пакет и везде использовать только его. Всё равно надо будет переустанавливать позиции при каждом использовании. Заодно сэкономим такты и память. Естественно возникнут проблемы с реентерабельностью функций, но это уже другой разговор.

Gonarh, Для формирования маски можно использовать функции побитовой арифметики: bit_and bit_not bit_or bit_xor примерно тоже самое можно сделать с помощью класса flags32

Для неживых объектов помогает снять флажок used_ai_location в поле object_flags. Флажок имеет маску 64. Не уверен однако, что для тушки это поможет. Живые объекты передвигаются по сетке. Может так статься, что независимо от "живости" привязка будет в любом случае. В АМК своя схема обхода аномалий, а встроенные движковые ограничения (вроде как) снимаются. Не разбирался подробно, но наверное надо как-то добавить свою аномалию в эту схему. Аномалия исходно - статический объект. Появляться и исчезать её заставили хитрые модостроители =) Т.е. опять же смотри, как это сделано в АМК.

Kirag, В качестве предположения. Там есть флажки object_flags. Эти флажки, насколько я помню на запись работают, а вот при чтении почему-то не читались. Т.е. при записи их надо было явно выставлять независимо от того, что там прочиталось до этого. Среди прочих там имеются use_swiches (как-то так по памяти). Может быть невключённость этих флажков влияет?

Kirag, 1. Смутно уже помню, но переход в онлайн предваряется вызовом метода серверного объекта (вроде как can_switch_online), который позволяет/не позволяет объекту перейти в онлайн. Я это к тому, что эти вызовы идут периодически с частотой вроде как одна секунда (но точно уже не помню). Это значит, что количество апдейтов до перехода в онлайн в целом величина переменная. Это если объект своим ходом переходит (от попадания в зону вокруг актора). Если пытаешься форсировать с помощью set_switch_online/offline, то см. ниже (п.3). 2. Почему не переходит в онлайн вообще да ещё иногда - тут ничего сказать не могу без эксперимента. Может с нетпакетом накосячил. Оружие вообще не столь к этому чувствительно, как другие объекты. 3. Сразу не перевести никак, просто потому, что это технически невозможно. Создаёшь ты на сервере, а в онлайне объект появляется на клиенте. Хоть это и одна машина, но сетевая архитектура всё равно остаётся. Передача по сети (а перевод объекта в онлайн связан с передачей нетпакета) происходит асинхронно, т.е. ты инициировал передачу (и только) и управление возвращается к тебе в скрипт. Ясно, что как минимум раньше следующего апдейта результата не дождёшься. vader92, используй time_global()

Добавлю. Хит можно наносить и отрицательный и таким образом "лечить". В качестве альтернативы можно перехать на движок ЗП. Там вместо этой функции появилось нормальное свойство bleeding на чтение и запись.

Я пытался понять логику работы ЧУ из кода, но признаться не осилил до конца. Объясните мне плз, как должен проходить час ужаса? Если не трудно, подкиньте также сохранёнку желательно на момент перед началом ЧУ и на локации, где он есть. ЧУ работает строго по игровым минутам + использует инфопорции как флаги. Начинается -- звук обратного отсчета if timeh == horror_begin_time.h and timem >= horror_begin_time.m and timem <= horror_begin_time.m + 2 then Тревожатся неписи - ключается состояние тревоги так npc_position = npc:position() position = vector():set(npc_position.x + math.random(-5,5), npc_position.y, npc_position.z + math.random(-5,5)) state_mgr.set_state(npc, "hide_s_right", nil, nil, {look_position = position}) Выдаётся случайное сообщение о начале ЧУ presoobj() В момент старта есть вероятность 50/50 удачного запуска. В случае удачи - успокаиваем неписей, получаем спецеффекты и спавн монстров. В случае неудачи - лишь соответствующее сообщение. Потом, если игра была загружена с сохранения, восстанавливаем спецеффекты. В конце ЧУ убираются спецеффекты и живые монстры. И в самом конце отбираются инфопорции. sapsan Два вопроса: 1. Сирена в начале должна просто проиграться один раз? Да. 2. Не понял с "успокаиванием" неписей. Почему они успокаиваются в случае удачного начала ЧУ? Не наоборот? Они "успокаиваются" сразу же перед спавном монстров или в случае "поломки" установки. Если их не "отпустить", то будут большие потери - монстры их начнут рвать. А само "успокоение" не заметно, так как сразу же получаем кучу спецеффектов, звуков и монстров. Зато неписи моментально реагируют на монстров. В качестве предварительного мнения: 1. Проверка на начало выглядит ненадёжной. На мой взгляд можно запросто её "проспать", поскольку во время сна игровое время меняется очень быстро. Так было задумано или допущено. 2. Или я чего не понял, или в течении всего времени стартовой проверки (1 или 2 минуты) мы постоянно запускаем один и тот же звук вместо того, чтобы запустить его один раз. Так был реализован звук обратного отсчета. Искать чесный звук мне было в лом - поэтому так и оставил. 3. Инфопоршенов что-то очень много (четыре). На мой взгляд двух достаточно. А если учесть все фазы и возможность игрока сохраниться и загрузится или перейти на другую локацию? Я и так добавил восстановление спецеффектов для таких случаев.sapsan

SDR-team, на С++ написан. Для разборки сгодится любой дизассемблер. Впрочем, если ты этого не знал, то пожалуй тебе и браться за подобные дела не стоит.

Vano_Santuri, Готового примера нет, но это достаточно просто сделать. Заносишь функции в массив. Ставишь один счётчик на циклический перебор. Ставишь второй циклический счётчик на время 20 секунд. Каждый апдейт обновляешь второй счётчик и по достижении 20-и секунд заворачиваешь его в ноль. При этом обновляешь первый счётчик, выполняешь очередную функцию из массива, при достижении конца массива заворачиваешь его в ноль.

Vano_Santuri, SetWndSize(vector2)

Vano_Santuri, Это однозначно метод. Возвращает ссылку на объект типа hanging_lamp, если это конечно hanging_lamp. Применим только к лампочкам. В справочнике я его упоминал в связи с описанием системы регистрации классов.

sapsan, на мой взгляд это имеет смысл только если перебираешь все возможные id циклом. Тогда действительно встречаются чисто клиентские объекты (например фейковые ракеты вертолёта, РПГ и родственные им гранаты после броска). Но всё же слишком усердствовать с этими проверками не стоит. Если честно, то ничего не понял. Можно подробнее про смещение в 4 дня? Разница между game:time() и миллисекундами вычесленными

Согласен, что C (а точнее даже хардкорный C++) знать здесь надо, но мне почему-то кажется, что после дизассемблинга придётся компилировать ассемблером, т.е. ассемблировать =)

Кстати, а о каком "много" вообще идёт речь? Если оценивать вероятность возникновения цепочек отказов, то получим: 1 раз - 50% 2 - 25% 3 - 12.5% 4 - 6.25% 5 - 3.125% и т.д. Можно видеть, что три отказа подряд можно спокойно ожидать, скажем, раз в игровую неделю, а пять - примерно раз в игровой месяц. Шесть и более отказов ожидать можно, хотя не каждый игрок это встретит. Однако учитывая, что играет не один человек, то вероятность того, что у кого-то такие случаи были и регулярно будут (не у одного, а вообще), весьма немаленькая. Такое запросто бывает при загрузке одного и того же сохранения. sapsan

Это лишено смысла. К чему может привести предлагаемая стратегия иллюстрирует вот такой пример: for i=1,10 do get_console():execute(tostring(random_number())) end Если в начале random_number стоит вызов math.randomseed, то этот код выводит 10 одинаковых чисел. Вызов math.randomseed должен быть сделан один раз за всю игру в начале. Почему-либо что-то не происходит с нужной частотой надо разбираться, но уж точное не грешить на недостаточное качество псевдослучайной последовательности. И надо убрать math.randomseed из random_number - это просто неправильно. Проверил - да, такой цикл выведет одно и то же число 10 раз. А вот если поставить get_console():execute(tostring(random_number())) в апдейт актора, то будем получать по кругу плавно возрастающие значения, для примера, от 0.00033570360392332 до 0.99887079000473. Тоесть math.randomseed() есть смысл поставить в том же апдейте актора, а random_number() вообще нигде не использовать. sapsan Весьма любопытное наблюдение. Из него во-первых следует, что генератор псевдослучайных чисел в Lua на самом деле паршивенький. Если инициализирующее число в math.randomseed() меняется (а оно от апдейта к апдейту гарантировано меняется), то первое полученное затем число должно в должной степени непредсказуемо отличаться от полученного после предыдущей инициализации. Т.е. к примеру если я сделал math.randomseed(1000) a1 = math.random() и math.randomseed(1001) a2 = math.random() то по идее могу рассчитывать, что a1 и a2 не будут иметь никакой видимой взаимосвязи. А здесь зависимость совершенно очевидная, что заметно даже невооружённым взглядом. Очевидно, что для целей криптографии этот генератор использовать не стоит =) Второй вывод - не стоит делать этот генератор хуже, чем он есть. randomseed имеет смысл сделать, но один раз за достаточно большое время. Скажем, при старте игры. В этом случае можно видеть, что math.random() выводит при каждом апдейте на самом деле внешне довольно случайные числа. Согласен. sapsan

andrewrap, может рестрикторы держат?

8push5, Так ведь в том и дело, что этот параметр не в секции, а вылет говорит, что параметр ищется в секции сталкера. Косвенная ссылка - это не наследование, в секцию этот параметр по идее попадать не должен. Ну и рассудить так, ведь с другими неписями всё нормально, а они сделаны на той-же секции "stalker". Но я естественно не знаю, что там человек ещё делал.

Вообще-то очень странная ошибка. Если посмотреть по конфигам, то вот этого параметра radiation_v в секции сталкера быть и не должно. Такой параметр в секции есть только у монстров. Но вроде по приведённому коду должны заспавниться именно сталкеры. Непонятно...

Ты всю игру распаковал?

Arhara, на мой взгляд есть смысл в чисто скриптовом моде. Самый первый, можно делать надстройки к существующему моду и при этом не терять совместимость с существующими сохранениями. Вообще-то это можно обеспечить и с новым all.spawn, но мало кто на это заморачивается. Ну вот и проблема - почти всё можно сделать скриптом, а вот пути создать нельзя - только меняя all.spawn

SDR-team, Элементы скриптового управления движением есть в разных AI схемах. Чтобы кто-то сделал полноценную скриптовую замену встроенному движковому хождению по путям - такого я не знаю.

TREWKO, Да так. Заносишь объекты функцией table.insert или как в ассоциативный массив по ключу. А вообще тебе сюда

andrewrap, поищи про таймеры АМК. Ищи в этой ветке или в соседних ковырялках. Или просто посмотри примеры их использования в самом АМК. P.S.: А вообще вопрос "как сделать что-то каждые X единиц времени" задают здесь регулярно. Впору уже вносить его в список правил в раздел злостных нарушений =)