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

[Artos 99]

malandrinus, опять мы несколько разными языками об одном, но...

FPS игры (приложения) и FPS рендера - суть едины (для игрока за монитором).

Частота обновлений биндера актора (число циклов в секунду) в точности соответствует игровому FPS (числу обновлений игрового экрана в секунду).

Вывод значений FPS, измерянной различными сторонними программами и скриптом на базе цикла апдейта актора, в точности соответствуют. Конечно, если говорить о замере за одну конкретную секунду, то результаты могут розниться, но средняя за 5 и более секунд - равны (с пренебрежимой погрешностью)! Это показывает практика.

Конечно, это косвенное соответствие, но в контексте вопроса подобные погрешности можно отбрасывать.

 

О частоте апдейтов актора и частоте вызовов от level.add_call:

Мною пишутся модули, многие из которых работают на любом патче ТЧ и на ЧН/ЗП. В нескольких из них (погода, обновления рестикторов, классов ...), апдейты выполнены именно на базе level.add_call. Пока, все варианты модов на этих модулях под всеми движками показывают, что нет никакого несоответствия между акторским и автономным апдейтом. Оговорю, что не занимался специально поиском расхождений между этими апдейтами, Вполне допускаю, что некие циклы пропускаются иль наоборот... но это в конечном счете никак не влияет ни на что.

Пока вижу во всех играх, что доп.коллбэк(и) срабатывает(ют) строго после каждого апдейта актора.

 

Ты что то замудренное сказал:

Кроме того, частота апдейтов актора вообще говоря подчиняется общему правилу для апдейтов всех объектов, т.е. чем дальше от актора, тем медленней.

Если актор всегда на одном и том же расстоянии от самого себя - то и нет никакой зависимости. А если она (зависимость по кодам) есть - то она константа (т.е. по сути нет зависимости).

 

Судя по трем вариантам вызова для метода level.add_call (различные параметры) - скорее это предназначалось для классов/менеджеров, а не конкретно объектов иль физ.объектов. Но вот какова причина, что тот же менеджер погоды разработчики лишили своего потока и завязали на акторский апдейт - неясно...

 

P.S.

В общем то, если исходить из заданного исходного вопроса, то:

Есть две основные задачи:

а) мониторинг некоего события

б) обновление ситуации в заданной периодичностью.

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

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

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

P.P.S.

Доп.преимущество level.add_call для подобных задач - нет необходимости влезать в коды биндера актора и регистрировать вызовы 'своих' скриптов/функций. Также, наличие методов level.remove_call (или из самого коллбэка) позволяет убирать коллбэки (закрывать поток), без обратной правки биндера.

Изменено 9 Октября 2012 пользователем Artos

[Malandrinus 615]

Artos,

измерения я проводил года четыре назад. С тех пор сменилось несколько поколений компьютеров, и мне сейчас физически не воспроизвести те условия. В то время слайдшоу на ТЧ у меня начиналось при средненьких параметрах динамики и разрешении 1024х768. Сейчас я даже на ЧН/ЗП не могу обеспечить просадку FPS до заметно низких значений ни на каком разрешении экрана при самых выкрученных настройках. Или может имело значение, что тогда у меня был однопроцессорный компьютер. Я не знаю точно, чтобы узнать, надо лезть в движок и разбираться, как синхронизируются отрисовка кадров, такты просчёта физики и обновления игровой логики.

 

Тем не менее тогда, несколько лет назад, я совершенно достоверно получал разницу между частотой апдейтов и FPS рендера. Тогда же я измерял частоту fastcall и тоже получал, что она в несколько раз выше частоты апдейтов. Тогда это для меня вполне объяснило название этого колбека и вообще необходимость в нём. Он действительно работал быстрее, чем просто апдейт.

 

Что касается того, что fastcall и add_call связаны с физикой движка. Это можно понять по внутренним названиям функций и классов.

[Artos 99]

malandrinus, согласен, что 3-5 лет назад мы имели и другие компы и знания/навыки, поэтому нынешние результаты отличны от прежних и гадать почему - врядли стОит. Исходим из реалий сегодняшних.

Зря мы сейчас углубились в обсуждение FPS, вскользь упомянутых Viнt@r'ем, т.к. с вопросом о level.add_call это все же не связано напрямую.

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

