Скриптование

[ColR_iT 171]

Лёха_тц, собственно у ПЫС это функция create, вот ее описание:

create(string <имя секции объекта>, vector* position, int level_vertex_id, int game_vertex_id, int parent_id)

подробнее о скриптовом спавне можешь прочитать здесь: http://www.stalkerin.gameru.net/wiki/index...вн_через_скрипт

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

 

Можно и через all.spawn. Берешь секцию любого физического объекта и меняешь путь модели на свой.

Изменено 12 Ноября 2011 пользователем ColR_iT

[ColR_iT 171]

AutoGnom

Для того, чтобы использовать функцию, её нужно разместить или сделать её вызов в файлах: либо xr_conditions.script, либо xr_effects.script, выбор зависит от того - используешь ли ты функцию, как условие или как эффект (надеюсь понятно в каком случае, куда писать функцию).

То есть:

on_info = {conditions}
;либо
on_ifo = %effects%

в случае использования функции в качестве условия и эффекта, нужно помнить:

для conditions (function - имя функции):

=function - требуется, чтобы function вернула true;

!function - требуется, чтобы function вернулся false.

для effects:

=function - в случае включения секции стартует функция function.

 

А вообще об использовании скриптов в логике можешь почитать здесь: >>Click Me<<

Изменено 29 Ноября 2011 пользователем ColR_iT

[ColR_iT 171]

alkogolik, выдать инфопоршен или выполнить функцию можно, но только при стрельбе не по любой точке двери.

hit_on_bone, работает с костями (в названии это видно), в скрипте написано следующее:

if self.st.hit_on_bone[bone_index] ~= nil then

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

hit_on_bone = 1|{+infoportion =function}

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

Для bone_index лично я нашел всего два значения, которые использовали ПЫС - это 1 и 2.

Изменено 22 Декабря 2011 пользователем ColR_iT

[ColR_iT 171]

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

Вот это пишешь в логику:

on_hit = hit
[hit]
on_info = {=chek_dictance} %+infoportion%

Где:

chek_dictance - функция в файле xr_condition следующего вида:

function chek_dictance ()
    local sid = 4 -- это Шустырй, нужно поставить свой story_id в секцию спавна радио и прописать его сюда
    local object = alife():story_object(sid)
    local object_pos = object.position()
    return actor_pos:distance_to_sqr(object_pos) >= 10000
end

infoportion - инфопоршен, который будет выдан, если функция chek_dictance вернет true.

[ColR_iT 171]

*Shoker*:

Во-первых: не делай поспешных выводов. xr_gulag.get_npc_gulag (obj) не возвращает объект типа строка.

Во-вторых: это уже обсуждалось на предыдущей странице.

 

TASTAN, могу ошибаться, но для для объекта гулага/смарта есть свойство name сравни его с именем нужного тебе гулага. Попробуй переписать строку так:

if smart and (smart.name ~= "mar_csky_base") and (level.name() == "marsh") then

Изменено 3 Января 2012 пользователем ColR_iT

[ColR_iT 171]

S.T.A.L.K.E.R-DOLG, боюсь, что losiara, тебя немножко сбил с толку.

Во-первых: для того, чтобы править логику НПС созданного без редактирования all.spawn - её (логику) нужно задавать через нет-пакеты.

losiara же привел тебе цитату с wiki и данное актуально именно при редактировании файла спавна.

center_point = kamp_center, здесь kamp_center - это название пути в файле way_название_локации распакованного all.spawn. Таким образом тебе нужно твои координаты писать в таком виде:

[kamp_center]
points = p0
p0:name = wp00
p0:position = -446.57,-0.2,-151.71
p0:game_vertex_id = 3905
p0:level_vertex_id = 258525

Совет! Давай имена более продуманно и развернуто, например novice_lager_kamp_center

 

def_state_moving = run - это состояние в котором НПС будут идти к точке kamp_center, если они отвлекутся на данжер или просто перейдут на эту схему. В данном случае - бег (run), все состояния можно посмотреть в файле state_lib.script из раздела "Ходячие состояния".

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

[ColR_iT 171]

losiara

хотя кто знает...

Вот видишь, сам же понял, что немного не к месту. По теме, но не к месту.

Ключевыми словами в вопросе были

без редактирования all.spawn

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

Если тебя не затруднит, то попрошу обращаться ко мне на "ты".

 

[ColR_iT 171]

