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

[Zander_driver 10 333]

1 минуту назад, mole venomous сказал:

Есть скриптовый вариант? Предложи

Я движка ОП не знаю)

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

В OGSR это число доступно в db.actor.alcohol

В оригинале ТЧ... не помню я.

В ОП

10 минут назад, Zander_driver сказал:

надо брать их справочную документацию/исходники и смотреть там.

 

В ОП есть же какой-то lua_help?
Вот с него и начать.

[mole venomous 3 381]

@Zander_driver , тогда самое разумное, это привнести правки в движок. Имея исходники движка ОП-2.2 и навык работы с движком.

[phalcor 60]

3 минуты назад, Zander_driver сказал:

В ОП есть же какой-то lua_help?
Вот с него и начать.

В lua_help ничего нет, в искходниках (от версии 2.1) - тоже нет. (под "нет" я подразумеваю "не нашёл").

Потому и вопрошаю про нет-пакеты. Однако же подозреваю, что и это не поможет 

Только что, mole venomous сказал:

привнести правки в движок. Имея исходники

Авторы не делятся такими священными данными 

[Zander_driver 10 333]

 

7 минут назад, mole venomous сказал:

самое разумное, это привнести правки в движок

Не совсем так.

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

в ОП где-нибудь что-то делается с опьянением ГГ или в зависимости от него? Вот там и смотреть, как они это значение получают.

Изменено 23 Июля 2023 пользователем Zander_driver

[mole venomous 3 381]

Алкогольная зависимость как работает? Если она есть... 

[Norman Eisenherz 309]

В ТЧ полностью движковый обсчет опьянения со ссылкой на eat_alcohol в конфиге расходника и скорость отрезвления alcohol_v (+ _sleep) в конфиге ГГ – см. [xrGame\ActorCondition.cpp]. В нетпакетах значение не упоминается.

[666Ian 6]

Движок огср. Нет-пакеты из огср стандартные(Артас)

Всем привет. Копаюсь иногда в сталкер, делаю всякое, вот дошли руки до свойств предметов(артефакты, оружие, броня). Дело в чем, значит, меняю я это свойство, например, у пистолета что-то типо pistol:get_weapon().cost = 10000. Отлично. Все работает, но до следующей загрузки и сбрасывается. Вопрос, как записать это свойство навсегда? это нет-пакеты? Просто я и пакетами пытался и как я понял пакетом менять-то особо нечего: моделька, custom_data(почти бесполезная штука для предмета?), положение и позиция на уровне, какие-то ненужные мне настройки стори ид, какие-то непонятные items_num... Нет, я гуглю конечно, смотрю, читаю про пакеты и медленно узнаю что-то новое, но может кто сразу скажет возможно ли пакетами менять свойства предмета, как я выше приводил пример скриптами, но навсегда? Если не пакеты, то может как-то ещё можно сохранить выставленный скриптом property? Если нельзя, то зачем вообще тогда эта возможность менять свойства предмета? 

[RayTwitty 492]

4 часа назад, phalcor сказал:

Подскажите, как можно определить опьянение актора? Скриптовой функции, я так понял, нет. 

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

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

 

Вроде в АМК моде была алкогольная зависимость, можно посмотреть как там сделали.

 

P.S. А, на чистом движке эффектор тоже не получить никак, так что только костыли выдумывать.

 

@666Ian значение надо сохранить в серверном объекте в se_item.script, найдя нужный тебе класс оружия. После чего загрузить и выставить это значение при входе оружия в онлайн (на net_spawn или на первом апдейте).

Изменено 23 Июля 2023 пользователем RayTwitty

[Опричник 5 298]

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

Вроде в АМК моде была алкогольная зависимость

И в огсе 0693 была. Только не знаю, своя или взяли откуда-нибудь.

[RayTwitty 492]

2 часа назад, Опричник сказал:

огсе 0693

В нем есть свойство alcohol, там все проще.

 

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

[666Ian 6]

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

 

@666Ian значение надо сохранить в серверном объекте в se_item.script, найдя нужный тебе класс оружия. После чего загрузить и выставить это значение при входе оружия в онлайн (на net_spawn или на первом апдейте).

А можно какой-нибудь простой пример, вот цену предмета конкретного выставить в 10 рублей? А то я голову сломал уже. Не понимаю как мне получить серверный объект методом для онлайнового. Да и вообще, наверное все не так делал.

