[SoC] Ковыряемся в файлах

[Artos 99]

Полтергейст: Вопросик насчёт all.spawn: какие будут последствия, если у двух объектов одинаковое имя?

... Походу это ляп разрабов. Кое-где так спешили, что забыли ...

Не делай поспешных выводов в очередной раз.

Если просмотреть 'all.spawn', то можно заметить, что немало типов объектов в нем имеют одинаковые имена (костры, лампочки, ящики, ...).

Задумайся сам, а требуется ли выдумывать имена для подобных объектов, если условие: "на одной локации только уникальные имена" - выполняется в любом случае для подобных объектов.

Костры между локациями не перемещаются, ссылок на имена лампочек с разных карт не имеется, ящики, если и используются 'глобально', то только по story_id'ам, а не по именам ... Так ли уж обязательно задавать уникальные имена? :-)

Так что разработчики просто с'экономили на именах и своем времени ...

Иной вопрос для модмейкеров: заспавнить в тот же ящик к Сидорычу (с не уникальным именем для игры и без сид'а) - нужно немного 'попотеть' и пошевелить мозгами/познаниями. ;-)

Изменено 16 Марта 2011 пользователем Artos

[Artos 99]

Куфзук: Ты хочешь сказать, что создание на одной локации двух объектов с одинаковым именем - чревато последствиями?

(немного оффтопика)

Непривычная для меня манера на АМК-форуме почти каждый вопрос сопровождать 'последствиями'.

Последствия всегда есть, когда что-то/где-то поисходит ... А вот 'чреватые' они или наоборот - все относительно. ;-)

Кто-то последствия, наступающие порой после сэйса, называет катастрофой, а кто-то ... счастливыми. ;-)

(к сути)

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

Имена могут быть и одинаковыми, к 'фатальным' последствиям это не приводит. Хотя создать такие объекты нужно тоже постараться, т.к. в том же all.spawn'e для одной локации нет причин это делать, самому модмейкеру сложнее разбираться что куда поставил. Простой скриптовой спавн назначает имя рандомно, добавляя суффиксом игровой идентификатор. Остается 'спавн по секции' ...

Так чем же все таки 'чревато'?

...

malandrinus, Похоже, что системное имя - рудимент от билдов. ... Да и нет нужды, поскольку и так есть уникальный id и назначаемый по желанию sid ...

А я бы не назвал рудиментом и не нужным. Собственно выше есть ответ (читаем #6075: "Как превратить ящик Сидорыча в квестовый тайник").

Поясню на этом примере: А что делать, если нет желания или возможности ковырять all.spawn или присваивать sid нет-пакетами? Да и sid'ов в игре может быть в 2-раза меньше чем игровый id и на все про все может и не хватить (учитывая аппетиты модмейкеров и рост новых локаций).

 

У меня в моде (Симбион) в этот ящик однократно спавнится книга. Сейчас ковыряюсь с новой схемой поведения неписей и в ящик у костра новичков (в деревне на Кордоне) захотелось заспавнить бутылку водки для проверки ... И все делается без ковыряния all.spawn'а и sid'ов а именно по имени и индексу локации.

Другой пример: В Баре заспавнены на столы водка, хлеб, ... Сейчас они имеют уникальные имена типа: "bar_vodka_0000". В игре и Меченый может выпить и закусить, и при схеме собирательства кто по столам пошмонать. Так и остаются после этого столы пустыми. Чтобы пополнить запасы опять же или sid'ы присваивать или проверять по координатам наличие на столах предметов ... Вот тут то уникальные имена для локации и годятся(!), облегчая поиск и проверку наличия именно того, что хочешь.

 

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

 

Изменено 16 Марта 2011 пользователем Artos

[Artos 99]

AKKK1, ответ на поверхности:

 

Как создается объект в игре? Как работает функция спавна?

В топике " Скриптование и спаун" уже сегодня давал краткое пояснение, дополню:

При создании новой игры движек начинает создавать объекты перечисленные в all.spawn'е, считавая и заданные параметры для каждого объекта, помимо тех, что заданы в его конфиг-секции (object:section_name). И т.к. задано и имя - то оно и присваивается сразу объекту.

Как спавнятся объекты скриптом, т.е. по функции (ре)спавна? Создается дефолтный объект в соответствии с его конфиг-секцией: create("section_name",...) и движек назначает объекту имя, всегда добавляя к имени суффиксом идентификатор созданного объекта. И только потом можно объекту что-то добавить/изменить, но(!) уже НЕ его имя (которое в недоступной для прямых правок секции нет-пакета 'cse_abstract').

 

Т.о. респавненный объект не получит имя 'escape_lager', а получит именем типа 'escape_lager23456' и, если работа завязана на конкретном имени объекта (а таких немало) - она (работа) уже до конца игры не будет задействована в случае гибели и исчезновения/удаления неписи. В этом случае только спавн по заведомо известной секции из all.spawn'а можно 'воссоздать' объект с нужным именем. Штатный респавн подобным не занимается.

Изменено 16 Марта 2011 пользователем Artos

[Artos 99]

=VENOM=, немного покритикую ;-)

 

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

