GAMEINATOR forums > Закрома Родины

Помощь - Поиск - Пользователи - Календарь

Полная версия этой страницы: Закрома Родины

GAMEINATOR forums > S.T.A.L.K.E.R. > Мастерская: создание модов для S.T.A.L.K.E.R.

Страницы: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77

Vampir35

13.08.2014, 16:46

Цитата

А это вообще ужас-ужас

Мне лично вполне удобно)

alpet

13.08.2014, 17:45

Цитата(abramcumner @ 13.08.2014, 17:29)

1. get_actor(), с какой стороны ни глянь, совсем не полиморфизм
2. Раньше, например, было элегантно: ГГ и НПЦ обрабатывались единообразно, а сейчас get_actor, get_npc
3. А это вообще ужас-ужас

1. В 111 добавил ещё более вандальную функцию get_actor_obj() чтобы более не трогать db.actor в скриптах

2. Вам никто не мешает пользоваться API как было раньше. Кстати свойство inventory так-же добавлено в game_object. С иммунитетами скоро переделаю в свойство-объект immunities, которое будет присутствовать у всех мобов.
3. Ну что там можно улучшить?

Vampir35

13.08.2014, 18:19

Цитата

Вам никто не мешает пользоваться API как было раньше.

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

abramcumner

13.08.2014, 19:05

Цитата(alpet @ 13.08.2014, 18:45)

1. В 111 добавил ещё более вандальную функцию get_actor_obj() чтобы более не трогать db.actor в скриптах

А к чему тогда разговоры про полиморфизм и прочее, если делается прямо противоположное

alpet

13.08.2014, 22:21

Цитата(abramcumner @ 13.08.2014, 20:05)

А к чему тогда разговоры про полиморфизм и прочее, если делается прямо противоположное

Давайте тут разберемся.
Мне хочется избежать неявных указаний классов в методах и свойствах game_object.
Например, думаю что следующий код:

Код

local ammo = level.object_by_id(id)
if ammo:get_ammo_box_curr() < ammo:get_ammo_box_size() then
ammo:get_ammo_box_curr() = ammo:get_ammo_box_curr() + 1
end

Несколько менее изящен, чем такой:

Код

local box = level.object_by_id(id).ammo_box
if box.curr < box.size then
box.curr = box.curr + 1
end

Хотя не буду спорить, кому что нравиться.

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

Код

local a = db.actor:get_actor()

Может быть представлен и так, при небольшой доработке:

Код

local a = db.actor.obj

Однако определив перед компиляцией свойство obj с типом CActor, его уже никак не изменить для остальных объектов. Можно сделать экспорт общего для многих объектов класса CEntity, который не будет экспортировать свойства характерные для наследников. Так например сделано для свойства immunities, поскольку класс CHitImmunity для большинства объектов является предком. Так-же в новой ревизии класс game_object предлагает следующие объекты-свойства:

Код

CInventory inventory
CEntityCondition conditions

Однако, из-за известных ограничений получается, что свойство db.actor.conditions != get_actor_obj().condition, поскольку у первого класс CEntityCondition, а у второго CActorCondition с большим числом свойств.
Пока не выяснится, как лучше осуществлять динамический экспорт классов... других вариантов просто нет. Надежда что это удастся реализовать, ещё есть )
P.S.: Свойство condition.health не равноценно game_object.health, как может показаться. Shadows приметил, что следуя туманной логике разработчиков, CScriptGameObject::SetHealth занимается зачем-то приращением, вместо присвоения.

Alex Rinic

13.08.2014, 22:32

Доброго времени суток. Хотел бы спросить по поводу одного известного бага.

Вопрос с подтекстом.

В оригинальном Stalker Shadow of Chernobyl нередко встречалась ситуация, когда при разрушении разбиваемых ящиков в случае, когда ящик находился на наклонной поверхности, предметы могли провалиться под карту. Это было связано с тем, что шейп главной кости предмета

осторожно картинка !

пересекался с террейном/материалом зданий. Из-за этого же бага в Stalker Clear sky артефакты при попытке взятия из аномалии частенько проваливались "под землю" при "подсветке" детектором. Баг можно обойти, разместив шейп главной кости значительно выше самой кости(как на примере в скриншоте), в этом случае предмет не провалится под карту, но в случае с артефактами начинается "ахтунг" : дело в том, что движок отыгрывает источник света и партиклы строго по положению главной кости артефакта и если главная кость ниже шейпа то источник света и точка отыгрывания партиклов оказываются "под землёй". Ещё хуже обстоит дело, если артефакт имеет свою анимацию и дочерние кости движутся относительно главной - выглядит, как будто артефакт "здесь", а партиклы "где-то там". Было бы замечательно, если бы можно было задавать через .ltx - конфиг кость, из которой "появятся" предметы при разрушении разбиваемого ящика.