[Zander_driver 10 333]

2 часа назад, 666Ian сказал:

Не понимаю как мне получить серверный объект методом для онлайнового.

Если "онлайновый" = клиентский, то никак

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

local obj = level.object_by_id(id) -- Получаем клиентский объект, зная его ID
local obj_id = obj:id() -- Узнаем ID клиентского объекта, если он у нас есть
local sobj = alife():object(id) -- Получаем серверный объект, зная его ID
local sobj_id = sobj.id -- Узнаем ID серверного объекта, если он (объект) у нас есть.
--ID серверных и клиентских объектов всегда совпадают. Так что, выяснив id одного из них (например клиентского), можно зная id получить серверный, и наоборот.
--У некоторых специфических объектов игры (например: Болт). Существует только клиентский объект, а серверного нет.

 

[666Ian 6]

27 минут назад, Zander_driver сказал:

Если "онлайновый" = клиентский, то никак

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

local obj = level.object_by_id(id) -- Получаем клиентский объект, зная его ID local obj_id = obj:id() -- Узнаем ID клиентского объекта, если он у нас есть local sobj = alife():object(id) -- Получаем серверный объект, зная его ID local sobj_id = sobj.id -- Узнаем ID серверного объекта, если он (объект) у нас есть. --ID серверных и клиентских объектов всегда совпадают. Так что, выяснив id одного из них (например клиентского), можно зная id получить серверный, и наоборот. --У некоторых специфических объектов игры (например: Болт). Существует только клиентский объект, а серверного нет.

local obj = level.object_by_id(id) -- Получаем клиентский объект, зная его ID
local obj_id = obj:id() -- Узнаем ID клиентского объекта, если он у нас есть
local sobj = alife():object(id) -- Получаем серверный объект, зная его ID
local sobj_id = sobj.id -- Узнаем ID серверного объекта, если он (объект) у нас есть.
--ID серверных и клиентских объектов всегда совпадают. Так что, выяснив id одного из них (например клиентского), можно зная id получить серверный, и наоборот.
--У некоторых специфических объектов игры (например: Болт). Существует только клиентский объект, а серверного нет.

 

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

[RayTwitty 492]

6 часов назад, 666Ian сказал:

А можно какой-нибудь простой пример, вот цену предмета конкретного выставить в 10 рублей?

Нужно создать биндер для оружия (по аналогии с физ. объектами например), подключить его в базовой секции в конфигах (если есть, иначе во всех секциях по отдельности), получать на net_spawn серверный объект и смотреть, сохранена ли там стоимость. Если да, то менять (восстанавливать) ее твоим способом через свойство cost для клиентского объекта.

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

 

Проще по-моему двиг поправить, добавив там в общую кучу сохранение cost))

[666Ian 6]

@RayTwitty да мне не только cost. Я вообще все свойства хотел менять в перспективе, такая же фишка интересная: вот есть у тебя ствол, ты с этим стволом в руках влез в какой-нибудь кисель или ещё лучше уронил его туда и вот уже пушка пройдя через условия поменяла свойства, стала там радиоактивной или стрелять сильнее, мощнее. Можно конечно переспавнить ствол и не парится, но зачем если вроде бы свойства так меняются. Те же артефакты можно было сделать уникальными, т.е каждый арт необычный и непредсказуемый. А так, я думаю, ну по крайней мере это звучит так, что это плохая идея возится с этим. Свойства эти никогда не сохранятся, они должны быть заранее где-то в скрипте прописаны и каждый раз выставляться предмету при его нет спавне, правильно я понял? Тот же биндер на физобьекты обрабатывает сразу все объекты, если даже выделить секцию, например артефакт медуза, то таких медуз по зоне будет дофига, и у всех модифицированные свойства будут? Тогда какой в этом смысл. Заранее брать какой-то предмет по имени там или айди какому, то тоже не то, потому что я и сам не знаю с каким предметом игрок пройдет через "улучшатор/ухудшатор". Это должен был быть бы каждый раз разный предмет. А может я вообще не так понял ответ твой и все отрисовал неправильно. Короче это достаточно геморно, чтобы поменять это как, например, меняется моделька предмета через пакеты? Потому что модельку я научился менять без всяких там биндеров, без всяких нет спавнов... Загнал в оффлайн, сменил модельку, вывел в онлайн и забыл. Вот так же я и свойства думал менять примерно, хотел бы. А ещё лучше было бы, чтобы все эти изменения в клиентском объекте оставались бы сами навсегда, как состояние там или кол-во патронов в той же пушке. 

 