2. Числовые значения для class_id могут в модах и изменяться по мере добавления новых объектов. Не стОит привязываться к конкретному значению (ИМХО) ведь можно использовать вместо 83 -> 'clsid.inventory_box'.

3. Почему то принято итерацию проводить до 65535, хотя 65535 - это уже технологический (временный) индекс и такого объекта в игре по сути не может быть. Мелочь, но повторяется многими ...

 

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

function get_invbox_by_level_and_name(sBoxName, sLevelName_for_Box)
 for id=1,65534 do
   local seObj = alife():object(id)
   if seObj and seObj:clsid() == clsid.inventory_box and seObj:section_name() == "inventory_box" and seObj:name() == sBoxName then
     local idGv = seObj.m_game_vertex_id --/ гейм-вертекс ящика
     if idGv and game_graph():valid_vertex_id(idGv) then --/ проверяем валидность гейм-вертекса
       local oVertex = game_graph():vertex(idGv) --/ глобальный вертекс ящика
       if oVertex then
         local idLevel = oVertex:level_id() --/ (числовой) индекс уровня/карты
         if idLevel then
           local sLevelName = alife():level_name(idLevel) --/ имя уровня/карты
           if sLevelName == sLevelName_for_Box then --/ это заданный уровень?
             news_manager.send_tip(db.actor, sBoxName, 0, "default", 8000) --/ сообщение на игровой экран
             return seObj --/> серверный объект искомого ящика
           end
         end
       end
     end
   end
 end
end

- его конечно можно подоптимизировать 'по месту', убрав излишние строки/перепроверки и закешировав результаты, но это уже ... забота модмейкера. :-)

 

P.S. О, пока готовил пост уже и malandrinus о том же высказался.

Изменено 16 Марта 2011 пользователем Artos

[Artos 99]

=VENOM=, аналогично, но(!) суть не в самой оптимизации, а в алгоритме. Это всего лишь заготовка(!) для тех, кто или использует готовенькое или не прочь доковырять под себя и свои нужды. Да и не бывает все всегда однозначно!

 

Я же специально написал: оптимизация забота модмейкера! А если ух озабочен оптимизацией, то и делать это нужно всерьез и конкретно.

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

Для циклов/схем - это особый разговор и я не зря упомянул о 'кешировании'.

В 'боевом' для меня варианте при статре игры единожды выполняется инициализация всех ящиков, создается их массив и далее остается только указать требуемое имя ... Никакая оптимизация использования порядка проверок по числим/строкам не даст такой выгоды как переход от итерации общего массива игровых идентификаторов (1...65534) к частной (1...25) :-)

Так что это уже скорее вопрос 'религии' модмейкера, т.е. кто к чему привык и что предпочитает. Я, как правило, предпочитаю 'оптимальную универсальность', перед 'оптимизированной частностью'.

 

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

local tInvBoxes = {} --/ массив Id для ящиков (по локациям)

function get_invbox_by_level_and_name(sBoxName, sLevelName_for_Box)
 local idInvBox = tInvBoxes[sLevelName_for_Box] and tInvBoxes[sLevelName_for_Box][sBoxName]
 if not idInvBox then --/ заданный ящик еще не был найден
   local sim = alife() --/ кешируем заодно уж и функцию
   for id=1,65534 do
     local seObj = sim:object(id)
     if seObj and seObj:clsid() == clsid.inventory_box and seObj:section_name() == "inventory_box" then
       local idGv = seObj.m_game_vertex_id --/ гейм-вертекс ящика
       if idGv and game_graph():valid_vertex_id(idGv) then --/ проверяем валидность гейм-вертекса
         local oVertex = game_graph():vertex(idGv) --/ глобальный вертекс ящика
         if oVertex then
           local idLevel = oVertex:level_id() --/ (числовой) индекс уровня/карты
           if idLevel then
             local sLevelName = sim:level_name(idLevel) --/ имя уровня/карты
             if not tInvBoxes[sLevelName] then
               tInvBoxes[sLevelName] = {} --/ создаем подмассив для локации
             end
             tInvBoxes[sLevelName][seObj:name()] = id --/ запоминаем идентификатор найденного ящика
             if seObj:name() == sBoxName then
               idInvBox = id --/ запоминаем идентификатор искомого ящика
               news_manager.send_tip(db.actor, sBoxName..":"..tostring(id), 0, "default", 8000) --/ сообщение на игровой экран (один раз!)
             end
           end
         end
       end
     end
   end
 end
 return idInvBox and alife():object(idInvBox) --/> серверный объект искомого ящика или nil