Замечу, что непонятно на каких результатах ты делаешь вывод о бОльшей скорости обновлений fastcall'а, но все мои тесты показывают, что эти вызовы не чаще акторских. Может быть та имеешь ввиду частоту по сравнению с апдейтами самих объектов, а не акторскими апдейтами?

Для себя я сделал вывод:

1. Т.к. параметром objects_per_update (=10) в конфиге (и не помню, еще где-то =32) ограничено число апдейтов для объектов не 'актор' (монстры/неписи/...) за один цикл, то естественно для каждого такого объекта средний период апдейта превышает акторский. Если еще учесть зависимость периодичности апдейтов от расстояния до актора (о чем ты уже упоминал), то средний апдейт для 'обычных' объектов значительно превышает акторский (~20...50ms), доходя и до секунды.

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

3. Ну а level.add_call - вероятно сходен по природе с fastcall'ом, но является не методом конкретного объекта, а 'автономным' методом, который применим как к объектам, так и 'вообще по нужде', давая возможность опять же иметь быстрые коллбэки для различных целей.

 

В итоге имеем варианты для организации и своих потоков (threads) на базе level.add_call, не зависимых от зависаний родительских, и дающих возможность по сути дублировать апдейты 'от актора', т.е. циклы следуют не реже.

Ну а уж если и есть какие-то нюансы - то это ж Сталкер ;-) и на то и дана голова, чтобы решать проблемы и достигать цели. :-)

Изменено 10 Октября 2012 пользователем Artos

[serega-gamer 0]

Всем здрасте! На днях написал скрипт для рем.комплекта и толком не протестировал, а сегодня заметил баг, проявляется он в том что функция будто зашкаливает делая одно и тоже (хотя вызывается один раз из интерфейса), в общем задумка была такая, функция сравнивает то что в слоте и в инвентаре по имени секции, если есть несколько одинаковых предметов то починка идёт если не то нет.А теперь о проблеме, когда в инвентаре не больше 2 одинаковых предметов и в слоте стоит идентичный им по секции предмет то всё идёт нормально а если предметов в инвентаре много, больше 2 тогда функция как будто зашкаливает, удаляет все идентичные предметы и так же проигрывает звуки починки (естественно наслаивая их друг на друга) подскажите пожалуйста, что здесь не правильно?

function repair_wpn_1()
local item_in_slot = db.actor:item_in_slot(2)
local act_rank = ranks.get_obj_rank_name(db.actor)
local cond_novice = item_in_slot:condition() + (math.random(20)+20)/100
local cond_experienced = item_in_slot:condition() + (math.random(20)+30)/100
local cond_veteran = item_in_slot:condition() + (math.random(20)+40)/100
local cond_master = item_in_slot:condition() + (math.random(30)+50)/100
for i= 0, db.actor:object_count() - 1 do
local item = db.actor:object(i)
if item:section() == item_in_slot:section() and item:id() ~= item_in_slot:id() and 0.20 <= item:condition() then
if act_rank == "novice" and 1.00 > item_in_slot:condition() and 0.20 <= item_in_slot:condition() then
item_in_slot:set_condition(cond_novice)
this.repair_wpn_sound()
alife():release(alife():object(item:id()), true)
elseif act_rank == "experienced" and 1.00 > item_in_slot:condition() and 0.20 <= item_in_slot:condition() then
item_in_slot:set_condition(cond_experienced)
this.repair_wpn_sound()
alife():release(alife():object(item:id()), true)
elseif act_rank == "veteran" and 1.00 > item_in_slot:condition() and 0.20 <= item_in_slot:condition() then
item_in_slot:set_condition(cond_veteran)
this.repair_wpn_sound()
alife():release(alife():object(item:id()), true)
elseif act_rank == "master" and 1.00 > item_in_slot:condition() and 0.20 <= item_in_slot:condition() then
item_in_slot:set_condition(cond_master)
this.repair_wpn_sound()
alife():release(alife():object(item:id()), true)
end
end
end
end

 

Изменено 11 Октября 2012 пользователем serega-gamer

[Viнt@rь 50]

