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

[Svoboда 3]

Тема для обсуждения скриптов всего и всех в серии игр STALKER.

Задавая вопрос (!):
1. Внимательно изучите суть вопроса. Вопрос должен соответствовать выбранной Вами темы. Это поможет сохранить порядок и читабельность темы, а также облегчит поиск и понимание сего;
2. Изучите то, что уже есть в теме (пролистайте "руками", воспользуйтесь поиском на форуме);
3. Изучите информацию которая может вам помочь:

 

 

Stalkerin. Там есть много хороших статей касательно данной темы.
Уроки по модостроению. Есть рабочие примеры готовых скриптов различного назначения.

 

Справочное руководство по языку Lua 5.1
https://www.mediawiki.org/wiki/Extension:Scribunto/Lua_reference_manual/ru
Справочник по функциям и классам. Собрано много информации по функциям и классам, не всем, но по основные сведения предоставлены.

 

Логика со вступлением и четырьмя частями:

 

Вступление
Часть первая
Часть вторая
Часть третья
Часть четвертая.

Smart_terrain (в простонароде - гулаг)
Интересный способ настроики логики для гулагов
Скриптовая часть игровой логики

4. Дабы не превращать обсуждение в "кашу" разной информативной направленности, задавайте несколько вопросов по порядку (в разных постах) после того, как получите ответ на предыдущий вопрос;
5. "Спасибо" и тому подобное - будьте так любезны в ПМ. Если не любите писать в ПМ, в конце вопроса напишите фразу: "Заранее спасибо!" - или что-то в этом духе;
6. ПОЖАЛУЙСТА! Указывайте, для какой игры Вам необходима информация (ТЧ, ЧН, ЗП), если стоит мод - укажите название мода;
7. Если Вы что-то сделали и результат не такой, какой Вами задумывался, то, пожалуйста, приводите коды которые Вы изменяли/писали целиком! Это поможет другим правильно ответить на Ваш вопрос, а также оградит Вас от лишней писанины.
8. Оформляйте сообщение. Пользуйтесь тегами для того, чтобы отделить код от текста. Пишите грамотно - ПОЛЬЗУЙТЕСЬ ЗНАКАМИ ПРЕПИНАНИЯ.
9. И помните: «Правильно заданный вопрос – половина ответа».

 

Какие вопросы следует задавать, а какие нет...

 

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

 

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

И последнее: очень рекомендовано к прочтению Правила форума
 

---

[Artos 99]

*Shoker*

Встроенная 'logf', как и аналогичные log1 (из x-Ray Extensions) и log123, которые также скриптом (lua_fix) могут быть задействованы, - чисто трансляторы полученной строки в штатный лог-файл и никак не расцвечивают строки.

Цвет текста в консоли целиком зависит от первых символов самой строки (префикса), а движек по этому символу уже расцвечивает ее.

Т.о. учитывая, что при использовании безконсольного вывода в лог (т.е. не консольными командами), можно вместо префикса 'load ~:'|'* Info' и т.п. формировать строки по своей потребности и начальными символами (*.!.~ ...) расцвечивать.

Однако данная версия все же подразумевает и отсутвие расширяющих dll-ек и тогда без "безопасного" префикса ('load ~:') коды вывода в лог станут фатальными ... (в ЧН/ЗП).

ИМХО, рюшечки все же менее важны, чем надежность и информативность.

 

Под трассировкой подразумевается то, что выдает debug.traceback, т.е. именно трассировку вызовов той функции, которая вызвала функцию abort и можно не только прочесть про ошибку, но и узнать откуда "ноги растут".

Вообще хотел добавить и вот это:

--/ выводит в лог стэк вызова функций (если доступен debug).
_G.callstack = function(fmt,is_abort)
  if is_abort == true then
    if type(error_log) == 'function' then --/ for CS|CoP
      log = error_log
      fmt = tostring(fmt)
    else
      fmt = "! [LUA][ERROR] "..tostring(fmt)
    end
  else
    fmt = "* DBG:"..tostring(fmt)
  end
  if debug then
    log(debug.traceback(fmt,2))
  else
    log(fmt)
  end