S.T.A.L.K.E.R-DOLG, при такой логике НПС будет действовать следующим образом: изначально его активная схема будет remark1, в которой он будет просто стоять и всё, причем будет игнорировать опасность далее чем 5 метров.

Даже если НПС был заспавнен через скрипт, то тебе как минимум нужно знать, что в файле all.spawn есть уже готовая точка, причем с нужными тебе координатами, если же их нет - тебе нужно править спавн файл.

[ColR_iT 171]

losiara.

Вот тебе на примере логики Волка из гулага esc_lager:

-- Волк, собственной персоной.
t = { section = "logic@esc_lager_volk",
    idle = 0,
    prior = 16, state = {0,1},
    in_rest = "", out_rest = "esc_lager_guard_kill_zone",
    predicate = function(obj_info)
                    return obj_info.profile_name == "esc_wolf"
                end
}

здесь видно, что в качестве предусловия на данную работу стоит проверка, что имя профиля esc_wolf. Обрати внимание, что предусловие происходит безымянной функцией, хотя правильно это называется функтор. obj_info - это объект класса game_object, таким образом можно сделать проверки различного рода, например кого-нибудь у кого денег будет больше какой-либо суммы, либо НПС с определенным рангом:

-- проверка на деньги
function(obj_info)
    return obj_info.money > 5000 
end
-- проверка на ранг
function(obj_info)
    return obj_info.character_rank > 600 -- если не ошибаюсь, то это ветеран, мастер > 900
end

В принципе всё зависит от фантазии.

[ColR_iT 171]

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

У тебя поднимается второй рюкзак с именем predbannik_inventory_box_0008, поставь ему также fixed_bones = link и он подниматься перестанет.

 

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

Сообщение от модератора ColR_iT

HellStalkerDog и strelok200, задавайте, пожалуйста, вопросы в соответствующие темы.

Посты Ваши переместил, в следующий раз просто удалю.

Спасибо за понимание.

Изменено 7 Января 2012 пользователем ColR_iT

[ColR_iT 171]

Ребята, возник вопрос касательно функции load_job, что в файлах гулагов для локаций, а именно таблица t с описанием работы.

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

Итак... Привожу таблицу со всеми найденными и используемыми свойствами в оригинале ТЧ 1.0006, а также небольшое описание, возникшее в результате поиска, исследований и догадок:

t = {
    section = "logic@",             -- секция логики в файле config\misc\gulag_название_уровня.ltx;
    idle = ,                        -- пауза между выполнением данной работы;
    prior = ,                       -- приорите на работу. Чем больше значение, тем быстрее будет занята работа;
    state = {},                     -- состояние гулага. Необходимо для функции load_states где определяется это состояние, 
                                    -- т.е. какая из работ (с определенным состоянием) будет занята;
    squad = ,                       -- сквад;
    group = groups[],               -- будет выбран из массива groups, который задан в custom data. Массив индексируется начиная с 1;
    in_rest = "", out_rest = "",    -- разрешено / запрещено входить в указанные рестрикторы;
    info_rest = "",                 -- задается имя рестриктора и все денжеры снаружи этого рестриктора не попадают внутрь для человека, 
                                    -- находящегося на этой работе;
    predicate = ,                   -- условие приема на работу;
    position_threshold = ,          -- расстояние до места работы при котором персонаж в онлайне считается достигшим места работы.
    timeout    = ,                  -- время по окончании которого работа освобождается/становиться недоступна;
    online = ,                      -- если true, то на этой работе персонаж всегда в онлайне;
    idle_after_death =              -- в течении этого времени, после смерти предыдущего "работника", данная работа будет недоступна.
    }

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

Теперь собственно вопросы касательно этого:

1. Свойство idle. Определяет паузу перед тем, как НПС начнет выполнять работу вновь. Собственно вопрос: что происходит во время паузы? Переходит ли персонаж под какую-либо секцию, либо выполняет туже работу, например, если указан walker, но со значениями по умолчанию?
2. squad. Что именно определяет этот параметр. Понятно, что если не задан, то будет значение из профиля НПС, но в целом, для чего нужен squad?
3. group. Также не ясно. Каким образом данный параметр влияет на поведение НПС?
4. info_rest. Описание нашел в интернете, но, к сожалению, кроме путаницы мне в голову ничего не привносит. Я так понимаю, что в радиус данного рестриктора, для НПС на данной работе, враги заходить не будут. Так ли это?
5. position_threshold. Понимаю это так: если НПС на расстоянии ближе чем указанно, то гулаг уже начинает искать ему работу. Хотя мне почему-то казалось, что гулаг изначально резервирует место, т.е. занимает работу под найденного НПС.
6. timeout. Время вроде идет в миллисекундах, но это не суть важно, важно другое - после того, как вышло время, что становиться с работой? Возможно ли заново её занять?
7. online. Два возможных значени - true и false. Если быть честным, то недопонимаю для чего данный параметр.
8. idle_after_death. Единицы измерения вроде как тоже мсек. Изначально не понял для чего, потому как увидел его в работе для Макса, на Арм складах... странно то, что исходя из описания непонятно для чего она там была нужно, так как в работе стоит условие на приём именно Макса.
9. Ну и последний интересующий меня вопрос - есть ли еще какие либо свойства, которые можно определять через данную таблицу?

