Редактирование движка X-Ray

[Карлан 1 050]

@Kober(BRUC), зачем тебе коллбек, там прекрасно справляется инфопоршень.

 

@mortan, CScriptGameObject::GetObjectByName и CScriptGameObject::GetObjectByIndex.

[Карлан 1 050]

Чего-то я сильно пригрузился. В чем секрет такой адовой тормознутости CUIInventoryCellItem? Драг-дроп конечно тоже далек от идеала, но вот этот класс жрет в ~8 раз больше драг-дропа. Можно конечно заняться оптимизацией того кода, который его использует, но это совершенно неправильно. У меня лист из ~200 итемов грузится ~0.4-0.5 секунды, это вообще трындец, этот класс у одного итема съедает ~1.6 миллисекунды, т.е. это около 70% всего времени, хотя там класс как грабли, со временем конечно разберусь, не сложно, но может кто уже знает.

Изменено 29 Октября 2016 пользователем Карлан

[Карлан 1 050]

@mortan, спасибо, занятно, но я все-же сторонник ванильного ТЧ интерфейса, поэтому бултыхаюсь в том, что есть, все безусловно нужно делать с чистого листа, но это очень много работы, я просто не вывезу по времени. При твоем подходе сеточная система в принципе не нужна, я бы просто к списку привинтил драг-дроп, но честно говоря сама идея мне не нравится, не люблю вот эти все листания взад-вперед, селекции и прочее. Поэтому и в торговле и везде я стараюсь рисовать полный список, хотя это и сильно бьет по оптимизации, а уже в самом интерфейсе, если требуется, давать игроку понять почему сейчас он с этим предметом не может взаимодействовать так как ему захотелось.

 

Если поговорить немного о моих опытах, то я делал на листах интерфейсы, там разумеется никаких тормозов нет, на формирование листа у меня уходило ~20 микросекунд, это в десятки тысяч раз(!) меньше, чем тот интерфейс, который сейчас у меня есть. То есть нужно как-то это все пересматривать, если не в сторону полной, то хотя бы в сторону частичной оптимизации, но мы с тобой на разных платформах, поэтому я просто исходя из ванильного дизайна не могу реализовать все в одном окне (тут я не о конфиге, конфиги как-раз можно свести, но не нужно, там и так не разобраться). А на ЗП и на ЧН там все в принципе проще, и если в ТЧ приходится каждое окно верстать с нуля, то в том же ЗП ты просто берешь их шаблон с этим драг-дропом актора и туда навешиваешь еще всего что нужно и готово. Причем что в ТЧ еще приходится по всяким дочерним окнам изворачиваться, что в ЧН/ЗП сделано обычным хинтом. В ТЧ я тоже написал нормальный хинт, и в принципе если заняться, то можно часть дизайна просто "захинтовать", но мне эта идея не очень нравится, вот эти вот все мерзкие всплывающие описания и т.п. Я веду к тому, что UI кодер на ТЧ, сохраняя оригинальный стиль, тратит времени столько же сколько на ЗП, но помноженное на количество окон + разработка каждого дочернего окна по своему стилю, на самом деле это ужасно, на ЗП работа с интерфейсами идет куда быстрее.

[Карлан 1 050]

@mortan, да нет, на самом деле тоже есть свои плюсы, состоят они в том, что ты любое окно можешь брать и работать с ним как тебе нужно не боясь что ты там случайно поломаешь другие, тут меньше времени уходит на тестирование например, но в целом это конечно так себе плюсы. К тому же в ТЧ нет явного разграничения текстурного и текстового статика, возможно с ООП точки зрения это грамотный подход, но он порою весьма не удобен, но структуризация конечно повышается, сам я уже тоже стараюсь разграничивать, так как текстовый статик я утащил из ЗП, если это можно так назвать, так как в ТЧ он тоже собственно говоря есть, а текстурный просто не трогал, и вот здесь получился некий гибрид, когда ты пишешь так как тебе удобно, и выстраиваешь уже себе ассоциацию из типов или из названий. На самом деле конечно тонна нюансов вплоть до рендеринга, каждый это сразу увидит, кто заинтересуется интерфейсами.

