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

[Struck 61]

Хотя пожалуй мой вопрос не снимается .

Мне нужно отследить факт того что объект мы подняли с земли.

Делаю вот так:

 

local sobj = alife():object(obj:id())
if sobj and sobj.parent_id and sobj.parent_id == 65535 then
sendtip("подобрали")
end

 

Типс вообще не вылетает, какой тогда parent у объекта лежащего на земле?(parent_id всегда возвращает "0", parent() - "userdata")

Изменено 18 Сентября 2012 пользователем Struck

[Artos 99]

Struck, убедительная просьба прекратить "ковыряние в детской песочнице аля СП".

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

 

 

Struck: Как получить факт того, что объект был поднят с земли?

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

 

По сути:

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

Во-вторых, у нормальных модмейкеров бесхозные предметы имеют (как правило) именно parent_id == 65535, а не '0', и метод parent() возвращает 'nil'.

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

В-третьих, не путай понятия для серверного объекта и клиентского. В переходные моменты вполне допустимы ситуации, когда parent_id ~= 65535 для серверного, но клиентский уже не имеет владельца, и наоборот.

Ну и последнее, к сожалению не всегда предмет "валяющийся на земле", т.е. вроде как бесхозный, не имеет владельца. Для некоторых ситуаций предмет сам себе владелец (parent_id == item_id), или имеет parent_id последнего владельца. А порой даже имеет в качестве parent() того, кто только еще "собрался брать" предмет...

Изменено 18 Сентября 2012 пользователем Artos

[Struck 61]

Artos,

Поэтому потрудить привести коды, из которых будет видно, что же ты такое у себя вытворяешь

 

Я привел тот код, который я вставляю напрямую в коллбек на обретение предмета, сторонних махинаций я(пока) не делаю. Выдает он мне то, что я написал. Что еще нужно для прояснения ситуации?

 

давай оперировать понятием "безхозный", т.е. не имеющий владельца.

Согласен.

[Artos 99]

Struck, вот это, не указанное тобою в вопросе: "код,который я вставляю напрямую в коллбек на обретение предмета" и является необходимым пояснением, которое и проясняет причину ерунды твоих результатов.

Неужели до тебя самого не доходит, что в коллбэке на взятие актором предмета (callback.on_item_take) - предмет УЖЕ принадлежит актору (взят, а не валяется "на земле"). Глупо проверять безхозность тогда, когда хозяин уже в наличии.

[Struck 61]

Artos, и как же быть? Я просто пока не представляю как свзяать 'бесхозный' предмет и инвентарь нпс/актора.

[Artos 99]

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

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

Хочешь проверить бесхозен ли предмет? Ну так что мешает это сделать, ведь это же простейщее действие. Но глупо это делать там/тогда, где это не имеет никакого смысла, т.е. когда у предмета заведомо есть владелец.

Способов проверки и тем более реализации, великое множество, но все зависит от исходных данных и от цели, для чего все это делается.

Не знаешь как, начни с самого простого: итерацией по всем объектам (их ID) в Зоне, и определяй бесхозный предмет иль нет.

Захотелось "взять" предмет - ну так в модах предостаточно и примеров, да и в каждой ситуации для НПС или вктора реализации различаются. На "едино и простенько" не надейся. ;-)

Изменено 18 Сентября 2012 пользователем Artos

[Zander_driver 10 331]

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

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

В дебаг-логе сохранялось вот это:

[22:39:01] 001B:006DBD38 xrLUA_GSC.dll, lua_yield()
[22:39:01] 001B:006DBEF6 xrLUA_GSC.dll, lua_yield()
[22:39:01] 001B:006D2367 xrLUA_GSC.dll, lua_gc()
[22:39:01] 001B:0046ACAC XR_3DA.exe, CRenderDevice::End()

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

И, вопрос к тем кто это использует. Сталкивался ли кто-нибудь, какие меры можно предпринять? Кроме очевидного "Не использовать лог-файл как вьючную лошадь" - иногда все таки необходимо его использовать именно так...

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

Игра - ТЧ 1,0004, не амк...

Изменено 18 Сентября 2012 пользователем Zander_driver

[Struck 61]

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

 

Захотелось "взять" предмет

Можно поподробнее?

Допустим я начинаю вот так:

 

for i=1,65535 do
local obj = alife():object(i)
if obj and obj.online and obj.parent_id and obj.parent_id == 65535 then
--/ сюда что?
end
end

Изменено 18 Сентября 2012 пользователем Struck

[Malandrinus 615]

Struck,

Мне нужно отследить факт того что объект мы подняли с земли.

Не думаю, что есть простое решение. К моменту колбека на передачу потеряна уже вся информация о предыдущем владельце, причём и на серверной и на клиентской стороне. Напрашиваются всякие мерзкие варианты со слежением за владельцем для всех объектов. Для этого надо с начала загрузки сейва следить за всеми событиями передачи, тогда можно сказать точно, у кого был объект. В общем-то это реализуемо, видел подобное в пределах инвентаря, когда надо было определять, где был объект: в слоте, рюкзаке, на поясе. Однако, при такой реализации будут и проблемы, к примеру с ящиками, для которых нет колбека на получение предмета. Придётся также следить за потерей предметов. Но как тогда быть со спавном прямо в ящики? В общем морока ещё та.

 

 