end

 

- и это опят все же 'заготовка', т.к. немало чудачеств еще стОит учесть.

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

Изменено 16 Марта 2011 пользователем Artos

[Artos 99]

Gonarh, читаем исходник вопроса:[spoiler=Вопрос AKKK1:]

Вот что интересно есть обьект(нпс) с уникальным именем в алл спавне escape_lager ....

допустим новичек в гулаге escape_lager

и соответствуюшей кастом датой типа

escape_lager = true

 

так вот при его гибели (через некоторое время) сработает респаун или будет найден и назначен на

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

 

 

Так вот параметр escape_lager = true сохрантся для него ?

и какие имена получают отреспауниные неписи?

 

Конечно вопрос задан ... некорректно, но ответить можно на понятные части:

а) Параметр, напрямую заданный в кастомдате в all.spawn'е, никак не передается другому неписю, т.е. НЕ наследуется.

б) Имена отреспавненные неписи получают, как уже и писал ранее, стандартно, но НЕ управляемо: т.е. к строке секции/имени профиля добавляется свободный на текущий момент игровой идентификатор выделенный сервером. Иначе: если даже, например, убить Волка, уничтожить его в аномалии (или просто удалить скриптом из игры) и попробовать (от)респавнить вновь по секции/профилю, то никак новый Волк не получит имени object:name() == "esc_wolf".

Не стОит путать 'имя' с секцией объекта или именем его профиля, это совершенно разные вещи.

 

В гулагах эксклюзивные работы могут привязываться к конкретным неписям по рузному: через 'story_id', 'profile_name' или 'name' ...

Так вот, если привязка по имени, как например, командир блок-поста вояк на Кордоне: obj_info.name == "esc_blokpost_commander", то при его гибели привязанные к его имени работы: "logic@esc_blockpost_kamp2" и "logic@esc_blockpost_commander_day" - уже НЕ будут никому выдаваться, какими бы клонированиыми не были профили его потенциальных приемников/потомков.

 

Резюме, вытекающее из вопроса:

Отреспавненные неписи МОГУТ быть назначены на освободившуюся работу, однако или логика этих неписей должна быть свободна от гулагов, т.е. пригодна для различных гулагов, или 'ручками' записывать принадлежность к нужному гулагу.

Если же работа привязана к эксклюзивному имени неписи, то ...

а) или в скрипте поменять условие выдачи, привязав к воспроизводимому при (ре)спавне параметру ('story_id', 'profile_name').

б) или (ре)спавнить уничтоженного непися по секции из all.spawn'а (по сути непись возождается в первозданном виде и с экслюзивным имененм).

[Artos 99]

AKKK1

Не стОит публично глаголить глупости.

1. Загляни в se_zones.script из АМК и увидишь перепаковку аномалий (function repack_zone(packet,size)), вызываемую из 'STATE_Read'. помимо определения радиуса строка: packet1:w_u8(0) -- restrictor_type - всем аномалии устанавливает '0'.

У вновь спавнящихся рандомных и говорить нечего, т.к. всем им дается дефолтный 0.

 

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

Посмотри в all.spawn'е левел вертексы для всех костров на Кордоне - они все одинаков и НЕ имеют отношения у реальным положениям на локации. Если считаешь их параметры уже в игре - увидишь, что они все стали соответствовать реальной сетке.

 

Полтергейст

В АМК уже есть все, чтобы писать в аномалии (amk.get_anomaly_data/amk.set_anomaly_data). Остается только добавить нужный параметр для установки (в amk_anoms.script) и отключить перепаковку.

Вот только зачем? Неписи будут рулить по Зоне обходя с завязанными глазами все аномалии, а т.к. спавнятся аномалии рандомно и в немалом кол-ве, то ... перекрытые пути и проблемы с 'any vertex' - обеспечены.

 

Добавлено через 16 мин.:

Макс 105, аномалии удаляет НЕ артефакт, а скрипт, который определяет что ты выбросил некий конкретный предмет (в частности артефакт) и по этому факту удаляет находящуюся поблизости аномалию заданного типа.

Т.е. НЕ функция привязана к артефакту, а наоборот.

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

Однако и удаление аномалий не самое простенькое дело и ... коды NLC6 не просто править ... не имея навыков.

Изменено 22 Марта 2011 пользователем Artos

[Artos 99]

Макс 105, а при чем тут удаление аномалии артефактом/предметом и прохождение через нее неписей?

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

 

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

 

