Winsor

Почему муторный? у меня граф перестраивается только для тех диалогов, которым нужно. Все диалоги перестраивать каждый раз - лишняя нагрузка. И он перестраивается полностью. Мы с Вами пошли просто разными путями. Вы, насколько я понял - пытались скриптом генерировать сам граф, я же генерацию графа оставил на движок, только сделал механизм перезагрузки. Как по мне - оба варианта имеют право на жизнь. Мой пост можно воспринимать как иллюстрацию - как победить shared_data.Она используется не только для диалогов.

Поговорим немного о диалогах в ТЧ 1.0007. Наверное, большинство знают что диалоги (как, например, и артикли в энциклопедии) являются объектами, которые загружаются один раз за всю сессию игры (на основании паттерна Singleton) в структуру SPhraseDialogData : CSharedResource. т.е. если мы разрабатываем диалог, то для проверки того что именно мы написали необходимо выйти и зайти в игру полностью. Само собой это сводит на нет полностью работу с диалогами, создаваемыми скриптами (через експорт функций класса CPhraseDialog). Но часто хочется оживить Зону и разнообразить диалоги. 1) расширяем чуть чуть экспорт CPhraseDialog

В основном UpdateCondition выполняется на главном апдейте CEntityAlive::shedule_Update. т.е. для Вашего класса , если Вы хотите использовать shedule_Update - Вам необходимо свой класс наследовать от CInventoryItemObject. CInventoryItem не имеет в предках CObject и не подходит для Вашей задачи.

Возник вопрос по шейдерами самосвечения, которые реализованы в ОГСЕ. На метку колиматора вешается models\selflight, по содержимому шейдер аналогичен hud_reddot ,добавил в движок экспорт функции для координат экрана, шейдер компилируется, но результат странный...все далается для r2 рендера. Было https://drive.google.com/open?id=0Bz4jwcb1uW2zV1RsZmNqb2NiQlU https://drive.google.com/open?id=0Bz4jwcb1uW2zUmdabHBmeVhRbjQ Стало https://drive.google.com/open?id=0Bz4jwcb1uW2zOFJEMDJRZnNHMTQ https://drive.google.com/open?id=0Bz4jwcb1uW2zbWNkbmJjTllEVHM сами шейдеры - https://drive.google.com/open?id=0Bz4jwcb1uW2zUER6WkdzRUF4WTA Подскажите, пожалуйста, что необходимо добавить в движок еще для правильно работы этих шейдеров?

Что именно? Если касаемо рендера там очень много всяких добавлений, какое из них касается шейдера самосвечения? Если худ оружия - разницы я не заметил. Я готов признать полную несостоятельность свою и пасть ниц пред знающим - но Вы конкретно знаете - что именно правилось, можете меня ткнуть? Или так - вот в каком то репозитарии кто-то что-то поправил и все у них заработало, наверное. У меня уже на 3-и листа такой информации....

Уважаемые знающие, что нужно в движке ТЧ добавить, чтобы работал шейдер selflight на худе оружия? Изменения в рендере, или где то в худе (CHUDTarget::Render) ?

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

методы в оригинале, который бы говорил, где предмет находился до перемещения - InBelt/InRuck - используют итераторы, единственный более быстрый - это InSlot. т.е. для того чтобы определить место, где предмет был - необходимо 1) доэкспортировать методы аналогичные InBelt/InSlot/InRuck в скрипты 2) контролировать вызов калбека строго ДО удаления предмета из списков 3) забыть о асинхронных таймерах при обработке этого калбека из скрипта 4) Вам все равно придется делать вызовы калбека на перед каждым изменением положения предмета, ибо после m_ruck.erase(it); InRuck уже никак не скажет где предмет был... Возьмем например CInventory::Slot - функция помещения предмета в слот. в ней два итератора - по рюкзаку и по поясу. Причем они вызываются последовательно, а не через ИЛИ и удаление предмета это просто erase из списка (не Drop, не REJECT_PARENT). т.е. для того чтобы сказать однозначно откуда был убран предмет в моем случае надо вызвать один и тот же калбек со второй константой callMovingCallback(pIItem,InventoryPlaceChange::removeFromBelt); или callMovingCallback(pIItem,InventoryPlaceChange::removeFromRuck); в Вашем случае, дабы разделить эти две операции и узнать однозначно где был предмет необходимо вызвать два разных калбека? Далее, помещение этого же предмета непосредственно в слот callMovingCallback(pIItem,InventoryPlaceChange::putToSlot); если при Вашем случае не вызывать предыдущие калбеки то в этом месте узнать где предмет был - нет никакой возможности. так что в моем случае не вижу кощунства, а всего лишь упрощение жизни использованием стандартного подхода к обработке событий... вся винда сделана на событиях с константами...