Zander_driver,

Использую данный дебаг-модуль в разработке своего мода. ...

периодически стали происходить вылеты при синхронизации.

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

get_console():execute("clear_log")

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

[Artos 99]

Как же тяжко тащить из болота бегемота

Struck, 'факт' - в нашем контексте - это событие, а про него можно только узнать, а не взять иль получить.

К твоему сведению, практически невозможно "взять" НЕбесхозный предмет, т.к. даже при передаче от одного к другому иль взятии из ящика - предмет на период в пару апдейтов становится бесхозным и т.о. актор иль НПС всегда обретают именно бесхозные предметы. В итоге, тот же коллбэк callback.on_item_take собственно и дает информаци ю о свершившемся "факте" получения предмета, а уж был он до этого бесхозным иль нет - извини, но движек игры и штатные скрипты об этом не ведают, т.к. подобное не запоминается.

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

sv !ownership (entity already has parent) new_parent [0][actor:single_player] id_parent [0][actor:single_player] id_entity [18953][myitem:myitem18953] [3664]

- но это уже из области багов движка.

 

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

Какова конечная цель твоих попыток "получить факт" взятия бесхозного предмета? Это же не самоцель!

Коллбэки на взятие предметов есть готовые, о бесхозности уже дано пояснение, чего же тебе требуется?

Определять перед взятием бесхозность предмета? Ну так получив нужный идентификатор и проверяй именно перед взятием.

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

 

Zander_driver, собственно некорректно называть модулем динамическую библиотеку ... те, кто не в курсе запутаются.

Судя по названию в строке лога "xrLUA_GSC.dll" - ты говоришь о модифицированной библиотеке на базе правок проекта "xrLuaFix by RvP".

Наверное мне более всех знакома именно эта тема, т.к. и развиваю ее и использую "на всю катушку" ;-)

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

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

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

Так же советую в логе отследить - а вообще сколько доступно памяти и не зашкаливают ли загруженные ресурсы твоего мода за предел доступного?

Изменено 18 Сентября 2012 пользователем Artos

[Struck 61]

Artos, у меня есть определенные предметы, ГГ бегает их и собирает, и как только он подбирает этот бесхозный(!) предмет происходит событие(единожды(!)(т.е. если мы выкинули этот предмет и подобрали опять(одругими словами - предмет побывал в инвентаре актора/нпс), то событие уже НЕпроисходит)), мне нужно запомнить id() в табличку(разумеется ее сохранив в псторе допустим) и вроде все просто, но ругается он у меня на строку с table.insert, когда я добавляю id предмета в свою табличку. Получаю id пердмета опять таки в коллбеке на обретение.

Добавляю разумеется как то так:

local id = obj:id()
table.insert(tbl,id)

Изменено 18 Сентября 2012 пользователем Struck

[Malandrinus 615]

Artos,

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

Это не так. Процесс смены владельца является мгновенным, если рассматривать его по отдельности для клиентской или серверной стороны. Т.е. к примеру после выполнения функции transfer_item на серверной стороне владелец уже сменился. Другое дело, что в течении упомянутых нескольких апдейтов имеется рассинхронизация с владельцем на клиентской стороне. Тем не менее, бесхозным предмет не становится ни на сервере, ни на клиентской стороне. К моменту получения колбека на передачу этой рассинхронизации уже нет.

[Artos 99]

malandrinus, согласен не совсем удачно выразился,

Подразумевал конечно то, что нельзя в некоторых ситуациях (взятие/передача/...) однозначно говорить о владельце предмета или его отсутствии только по одному из свойств parent_id или parent() -> parent():id(), которые рассинхронизированы.

В итоге или предмет безхозен перед взятием или его "владелец" пока еще неясен, т.е. зависит от типа объекта (серверный или клиентский).

 

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

Если же ты описываешь "что хотешь получить" - тогда становится понятнее для чего тебе 'безхозность' была нужна...

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

Замечу, что не стОит просто сыпать в свою табличку каждый раз идентификаторы предметов, как раз при повторном взятии в табличке будут дубли. Да и пользоваться такой табличкой несподручно... Может tbl[id] = true - будет удобнее? ;-)

И почему бы тебе в конце концов не воспользоваться советом и не посмотреть как это УЖЕ сделано?! и уже тогда изобретать велосипед и наступать на грабли, по которым уже кто-то до тебя прошелся. В том же Симбионе актор собирает КПК и их иды запоминаются - вот и взгляни. Заодно там и чистка таблицы и прочее. Запоминать же в pstor - ой как не советую...

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

Изменено 18 Сентября 2012 пользователем Artos

[Zander_driver 10 331]

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

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