Добавлено через 22 мин.:

AKKK1

Повторяю, что параметры для левел- и гейм- вертекса, заданные в all.spawn'е (по сути это доп.конфиг) для объектов при спавне НЕ важны (почти). Вспомни, сам наверное не раз при спавне брал их 'с потолка', а точнее от актора.

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

 

О причине по которой именно на Кордоне объекты имеют 0-ой геййм-вертекс при спавне - можем предполагать: Актор (ГГ) спавнится именно на Кордоне и все (почти) объекты попадают в алайф текущей локации. По выше написанной причине заморачиваться с индексами гейм-вертексов нет особой нужды. 0-ой вертекс принадлежит именно Кордону и объекты 'сами' найдут точные значения практически сразу после начала игры.

На остальных локациях посложнее. Отдельные алгоритмы/функции в игре просчитывают и НЕ текущую локацию ... при этом могут потребоваться/использоваться именно вертексы - вот и возникла необходимость/желательность расставить объекты на заранее определенные точки/вертексы.

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

 

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

Изменено 22 Марта 2011 пользователем Artos

[Artos 99]

Полтергейст

Конечной цели можно достигать (как правило) различными путями.

Можно и чесать левой пяткой правое ухо или почесать об стену, каждый выбирает свое. ;-)

Немного о твоем варианте "обхода аномалий":

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

Твой вариант: неписи как экстрасенсы разруливают по Зоне между аномалиями, иногда все же попадая в некоторые. По-мне, такая Зона и тупость/яснозоркость ботов неинтересны ...

 

2. Уйти от необходимости расчищать пути от аномалий врядли удастся. Да и это далеко НЕ панацея, тут далеко не все просто.

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

 

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

 

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

 

Министр, не находишь, что мое 'почти' и твое 'не совсем' - об одном и том же? :-)

Всегда найдутся исключения из правил. Всегда найдутся ситуации, когда какие-то условия не выполняются или выполняются иначе/с оговорками ...

А по конкретно твоему примеру: Ты дал недостаточно информации, но можно предположить, что корни проблемы в ином аспекте. Укрытия собственно НЕ объект. Это область, описанная набором координат, привязанным к некоторому объекту игры. И если что-то не так или с самим объектом (рестриктором, ...) или некорректно задан набор координат, или некорректно обрабатывается заданный набор - то и результат будет отличный от ожидаемого.

Я говорил про объекты, а ты в примере - уже о производной, полученной возможно некорректным способом или в некорректной ситуации.

Живой пример: Решал оптимизировать алгоритмы для костров. Задался целью сделать костровой массив сразу и для всего ... т.е. при старте собираются все данные и позже все схемы/модули используют уже готовые параметры.

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

Так что учитывать необходимо и временнЫе параметры при спавне объектов, особенно на старте игры.

 

Макс 105, давно бы выложил сэйв и кто-нибудь помог бы режить проблему.

В твоем варианте гораздо проще определить неудобный объект аномалию и на старте игры ее просто отключить/удалить.

Если это не специально сделано разрабами, дабы закрыть 'путь в никуда' - то такой разовый момент не требует создания новых анигиляторов аномалий ...

 

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

Кстати вопрос(!):

Все знают о массиве/классе 'clsid'. Практически все числовые идентификаторы'class_id' из него пожно получить по уже известным полям/ключам. Однако, именно для кострового пламени (секция [zone_flame_small] с классом 'Z_CFIRE' в конфиг-файле) не могу найти наименования ключа/поля (типа: clsid.zone_zharka_s).

Кто знает? А то читать класс из конфиг-файла как то ... надоело. ;-)

[Artos 99]

malandrinus