[Карлан 1 050]

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

Изменено 10 Января 2017 пользователем Карлан

[Карлан 1 050]

 

 

  Winsor писал(а):

1) доэкспортировать методы аналогичные InBelt/InSlot/InRuck в скрипты

Вот это и сделано.

 

 

 

  Winsor писал(а):

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

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

[Карлан 1 050]

@mortan, начнем с того, что конфиги артефактов вообще своеобразны, они в части параметров вычисляются под проценты, и там действуют свои делители, в ЗП для этого, как верно выше сказали, существует магнитуда, это ни что иное, как кастомный делитель, который позволяет настроить корректное отображение требуемого параметра. Такой класс можно заводить как общий для всех, так и под каждый класс отдельно создавать. У меня существует собственный класс, несколько расширенный вариант ЗПшного.

 

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

[Карлан 1 050]

@Kondr48, в ЗП, как я понимаю, просто размазали функционал CUIStatic, и CUITextWnd предназначается исключительно для текстовых статиков, а CUIStatic для текстурных. В ТЧ это все один класс, и, как мне опять же кажется, это удобнее. Ничего такого "вау" там нет, и это точно не потерянный функционал CUIStatic, что-то там, как я помню, и добавили, но это совершенно несущественные вещи.

[Карлан 1 050]

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

[Карлан 1 050]

@Kondr48, пысовские обертки над стандартными функциями, которые они под deprecated загнали. В ТЧ можно и без них.

 

@mortan, точно я не помню, вроде в инвентарном овнере, на получении итема в слот он аттачится, там класс что-то вроде атачмент овнер или вроде того.

[Карлан 1 050]

@mortan, смотри формулы. Так и должно быть. Если ты на ЗП, то там все печально, смотри в ТЧ, там все более наглядно.

[Карлан 1 050]

@naxac, в Lua все числа float - 32 разряда. В штатном луа никак использовать их не удастся, но есть специальные расширения позволяющие использовать 64 разрядные числа в Lua, если совсем сильно надо, то можно установить, подойдет и на любой оригинальный движок, с исходниками это все весьма мало связано.

 

А при экспорте 64 разрядных переменных в любых видах игра валится.

[Карлан 1 050]

Какая-то полная печаль и уныние.

 

  18.07.2017 в 15:05, UnLoaded сказал:

Но, тогда, сразу вопрос в догонку: почему для радиоактивных аномалий сделано по иному - как я уже указал в исходном вопросе, тип хита указан напрямую ?

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

 

@Winsor по первому вопросу текстом не знаю как быстро описать.

 

  19.07.2017 в 07:51, Winsor сказал:

при переходе offline/online методы save/load не вызываются. т.е. задача именно из скриптов увидеть этот переход.

Мое хранилище умеет это делать (различать факт того, когда объект удален, от факта, когда объект просто ушел в оффлайн) , пример использования можешь в m_items.script посмотреть. Подробнее писал тут.

 

  19.07.2017 в 06:06, Zagolski сказал:

А в ТЧ многое не так как нужно сделано...

Перечисли несколько примеров, если не трудно. И вот здесь, что конкретно не так?

 

---

 

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

 

 

[Карлан 1 050]

  03.01.2018 в 18:57, dsh сказал:

Похоже, что нет. В net_Spawn() передается CSE_Abstract, а в нем нет измененного condition, там 1.0. Я же и пишу, что кто-то пытался сделать, но то-ли даже не проверял, то-ли проверил и не осилил сделать рабочее.