serega-gamer, ты не подумал просто прервать цикл? Посмотри внимательнее, у тебя, цикл работает пока не переберет все объекты, которые есть в инвентаре, а по условию, если оно истинное, то выполняется действие, то есть, если 2 одинаковых объекта в инвентаре с тем, что в руках, то действие в цикле будет выполнятся 2 раза, если 3 обьекта - 3 раза и тп, поэтому, после выполнения нужного тебе действия, цикл нужно прервать!

Изменено 11 Октября 2012 пользователем Viнt@rь

[ColR_iT 171]

serega-gamer, причину тебе уже назвали. Но хотелось бы ещё добавить, что не очень то у тебя код оптимизированный получился. Может лучше так!?

local function check_condition (item_in_slot)
  return item_in_slot:condition() < 1 and item_in_slot:condition() >= 0.2
end
function repair_wpn_1()
  local item_in_slot = db.actor:item_in_slot(2)
  local act_rank = ranks.get_obj_rank_name(db.actor)
  local cond_standard = {
	 ["novice"]    = (item_in_slot:condition() + (math.random(20)+20)/100),
	 ["experienced"]    = (item_in_slot:condition() + (math.random(20)+30)/100),
    ["veteran"]    = (item_in_slot:condition() + (math.random(20)+40)/100),
    ["master"]    = (item_in_slot:condition() + (math.random(20)+50)/100),
  }
  for i = 0, db.actor:object_count() - 1 do
  local item = db.actor:object(i)
  if item:id() ~= item_in_slot:id() and item:section() == item_in_slot:section() then
	 if check_condition (item_in_slot) then
	    item_in_slot:set_condition(cond_standard[act_rank])
	    this.repair_wpn_sound()
	    alife():release(alife():object(item:id()), true)
	    return
	 end
  end
  end
end

 

[Viнt@rь 50]

ColR_iT,

 

ну, оптимизация - личное дело каждого), хочет оптимизирует, хочет - нет, просто вот ты написал уже оптимизированный вид, так человек просто скопипастит, да и все, в итоге не научится оптимизации))

 

 

 

[spoiler= ]А я вот тоже изначально так думал, пока мне не продемонстрировали мой же код, только раз в пять короче и быстрее. Если человеку не с чем будет сравнивать, то и учиться будет не на чём.

ColR_iT

Изменено 11 Октября 2012 пользователем ColR_iT

[Nazgool 250]

ColR_iT, можно ещё чуток "подкрутить"

local cond_standard = {
["novice"]	 = 20,
["experienced"] = 30,
["veteran"]	 = 40,
["master"]	 = 50,
}

function repair_wpn_1()
local item_in_slot = db.actor:item_in_slot(2)
if item_in_slot:condition() < 0.9 and item_in_slot:condition() >= 0.2 then -- сначала правильнее будет проверить - подходит ли вообще ствол для ремонта
 for i = 0, db.actor:object_count() - 1 do
	 local item = db.actor:object(i)
	 if item:section() == item_in_slot:section() then -- тут лучше сначала проверить, совпадает ли итем по названию секции? Как правило мы имеем пару-тройку одинаковых стволов. Все остальные (сотня? больше?) итемов не пройдут эту проверку. Зачем же зря гонять систему на две проверки (через and)?
		 if item:id() ~= item_in_slot:id() then -- а когда название секции совпадёт, то тогда и проверим - не в слоте ли он?
			 local act_rank = ranks.get_obj_rank_name(db.actor) -- и только теперь вычисляем ранг, ведь раньше он совершенно не нужен.
			 item_in_slot:set_condition(item_in_slot:condition() + (math.random(20) + cond_standard[act_rank])/100)
			 this.repair_wpn_sound()
			 alife():release(alife():object(item:id()), true)
			 return
		 end
	 end
 end
end
end

 

Изменено 11 Октября 2012 пользователем Gun12

[Artos 99]

Gun12, все же не до конца "подкручено"...

1. Отсутствует подстраховка, т.е. проверка - а есть ли вообще ствол в проверяемом слоте:

if item_in_slot and item_in_slot:condition() < 0.9 and item_in_slot:condition() >= 0.2 then

2. Если ориентироваться на "сотни" предметов в инвентаре, тогда уж стОит закешировать и секцию ствола и актора.