Пример

Содержимое файла models\objects\box_metall_01.ltx, сам файл подключается к модели в actor editor'е

много знаков

CODE

;--- destroyed sections --------------------------------------------------------

;-------------------------------------------------------------------------------
;--- disable -------------------------------------------------------------------
;-------------------------------------------------------------------------------

[disable]
linear_factor            = 0.5
angular_factor           = 0.5

;-------------------------------------------------------------------------------
;--- collide -------------------------------------------------------------------
;-------------------------------------------------------------------------------

[collide]
not_collide_parts        = 0

;-------------------------------------------------------------------------------
;--- destroyed part ------------------------------------------------------------
;-------------------------------------------------------------------------------

[destroyed]
physics\box\prt\box_metall_01_prt1
physics\box\prt\box_metall_01_prt2

[autoremove_parts]
time					  = 60

;-------------------------------------------------------------------------------
;--- damage params -------------------------------------------------------------
;-------------------------------------------------------------------------------

[collision_damage]
link                     = 0.1

;-------------------------------------------------------------------------------
;--- particles -----------------------------------------------------------------
;-------------------------------------------------------------------------------

[particles]
destroy_particles        = destroy_fx\destroy_wood_00

;-------------------------------------------------------------------------------
;--- particle_bones ------------------------------------------------------------
;-------------------------------------------------------------------------------

[particle_bones]
link                     =  0.0, 0.15, 0.0

;-------------------------------------------------------------------------------
;--- sound ---------------------------------------------------------------------
;-------------------------------------------------------------------------------

[sound]
break_sound              =  material\wood\wood_crash1_hl2

;-------------------------------------------------------------------------------
;--- damage_bones --------------------------------------------------------------
;-------------------------------------------------------------------------------

;bone_name               = <hit_scale>,<-1>,<wound_scale>
;<hit_scale>             - коэфф. изменения хита (уменьшения здоровья)
;<wound_scale>           - коэфф. изменения величины открытой раны - незадействован

;-------------------------------------------------------------------------------

default                  = 1.0, -1, 0.0

[immunities]
burn_immunity            = 0.5        ;коэффициенты иммунитета
strike_immunity          = 0.5
shock_immunity           = 0.5
wound_immunity           = 0.5
radiation_immunity       = 0.0
telepatic_immunity       = 0.0
chemical_burn_immunity   = 0.0
explosion_immunity       = 0.5
fire_wound_immunity      = 0.5

;-------------------------------------------------------------------------------
;--- impulse_transition --------------------------------------------------------
;-------------------------------------------------------------------------------

[impulse_transition_to_parts]
random_min               = 0.2     ; величина случайно направленного импульса пропорционально массе нового объекта
random_hit_imp           = 0.2     ; величина случайно направленного импульса пропорционально разрушающему хиту
;ref_bone                          ; кость из по которой определяется скорость для частей у который связь не задана, по умолчанию рут
imp_transition_factor    = 1.0     ; фактор с которым прикладывается хит по исходному объекту ко всем частям
lv_transition_factor     = 0.2     ; коэффициент передачи линейной скорости
av_transition_factor     = 0.2     ; коэффициент передачи угловой скорости

;-------------------------------------------------------------------------------
;------ End params -------------------------------------------------------------
;-------------------------------------------------------------------------------

Например добавить секцию

код

CODE

[item_spawn]
item_spawn_bone = bone_01

При разбивании такого ящика предметы появляются по координатам кости bone_01, а не главной кости. В случае же, если секция [item_spawn] отсутствует, или указанная кость не существует, или отсутствует параметр item_spawn_bone, предметы появляются по координатам главной кости link.

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

Пример

Кусок кода из misc\artefacts.ltx

Код

CODE

[af_vyvert]:af_base
GroupControlSection	= spawn_group
$spawn				= "artifacts\gravy vyvert"

$prefetch 			= 64
cform				= skeleton
class				= ARTEFACT

visual				= physics\anomaly\artefact_gravy1.ogf  
description			= enc_zone_artifact_af-vyvert
inv_name			= af-vyvert
inv_name_short		= 
inv_weight			= 0.5

inv_grid_x			= 14
inv_grid_y			= 0

cost				= 1000

jump_height			= .3

particles			= anomaly2\artefact\artefact_gravi

lights_enabled = false	;true			;???? ? 

