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

[WinCap 316]

1 час назад, mdm64 сказал:

изменение хода времени во время диалогов, всё прекрасно работает.

Расскажи, пожалуйста, что и как сделал?

[mdm64 579]

@WinCap, https://www.amk-team.ru/forum/topic/6185-skriptovanie/?do=findComment&comment=1345137

[_Sk8_AsTeR_ 117]

Господа, а как можно воскресить НПС в огср х64? 

А конкретно - Кузнецова (как узнать его ид?)

[AndreySol 215]

10 часов назад, _Sk8_AsTeR_ сказал:

Кузнецова (как узнать его ид?)

Зачем Id? Для спавна нужна секция конфига или номер секции из алл.спавн.

[_Sk8_AsTeR_ 117]

@AndreySol, А, то есть просто его заново заспавнить... А все инфопоршни его касаемые, они останутся актуальными? 

Например пару квестов с ним было выполнено, были выданы соответствующие инфопоршни о их завершении, всё останется актуальным?

[AndreySol 215]

Инфо-порции останутся, просто заспавни этого Кузнецова в нужное место.

[_Sk8_AsTeR_ 117]

@AndreySol, Окей, повелитель зоны придется расчехлять похоже)

[mdm64 579]

Доброго времени!

Платформа ЗП

Через некоторое время после начала игры (новая или сохранение - несущественно) происходит вылет с таким логом:

Скрытый текст

FATAL ERROR
 
[error]Expression    : !m_error_code
[error]Function      : raii_guard::~raii_guard
[error]File          : ..\xrServerEntities\script_storage.cpp
[error]Line          : 748
[error]Description   : error in error handling
 

stack trace:

0023:006C75D1 xrCore.dll, xrDebug::fail()
0023:0714660E xrGame.dll, CDialogHolder::IgnorePause()
0023:07012CBC xrGame.dll, CDialogHolder::operator=()
0023:03E6B1B1 lua.JIT.1.1.4.dll, lua_getinfo()
0023:03E6B530 lua.JIT.1.1.4.dll, lua_getinfo()
0023:03E62092 lua.JIT.1.1.4.dll, lua_call()

Вопрос - где искать косяк или хотя бы примерное направление поисков ошибки?

[AndreySol 215]

16.09.2020 в 19:47, mdm64 сказал:

хотя бы примерное направление

В скриптах.

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

[mdm64 579]

@AndreySol, Да исходники-то есть, но я не понял, где искать эту 748 строку. Судя по этому сообщению error in error handling - ошибка в отладчике ошибок, если не ошибаюсь.

[WinCap 316]

5 часов назад, mdm64 сказал:

я не понял, где искать эту 748 строку

Не трать время зря, ничего полезного там нет.

 

"Error in error handling" - Lua не смог корректно обработать ошибку.

Найти причину очень сложно. Вспоминай всё, что менял в последнее время.

В первую очередь проверяй все скрипты, которые правил, и не только корректность синтаксиса, но и правильность написания имен переменных и функций (хорошо помогает подсветка совпадающих слов в Notepad++).

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

[mole venomous 3 433]

Добренько вам. Есть ли возможность поставить в исключения для схемы выброса непися, находящегося в конкретном гулаге под конкретной работой. Или всех НПС под этим гулагом, независимо от "рода деятельности" (в основе ТЧ 1.0006 + АМК 1.41) .

Изменено 20 Сентября 2020 пользователем mole venomous

[phalcor 60]

Если неписю продать штук 10-20 разных стволов, он какое-то время будет их носить в инвентаре, но затем большинство из них в одну секунду пропадут, останется только самое мощное (по его мнению).

Вопрос - как можно  управлять этим процессом? (например, запретить такое вот исчезновение оружия из инвентаря непися). За это отвечает какой-то скрипт или что-то еще?

[phalcor 60]

15 часов назад, phalcor сказал:

За это отвечает какой-то скрипт или что-то еще?