P.S. Извините за такое количество вопросов, но разделять их было (ИМХО) также глупо.

[ColR_iT 171]

Keng.

1. Да, можно. Простой пример - Волк. После выполнения ГГ задания в Темной Долине, он идет аж на Арм Склады. На счет выполнения рандомной работы ... ммм думаю - да, вполне возможно организовать.

2. В принципе возможно.

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

[ColR_iT 171]

Keng, НПС "проталкивает" оружием некоторые препятствия, через которые, по идее, не должны, из-за того, что они не взаимодействуют с геометрией как таковой. Они даже по ней не ходят (вопрос поднимался в соседней теме). Граниуц всех их движений (имеется ввиду место действия) определяет АИ сетка, поэтому, если она расположена близко к стене, а габариты НПС чуть более этого расстояния, то в игре и наблюдается таковое. По сути это тема для другого топика.

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

[ColR_iT 171]

nanshakov, а ты уверен, что твои НПС попадают под этот гулаг? Может гулаг уже пригреб кого-то?

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

К стати, под каким состоянием гулаг начинает работу (что у тебя в функции load_states)?

[ColR_iT 171]

nanshakov, много вопросов, причем мало определяющих... Все они (вопросы), скажем так, давно разжеваны, поэтому для начала могу посоветовать дать ссылку на очень хорошую статью на wiki: Настройка логики, там в пяти частях - долго, но информативно. Там ты найдешь ответы на заданные вопросы. Изменено 21 Января 2012 пользователем ColR_iT

[ColR_iT 171]

Мдааа... в принципе я ожидал, что и эта часть, скажем так, урезана.

Спасибо всем за пояснения.

Кстати я нашел ПЫСовское описание изначального назначения параметров team, squad и group, звучит оно следующим образом:

1. Команда (team).

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

- 0: к этой команде принадлежат: Актер, Торговец, Бармен, Представитель ученных, другие сюжетные миролюбивые персонажи. К этой команде также относятся все сталкеры-одиночки, которые по умолчанию должны быть нейтральными к актеру.

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

- 2: Военные сталкеры, армия.

- 3: Параноики, зомбированные и сумасшедшие сталкеры, которые уже с трудом могут принадлежать к какой то категории. Они сами по себе.

- 4: Reserved

- 5: Группировка «Долг»

- 6: Группировка «Грех»

- 7: Группировка «Монолит»

- 8: Сталкеры анархисты из группировки «Свобода»

- 9..31: Reserved

 

2. Отряд (squad)

Описывает принадлежность сталкеров из одной команды к разным группам внутри одного уровня. Это разделение существует внутри каждого уровня. Для каждой команды это разделение тоже особое. Значение отряда должно находится в пределах от 0 до 31.

 

3. Группа (group)

Описывает разбиение больших отрядов на более мелкие структурные единицы. Если такое разделение не нужно – дублирует отряд. Сталкерам одиночкам лучше давать уникальные группы. Значение группы должно находится в пределах от 0 до 31.

 

 

Распределение по сквадам и группам.

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

Группа ставится каждому человеку своя отдельная. Получается что на одном уровне не может быть больше чем 32 сталкеров одиночек в каждой команде. Итого 32 нейтральных, 32 злых. Если, скажем, необходимо поставить группу из трех бандитов – то всем им нужно ставить одинаковую группу. Тогда общее число сталкеров увеличится. Вообщем думаю что хватит с головой 

0: Escape

1: Garbage

2: Agroprom

3: DarkDolina

4: RostokBar

5:

6:

7:

8:

9:

10:

11-31: Reserved

Но вот, к большому сожалению, применение этих параметров в практических целях, я не наблюдал.

Знаю только, что изначально group использовалась для синхронизации передвижения НПС по путям, синхронизация производилась при помощи флага n в точках движения walk, а так же при условии нахождения НПС в одной группе.