artefact_activation_seq		= af_activation_gravi

;скорости увеличения (уменьшения) 
health_restore_speed = 0.0			
radiation_restore_speed = 0.0005
satiety_restore_speed = 0.0
power_restore_speed = 0.0
bleeding_restore_speed = 0.0
hit_absorbation_sect = af_vyvert_absorbation

[af_vyvert_absorbation]
burn_immunity = 1.0				;коэффициенты иммунитета 
strike_immunity = 1.0
shock_immunity = 1.0
wound_immunity = 0.98
radiation_immunity = 1.0
telepatic_immunity = 1.0
chemical_burn_immunity = 1.0
explosion_immunity = 1.0
fire_wound_immunity  = 1.0

Например в сецию [af_vyvert] добавить параметр show_lights_bone = bone_01, партиклы и источник света в этом случае будут отыгрываться по расположению кости bone_01. В случае же, если отсутствует параметр show_lights_bone, или кость указана неверно, то партиклы и источник света отыгрываются по координатам главной кости артефакта.

Планируется ли сделать что-то подобное ?

abramcumner

13.08.2014, 23:38

Цитата(alpet @ 13.08.2014, 23:21)

P.S.: Свойство condition.health не равноценно game_object.health, как может показаться. Shadows приметил, что следуя туманной логике разработчиков, CScriptGameObject::SetHealth занимается зачем-то приращением, вместо присвоения.

Это порочная практика тащить в скрипты кишки движка.

Цитата

local ammo = level.object_by_id(id)
if ammo:get_ammo_box_curr() < ammo:get_ammo_box_size() then
ammo:get_ammo_box_curr() = ammo:get_ammo_box_curr() + 1
end

Цитата

local box = level.object_by_id(id).ammo_box
if box.curr < box.size then
box.curr = box.curr + 1
end

Еще круче:

Код

local obj = level.object_by_id(id)
obj.ammo_cur = 1

Проверка на переполнение в движке, работает как health; с патронами и оружием единообразно
Ну и уже есть set_ammo_elapsed заюзайте его и для пачки патронов.

alpet

14.08.2014, 08:46

Цитата(abramcumner @ 14.08.2014, 00:38)

Еще круче:

Код

local obj = level.object_by_id(id)
obj.ammo_cur = 1

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

Этот-же код может выглядеть элегантно, при соответствующем конструкторе и выделенном классе ammo_box:

Код

local box = ammo_box(id)
box.curr = 1

Однако это все лирика, я просто надеюсь что свое видение API передал

MegaNub

14.08.2014, 09:51

Кто-нибудь пробывал собирать редактор погоды?

Vampir35

14.08.2014, 11:29

Alpet, а почему такая конструкция в 111 ревизии стала вызывать вылет?

Код

db.actor:item_in_slot(9):torch_enabled()

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

alpet

14.08.2014, 12:56

Цитата(Vampir35 @ 14.08.2014, 12:29)

Alpet, а почему такая конструкция в 111 ревизии стала вызывать вылет?

Код

db.actor:item_in_slot(9):torch_enabled()

Переделано, для соответствия документации (как раз случай, когда разные функции разошлись к разным объектам). Теперь нет такой функции как torch_enabled, есть свойстов CTorch.on
[code]
local torch_on = db.actor:get_torch().on
-- или, что равноценно:
torch_on = db.actor:item_in_slot(9):get_torch().on
[code]

Modera

14.08.2014, 14:36

Цитата(Modera @ 10.08.2014, 16:32)

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

Разобрался в чём проблема была, оказывается directx sdk из архива от Diablo не подходит туда.
А версия за апрель 2006 отлично подходит.

Vampir35

14.08.2014, 15:34

Alpet, в предыдущих ревизиях фонарик можно было отключить так:

Код

db.actor:item_in_slot(9):enable_torch(false)

Как это теперь сделать?)

MegaNub

14.08.2014, 15:59

Цитата(MegaNub @ 14.08.2014, 10:51)

...редактор погоды?

Интересная штука, да ещё и WYSIWYG, не обычно для X-Ray

alpet

14.08.2014, 16:42

Цитата(Vampir35 @ 14.08.2014, 16:34)

Alpet, в предыдущих ревизиях фонарик можно было отключить так:

Код

db.actor:item_in_slot(9):enable_torch(false)

Как это теперь сделать?)

Много способов:

Код

db.actor:item_in_slot(9):get_torch():enable(false)
-- или
db.actor:get_torch():enable(false)
-- или
get_torch_obj(0):enable(false) -- получить фонарь гг