Все там рабочее, смотри Prosectors 1.3 (там еда подпорченная спавнится движком), если ты не понимаешь процесс создания объекта, и что за серверный объект на самом деле падает в net_Spawn при создании объекта, затем пытаясь написать какой-то свой чудо-код, который вдруг работает не так как хотелось, то это говорит о том, что ты просто не знаешь матчасть создания объекта. Смотри оригинальный bind_smart_terrain.script (не совсем по теме, но по твоим выводам - каждая такая телега для тебя), его не дураки делали. Надо знать когда писать в пакет, еще раз для танкистов, если вы до отправки события спавна (в данном контексте - до вызова net_Spawn), не меняете m_fCondition в пакете заготовки, то не ждите отличной от дефолтного значения кондиции и на клиентской части.

 

Твой метод - костыль. По нормальному так не делается. Не путай людей.

 

  01.10.2018 в 22:42, AndreySol сказал:

Проверил - все правильно...

Cудя по твоим постам-советам на форуме ты супер-модмейкер, а на деле сразу видно, что стать чемпионом страны по шахматам тебе явно не светит. Из твоих вопросов следует, что ты вообще ничего не понимаешь в принципах работы фабрики объектов, рассказывать про это словами - долго, код понять можно быстрее, чем писать эти самые слова как это все работает. Конкретно по твоим пробелам, не регай две пары и будет тебе счастье, за эти "дубликаты" уже давно пора руки отстреливать таким модмейкерам, хотя может кому и нравится мазохизм вида == clsid.что-то_там or == clsid.что-то_там_s, я не знаю. Если кому и нравится, то тот - не я. Потому-что такая шляпа в принципе противоречит формальной логике. Вообще всем скриптерам необходимо знать фабрику, так как в противном они начинают умничать перед, например, мапперами, которые, в последующем, умничают передо мной, говоря что Z_что-то_там - работает нормально, а ZS_что-то_там - не работает вовсе, практически сюда же и великолепная фантазия, что keep_saved_data_anyway не влияет на сохранение client_data. Фи!
Хотя, если бы тут каждый писал только о том, что реально проверил, а не выдумывал свои красочные фантазии ("судя по коду..."(с)) - это был бы уже не АМК.

 

@lordmuzer, в трезвой памяти регать две одинаковые пары никто не будет (да, ст и респавн делали явно НЕ в трезвой). Регистрации вообще все в скрипты переносятся для стандартизации и более широкого управления, но нет гарантии что потом какой-то подобный вася не поменяет числовой клсид на свое более правильное имя, тогда в движке получишь голый вассер на сравнении (с тем самым TEXT2CLSID, что ты упомянул). Поэтому вась нужно держать на поводке и туда не пущать. А где есть фактический объект, то обязательно проверять через кастование (это я к тому, что есть вектора из набора классов и там кастование разумеется невозможно). И немного бредовых мыслей напоследок, например, такое решение - написать эмулятор скриптовой серверной части, и вычистить весь механизм скриптовой регистрации, все-равно в скриптах ты ничего нового не придумаешь по клиентской (хотя можно, но за 11 лет никто не пытался, потому что практика показывает, что в луабинде большинство крутых модмейкеров шарят на уровне домохозяйки). Или написать отдельный конструктор объекта со строковым представлением серверного класса, но это уже отдельные извращения, к тому же это будет именно для того, чтобы в скриптах все заремать (при таком подходе), а если это заремать - публика разорвет. Вот и лавируй чтобы вылавировать.

 

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

[Карлан 1 050]

@dsh, тормози ногами, а не головой. Смотреть сюда, начинаешь новую игру, идешь торговать со сталкерами, смотришь состояние еды. Мой посыл к тому, что если что-то по твоему не доделано/не работает, то так и пиши, что это твое мнение и оно может быть неправильным. Так как "не осилил сделать рабочее" звучит пренебрежительно, особенно когда оно все рабочее. Твой настрой я понял, окей, ответил я ради восстановления справедливости (так как там все рабочее), я из себя тут не завариваю умника во всех направлениях, говорю только о том, что знаю наверняка. А у тебя рот как дверца болтается, базаришь больше, чем вывозишь.

 

  12.10.2018 в 17:09, dsh сказал:

Что, опять захотелось показать, какой ты весь из себя умный?

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