3. Удаление объекта из игры (да еще инвентарного) без проверки наличия в игре его серверной копии - чревато...

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

Итого, с учетом надежности кода, можно так:

function repair_wpn_1()
 local item_in_slot = db.actor:item_in_slot(2)
 --/ сначала правильнее будет проверить - имеется ли вообще ствол и подходит ли он для ремонта
 local item_condition = item_in_slot and item_in_slot:condition()
 if item_condition and item_condition < 0.9 and item_condition >= 0.2 then
   local actor = db.actor --/ кешируем акторский объект
   local item_section = item_in_slot:section() --/ кешируем секцию
   for i = 0, actor:object_count() - 1 do
  local item = actor:object(i)
  if item:section() == item_section and item:id() ~= item_in_slot:id() then
    local se_item = alife():object(item:id()) --/ проверяем наличие серверного объекта
    if se_item and se_item.m_story_id < 4294967295 then --/ квестовые не удаляем!
	  local cond_standard = { novice = 20, experienced = 30, veteran = 40, master = 50 }
	  local act_rank = ranks.get_obj_rank_name(actor)
	  item_in_slot:set_condition(item_condition + (math.random(20) + cond_standard[act_rank])/100)
	  this.repair_wpn_sound()
	  alife():release(se_item, true)
	  return --/> выход, ремонт завершен
    end
  end
   end
 end
end

 

[serega-gamer 0]

Всем большое спасибо! А по поводу перестраховки (проверки на наличие чего либо в слоте), она у меня есть, только в интерфейсе, по непонятной причине не хотела работать в этой функции.

[Viнt@rь 50]

Можно ли скриптом привязать партикл к модельке нпс(к ее какой то кости)?

 

Во-первых, вопрос не в тему.

Во-вторых, пиши с большой буквы.

В-третьих, электрохимера АМК.

ColR_iT

 

 

Прошу, прощения =)

 

Переформулирую вопросик так сказать "нормально" а не абы как...

 

Можно ли "прицепить" партикл к определенной кости модели, к примеру - нпс? и если да, то каким образом? Скажу даже для чего, для идеи с "паром изо рта нпс"

И сразу встречный вопрос, в последствии вот такого действия, не повлияет ли это на производительность?

 

ЗЫ

ColR_iT, ок гляну, чет забыл за химеру

Изменено 13 Октября 2012 пользователем Viнt@rь

[Artos 99]

Упрощенный алгоритм выбора "Куда задавать вопрос?":

1. Поисковиком или иначе ищем - а не задавался ли подобный вопрос и не давался ли уже ответ(ы).

2. Читаем шапки топиков и по рекомендованным ссылкам просматриваем ФАКи, статьи и т.п.

3. Если вопрос по наличию или использованию функций/методов -> "Справочник по функциям и классам" + lua_help.script

4. Если вопрос по типичным функциям Lua -> "Язык Lua. Общие вопросы программирования"

5. Если вопрос типа "а как сделать/что означает/...?" -> "Ковырялка" соответствующей версии игры ТЧ/ЧН/ЗП

6. Если вопрос по конкретным игровым скриптам,алгоритмам или их заготовкам,черновикам, проблемам скриптов - этот топик.

... по тектурам, моделям, перл-скриптам, SDK и т.д. -> тематические топики.

 

Примечание: Адресные или личные вопросы (к конкретным адресатам) и "спасибки" -> ЛС

 

P.S. Как правило, если не знаешь куда задать вопрос, и тем более не можешь сформулировать, - лучше вообще никуда и ничего не задавать, а постараться задействовать свою "думалку"... или заняться другими делами.

ИМХО

Изменено 13 Октября 2012 пользователем Artos

[Daemonion 0]

Извините за мой плохой русский, я носителем английского языка ...

 

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

 

Как правило, игровой движок должен принимать моно файлы с при креплениями "_l" и "_r" и применять их для правого и левого каналов, чтобы получит стероеэффект.

 

Мои тесты показали, неоднократно, что движок не способен сделать это. Он просто не работает.

 

Я попытался изменить функцию "function action_sound2d:get_source_positions()" в "sr_sound2d.script", но ничего не изменилось. Я даже написал новую функцию, чтобы повернуть звуки на разные оси ( X, Y, Z).

 