'clsid.zone_campfire' - это все же НЕ для ТЧ (SHOC) :-(

 

Спасибо за ответ, и хотя он практически для меня не дал результата, но(!) ... подтвердил безрезультатность дальнейших поисков (уж если ты не знаешь ...) и приступить к брутфорсу этого массива. Может и удасться наткнуться на положительный результат.

 

P.S.

Дополню по отключению аномалий (не столь для тебя, сколь для других):

Удаление аномалий 'оптом' или даже по одиночке может быть не столь критично к скриптам (все же нормальные скрипты пишутся с необходимыми перепроверками ...), сколь для движка. Поясню:

Если в аномалию попал труп, то и аномалии и трупу прописываются соответствующие рестрикторы (dynamic_in_restrictions/dynamic_out_restrictions). Прописываются в юзердаты объектов и соответственно сохраняются в сэйвы(!).

Т.о. если удалить даже на старте игры (сэйва) подобную 'задействованную' аномалию - чтение рестриктора из 'аномального' трупа приведет к фатальной ошибке из-за ненайденного рестриктора.

Требуется вначале отключить аномалию ( obj:disable_anomaly() ) и после апдейта трупа - рестриктор отключенной аномалии (dynamic_out_restrictions) будет 'забыт', что позволит относительно безболезненно удалять аномалию.

 

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

Изменено 24 Марта 2011 пользователем Artos

[Artos 99]

malandrinus

Сорри за свой некорректный вопрос, совсем замодился ...

Т.к. мы в топике '[SoC] Ковыряемся в файлах' - то и не'посчитал обязательным уточнять для какого именно варианта игры (ТЧ/ЧН/ЗП).

Сам же выдрал этот класс (Z_CFIRE) из ЧН и приделал к костровому пламени (zone_flame_small) в ТЧ и подзабыл.

Более точный вопрос таков:

В классе/массиве 'clsid' (ТЧ/SoC) имеется под неизвестным мне ключом массива - 'class_id' (числовое значение поля в массиве), который соответствует костровому пламени в ЧН/ЗП (класс Z_CFIRE или скрипт-класс 'clsid.zone_campfire').

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

При присвоении секции [zone_flame_small] класса Z_CFIRE (вместо Z_MBALD) и в ТЧ появляется возможность легко отличить костры от аномалий (по class_id), однако напрямую (по ключу) этот класс недоступен из массива 'clsid'.

Каков этот ключ или как его определить? Иначе: каков скриптовой класс (в ТЧ!) для полученного таким образом объекта?

Изменено 24 Марта 2011 пользователем Artos

[Artos 99]

malandrinus

В общем то сейчас после попытки доформулировать/пояснить сделанное - разобрался (почти) ...

 

Пояснение (может кому пригодится):

 

В ТЧ костры (точнее пламя, которое и дает хиты) приходится отлавливать (во многих модах) по их секции (zone_flame_small) и по системному имени, отсекая лишнее маской (типа: "flame_small").

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

б) Костры попадают в один ряд с аномалиями других типов, и приходится дополнительно фильтровать в 'аномальных' алгоритмах, например при дин.респавне. Тоже съедает ресурсы.

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

 

В ЧН/ЗП костры уже выделены в отдельный класс (Z_CFIRE => clsid.zone_campfire), что облегчает работу с ними.

 

Ничего не мешает вроде как сделать подобное и в ТЧ(!).

Находим в конфиг-файле '\gamedata\config\misc\zone_kampfire.ltx' искомую секцию [flame_small] и меняем в ней строку/параметр^

'class = Z_MBALD' на 'class = Z_CFIRE'.

Костры по прежнему остаются кострами, которые и горят и жгутся (для неписей и актора) ... но уже перестали определяться аномальными скриптами(!).

 

Моя заморочка, которая и породила вопрос: В массиве 'clsid' исходной игры имеем 187 полей для различных зарегестрированных в игре классов.

Но(!), в рабочем моде, т.е. при добавлении доп.классов, одно поле 'clsid.??? = 185' оказалось пропущенным (пустым) и мне не удалось его определить. Получилась 'дырка'.

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

 

В общем в итоге: При изменении класса Z_MBALD на Z_CFIRE для 'zone_flame_small' получаем прямой доступ к объектам кострового пламени как:

zone_flame_small=[Z_CFIRE] = clsid.zone_dead = 178 (в чистой игре!). Быстро, удобно и не им еем коллизий (вроде) с чем-то другим. :-)

 

===

(Вот только ... что же за дырка с 185-ым классом(?) не дает покоя :-) )