[RayTwitty 492]

1 час назад, 666Ian сказал:

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

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

 

1 час назад, 666Ian сказал:

Тот же биндер на физобьекты обрабатывает сразу все объекты, если даже выделить секцию, например артефакт медуза, то таких медуз по зоне будет дофига, и у всех модифицированные свойства будут? Тогда какой в этом смысл.

Нет, экземпляр биндера создается для каждого объекта отдельно, в том и смысл))) Биндер физ. объектов я привел в пример как тот, который можно взять за основу. По-нормальному конечно, для артов нужен свой биндер, для оружия свой и т.д. У всех объектов же разные параметры.

Изменено 24 Июля 2023 пользователем RayTwitty

[666Ian 6]

29 минут назад, RayTwitty сказал:

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

 

Нет, экземпляр биндера создается для каждого объекта отдельно, в том и смысл))) Биндер физ. объектов я привел в пример как тот, который можно взять за основу. По-нормальному конечно, для артов нужен свой биндер, для оружия свой и т.д. У всех объектов же разные параметры.

Тогда я не так понял. Блин. Про арты и оружие свой биндер, то понятное дело, а по биндеру я представил bind_destroyble_object.script(ну или как он там. Скрипт который к ящикам подключен и дверям там, рычагам), когда расписывал свои мысли, ну и видимо не в ту сторону посмотрел... Плохо понимаю в этом деле просто. Мне бы пример всё-таки. По-другому писать-то и не научился пока.

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

[Norman Eisenherz 309]

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

Прокачка как раз пишется в нетпакет (таблица upgrades в STATE-части), но обработка прокачки есть только в ЧН/ЗП и подобных движках.

[666Ian 6]

@Norman Eisenherz это мне помогали, есть такой код. Для чн. У меня огср движок и может там есть это, да и ковыряя пакеты оружия, артов и брони мне выводило в лог этот самый upgrades. Только я точно пробовал применять на арты и получал вылет, что нельзя артэфакту это ставить якобы, хоть лог до этого и выдавал будто бы применить это можно к ним. Может из-за того, что конфиги не заполнены по аналогии с зп или чн. Не знаю возможно ли это в общем сделать. Ну вариант хуже или лучше варианта от рейтвитти? Попробую на пушку сейчас сделать, но что-то вспоминая мод ганслингер на тч и систему апгрейдов оружия с него, которая заключал в переспавне секций как я помню, сильно сомневаюсь в работоспособности этого способа даже на огср движке великом и могучем 

 

Я ещё вроде видел то, о чем тут мечтаю, в моде prosectors project, но вряд ли у меня стащить оттуда выйдет. Там скрипты совсем по-другому написаны и, наверное, движок с огср отличается. А ещё там дата зашифрована с ней возится конечно мне тоже гемор

 

Решил всё-таки способом @RayTwitty попробовать подумать ещё раз. Правда, если пример получить невозможно с которого бы я все слизал, можно хоть подсказку какой биндер имеется ввиду. Я о том, что куда пробовать: делать что-то в скрипте se_item(вообще без понятия что) или прямо создавать биндер на подобии bind_heli, bind_physic_object опираясь вдобавок на подобные статьи из интернета, после чего пройтись, если мне нужна броня, по конфигам всех броников где подключить им этот биндер. В самом биндере достаточно будет использовать методы (save, load), которые сами все сделают. Или мне нужно полностью биндер делать с апдейтами там и остальными методами, полноценный. Я просто не вижу пока, может не нашел, где и как используется save,load. Пока думается, что при выходе предмета в онлайн все само сработает как надо:) как-то там. При этом апдейт мне вроде не нужен, поэтому нет в нем нужды, как и в нет дестрой, правильно? 

 

Всё что имею. Меняю свойства - цену и модельку

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

function outfit_changer()
db.actor:iterate_inventory(
	function( dummy, obj )
	if isOutfit(obj) then
	change_property(obj)
      end
    end
  )
end