Таки нашёл сам. Предметы из инвентаря неписей исчезают благодаря функции first_update(npc) в скрипте trade.script. (Это справедливо для ОП 2.1). Может кому-то будет полезна эта информация 

[_Sk8_AsTeR_ 117]

Доброго времени! Возможно ли в Нет-пакет НПС добавить какие-то свои данные? В качестве теста - новую переменную, которая будет в себе хранить просто какое-нибудь число. Как это реализовать? Чтение нетпакета:

Скрытый текст

local pk = get_netpk(npc) --
if pk and pk:isOk() then
	local data = pk:get()
  	--КАКАЯ-ТО ФУНКЦИЯ, работаем с нет-пакетом
  	pk:set(data)

 

 

Изменено 23 Сентября 2020 пользователем _Sk8_AsTeR_

[Kirgudu 1 217]

@_Sk8_AsTeR_, судя по коду, речь о модуле Артоса?
Можно, только не в стандартные свойства нет-пакета для данного объекта, а в его кастом дату. Например, при взятии артефакта в инвентарь я успешно добавлял признак того, что артефакт уже был найден (для исключения повторного учёта в статистике):

Скрытый текст

function on_artefact_take(obj)
	local s_obj = alife():object(obj:id())
	if s_obj then
		local pk = get_netpk(s_obj, 1)
		if pk:isOk() then
			local data = pk:get()
			local tbl = data.custom_data:getTable()
			if not tbl.artefact_found then
				xr_statistic.inc_founded_arts_counter()
				tbl.artefact_found = {}
				data.custom_data:setTable(tbl)
				pk:set(data)
			end
		end
	end
end

 

Для понимания: в данном случае присвоенная свойству artefact_found пустая таблица превращается в кастом дате, представленной строкой, в секцию [artefact_found] без дочерних элементов.

[_Sk8_AsTeR_ 117]

@Kirgudu, интересно. А после проделанных манипуляций сейвы теоретически могут каким-либо образом убиться? 

[Kirgudu 1 217]

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

[Zander_driver 10 334]

1 час назад, _Sk8_AsTeR_ сказал:

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

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

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

1 час назад, Kirgudu сказал:

чтобы не "убились", и надо задействовать кастом дату.

Это не панацея в любом случае. Т.к. кастом-дата - неотъемлемая часть нетпакета, а сам нетпакет не резиновый.

Если в модуле Артоса есть проверка, запрещающая запись в пакет лишних данных - значит, когда мы попытаемся записать слишком много, часть данных не запишется.

Если такой проверки внутри модуля нет, и мы не проверив, запишем больше разрешенного объема, то получим битый сейв. Т.е. и так и эдак, следить за объемом своих данных, надо самому, а не полагаться на то, что Артос "все предусмотрел". Тут нельзя избавить конечного пользователя от заботы об объеме данных. Получится выбор между потерей данных во имя стабильности, либо битьем сейвов во имя сохранения всего и вся.
Как вариант для записи больших данных - se_stor того же Артоса. Там данные распределяются по нетпакетам многих объектов, а не одного, и благодаря этому хранить можно теоретически сколько угодно. Только следить за тем, чтобы не было монолитных неделимых строк размером больше разрешенной длины нетпакета. Если такие запихивать на запись, то даже se_stor будет бить сейвы. Проверено на личном опыте...

Скрытый текст

 

 

[Kirgudu 1 217]

@Zander_driver, я имел в виду несколько другое. Если выбирать между записью в кастом дату и в отдельное свойство всего нет-пакета [ local data = pk:get()    data.my_prop = 1    pk:set(data) ] - однозначно следует предпочесть кастом дату, поскольку добавление отдельного свойства может поломать весь нет-пакет, обладающий определённой структурой для каждого типа объекта (хотя не исключено, что модуль просто проигнорирует добавленные свойства, не характерные для нет-пакета - это я не проверял).

Ну а то, что мы не можем превышать определённую длину, обсуждалось уже много раз. Впрочем, согласен, упомянуть об этом стоило. 

Изменено 23 Сентября 2020 пользователем Kirgudu