Кстати, сделал в 113 ревизии и получение объекта с произвольными классом. Для этого можно использовать свойство interface объекта game_object или глобальную функцию engine_object( id or game_object ):

Код

-- выключение фонаря
db.actor:item_in_slot(9).interface:enable(false) -- interface выдает объект CTorch
-- причинить вред здоровью
db.actor.interface.condition.health = 0.3 -- interface выдает объект CActor

Мне думается, что программисты GSC об таких возможностях luabind не знали, поэтому и свалили все классы в один game_object.

HikeR

14.08.2014, 17:12

а мне думается, что программисты GSC хотя бы знали что такое профайлер.

посмотрел на "изящную замену"

Код

local ammo = level.object_by_id(id)
if ammo:get_ammo_box_curr() < ammo:get_ammo_box_size() then[/i]
--
local box = level.object_by_id(id).ammo_box
if box.curr < box.size then

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

впрочем, даже без профайлера "тяжесть" подобного изящества описана в мануалах и Lua и luajit-а (даже древней первой версии).

abramcumner

14.08.2014, 17:16

Цитата(alpet @ 14.08.2014, 17:42)

Не знали, но alife():object сделали. Умора!

Ронин

14.08.2014, 18:00

Цитата(MegaNub @ 14.08.2014, 17:59)

Цитата(MegaNub @ 14.08.2014, 10:51)

...редактор погоды?

Интересная штука, да ещё и WYSIWYG, не обычно для X-Ray

Риалтайм настройка? Работает? А под ЗП заведется?

Tron

14.08.2014, 18:49

Реалтайм-реалтайм.под Зовом не заведется

Shoкer

14.08.2014, 18:55

По поводу этих интерфейсов интересно насколько технически возможно в рамках С++ и ресурсоёмкости возможность просто создать и экспортировать универсальный С++ метод, который автоматом экспортировал бы (хотя бы) все свойства класса и привязывал бы их к имени класса, чтобы например в lua получать\изменять свойства объекта так:

db.actor:Engine("CActor").fCurAVelocity
db.actor:Engine("CActor").m_fWalkAccel
db.actor:Engine("CInventoryOwner").m_money

И т.д и т.п
То-есть кастовать для lua-объекта нужный движковый класс (предком которого является lua-объект) и вычитывать любое его свойство.

Упор делается именно на автоматизацию - возможность работать с любым классом движка без предварительной его подготовки и экспорта в Lua.
Или же такое решение потребует серьёзного переписывания движковых классов?

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

MegaNub

14.08.2014, 18:59

Цитата(Scarabay @ 14.08.2014, 19:00)

Риалтайм настройка? Работает? А под ЗП заведется?

Да, Real-time, всё работает. На ЗП к сожалению не заведётся, нужна Debug или Mixed версия xrEngine

alpet

14.08.2014, 19:09

Цитата(HikeR @ 14.08.2014, 18:12)

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

Вы меня пугаете! Покажите код, в котором копируются все свойства объектов. Да и бенчмарк, демонстрирующий дикие затраты тактов ЦП, на подход с интерфейсами... очень помог-бы

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

Цитата(abramcumner @ 14.08.2014, 18:16)

Не знали, но alife():object сделали. Умора!

Функция alife_object всегда возвращает CSE_ALifeDynamicObject, и никакой другой. Так что, видимо все-таки не знали

Shoker
На моей практике, без дополнительного кода ничего не получится. Экспорт свойств через luabind требует "ручной работы", зачастую рутинного перечисления выдаваемых наружу свойств.
Для актора уже большая часть свойств доступна.

Tron

14.08.2014, 19:13

Есть генераторы для луабинда
Liabindcxx

HikeR

14.08.2014, 19:23

Цитата(alpet @ 14.08.2014, 20:09)

Покажите код, в котором копируются все свойства объектов.

второй раз покажу, это нетрудно — local box = level.object_by_id(id).ammo_box

p.s.
поправочка: во время создания ссылки на таблицу ammo_box (если у этой таблицы переопределен метаметод __index), либо еще раньше (для предварительного заполнения членов таблицы).

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

и да, box.curr = box.curr + 1 это не ООП. ООП это как минимум box.set_curr(box.get_curr + 1), особенно в Lua, где невозможно нативное создание приватных членов.

alpet

14.08.2014, 20:12

Цитата(HikeR @ 14.08.2014, 20:23)

1. второй раз покажу, это нетрудно — local box = level.object_by_id(id).ammo_box
2. и да, box.curr = box.curr + 1 это не ООП. ООП это как минимум box.set_curr(box.get_curr + 1), особенно в Lua, где невозможно нативное создание приватных членов.