Кстати о флагах точек путей, как оказывается их намного больше тех, которые описаны на Wiki:

Флаги пути path_walk:

 

n = 0 .. 9999 – номер точки синхронизации. Рекомендуется первой точке задавать значение 0, остальным – числа по возрастанию с произвольным шагом. Прийдя в точку с большим n, сталкер будет ждать отстающих напарников. Примечание: сталкер дожидается опаздывающих напарников _только_ в точках остановки (т.е. только в тех местах, где точка path_walk имеет общие флаги с одной из точек path_look).

Внимание – для поддержки зацикленных маршрутов, сталкеры на точке с минимальным n дожидаются сталкеров на точке с максимальным n. Поэтому минимальное количество точек синхронизации для корректной работы схемы должно составлять 3 точки или больше!

 

s = имя_звуковой_схемы – пробегая через эту точку, сталкер включит указанную звуковую схему. Звук стартует ДО начала поворота и старта анимации. Для того, чтобы звук стартовал синхронно с анимацией – задавайте его в path_look соответствующей точки, а не в path_walk. Если нужно стартовать звук одновременно с ЛЮБОЙ из анимаций в этой точке, можно воспользоваться параметром sa.

 

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

 

sa = true – ждать начала анимации в точке, прежде чем стартовать проигрывание звука (по умолчанию false).

 

sc = true – разрешить проигрывать звуки схемы неоднократно (по умолчанию false).

 

sf, st – временной интервал повторения фраз из выбранной звуковой схемы в секундах (по умолчанию от 5 до 10 сек).

 

p = 0 – 100 – при наличии в точке флажка, общего с одной из точек path_look, задает вероятность того, что персонаж остановится в точке (по умолчанию 100).

 

c = true – дальше перемещаться в присяде (по умолчанию false)

 

r = true – дальше перемещаться бегом (по умолчанию false)

 

d = true – перемещаться в состоянии danger (по умолчанию false)

 

ds = имена_диалогов – имена диалогов, которые разрешено стартовать начиная с этой точки (разрешение действует до следующей точки). Имена задаются в виде текстовой строки, разделенной запятыми: ds=bandits_talk,weather_talk и т.д.

 

ret = число – сразу же по прибытии в точку вызывает зарегистрированный при инициализации movement manager-а callback с этим числом в качестве второго аргумента.

 

rel = name,name,… - меняет отношение других персонажей к себе. Используется вместе с параметром ret. Вызывается менеджером перемещения подобно пользовательской callback-функции, при этом в rel перечисляются через запятую персонажи, у которых нужно сменить отношение к себе, а в ret задается, какое именно отношение нужно установить: 1 – хорошее, 0 – плохое. Пример: ”ret=0|rel=bandit1,bandit2” – установит у бандитов плохое отношение к персонажу, который пришел в данную точку пути.

 

w = имя_walk_пути – переводит схему на новый path_walk. Рекомендуется также задать новый path_look с помощью параметра ”l”, иначе текущий path_look будет сброшен. Персонаж идет на стартовую точку с режимом перемещения, заданным в точке с параметром ”w”. Настройки функции коллбека при переключении пути сохраняются.

 

l = имя_look_пути - сбросит схему на новый path_look. Задавать параметр ”l” нужно вместе с параметром ”w”, иначе ”l” будет проигнорирован. По умолчанию path_look при смене path_walk будет сброшен.

 

Флаги пути path_look:

 

p = 100 – вероятность, с которой персонаж посмотрит именно в эту точку. Значения p всех возможных точек суммируются, т.е. если у одной точки p = 100, а у другой 300, то персонаж посмотрит в первую с вероятностью 25%! (т.е. 100 из 400).

Рекомендуется задавать p так, чтобы их сумма составляла 100.

По умолчанию у всех точек p = 100.

 

a = анимация, которую проиграет персонаж, посмотрев в эту точку (по умолчанию idle). Для того, чтобы персонаж стоял в точке без анимации, задайте значение nil: ”a=nil”

 

nowpn = true – если персонаж должен спрятать оружие

 

c = true – смотреть в точку в присяде (по умолчанию используется значение одноименного поля из path_walk)

 

d = true – смотреть в точку в состоянии danger (по умолчанию используется значение одноименного поля из path_walk)

 

att = 1 или 2 – номер атаки (основная, вспомогательная). Можно использовать вместо анимации (например ”a=nil|att=1”), можно вместе с анимацией (”a=стреляем_в_потолок|att=1»).

 