;--/ userdata 'clsid' (ClassID)
clsid.art_bast_artefact       =   0
clsid.art_black_drops         =   1
clsid.art_gravi_black         =   2
clsid.art_dummy               =   3
clsid.art_electric_ball       =   4
clsid.art_faded_ball          =   5
clsid.art_galantine           =   6
clsid.art_gravi               =   7
clsid.art_mercury_ball        =   8
clsid.art_needles             =   9
clsid.art_rusty_hair          =  10
clsid.art_thorn               =  11
clsid.art_zuda                =  12
clsid.bloodsucker             =  13
clsid.boar                    =  14
clsid.burer                   =  15
clsid.cat                     =  16
clsid.controller              =  17
clsid.crow                    =  18
clsid.dog_black               =  19
clsid.psy_dog_phantom         =  20
clsid.psy_dog                 =  21
clsid.dog_red                 =  22
clsid.flesh                   =  23
clsid.flesh_group             =  24
clsid.fracture                =  25
clsid.pseudo_gigant           =  26
clsid.graph_point             =  27
clsid.chimera                 =  28
clsid.phantom                 =  29
clsid.poltergeist             =  30
clsid.snork                   =  31
clsid.stalker                 =  32
clsid.script_stalker          =  33
clsid.trader                  =  34
clsid.script_trader           =  35
clsid.tushkano                =  36
clsid.zombie                  =  37
clsid.wpn_ammo                =  38
clsid.artefact                =  39
clsid.wpn_ammo_m209           =  40
clsid.wpn_ammo_og7b           =  41
clsid.wpn_ammo_vog25          =  42
clsid.game_cl_artefact_hunt   =  43
clsid.game_cl_deathmatch      =  44
clsid.game_cl_LastStanding    =  45
clsid.game_cl_single          =  46
clsid.game_cl_team_deathmatch =  47
clsid.helicopter              =  48
clsid.script_heli             =  49
clsid.car                     =  50
clsid.device_pda              =  51
clsid.device_detector_simple  =  52
clsid.device_torch            =  53
clsid.equ_exo                 =  54
clsid.equ_military            =  55
clsid.equ_scientific          =  56
clsid.equ_stalker             =  57
clsid.equ_stalker_s           =  58
clsid.wpn_grenade_f1          =  59
clsid.wpn_grenade_fake        =  60
clsid.level                   =  61
clsid.game                    =  62
clsid.wpn_grenade_rgd5        =  63
clsid.wpn_grenade_rpg7        =  64
clsid.hud_manager             =  65
clsid.obj_antirad             =  66
clsid.obj_attachable          =  67
clsid.obj_bandage             =  68
clsid.obj_bolt                =  69
clsid.obj_bottle              =  70
clsid.obj_document            =  71
clsid.obj_explosive           =  72
clsid.obj_food                =  73
clsid.obj_medkit              =  74
clsid.level_changer           =  75
clsid.main_menu               =  76
clsid.mp_players_bag          =  77
clsid.online_offline_group    =  78
clsid.actor                   =  79
clsid.obj_breakable           =  80
clsid.obj_climable            =  81
clsid.hanging_lamp            =  82
clsid.inventory_box           =  83
clsid.obj_physic              =  84
clsid.script_phys             =  85
clsid.projector               =  86
clsid.switcher                =  87
clsid.obj_phys_destroyable    =  88
clsid.obj_phskeleton          =  89
clsid.respawn                 =  90
clsid.script_zone             =  91
clsid.artefact_s              =  92
clsid.car_s                   =  93
clsid.script_object           =  94
clsid.smart_terrain           =  95
clsid.smart_zone              =  96
clsid.bloodsucker_s           =  97
clsid.boar_s                  =  98
clsid.burer_s                 =  99
clsid.cat_s                   = 100
clsid.chimera_s               = 101
clsid.controller_s            = 102
clsid.psy_dog_phantom_s       = 103
clsid.psy_dog_s               = 104
clsid.dog_s                   = 105
clsid.flesh_s                 = 106
clsid.gigant_s                = 107
clsid.fracture_s              = 108
clsid.poltergeist_s           = 109
clsid.pseudodog_s             = 110
clsid.snork_s                 = 111
clsid.tushkano_s              = 112
clsid.zombie_s                = 113
clsid.hlamp_s                 = 114
clsid.space_restrictor        = 115
clsid.script_restr            = 116
clsid.spectator               = 117
clsid.game_sv_artefact_hunt   = 118
clsid.game_sv_deathmatch      = 119
clsid.game_sv_LastStanding    = 120
clsid.game_sv_single          = 121
clsid.game_sv_team_deathmatch = 122
clsid.device_torch_s          = 123
clsid.turret_mgun             = 124
clsid.game_ui_artefact_hunt   = 125
clsid.game_ui_deathmatch      = 126
clsid.game_ui_single          = 127
clsid.game_ui_team_deathmatch = 128
clsid.wpn_ak74_s              = 129
clsid.wpn_binocular_s         = 130
clsid.wpn_bm16_s              = 131
clsid.wpn_groza_s             = 132
clsid.wpn_hpsa_s              = 133
clsid.wpn_knife_s             = 134
clsid.wpn_lr300_s             = 135
clsid.wpn_pm_s                = 136
clsid.wpn_rg6_s               = 137
clsid.wpn_rpg7_s              = 138
clsid.wpn_scope_s             = 139
clsid.wpn_shotgun_s           = 140
clsid.wpn_svd_s               = 141
clsid.wpn_svu_s               = 142
clsid.wpn_usp45_s             = 143
clsid.wpn_val_s               = 144
clsid.wpn_vintorez_s          = 145
clsid.wpn_walther_s           = 146
clsid.wpn_ak74                = 147
clsid.wpn_binocular           = 148
clsid.wpn_bm16                = 149
clsid.wpn_fn2000              = 150
clsid.wpn_fort                = 151
clsid.wpn_grenade_launcher    = 152
clsid.wpn_groza               = 153
clsid.wpn_hpsa                = 154
clsid.wpn_knife               = 155
clsid.wpn_lr300               = 156
clsid.wpn_mounted             = 157
clsid.wpn_pm                  = 158
clsid.wpn_rg6                 = 159
clsid.wpn_rpg7                = 160
clsid.wpn_scope               = 161
clsid.wpn_shotgun             = 162
clsid.wpn_silencer            = 163
clsid.wpn_stat_mgun           = 164
clsid.wpn_svd                 = 165
clsid.wpn_svu                 = 166
clsid.wpn_usp45               = 167
clsid.wpn_val                 = 168
clsid.wpn_vintorez            = 169
clsid.wpn_walther             = 170
clsid.wpn_wmagaz              = 171
clsid.wpn_wmaggl              = 172
clsid.zone_bfuzz_s            = 173
clsid.zone_electra_s          = 174
clsid.zone_galant_s           = 175
clsid.zone_ice_s              = 176
clsid.zone_mbald_s            = 177
clsid.zone_mincer_s           = 178
clsid.zone_zharka_s           = 179
clsid.zone_acid_fog           = 180
clsid.ameba_zone              = 181
clsid.zone_bfuzz              = 182
clsid.zone_dead               = 183;--/#!# Z_CFIRE
clsid.zone_galantine          = 184
clsid.<NOT_Found!>            = 185;--/#?#
clsid.zone_mosquito_bald      = 186
clsid.zone_mincer             = 187
clsid.zone_mines_s            = 188
clsid.nogravity_zone          = 189
clsid.zone_radioactive        = 190
clsid.zone_rusty_hair         = 191
clsid.team_base_zone          = 192
clsid.torrid_zone             = 193
clsid.zone                    = 194

 