1. Так мне надо увидеть код в исходниках luabind. Ничего подобного я не нашел, скажем в функции construct_lua_class_callback нет никаких намеков на копирование чего-либо. А метатаблица создается один раз.
Расходы на создания враппера object_rep безусловно имеются, но они фиксированные и на современных процессорах могут считаться исчезающе малыми. Имхо некоторые COM-интерфейсы куда дороже обходятся, и ничего - используют люди. Если потребуется гоняться за экономией 1000 тактов ЦП на доступ к свойству, то уж лучше тяжелый код в движок сразу перетащить, разве не так?
Кстати не исключаю возможности кэширования object_rep в часто используемых объектах, с отключением сборщика мусора. Тогда расходы будут совершенно ничтожными, сравнимыми с smart_cast.

Если уж говорить об качественной оптимизации для скриптов, я за время своего знакомство с ТЧ обнаружил массу тормозов именно из-за некорректного использовании API, а не на реализации.
Скажем чего стоит только перебор 65535 объектов, с вызовами level.object_by_id или alife():object. Особенно весело, когда сканирование ведется несколько раз подряд. Решил эту проблему только выделением поиска в двоичный код, для чего в перехватчике реализовал реестр игровых объектов. И там в самом деле приходится копировать указатели на всех объекты, и часть свойств регулярно копировать. Но результатом стала огромная оптимизация поиска.
Поскольку появились исходники движка, это можно сделать и на С++, без использования копии списков объектов.

2. Хм, так ведь не обязательно использовать всегда .def_readwrite. Если требуется валидация значения при присвоении, куда правильнее использовать .property, а не редко без оного и вовсе не обойтись.

User_X.A.R26

14.08.2014, 20:38

Снова своими кривыми руками пытаюсь скомпилировать сорсы ЧН 10 патч. Сейчас собираю xrEngine, но никак не могу собрать. Папки вроде бы прописал все, что нужны. Если компилировать на Mixed-конфигурации, то получается вот такой лог, если на Release, то вот лог, при Debug такой лог. Как быть?

MegaNub

14.08.2014, 21:02

User_X.A.R26, можно логи по нормальному прикрепить, а то как-то скачивать или куда-то переходит не охото, ну или выдержку из них?

HikeR

14.08.2014, 21:38

Цитата(alpet @ 14.08.2014, 21:12)

Так мне надо увидеть код в исходниках luabind.

luabind — всего лишь обертка над Lua C API, с огромным геморроидальным пластырем в виде boost-а. а луашное апи это набор функций для работы со стеком, lua_pushXXX добавляет в стек, lua_toXXX достает из стека (XXX = integer, string, function и прочие поддерживаемые типы), плюс двусторонний вызов ф-ий. никакой самостоятельностью luabind не занимается, тупо генерит тонны шаблонного кода из пары строчек.

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

Цитата(alpet @ 13.08.2014, 23:21)

Код

ammo:get_ammo_box_curr() = ammo:get_ammo_box_curr() + 1

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

YURSHAT

14.08.2014, 21:41

User_X.A.R26, в логе же сказано, что oalibmt.lib скомпилена более старой студией нежели ваша. Как вариант нужно пересобрать либу oalibmt.lib вашей версией студии.

HikeR

14.08.2014, 21:41

Цитата(alpet @ 14.08.2014, 21:12)

с отключением сборщика мусора

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

alpet

14.08.2014, 22:05

Цитата(HikeR @ 14.08.2014, 22:38)

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

Увлекся копипастой, вот и написал ерунду. Надеюсь понятно, что я на самом деле имел в виду.

Цитата(HikeR @ 14.08.2014, 22:41)

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

Это не справедливо. Свойства актора кроме как моими методами ещё не достаются в движке, по крайней мере большая часть.

Vampir35

14.08.2014, 22:24

Цитата(alpet @ 14.08.2014, 23:05)

Этой действительно так, но главное, чтобы в любой момент можно было использовать "старые" методы оригинала. Иначе тяжелая адаптация может просто отпугнуть от патча модмейкеров)

HikeR

14.08.2014, 22:31

все равно не понимаю. хочется больше ООП, но стандартные геттеры/сеттеры заменяются на небезопасный прямой доступ. вместо быстрого вызова по ссылке db.actor создается его двойник get_actor_obj().

помимо актора есть еще туча объектов. натравите toLua++ на заголовки нужных классов — получите доступ из луа ко всем классам/членам/чему угодно, без необходимости ручками прописывать биндинги каждому классу/члену/чему угодно (с оговорками, ессно). вот будет раздолье...