end

- но ... передумал. В ЗП это есть и c включенным дебагом можно не только при abort'ах просматривать стеки вызовов, но ... бездумное злоупотребление по неопытности может принести больше вреда.

Если тебе потребно - просто добавь 'это' или посмотри как в ЗП.

 

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

RvP, просто в доступе модмейкерам скомпилированной dll-ки для ЧН/ЗП не было.

Так же, пока нет версий для ЧН/ЗП с дублированным выводом во второй (дебаг) лог-файл. Хотя в данной версии вывод в доп.лог не полный (вместо SetLogCB использован то же Log), но и это уже подспорье при "безлоговых" вылетах.

Изменено 1 Марта 2012 пользователем Artos

[RvP 1]

Artos,

RvP, просто в доступе модмейкерам скомпилированной dll-ки для ЧН/ЗП не было.

да ладно

Изменено 11 Марта 2012 пользователем ColR_iT

[Artos 99]

RvP, предлагаю не пустословить, тем более собственно и ни о чем.

Если кроме "

Да ладно", смайликов и упоминаний о некоей мифической "универсальной/совместимой" DLL-ке для всех игр (ТЧ/ЧН/ЗП или хотя бы для последних) у тебя есть чем поделиться с комьюнити - что мешало или мешает это сделать?

И давай не будем эту тему продолжать, т.к. тебе прекрасно известно, что ни до, ни сейчас ни в ближайшее время такой DLL-ки нет и не будет, т.к. как минимум функции вывода в лог (Log и SetLogCB) находятся в xrCore.dll, которая у каждой игры своя ...

Т.о. требуется и корректно определять версию игры (или xrCore) на старте и портировать все три библиотеки, да еще и преодолеть различную подгрузку "универсальной" библиотеки для xrLua в ТЧ и lua.JIT.1.1.4 в ЧН/ЗП.

 

Изменено 11 Марта 2012 пользователем ColR_iT

[Unnamed Black Wolf 5]

Artos,

Она не универсальна.. Просто, существуют версии для ЧН/ЗП, длл которые имеют log1, и не только.

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

на счет цветов..

## (две решётки) непонятно-синеватый (цвет здесь показан точный #0E8C82)