Изменено 24 Марта 2011 пользователем Artos

[Artos 99]

malandrinus

То, что 'так делать нельзя' - знаю, не новичок все же ... Но как говориться ... если лчень хотсА, то ... можно. :-)

Добавив подобным образом (вначале!) - не нашел никаких проблем/ошибок в игре - и использовал.

Одноко (еще раз спасибо твоему первому ответу!) сделал 'по-человечески', тем более это мне и так потребовалось.

 

Занес 'Z_CFIRE' с 'zone_campfire' в 'class_registrator.script', тем самым потеснив (как ты и сказал) 'clsid.zone_dead'.

Заодно конечно добавил обработчик "se_zones.se_zone_campfire", в котором теперь ловить все костры стало проще (чем перебором).

 

Однако с дыркой (теперь = 186) так и осталась непонятка. Твое предположение о 'Z_MINES' неверно, т.к. clsid.zone_mines_s есть в моей таблице (188), но ... буду искать (неспешно).

[Artos 99]

Gideon Vi

Не ковыряй там, где не уверен ...

Смотришь табличку "level_anoms' в 'amk_anoms.script'.

 

На примере 1-ой строки таблицы (для АМК): l01_escape={100,150,1000,{mosquito_bald=60 ,mincer=30 ,witches_galantine=10}},

 

l01_escape - это уровень, для которого предназначены следующие параметры;

 

100,150,1000 - количества вномалий на локации: минимум. максимум, лимит;

Т.е. это именно то, что тебе нужно:

Минимум (100) - сколько минимально заспавнится аномалий на локацию при дин. (ре)спавне;

Максимум (150) - сколько максимум заспанится аномалий на локацию при дин. (ре)спавне;

Лимит(1000) - предел кол-ва аномалий для локации, т.е. аномалии более спавниться не будут.

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

 

Следующие данные - это процентное соотношение типов аномалий, которые будут рандомно спавниться. Сумма (60+30+10) должна обязательно быть равна 100(%). Так что можешь и ассортиментом аккуратно(побаловаться).

 

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

Изменено 26 Марта 2011 пользователем Artos

[Artos 99]

Мда-а-а ... сколь же мусора в ответах и вопросах ....

Внесу правки, в то, что режет глаза:

 

1. Активная схема (имя) хранится в поле 'active_scheme' акторского стораджа (хранилища), т.е.:

 

local Active_Scheme = db.storage[obj_id].active_scheme --/ где obj_id - игровой идентификатор объекта NPC

 

Т.о. (разжевываю для Whisper) чтобы узнать находится ли непись (NPC) под схемой "Чуваки сидят у костра" (kamp) достаточно получить каким-либо образом игровой идентификатор нужного NPC и проверкой:

 

if db.storage[obj_id].active_scheme and db.storage[obj_id].active_scheme == "kamp" then

 

- узнать есть ли вообще активная схема у непися и искомая ли это схема.

 