У меня кончились идеи, может ли кто то помочь? Я хотел бы получить стерео аудио работающую в STALKER.

[Artos 99]

Daemonion, сам движек ТЧ конечно не отыграет тебе стерео-звук, однако с помощью скриптов вполне можно отыгрывать "левый" (_l) и "правый" (_r) звуковые файлы с достаточного для псевдо-стерео звучания.

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

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

Изменено 15 Октября 2012 пользователем Artos

[xxx5 1]

Добрый вечер, что не так в этом скрипте:

 

function soul_have(first_speaker, second_speaker)

local item_sections = {"af_soul"}

local needed = 2

local count = 0

local item_section

local function calc(temp, item)

if item:section() == item_section then

count = count + 1

end

end

for k,v in pairs(item_sections) do

item_section = v

get_story_object("actor"):iterate_inventory(calc, actor)

end

return count >= needed

end

 

 

А то вылетело с таким логом:

 

Expression : fatal error

Function : CScriptEngine::lua_error

File : E:\priquel\sources\engine\xrServerEntities\script_engine.cpp

Line : 180

Description :

Arguments : LUA error: .... - Чистое Небо\gamedata\scripts\trade_dialog.script:13: attempt to call global 'get_story_object' (a nil value)

 

 

[Artos 99]

xxx5,

1. Читаем в шапке:

6. ПОЖАЛУЙСТА! Указывайте, для какой игры Вам необходима информация (ТЧ, ЧН, ЗП), если стоит мод - укажите название мода;

2. Глобальный (да и вообще) метод 'get_story_object' имеется только в ЗП.

3. И зачем так извращаться, когда всего-то требуется пройтись по инвентарю гейм-объекта актора?

db.actor:iterate_inventory(calc, actor)

... или это желание все сделать не так как уже сделано?

 

P.S. "Спасибки" - > в ЛС, и оправдываться в топике не стОит..., т.е. не захламляем топик.

Желание "изобрести велосипет" может быть и не глупость, но... целесообразность затрат времени и сил - под сильным вопросом.

Изменено 15 Октября 2012 пользователем Artos

[Malandrinus 615]

Daemonion,

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

 

Как правило, игровой движок должен принимать моно файлы с при креплениями "_l" и "_r" и применять их для правого и левого каналов, чтобы получит стероеэффект.

 

Мои тесты показали, неоднократно, что движок не способен сделать это.

 

Первое. Движок на самом деле не может играть стереозвук по-настоящему. Файлы с именами "_l" и "_r" читаются только в отдельных случаях: музыка в меню, саундтрек уровня, видеоролики. Однако, даже в этом случае движок лишь имитирует стерео, играя звук из точек слева и справа от актора. Таким образом, каналы в любом случае смешиваются. Это можно заметить, если сделать каналы существенно различными, к примеру взять для музыки меню две совершенно разные мелодии.

 

Второе. Чтобы звуковая схема в sr_sound2d.script играла стереозвук надо в секции логики для этой схемы поставить параметр stereo = 1. Тогда только и будут читаться файлы обоих каналов.

 

Третье. Звуковая схема в sr_sound2d.script пытается имитировать стереозвук таким же образом, как это делается для музыки в главном меню и видеороликов, но почему-то делает это не совсем так, возможно просто ошибочно. Для проигрывания стереозвука там делается так:

 

self.snd_obj_l:play_at_pos (actor, pos_l, d / 1000.0, sound_object.s3d)

self.snd_obj_r:play_at_pos (actor, pos_r, d / 1000.0, sound_object.s3d)

В то время как сам движок использует sound_object.s2d

 

В итоге оба канала практически неразличимо смешиваются. Чтобы имитировать движковое поведение более точно и уменьшить смешивание надо сделать следующее:

1. Эти две строки в функции action_sound2d:play_sounds заменить на

self.snd_obj_l:play_at_pos (actor, vector():set(-0.5,0.0,0.3), d / 1000.0, sound_object.s2d)

self.snd_obj_r:play_at_pos (actor, vector():set( 0.5,0.0,0.3), d / 1000.0, sound_object.s2d)

 

2. В функции action_sound2d:update убрать фрагмент

if self.st.stereo == true then
 ....