t = время, которое персонаж будет ждать, играя анимацию или стреляя (по умолчанию 5000). Если требуется ждать бесконечно долго (например, это финальная точка пути), нужно задать t равным ”-1”.

Примечание: если персонаж ждет синхронизации в точке, то он будет играть анимацию столько времени, сколько нужно для того, чтобы дождаться напарников, но только по прибытию всех напарников на точки засечет заданное в ”t” время. Исключение составляет стрельба – персонаж не станет стрелять сразу по прибытию в точку, а сперва дождется напарников, а потом уже начнет стрелять в течение заданного времени.

 

s = имя - звук, который персонаж разово проиграет, посмотрев в эту точку.

 

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

 

sl = имя_прожектора – если задано, то при повороте в указанную точку персонаж также повернет и прожектор в неё.

 

ret = число – после поворота в целевую точку вызывает зарегистрированный при инициализации movement manager-а callback с числом ret в качестве второго аргумента. При этом время ожидания (поле t) игнорируется, т.е. после того как callback вызовет update_movement_state – персонаж сразу же пойдет дальше.

Вот только опять таки - какие из них рабочие, я пока не выяснил.

 

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

Ах, да... еще есть флаги предназначенные для вертолета, БТР, мобов и еще всякие, назначение которых совершенно не ясно...

Изменено 25 Января 2012 пользователем ColR_iT

[ColR_iT 171]

temakonkin, ты не правильные параметры передаешь в функцию create. Так, например, переменная lv это допустимый левел вертекс выбранный из таблицы, lv_1 и lv_e это тоже самое, абсолютно ничем не отличается. А также gv и gv_e это тоже одно и тоже - допустимый гейм вертекс из таблицы.

В функцию create же нужно передавать следующие параметры:

create (
        string,                 -- "имя секции объекта"
        vector* position,       -- координаты из трех точек
        int level_vertex_id,    -- левел вертекc уровня
        int game_vertex_id      -- гейм вертекс
        )

а ты что передаешь?

Чем ты руководствовался? И еще лог который ты привел, указывает, что ошибка в 42 строке файла mob_random_spawn_list.script, а код ты привел из 35 строк, так что недостача. И ссылочку на оригинал статьи скинь.

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

[ColR_iT 171]

temakonkin

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

count - количество мобов, которые будут заспавнены;

section - секция моба которая будет заспавнена;

А дальше по сути бред (уж извини за откровенность)...

lv - левел вертекс уровня;

gv - гейм вертекс;

lv_1 - опять левел вертекс уровня;

gv_e - опять гейм вертекс;

lv_e - и всё тот же левел вертекс уровня.

Как я уже писал, функция create принимает определенные параметры, один из которых вектор, состоящий из трёх координат, т.е. здесь:

vector():set(lv,lv_1,gv)

в качестве lv,lv_1 и gv должны быть координаты присущие уровню, а не те значения, которые принимают эти переменные в твоём случае.

Но и при всём при этом, ошибка, т.е. непосредственно сам вылет, происходит у тебя из-за другого, а именно из-за вот этой строки:

local lv = math.random(level_vertexes[level.name()]["lvid"]) --выбираем левел вертекс

Догадаешься почему?

P.S. Чтобы найти ошибку, сравни твой код с оригиналом, причем не на странице сайта, а желательно с возможностью подсветки синтаксиса, будет легче.

P.P.S. Нагрубить/обидеть/оскорбить не пытался и намерений таковых не было.

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

[ColR_iT 171]

Сообщение от модератора ColR_iT

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

Твой ответ в посте #3740 был, скажем так, резок.

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

И дабы не начинать споры ни о чём, пресечём их на корню.

Artos и *Shoker* - "давайте жить дружно!"©

Благодарю за понимание.

Изменено 3 Февраля 2012 пользователем ColR_iT

[ColR_iT 171]

KitkaT.Net, начнём с того, что ты не привёл некоторые свои правки, а именно:

- как ты распределяешь работы (у тебя два состояния state), делается это в том же gulag_escape.script в функции load_states;

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

А если на вскидку, то уже могу указать на некоторые не точности.

В секции kamp@esc_new_lager_kamp1, ты не правильно указал точку path_walk, она должна состоять из имени center_point, т.е. npc1_kamp и окончания _task, в итоге у тебя должно получится npc1_kamp_task.

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

Изменено 3 Февраля 2012 пользователем ColR_iT