вот банальный вопрос: почему разработчики постоянно юзают "страшную" скриптовую функцию типа isMonster/isStalker вместо того чтобы для каждого объекта хранить дополнительный тип? ответьте на него и вам сразу станет понятна безперспективность в развитии выбранного вами способа облегчения жизни скриптописателя.

alpet

14.08.2014, 23:12

Цитата(Vampir35 @ 14.08.2014, 23:24)

Согласен, методы оригинала абсолютно неприкосновенны.

Цитата(HikeR @ 14.08.2014, 23:31)

1. все равно не понимаю. хочется больше ООП, но стандартные геттеры/сеттеры заменяются на небезопасный прямой доступ.
2. вместо быстрого вызова по ссылке db.actor создается его двойник get_actor_obj().
3. помимо актора есть еще туча объектов. натравите toLua++ на заголовки нужных классов — получите доступ из луа ко всем классам/членам/чему угодно, без необходимости ручками прописывать биндинги каждому классу/члену/чему угодно (с оговорками, ессно). вот будет раздолье...
4. вот банальный вопрос: почему разработчики постоянно юзают "страшную" скриптовую функцию типа isMonster/isStalker вместо того чтобы для каждого объекта хранить дополнительный тип? ответьте на него и вам сразу станет понятна безперспективность в развитии выбранного вами способа облегчения жизни скриптописателя.

1. Luabind сам генерит геттеры и сеттеры для свойств. Если где-то отдельно нужны проверки на диапазон, можно без проблем использовать движковые геттеры и сеттеры через .property.
2. А как ещё-то? db.actor это переменная класса object_rep с отсылкой на обертку CScriptGameObject для объекта актора. В то время как get_actor_obj() возвращает object_rep с ссылкой на CActor и соответственно другой метатаблицей.
Мне никакого интереса загрязнять CScriptGameObject всеми свойствами актора нет.
3. Это только кажется просто. А на самом деле отдельные свойства надо конвертировать, выводить из глухой приватности класса - автоматика тут не поможет.
4. Сильно сомневаюсь, что они это по требованиям высокой производительности сделали. Скорее ради большей багоустойчивости скриптового API.
Алаверды: почему разработчики сделали выдачу интерфейсов get_car, get_hanging_lamp, они же могли и эти свойства засыпать в game_object по идее?

krovosnork

14.08.2014, 23:27

Цитата(MegaNub @ 14.08.2014, 16:59)

Да, Real-time, всё работает. На ЗП к сожалению не заведётся, нужна Debug или Mixed версия xrEngine

А на ТЧ сделать можно?

HikeR

15.08.2014, 00:14

1. lua-скрипту совершенно фиолетово что там генерит luabind, он (luabind) работает для си-программиста, а не для скриптописателя.
2. поэтому вы решили загрязнить глобальное пространство имен в Lua? странный подход.
3. приватные члены на то и приватные, чтобы их не трогали и никуда не выводили. и toLua в корне отличается от luabind-а, корпеть над каждым "свойством" не нужно.
4. нет связи с багоусточивостью, скорее наоборот, нужно отслеживать все такие ф-ии и своевременно добавлять в них новые проверки (по мере разработки).

p.s.
уточняющий вопрос, от экспорта в скрипты абсолютно всех классов/переменных вас останавливает только трудоемкость и рутинность этой операции и ничего более?

alpet

15.08.2014, 00:45

Цитата(HikeR @ 15.08.2014, 01:14)

2. поэтому вы решили загрязнить глобальное пространство имен в Lua? странный подход.
3. приватные члены на то и приватные, чтобы их не трогали и никуда не выводили. и toLua в корне отличается от luabind-а, корпеть над каждым "свойством" не нужно.
4. нет связи с багоусточивостью, скорее наоборот, нужно отслеживать все такие ф-ии и своевременно добавлять в них новые проверки (по мере разработки).
5. уточняющий вопрос, от экспорта в скрипты абсолютно всех классов/переменных вас останавливает только трудоемкость и рутинность этой операции и ничего более?

2. Уж лучше добавить 1 функцию в _G, чем пару десятков в game_object.
3. И что-же поделать, если по замыслу разработчиков класса они приватные, а мне нужен доступ RW?
4. Так что-же, они просто хотели сэкономить 100 мс процессорного времени за час работы движка?
5. Целесообразность, вот чем я руководствуюсь. То что я сейчас вытаскиваю наружу, уже давно и успешно используется в моде NLC, только там приходится тупо напрямую с памятью работать.
По мне так, это пока один из немногих модов, где исчезает статичный мир оригиналки - и все становиться более-менее изменчивым.