function change_property(obj)
local item_id = obj:id()
--
local pos = db.actor:position()
db.actor:drop_item_and_teleport(obj, vector():set(pos.x + 5, pos.y, pos.z))
alife():set_switch_offline(item_id, true)
alife():set_switch_online(item_id, false)
alife():set_interactive(item_id, false)
local pk = m_netpk.get(obj)
if pk and pk:isOk() then
local data = pk:get()
local description = pk:dumpDesc()
log1(description)
data.visual_name = "weapons\\wpn_rpg_7.ogf"
pk:set(data)
end		
to_online(item_id)
end

function to_online(id)

	local iTimer = time_global() + 3000
	
	local function check_timer()
		return time_global() > iTimer
	end

	local function spawn_callback(id, obj)
		obj:transfer_item(obj, db.actor )
		obj:get_outfit().cost = 10
	end
	
	local function action_timer()
		alife():set_switch_offline(id, false)
		alife():set_switch_online(id, true)
		alife():set_interactive(id, true)
		
		level.client_spawn_manager():add(id, 0, spawn_callback)
		
	end

	level.add_call(check_timer, action_timer)
end

 

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

Дальше я жму сохранить игру, следующее действие - загрузить.

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

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

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

function init(obj)
	local noutfit_binder = outfit_binder(obj)
	obj:bind_object(noutfit_binder)
end

---------------------------------------------------------------------------------------------
class "outfit_binder" (object_binder)
function outfit_binder:__init(obj) super(obj)
	self.initialized = false
	self.loaded = false
end

function outfit_binder:reload(section)
	object_binder.reload(self, section)
end

function outfit_binder:reinit()
	object_binder.reinit(self)
end

function outfit_binder:net_spawn(data)
	if not object_binder.net_spawn(self, data) then
		return false
	end

	return true
end

function outfit_binder:update(delta)
	object_binder.update(self, delta)

end

function outfit_binder:net_destroy()
	object_binder.net_destroy(self)
end

function outfit_binder:net_save_relevant()
	return true
end

function outfit_binder:keep_saved_data_anyway()
	return true
end

function outfit_binder:save(packet)
	object_binder.save(self, packet)
end

function outfit_binder:load(reader)
	self.loaded = true

	object_binder.load(self, reader)
end

 

 

 

[Zander_driver 10 333]

Ох, Ёлки зеленые, кучерявые...

@666Ian , дружище, по порядку.

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

У меня огср движок

Это очень хорошо. На нем есть как минимум 4 варианта, как сделать то что ты хочешь.

0) Нетпакеты сразу забудь. Вообще. Оно тебе не надо, совсем, тем более если на ogsr.

1)

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

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

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

2) Можно писать свои свойства в кастом-дату серверного объекта. В ogsr она доступна по адресу sobj.custom_data , причем доступна как для чтения, так и для записи. Туда можно записать свои сериализованные свойства (конкретно для ДАННОГО объекта), и применять их при net_spawn в биндере. Недостаток тут есть - custom_data иногда все же используется/перезаписывается всякими другими скриптами, и не так уж много данных в нее влезет. Но рамки использования достаточно широкие, и в принципе это может быть удобная и гибкая система кастомизации свойств объектов, хоть и не всех.

3) Можно писать свои свойства в script_vars_storage (см. ogsr-wiki), Записывая туда также id объекта, для которого это записано. И соответственно опять же применять их при net_spawn в биндере. Немножко больше мороки, но зато этот метод лишен минусов варианта с кастом-датой. Записывать можно - сколько душе угодно, и чего угодно, не опасаясь что какие-то посторонние скрипты туда зачем-то полезут.

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

Ну и...

4) Метод самый простой и удобный. Но в каком-то смысле и "непростой"...

Берешь исходники движка. И пишешь туда сохранение всех тех свойств которые ты желаешь сохранять, в серверный объект(ы). В классы серверных объектов.

Я лично делал именно так, заготовив сохраняемых параметров с запасом и на вырост, чтоб по ходу доработок добавлять сохраняемых свойств и не требовать НИ при этом.

Единственный минус этого метода - надо знать C++ и уметь собирать движок. В остальном одни плюсы...

16 часов назад, 666Ian сказал:

Пока думается, что при выходе предмета в онлайн все само сработает как надо:) как-то там.

Неа. Все что штатно движок грузит из конфига - если ты хочешь чтоб оно грузилось из кастом-даты / script_vars_storage / серверного объекта, то надо это делать ручками. "Само" оно только из конфига будет загружаться.

24.07.2023 в 17:36, 666Ian сказал:

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

Но вообще, по хорошему...

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

Движок это всё шустрее обработает.