~~ (две тильды) чисто жёлтый (#FFFF00)

** (два умножения) серый (#808080)

!! (два восклицательных знака) красный (#FF0000)

-- (два минуса) зелёный (#00FF00)

Изменено 1 Марта 2012 пользователем Unnamed Black Wolf

[Artos 99]

Unnamed Black Wolf

Ну зачем оспаривать или подтверждать то, что и так почти всем известно(?) и адресовать пост мне, кто и говорит что НЕТ универсальной/совместимой/...

Изначально разговор идет о расширителе Lua на базе проекта "xrLuaFix" (by RvP) - о чем читаем в кратком описании выложенного набора: #3936 При чем тут "она не универсальна" и начинать разговор о совершенно ином?

Многим из нас известно о существовании параллельного проекта x-Ray Extensions (by Malandrinus), но это тем более совершенно иная тема.

Существующие варианты для ЧН/ЗП сильно устарели. Для ЧН (что требуется тому же (*Shoker*'у) вообще мало что сделано. Пространства 'debag' также нет.

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

Данный вариант комплекта дает практически каждому модмейкеру для любого мода готовый набор (DLL+script) чтобы получить и информативный лог, в том числе из любого разумного набора аргументов для строки лога и дебаговый лог-файл (что важно при "безлоговых" ошибках), и инструметарий 'debug'-пространства, что также для любого модмейкера большое подспорье. И все это достаточно компактно и бесконфликтно как с кодами игры, так и с публичным применением/распространением подобной правки/добавки.

Цель комплекта в данном случае: дать любому модмейкеру для любой версии игры готовый к применению инструмент с минимальным необходимым для моддинга набором работы со скриптами/кодами, а не супернавороченый многофункциональный, но узко-заточенный, комбайн. Мы все же в "Школе", а не в "мастерских" ;-)

 

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

Изменено 1 Марта 2012 пользователем Artos

[*Shoker* 322]

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

Создать раздел вроде "Полезные скрипты\расширения" с прямыми ссылками на посты.

 

Unnamed Black Wolf

Вот оно как... а казалось всё узнал.

Пойду сделаю свою жизнь ярче

Спс. за цитату.

Они ведь могут в комбинации встречаться?

Изменено 1 Марта 2012 пользователем *Shoker*

[Artos 99]

*Shoker*, это пока первая версия, можно считать 'beta'. Есть моменты которые еще нужно бы доработать (хотя бы по дублирующему выводу в лог для ЧН/ЗП). Вот тогда или в шапку или в тему инструментария ее можно будет положить (если будет востребована).

О разделе по "полезным скриптам" - в процессе подготовки и обмозговывания :-). Вероятно (если движек форума позволит) второй в теме пост будет под эти цели.

 

И совет, если решил расцвечивать:

Учитывая, что делаешь мод на ЧН, которая (версия) критична к консольным командам, в функции _G.printf, которая в lua_fix.script, замени префиксы "* Info" и "* DBG" на пустышки (иль сотри их) и тогда в каждой строке, которую отправляешь в лог сможешь задавать префиксом расцветки.

И ... к сожалению запамятовал, но в каком-то моде был сделан набор функций-заготовок для вывода в лог разными цветами, типа: log_warning, log_fail, log_info, ...

[*Shoker* 322]

Вероятно (если движек форума позволит) второй в теме пост будет под эти цели.

Насколько я знаю, тут ограничение на размер сообщения. Если там будет слишком много кода\описания, то придётся ещё один пост забирать. Гораздо компактнее давать ссылки на посты. Можно и скрипт скачать и его обсуждение глянуть.

 

По поводу ЧН - всё вывожу через error_log(), тоесть без консоли. Пока не сбоило, а вот когда иногда вывожу через get_console() бывает виснет, особенно при частых вызовах. Кстати... а в error_log() та будет расцветка работать? Надо проверить...

 

_____________________

 

Насчёт alife():remove_in_restriction(soNPC, idRestr)

Вообщем похоже она вроде как и удаляет "ограничение" у НПС, но вылет по прежнему оставался. Удалил через нет-пакет и всё заработало пучком. Но всё же интересно почему удаление через alife() так работает странно.

Изменено 1 Марта 2012 пользователем *Shoker*

[Artos 99]

*Shoker*, с error_log() расцвечивать не получится, т.к. эта функция пристыковывает свой префикс в начало строки ( ! [LUA][ERROR] ) ...

Да и небезопасно, привыкнешь ... а в ЗП подобный вывод в "лог" сродни abort'у. ;-)

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

 

Ну а по по рестрикторам: когда достсточно набьешь шишек - бум разговаривать на одном языке - "битых, но наученных практикой". ;-)

Тем более пока не ясно, поменял ты алгоритм иль нет, т.е. чистишь "до" или "после". (но это мы опять за старое ...)

Изменено 1 Марта 2012 пользователем Artos

[*Shoker* 322]

Тем более пока не ясно, поменял ты алгоритм иль нет, т.е. чистишь "до" или "после"

Чистка идёт одновременно с удалением. Тоесть для удаления у меня идёт перебор всех объектов в игре (не экономно конечно, но юзаю старый сторонний алгоритм и как то привык к нему, тока вчера заметил что лучше бы удалять по таблице) и во время этого перебора если найдена аномалия - она удаляется, если нпс = у него чистится "ограничение", тоесть у меня и так и так получается...

 

_______

 

А вот заметил сообщения вида:

! cannot remove restriction with id 21963 to the entity with id 22264, because there is no space restrictor with the specified id

Но при save\load вылетов нету. И "ограничения" вроде как удалены.

Критично ли оставлять так как щас или может в дальнейшем аукнуться?

Изменено 2 Марта 2012 пользователем *Shoker*

[Artos 99]

*Shoker*, кротко можно ответить: "Не критично."

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

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

Изменено 2 Марта 2012 пользователем Artos

[_Призрак_ 11]

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

local str = r:r_stringZ()
if r:r_tell() > size then
    str = string.sub(str,1,size)
end

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

local str = ""
for i=1,size do
    str=str..string.char(r:r_u8())
end

где size - размер файла в байтах

Все работает, но работает невероятно медленно. Если раньше был небольшой лаг, то сейчас у меня игра зависает на пол минуты. Может у кого нибудь есть универсальное решение?

Изменено 3 Марта 2012 пользователем _Призрак_

[Nazgool 250]

_Призрак_

Подобная конкатенация в цикле - str=str..add - всегда была ужасно медленной штуковиной.

Сделай через таблицу :

local t = {}
local char = string.char
for i=1,size do
    t[#t+1] = char(r:r_u8())
end
local str = table.concat(t)

Изменено 3 Марта 2012 пользователем Gun12

[AndreySol 215]

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

В апдейте актера вызываю ф-цию:

local all_weight = 0
function show()
    GetInvWeight() -- здесь в переменную all_weight собираем общий вес

    local msg = nil
    local hud = get_hud()

    local cs = hud:GetCustomStatic("info_panel")
    if cs == nil then
        hud:AddCustomStatic("info_panel", true)
        cs = hud:GetCustomStatic("info_panel")
    end

    if cs ~= nil then
        msg = string.format("вес - %.2f кг", all_weight)
        cs:wnd():SetText(msg)
    end
end

эта ф-ция считает сам вес:

local get_ini = system_ini()
function GetInvWeight()
    all_weight = 0

    local npc = db.actor
    if npc ~= nil then
        npc:iterate_inventory(check_all_actor_items, npc)
    end
end
function check_all_actor_items(actor, item)
    local add_weight = 0
    local count = 0

    local section = item:section()
    if section then
        if get_ini:section_exist(section) then
            if get_ini:line_exist(section, "inv_weight") then
                if get_ini:line_exist(section, "class") then
                    local key_class = get_ini:r_string_wq(section, "class")
                    if key_class == "AMMO" then
                        local se_obj = alife():object(item:id())
                        local packet = net_packet()
                        cse_alife_item_ammo.STATE_Write(se_obj, packet)
                        packet:r_seek(packet:w_tell() - 2)
                        count = packet:r_u16() -- кол-во боеприпаса в пачке --

                        add_weight = Get_ammo_weight(section, count)
                    else
                        add_weight = get_ini:r_float(section, "inv_weight")
                    end
                end

                all_weight = all_weight + add_weight
            end
        end
    end
end

эта ф-ция считает вес реальной пачки патронов (не полной\полной)

function Get_ammo_weight(section, count)
    local count_in_box = 0 -- кол-во патронов в полной пачке --
    local box_weight = 0     -- вес полной пачки патронов --

    if get_ini:section_exist(section) then
        if get_ini:line_exist(section, "inv_weight") then
            box_weight = get_ini:r_float(section, "inv_weight")
        end

        if get_ini:line_exist(section, "box_size") then
            count_in_box = get_ini:r_float(section, "box_size")
        end
    end

    if box_weight > 0 and count_in_box > 0 then
        return (box_weight/count_in_box)*count
    else
        return 0
    end
end

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

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

Изменено 3 Марта 2012 пользователем AndreySol

[Artos 99]

AndreySol, вообще то советовать "как исправить" то, что заведомо ошибочно - неразумно.

Можно долго гадать (тем более не указана версия игры), сколь часто и с каким результатом можно обращаться к нет-пакетам объекта, каждый раз вызывая локальные копии пакетов и справляется ли движек с подобным ... Но можно и просто указать на порочность данного алгоритма:

1. Ты считаешь, что обновлением ~50 раз в секунду в окне кастом-статика получаешь больше информации, чем, например, делая подобное 1 раз в секунду?

2. Ты считаешь, что те же самые секции объектов/предметов, следует перечитывать каждый раз заново из конфиг-файлов, т.к. один раз прочитанное может измениться?

 

Попробуй переписать свои функции с учетом вышесказанного, и кешируя ту же local packet = net_packet() один раз, а не в каждом цикле апдейта да еще и для каждой пачки(!). Тогда есть смысл искать непонятки и решение для них, а не гадать над непригодным для игры кодом. :-) Не лишним, также, будет packet:w_begin(0) - т.е. установка в начало нет-пакета перед его чтением ...

Изменено 3 Марта 2012 пользователем Artos

[Nazgool 250]

Я уже забыл конечно (давно сталкером не занимался). Собственно - изменение в инвентаре это не дроп\тэйк?

Если да, то ставить обновление на них вместо апдейта.

[Artos 99]

Gun12, ты прав, это более подходящий вариант для апдейта веса, но ... AndreySol не потрудился указать цели своих проверок.

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

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

Изменено 3 Марта 2012 пользователем Artos

[AndreySol 215]

1. Ты считаешь, что обновлением ~50 раз в секунду в окне кастом-статика получаешь больше информации, чем, например, делая подобное 1 раз в секунду?

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

2. Ты считаешь, что те же самые секции объектов/предметов, следует перечитывать каждый раз заново из конфиг-файлов, т.к. один раз прочитанное может измениться?

но может изменится содержимое инвентаря.

Да и проблема как я понял, все-же в чтении из нет-пакета.

и кешируя ту же local packet = net_packet() один раз, а не в каждом цикле апдейта да еще и для каждой пачки(!)

если имеется в виду вынести local packet = net_packet() из ф-ции GetInvWeight(), то я попробовал и с учетом добавления packet:w_begin(0) - результат тот-же.

[Artos 99]

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

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

Такой ответ тебя устраивает: "У меня на чистой SCoP v1.0006 твои коды работают без проблем и все отображается!" - ?

Т.о. искать черную кошку в темной комнате, да еще когда ее там нет - потрудись сам.

Также тебе дали рекомендации/советы по и оптимизации и собственно по возможным причинам твоей проблемы:

 

1. Хорошо, что тебе это известно, ну а думалка то на что?

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

- нужно все же различать: обновление одной и той же картинки/иконки или обновление текста/цифр. Неужели не в домек, что меняя цифирьки с частотой 50 раз в секунду и если цифирьки меняются - ты ничего не разберешь в выводимом сообщении?!

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

 

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

 

Ну и конечно же "проблема" в чтении из нет-пакета, раз закомментирование именно строк с ними убирает ошибку, а точнее - в подобном чтении, которое применяешь именно ты ...

Не буду гадать далее, но если возникает ошибка нужно все же уделить внимание даже тем участкам кода, которые кажутся "правильными":

- получая серверный объект пачки патронов, наверное стОит перепроверить "а существует ли se_obj в игре?", и только после этого пытаться читать его нет-пакеты.

- стОит ли полагаться неким проверкам по строкам в конфиг-файлах о классе объекта, когда можно напрямую однозначно проверить класс объекта для тех же патронов: "if item:clsid() == clsid.wpn_ammo then ...";

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

 

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

 

 

[_Призрак_ 11]

Есть более элегантное решение. Установите себе X-Ray extensions, там есть метод (в каком то из последних ревизий добавили), который возвращает вес инвентаря