2. В поле 'active_section' хранится активная секция (упрощенно - часть схемы). Она может быть одна для схемы, а может быть и несколько (чаще всего), что приписывается в конфигах логики.

 

3. В поле 'section_logic' хранится секция логики (часть схемы), которая предназначается для активации, считывается из сэйва или устанавливается при конфигурации схем(ы).

 

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

Например для Лиса на Кордоне: активная секция может быть 'kamp@esc_stalker_fox', которая является частью схемы 'kamp'.

Изменено 21 Мая 2011 пользователем Artos

[Artos 99]

Spezer

Не стОит валить с больной головы на здоровую, ACDC тут совершенно не при чем (точнее не его вина).

Когда ты ковыряешься в all.spawn'е, до(у)бавляя секции объектов - тем самым изменяется кол-во секций как общее число, так и по локациям.

ACDC при компиляции соответственно изменяет порядок (индексацию) следования секций объектов.

В АМК-моде имеются моменты, когда объекты удаляются и затем переспавнятся по номеру секции из all.spawn'а. Так, например, закрывается и затем открывается переход с Кордона на ТД.

Т.о. греши на свою невнимательность и приводи в скриптах, которые спавнят объекты по номерам секций, номера в соответствии с вновь тобою скомпилированным all.spawn'ом. Обрати внимание на объекты с story_id = 6000 и 830.

 

KD87

В m_stalker.ltx для секции [stalker_sakharov] предусмотрены соответствующие иммунитеты [stalker_immunities_sakharov] (все 0.0), что его и его клонов делает практически бессмертными ... Хотя делать всех квестовиков 'сахарными' клонами ... это уже не Сталкер (ИМХО).

Изменено 16 Июля 2011 пользователем Artos

[Artos 99]

n6260

Все же ответ "сколько угодно" - не корректен.

Имеются чисто 'физические' ограничители в кодах/движке:

Количество гейм-вертексов (game_vertex) имеет конечное число: 65535 (индекс хранится в 'u16').

Если 'средняя' локация будет иметь ~100...150 гейм-вертексов (например Бар имеет ~150) - то выходит всего ~ 500 локаций.

Если учесть, что некоторые параметры, учитывающие кол-во локаций и вовсе ограничены числом 255 (например параметр 'terrain' для неписей) - то выходит НЕ более 254 локаций.

 

Изменено 15 Августа 2011 пользователем Artos

[Artos 99]

Biler, n6260, _Val_

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

Если же оружие имеет опциональные навесы - то для их показа два варианта:

а) При надевании навеса - заменять предмет (менять секцию с другой моделю) на аналогичный, но с визуалом на котором виден навес.

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

Оба варианта требуют перевода объекта в оффлайн и обратно, дабы изменения были восприняты клиентской игрою.

 

ИМХО, для такой 'мелочи' подобное мало кому хочется реализовывать.

Изменено 17 Августа 2011 пользователем Artos

[Artos 99]

7.9

Т.к. далеко не все ящики биндятся (в 'bind_physic_object.script') - то для подобных операций с pstor'ом требуются принудительные действия, дабы активизировать бинд-методы save/load для ящиков без логики.

Ящики с логикой(!) биндятся в 'bind_physic_object.script', там же запоминаются.читаются их переменные (pstor).

Чтобы ящик биндился - для него требуется наличие логики или же ... 'ручками' добавить все (деже без логики) ящики в биндер (аналогично прожекторам). Тогда и будут активированы для всех них запись/чтение pstor'а.

 

Ну а для вновь заспавненных, можно просто добавить 'логику-пустышку' (типа 'treasure_inventory_box.ltx'), не ковыряя их биндер.

 

P.S. Ну или самое простое: хранить свою строку для ящика в сторадже актора, помня, что он все же не резиновый. :-)

Изменено 20 Августа 2011 пользователем Artos

[Artos 99]

7.9

СтОит давать более подобную информацию, иначе пустая трата времени на погадалки.

1. Наличие логики - прописывается в юзердате серверного объекта (см. нет-пакет -> параметр 'custom_data' или читай 'obj:spawn_ini()') и никак не может быть потеряно, если только скриптом же специально не почистить.

2. Если объект-ящик имеет логику - он обязательно биндится (добавляется в биндер). Подразумевается, что объект имеет в своей или родительской секции параметр: 'script_binding = bind_physic_object.init'.

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

 

Т.о. твое утверждение/предположение: "При переходе между локациями (туда и сразу обратно) ящик не "биндится" " - ошибочно. Ящик или биндится (имея логику) или нет, не зависимо загружается локация при переходе актора на этот уровень или же после 'ручного' сэйва.

Без доп.информации от тебя - можно сколь угодно спорить о теории.