MegaNub

15.08.2014, 07:44

Цитата(krovosnork @ 15.08.2014, 00:27)

А на ТЧ сделать можно?

В теории - да, а так фиг его знает. Хотя почему бы и нет, если кому-то будет охото этим заниматься?

abramcumner

15.08.2014, 11:15

Цитата(alpet @ 14.08.2014, 20:09)

Функция alife_object всегда возвращает CSE_ALifeDynamicObject, и никакой другой. Так что, видимо все-таки не знали

alife():object возвращает конкретный серверный класс. Если был зарегистрирован скриптовый, то возвращает скриптовый серверный класс.

alpet

15.08.2014, 12:17

Цитата(abramcumner @ 15.08.2014, 12:15)

Ок. Тогда предскажите выполнение следующего кода:

Код

local sa = alife():object(0)
if sa then
   if sa.reputation then
      printf(" actor reputation %s ", sa:reputation())
   else
      printf(" object 0 is not cse_alife_creature_actor ")
   end
end

HikeR

15.08.2014, 15:19

Цитата(alpet @ 15.08.2014, 01:45)

Уж лучше добавить 1 функцию в _G, чем пару десятков в game_object.

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

Код

-- вместо четырехкратного вызова глобального объекта
local pos = db.actor:position()
local dir = db.actor:direction()
local vid = db.actor:level_vertex_id()
local gvid = db.actor:game_vertex_id()

-- он вызывается однократно
local actor = db.actor

local pos = actor:position()
local dir = actor:direction()
local vid = actor:level_vertex_id()
local gvid = actor:game_vertex_id()

(предполагается, что переменные pos/dir/etc используются более одно раза)

теперь правильное применение вашей инициативы:

Код

local actor = get_actor_obj()

local pos = actor:position()
local dir = actor:direction()
local vid = actor:level_vertex_id()
local gvid = actor:game_vertex_id()

и накой весь этот огород?

по поводу остального вчера были умные мысли, но ночью форум упал и не дал возможность ими поделиться, а сейчас все с головы вылетело ;)

alpet

15.08.2014, 16:33

Цитата(HikeR @ 15.08.2014, 16:19)

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

1. Согласен со всем сказанным, только вот не уверен что обращение к get_actor_obj() дороже в сравнении с обращением к db.actor. Во втором случае приходится ещё и таблицу db проверять.
Более того, я нигде не видел подобных оптимизаций:

Код

local client_obj = level.object_by_id
for i = 1,65535 do
local obj = client_obj(i)
...
end

Везде и всегда идет 65535 обращений к глобальной таблице level.
2. Все-бы хорошо, но get_actor_obj возвращает объект класса CActor, а не game_object. Подразумеваются несколько разные возможности и начинки классов. Дублировать стандартные функции я в CActor/CGameObject не решился.

HikeR

15.08.2014, 18:12

Цитата(alpet @ 15.08.2014, 17:33)

Во втором случае приходится ещё и таблицу db проверять.

не приходится, поиск начинается с db, а actor вызывается уже после нахождения. разница ровно на одну инструкцию.

> Везде и всегда идет 65535 обращений к глобальной таблице level.
в оригинальных скриптах не нашел ничего подобного. а "мододелы" никогда не задумывались об оптимизациях, не говоря уже про вникание в механику Lua.

стандартная Lua-практика по оптимизации hash lookup:

Код

local byte, char = string.byte, string.char
local function foo(x)
return char(byte(x)+1)
end

вот luajit выше второй версии прямо предупреждает в мануале, что он способен сам справится с подобными конструкциями и не надо ему мешать. любую глобальную таблицу любой вложенности можно смело вызывать напрямую (типа x = string.char(x):lower():byte()). ручное кеширование требуется только для ffi-вызовов внешних ф-ий напрямую из C–кода (но оно и понятно).

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

> get_actor_obj возвращает объект класса CActor, а не game_object
ок, пример неудачен. однако принцип использования точно такой же, что-то глобальное один раз кешируется и для обращения к элементам используется уже локальная ссылка на это что-то. поэтому в скриптах никакой разницы не обнаружится, кроме роста глобального окружения.

> Дублировать стандартные функции я в CActor/CGameObject не решился.
а надо не дублировать, надо заменять все под одну гребенку ;)

alpet

15.08.2014, 18:36

Цитата(HikeR @ 15.08.2014, 19:12)

1. не приходится, поиск начинается с db, а actor вызывается уже после нахождения. разница ровно на одну инструкцию.
2. а надо не дублировать, надо заменять все под одну гребенку