Так же советую в логе отследить - а вообще сколько доступно памяти и не зашкаливают ли загруженные ресурсы твоего мода за предел доступного?

В том то и дело что правками движка я (пока) не занимался вообще. А по скриптам... дело в том что одни и те же "новые" скрипты, на одной машине прекрасно работают не вызывая никаких сбоев, на другом же компе - 100% происходит вылет. Заполнение памяти - до предела еще далеко.

[Artos 99]

Zander_driver, к сожалению пока информации слишком мало и скорее на кофейной гуще гадаем.

Если уж пишешь про "модуль RvP", то на компе где "100% происходит вылет", без этого модуля (библиотеки) ошибка все равно проявляется?

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

Изменено 19 Сентября 2012 пользователем Artos

[Struck 61]

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

 

Только осталось одно но(!), как сделать еще запоминание того, что предмет побывал и у непися в инвентаре? Т.к. когда я беру из рюкзака непися предмет у меня тоже происходит мое событие. Зарегестрировать оn_item_take в xr_motivator.script и вызывать там? Или только более геморройный вариант годится?(Типа перебирать инвентарь юзаемого трупа, если в нем есть мои предметы то заносить их в таблицу "побывавших в рюкзаке").

 

Типа как-то так:

function use(npc)
for i=0,npc:object_count()-1 do
local obj = npc:object(i)
local id = obj:id()
if npc:object(obj:section()) then
if founded_items[id] == nil then
if isMyItems(obj) then
founded_items[id] = true
end
else
if not isMyItems(obj) then
founded_items[id] = nil
end
end
end
end
end

 

Изменено 19 Сентября 2012 пользователем Struck

[Shredder 49]

direction - для серверного объекта можно прочитать только из его нет-пакета ('abstract'-параметры) или имея расширенный движек...

На всякий случай сообщаю, что в ЗП у серверного объекта есть свойство angle, которое как-раз и является тем самым direction. Это свойство к тому же доступно и на запись.

[Struck 61]

Предыдущий вопрос неактуален, все сделал!

 

Как можно проверить какая фраза была выбрана в скриптовом диалоге(без использования инфопоршней/функций)?

 

Обрисую что хочу в конечном итоге:

 

Мне выпадает три фразы для ответа:

Фраза 1
Фраза 2
Фраза 3

 

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

 

Постараюсь сейчас обрисовать свой диалог:

Фраза 1 => Сообщение с talk_message(1) => Фраза 4 Фраза 5 Фраза 6
Фраза 2 => Сообщение с talk_message(2) => Фраза 4 Фраза 5 Фраза 6
Фраза 3 => Сообщение с talk_message(3) => Фраза 4 Фраза 5 Фраза 6

У 4,5 и 6 фраз название одинаковое, но действия разнятся в зависимости от выбранного сообщения с talk_message.

Изменено 19 Сентября 2012 пользователем Struck

[Artos 99]

Struck, Каждая строка-фраза при клике по ней вызывает соответствующую ветку диалога, передавая на вход аргументы: oSpeaker1, oSpeaker2, sDlgId, [idParent,] idPhase. 3-ий аргумент - текстовый идентификатор (название) выбранной фразы, последний - собственно числовой идентификатор фразы.

Возьми мод "Arena_Extension_Mod" (by kstn, IG-2007) и поизучай как там сделаны ветвления диалогов. Тебе придется очень тяжко, т.к. тема скриптовых диалонов очень не проста для понимания и реализации.

Также могу посоветовать посмотреть, например, как реализован скриптовой диалог обмена артефактов в dialogs_add.script (SIMBION-mod). В нем достаточно комментариев для самостоятельного разбора...

[Struck 61]

Такой вопрос, вывожу статик в инвентарь, который по мере игры обновляется, все вроде хорошо, бегаем - собираем итемы, он обновляется, но(!) после save/load статик старый остается, причем сбрасывается параметр cnt на 0(изначально у меня local cnt = 0), а поверх него появляется новый(накладывается) и отсчет идет уже в наложенном статике, ввиду чего получается невозможно прочесть написанное.

 

local wnd = nil
local ca, cr, cg, cb = 255, 231, 153, 22

function show(cnt)
if wnd == nil then return end
wnd:SetText("Кол-во: "..cnt)
end

function init()
if wnd then return end
local inventory_wnd = level.main_input_receiver()
wnd = CUIStatic()
wnd:SetAutoDelete(true)
wnd:SetWndRect(190, 730, 108, 33)
wnd:SetText("Кол-во: ")
wnd:SetFont(GetFontGraffiti22Russian())
wnd:SetTextColor(ca,cr,cg,cb)
inventory_wnd:AttachChild(wnd)
end

 

 

Вызываю следующим образом, при переборе инвентаря методом iterate_inventory пишу show(cnt), в info_callback'e вызываю функцию init().

 

P.S. Смотрел m_backpack.script в SIMBION'e, но...мало что понял, хотя там вроде бы есть что мне нужно.