Не надо никакой таблички. просто нужно в нескольких местах сделать правильные вызовы калбека. Для ТЧ 1.0007 1) CInventory::Slot здесь, например, у меня сразу 3-и вызова калбека - перемещение из пояса,перемещение из рюкзака, перемещение в слот 2)CInventory::Belt - перемещение из слота, перемещение из рюкзака, перемещение на пояс 3) CInventory::Ruck - перемещение из слота, перемещение из пояса, перемещение в рюкзак 4) CInventory::Eat - перемещение из рюкзака в результате это выглядит как вызов одного и того же калбека с двумя параметрами - итем и константа, говорящая что с ним произошло. для скрипта - это прицепленый калбек для любого НПС (в том числе и для актора) с проверкой на второй параметр. p.s. Ну раз тема "Редактирование движка" - то понятно, что это все делается при наличии исходников. В каких либо других вариантах (отдельные патчи exe) - это может быть реализовано по другому.

В ТЧ 1.0007 hud_adjust_mode аналогично используется только в debug версии движка. Ка пользоваться? Собрать движок в debug configuration, с консоли сказать , например, hud_adjust_mode 1. Более подробно о этом режиме в файле xr_3da\xrGame\ui\UIMainIngameWnd.cpp, как сохранять - разбираться там же. сам параметр сохраняется в user.ltx.

Товарищи... каким образом из окна инвентаря CUIInventoryWnd можно перезарядить неактивное оружие? которое стоит в слоте? CUIGameSP* pGameSP = smart_cast<CUIGameSP*>(HUD().GetUI()->UIGame()); pGameSP->InventoryMenu->GetHolder()->StartStopMenu(pGameSP->InventoryMenu,true); //прячем окно инвентаря m_pInv->ProcessSlotAction(true,weapon->GetSlot()); //делаем активным слот с оружием //а дальше магия - оружие достается, но не играет ни анимация, ни идет перезарядка. //не работает так m_pInv->Items_SetCurrentEntityHud(true); weapon->Action(kWPN_RELOAD, CMD_START); //или так CHudItem* pHudItem = smart_cast<CHudItem*>(m_pInv->ActiveItem()); if (pHudItem) { pHudItem->OnStateSwitch(CWeapon::eReload); }; //или так weapon->OnStateSwitch(CWeapon::eReload); //или так weapon->SetState(CWeapon::eReload); //или так weapon->Reload(); если после активации оружия в слоте (оно разряжено) нажать выстрел, зайти/выйти в главное меню - то CWeapon::eReload состояние применяется... а как сделать это кодом?

почему нельзя??? _GetItem (cmd_line,i,m_params,'/'); в то же движке обычным поиском. для std::string есть функция erase.

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

- Да, почему нет. классы необходимые для этого есть. единственная проблема, над которой я сейчас размышляю - это научить CUIDragDropListEx принимать в себя не InventoryItems, а просто визуал объекта, секцию. спицифическое такое желание. Подходит ли это для ЗП? скорее всего да, разницы в классах я не изучал, но не думаю что очень сильно различаются. - все зависит от того как Вы храните информацию о апгрейдах. в идеале - это отдельный список, который можно обнулять, и на основании которого у Вас применяются какие то свойства. если это отдельные поля объектов - то проще придумать наследуемую функцию, которая обнуляет эти параметры в своем классе и вызывает inherited. так что от архитектуры зависит. Иногда и отдельные функции под каждое свойство - проще чем то что я написал.