1. Что-то сомневаюсь я в такой простоте

Скорее всего в таблицах Lua производится бинарный поиск, каждый раз с середины таблицы (или бинарного дерева, в случае boost::map).
2. Это как? В настоящее время я делаю экспорт свойств для самых основных объектов: артефакты, броня, оружие и т.п. И классов получается много больше будет доступно в скриптах, в сравнении с оригиналом.

alpet

16.08.2014, 00:50

Ещё починил дамп файла lua_help. Однако теперь жирно получается с скриптовым API у меня, для базовых объектов основные функции и свойства готовы

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

jketiynu

16.08.2014, 23:58

Sorry for posting in English, but I'm having one last hurdle in compiling the CS source.

Here is the error log from Visual Studio: http://pastebin.com/taNTErW7

It appears to be a problem with problem_solver.h.

Feel free to reply in Russian as I can use Google Translator.

*Edit*
Found solution through Google but haven't tried it yet.

jketiynu

17.08.2014, 01:36

Sorry again for the English.

I got everything to compile, but now it crashes with this error:

I have no idea what I did wrong. I could upload the source if someone is willing to take a look at it.Loading DLL: xrRender_R2.dll

CODE

Loading DLL: xrGame.dll

FATAL ERROR

[error]Expression    : hGame
[error]Function      : CEngineAPI::Initialize
[error]File          : EngineAPI.cpp
[error]Line          : 101
[error]Description   : Game DLL raised exception during loading or there is no game DLL at all

stack trace:

0023:74268E37 xrCore.dll, xrDebug::fail(), c:\users\matthew\desktop\cs_source_again\stalker-clearsky-ad3574300e42\development\src\xrcore\xrdebugnew.cpp, 282
0023:00AD405B xrEngine.exe, CEffect_Rain::RenewItem()

MegaNub

17.08.2014, 08:12

jketiynu, точно всё на одной конфигурации собрано? Надеюсь вы понимаете по-русски, а то с английским не важно.

jketiynu

17.08.2014, 08:24

QUOTE (MegaNub @ 17.08.2014, 09:12)

jketiynu, точно всё на одной конфигурации собрано? Надеюсь вы понимаете по-русски, а то с английским не важно.

Yes, it's the same configuration.

I'm now wondering if it has to do with an error in xrNetServer. I tried to compile it, and it generated a .lib file for xrGame to use, but at the same time it would not compile the xrNetServer.dll because of the following errors:

CODE

1>NET_Client.obj : error LNK2001: unresolved external symbol _IID_IDirectPlay8Client
1>NET_Client.obj : error LNK2001: unresolved external symbol _CLSID_DirectPlay8Client
1>NET_Client.obj : error LNK2001: unresolved external symbol _IID_IDirectPlay8Address
1>NET_Client.obj : error LNK2001: unresolved external symbol _CLSID_DirectPlay8Address
1>NET_Client.obj : error LNK2001: unresolved external symbol _CLSID_DP8SP_TCPIP
1>NET_Server.obj : error LNK2001: unresolved external symbol _IID_IDirectPlay8Server
1>NET_Server.obj : error LNK2001: unresolved external symbol _CLSID_DirectPlay8Server
1>..\..\..\binaries\xrNetServer.dll : fatal error LNK1120: 7 unresolved externals

Since it generated the .lib though, I assumed it was okay to use the .lib to build xrGame.dll. Maybe those errors are what is causing the problem though?

----
*Edit*
Solved the problem. I was using an older commit of the repo found here: https://bitbucket.org/stalker/clearsky/src/...00e42?at=master
It included DirectX SDK files, but they weren't the March 2008 version. I replaced them with the ones from March 2008, NetServer.dll compiled fine, then I added it to my bin folder and the game starts normally.

The only problem I have now is that DX10 doesn't work. It gives me the error "Pixel shader 1.1 or higher required" when trying DX10.

Tron

17.08.2014, 11:11

jketiynu,xrNetServer.dll is required for successful launch.

Цитата

Solved the problem. I was using an older commit of the repo found here: https://bitbucket.org/stalker/clearsky/src/...00e42?at=master
It included DirectX SDK files, but they weren't the March 2008 version. I replaced them with the ones from March 2008, NetServer.dll compiled fine, then I added it to my bin folder and the game starts normally.

This version is sucessfully works with dxsdk 2010 jule.just by default jule 2010 is not contains dplay8.lib. It's was moved from older version dxsdk.And is needed special define

this repository is contains only 1.5.0.7.
I not tested on 1.5.1.0.

DX10 works,on "develop",it's main render in this repo

Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.