end

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

 

После этих изменений и добавления параметра stereo = 1 звук будет играться практически также, как в главном меню. Как я говорил, определённое смешивание каналов будет присутствовать всё равно.

 

First, the engine can't really play stereo. It automatically reads separate channels in "_l" and "_r" files only for the main menu music, level soundtrack, and videotutorials. Even in this case stereo is just an imitation. The engine plays two sounds from points to the left and to the right from the actor, so two sounds are somehow mixed. You can notice that if you will take for two channels two completely differents tunes.

 

Second. To make the scheme from sr_sound2d.script play stereo, one needs to add stereo = 1 parameter into the logic section for this scheme.

 

Third, the scheme from sr_sound2d.script tryes to imitate playing stereo the same way as the engine does, but with a little difference (and maybe just incorrectly). It plays two channels using this syntaxis:

 

self.snd_obj_l:play_at_pos (actor, pos_l, d / 1000.0, sound_object.s3d)

self.snd_obj_r:play_at_pos (actor, pos_r, d / 1000.0, sound_object.s3d)

 

But the engine internally uses the constant value equivalent to the sound_object.s2d

 

As a result, both channels are mixed almost completely. So, to imitate, what engine does in the main menu, one needs to do the following:

 

1. Replace these two lines in the function action_sound2d:play_sounds with

 

self.snd_obj_l:play_at_pos (actor, vector():set(-0.5,0.0,0.3), d / 1000.0, sound_object.s2d)

self.snd_obj_r:play_at_pos (actor, vector():set( 0.5,0.0,0.3), d / 1000.0, sound_object.s2d)

 

That will make mixing less noticable

 

2. In the function action_sound2d:update remove or comment out the fragment

if self.st.stereo == true then
 ....
end

 

If not do so, sound will stop shortly after beginning.

 

After that (and don't forget about stereo = 1 in a logic section) stereo will play the same way as it plays in the main menu. Again, there will be some channels mixing anyway.

 

 

[Daemonion 0]

I will PM you. Nevermind, your PM does not work.

 

Для тех, кто говорит на английском языке:

Malandrinus,

 

 

You speak English? Ура! Let me explain what I am trying to do with stereo sound in STALKER.

 

I am a sound designer. I am making space restrictors in each building to play stereo sounds to make realistic audio.

. Here is the audio I made. I make unique, stereo audio for each building type - house, bunker, tunnel, barn, etc.

 

 

As you know, STALKER only accepts mono files (_l and _r). This is ok, because I can split a stereo file into left and right channels. But the code to combine _l and _r does not work in game!

 

Here is my code for a space restrictor. This code will play sr_sound_act@in_house when the actor walks inside. If it is raining, it will play sr_sound_act@in_house_its_raining. When the player walks outside the restrictor, it will play sr_sound_act@outdoor_night, outdoor_day or raining_outside. These all must be combined stereo _l and _r files to sound best. However, it will only play mono.

 

Here is my sr_sound2d.script file. I made the changes you suggested:

self.snd_obj_l:play_at_pos (actor, vector():set(-0.5,0.0,0.3), d / 1000.0, sound_object.s2d)
self.snd_obj_r:play_at_pos (actor, vector():set( 0.5,0.0,0.3), d / 1000.0, sound_object.s2d)

but I get error.

 

However, I do not know where to add "one needs to add stereo = 1 parameter into the logic section for this scheme" in the file. Could you please help! I have been trying for six months to make this stereo audio work! Thank you so much for you help!

 

Изменено 16 Октября 2012 пользователем Daemonion

[Artos 99]

Daemonion, в своем ответе-рекомендации malandrinus допустил оговорку с параметром stereo = 1.

Этот параметр читается скриптом схемы как булево(логическое) значение (utils.cfg_get_bool) и при чтении числа происходит ошибка, т.к. ожидаются строки с false/true.

Если требуется в схеме sr_sound_act включить псевдо-стерео, необходимо в секции логики задавать параметр так: stereo = true

Изменено 16 Октября 2012 пользователем Artos

[Malandrinus 615]

Artos, при чтении параметра функцией r_bool, true вернётся при любом значении из набора: "true", "yes", "on", "1". Соответственно, false при всех остальных значениях.