все что написано далее - относиться к ТЧ. Количество ячеек не влияет на количество итемов в них. есть класс CUIDragDropListEx (на нем реализован любое визуальное отображение итемов в инвентаре)- ему все равно, сколько в нем ячеек прорисовано. хоть один итем на 5х5 ячеек. т.е. контролировать количество CUICellItem-ов в одном отдельно взятом CUIDragDropListEx - это задача не CUICellItem. Посмотрите, как реализована функция CUIInventoryWnd::ToSlot - вот там ответ на Ваш вопрос - "аналогия с оружейными слотами, вещь просто возвращается на место". реализация самого рюкзака на спине - 1) это отдельное окно, опять таки с CUIDragDropListEx 2) у того же CUIDragDropListEx его заполнение выполняется с помощью цепочки SetItem - в нем Вы сможете по каким либо признакам разрешать или запрещать добавлять итемы в CUICellContainer. Получить CInventoryItem с CUICellItem можно по полю m_pData 3) отображение в рюкзаке - я бы добавил для CUICellItem какой нибудь признак, отображать ли его в инвентаре, или в рюкзаке. единственное - надо выбрать либо из существующих, что сохраняются в сейве, либо добавить в класс CInventoryItem свой признак. я бы использовал m_eItemPlace - он сохраняется в сейве и подходит для такой задачи.

Уважаемый Карлан, так не поделитесь информацией, как Вы у себя смогли решить эту проблему?

- а как именно пофиксили - не поделитесь информацией? интересует именно предметы из ящиков Спасибо за любую информацию! p.s. хотя с другой стороны - что там, что там - все это спавниться ("выпадает"). Но все равно буду очень благодарен за информацию!

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

auto source=this; if (m_Owner==Actor()) { source=Actor(); } source->callback(типкалбекахит)(кто_стрелял, из_чего, чем); теперь в классе актора, или сталкера (да, нужен скриптовый класс биндера "script_binding= ", иначе у чего будет движок вызывать эти методы при их наличии?) регистрируем этот калбек через set_callback в одном вызове (ну и в одном очищаем) - чаще всего init/net_destroy. все, дальше обрабатываем так как надо. никаких load/save/update не требуется. еще один пример - реализация калбека на хит по объекту. движком генерируем вызов этого калбека из CGameObject (прародителя усех объектов в луа). в самих скриптах только в объектах (биндере), например, бочки делаем обработку этого калбека - и все, обрабатываются только бочки. Само собой, иногда приходиться идти на хитрость - есть окно инвентаря - вот куда ему добавить перехват калбека , если по умолчанию, ни сам класс этого окна не экспортируется в игру (это полбеды), ни в игре нету дочернего класса от CUIInventoryWnd, чтобы на нем добавить обработчики (как это например сделано для главного меню). Но со вторым вариантом возиться долго и не интересно. проще всегда делать Actor()->callback(калбек_из_окна)(окно_каллбека, другие параметры) и в биндере актора перехватить это калбек. все, чесно и прозрачно. Придумывать единый механизм, отличный от Actor() для таких целей - ну не знаю, не уверен что это окупиться. Поделиться чем? в движке примерно 4к файлов *.cpp. Сформулируйте вопрос...

@Карлан, с самим CUIInventoryCellItem ничего странного нету. а вот в CUICellItem есть подозрение, что очень много времени занимает построение списка чилдов (PushChild/PopChild). У Вас 200 итемов разных, или группируются по каким либо признакам? Ну и зависит, с какого окна это все вызвали - как по мне, просто CUIInventoryWnd работает быстрее, чем CUITradeWnd.

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

- так а чем закончился Ваш поиск решения?

- да, оно. о великий господин, бью челом - скажите хотя бы в каком файле эти изменения делались ? Пока я отказался от дополнительного статика самого нижнего. Вникаю в CUICellContainer::Draw(). пока не сильно получается У Вас это сделано движком? или внешним скриптом?

Уважаемые, как итему в инвентаре ГГ сменить цвет бакгроунда? ТЧ 1.0007 Ничего умнее CurrentItem()->SetMask(frame_window) с прозрачной текстурой, или текстурой без _back (типа рамочка по краям)... Но коряво это все... и не красиво.

по другому не меняется. а текст с помощью set_tip_text_default() set_tip_text() я делал по другому, правда, не для трупа - в биндере, без мотиватора. в net_spawn делал проверку, и если физический объект надо было юзать - вешал на него калбек и тип_текст. если нет - не вешал